Как избавиться от SIGBUS при работе php-fpm?

Question

[multifinger]

Поднял веб-сервер с nginx + php-fpm + symfony1.4, работают скрипты использующие MySQL, APC, Memcached



Тестирую сервер под нагрузкой в течении длительного времени, смотрю логи:

Jun 22 17:54:13.793226 [WARNING] [pool www] child 27950 exited on signal 7 SIGBUS after 82.113882 seconds from start
Jun 22 17:54:13.793555 [NOTICE] [pool www] child 27978 started
Jun 22 17:57:05.123482 [WARNING] [pool www] child 27978 exited on signal 7 SIGBUS after 171.329932 seconds from start
Jun 22 17:57:05.123796 [NOTICE] [pool www] child 28069 started
Jun 22 17:59:56.901823 [WARNING] [pool www] child 28070 exited on signal 7 SIGBUS after 169.362491 seconds from start
Jun 22 17:59:56.902103 [NOTICE] [pool www] child 28105 started
Jun 22 18:03:03.044205 [WARNING] [pool www] child 28206 exited on signal 7 SIGBUS after 91.774054 seconds from start
Jun 22 18:03:03.044678 [NOTICE] [pool www] child 28226 started
Jun 22 18:03:57.233633 [WARNING] [pool www] child 28228 exited on signal 7 SIGBUS after 39.234232 seconds from start
Jun 22 18:03:57.233907 [NOTICE] [pool www] child 28235 started
Jun 22 18:04:30.170006 [WARNING] [pool www] child 28235 exited on signal 7 SIGBUS after 32.936104 seconds from start
Jun 22 18:04:30.170279 [NOTICE] [pool www] child 28253 started
Jun 22 18:05:25.752235 [WARNING] [pool www] child 28264 exited on signal 7 SIGBUS after 40.075326 seconds from start
Jun 22 18:05:25.752519 [NOTICE] [pool www] child 28339 started
Jun 22 18:07:55.575072 [WARNING] [pool www] child 28358 exited on signal 7 SIGBUS after 52.005688 seconds from start
Jun 22 18:07:55.575345 [NOTICE] [pool www] child 28365 started
Jun 22 18:09:17.171426 [WARNING] [pool www] child 28376 exited on signal 7 SIGBUS after 43.982024 seconds from start
Jun 22 18:09:17.171846 [NOTICE] [pool www] child 28403 started

Иногда веб-сервер по непонятным причинам вообще подвисает…

Помогите разобраться, если кто сталкивался.



Всю необходимую информацию, логи и т.п. предоставлю

Comments

[gaelpa]

Просьба, если найдете в чем была проблема, или хотя бы сможете её обойти, отписаться в вопросе «по результатам».

[multifinger]

Актуальная проблема? Конечно отпишусь!

[gaelpa]

Слава богу пока нет, но ведем миграцию на fpm — не хотелось бы нарваться.

[multifinger]

UPD:
root@ws542 ~ # uname -a Linux ws542 2.6.32-39-server #86-Ubuntu SMP Mon Feb 13 23:15:11 UTC 2012 x86_64 GNU/Linux root@ws542 ~ # php -v PHP 5.3.2-1ubuntu4.17 with Suhosin-Patch (cli) (built: Jun 19 2012 03:21:35) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with Suhosin v0.9.29, Copyright (c) 2007, by SektionEins GmbH

[multifinger]

UPD: отключение APC как-будто помогло, 5 минут в логах чисто… позже отпишусь что и как…
APC все-таки использовать хочется, кто знает как его правильно собрать? Я ставил из pecl-репозитория, а нужно по науке еще патчи какие-то наложить поверх и ручками все собрать.

[multifinger]

UPD: отключение APC не помогло, SIGBUS опять вылез

Answer 1

[multifinger]

Нашел решение, по крайней мере производительность выросла и SIGBUS больше вообще не встречается.

Во первых:

#/etc/php5/fpm/pool.d/www.conf
pm.max_children = 80 << 2000Mb (total_fpm_memory) / 25Mb (one fpm process memory usage)
pm.max_spare_servers = 20
pm.max_requests = 200

Это в целом улучшает стабильность, параметры расчитываются индивидуально
в этом же файле временно можно включить и посмотреть медленные запросы:

#slowlog = /var/log/php-fpm-slow.log
#request_slowlog_timeout = 5s
#listen.backlog = -1

Далее:

#/etc/php5/conf.d/apc.ini
[APC]
extension = apc.so
apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 256
apc.optimization = 0
apc.num_files_hint = 10000
apc.user_entries_hint = 10000
apc.ttl = 0
apc.user_ttl = 0
apc.gc_ttl = 600
apc.cache_by_default = 1
apc.filters = "apc\.php$"
apc.slam_defense = 0
apc.use_request_time = 1
apc.mmap_file_mask = /tmp/apc.XXXXXX
apc.file_update_protection = 2
apc.enable_cli = 0
apc.max_file_size = 5M
<b>apc.stat = 0</b>
apc.write_lock = 1
apc.report_autofilter = 0
apc.include_once_override = 0
apc.rfc1867 = 0
apc.rfc1867_prefix = "upload_"
apc.rfc1867_name = "APC_UPLOAD_PROGRESS"
apc.rfc1867_freq = 0
apc.localcache = 1
apc.localcache.size = 512
apc.coredump_unmap = 0
apc.stat_ctime = 0

Тут на самом деле ключевой была только настройка apc.stat = 0, остальное можно выкинуть

Собственно именно добавление apc.stat = 0 позволило устранить SIGBUS ошибку, теперь в логах только уведомления о том что дочерние процессы перезапускаются (из-за pm.max_request)

Answer 2

[NiGHt_LEshiY]

Попробуйте отключить кэширование (начать лучше с APC), если это возможно, и перезапустите php.
Есть такое чувство, что APC виноват в том, что лезет «не туда» куда следует в смысле памяти.

Comments

[multifinger]

Пробовал — дело не в APC, первым делом на него грешил…
Проявляется только под нагрузкой.

[NiGHt_LEshiY]

SIGBUS можно понимать как SEGFAULT, в смысле обращения к области памяти, в которую лезть нельзя. Обычно кэшеры mmap()'ят файлы в память и развлекаются там.
Если же это не кэш, то… можно откатиться на 5.3 и протестировать там (если сейчас 5.4).
Вы пишите, в каких конфигурациях уже тестировали, чтобы время не тратить на обзор всех вариантов.

Answer 3

[VBart]

Обновляться уже пробовали?

Answer 4

[Арвид Годюк]

А вы error_log в php.ini настроили? Если нет — включите, если да — то посмотрите что там. Уж очень похоже на то, что у вас памяти не хватает скрипту.