normalmente é o arquivo .htaccess que re-injetou um URI de solicitação alterado, verifica isso e você também pode redefinir seus arquivos de configuração
meu site foi atrasado alguns dias atrás ... algumas imagens não aparecem ... recebi
408 Request Time-out: Server timeout waiting for the HTTP request from the client
Algumas vezes nunca aconteceu antes.
eu fiz uma pequena verificação de desempenho, basicamente o comando top no ssh
este é o resultado
como você pode ver, o uso de memória é muito alto ... ou eu acho que é.
Eu reiniciei o servidor ... ele caiu mas depois de um tempo ele sobe de novo .... (isso é cerca de uma hora após a reinicialização)
após meia hora = >
top - 16:14:22 up 1:56, 2 users, load average: 0.62, 0.90, 1.15
Tasks: 303 total, 1 running, 302 sleeping, 0 stopped, 0 zombie
Cpu(s): 8.0%us, 0.2%sy, 0.0%ni, 91.4%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 32840004k total, 21037648k used, 11802356k free, 430832k buffers
Swap: 1050616k total, 0k used, 1050616k free, 16527108k cached
agora mesmo
[root@ns4008353 ~]# top
top - 16:33:25 up 2:15, 2 users, load average: 0.88, 0.94, 0.98
Tasks: 303 total, 3 running, 300 sleeping, 0 stopped, 0 zombie
Cpu(s): 6.8%us, 0.2%sy, 0.0%ni, 92.8%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 32840004k total, 22388160k used, 10451844k free, 434964k buffers
Swap: 1050616k total, 0k used, 1050616k free, 17324104k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7532 mysql 20 0 3750m 492m 5556 S 18.0 1.5 49:53.58 mysqld
12903 apache 20 0 232m 40m 4864 S 16.3 0.1 0:56.74 httpd
7748 apache 20 0 235m 43m 5256 S 11.6 0.1 1:33.36 httpd
8010 apache 20 0 262m 70m 4856 R 6.7 0.2 1:32.05 httpd
7747 apache 20 0 235m 43m 5220 S 1.3 0.1 1:06.37 httpd
7749 apache 20 0 222m 30m 5164 S 1.3 0.1 1:58.53 httpd
7996 apache 20 0 250m 59m 5476 S 1.3 0.2 1:37.37 httpd
10 root 20 0 0 0 0 S 0.3 0.0 0:09.72 rcu_sched
7714 apache 20 0 265m 73m 4972 S 0.3 0.2 1:34.53 httpd
7905 named 20 0 669m 24m 3020 S 0.3 0.1 0:02.01 named
7999 apache 20 0 232m 40m 4968 S 0.3 0.1 1:17.67 httpd
20865 root 20 0 0 0 0 S 0.3 0.0 0:01.05 kworker/2:2
21491 root 20 0 15212 1308 852 S 0.3 0.0 0:01.38 top
23810 root 20 0 15212 1340 852 R 0.3 0.0 0:00.07 top
1 root 20 0 19404 1568 1268 S 0.0 0.0 0:00.58 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
livre m
[root@ns4008353 ~]# free -m
total used free shared buffers cached
Mem: 32070 21897 10173 0 424 16955
-/+ buffers/cache: 4516 27553
Swap: 1025 0 1025
você acha que esta é a razão da resposta lenta? Existe algum comentário para obter mais informações sobre o que está usando a memória?
eu tenho um servidor dedicado:
Processor Name Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz
Vendor ID GenuineIntel
Processor Speed (MHz) 1600.000
Total Memory 32840004 kB
Free Memory 10416752 kB
Total Swap Memory 1050616 kB
Free Swap Memory 1050616 kB
System Uptime 0 Days, 2 Hours and 22 Minutes
Apache 2.2.24 Running
DirectAdmin 1.43.0 Running
Exim 4.76 Running
MySQL 5.5.31 Running
Named 9.8.2rc1 Running
ProFTPd 1.3.4d Running
sshd Running
dovecot 2.2.4 Running
depois de procurar nos meus arquivos de log, vi muitos erros
[Sat Sep 28 00:15:41 2013] [error] [client 66.249.73.162] Request exceeded the limit of 10 internal redirects due to probable co
nfiguration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace
A descrição do seu problema são solicitações HTTP lentas, mas, como você mostrou, a CPU e a memória não estão esgotadas. Então, algumas coisas para verificar:
LogFormat "% h% l% u% t \"% r \ "% > s% b" comum
E adicione% D depois de% b (mas dentro da cotação final). Consulte o link
Em seguida, recarregue / reinicie o httpd e seu arquivo access_log agora deve mostrar o tempo que cada resposta demora em microssegundos na última coluna. Confirme que estes são lentos. Talvez apenas alguns tipos de solicitações sejam lentos? Eu noto que o MySQL está usando alguma CPU, então talvez um tipo de requisição esteja acertando uma consulta de banco de dados lenta?
Se as respostas acima forem lentas e não houver um padrão óbvio (por exemplo, páginas específicas), será necessário determinar onde elas estão lentas. O% D time inclui tudo, desde ler o pedido do cliente, servir o arquivo (que inclui qualquer código de aplicativo ou consultas de banco de dados) e escrever a resposta, apenas informando que há uma lentidão, não necessariamente onde. Então agora você precisa isolar onde está a desaceleração. Eu primeiro verificaria o aplicativo. Verifique também o log lento do MySQL (ative-o se ele não estiver ativado).
Verifique seu error_log - talvez haja alguns tempos limite de aplicativos ou outros erros.
Se você não estiver tendo sorte, também poderá executar pstack ${PID} periodicamente para tentar entender o que o httpd está fazendo.
Finalmente, você pode usar o tcpdump e algo como o Wireshark para isolar onde a lentidão é, embora isso seja um pouco entediante. Acho que há também um módulo httpd que divide o tempo em uma solicitação, mas não consigo encontrá-lo agora e não o vejo na lista de módulos internos.
O seu uso de memória não é alto, você deve pular essa parte da solução de problemas e tentar o que o Inforfinity sugeriu.
O kernel do Linux tende a ocupar a memória não utilizada disponível para o cache de disco. Isso torna o sistema mais rápido. Se algum aplicativo precisar de memória, ele pegará isso do próprio cache. Então basicamente você não está com pouca memória. Considere a saída de free -m
- / + buffers / cache: 4516 27553
4516MB de RAM real está sendo usada, 27553 é a memória livre real. Perto de 17G é armazenado em cache.
Tente fazer testes de desempenho no seu servidor da web. Use httperf para benchmark.
link