TCP 異常斷開
背景：
1、 tcp client 終端為智能手表，目前同時在線大約有6000臺，通過服務器記錄發(fā)現(xiàn)在白天的時候，一些手表的 tcp 斷開比較頻繁，到晚上的時候不怎么斷開（晚上是業(yè)務低谷，各個手表基本不怎么上傳數(shù)據(jù)到服務器）。
2、手表使用的是2G 網(wǎng)絡，活動范圍都在城市內。
3、workerman 運行截圖：
4、已經(jīng)按照“Linux內核調優(yōu)”章節(jié)介紹 的方法調優(yōu)了系統(tǒng)配置
5、機器配置：騰訊云 4核8G 內存，服務器負載穩(wěn)定在0.15
6、設備在線時會保持 TCP 上連接，頻繁傳輸數(shù)據(jù)（每分鐘內都會上傳）
7、有業(yè)務自身實現(xiàn)的心跳機制
向作者和大家請教：是否有辦法判斷 TCP 斷開的原因？比如以下可能：
1.worker 進程超時嚴重
手表終端網(wǎng)絡環(huán)境差
服務器配置有問題
能否指點一下排查的方向，以及 workerman 和我的服務器能否支持這么多設備同時在線
之前排查發(fā)現(xiàn)有業(yè)務 IO 阻塞，解決后情況好了很多，但還是有不少，請大家分享一點經(jīng)驗，非常感謝了。
我們產(chǎn)品目標是8萬手表終端同時在線，該如何調優(yōu) workerman ？
2個回答
打賞
首先感謝你這么詳細的提問！
如果業(yè)務每個請求處理時間都足夠快，支持8萬設備在線是沒問題的。
但是如果業(yè)務有一點慢，比如數(shù)據(jù)庫操作一次需要0.05秒，假設8萬設備每秒產(chǎn)生5000個操作數(shù)據(jù)庫的請求，那么設備每秒產(chǎn)生的請求需要服務端耗時25秒才能處理完(多進程的情況下可以緩解)，這樣請求不斷累積會出現(xiàn)業(yè)務延遲越來越嚴重。如果客戶端設備有做超時斷開操作，那么可能會導致大面積連接斷開重連。往壞一點說，如果某些請求處理更慢些，例如慢sql 訪問外部存儲或者curl超時阻塞了幾十秒，那個情況會變得更差。所以保證每個請求都能極快的處理是保持上萬并發(fā)連接的關鍵。
目前總結的客戶端連接斷開的原因大概有以下幾個方面：
1、設備所處環(huán)境網(wǎng)絡不穩(wěn)定
2、設備與服務器間沒有用心跳來維持連接。心跳間隔最好小于60秒，大于60秒的心跳無法有效維持連接，有些可能需要的心跳間隔更小。
3、沒有安裝event擴展，導致單個進程無法維持超過1024個連接，多余的連接會有超時斷開的情況
4、沒有按照手冊優(yōu)化linux內核
例如內核進程打開文件數(shù)限制了單個進程只能維持1024個連接，多余連接超時斷開
例如內核同時打開了net.ipv4.tcp_tw_recycle 和 net.ipv4.timestamp 導致處于nat網(wǎng)絡的客戶端連接超時
例如內核防火墻跟蹤表 (net.netfilter.nf_conntrack_max)大小設置太低，無法應對大量連接，導致客戶端連接超時或者斷開
5、業(yè)務bug導致一些連接被錯誤的斷開
6、設備bug導致連接斷開
根據(jù)描述，白天設備連接斷開比較頻繁，夜晚比較穩(wěn)定，我有點懷疑是由于白天很多用戶活動與不同的環(huán)境導致，例如在電梯 地鐵 地下室等環(huán)境網(wǎng)絡比較差，連接斷開。等到了信號好的地方又重新連接。
而夜里時大家都在睡覺，不會出現(xiàn)網(wǎng)絡環(huán)境頻繁變更的情況，自然比較穩(wěn)定。
-
aidong_wang 2018-05-19非常感謝提供的思路，看來問題很有可能出在業(yè)務有點慢的問題上。產(chǎn)品初期最關心的是實現(xiàn)業(yè)務邏輯，對于性能問題并不是很重視。我先從這個方向理一下，有進展再向您請教
