騰訊雲國際實名帳號 修改系統文件句柄上限解決報錯
引言：當伺服器‘抽風’時，別急著摔鍵盤！
某天，你的Nginx突然開始報錯："Too many open files"，日誌裡滿屏都是這個，伺服器好像在說："哼，你開太多檔案了，我受不了啦！"這時候你可能會想砸鍵盤，但別急，這其實是系統在提醒你："你的檔案句柄上限不夠用了！"別慌，今天我們就來聊聊怎麼解決這個"手抖"問題。
啥是檔案句柄？餐廳座位的比喻
檔案句柄（File Descriptor）聽起來很專業，但其實很簡單。想像一下你去一家餐廳吃飯，每張桌子就是一個檔案句柄。系統給你分配了1024張桌子，當所有桌子都被佔滿，新來的顧客（比如請求）就只能站著等或者被拒絕。這就像你的程式像餓瘋了的獅子，但系統只給它1024根骨頭，再多的肉都吃不到！
檔案句柄的日常用途
每個開啟的檔案、網路連接、socket等等，都會佔用一個檔案句柄。比如你的Web伺服器需要同時處理1000個連接，每個連接都需要一個句柄。如果系統預設只給1024個，那當連接數超過這個數，自然就報錯了。這就像你的餐廳只有1024個座位，但實際有1500個顧客，只能讓500個站著等或者直接拒絕。
為什麼會有上限？系統的小氣鬼設定
騰訊雲國際實名帳號 系統預設的檔案句柄上限通常設得很低，比如1024，主要是出於安全考慮。畢竟如果一個進程無限開啟檔案，可能會耗盡系統資源，導致整個系統崩潰。但這種預設設定對於高併發的應用（比如Nginx、MySQL、Redis）來說，顯然不夠用。所以，我們需要手動調高這個上限。
報錯現場：當你的程式"哭訴"Too many open files
最常見的場景就是Web伺服器、資料庫或者某個後台服務突然開始瘋狂報錯。比如Nginx的日誌裡出現"open() failed (24: Too many open files)"，或者Java程式拋出"java.io.FileNotFoundException: Too many open files"。這時候，你的程式可能無法再接收新連接，或者檔案操作失敗，整個服務就癱瘓了。
常見的錯誤場景
舉個例子：你部署了一個高流量的網站，突然訪問量暴增，Nginx開始報錯。你檢查日誌，發現全是"Too many open files"，這時候你可能會想："我明明有足夠多的伺服器資源，為什麼還報這個錯？"其實，問題不在硬體，而是系統設定的檔案句柄上限太低，擋住了你的服務。就像你的餐廳有足夠多的座位，但系統只允許你使用1024個，再多的顧客就只能排隊了。
檢查當前限制：先量體溫再吃藥
在動手修改前，得先知道現在系統限制是多少。這就像看病前先量體溫一樣，不能盲目開藥。
用ulimit查看
在終端輸入ulimit -n，會顯示當前shell的檔案句柄上限。通常預設是1024。如果想看更詳細的資訊，可以輸入ulimit -a，裡面會列出所有限制，包括檔案句柄。
查看系統全局限制
輸入cat /proc/sys/fs/file-max，可以看到系統整體的檔案句柄上限。這個值通常比ulimit的值大很多，但具體取決於系統配置。另外，用cat /proc/sys/fs/file-nr可以看到當前已使用的句柄數，格式是"已分配/已使用/最大值"。如果"已使用"接近"最大值"，那就說明需要調整。
臨時解決方案：快刀斬亂麻
如果你只是臨時需要調高，比如測試一下，可以用ulimit命令直接修改當前shell的限制。
命令行直接調高
比如輸入ulimit -n 65535，這樣當前shell就能開啟最多65535個檔案了。但注意，這招只對當前終端有效，重啟終端或者重新登入後就失效了。這就像你臨時在餐廳裡多租了幾個座位，但明天還得還回去。適合緊急情況，但不能作為永久解決方案。
永久解決方案：讓系統"記性好"
想要永久生效，得修改系統配置文件。這就像把餐廳的座位數永久增加，這樣每次開業都能用更多座位。
修改limits.conf
編輯/etc/security/limits.conf文件，添加以下內容：
* soft nofile 65535
* hard nofile 65535
這裡的*代表所有用戶，soft是軟限制，hard是硬限制。如果你只想修改特定用戶（比如nginx用戶），可以把*換成用戶名，例如nginx soft nofile 65535。修改後需要重新登入或者重啟系統才能生效。
調整sysctl參數
除了用戶級別的限制，系統全局的檔案句柄上限也需要調整。編輯/etc/sysctl.conf，添加：
fs.file-max = 100000
然後執行sysctl -p讓配置立即生效。這樣系統整體能支援更多檔案句柄。注意，這個值要大於limits.conf裡設定的值，否則可能還是不夠用。
注意事項：別踩這些坑！
修改配置後，可能會遇到一些坑，得小心避開。
重啟服務還是重啟系統？
有時候修改了limits.conf後，服務還是沒有生效，可能是因为服務是在修改前啟動的。比如Nginx在修改limits.conf後沒有重啟，所以它的限制還是舊值。這時候需要重啟服務，或者對於systemd服務，可能需要修改service文件中的LimitNOFILE參數。比如在Nginx的service文件中添加LimitNOFILE=65535，然後systemctl daemon-reload和systemctl restart nginx。
修改後檢查是否生效
騰訊雲國際實名帳號 修改完成後，可以用ulimit -n檢查當前shell的限制，或者用cat /proc/[pid]/limits查看某個進程的限制。比如Nginx的主進程PID是1234，可以輸入cat /proc/1234/limits，看裡面的"Max open files"是否更新了。如果沒更新，說明配置沒生效，可能需要檢查哪裡出錯了。
PAM模塊的隱藏陷阱
有些Linux發行版需要確認pam_limits模組已啟用。比如在/etc/pam.d/common-session或/etc/pam.d/login中，確保有session required pam_limits.so這一行，否則修改limits.conf可能無效。這就像你寫了一張優惠券，但店員根本沒看到，你還在傻等打折，結果發現自己是自嗨。
Windows用戶別著急，這裡有特別提醒
如果你用的是Windows系統，處理方式就完全不同了。通常需要調整註冊表中的某些鍵值，比如HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\IoPageLockLimit，或者通過組策略設定。不過，Windows環境下檔案句柄的問題相對較少，通常用其他方式管理資源。建議查閱微軟官方文檔，畢竟Windows和Linux底層機制差異太大，不能直接套用Linux的方法。
總結：讓伺服器"吃饱喝足"
檔案句柄上限的問題看似複雜，其實解決起來很簡單。只要知道如何檢查、調整配置，就能讓伺服器不再"抽風"。記住，調整前先確認問題，調整後記得檢查是否生效。別像我朋友那樣，改了limits.conf卻忘了重啟服務，結果還抱怨"改了沒用"，最後才發現是自己忘了重啟。現在你已經掌握了這個技能，下次遇到類似問題，就可以自信地解決，讓伺服器安心工作，別再讓它"餓肚子"了！
附錄：常用命令快速參考
- 檢查當前shell限制：
ulimit -n - 查看系統全局上限：
cat /proc/sys/fs/file-max - 查看實際使用情況：
cat /proc/sys/fs/file-nr - 立即生效sysctl修改：
sysctl -p - 檢查進程限制：
cat /proc/[PID]/limits
