В настоящее время у меня высокая загрузка ЦП на сервере, на котором работает всего пара сайтов с очень низким трафиком. Один из сайтов находится в стадии разработки и скоро будет запущен. Однако этот сайт работает очень-очень медленно ... Просматривая его страницы, я вижу, что загрузка ЦП для httpd изменяется с 30% до 100% (см. Верхний результат ниже).
Я настроил httpd и MySQL, Apache Solr, Tomcat для обеспечения высокой производительности и использую APC.
Не уверен, что делать отсюда или как найти виновника, поскольку у меня есть куча сообщений в журнале httpd, и я уже какое-то время искал тупики ... любая помощь приветствуется.
Сервер: AuthenticAMD, четырехъядерный процессор AMD Opteron (tm) 2352, ОЗУ 16 ГБ
Linux 2.6.27 64-разрядная, 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()
Попробуйте добавить% P (и% D) в файлы журнала - тогда вы сможете сопоставить то, что вы видите в «верху», с журналом доступа.
Я вижу в списке mod_perl. Этот сайт - приложение, написанное на PERL? Если так, то в основе проблемы будет плохо написанный код PERL.
Тот же комментарий относится к PHP. Приложения PHP не отличаются производительностью, а приложения CMS имеют репутацию ресурсоемких приложений. Если вы являетесь хостинг-провайдером, лучше всего либо запретить этот пакет CMS, либо взимать более высокую плату, чтобы покрыть дополнительные ресурсы.
Но если вы используете эту CMS для собственного использования, поскольку она имеет открытый исходный код, вам следует опубликовать еще один вопрос в StackOverflow, назвав пакет и спросив, как отследить и исправить плохо написанный код.
[уведомление] дочерний pid 22782 сигнал выхода Segmentation fault (11)
Здесь точно что-то не так, следует добавить ulimit -c unlimited к началу /etc/init.d/httpd чтобы получить дамп ядра в следующий раз, когда он завершится с ошибкой segfault. Вероятно, в корне проблемы лежит mod_jk, поскольку в журнале есть ошибка, связанная с mod_jk.
Я больше не видел ошибки segmentation fault, но я все еще вижу высокую загрузку процессора, исходящую от httpd. Мне удалось запустить strace в процессе 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)
Как лучше всего решить эту проблему и найти источник этой ошибки для отсутствующего каталога?