sleep?
renice?
ionice?
cpulimit?
连着上了两周班，搞的闷了一脸痘，右下巴起了个大包，现在还没好，我是谁？为了谁？为了兄弟姐妹不流泪？谁最美？谁最美？
那个周六还是我生日啊，我加班到了23点，在路边吃了碗西红柿鸡蛋面就解决了。第二天一大早又跑过去，有时候真是十分讨厌工作这么认真，这么敬业的自己，，，
OK, this is a long story, let`s cut it short
天那个撸的，一下子给了18T的压缩文件，挂在了3台服务器上，一个压缩包250多G，6个分卷，解压一个包要5个多小时，解压后有600多个1G左右的文件解压过程中还没临时文件名，要想办法区分，那些是已解压完的。上头说让我去协助帮现场同事尽快搞下，不能因为我们数据接入缓慢影响了其它小组的进度，毕竟是公司一年一度的大事啊！我周五下午过去，现场同事晚上就走了，走了，周未回老家，下周一去出差，出差，这闹的那一出啊！这是什么操作，实在看不懂。我也是懵逼，烦躁，惊呆了，这么些个东西，三言两语交代了下，就丢给我了，对，我就是那个接盘侠，看你们这nfs目录mount的，看你们这Kafka topic和hive表的命名，虽然我做事也不怎么样，但命名规则至少要统一啊，我的心瞬间都烦了起来
我也从来没这样接过数据，我也从来没在短时间内接入过这么多数据，还好就一个协议，不然真的是要炸了
想想这么大的一个个压缩包，解压失败了怎么搞，爆盘了怎么搞
又要mount盘又要分发数据又要改配置，人肉部署上百个进程去接入kafka然后入hive，还要人工监控随时根据服务器负载调整，流程复杂，配置麻烦，时间紧迫，有些程序时不时还会崩溃，其它同事天天又嗷嗷待哺样子，上头又天天问进度，十分绝望，，，
还好我不但长的好看且机智，多番打听，在得知这份数据只需要入hive，不入kafka后，我的世界忽然光亮了起来，对，爱是一道光，如此美妙，指引我们想要的未来，魔力北极光，，，
于是，我就想啊想啊，怎么才能以最快又最简单省事的把这几十T的数据解压然后入到hive?
这么简单还用想？
手起手落，冻痴来个冬，啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪啪，花了半天时间，写了三个小小python脚本，一个解压文件，一个扫描识别本地目录已完成解压文件上传hdfs，一个扫描hdfs目录采用动态分区的方式把数据入到hive，又花了半天时间测试验证，基本满足需求
OK，加个班，全部部起来，一台8个解压脚本，16个上传脚本，8个入库脚本，启动，下班，回去睡觉觉，刚要睡着时我想到会木会爆盘啊
果不其然，有生产就有消费，就会有生产与消费速度不匹配的问题，上传hdfs跟不上解压的速度导致爆盘，第二天一大早赶到现场，昨夜11点多时解压失败了，脚本没配自动拉起服务，天那个撸的一整夜都浪费了，老实人我良心有点过不去啊，，，
正常上传1G的文件到hdfs 10s内就可以搞定，在凌晨没人使用hive时，上传的更快，但当hive中跑大量任务资源被大量占用时，就需要10多分钟才能完成一个文件的上传，甚至更久。如果能多撑一会等到集群空闲的时候就好了啊，想法是好的，但事与愿违在你的一生中每次都是以100%的概率出现，你知道？狗都改不了eat shit 的，无论你揍的有多狠，它总会有饥饿的时候，或许原本shit对它就是一种美味的诱惑，也可能它确实是得了某种怪异的病了吧，忘了它，叫我怎么忘了它，就像放开手中沙，，，
怎么搞？不能不让别人用hive啊，也不能守着，随时观察停掉解压啊，一个包要解5个多小时啊，这已经解压了一大半再停掉，太太大太，，，身为一个不是很专业的运维，要让它全自动化的运行才行啊！low逼的在旁边守着，盯着，太有失我高贵程序员的身份了。
首先我想到了在解压脚本中sleep，但是只能在解压上一个包与下一个包之间sleep，现在一个包解压完就600多G了咱又不能修改gzip命令，在其代码中sleep啊，除非使用python接口，不使用gzip命令解压，咱不能总想着在代码中加sleep这种丑陋的方式，而且并不是每一个程序你都有代码可以改，咱们要有种更通用的方式，从外部干预它，，，
renice？但是咱40核cpu使用率不到30%啊，没人跟你抢
cpulimit? 我不想让它慢下来，我还要尽可能的压榨这台服务器，只是不想爆盘而已啊
看看咱这盘又读又写的，好在都是大文件读写，磁盘请求队列时不时会上万，还是和业务共用的服务器，业务反应平常启动系统5分钟，现在半小时也启动不了了，，，
当业务要启动系统读盘时，咱要消停会，ionice调整业务进程io为实时调度最高优先级搞定，，，
爆盘啊，爆盘啊，怎么办，怎么办？
sleep，renice ，ionice，cpulimit 通通不满足我的需求呀呀呀
做为一个半掉子运维的我还是想到了进程有种状态是T，被追踪或停止状态，信号sigstop可让进程变为T状态，信号是什么？信号是一种软中断，可以中断正在运行的进程，信号是进程间的一种异步通信方式
第一次与信号亲密接触是刚工作时，写了个python脚本，第1天白天运行了一天正常，第2天早上去挂了，检查了下程序日志无异常，第3天早上去又挂了，检查了下日志无异常，事不过三啊！不然就是个傻蛋了。通过两天的日志结束时间我发现刚好是下班后程序就挂了，
我就想下班会发生什么？为什么下班后程序就挂了？真是好诡异啊！我就想啊想，我想到了关机，那关机会发生什么？xshell退出，xshell退出会导致什么，控制台连接断开（我想到了信号中有个sighup是跟控制台连接相关的），控制台连接断开会发生什么？会给相关的进程发送sighup信号，而sighup的默认动作是结束进程，OK，忽略此信号，完美解决
那么sigstop信号是干啥的？此信号不可忽略但可被捕获，可以使正在运行的进程暂停直至接收到sigcont信号再恢愎运行
于是小脑袋一动，就有了如下代码，，，
我对着这短短几行代码，欣赏了好久好久，真是被自己帅吊了，，，
运行如下图，效果杠杠的，再也不用担心爆盘了，可以安心睡觉觉了
在磁盘使用率高于97%时会发送sigstop信号给所有gzip进程，暂停解压，当磁盘使用率低于98%时，发送sigcont给所有gzip进程，继续解压，ok，全面推广起来，约么还有60个压缩包12T左右，均分到3台服务器，每台开启5个解压脚本，10个上传脚本，一个入库脚本，就这么白天走走停停夜半疯狂解压
2天愉快的解压完了18T数据，完成了44T数据的入库，此次我也算是第一次感受到了分布式系统极高的吞吐量，100G的数据，26个节点的hive集群，在资源充足的情况下入库只需5分钟，，，
