背景
在一段沒有日志的歷史遺留代碼上面加入監控部署后不久，就收到了服務調用成功率低的告警，真是嘩了狗了
解決過程
client端在線上單機部署，根據監控上面的返回碼比例看出失敗原因都是鏈接失敗，通過 tcpdump 在 server 端和 client 端抓包沒有發現拒絕的鏈接請求，另外有另外一台機器同樣訪問着 server 端的服務，排除丟包（這個可能也可以通過ping命令排除），server端高負載可能，所以可以推斷是 client 端的問題。
看到 client 端定時任務起來后 CPU 滿了，可惜只是個現象，還是看不出到底是機器性能問題還是啥問題
原來的代碼沒打日志，不能直接查到系統錯誤碼，正在執行任務也不能直接改代碼重新部署，改用 telnet 嘗試發起 TCP 連接，遂鏈接失敗
還是沒有系統錯誤碼，不過這樣就好定位了，通過自己寫的 python 工具發起連接試試，
google之，找到 http://www.51testing.com/html/21/66821-147278.html ， http://huoding.com/2013/12/31/316 ，這是個大量 TCP 短連接的調用，基本符合上面說到的情況，根據前輩的建議，開啟了 tcp_timestamps 和 tcp_tw_reuse。一段時間后，就看到 CPU 降下去，成功率上來了撒花
