我最近在2台服务器之间进行了迁移（最新的规格较低），即使服务器上没有负载，它也会一直冻结，以下是我的规格：
HP DL120G5 / Intel四核Xeon X3210 / 8GB RAM
free -m输出：
total used free shared buffers cached
Mem: 7863 7603 260 0 176 5736
-/+ buffers/cache: 1690 6173
Swap: 4094 412 3681
正如你所看到的那样，交换时有412 mb，而有近80％的物理ram可用
我不知道这是否会造成任何麻烦，但我的旧服务器几乎没有使用交换，所以我认为这似乎不对。
我有cPanel许可证，所以我联系了他们的支持，他们注意到我有高iowait，是的，当我跑sar我发现有时它超过60％，大多数情况下它是20％，但有时它达到60％甚至70 ％
我真的不知道如何诊断，我怀疑我的驱动器很慢，这可能会导致延迟，所以我使用dd运行测试，速度为250 mb / s所以我认为传输速度还可以加上硬件应该是全新的。
当我使用gzip或tar提取文件（备份或恢复cpanel帐户）时，通常会发生高负载。
一个重要的事情是top报告说mysql正在使用100％到125％的CPU，有时它会达到更多，如果我跟踪mysql进程我会不断得到这个错误：
setsockopt（376，SOL_IP，IP_TOS，[8]，4）= -1 EOPNOTSUPP（不支持操作）
我不知道这意味着什么，也没有得到有用的信息。
我忘了提到它是一个值得的网络托管服务器，所以它有网络托管的标准设置（apache，php，mysql等）
那么我如何正确诊断这个问题并找到解决方案，或者可能是什么原因？
答案 0 :(得分：1)
正如您现在所知，free -m输出显示7603MiB（~7.6GiB）USED，而不是免费。
你已经内存不足并且已经开始交换，这会大大减慢速度。由于大多数应用程序都不知道虚拟内存现在来自速度慢得多的磁盘，因此系统很可能会“挂起”而没有反馈来描述问题。
从你的描述中，为了重新获得控制权，我kill的第一个过程就是Mysql。如果你有来自另一台机器的ssh / rsh / telnet连接到这个盒子，你可能必须从那里登录才能从kill获得一个可用的命令行。
我对发生的事情的第一个想法（假设？）是......
MySQL正在尝试执行一些不受支持的功能，因为此机器当前已配置。它可能缺少一个库，或者没有设置环境变量或任何数量的东西。
该操作分配了一些内存，但是失败并且没有清理分配。如果这是一个shell脚本，可以通过在开头放置一个事件trap命令来修复它，该命令运行一个释放内存并清理的函数。
编写代码是为了在失败时继续重试，因此会迅速耗尽所有内存。回到shell脚本插图，trap函数也可能会提示您是否确实要继续重试。
不是一个完整的答案，但希望会有所帮助。