0

We just moved to a new server. 2 x Dedicated, 48 GB ram, php-fpm, nginx, memcached, APC. We have an issue where each php-fpm process that spawns keeps getting bigger. A fresh restart of php-fpm shows each process takes 30-100 MB. After a few hours, they are over 250MB. After 8 hours they are at 1.1GB or more for each php-fpm process that spawns. Brining the server to it’s knees. I had to restart php-fpm every hour. To mitigate for the time being, we reduced pm.max_requests to 1,000 from 10,000. It seems to have stopped each process from growing, but we have other issues.

  1. Anytime you save a product in admin, we get a 500 server error. The product saves, but it’s quite annoying.

  2. our magento import script from stoneedge won’t import orders and gives me 503 Bad Gateway Error. So we can’t import orders. This error is in nginx for the import script

2013/01/31 07:45:30 [error] 15417#0: *435945 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 173.14.230.102, server: www.campsaver.com, request: “POST /magento-import.php HTTP/1.1”, upstream: “fastcgi://127.0.0.1:9000”, host: “www.campsaver.com”

  1. this error is all over the place in nginx error logs too. Every few minutes.

2013/01/31 23:53:06 [error] 15430#0: *1176895 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 209.85.238.209, server: www.campsaver.com, request: “GET /mens-clothing/men-s-shirts?brand=254 HTTP/1.1”, upstream: “fastcgi://127.0.0.1:9000”, host: “www.campsaver.com”

  1. These errors are all over my php-fpm error logs

Jan 31 23:56:40.551917 [WARNING] [pool www] child 32011 exited on signal 7 SIGBUS after 8332.830655 seconds from start Jan 31 23:56:40.552514 [NOTICE] [pool www] child 935 started Jan 31 23:56:51.018778 [WARNING] [pool www] child 675 exited on signal 7 SIGBUS after 1080.377420 seconds from start Jan 31 23:56:51.019400 [NOTICE] [pool www] child 936 started Jan 31 23:57:07.588714 [WARNING] [pool www] child 601 exited on signal 7 SIGBUS after 1456.255594 seconds from start Jan 31 23:57:07.589324 [NOTICE] [pool www] child 940 started Jan 31 23:57:51.147662 [WARNING] [pool www] child 32037 exited on signal 7 SIGBUS after 8302.292151 seconds from start Jan 31 23:57:51.148279 [NOTICE] [pool www] child 942 started Jan 31 23:58:33.067957 [WARNING] [pool www] child 843 exited on signal 7 SIGBUS after 430.257647 seconds from start Jan 31 23:58:33.068582 [NOTICE] [pool www] child 944 started

Any ideas what is wrong with my server setup here?

1 Answer 1

1

SIGBUS
The SIGBUS signal is sent to a process when it causes a bus error. The conditions that lead to the signal being raised are, for example, incorrect memory access alignment or non-existent physical address.

So it sounds like you are over committing on memory and PHP is falling down because of it.

You could confirm by looking at the last kernel messages

dmesg

Or by simply checking your committed memory - and comparing to how much memory you actually have available.

cat /proc/meminfo | grep Committed_AS

Your issue sounds like it stems from a memory leak in a PHP extension - or simply bad Magento programming - the latter is more likely.

Thankfully, the former is easy to test. Just disable all PHP extensions apart from the bare minimum required for Magento (eg. APC/Source Guardian/Ioncube etc.).

The latter can be tested by merely following a standard Magento debug process.

At present, you are merely masking the problem by lowering the max requests value. If you don't have a good level of experience with Nginx and PHP-FPM - don't bother drinking the Magento kool-aid that Nginx/PHP-FPM is the holy grail of performance. It isn't. And its clearly causing you problems. My suggestion would be to go back to a more manageable Apache/mod_php configuration, which will yield the same performance and be more stable.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .