TCP拥塞控制算法是令TCP协议保持高效率传输的重要设计，不过由于大多数人平时并不需要关心它，大家并不会深入去了解各种拥塞协议之间的差异。提到TCP拥塞控制算法，总令人想到一大堆专业名词，例如拥塞窗口、重传、丢包、RTT……等等，不过其本质可以用”排队论”（Queuing Theory）进行解释。本文将尝试用通俗易懂的方式讲解TCP Vegas算法的设计与实现（其他拥塞控制算法其本质并无太大差异，在了解Vegas算法的基础上很容易触类旁通）
先让我们看看维基百科上是如何解释TCP Vegas算法的：
TCP Vegas is a TCP congestion avoidance algorithm that emphasizes packet delay, rather than packet loss, as a signal to help determine the rate at which to send packets.——Wikipedia
TCP Vegas算法是一种拥塞避免算法，它通过关注延迟而不是关注丢包来决定如何调节发包率。
最近团队凉了，下一份工作又还没有完全落实，除了帮着处理一些公司解散的琐事之外，基本赋闲在家，每天遛狗、吸猫、看书、写代码、玩游戏、做饭、打扫卫生，累了就困会儿，精神好就出去遛个弯，过着令人实名羡慕的生活，也算是个Gap Month吧。最近GitHub上有个996.ICU的项目大火，我最近参加了几场面试，也读/重读了几本书，借这篇文章谈谈我的看法和一些思考。
一周前我去某西二旗知名大厂面试，三轮技术面从两点聊到了晚上七点多，最后一轮的面试官在最后问了我两个问题：
我知道如果我渴求这份工作的话，我应该回答可以接受，甚至谎称我之前就996以证明我有足够的“自驱力”，但是我的回答令她失望了，当时的对话内容大概是这样的：
用过类Unix系统的朋友，应该对console、terminator、tty、pty、shell这些单词都不陌生，也应该听说过设备文件、Unix一切皆文件等等说法。但是却很少有人能清晰的解释他们的区别和原理（反正在这之前我也是很懵的），这里我们就来好好捋一捋。
前面讲到了Slurmdbd的配置，Slurmdbd负责存储作业记录，其实同时它还提供了账务信息的存储并负责资源限制的功能。默认情况下Slurm只会根据各集群中的基本配置限制作业，而不会启动跟账务系统相关联的资源限制，我们需要配置AccountingStorageEnforce选项以启用该功能。该配置项允许配置多个限制条件，以逗号分隔，他们分别是：
associationsnostepsnojobs和nosteps听起来很奇怪，配置后将不会记录作业信息，这不是相当于阉割掉了一部分slurmdbd的功能吗？实际上这在你想要使用资源限制但不关心利用率的环境中可能会有所帮助。
经过前面的内容，大家应该对于Slurm最基本的功能使用有了认识。不过对于在生产环境中集群多用户使用作业调度系统，其实还没有深入了解。例如集群环境下如何统一作业运行时的用户权限？Slurm的资源限制究竟是如何实现的？如何为不同的用户配置不同的资源限制策略？如何得到集群资源使用情况的数据报表等等。下面我们就介绍这部分内容，先从Slurm的账务系统（accounting）说起。
前面介绍过了如何为作业指定资源参数，不过我们只涉及到了节点数量、CPU和内存相关的指定。而专业的集群调度系统，应该支持多种复杂的硬件资源管理调度策略，为集群内各种硬件提供统一的资源调度管理。例如目前很火热的GPU集群，就需要统一管理调度GPU资源。通用资源包括但不限于GPU、MIC、NIC等设备的管理，Slurm通过一种灵活的插件机制实现了“通用资源”的管理，你甚至可以自己开发专用的通用资源管理插件以支持特殊的设备管理。GPU是最为常见的，所以我们这里以GPU为例进行介绍。
前面介绍了如何提交作业，不过我们只讲了最简单的作业提交。实际上Slurm的作业提交方式也有多种，将所需的作业编写成脚本再用sbatch命令提交是最为常见的方式，不过这种方式存在弊 端，你可能会因为脚本中某一个命令执行失败而反复编辑脚本，再不断的查看新提交的任务的输出，在调试时显得很不灵活；又或者你的程序需要交互式的应答才能跑通，这时候srun和salloc则是更好的方式。
salloc从字面上就能看出来，实际上是”slurm allocate”的缩写，在解释salloc之前，我们先回顾一下之前对于作业和作业步的定义：
- 作业（job）：特定时间为用户进行的一次资源申请或分配即可看作一个作业。这和我们惯性思维中的作业概念并不一致，传统意义上我们总是认为作业应该是某个运行的脚本或者程序，但事实上Slurm的作业只代表一次资源申请或分配。理解这个区别将有利于你理解Slurm中一些比较高级的用法。
- 作业步（job step）：Slurm中有作业步的概念，你可以理解为子作业。这允许我们在某个作业中分步骤的细分使用计算资源。
前面介绍了如何查看作业的状态，下面我们介绍一下如何查看节点的状态。跟作业状态查看类似，节点状态也可以通过命令行获取，有两种方式：sinfo和scontrol show node，命令行工具的使用时非常简单的，但是节点的状态理解比较复杂。还是先从简单的介绍命令行工具开始吧。
前面介绍了作业的提交，下面我们介绍一下如何查看作业的状态。查看作业状态的方式有多种，Slurm提供了多个命令行工具，包括scontrol,squeue,sstat,sview等等都可以查看作业状态，不过由于我们暂时还没介绍到交互作业和作业步(sstat)，可视化(sview)也不是我们关心的重点，我们先只介绍scontrol和squeue查看作业状态。
如果只是讲这两个命令的使用的话，就大可不必单独写一篇文章来赘述了，我们要关注的核心是状态对应的具体含义。不过在开始之前我们还是先简单介绍一下如何使用这两个命令行工具。
上一节中我们介绍了最简单的作业提交，我们将脚本编辑好之后交由Slurm调度，然后该脚本会运行在合适的节点上，并得到输出结果。在单台计算机上运行时，我们会觉得一切都很自然，就像是写几行代码然后编译运行得到结果一样。不过当你有一个集群时，就有一些区别了。假设我们有一个20个计算节点的集群，假设是如下配置：
1 | ################################################ |
一共有20个节点，我将他们分成了三个队列：高性能、普通、二者混合。