我们运行一个vBulletin论坛，每天有6,000名访问者在一个5GB RAM和24个CPU核心的SSD VPS上运行。 在典型的一天，我们在任何时候都会看到30-50个并发用户。 在忙碌的早上，它会上升到130.在这两个时期，该网站是闪电般迅速和响应（忙碌的早晨不影响速度）。 我们喜欢VPS，并优化了我们的许多查询，以保持网站快速运行。
不幸的是，每周2-3次，我们经历了一个突然的负载平均上升，减慢了网站，并使其无法使用3-6分钟。 每当我和我们的主人打开一个支持票，他们就把它归咎于高stream量，但是日志显示交通水平并没有比平常高。 事实上，尖峰通常会在当天晚些时候发生（周二和周四我已经注意到）事情更加安静。 在尖峰期间没有运行cron作业，或从vBulletin预定的任务。
那么他们就把它归咎于可能的开发问题和错误的查询，但是SQL过程列表又一次没有显示出exception，我认为开发问题会导致一致的性能问题，而不仅仅是每周两次。
这是我们的服务器在正常的日子里的样子（现在有40个人在线）
total used free shared buffers cached Mem: 5120 3408 1711 0 0 2466 -/+ buffers/cache: 942 4177 Swap: 0 0 0 最佳
top - 10:56:51 up 8 days, 1:05, 1 user, load average: 0.80, 0.86, 1.00 Tasks: 75 total, 3 running, 72 sleeping, 0 stopped, 0 zombie Cpu(s): 4.7%us, 0.4%sy, 0.0%ni, 94.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 5242880k total, 3532408k used, 1710472k free, 0k buffers Swap: 0k total, 0k used, 0k free, 2538048k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11717 nobody 20 0 57356 23m 6100 S 17.6 0.5 0:00.67 httpd 11609 nobody 20 0 57312 24m 6256 S 6.0 0.5 0:03.81 httpd 11672 nobody 20 0 55324 21m 6064 S 6.0 0.4 0:01.50 httpd 11689 nobody 20 0 55336 21m 6196 S 6.0 0.4 0:01.96 httpd 11675 nobody 20 0 55312 21m 6008 S 5.3 0.4 0:01.86 httpd 11708 nobody 20 0 55056 21m 5796 S 5.3 0.4 0:01.06 httpd 11624 nobody 20 0 55320 21m 6108 S 5.0 0.4 0:04.24 httpd 11669 nobody 20 0 56680 23m 6172 S 5.0 0.4 0:01.91 httpd 11688 nobody 20 0 59336 25m 6048 S 4.7 0.5 0:02.04 httpd 11704 nobody 20 0 62324 28m 5752 S 4.7 0.6 0:01.93 httpd 11674 nobody 20 0 55144 21m 5680 S 4.3 0.4 0:01.72 httpd 11715 nobody 20 0 56860 22m 5496 S 4.3 0.4 0:00.41 httpd 11489 nobody 20 0 57384 23m 6308 S 4.0 0.5 0:05.46 httpd 11492 nobody 20 0 56516 23m 6256 S 4.0 0.4 0:05.66 httpd 11631 nobody 20 0 55028 21m 5940 S 4.0 0.4 0:02.59 httpd 11645 nobody 20 0 57924 24m 6108 S 4.0 0.5 0:02.84 httpd 11666 nobody 20 0 55564 21m 5924 S 4.0 0.4 0:02.09 httpd 11633 nobody 20 0 55568 21m 5944 S 3.7 0.4 0:02.17 httpd 11691 nobody 20 0 59444 25m 6000 S 3.7 0.5 0:02.03 httpd 15004 mysql 15 -5 1260m 455m 4896 S 3.7 8.9 598:25.20 mysqld 11630 nobody 20 0 57096 23m 6272 S 3.3 0.5 0:03.72 httpd 11670 nobody 20 0 55032 20m 5844 S 3.3 0.4 0:01.57 httpd 11685 nobody 20 0 55064 21m 6028 S 3.3 0.4 0:01.89 httpd 11614 nobody 20 0 0 0 0 Z 0.3 0.0 0:03.68 httpd <defunct> 11682 nobody 20 0 55064 21m 6004 S 0.3 0.4 0:02.08 httpd 1 root 20 0 2900 980 800 S 0.0 0.0 0:00.25 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd/11679 3 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khelper/11679 134 root 16 -4 2464 624 332 S 0.0 0.0 0:00.00 udevd 568 root 20 0 37000 2088 792 S 0.0 0.0 0:03.94 rsyslogd 581 named 20 0 331m 41m 2112 S 0.0 0.8 6:17.95 named 677 root 20 0 8944 988 476 S 0.0 0.0 0:00.02 sshd 684 root 20 0 3264 744 564 S 0.0 0.0 0:00.00 xinetd 1526 root 20 0 3100 1064 828 S 0.0 0.0 0:02.67 dovecot 1529 dovenull 20 0 7092 2648 2076 S 0.0 0.1 0:00.04 pop3-login 1530 dovenull 20 0 7232 3040 2364 S 0.0 0.1 0:00.67 imap-login 1531 dovecot 20 0 2956 1012 872 S 0.0 0.0 0:01.03 anvil 1532 root 20 0 3084 1196 896 S 0.0 0.0 0:00.93 log 1535 root 20 0 3764 1800 1024 S 0.0 0.0 0:02.52 config 1537 dovenull 20 0 7244 2996 2336 S 0.0 0.1 0:00.18 pop3-login 1541 dovenull 20 0 7392 3112 2344 S 0.0 0.1 0:01.57 imap-login 1561 root 20 0 2988 520 372 S 0.0 0.0 0:00.00 atd 2152 root 20 0 12476 6792 2492 S 0.0 0.1 0:00.09 leechprotect 4916 root 20 0 13820 8048 1332 S 0.0 0.2 0:08.36 lfd - sleeping 11340 nobody 20 0 63296 29m 6352 S 0.0 0.6 0:07.12 httpd
正如你所看到的，平均负载是相当健康的。 一直保持在1-7％左右，从不高于这个水平（峰值期间除外）。
这是在穗期间的顶部。 正如你所看到的，睡眠任务的数量是我们通常看到的数量的两倍多。 目前有30人在线。
top - 17:32:38 up 2 days, 7:41, 1 user, load average: 33.61, 11.77, 5.56 Tasks: 168 total, 3 running, 163 sleeping, 0 stopped, 2 zombie Cpu(s): 5.3%us, 0.3%sy, 0.0%ni, 94.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 5242880k total, 5081012k used, 161868k free, 0k buffers Swap: 0k total, 0k used, 0k free, 3327124k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3838 nobody 20 0 59124 22m 5984 S 14.6 0.4 0:01.01 httpd 3861 nobody 20 0 59120 21m 5744 S 10.6 0.4 0:00.60 httpd 3799 nobody 20 0 59140 22m 6028 S 8.6 0.4 0:00.75 httpd 3840 nobody 20 0 58852 21m 5972 S 7.3 0.4 0:00.88 httpd 15004 mysql 15 -5 1247m 362m 5224 S 7.0 7.1 154:57.98 mysqld 3800 nobody 20 0 60580 23m 5988 S 6.0 0.5 0:01.23 httpd 3854 nobody 20 0 58920 21m 5840 R 6.0 0.4 0:00.68 httpd 3878 nobody 20 0 58824 21m 5852 S 5.3 0.4 0:00.91 httpd 3779 nobody 20 0 59108 22m 6004 S 4.7 0.4 0:02.62 httpd 3844 nobody 20 0 58828 21m 5816 S 4.7 0.4 0:00.65 httpd 3855 nobody 20 0 58868 21m 5872 S 4.7 0.4 0:00.63 httpd 3867 nobody 20 0 61600 24m 5968 S 4.7 0.5 0:01.07 httpd 3892 nobody 20 0 59080 21m 5620 S 4.7 0.4 0:01.00 httpd 3901 nobody 20 0 59196 22m 5760 S 4.7 0.4 0:01.07 httpd 3862 nobody 20 0 58824 21m 5600 S 4.3 0.4 0:00.97 httpd 3683 nobody 20 0 60400 23m 5940 R 4.0 0.4 0:01.50 httpd 3560 nobody 20 0 61712 24m 6140 S 3.7 0.5 0:06.92 httpd 3793 nobody 20 0 58848 21m 5988 S 3.7 0.4 0:00.74 httpd 3837 nobody 20 0 59352 21m 5816 S 3.7 0.4 0:00.54 httpd 3856 nobody 20 0 59352 21m 5632 S 3.7 0.4 0:00.94 httpd 3768 nobody 20 0 61172 23m 6000 S 3.3 0.5 0:02.02 httpd 3772 nobody 20 0 58880 21m 6020 S 3.3 0.4 0:02.57 httpd 3826 nobody 20 0 58856 21m 5568 S 3.3 0.4 0:00.75 httpd 3850 nobody 20 0 60356 23m 6156 S 3.3 0.5 0:00.96 httpd 3841 nobody 20 0 58824 21m 5676 S 3.0 0.4 0:01.15 httpd 3784 nobody 20 0 58848 21m 6008 S 0.7 0.4 0:01.61 httpd 1545 root 20 0 52776 16m 6564 S 0.3 0.3 1:54.88 httpd 3572 nobody 20 0 0 0 0 Z 0.3 0.0 0:07.76 httpd <defunct> 3807 nobody 20 0 59104 21m 5844 S 0.3 0.4 0:00.81 httpd 3820 nobody 20 0 59160 21m 5756 S 0.3 0.4 0:00.76 httpd 3868 nobody 20 0 58892 21m 5632 S 0.3 0.4 0:00.79 httpd 3884 nobody 20 0 58824 21m 5792 S 0.3 0.4 0:00.22 httpd 1 root 20 0 2900 988 808 S 0.0 0.0 0:00.10 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd/11679 3 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khelper/11679 134 root 16 -4 2464 500 260 S 0.0 0.0 0:00.00 udevd 568 root 20 0 37000 1304 776 S 0.0 0.0 0:00.87 rsyslogd 581 named 20 0 329m 39m 2164 S 0.0 0.8 1:52.02 named 677 root 20 0 8944 988 476 S 0.0 0.0 0:00.00 sshd 684 root 20 0 3264 744 564 S 0.0 0.0 0:00.00 xinetd 1526 root 20 0 3100 1064 828 S 0.0 0.0 0:00.73 dovecot 1529 dovenull 20 0 7092 2660 2088 S 0.0 0.1 0:00.02 pop3-login 1530 dovenull 20 0 7232 2956 2344 S 0.0 0.1 0:00.21 imap-login 1531 dovecot 20 0 2956 1012 872 S 0.0 0.0 0:00.27 anvil 1532 root 20 0 3084 1160 896 S 0.0 0.0 0:00.26 log
我的主机调查，并最终承认这个具体的实例是由于我的节点中的另一个VPS造成的问题，但否认任何其他高峰与这个问题有关。 两天后又发生了这种事情，他们把这个事情归咎于Apache MaxClients，这在技术上是正确的，但我的观点是，我们从来不应该把它放在第一位。 同样，网上只有30人（而且服务器在同一天早些时候在线处理了130人，绝对没有问题）。 我的怀疑是io问题导致所有这些任务排队等待，所以队列变得越来越长，最终违反了MaxClients并增加了平均负载。
如果确实如此，我不想提出我的MaxClients，因为服务器问题不应该在第一时间发生。 在正常的日子里，我们永远不会靠近MaxClients。 当然，如果我的平均负载平均徘徊在90％左右，那么我会愿意把交通问题的责任归咎于高峰。 但是我的负载平均值总是在1-7％之间，在峰值期间从来没有交通峰值。 100％的每日双峰会没有任何意义。
我在被录取的io问题期间检查了sar，并且我没有看到任何表示io问题的东西，所以下次发生这种情况时我不知道如何检查io问题：
04:40:01 PM CPU %user %nice %system %iowait %steal %idle 04:50:01 PM all 8.60 0.00 0.55 0.00 0.36 90.48 05:00:01 PM all 8.18 0.00 0.54 0.02 0.20 91.06 05:10:01 PM all 8.44 0.14 0.55 0.05 0.17 90.65 05:20:01 PM all 8.28 0.00 0.53 0.01 0.15 91.02 05:30:01 PM all 7.02 0.00 0.47 0.00 0.11 92.40
在我的最高时间（17:32 / 5:32 PM），平均30+的平均值，爱荷华州为0.00。 他们如何确定这是一个io问题？ 我怎样才能在未来自己确定呢？
所以，最后，我有两个问题：
这些症状表明是否有任何具体问题可以解释发生了什么事情？
你能build议任何监控工具，这将帮助我找出问题，并certificate根本原因？
谢谢！