那天服務器又趴窩了

凌晨三點手機嗡嗡震，不用看就知道報警短信又炸了。用戶投訴頁面慢得跟烏龜爬似的，我爬起來披件衣服就沖向公司機房。服務器風扇叫得跟拖拉機一樣，得，準是哪里又堵車了。這已經不是第一次了，再不想轍老板怕是要讓我卷鋪蓋走人。

工具箱掏出來挨個試

二話不說先接上終端。第一步top命令拍臉上。一看CPU爆到99%，好幾個叫“訂單處理”的進程快把服務器吸干了。其他指標倒還負載像坐了火箭似的沖上兩位數。這不明擺著CPU是瓶頸嗎？趕緊把這幾個吸血鬼的進程號記在小本本上。

內存賬單對不上數

順手敲了個free -m。咦，8G內存剩1.2G，但程序實際吃掉的內存滿打滿算才3G多？剩下4G多憑空蒸發(fā)了？活見鬼！八成是內存泄露在偷電。這時候可不能慌，默默打開監(jiān)控記錄開始拉曲線圖。

硬盤讀寫像蝸牛

搬出iostat大殺器查硬盤。好家伙，某個硬盤的util值卡在98%死活下不來，讀寫速度慢得像老爺車。用lsof一查，原來是個日志文件瘋狂輸出，半夜還這么拼真是服了。立馬把它挪到閑置的SSD上，硬盤瞬間喘過氣來了。

線程打架現場抓包

• jstack伺候那幾個CPU大戶進程
• 把線程堆棧全扒拉出來
• 發(fā)現十幾個線程在搶同一把鎖
• 鎖的持有者居然卡在等網絡響應

真相大白！外面API接口卡死，里面線程排長隊干瞪眼。這設計真夠坑的。

掏了塊膠布出來

連夜給搶鎖那段代碼打補?。?/p>

• 加了超時控制
• 改成異步回調
• 線程池重調參數
• API調用方約談寫血書

折騰到早上七點，負載從15降到0.8。老板拍肩說請我吃燒烤——當然用的是我自己的加班餐補。