我们有两台 ubuntu 8.04 服务器。在数据库服务器上，我将 table_cache 设置为 1000，但是当我重新启动 mysql 时，状态仅显示 257，而打开文件限制显示 1024
我通过执行 ulimit -n 8192 调整了 ulimit，然后重新启动 mysql；这似乎起了作用，然而几个小时后，我执行了 ulimit -n 并发现它又回到了 1024
有点担心。
我编辑了 /etc/security/limits.conf 并添加了
mysql soft nofile 8192
mysql hard nofile 8192
然后重新启动，没有变化。然后我编辑并将 mysql 更改为 * 重新启动，没有变化然后我编辑并将其更改为一行
* - nofile 8192
并重新启动，没有变化。
cat /proc/sys/fs/file-max
给我 768730
sysctl fs.file-max
给我fs.file-max = 768730
我有点不知道如何设置并保持 ulimit 值设置，以便可以在 mysql 上正确增加表缓存。
答案1
[编辑：为清晰起见解释细节]
我怀疑您检查了与 mysql 不同的用户的 ulimit；)
更改后无需重启limits.conf。您必须在 中相应的 PAM 服务中启用此文件的使用/etc/pam.d/。
一定grep pam_limits /etc/pam.d/*要清楚在什么情况下limits.conf会用到它。
例如，在以 ...limits.conf调用的 shell 中可以看到 for中的更改sudo -u user bash，但在以 ... 运行时则看不到sudo su - user- 这是因为 Ubuntu 上的默认设置如下：
$ grep limits /etc/pam.d/*|grep su
/etc/pam.d/su:# session required pam_limits.so
/etc/pam.d/sudo:session required pam_limits.so
因此，如果您使用 检查限制，sudo su - mysql则会出现混乱 -su没有打开限制。您可以通过观察 检查正在运行哪个 pam 服务/var/log/auth.log。
pam.d/other对于所有可能类型的 mysql 调用，修改或仅仅修改都应该是安全的pam.d/common-session。
答案2
一种更直接的方法(也是一种 hack)是ulimit -n 8192在 mysql 的 init 脚本中添加命令 /etc/init.d/mysql。该控制对 shell 及其打开的子进程/shell 有效。
编辑：su之所以sudo出现“怪异”现象，是因为 limits.conf 文件与 PAM 限制有关，如果我没记错的话，它仅适用于登录 shell。此外，还有一些关于start-stop-daemon无法使用 pam 限制的信息。
答案3
如果你不确定 MySQL 的当前限制，请使用你选择的方法（top、ps aux、pgrep 等）检查 mysqld 的当前进程 ID。然后只需输入
sudo cat /proc/mysql_process_id_you_found/limits
如果它没有告诉您打开文件的数量为 8192，您可以按照某人的建议修改初始化脚本。
答案4
您是否将会话所需的 pam_limits.so 添加到 /etc/pam.d/common-session？