記錄最近出的幾個bug
connection reset by peer
最近服務器經常性的出現connection reset by peer的錯誤，開始我們只是以爲小概率的網絡斷開導致的，可是隨着壓力的增大，每隔2分鐘開始出現一次，這就不得不引起我們的重視了。
我們的業務很簡單，lvs負責負載均衡（採用的是DR模式），keepalive timeout設置的爲2分鐘，後面支撐兩臺推送服務（後面叫做push），客戶端首先通過lvs路由到某臺push之後，向其發送推送消息。
客戶端使用的是python request（底層基於urllib3），首先我很差異出了這樣的錯誤竟然沒有重試，因爲寫代碼的童鞋告訴我會有重試機制的。於是翻了一下request的代碼，竟然發現默認的重試是0，一下子碉堡了。
不過，即使改了重試，仍然沒有解決reset by peer的問題。通常出現這種情況，很大的原因在於客戶端使用的是keep alive長連接保活tcp，但是服務器端關閉了該連接。可是我們的服務器實現了定時ping的保活機制，應該也不會出現的。
然後我將目光投向了lvs，因爲它的timeout設置的爲2分鐘，而reset by peer這個錯誤也是兩分鐘一個，所以很有可能就是我們的定時ping機制不起作用，導致lvs直接close掉了連接。
於是查看push自己的代碼，陡然發現我們自己設置的定時ping的時間是3分鐘，頓時無語了，於是立刻改成1分鐘，重啓push，世界清靜了。
ifconfig overruns
push換上新的機器之後，（性能妥妥的強悍），我們竟然發現推送的丟包率竟然上升了，一下子碉堡了，覺得這事情真不應該發生的。通常這種情況發生在cpu處理網絡中斷響應不過來。但是我們可是妥妥的24核cpu，並且開啓了irqbalance。
好不，用cat /proc/interrupts之後，發現所有的網卡中斷都被cpu0處理了，irqbalance完全沒有起作用。google之後發現，有些網卡在PCI-MSI模式下面irqbalance無效，而我們的網卡恰好是PCI-MSI模式的。
沒辦法，關停irqbalance，手動設置網卡中斷的SMP_AFFINITY，一下子世界清靜了。
總結
可以發現，最近出的幾次蛋疼的事情都是在運維層面上面出現的，實際測試也測不出來，碰到這樣的問題，只能通過log這些的慢慢摸索排查了。當然也給了我一個教訓，任何error級別的log都應該重視，不應該想當然的忽略。