問題
socket too many open files
進程打開一個文件 ,但是現在進程打開的句柄已經達到了上限，已經無法打開了
查看進程 open file
lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more
查看 open files 配置
ulimit -a #查看當前的
修改open file 配置
ulimit -n 1024 # 修改爲1024 臨時
vi /etc/security/limits.conf # 修改配置文件
滿足併發打開的數量就不會出現該問題了
why
在 Linux 平臺上運行的進程都會從系統資源申請一定數量的句柄，
而且系統控制了進程能夠申請的最大句柄數量。
用戶程序如果不及時釋放無用的句柄，將會引起句柄泄露，
從而可能造成申請資源失敗，導致系統文件句柄用光連接不能建立。
在 Linux 環境中，任何事物都是用文件來表示，
設備是文件，目錄是文件**，socket 也是文件**。
用來表示所處理對象的接口和唯一接口就是文件。
應用程序在讀 / 寫一個文件時，首先需要打開這個文件，
打開的過程其實質就是在進程與文件之間建立起連接，
句柄的作用就是唯一標識此連接。
此後對文件的讀 / 寫時，目標文件就由這個句柄作爲代表。
最後關閉文件其實就是釋放這個句柄的過程，使得進程與文件之間的連接斷開。
lsof # （list open files）是一個列出當前系統打開文件的工
lsof 輸出各列信息的意義如下：
COMMAND：進程的名稱
PID：進程標識符
USER：進程所有者
FD：文件描述符，應用程序通過文件描述符識別該文件。如 cwd、txt 等
TYPE：文件類型，如 DIR、REG 等
DEVICE：指定磁盤的名稱
SIZE：文件的大小
NODE：索引節點（文件在磁盤上的標識）
NAME：打開文件的確切名稱
https://www.jianshu.com/p/382c5b62f693
問題
connect cannot assig requested address
說到這裏就不得不說下tcp 三次握手了
建立tcp 客戶端會分配隨機端口
但是端口有限，
斷開後還有延遲 WAIT TIME
併發數量上來之後，就會出現該問題
多個http 過來之後，tcp連接無法建立
查看端口可用範圍
sysctl net.ipv4.ip_local_port_range
修改配置
# 臨時修改
sysctl -w net.ipv4.tcp_fin_timeout=1 # 修改系統默認的 TIMEOUT 時間
# sysctl -w net.ipv4.tcp_timestamps=1
sysctl -w net.ipv4.tcp_tw_recycle=1 #表示開啓TCP連接中TIME-WAIT sockets的快速回收，默認爲0，表示關閉。
sysctl -w net.ipv4.tcp_tw_reuse = 1 #表示開啓重用。允許將TIME-WAIT sockets重新用於新的TCP連接，默認爲0，表示關閉；
vi /etc/sysctl.conf # 修改配置文件
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
/sbin/sysctl -p
why
tcp_v4_connect的作用主要是完成TCP連接三次握手中的第一個握手，
即向服務端發送SYNC = 1和一個32位的序號的連接請求包。
要發送SYNC請求包，按照TCP/IP協議，就必須有源IP地址和端口，源IP地址的選擇和路由相關，需要查詢路由表，
在ip_route_connect中實現，源端口的選擇在__inet_hash_connect中實現，而且如果找不到一個可用的端口，
這個函數會返回-EADDRNOTAVAIL，因此基本上可以確定是這個函數返回錯誤導致connect失敗；
TCP
CLOSED：無連接是活動的或正在進行
LISTEN：服務器在等待進入呼叫
SYN_RECV：一個連接請求已經到達，等待確認
SYN_SENT：應用已經開始，打開一個連接
ESTABLISHED：正常數據傳輸狀態
FIN_WAIT1：應用說它已經完成
FIN_WAIT2：另一邊已同意釋放
ITMED_WAIT：等待所有分組死掉
CLOSING：兩邊同時嘗試關閉
TIME_WAIT：另一邊已初始化一個釋放
LAST_ACK：等待所有分組死掉
https://www.jianshu.com/p/51a953b789a4
https://www.cnblogs.com/djiankuo/p/5956606.html
https://www.bbsmax.com/A/RnJWbwoYzq/
https://blog.csdn.net/wenshuangzhu/article/details/44060901?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1