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分鐘，，，
