Tente adicionar% P (e% D) aos seus arquivos de registro - então você deve ser capaz de correlacionar o que você vê em 'top' com o seu registro de acesso.
Atualmente, estou recebendo alta CPU em um servidor que está executando apenas alguns sites com tráfego muito baixo. Um dos sites está em desenvolvimento ainda em breve. No entanto, este site é muito muito lento ... Ao navegar através de suas páginas, eu posso ver que a CPU vai de 30% a 100% para o httpd (veja a saída superior abaixo).
Eu ajustei o httpd & MySQL, Apache Solr, Tomcat para alto desempenho e estou usando o APC.
Não sei o que fazer a partir daqui ou como encontrar o culpado, pois tenho um monte de mensagens no log do httpd e tenho perseguido becos sem saída há algum tempo ... qualquer ajuda é muito apreciada.
Servidor: AuthenticAMD, Processador AMD Opteron (tm) Quad-Core 2352, RAM 16GB
Linux 2.6.27 64 bits, Centos 5.5
Plesk 9.5.4, MySQL 5.1.48, PHP 5.2.17
Apache / 2.2.3 (CentOS) DAV / 2 mod_jk / 1.2.15 mod_ssl / 2.2.3 OpenSSL / 0.9.8e-fips-rhel5 PHP / 5.2.17 mod_perl / 2.0.4 Perl / v5.8.8
Tomcat6-6.0.29-1.jpp5, Tomcat-native-1.1.20-1.el5, Apache Solr
topo
17595 apache 20 0 1825m 507m 10m R 100.4 3.2 0:17.50 httpd
17596 apache 20 0 1565m 247m 9936 R 83.1 1.5 0:10.86 httpd
17598 apache 20 0 1430m 110m 6472 S 54.5 0.7 0:08.66 httpd
17599 apache 20 0 1438m 124m 12m S 37.2 0.8 0:11.20 httpd
16197 mysql 20 0 13.0g 2.0g 5440 S 9.6 12.6 297:12.79 mysqld
17617 root 20 0 12748 1172 812 R 0.7 0.0 0:00.88 top
8169 tomcat 20 0 4613m 268m 6056 S 0.3 1.7 6:40.56 java
link
[debug] prefork.c(991): AcceptMutex: sysvsem (default: sysvsem)
[info] mod_fcgid: Process manager 17593 started
[debug] proxy_util.c(1854): proxy: grabbed scoreboard slot 0 in child 17594 for worker proxy:reverse
[debug] proxy_util.c(1967): proxy: initialized single connection worker 0 in child 17594 for (*)
[debug] proxy_util.c(1854): proxy: grabbed scoreboard slot 0 in child 17595 for worker proxy:reverse
[debug] proxy_util.c(1873): proxy: worker proxy:reverse already initialized
[notice] child pid 22782 exit signal Segmentation fault (11)
[error] (43)Identifier removed: apr_global_mutex_lock(jk_log_lock) failed
[debug] util_ldap.c(2021): LDAP merging Shared Cache conf: shm=0x7fd29a5478c0 rmm=0x7fd29a547918 for VHOST: example.com
[info] APR LDAP: Built with OpenLDAP LDAP SDK
[info] LDAP: SSL support available
[info] Init: Seeding PRNG with 256 bytes of entropy
[info] Init: Generating temporary RSA private keys (512/1024 bits)
[info] Init: Generating temporary DH parameters (512/1024 bits)
[debug] ssl_scache_shmcb.c(374): shmcb_init allocated 512000 bytes of shared memory
[debug] ssl_scache_shmcb.c(554): entered shmcb_init_memory()
[debug] ssl_scache_shmcb.c(576): for 512000 bytes, recommending 4265 indexes
[debug] ssl_scache_shmcb.c(619): shmcb_init_memory choices follow
[debug] ssl_scache_shmcb.c(621): division_mask = 0x1F
[debug] ssl_scache_shmcb.c(623): division_offset = 96
[debug] ssl_scache_shmcb.c(625): division_size = 15997
[debug] ssl_scache_shmcb.c(627): queue_size = 2136
[debug] ssl_scache_shmcb.c(629): index_num = 133
[debug] ssl_scache_shmcb.c(631): index_offset = 8
[debug] ssl_scache_shmcb.c(633): index_size = 16
[debug] ssl_scache_shmcb.c(635): cache_data_offset = 8
[debug] ssl_scache_shmcb.c(637): cache_data_size = 13853
[debug] ssl_scache_shmcb.c(650): leaving shmcb_init_memory()
Tente adicionar% P (e% D) aos seus arquivos de registro - então você deve ser capaz de correlacionar o que você vê em 'top' com o seu registro de acesso.
[notice] child pid 22782 exit signal Segmentation fault (11)
Algo está definitivamente errado aqui, você deve adicionar ulimit -c unlimited ao início de /etc/init.d/httpd para obter um coredump da próxima vez que falhar com o segfault. Provavelmente o mod_jk é a raiz do problema, pois há um erro relacionado ao mod_jk no log.
Eu vejo mod_perl na lista. Este site é um aplicativo escrito em PERL? Se sim, então o código PERL mal escrito estará na raiz do problema.
O mesmo comentário se aplica ao PHP. Os aplicativos PHP não são conhecidos pelo desempenho e os aplicativos CMS têm uma reputação como hogs de recursos. Se você é um provedor de hospedagem, seria melhor proibir esse pacote CMS ou cobrar uma taxa mais alta para cobrir os recursos extras.
Mas, se você estiver executando este CMS para seu próprio uso, já que ele é opensource, você deve postar outra pergunta no StackOverflow, nomeando o pacote e perguntando como rastrear e corrigir o código mal escrito.
Eu não vi o erro de falha de segmentação novamente, mas ainda estou vendo a alta CPU proveniente do httpd. Consegui executar um strace no processo httpd com a CPU e consegui seguir:
# strace -c -p 28964
Process 28964 attached - interrupt to quit
^CProcess 28964 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
88.94 0.006093 0 98299 4562 lstat
3.01 0.000206 0 2740 getcwd
2.28 0.000156 0 2158 2 read
2.26 0.000155 0 541 37 open
1.68 0.000115 0 1321 1321 readlink
1.52 0.000104 0 1678 822 access
0.32 0.000022 0 502 fstat
0.00 0.000000 0 25 write
0.00 0.000000 0 507 close
0.00 0.000000 0 547 478 stat
0.00 0.000000 0 23 poll
0.00 0.000000 0 2 rt_sigaction
0.00 0.000000 0 2 rt_sigprocmask
0.00 0.000000 0 2 writev
0.00 0.000000 0 3 setitimer
0.00 0.000000 0 1 sendfile
...
------ ----------- ----------- --------- --------- ----------------
100.00 0.006851 108381 7224 total
Os erros 4562 do lstat são do mesmo tipo de erros e aparecem assim no arquivo de log:
# strace -f -t -o /var/log/strace.output -p 28964
strace.output
28964 07:10:38 lstat("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
28964 07:10:38 lstat("/var/www", {st_mode=S_IFDIR|0755, st_size=94, ...}) = 0
28964 07:10:38 lstat("/var/www/vhosts", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
28964 07:10:38 lstat("/var/www/vhosts/example.com", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
28964 07:10:38 lstat("/var/www/vhosts/example.com/httpdocs", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
28964 07:10:38 lstat("/var/www/vhosts/example.com/httpdocs/sites", {st_mode=S_IFDIR|0755, st_size=30, ...}) = 0
28964 07:10:38 lstat("/var/www/vhosts/example.com/httpdocs/sites/all", {st_mode=S_IFDIR|0755, st_size=66, ...}) = 0
28964 07:10:38 lstat("/var/www/vhosts/example.com/httpdocs/sites/all/modules", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
28964 07:10:38 lstat("/var/www/vhosts/example.com/httpdocs/sites/all/modules/views", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
28964 07:10:38 lstat("/var/www/vhosts/example.com/httpdocs/sites/all/modules/views/includes", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
28964 07:10:38 lstat("/var/www/vhosts/example.com/httpdocs/sites/all/modules/views/includes/sites", 0x7fff1e627370) = -1 ENOENT (No such file or directory)
As pastas listadas acima estão todas neste diretório de sites e fazem parte do Drupal CMS. No entanto, o último listado
/var/www/vhosts/example.com/httpdocs/sites/all/modules/views/includes/sites
não existe e deve ser realmente
/var/www/vhosts/example.com/httpdocs/sites
que existe. Parece que o lstat está tentando ler um diretório que não existe ....?
-1 ENOENT (No such file or directory)
Qual seria a melhor maneira de solucionar isso e encontrar a origem desse erro para o diretório ausente?