How to get rid of SIGBUS when running php-fpm?

Asked bylittleshout

Raised a web server with nginx + php-fpm + symfony1.4, working scripts using MySQL, APC, Memcached

I test the server under load for a long time, I look at the logs:
  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

Sometimes, for unknown reasons, the web server generally hangs ...
Help to figure out if anyone came across.

All necessary information, logs, etc.

Please, if you find what was the problem, or at least be able to get around it, unsubscribe in the question "according to the results." - linka
Actual problem? Of course accomplish your goal! - melodie
Thank God not yet, but we are migrating to fpm - I would not want to run into it. - samonia byford
  [email protected] ~ # uname -a Linux ws542 2.6.32-39-server #86-Ubuntu SMP Mon Feb 13 23:15:11 UTC 2012 x86_64 GNU/Linux [email protected] ~ # 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 - missy reed
UPD: turning off the APC seemed to help, 5 minutes in the logs are clean ... later I will accomplish what and how ...
Still, you want to use APC, who knows how to assemble it correctly? I put from the pecl-repository, but according to the science, I still need to put some patches on top and collect all the pens. - ng yoon fatt
UPD: disabling APC did not help, SIGBUS got out again - storm rogers johnson


I found a solution, at least the performance increased and SIGBUS no longer occurs at all.

pm.max_children = 80 << 2000Mb (total_fpm_memory) / 25Mb (one fpm process memory usage)
pm.max_spare_servers = 20
pm.max_requests = 200

It generally improves stability, parameters are calculated individually
In the same file, you can temporarily enable and view slow queries:
#slowlog = /var/log/php-fpm-slow.log
#request_slowlog_timeout = 5s
#listen.backlog = -1

extension =
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

Here, in fact, the key was only setting apc.stat = 0, the rest can be thrown out

Actually, adding apc.stat = 0 eliminated the SIGBUS error, now in logs only notifications that child processes are restarted (due to pm.max_request)
jared currier
Try disabling caching (start better with APC), if possible, and restart php .
There is a feeling that the APC is to blame for the fact that it climbs “not there” where it follows in terms of memory.
I tried it - it's not about the APC, the first thing I did was to sin ...
It appears only under load. - naomi sweo
SIGBUS can be understood as SEGFAULT, in the sense of referring to a memory area in which it is impossible to climb. Usually, mmap () caches are stored in memory and entertained there.
If this is not a cache, then ... you can roll back to 5.3 and test it there (if it is now 5.4).
You write in which configurations you have already tested, so as not to waste time on reviewing all the options. - lorraine barcant
darren m
Have you tried updating?
megan davidson
Did you configure error_log in php.ini? If not, turn it on; if so, see what's there. It is very similar to the fact that your memory is not enough for the script.
Why aren’t withdrawals when commenting on answers in Q & amp; A? :: Wireless video surveillance on the street :: iMac - is it worth it? :: Need to connect two points ~ 5km, speed 4-10Gb? :: Incomprehensible pop-up ad
Leave Repply forHow to get rid of SIGBUS when running php-fpm?
Useful Links