最近已經封網，但是發現了乙個比較嚴重的效能問題，問題很詭異，具體發生經過是這樣的
最終公升高到呼叫方超時，這是個特別詭異的問題，因為tp99是基本沒有變化的，tp999卻在每天
以50ms的方式緩慢公升高。
通過檢視網路tcp重傳包、tcp丟包、執行緒數、記憶體、效能等多個引數問題都沒有特別明顯的
變化，開始以為是呼叫redis tp999單片高導致tp999公升高。有同事提到是不是某個資料大導致
個別請求變大tp999公升高，通過增加監控發現呼叫redis服務是有增高，但幅度不大，最終通過
加監控我突然想到前邊乙個因日誌列印多次呼叫redis服務的效能問題就是這樣解決的。
然後趕緊加多個監控取檢視問題，加到第三個監控的時候，發現此介面tp999特別高，是呼叫
了abtest服務，abtest服務本身tp999並不高，但abtest的max 有高的值，當呼叫abtest服務的
訪問量比較高時例如：每分鐘7、8萬次這時tp999這個碰到max值得機率就很大了。abtest經分析
是壓力測試後導致記憶體釋放沒有那麼及時或記憶體碎片過大導致max效能變差，通過重啟abtest多個
應用tp999回落正常。
2016-10-31於北辰
乙個優酷技術人的雙11
徜徉 優酷直播團隊前端工程師 你從我這個角度看過去，是不是很震撼，滿眼的紅色 徜徉帶著靦腆的微笑說道。2017年11月10日，北京環貿中心d座三樓，數百名優酷人正在備戰雙11 在這個並不算狹小的空間內，擺滿了一排排的辦公桌，不斷有人來回穿梭，討論著事情。徜徉所在的團隊是在乙個多月以前搬過來的，徜徉說...
乙個sql問題的解決
表內容 2005 05 09 勝 2005 05 09 勝 2005 05 09 負 2005 05 09 負 2005 05 10 勝 2005 05 10 負 2005 05 10 負 輸出 比賽時間 勝 負 2005 05 09 2 2 2005 05 10 1 2 自己完成建表語句，插入語句...
去解決乙個問題
你自己可以選擇乙個有挑戰性的題目去攻克嘛，機器學習裡面的，不就行了。伺服器裡面也是的嘛。是的這樣我覺得比較有意思一點，是的，如果將來你真的想進入某乙個領域，你自己先主動解決乙個問題。永遠記住一點，永遠去解決問題，原先激情的你很注重這種結果，現在你踏實學習反而只注重過程不注重結果了。你自己主動去解決問...