Executamos um fórum de vBulletin com 6.000 visitantes por dia em um SSD VPS com 5 GB de RAM e 24 núcleos de CPU. Em um dia típico, vemos 30 a 50 usuários simultâneos em qualquer momento. Nas manhãs ocupadas, vai até 130. Durante ambos os tempos, o site é muito rápido & responsivo (manhãs ocupadas não causam impacto na velocidade). Nós amamos o VPS e otimizamos muitas de nossas consultas para manter o site funcionando rapidamente.
Infelizmente, 2 a 3 vezes por semana, experimentamos um pico de carga súbita que desacelera o site e o inutiliza por 3 a 6 minutos. Toda vez que eu abro um ticket de suporte com nosso host, eles culpam o tráfego alto, mas os logs mostram que os níveis de tráfego não são mais altos do que o normal. Na verdade, os picos geralmente acontecem no final do dia (notei às terças e quintas) quando as coisas estão muito mais silenciosas. Nenhuma tarefa do cron em execução durante os picos ou tarefas agendadas do vBulletin.
Então, eles culpam possíveis problemas de desenvolvimento & consultas ruins, mas, novamente, a lista de processos SQL não mostra nada incomum, e eu acho que os problemas de desenvolvimento levariam a problemas de desempenho consistentes, e não apenas um pico duas vezes por semana.
Veja como é o nosso servidor em um dia normal (40 pessoas on-line agora)
total used free shared buffers cached
Mem: 5120 3408 1711 0 0 2466
-/+ buffers/cache: 942 4177
Swap: 0 0 0
Top
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
Como você pode ver, a média de carga é bastante saudável. Consistentemente em torno de 1-7%, e nunca acima disso (exceto durante os picos).
Aqui está um top durante o pico. Como você pode ver, o número de tarefas para dormir é mais que o dobro do que normalmente vemos. 30 pessoas estavam on-line no momento.
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
Meu host investigou e finalmente admitiu que essa instância específica estava relacionada a problemas causados por outro VPS no meu nó, mas negou qualquer outro problema relacionado a esse problema. Isso aconteceu novamente dois dias depois e eles culparam o Apache MaxClients, o que foi tecnicamente verdadeiro, mas o que eu quero dizer é que nunca deveríamos ter chegado a ele em primeiro lugar. Mais uma vez, havia apenas 30 pessoas on-line (eo servidor lidou com 130 pessoas on-line mais cedo naquela mesma manhã com absolutamente nenhum problema). Minha suspeita é que o problema do io faz com que todas essas tarefas façam fila e esperem, então a fila fica mais longa & mais, eventualmente violando MaxClients e aumentando a média de carga.
Se esse for realmente o caso, não quero aumentar meus MaxClients devido a um problema no servidor que não deveria estar acontecendo em primeiro lugar. Nós nunca estamos perto de nossos MaxClients em um dia normal. Claro, se a minha média de carga estivesse em torno de 90%, estaria disposto a culpar os problemas de tráfego. Mas minha média de carga é sempre de 1 a 7% e nunca há picos de tráfego durante o pico. Um pico bi-diário acima de 100% não faz qualquer sentido.
Verifiquei o sar durante os problemas de io admitidos, e não vejo nada que indique problemas de io, por isso não sei como verificar problemas de io na próxima vez que isso ocorrer:
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
Na época do meu início (17:32 / 5:32 PM) com média de carga de 30+, o iowait era de 0,00. Como eles determinaram isso como um problema de io? E como posso determinar isso sozinho no futuro?
Então, em conclusão, tenho duas perguntas:
Esses sintomas indicam problemas específicos que explicariam o que está acontecendo?
Você pode sugerir alguma ferramenta de monitoramento que me ajude a identificar o problema e provar a causa raiz?
Obrigado!