由于 MySQL 进程，我面临 CPU 负载过高的问题。我使用 Google 搜索以解决此错误，但没有成功。
我在 Google 上找到了解决方案，好像这是由于磁盘空间不足导致的，但是在我的计算机上df -f显示如下。它只占用了 77%。
[root@mydomain log]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
87G 63G 19G 77% /
/dev/sda1 99M 24M 71M 26% /boot
tmpfs 1014M 0 1014M 0% /dev/shm
很抱歉给您带来不便。实际上，我已将大图移至/var/log/mysqld.log。/var/log/mysqld.log.bak现在不再出现/var/log/mysqld.log如下所示的错误。
[ERROR] /usr/libexec/mysqld: Error writing file '/var/run/mysqld/mysqld.pid' (Errcode: 28)
[ERROR] Can't start server: can't create PID file: No space left on device
[ERROR] /usr/libexec/mysqld: Table './db_name/table_name' is marked as crashed and should be repaired
现/var/log/mysqld.log列出：
[root@mydomain log]# tail -5 /var/log/mysqld.log
130724 08:33:53 mysqld started
130724 8:33:54 InnoDB: Started; log sequence number 0 94462
130724 8:33:54 [Note] /usr/libexec/mysqld: ready for connections.
TOP命令输出。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7831 mysql 18 0 179m 64m 4492 S 95.6 3.2 1168:01 mysqld
12231 root 16 0 2592 1328 900 R 1.8 0.1 0:00.13 top
136 root 10 -5 0 0 0 S 1.5 0.0 94:19.68 kswapd0
df -i命令输出：
[root@mydomain log]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/VolGroup00-LogVol00
23298048 1235574 22062474 6% /
/dev/sda1 26104 43 26061 1% /boot
tmpfs 224005 1 224004 1% /dev/shm
有人可以帮我吗？
答案1
要显示实际处理的查询，请登录 MySQL 并输入以下命令：
show processlist
如果没有运行查询，那么您可以使用以下命令来跟踪服务器正在执行的操作：
ltrace -p PID # trace library calls
strace -p PID # trace system calls
答案2
你的系统（和大多数系统一样）可能使用 tmpfs（临时文件系统）来/var/运行（查看错误的路径）。
尝试不使用任何别名的 df 命令：
\df -h
（包括反斜杠）。我已将自己的 df 别名为不显示 tmpfs 内容，使输出保持相对干净，但您需要查看完整输出。您还可以通过查看/proc/mounts，但不会显示使用情况和可用空间。
从我的系统：
xenon-lornix:~> \df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 451G 23G 406G 6% /
udev 10M 0 10M 0% /dev
tmpfs 372M 748K 371M 1% /run
/dev/disk/by-label/xenon 451G 23G 406G 6% /
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 2.3G 712K 2.3G 1% /run/shm
但等等！你说...没有/var/运行那里......你是对的，让我们看看 /var/run 在文件结构中的位置：
xenon-lornix:~> ls -l /var/
total 40,960
# extra stuff deleted for clarity
drwxrwxrwt 5 root root 4,096 Jul 24 16:02 tmp/
lrwxrwxrwx 1 root root 9 Jul 18 18:44 lock -> /run/lock/
lrwxrwxrwx 1 root root 4 Jul 18 18:44 run -> /run/
这就是答案： /var/运行是指向/跑步，它位于 372Meg tmpfs 文件系统上。
tmpfs 372M 748K 371M 1% /run
看看/跑步，我猜里面有些垃圾占用了空间。不，我不建议改变尺寸，这并不能解决问题，只是给它贴上创可贴。弄清楚是什么在填充/跑步...这个默认尺寸适用于无数其他机器，那么您的机器又是怎么回事呢？
如果你无法弄清楚是什么占用了空间，你能原因/跑步可以更大，但请记住 tmpfs 与进程共享内存。它速度快、临时，但如果太大，可能会影响正在运行的进程。它目前（默认）设置为核心内存（物理内存）的 10%，这是最大大小。更多详细信息可在 /etc/default/tmpfs 和 tmpfs(5) 手册页中找到。（Debian 系统，其他版本可能有所不同，请先查看 tmpfs(5) 手册页以获取线索。）
由于使用了 tmpfs，内容在重启后不会保留，这意味着重启此服务器将立即解决问题。但除非您弄清楚为什么会发生这种情况，否则可能会再次发生。找出填充 /run (/var/run) 的内容。
/var/lock (/run/lock) 和 /var/shm (/run/shm) 是单独的挂载，与 /run (/var/run) 的大小无关。