在生成一些报告的每一天，mysql进程占用1或2个内核（100％）。 问题是整个服务器在那个时候变得没有反应。 我不能ssh，postfix不起作用，apache也不行。 我可以ping服务器。 Cronjobs也可以工作，所以我现在每隔一分钟就把顶端的输出保存到一个文件中。
有更多的内核可用，内存使用率不高，所以我不知道为什么会发生这种情况。 关于报告的应用程序我可以做的不多，但是我发现很奇怪，一旦mysql超载，其他所有事情都停止。 平均负荷达到1.5左右。 一切都结束后，事情开始正常。 有什么我可以做的吗？
带有内核3.13的Ubuntu 12.04在物理服务器上。
top - 21:51:02 up 82 days, 13:57, 8 users, load average: 1.19, 1.21, 1.15 Tasks: 367 total, 1 running, 364 sleeping, 0 stopped, 2 zombie Cpu(s): 1.2%us, 0.9%sy, 1.4%ni, 95.7%id, 0.8%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 16274920k total, 13190728k used, 3084192k free, 284272k buffers Swap: 4095996k total, 1006148k used, 3089848k free, 4570996k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20794 mysql 20 0 3904m 893m 5260 S 100 5.6 2810:00 mysqld 19807 otrs 20 0 211m 46m 5560 S 75 0.3 0:00.39 otrs.PostMaster 14 root 20 0 0 0 0 S 2 0.0 20:49.52 rcuos/6 安装一些适当的监控，并使用它来收集有关系统在正常和负载情况下如何执行的信息。 使用监视来查看哪些资源被消耗。 根据你发现的事实采取适当的行动。
阅读您的日志，他们的条目有时间戳，检查运行报告时是否logging了任何相关的内容。
学会使用科学的方法或类似的方式，而不是猜测或期待互联网猜测 。
我会在这里推荐的一个注意事项是你提到你每隔一分钟就将顶部输出保存到一个文件中。 为什么不使用atop？ 如果你愿意的话，你可以在上面configurationlogging每秒的活动（注意这将占用大量的磁盘使用）。 然后，您可以稍后使用atop -r 日志文件查看以前生成的日志 。 这会给你一个更好的想法。 Atop有一个伟大的人的页面，所以只是通读，你可以很容易地看你的服务器，并获得更好的资源使用的想法。
另外要注意的是，我们几乎不可能真的帮你解决这个问题。 MySQL问题可能与configuration问题有关，但也可能与数据库本身有关。 如果你有很多碎片表，它可以减缓某些过程中的事情。 有很多事情可能会导致你的MySQL实例问题，这会减慢速度。
如果您不熟悉MySQL，我会build议您下载并使用mysqltuner.pl 。 一个简单的perl脚本，用于获取您的MySQL实例的基本概述，您可以通过该实例查看并进一步进行故障排除。
不要把mysqltuner.pl输出为宗教
我的意思是，不要只是做它所说的一切。 用它来更好地了解正在发生的事情，并帮助您的谷歌进一步。