MySQL「Resource temporarily unavailable」錯誤根因：limits.conf nproc 限制與線程模型解析

錯誤現場

[root@dbmain ~]# su - mysql
su: cannot set user id: Resource temporarily unavailable

排查過程

1. 檢查 ulimit -a

max user processes (-u) 25600  # 看似足夠
open files (-n) 1024

2. 檢查 /etc/security/limits.conf

mysql soft nproc 500
mysql hard nproc 500   # 關鍵：硬限制僅 500
mysql soft nofile 1024
mysql hard nofile 65536

3. 統計 mysql 使用者進程數

ps -ef | grep mysql
# 僅顯示 3-4 個進程 (mysqld_safe, mysqld, client 連線)

進程數遠低於 500，為何仍報錯？

核心真相：MySQL 線程 = 系統輕量進程 (LWP) 計入 nproc

Linux 線程由 clone() 建立，在 /proc//task/ 下各佔一個目錄，**每個線程佔用一個 nproc 名額**。MySQL 預設 max_connections=151，加上內部背景線程 (IO、Purge、Binlog Dump 等)，輕鬆超過 500。

驗證

# 查看 mysqld 主進程所有線程
ls /proc/$(pidof mysqld)/task/ | wc -l
# 結果可能 600+，遠超 nproc=500

解決方案

修改 /etc/security/limits.conf

mysql soft nproc 65535
mysql hard nproc 65535
mysql soft nofile 65535
mysql hard nofile 65535

或參考 Oracle/Grid 設置：nproc 16384、nofile 65536。

systemd 環境額外配置

# /etc/systemd/system/mysqld.service.d/override.conf
[Service]
LimitNPROC=65535
LimitNOFILE=65535

執行 systemctl daemon-reload && systemctl restart mysqld。

為何 max_connections 不夠用？

• max_connections 僅限制「用戶連線線程」，不包含內部系統線程。
• 每個連線可能衍生多個線程 (Prepared Statement、存儲過程等)。
• 從庫 Slave_IO_Running、Slave_SQL_Running 各佔一線程。

最佳實踐清單

1. 設定 limits.conf nproc/nofile ≥ 65535 (mysql 用戶)。
2. systemd 同步設定 LimitNPROC/NOFILE。
3. max_connections 根據記憶體試算：(總記憶體 - 全域Buffer) / 單線程記憶體。
4. 監控 Threads_connected、Threads_running、ps -eLf | grep mysql | wc -l 實際線程數。

總結

MySQL 線程模型導致系統層面 nproc 消耗遠超可見進程數。**DBA 必須同時調整 OS 層面 limits.conf/systemd 與 MySQL 參數**，單調整一方必失效。此錯誤常發生於新部署、從庫啟動、高併發突增場景，建議納入部署清單標準化配置。