我想查看這個，是因?yàn)槲覀儸F(xiàn)在的業(yè)務(wù)是共享設(shè)備，投放在外面的設(shè)備與服務(wù)器通過TCP長連接，用是GatewayWorker。目前大約有7000臺設(shè)備，Linux內(nèi)核優(yōu)化和event擴(kuò)展都做了，前面6月底的時候出現(xiàn)過TCP連接突然大量掉線，只剩3000左右維持著，查看日志沒有任何東西。原本以為業(yè)務(wù)堵塞，日志里沒記錄下超時。所以想問要不要開啟declare(ticks=1)。

TOP圖截了2張，請大神幫忙看一下，非常感謝。

1.declare(ticks=1)一直沒開，gateway進(jìn)程數(shù)現(xiàn)在是24，按照手冊文檔是有點(diǎn)高，但是當(dāng)時低的時候TCP連接數(shù)達(dá)到一定高度后會自動下降然后再回升，以為是連接性能不夠，所以才增加了gateway進(jìn)程數(shù)。

2.安裝了event擴(kuò)展優(yōu)化linux內(nèi)核，都是很久以前做的工作了，期間gatewayWorker沒有用restart指令，都是stop，然后再start -d啟動的，不知道這樣跟直接restart相同嗎？

3.內(nèi)核優(yōu)化倒確實(shí)是沒有嚴(yán)格按照workerman手冊來，當(dāng)時也參考了其他的文檔，現(xiàn)在在sysctl.conf文件中新增的是這樣：
net.ipv4.tcp_max_tw_buckets = 8000
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 30000
fs.file-max = 6815744
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.ip_local_port_range = 20000 65000
防火墻跟蹤表的大小沒找到在哪里查看，# cat /proc/sys/net/netfilter/nf_conntrack_max，說是no such file or directory

4.打開文件數(shù)，在/etc/security/limits.conf這個文件里是這樣的，比你的建議值?。?br /> root soft nofile 65535
root hard nofile 65535

• soft nofile 65535
• hard nofile 65535
  我想請問用手冊里的方法2：在/etc/profile文件末尾添加一行ulimit -HSn 102400，這樣每次登錄終端時，都會自動執(zhí)行/etc/profile。
  在文件末尾添加這一樣后，需要執(zhí)行什么操作嗎？需要重啟服務(wù)器嗎？

5.優(yōu)化linux內(nèi)核后，都是執(zhí)行了/sbin/sysctl -p，按照大神的說法，都是要重啟gatewayWorker，那執(zhí)行了/sbin/sysctl -p服務(wù)器要重啟嗎？

@1:我們的服務(wù)器用的是阿里云的，運(yùn)行了service iptables status后，看到是loaded:not-found; Active:inactive那應(yīng)該是沒開吧。也咨詢了阿里云的客戶，說公共鏡像系統(tǒng)的服務(wù)器，系統(tǒng)內(nèi)默認(rèn)是沒有開防火墻的。那么我就是沒開防火墻。但是你說的開了防火墻，net.netfilter.nf_conntrack_max這個值設(shè)置的比較低的后果跟我遇到的情況有點(diǎn)像。那我現(xiàn)在需要打開防火墻，再設(shè)置這個參數(shù)嗎？

我目前設(shè)置的是net.ipv4.tcp_tw_recycle=1和net.ipv4.tcp_timestamps=1，搜了一下資料，大神說的不對吧，應(yīng)該是這2個同時為1，會對nat網(wǎng)絡(luò)的客戶端造成影響吧？我現(xiàn)在投放在外面的設(shè)備大部分是通過GPRS手機(jī)卡連接到服務(wù)器的，也有部分是通過路由器。所以是通過路由器的部分設(shè)備因是nat網(wǎng)絡(luò)會連接異常斷開？那我要把net.ipv4.tcp_tw_recycle改成0嗎？

stop再start和restart一個效果
沒開防火墻就不需要net.netfilter.nf_conntrack_max這個配置，但是如果開了防火墻net.netfilter.nf_conntrack_max一定要按照手冊設(shè)置，如果這個值設(shè)置的比較低，則會導(dǎo)致連接超時或者連接異常斷開，尤其是服務(wù)重啟大量客戶端斷線并瞬間重連時，nf_conntrack表很容易滿，導(dǎo)致有大量客戶端連接失敗或者斷線，而當(dāng)nf_conntrack表慢慢有空余位置時，客戶端的連接慢慢會恢復(fù)。然而如果net.netfilter.nf_conntrack_max值過低，有些客戶端可能會一直無法連接上。

net.ipv4.tcp_tw_recycle和net.ipv4.tcp_timestamps不能同時為1，否則會導(dǎo)致處理nat網(wǎng)絡(luò)的客戶端連接超時或者連接異常斷開

/sbin/sysctl -p 后不用重啟服務(wù)器

之前手誤，應(yīng)該是net.ipv4.tcp_tw_recycle和net.ipv4.tcp_timestamps不能同時為1，否則會造成nat網(wǎng)絡(luò)的客戶端超時

net.netfilter.nf_conntrack_max設(shè)置著，如果開了防火墻會生效，沒開防火墻也不影響

@1:把net.ipv4.tcp_tw_recycle關(guān)掉的話，處于 TIME_WAIT 狀態(tài)的連接數(shù)就會漲上去。當(dāng)時是為了解決TIME_WAIT 過多，所以設(shè)置了net.ipv4.tcp_syncookies = 1; net.ipv4.tcp_tw_reuse = 1 ;net.ipv4.tcp_tw_recycle = 1;net.ipv4.tcp_fin_timeout = 30。那我要把net.ipv4.tcp_tw_recycle改成0嗎？

TIME_WAIT狀態(tài)的連接數(shù)量受net.ipv4.tcp_max_tw_buckets來限制，一般來說TIME_WAIT狀態(tài)的連接數(shù)量不超過2萬都沒事。
TIME_WAIT是一個很正常的網(wǎng)絡(luò)狀態(tài)，不用擔(dān)心。

@1:剛才問了我們的硬件人員，出問題的這個系統(tǒng)里的設(shè)備，從一開始就是用的路由器連接網(wǎng)絡(luò)，那我3月份的時候就已經(jīng)把net.ipv4.tcp_tw_recycle設(shè)置為1了，一直正常運(yùn)行到6月底，將近3個月，那不應(yīng)該是nat網(wǎng)絡(luò)的客戶端超時吧？

如果從使用人數(shù)及頻率上來說，每個月都是逐漸增加的，但是從單月來說，不會突變。比如6月份沒太大變化，但前半個月還好的，后半月卻出問題了。
所以這才是我們一直疑惑的地方，程序沒怎么改動過，一直好好運(yùn)行著，為什么突然就出問題了？目前找到的這些原因，不管是防火墻，還是內(nèi)核優(yōu)化，還是nat網(wǎng)絡(luò)，都不能很好解釋為什么前面好，現(xiàn)在不好？（特別是沒做什么改動，設(shè)備沒大量增加的情況下）

另外還找到2個可能的原因：1.沒有用MySQL組件；2.心跳檢測，沒有心跳的設(shè)備觸發(fā)OnClose，但是OnClose里沒有用Gateway::closeClient($client_id)；（但這2個原因感覺跟上面的一樣，沒法解釋為什么前面好，現(xiàn)在不好）

問題比較多，有勞大神了~

net.ipv4.tcp_tw_recycle和net.ipv4.tcp_timestamps都是1的情況下，僅1臺設(shè)備通過nat網(wǎng)絡(luò)連接服務(wù)端沒有問題，如果設(shè)備數(shù)大于1則有可能會出現(xiàn)問題。

連接數(shù)增加1000后又恢復(fù)的問題這個不好定位，從統(tǒng)計(jì)圖里無法判斷是什么連接，多的連接也不一定是設(shè)備連接，也有可能根本不是php產(chǎn)生的連接，有人在上面運(yùn)行了個什么腳本或者某個軟件升級啥的都有可能產(chǎn)生連接，有人用掃描軟件建立起1000個連接也不是沒可能，網(wǎng)絡(luò)波動啥的都有可能，情況太多，太難定位了。即使現(xiàn)在有現(xiàn)場，你也幾乎沒辦法定位到哪些連接是新增的，因?yàn)橹翱赡懿]有給連接做分類統(tǒng)計(jì)。

沒用到MySQL組件不會直接導(dǎo)致有什么問題，業(yè)務(wù)上注意使用單例以及mysql斷線重連即可。設(shè)備定時向服務(wù)端上報心跳可以保持連接，心跳間隔最好小于1分鐘。onClose代表連接已經(jīng)斷開，不用調(diào)用Gateway::closeClient($client_id)

@1:
http://doc.workerman.net/appendices/kernel-optimization.html
1.大神你好，我把net.ipv4.tcp_tw_recycle改成0了，net.ipv4.tcp_max_tw_buckets 改成20000了，然后從TCP監(jiān)控圖能看出，非活躍連接數(shù)non-established馬上就上升到20000了，然后基本維持在上面。期間因?yàn)楦牧舜蜷_文件數(shù)，重啟了一下，也看到馬上又上升到20000，并維持在上面。不知道這樣好不好？以前就是看到非活躍連接數(shù)non-established一直比較高，所以才把net.ipv4.tcp_tw_recycle開啟的。截圖的話，請看下面第2個回復(fù)（評論里帶不了圖）
2.我看到Linux內(nèi)核調(diào)優(yōu)里面，打開文件數(shù)，前2種方法里面都是修改為102400，只有第3種方法里面是改成了1024000，差了10倍，到底應(yīng)該是改成多少？

@1:
我的服務(wù)器上，tcp_tw_reuse也開啟著，它是用于TIME_WAIT重用，看到有文檔說 “時間戳重用TIME_WAIT連接機(jī)制的前提是IP地址唯一性，得出新請求發(fā)起自同一臺機(jī)器，但是如果是NAT環(huán)境下就不能這樣保證了，于是在NAT環(huán)境下，TIME_WAIT重用還是有風(fēng)險的?！?/p>

所以這意思是如果設(shè)備通過路由器連接的話，像上面說到的tw_recycle一樣，也要關(guān)閉嗎？

要關(guān)閉

進(jìn)程打開文件數(shù)10萬就差不多了，如果你服務(wù)器要支持超過10萬的連接數(shù)，那就再調(diào)到你想要達(dá)到的連接數(shù)的值。

@1:
那現(xiàn)在關(guān)掉tw_recycle及tw_reuse的話，TIME_WAIT的數(shù)量就一直維持在tw_buckets設(shè)定值上，這正常嗎？

大神前面說過“TIME_WAIT狀態(tài)的連接數(shù)量受net.ipv4.tcp_max_tw_buckets來限制，一般來說TIME_WAIT狀態(tài)的連接數(shù)量不超過2萬都沒事?！? 按照這個說法的話，由于有net.ipv4.tcp_max_tw_buckets壓制著，TIME_WAIT狀態(tài)的連接數(shù)量應(yīng)該就是不超過2萬的吧？那就是都沒事的？

TIME_WAIT的數(shù)量就一直維持在tw_buckets設(shè)定值正常。net.ipv4.tcp_max_tw_buckets限制了不會超過2萬

@1:
多謝大神幾天來的解答。
現(xiàn)在把tw_recycle關(guān)掉了幾天了，從監(jiān)控圖來看，TIME_WAIT狀態(tài)的連接數(shù)（即非活躍連接數(shù)non-established）一直維持在20000左右。即使是晚上低谷時段，活躍連接數(shù)established減少了三四千，TIME_WAIT狀態(tài)的連接數(shù)還是維持在20000左右，沒有減少。TIME_WAIT的數(shù)量好像不受實(shí)際連接數(shù)變化的影響？？
截圖請看最后一個回復(fù)，多謝大神指教。

gatewayWorker內(nèi)部有一些接口調(diào)用走的socket調(diào)用，會不斷產(chǎn)生TIME_WAIT的連接

@1:總覺得不是很穩(wěn)定，前幾天還維持在活躍連接數(shù)established接近7千，今天到中午了還只有5千5左右，差了1千多。前面也看了GatewayWorker的分布式部署，想再拿一臺服務(wù)器來做分布式部署。只是覺得我現(xiàn)在只有7千臺設(shè)備的長連接，現(xiàn)在就用2臺服務(wù)器來分布式部署，會不會早了點(diǎn)??？
大神，分布式部署會不會對TCP長連接的效果會好一些？

@1:查看今天的銷售記錄的話，發(fā)現(xiàn)有四家店一筆訂單都沒有，這四家店的設(shè)備加起來差不多1千臺。這4家點(diǎn)昨天還是有訂單的，至少說明設(shè)備是有連接的。這樣的話，感覺就是這4家店斷了，但是奇怪的是，不是這4家店每家斷了部分設(shè)備，而是這4家店里的設(shè)備都斷了。真是奇怪。

通訊量不大的業(yè)務(wù)，服務(wù)器稍微好點(diǎn)的支持10萬連接基本沒有問題，但是不代表任何業(yè)務(wù)都可以支持這么大的量，能否支持這么大的量更多的是取決于業(yè)務(wù)本身。

是否增加服務(wù)器不是單單看連接數(shù)，要根據(jù)具體情況分析，主要看哪里是瓶頸，帶寬？內(nèi)存？cpu？達(dá)到瓶頸并且沒辦法再擴(kuò)展則可以考慮加服務(wù)器。比如從之前截圖看單臺服務(wù)器有7000設(shè)備連接，單臺設(shè)備每天處理的請求數(shù)達(dá)到3億，每秒平均處理3000-4000請求，峰值應(yīng)該會超過1萬。整個系統(tǒng)負(fù)載是3到4左右，cpu使用率超過60%，cpu及負(fù)載已經(jīng)算很高了。如果再來點(diǎn)突發(fā)請求可能cpu就跑滿了，就會導(dǎo)致數(shù)據(jù)延遲、連接斷開的各種問題。那么可以考慮增加服務(wù)器增加gatewayWorker的計(jì)算能力。

帶寬是否跟得上也要注意下，看下監(jiān)控帶寬是否達(dá)到限定值，如果帶寬不夠也是可能造成連接斷開的情況

還有就是業(yè)務(wù)優(yōu)化：
正常情況下7000設(shè)備，假設(shè)每臺設(shè)備10秒傳輸1次數(shù)據(jù)(已經(jīng)算很頻繁)，那么每秒也才700個請求，是目前請求量的1/5，如果每秒700請求系統(tǒng)cpu使用率和負(fù)載將大大降低，能承受的設(shè)備數(shù)會更多一些。所以看下客戶端為什么會發(fā)送這么大量的請求，是否可以優(yōu)化。

還有就是業(yè)務(wù)bug、客戶端bug以及網(wǎng)絡(luò)環(huán)境差導(dǎo)致斷開。

我不清楚你們是什么業(yè)務(wù)，周末大部分公司都放假了，沒訂單很正常吧。有些公司還會周末斷電斷網(wǎng)，設(shè)備自然下線了。

@1:大神說到的截圖17天50億請求，是Gateway的請求數(shù)和BusinessWorker請求數(shù)的總和嗎？
我想請教一下這個請求數(shù)有哪些部分組成??？
因?yàn)榇_實(shí)覺得這個請求數(shù)特別高，于是我們就在我們的測試服務(wù)器上在OnMessage里把服務(wù)器收到的指令全部存到一個文件里。2臺設(shè)備1個小時，服務(wù)器總共收到126條指令，對應(yīng)的，服務(wù)器應(yīng)回應(yīng)126次，那么收發(fā)至少252次。但查看php start.php status(圖見最后一個回復(fù)），Gateway的請求數(shù)就有851條，BusinessWorker的請求數(shù)也有260左右。遠(yuǎn)高于指令的數(shù)量。

另外還有一個，大神說過心跳間隔最好小于1分鐘，是指$gateway->pingInterval這個的值吧？

懇請大神指教。

17天50億是看的Gateway請求，這些請求包括硬件設(shè)備發(fā)往gateway的請求(包含心跳請求)，另外還有極小部分請求是服務(wù)啟動時gateway與Worker建立連接時通訊的請求。

心跳最好是客戶端發(fā)起，發(fā)起間隔小于1分鐘，用于?；睢?/p>

服務(wù)端可以用以下配置，服務(wù)端不發(fā)心跳，如果120秒沒收到客戶端心跳就斷開連接
$gateway->pingInterval = 120;
$gateway->pingNotResponseLimit = 1;
$gateway->pingData = '';

@1:大神你好
1.我們服務(wù)器不主動發(fā)心跳包，但是設(shè)備發(fā)心跳包過來的話會回應(yīng)，然后在服務(wù)器的start_gateway.php里面是這么設(shè)置的：
$gateway->pingInterval = 50;
$gateway->pingNotResponseLimit = 2;
$gateway->pingData = '';

2.如果是看Gateway請求的話，就像我前面說的，我們記錄到文件里的數(shù)據(jù)顯示，2臺設(shè)備發(fā)過來的指令（包含心跳）總共就126條，服務(wù)器回應(yīng)的沒記錄，但理論上是來幾條回幾條，那么總共就是126*2=252次請求，而php start.php status里統(tǒng)計(jì)的Gateway的請求數(shù)就有850多條，剔除極小部分請求是服務(wù)啟動時gateway與Worker建立連接時通訊的請求的話，還是大很多啊。