首先，让我解释一下我为什么要这样做。一切都运行良好。我导入了另一台服务器上的 MySQL DB 快照，准备设置主-主复制（设置完成后，该服务器将成为阵列中的主服务器）。我已启用 MySQL 从属复制，它正在追赶。我还通过 cygwin 进行了 rsync 传输。我忘了一些东西，所以我STOP SLAVE向 MySQL 发出了一个命令。这导致整个服务器完全挂起。ping 没有回复，什么都没有。在这种状态下大约 15 分钟后，该机器被手动硬重启。
这让我不禁怀疑我是否可以信任该服务器。 STOP SLAVE根本不是一个密集的呼叫。我不知道为什么这会导致 MySQL 崩溃，更不用说整个操作系统了。所以现在我想知道这是否是硬件问题。我们刚刚在服务器上安装了全新的 Ram（32gb），但他们从未在其上运行过 memtest。由于我无法物理访问服务器（在另一个国家/地区），他们直到周一早上才会运行 memtest。我想在周末尽可能多地进行测试。
几年前，我在 Linux 中遇到过类似的问题，这是由错误的 BIOS 引起的，在高 I/O 负载下，机器会冻结。为了重现这个问题，我让几个 python 脚本生成一些大文件（10gb 以上），然后在这些文件中随机寻找不同的位置。这导致机器在几分钟内停止运行。
所以我开始思考，为什么不做类似的事情呢？所以我写了一个 Python 程序来读取和写入一系列文件（在 4 个进程中运行），希望能使磁盘饱和。然后我又写了另一个程序，尝试尽可能多地消耗内存（现在为 32gb 并且还在增加），同时随机读取和写入其列表中的位置。它已经运行了大约一个小时，仍然很稳定（交换使速度变慢，但仍然很稳定）。
所以我来这里想问一下，有没有用户空间的压力测试 2k8 的方法，而这些方法实际上并不依赖于应用程序？一旦 MySQL 赶上进度，我就会编写一个脚本来随机查询它，以增加 I/O 和内存使用量。但我更希望测试机器和操作系统，而不是应用程序……但在此之前，我想惩罚这台机器的停机。
谢谢
答案1
答案2
我在这里可能陈述的是显而易见的事实，但是您是否检查过服务器上的事件日志以查看是否有助于确定导致崩溃的具体原因？
我不确定这是否是我的误导性迷信，因为我没有图表来证明这一点，但我注意到大多数时候我看到的服务器问题都是与软件/操作系统相关的错误。