Следует обратиться к access.log — URL и коды ответа от backend фиксируются там. В виртуальной машине Битрикс он может быть отключен. Чтобы его включить, в файле /etc/nginx/nginx.conf необходимо закомментировать следующую строку:
Действительно access.log был выключен, включил в конфиге.
Запустил скрипт из поста #20, получил в error.log Segmentation fault (11) и в access.log код 502. После этого дождался очередной ошибки Segmentation fault (11), но в access.log 502 кода не было, да и вообще ошибок нет.
Может что access.log момент падения апача не был записан ? Есть какой нибудь удобный анализатор логов под Windows?
1) Поиск в логе производится по коду 502, а записывается другой код (500, 503).
2) Процессы Apache периодически падают сам по себе, без запроса. Тогда это проблема, не связанная с той, что описана в комментарии #17. Мне этот вариант видится крайне маловероятным.
3) В конфигурационных файлах Nginx есть еще одна директива access_log off (или /dev/null), которая переопределяет общую (ту что в nginx.conf) для каких-то location. Что выдает команда:
Код
grep -Ri access_log /etc/nginx
Во всех остальных случаях соответствующая запись должна быть зафиксирована в логе.
Анализатор логов под Windows, боюсь, подсказать не смогу. Очень давно не работал с этой ОС.
Иван пишет: 1) Поиск в логе производится по коду 502, а записывается другой код (500, 503).
Проверил ёщё раз 5хх ошибок не генерируется
Цитата
Иван пишет: 3) В конфигурационных файлах Nginx есть еще одна директива access_log off (или /dev/null), которая переопределяет общую (ту что в nginx.conf) для каких-то location. Что выдает команда:
То есть, если обратиться к скрипту из комментария #20, то запись в access.log Nginx есть? При этом, в логе ошибок Apache существуют записи о Segmentation fault, для которых в access.log Nginx соответствий нет?
Если все так, то остаются лишь два случая:
1) Существуют ситуации, когда запросы уходят напрямую в Apache, минуя Nginx. Такие обращения может создавать система мониторинга (например, Nagios), или, если Apache и iptables настроены соответствующим образом, запросы могут приходить извне на другой порт.
2) Сомнительный вариант 2 из списка выше. Который, в свете имеющихся данных, перестает казаться таким уж сомнительным.
Что касается указанного участка конфигурационного файла Nginx — он нужен для построения графиков сервисом munin. Как видно из приведенных настроек, обращение к Apache в этом случае не происходит, потому, его можно не рассматривать. Лог access1.log пустой, так как сервис munin, вероятнее всего, отключен.
Система - OpenVZ контейнер с установленным внутри минимальным CentOS release 6.5 (Final) Поверх накатил Bitrix virtual appliance version 4.3.2 Для изучения возможностей крутится демо-версия корп-портала.
Захожу на него нечасто, но иногда попадаю на ошибку
Как подсказывает мне моя практика проблема скорее всего в прекомпиляторе APC. Чтобы выяснить наверняка, выключите его: В файле /etc/php.d/apc.ini закомментируйте строку extension = apc.so и перезапустите апач: service httpd restart
Если все ок, то в выводе команды php -m не должно фигурировать модуля apc И понаблюдайте. Если падать перестанет - 100% дело в нем) Правда с отключенным apc сайт будет гораздо дольше откликаться. Но прекомпилятор можно будет заменить на какой-либо другой (например, XCache, memcached и т.д.).
Так же можно попробовать в файле /etc/httpd/bx/conf/prefork.conf уменьшить значение MaxRequestsPerChild раза в 2-3 Оно отвечает за количество запросов, которые каждый из форков апача выполнит, прежде чем будет закрыт и создан новый (защита от утечек памяти) Чаще будут закрываться - больше шанс, что он не успеет зависнуть из-за apc =) Правда при малой процессорной мощности и большой посещаемости сайта слишком малые значения вызовут значительное повышение нагрузки на CPU. И да, после правки этого файла тоже не забудьте перезапустить httpd.
У нас один в один та же проблема - только не apc глючил, а opcache встроенный в 5.5 Заменили на xcache, думали, что проблема решена, но падения продолжились, только стали реже.
Аналогичная ситуация. Только вот у меня после обновления с 12 ноября полезли ошибки в апач:
[Wed Nov 12 09:51:32 2014] [notice] child pid 51202 exit signal Segmentation fault (11) [Wed Nov 12 10:08:44 2014] [notice] child pid 51164 exit signal Segmentation fault (11) [Wed Nov 12 10:09:31 2014] [notice] child pid 50558 exit signal Segmentation fault (11)
И так до бесконечности. Пытался обратиться в тех.поддержку.
Цитата
Вчера обновили Корпоративный портал до версии 14.9.4. Сразу же втечение дня стали появляться постоянные "подвисания" Логи http сразу же после обновления стали заваливаться следующими записями: [Wed Nov 12 09:51:32 2014] [notice] child pid 51202 exit signal Segmentation fault (11) [Wed Nov 12 10:08:44 2014] [notice] child pid 51164 exit signal Segmentation fault (11) [Wed Nov 12 10:09:31 2014] [notice] child pid 50558 exit signal Segmentation fault (11)
Сегодня портал подвис вообще на 2 минуты, http вернул в логе следующее: [Thu Nov 13 11:52:37 2014] [error] server reached MaxClients setting, consider raising the MaxClients setting Далее анализируем через отладчик gdb веб сервер http В итоге получаем креш вот в этом месте: Reading symbols from /lib64/libgthread-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /lib64/libgthread-2.0.so.0 Reading symbols from /usr/lib64/php/modules/wddx.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/php/modules/wddx.so Reading symbols from /usr/lib64/php/modules/zip.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/php/modules/zip.so Core was generated by `/usr/sbin/httpd'. Program terminated with signal 11, Segmentation fault. #0 0x00007fac36ed6db4 in ?? () from /etc/httpd/modules/libphp5.so Missing separate debuginfos, use: debuginfo-install httpd-2.2.15-30.el6.centos.x86_64 Как видим проблема с модулем php - libphp5.so Как обновление портала могло повлиять на php модуль и как эту проблему можно устранить? Обновление произвели в 12.11.2014 09:44:37, а ошибки полезли через пару минут, в 9:51 На сервере и момент установки ничего не обновлялось - последние записи yum.log с установкой датированы июлем. Не корректных отключений не было, uptime сервера 113 дней. В качестве платформы испльзуется Bitrix virtual appliance version 5.0.44.
Получил замечательный ответ, что надо обновить веб-окружение. Только вот не хочется таким "сомнительным" обновлением обновляться, чтоб остатки не доломать. Веселая идея в том, как могло обновления портала повлиять на php модуль? Ребят, так никто и не поборол проблему? Очень актуально
Похожая проблема - внезапно стал падать сайт (только один из всех на сервере) на вызове функции mail и только в том случае если перед вызовом подключено ядро битрикса. Если просто вызвать mail - то все работает. Падает все - и php-fpm и cgi и libphp5
bt Core was generated by `php-fpm: pool best '.
Program terminated with signal 11, Segmentation fault.
#0 0x00007ffb29b07580 in strcat () from /lib64/libc.so.6
return_value_used=<value optimized out> [Шутливо] at /usr/src/debug/php-5.3.3/ext/standard/mail.c:178
#3 0x00000000005f3bf8 in zend_do_fcall_common_helper_SPEC (execute_data=<value optimized out> [Шутливо] at /usr/src/debug/php-5.3.3/Zend/zend_vm_execute.h:316
#4 0x00000000005cad40 in execute (op_array=0x321f8e0) at /usr/src/debug/php-5.3.3/Zend/zend_vm_execute.h:107
#5 0x00000000005a4f5d in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/debug/php-5.3.3/Zend/zend.c:1235
#6 0x0000000000552fe8 in php_execute_script (primary_file=0x7fff02eb3b40) at /usr/src/debug/php-5.3.3/main/main.c:2268
#7 0x00000000006374c8 in main (argc=<value optimized out>, argv=<value optimized out> [Шутливо] at /usr/src/debug/php-5.3.3/sapi/fpm/fpm/fpm_main.c:1925