系統配置
壓測測試部分問題
以前沒有動手實踐高併發系統搭建，對它的認知侷限在事務控制，非同步處理，微服務，負載均衡的應用層處理上。這兩天在伺服器的實踐調優，了解如何配置引數，更重要的是知道為什麼要這麼配置，從而認識到了應用與作業系統的一些相關聯絡。
這個過程遇到了許多bug和系統相關，在這次記錄中也會一起提到。文章後面會附上實測情況。
下面是nginx的主要主要配置。
# 避免許可權問題
user root;
# 一般設定邏輯cpu數，可參看自身系統配置：cat /proc/cpuinfo| grep "processor"| wc -l
worker_processes 6;
# 核心一切皆檔案，所以有客戶端連線就會有檔案使用。
# 開啟檔案控制代碼數量
fs.file-max = 655360
# 最大ip跟蹤數
net.nf_conntrack_max = 655360
#表示當keepalive起用的時候，tcp傳送keepalive訊息的頻度。預設是2小時，改為2分鐘。
net.netfilter.nf_conntrack_tcp_timeout_established = 120
# 允許系統開啟的埠範圍，擴大埠數
net.ipv4.ip_local_port_range = 10000 65535
# 用來限制監聽(listen)佇列最大資料報的數量，超過這個數量就會導致鏈結超時或者觸發重傳機制，
net.core.somaxconn = 65535
# 每個網路介面接收資料報的速率比核心處理這些包的速率快時，允許送到佇列的資料報的最大數目。
net.core.netdev_max_backlog = 262144
# 開啟時就是同乙個源ip來連線同乙個目的埠的資料報時間戳必須是遞增的，否則就丟棄
net.ipv4.tcp_timestamps = 0
# 是否啟用timewait 快速**。如果伺服器身處nat環境，tcp_timestamps為1，安全起見，要禁止
net.ipv4.tcp_tw_recycle = 1
# 開啟重用。允許將time-wait sockets 重新用於新的tcp 連線。
net.ipv4.tcp_tw_reuse = 1
# timeout狀態時間
net.ipv4.tcp_fin_timeout = 15
# 在time_wait數量等於該值時，不會有新的產生，
net.ipv4.tcp_max_tw_buckets = 262144
# 系統中最多有多少個tcp 套接字不被關聯到任何乙個使用者檔案控制代碼上。如果超過這個數字，孤兒連線將即刻被復位並列印出警告資訊。
net.ipv4.tcp_max_orphans = 262144
# 是指定所能接受syn同步包的最大客戶端數量。
net.ipv4.tcp_max_syn_backlog = 262144
# 為了開啟對端的連線，核心需要傳送乙個syn，以確認收到上乙個 syn連線請求包。也就是所謂三次握手中的第二次握手。
# 這個設定決定了核心放棄連線之前傳送syn+ack 包的數量。
net.ipv4.tcp_synack_retries = 1
# 對於乙個新建連線，核心要傳送多少個 syn 連線請求才決定放棄，測試感覺兩個更穩定
net.ipv4.tcp_syn_retries = 2
# 開啟syn cookies，當出現syn 等待佇列溢位時，啟用cookies 來處理，目的是為了防止syn flood攻擊。合法使用者的高負載應該調整tcp_max_syn_backlog、tcp_synack_retries屬性，
net.ipv4.tcp_syncookies = 0
* soft nofile 65535
* hard nofile 65535
* soft nproc 65535
* hard nproc 65535
sysctl -p使得配置生效，可用通過ulimit -a檢視file配置是否生效，臨時設定也可用通過ulimit -u 65535配置。
ab單條測試-c 不能超過1w。下面是測試傳送60w請求，伺服器每秒處理1.3w，90%響應在1.4s內。
# 通過指令碼多執行緒壓測，3個執行緒每個併發1w，實現3w concurrency level，總共24w請求
我們抽選乙個結果可能看到3w 併發的情況下，伺服器90% 的響應時長在3.3s內。高併發以響應90%請求5s內返回指標來看，伺服器的理論極限承載應該可以調整到4w左右rps（requests per second）
檢視net.ipv4.ip_local_port_range、net.ipv4.tcp_tw_recycle、net.ipv4.tcp_tw_reuse、net.ipv4.tcp_timestamps 等系統配置connect() failed (110: connection timed out) while connecting to upstream
要檢視系統日誌：dmesg
異常資訊：nf_conntrack: table full, dropping packet.
解決方案：檢視系統上述net.nf_conntrack_max配置。
當然如果併發數達到一定數量、業務系統伺服器也會超過承載極限，出現請求超時。
apr_pollset_poll: the timeout specified has expired (70007)
主要是timeout連線超時了，可以加個-k引數，讓連線keepalive，另外注意nginx的超時配置。
apr_socket_connect(): 由於目標系統積極拒絕
業務系統伺服器引起，可能是請求過載。
與第二個問題類似，這裡的load 我配置的負載均衡服務名，所以nginx應該是端時間找不到後端可用server，就會報no live upstream。可以考慮增加業務伺服器資料或者改進介面效率。
nginx高併發配置
nginx配置及說明 worker processes 8 nginx 程序數，建議按照cpu 數目來指定，一般為它的倍數。worker cpu affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000...
nginx高併發配置
nginx配置及說明 worker processes 8 nginx 程序數，建議按照cpu 數目來指定，一般為它的倍數。worker cpu affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000...
nginx 高併發配置 1萬併發
系統層優化 系統 socket 層優化 echo 65535 proc sys net core somaxconn 准許最大鏈結數 echo 1 proc sys net ipv4 tcp tw recycle 快速 鏈結 echo 1 proc sys net ipv4 tcp tw reuse...