湖南通航智能调度多次启动失败

通航智能调度系统在多次启动失败的情况下，可能存在以下几个原因：
1 硬件故障：可能是服务器或计算机硬件出现故障，导致系统无法启动或运行异常。
2 网络问题：通航智能调度系统需要依赖于网络通信，如果网络连接不稳定或网络中断，系统无法正常启动或者运行异常。
3 系统软件问题：通航智能调度系统安装配置不正确或者存在未知漏洞等问题，会导致系统无法正常运行。
针对以上问题，建议采取以下解决方案：
1 检查硬件设备，确保服务器工作正常；
2 检查网络连接，确保连接稳定，如有需要可以考虑增加网络冗余；
3 检查系统软件，如有异常可以进行升级或者安装修复程序等。
同时，还需要对实际情况进行具体分析，了解故障出现的详细情况，找出具体的原因，并针对性地做出相应的处理措施。如果以上方法无法解决问题，建议联系相关技术支持人员寻求帮助。

对于做过 BI 开发的朋友，ETL 并不陌生，只要涉及到数据源的数据抽取、数据的计算和处理过程的开发，都是 ETL，ETL 就这三个阶段，Extraction 抽取，Transformation 转换，Loading 加载。

从不同数据源抽取数据 EXTRACTION ，按照一定的数据处理规则对数据进行加工和格式转换 TRASFORMATION，最后处理完成的输出到目标数据表中也有可能是文件等等，这个就是 LOADING。

再通俗一点讲，ETL 的过程就跟大家日常做菜一样，需要到菜市场的各个摊位买好菜，把菜买回来要摘一下，洗一洗，切一切最后下锅把菜炒好端到饭桌上。菜市场的各个摊位就是数据源，做好的菜就是最终的输出结果，中间的所有过程像摘菜、洗菜、切菜、做菜就是转换。
在开发的时候，大部分时候会通过 ETL 工具去实现，比如常用的像 KETTLE、PENTAHO、IBM DATASTAGE、INFORNAICA、微软 SQL SERVER 里面的 SSIS 等等，在结合基本的 SQL 来实现整个 ETL 过程。

也有的是自己通过程序开发，然后控制一些数据处理脚本跑批，基本上就是程序加 SQL 实现。
哪种方式更好，也是需要看使用场景和开发人员对那种方式使用的更加得心应手。我看大部分软件程序开发人员出身的，碰到数据类项目会比较喜欢用程序控制跑批，这是程序思维的自然延续。纯 BI 开发人员大部分自然就选择成熟的 ETL 工具来开发，当然也有一上来就写程序脚本的，这类 BI 开发人员的师傅基本上是程序人员转过来的。

用程序的好处就是适配性强，可扩展性强，可以集成或拆解到到任何的程序处理过程中，有的时候使用程序开发效率更高。难就难在对维护人员有一定的技术要求，经验转移和可复制性不够。

用 ETL 工具的好处，第一是整个 ETL 的开发过程可视化了，特别是在数据处理流程的分层设计中可以很清晰的管理。第二是链接到不同数据源的时候，各种数据源、数据库的链接协议已经内置了，直接配置就可以，不需要再去写程序去实现。第三是各种转换控件基本上拖拉拽就可以使用，起到简化的代替一部分 SQL 的开发，不需要写代码去实现。第四是可以非常灵活的设计各种 ETL 调度规则，高度配置化，这个也不需要写代码实现。

所以在大多数通用的项目中，在项目上使用 ETL 标准组件开发会比较多一些。

ETL 从逻辑上一般可以分为两层，控制流和数据流，这也是很多 ETL 工具设计的理念，不同的 ETL 工具可能叫法不同。

控制流就是控制每一个数据流与数据流处理的先后流程，一个控制流可以包含多个数据流。比如在数据仓库开发过程中，第一层的处理是ODS层或者Staging 层的开发，第二层是DIMENSION维度层的开发，后面几层就是DW 事实层、DM数据集市层的开发。通过ETL的调度管理就可以让这几层串联起来形成一个完整的数据处理流程。

数据流就是具体的从源数据到目标数据表的数据转换过程，所以也有 ETL 工具把数据流叫做转换。在数据流的开发设计过程中主要就是三个环节，目标数据表的链接，这两个直接通过 ETL 控件配置就可以了。中间转换的环节，这个时候就可能有很多的选择了，调 SQL 语句、存储过程，或者还是使用 ETL 控件来实现。

有的项目上习惯使用 ETL 控件来实现数据流中的转换，也有的项目要求不使用标准的转换组件使用存储过程来调用。也有的是因为数据仓库本身这个数据库不支持存储过程就只能通过标准的SQL来实现。

我们通常讲的BI数据架构师其实指的就是ETL的架构设计，这是整个BI项目中非常核心的一层技术实现，数据处理、数据清洗和建模都是在ETL中去实现。一个好的ETL架构设计可以同时支撑上百个包就是控制流，每一个控制流下可能又有上百个数据流的处理过程。之前写过一篇技术文章，大家可以搜索下关键字 BIWORK ETL 应该在网上还能找到到这篇文章。这种框架设计不仅仅是ETL框架架构上的设计，还有很深的ETL项目管理和规范性控制器思想，包括后期的运维，基于BI的BI分析，ETL的性能调优都会在这些框架中得到体现。因为大的BI项目可能同时需要几十人来开发ETL，框架的顶层设计就很重要。

可能app服务器在维护中。
可能app服务器在维护中，稍后再试，或者系统版本不兼容，向客服反应，也可能手机网络不畅通，建议重新连接就好了。
APP一般指手机软件，手机软件，主要指安装在智能手机上的软件，完善原始系统的不足与个性化。

分散自律调度集中系统,主要由调度中心系统、车站仿真系统和网络传输系统三部分构成。
一、调度中心系统
1、调度中心应用系统
（1）列车调度员工作站
列车调度员台工作站配备带3-4台大屏幕显示器，主要功能是实时监控管辖范围内列车运行状态，制定、调整和下达列车阶段计划，查阅实迹运行图，下达调度命令以及与相邻区段列车调度员交换信息。每个调度区段配备一套备用设备，当主用设备故障时，可取代故障设备，保证系统的正常工作。
（2）助理调度员工作站
助理调度员工作站一般配备1-2台大屏幕显示器，主要功能是：无行车人员车站的调车作业计划的编制、调整以及调车工作的领导工作；同时，可以根据阶段计划和调度员的口头指令进行车站的调车进路的排列。每个调度区段配备一套备用设备（采用N+1备份，同列车调度员台合用备用设备），当主用设备故障时，可取代故障设备，保证系统的正常工作。
（3）控制工作站
控制工作站一般配备1-2台大屏幕显示器, 主要功能是:提供车站的按钮 *** 作界面,可以直接遥控车站的进路和其他信号设备; 本工作站可以和助理调度员工作站合并。
（4）调度长工作站
调度长工作站一般配备带1-2台显示器，让调度长掌握线路实际运营情况 ，组织生产和运输指挥。
（5）计划员工作站
计划员工作站一般配备1-2台显示器,提供站场显示和实际运行图显示,辅助计划调度完成日班计划的生成和下达。
（6）培训台工作站
培训台工作站配备带多显示器的计算机设备，可为调度所各级行车指挥人员提供系统岗位技术培训。
（7）打印机和绘图仪
作为共享设备执行各工作台的绘图和打印命令。
2、总机房设备
（1）数据库服务器
双机热备配置, 安装数据库管理系统DBMS(DB2), 主要功能是存储DMIS/CTC系统的基本图、日班计划、阶段计划、实绩运行图及其他各项数据等。
（2）应用服务器
双机热备配置，主要功能包括：列车阶段计划的生成、调整、冲突检测和调车作业计划的生成等应用,是调度中心系统的核心处理设备。应用服务器可以和数据库服务器合并。
（3）通信前置机
双机热备配置，主要功能是完成中心系统与车站系统的数据交换和通信隔离。
（4）系统维护工作站
系统维护工作站一般配置1台大屏幕显示器, 主要完成网络管理、设备运行状态监视、数据更新等维护功能。
（5）接口机
接口机分为TMIS系统接口机、分界口系统接口机等，实现与其他各相关系统间的数据交换和资源共享。
（6）试验分机
调度中心总机房设置一套试验分机用于车站分机设备的测试和系统的调试。
（7）电源系统
电源系统采用集中供电方式，由防雷屏、转换屏、稳压屏、UPS电源等组成。
二、车站仿真系统
新一代调度集中系统FZK-CTC采用了分散自律的理念,即由车站系统完成进路选排、冲突检测、控制输出等核心功能,所以FZK-CTC的车站系统方案设计是极其关键的。
1、车站自律机LiRC
车站自律机是新一代分散自律型调度集中系统的车站核心设备,其硬件选用专用的工业级计算机设备,在可靠性、数据处理能力等方面有严格保证。车站自律机的 *** 作系统则是特殊定制的实时多任务 *** 作系统,在软件设计上保证高效、简洁、严密，且经过完整全面的测试。
LiRC的功能主要包括：
接收存储调度中心的列车运行计划、调车作业计划等,并可以自动按计划进行进路排列,驱动联锁系统执行
接收调度中心和本地值班员(信号员)的直接控制 *** 作指令(按钮命令),经与列车计划以及联锁关系检查后,确认无冲突后驱动联锁系统执行
2、对信号设备的表示信息进行分析,确认进路的完整性和信号的正确性,并能对不正常情况进行处理
3、对车次号进行安全级管理
（1）列车及调车作业的跟踪
（2）接收邻站的实际和计划运行图
（3）接收调度中心和本站值班员的进路人工干预,并调整内部处理流程
（4）采集数据处理形成信号设备的图形表示信息
（5）列车车次跟踪显示处理
（6）向调度中心发送设备表示信息
（7）形成本站的自动报点信息
（8）输入/输出板
对于6502 继电集中联锁车站,需要设置输入/输出板,完成输入码位的采集和CTC控制指令的输出。输入/输出板包括信息采集板(DIB)和控制输出板(DOB)。
（9）车站值班员工作站
值班员工作站设置于车站运转室内，一般采双显示器，并采用双机热备模式。
其功能主要包括：
（1）用户登录和权限管理
基本图、日计划、班计划、车站调车计划、阶段计划、调度命令的调阅与签收
调车进路的办理，相邻车站的站场显示，区间的运行状态显示
（2）车次号的输入修改确认
（3）行车日志的自动记录、存储、打印
（4）列车编组和站存车的输入上报
（5）调车计划的编制和打印
（6）电务维修终端
系统维护工作站设置于车站信号机械室内，通过CAN或其他现场通信技术与微机监测单元通信，获取信号设备的工作状态, 供电务维修人员参考使用。
（7）综合维修终端
综合维修工作站用于无行车值班人员的车站, 电力、工务、桥隧等工种人员施工时,与调度中心联系进行施工申请,签收调度命令等。
三、网络传输系统
调度中心采用两台高性能100M交换机构成中心冗余局域网的主干, 服务器、工作站等计算机设备均配备两块100M冗余网卡与交换机连接; 调度中心还采用两台中高端CISCO路由器与车站基层广域网连接, 路由器应具备足够的带宽和高速端口以满足通信要求,同时为了保证中心局域网的安全,路由器和交换机之间应加装防火墙隔离设备。
车站系统采用两台高性能交换机或集线器构成车站局域网主干,车站调度集中自律机LiRC、值班员工作站、信号员工作站等设备均配备两个以太网口进行网络连接。车站系统也需要配备两台路由器和车站基层广域网连接。
车站基层广域网连接调度中心局域网和各车站局域网, 应采用双环、迂回的高速专用数字通道, 数字通道的带宽不应低于2Mbps/s,每个通道环的站数不应超过8个站。为了确保通信的可靠性,每个环应交叉连接到局域网两台路由器上。
网络通信协议采用通用的TCP/IP协议, 可采用CHAP 身份验证及IPSEC等安全保密技术。
电务维修系统的网络一般情况下和CTC网络隔离。

大数据调度系统，是整个离线批处理任务和准实时计算计算任务的驱动器。这里我把几个常见的调度系统做了一下分类总结，结合目前阿里云上的MaxCompute中的调度系统，做个对比。

Oozie是一个workflow(工作流)协调系统,是由Cloudera公司贡献给Apache的,主要用来管理Hadoop作业(job)。

统一调度hadoop系统中常见的mr任务启动、Java MR、Streaming MR、Pig、Hive、Sqoop、Spark、Shell等。

配置相关的调度任务复杂，依赖关系、时间触发、事件触发使用xml语言进行表达。

任务状态、任务类型、任务运行机器、创建时间、启动时间、完成时间等。

支持启动/停止/暂停/恢复/重新运行：支持启动/停止/暂停/恢复/重新运行。

可以通过DB支持HA(高可用)。调度任务时可能出现死锁，依赖当前集群版本，如更新最新版，易于现阶段集群不兼容。

Azkaban是由Linkedin公司推出的一个批量工作流任务调度器，主要用于在一个工作流内以一个特定的顺序运行一组工作和流程，它的配置是通过简单的key:value对的方式，通过配置中的dependencies 来设置依赖关系，这个依赖关系必须是无环的，否则会被视为无效的工作流。Azkaban使用job配置文件建立任务之间的依赖关系，并提供一个易于使用的web用户界面维护和跟踪你的工作流。

command、HadoopShell、Java、HadoopJava、Pig、Hive等，支持插件式扩展。

实际项目中经常有这些场景：每天有一个大任务，这个大任务可以分成A，B，C，D四个小任务，A，B任务之间没有依赖关系，C任务依赖A，B任务的结果，D任务依赖C任务的结果。一般的做法是，开两个终端同时执行A,B，两个都执行完了再执行C，最后再执行D。这样的话，整个的执行过程都需要人工参加，并且得盯着各任务的进度。但是我们的很多任务都是在深更半夜执行的，通过写脚本设置crontab执行。其实，整个过程类似于一个有向无环图（DAG）。每个子任务相当于大任务中的一个流，任务的起点可以从没有度的节点开始执行，任何没有通路的节点之间可以同时执行，比如上述的A，B。总结起来的话，我们需要的就是一个工作流的调度器，而Azkaban就是能解决上述问题的一个调度器。

提供job配置文件快速建立任务和任务之间的依赖关系，通过自定义DSL绘制DAG并打包上传。

只能看到任务状态。

只能先将工作流杀死在重新运行。

通过DB支持HA，任务太多时会卡死服务器。

Airflow 是 Airbnb 开源的一个用 Python 编写的调度工具。于 2014 年启动，2015 年春季开源，2016 年加入 Apache 软件基金会的孵化计划。Airflow 通过 DAG 也即是有向非循环图来定义整个工作流，因而具有非常强大的表达能力。

支持Python、Bash、>诸如此类的调度系统有以下基本调度功能
1) 调度 *** 作：呼叫、禁话、强插、强拆、代接、监听、组播、广播、会议、夜服、IP联动话机；
2) 监控功能：能够通过图标颜色和文字指示出用户状态，如呼叫、振铃、通话；
3) 呼叫及通话：拨号呼叫、来电接听、多线路切换；
4) 管理功能：系统管理、分组管理、帐号管理、权限管理、热线管理；
2 行政办公功能
1)内部免费通话；
2)基本电话业务：呼叫转移、呼叫保持、呼叫驻留、呼叫等待、来电显示、免打扰等；
3)会议功能：九方会议、会议桥、公共会议室；
4)语音信箱、呼叫直入、呼叫限制、组合功能键、自动话务员、IVR、用户分组、振铃组呼叫记录、热线功能、视频通讯、录音服务、电话报时、通话话机查询、已接或未接来电、通过话机查询本机号码等。
其他特色的调度功能是根据各产品的情况，比如捷思锐科技的多媒体调度系统，它的特色是
1）分布式部署
允许在一个系统中部署多台调度机，既满足跨地域部署需求，又可以解决单台设备容量不足问题。调度机无需配置，即插即用；
2）双机热备
调度主机可以进行双机热备，而非板卡式备份，为系统安全、稳定的运行提供保障。同时各调度终端可以提供双注册的方式进行注册，在注册到中心调度主机的同时，可以根据需要注册到本地的服务器、调度机或者IP-PBX，在最大程度上保证煤矿内部的通信畅通。
3）救生引导及紧急广播
通过井下多个扩播电话机或广播将声音在井下进行广播，可以用于普及安全知识或丰富矿工业余生活，在紧急情况下还可以作为救生引导系统使用。在出现突发事件时，可直接播放应急预案中设置好的预案语音文件，实现突发事件的快速引导。
4）与其他监控监测系统有效融合，实现应急联动
煤矿安全监控系统、数字工业电视监控系统及其他监控监测系统通过调度机可与整个系统有效融合，实现应急联动功能。
提供报警收集接口，与井下各种监测报警系统有效对接。例如：井下气体监测系统监测到有毒气体，气体监测系统可向MDS调度系统发送相应数据，MDS调度系统触发相应的报警联动系统，以广播或其他方式迅速告知井下人员迅速撤离。
5）通话录音功能
录音系统通过IP网络和调度主机互联互通，实现对指定通话录音；可对多路电话同时录音；可预设录音时间对某些号码进行录音；还可对指定号码进行录音。服务器提供文件查询及管理功能。
6）自定义组功能和权限管理
用户可以按组织结构或职能进行分组，每个成员可以在不同的分组中；调度台支持自定义扩展组功能，可以将成员加入扩展组进行会议和组播功能；支持灵活的、丰富的指挥调度级别和权限设置（指挥、控制、浏览），支持灵活多样的指挥调度和控制模式，系统最大支持256级调度权限，不同权限拥护具备不同的 *** 作能力。
7）座机对讲功能
对讲功能是捷思锐调度系统特有功能，终端只需要按下PTT键即可立即进行类似集群呼叫的组呼；在同一个组中的终端可以听到发起终端的讲话。对讲功能接续速度快，被叫终端自动接听，提高应对速度。
8）集成常规对讲系统
可以把煤矿常规对讲系统和多媒体调度系统融合在一起，实现调度分机、对讲机、外线之间互相通信，并可通过调度台调度对讲终端。
9）视频调度功能
通过可视化终端，调度员可以监控现场图像。视频监控终端还可以和语音设备进行联动，可进行同步的语音视频通话
10）多方紧急会议
煤矿调度人员可在调度台上一键召集多个终端参加多方紧急会议，参会人员可以是内线分机，也可以是外线分机；可以是召集某个组的所有成员，也可召集隶属于不同组的成员参加紧急会议。
11）井下人员定位
井下人员的手持WiFi终端可支持WiFi定位功能，可实时向井上调度中心发送定位信息，井上指挥人员可在显示器上实时查看井下人员所处的位置。

任何领域，革命性的碾压式推陈出新并不是没有，但是概率极低，人们普遍的狂妄在于，总是认为自己所置身的环境正在发生着某种碾压式的变革，但其实，最终大概率不过是一场平庸。

作者 | dog250

责编 | 刘静

出品 | CSDN博客

但凡懂Linux内核的，都知道Linux内核的CFS进程调度算法，无论是从2623将其初引入时的论文，还是各类源码分析，文章，以及Linux内核专门的图书，都给人这样一种感觉，即 CFS调度器是革命性的，它将彻底改变进程调度算法。 预期中，人们期待它会带来令人惊艳的效果。

然而这是错觉。

人们希望CFS速胜，但是分析来分析去， 却只是在某些方面比O(1)调度器稍微好一点点 。甚至在某些方面比不上古老的44BSD调度器。可是人们却依然对其趋之若鹜，特别是源码分析，汗牛塞屋！

为什么CFS对别的调度算法没有带来碾压的效果呢？

首先，在真实世界，碾压是不存在的，人与人，事与事既然被放在了同一个重量级梯队比较，其之间的差别没有想象的那么大，根本就不在谁碾压谁。不能被小说电视剧蒙蔽了，此外，徐晓冬大摆拳暴打雷雷也不算数，因为他们本就不是一个梯队。

任何领域，革命性的碾压式推陈出新并不是没有，但是概率极低，人们普遍的狂妄在于，总是认为自己所置身的环境正在发生着某种碾压式的变革，但其实，最终大概率不过是一场平庸。

最终就出现了角力，僵持。

其次，我们应该看到，CFS调度器声称它会给交互式进程带来福音，在这方面CFS确实比O(1)做得好，但是惊艳的效果来自于粉丝的认同。Linux系统交互进程本来就不多，Linux更多地被装在服务器，而在服务器看来，吞吐是要比交互响应更加重要的。

那么以交互为主的Android系统呢？我们知道，Android也是采用了CFS调度器，也有一些事BFS，为什么同样没有带来惊艳的效果呢？

我承认，2008年前后出现CFS时还没有Android，等到Android出现时，其采用的Linux内核已经默认了CFS调度器，我们看下Android版本，Linux内核版本以及发行时间的关系：

Linux内核在2623就采用了CFS调度器。所以一个原因就是没有比较。Android系统上，CFS没有机会和O(1)做比较。

另外，即便回移一个O(1)调度器到Android系统去和CFS做AB，在我看来，CFS同样不会惊艳，原因很简单，Android系统几乎都是交互进程，却前台进程永远只有一个，你几乎感受不到进程的切换卡顿，换句话说，即便CFS对待交互式进程比O(1)好太多，你也感受不到，因为对于手机，平板而言，你切换 APP 的时间远远大于进程切换的时间粒度。

那么，CFS到底好在哪里？

简单点说，CFS的意义在于， 在一个混杂着大量计算型进程和IO交互进程的系统中，CFS调度器对待IO交互进程要比O(1)调度器更加友善和公平 。理解这一点至关重要。

其实，CFS调度器的理念非常古老，就说在业界，CFS的思想早就被应用在了磁盘IO调度，数据包调度等领域，甚至最最古老的SRV3以及43BSD UNIX系统的进程调度中早就有了CFS的身影，可以说，Linux只是 使用CFS调度器 ，而不是 设计了CFS调度器 ！

就以43BSD调度器为例，我们看一下其调度原理。

43BSD采用了1秒抢占制，每间隔1秒，会对整个系统进程进行优先级排序，然后找到优先级最高的投入运行，非常简单的一个思想，现在看看它是如何计算优先级的。

首先，每一个进程j均拥有一个CPU滴答的度量值Cj，每一个时钟滴答，当前在运行的进程的CPU度量值C会递增：

当一个1秒的时间区间ii过去之后，Cj被重置，该进程jj的优先级采用下面的公式计算：

可以计算，在一个足够长的时间段内，两个进程运行的总时间比例，将和它们的Base_PrioBase_Prio优先级的比例相等。

43BSD的优先级公平调度是CPU滴答驱动的。

现在看Linux的CFS，CFS采用随时抢占制。每一个进程j均携带一个 虚拟时钟VCj ，每一个时钟滴答，当前进程k的VCk会重新计算，同时调度器选择VC最小的进程运行，计算方法非常简单：

可见， Linux的CFS简直就是43BSD进程调度的自驱无级变速版本！

如果你想了解CFS的精髓，上面的就是了。换成语言描述，CFS的精髓就是 “ n个进程的系统，任意长的时间周期TT，每一个进程运行T/n的时间！ ”

当然，在现实和实现中，会有80%的代码处理20%的剩余问题，比如如何奖励睡眠太久的进程等等，但是这些都不是精髓。

综上，我们总结了：

所以无论从概念还是从效果，Linux CFS调度器均没有带来令人眼前一亮的哇塞效果。但是还缺点什么。嗯，技术上的解释。

分析和解释任何一个机制之前，必然要先问，这个机制的目标是什么，它要解决什么问题，这样才有意义。而不能仅仅是明白了它是怎么工作的。

那么Linux CFS调度器被采用，它的目标是解决什么问题的呢？它肯定是针对O(1)算法的一个问题而被引入并取代O(1)，该问题也许并非什么臭名昭著，但是确实是一枚钉子，必须拔除。

O(1)调度器的本质问题在于 进程的优先级和进程可运行的时间片进行了强映射！

也就是说，给定一个进程优先级，就会计算出一个时间片与之对应，我们忽略奖惩相关的动态优先级，看一下原始O(1)算法中一个进程时间片的计算：

直观点显示：

针对上述问题，26内核的O(1)O(1)引入了双斜率来解决：

直观图示如下：

貌似问题解决了，但是如果单单揪住上图的某一个优先级子区间来看，还是会有问题，这就是相对优先级的问题。我们看到，高优先级的时间片是缓慢增减的，而低优先级的时间片却是陡然增减，同样都是相差同样优先级的进程，其优先级分布影响了它们的时间片分配。

本来是治瘸子，结果腿好了，但是胳臂坏了。

本质上来讲，这都源自于下面两个原因：

固定的优先级映射到固定的时间片。

相对优先级和绝对优先级混杂。

那么这个问题如何解决？

优先级和时间片本来就是两个概念，二者中间还得有个变量沟通才可以。优先级高只是说明该进程能运行的久一些，但是到底久多少，并不是仅仅优先级就能决定的，还要综合考虑，换句话距离来说，如果只有一个进程，那么即便它优先级再低，它也可以永久运行，如果系统中有很多的进程，即便再高优先级的进程也要让出一些时间给其它进程。

所以，考虑到系统中总体的进程情况，将优先级转换为权重，将时间片转换为份额，CFS就是了。最终的坐标系应该是 权重占比/时间片 坐标系而不是 权重(或者优先级)/时间片 。应该是这个平滑的样子：

看来，Linux CFS只是为了解决O(1)O(1)中一个 “静态优先级/时间片映射” 问题的，那么可想而知，它又能带来什么惊艳效果呢？这里还有个“但是”，这个O(1)O(1)调度器的问题其实在计算密集型的守护进程看来，并不是问题，反而是好事，毕竟高优先级进程可以 无条件持续运行很久而不切换 。这对于吞吐率的提高，cache利用都是有好处的。无非也就侵扰了交互进程呗，又有何妨。

当然，使用调优CFS的时候，难免也要遇到IO睡眠奖惩等剩余的事情去设计一些trick算法，这破费精力。

对了，还要设置你的内核为HZ1000哦，这样更能体现CFS的平滑性，就像它宣称的那样。我难以想象，出了Ubuntu，Suse等花哨的桌面发行版之外，还有哪个Linux需要打开HZ1000，服务器用HZ250不挺好吗？

关于调度的话题基本就说完了，但是在进入下一步固有的喷子环节之前，还有两点要强调：

在CPU核数越来越多的时代，人们更应该关心 把进程调度到哪里CPU核上 而不是 某个CPU核要运行哪个进程 。

单核时代一路走过来的Linux，发展迅猛，这无可厚非，但是成就一个 *** 作系统内核的并不单单是技术，还有别的。这些当然程序员们很不爱听，程序员最烦非技术方面的东西了，程序员跟谁都比写代码，程序员特别喜欢喷领导不会写代码云云。

Linux在纯技术方面并不优秀，Linux总体上优秀的原因是因为有一群非代码不明志的程序员在让它变得越来越优秀，另一方面还要归功于开源和社区。Linux的学习门槛极低，如果一个公司能不费吹灰之力招聘到一个Linux程序员的话，那它干嘛还要费劲九牛二虎之力去招聘什么高端的BSD程序员呢？最终的结果就是，Linux用的人极多，想换也换不掉了。

但无论如何也没法弥补Linux内核上的一些原则性错误。

Linux内核还是以原始的主线为base，以讲Linux内核的书为例，经典的Robert Love的《Linux内核设计与实现》，以及《深入理解Linux内核》，在讲进程调度的时候，关于多核负载均衡的笔墨都是少之又少甚至没有，如此经典的著作把很多同好引向了那万劫不复的代码深渊。于是乎，铺天盖地的CFS源码分析纷至沓来。

但其实，抛开这么一个再普通不过的Linux内核，现代 *** 作系统进入了多核时代，其核心正是在cache利用上的革新，带来的转变就是进程调度和内存管理的革新。review一下Linux内核源码，这些改变早就已经表现了出来。

可悲的是，关于Linux内核的经典书籍却再也没有更新，所有的从传统学校出来的喜欢看书学习的，依然是抱着10年前的大部头在啃。

>

对于磁盘I/O，Linux提供了cfq, deadline和noop三种调度策略

考虑到硬件配置、实际应用场景（读写比例、顺序还是随机读写）的差异，上面的简单解释对于实际选择没有太大帮助，实际该选择哪个基本还是要实测来验证。不过下面几条说明供参考：

NOOP全称No Operation,中文名称电梯式调度器，该算法实现了最简单的FIFO队列，所有I/O请求大致按照先来后到的顺序进行 *** 作。NOOP实现了一个简单的FIFO队列,它像电梯的工作方式一样对I/O请求进行组织。它是基于先入先出（FIFO）队列概念的 Linux 内核里最简单的I/O 调度器。此调度程序最适合于固态硬盘。

Deadline翻译成中文是截止时间调度器，是对Linus Elevator的一种改进，它避免有些请求太长时间不能被处理。另外可以区分对待读 *** 作和写 *** 作。DEADLINE额外分别为读I/O和写I/O提供了FIFO队列。

Deadline对读写request进行了分类管理，并且在调度处理的过程中读请求具有较高优先级。这主要是因为读请求往往是同步 *** 作，对延迟时间比较敏感，而写 *** 作往往是异步 *** 作，可以尽可能的将相邻访问地址的请求进行合并，但是，合并的效率越高，延迟时间会越长。因此，为了区别对待读写请求类型，deadline采用两条链表对读写请求进行分类管理。但是，引入分类管理之后，在读优先的情况下，写请求如果长时间得到不到调度，会出现饿死的情况，因此，deadline算法考虑了写饿死的情况，从而保证在读优先调度的情况下，写请求不会被饿死。

总体来讲，deadline算法对request进行了优先权控制调度，主要表现在如下几个方面：

CFQ全称Completely Fair Scheduler ，中文名称完全公平调度器，它是现在许多 Linux 发行版的默认调度器，CFQ是内核默认选择的I/O调度器。它将由进程提交的同步请求放到多个进程队列中，然后为每个队列分配时间片以访问磁盘。 对于通用的服务器是最好的选择，CFQ均匀地分布对I/O带宽的访问 。CFQ为每个进程和线程，单独创建一个队列来管理该进程所产生的请求,以此来保证每个进程都能被很好的分配到I/O带宽，I/O调度器每次执行一个进程的4次请求。该算法的特点是按照I/O请求的地址进行排序，而不是按照先来后到的顺序来进行响应。简单来说就是给所有同步进程分配时间片，然后才排队访问磁盘。

多队列无 *** 作I / O调度程序。不对请求进行重新排序，最小的开销。NVME等快速随机I / O设备的理想选择。

这是对最后期限I / O调度程序的改编，但设计用于 多队列设备。一个出色的多面手，CPU开销相当低。

---