Высокая загрузка ЦП из процесса httpd

В настоящее время у меня высокая загрузка ЦП на сервере, на котором запущено несколько сайтов с очень низким трафиком. Один из сайтов находится в стадии разработки. Тем не менее, этот сайт очень очень медленный... При просмотре его страниц я вижу, что процессор загружается с 30% до 100% для httpd (см. Верхний вывод ниже).

Я настроил httpd & MySQL, Apache Solr, Tomcat для высокой производительности, и я использую APC.

Не уверен, что делать отсюда или как найти виновника, так как у меня есть куча сообщений в журнале httpd, и я давно гнался в тупик... любая помощь очень ценится.

Сервер: AuthenticAMD, четырехъядерный процессор AMD Opteron(tm) 2352, ОЗУ 16 ГБ

Linux 2.6.27 64-bit, 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

Топ

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

httpd error_log

[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()

4 ответа

Попробуйте добавить%P (и%D) к вашим файлам журналов - тогда вы сможете соотнести то, что вы видите в верхней части, с вашим журналом доступа.

Я вижу mod_perl в списке. Является ли этот сайт приложением, написанным на PERL? Если это так, то корень проблемы - плохо написанный PERL-код.

Тот же комментарий относится и к PHP. Приложения PHP не известны своей производительностью, а приложения CMS имеют репутацию боровов с ресурсами. Если вы являетесь хостинг-провайдером, было бы лучше либо запретить этот пакет CMS, либо взимать более высокую ставку для покрытия дополнительных ресурсов.

Но, если вы используете эту CMS для своего собственного использования, так как она с открытым исходным кодом, вы должны опубликовать еще один вопрос в StackOverflow, назвав пакет и спросив, как отследить и исправить плохо написанный код.

[примечание] дочерний пид 22782 выходной сигнал Ошибка сегментации (11)

Что-то здесь определенно не так, вы должны добавить ulimit -c unlimited к началу /etc/init.d/httpd чтобы получить coredump в следующий раз, если он потерпит неудачу с segfault. Возможно, mod_jk является корнем проблемы, поскольку в журнале есть ошибка, связанная с mod_jk.

Я не видел ошибку ошибки сегментации снова, но я все еще вижу высокую загрузку ЦП из httpd. Я смог запустить процесс httpd с процессором и получил следующее:

   # 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

Ошибки 4562 от lstat относятся к типу ошибок того же типа и отображаются следующим образом в файле журнала:

# 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)

Все перечисленные выше папки находятся в этом каталоге веб-сайта и являются частью Drupal CMS. Однако последний из перечисленных

/var/www/vhosts/example.com/httpdocs/sites/all/modules/views/includes/sites 

не существует, и это действительно должно быть

/var/www/vhosts/example.com/httpdocs/sites

который существует. Похоже, lstat пытается прочитать каталог, который не существует....?

-1 ENOENT (No such file or directory)

Каков наилучший способ устранить эту проблему и найти источник этой ошибки для отсутствующего каталога?

Другие вопросы по тегам