Мы только что переехали на новый сервер. 2 выделенных, оперативная память 48 ГБ, php-fpm, nginx, memcached, APC. У нас есть проблема, из-за которой каждый запускаемый процесс php-fpm становится больше. Новый перезапуск php-fpm показывает, что каждый процесс занимает 30–100 МБ. Через несколько часов их размер превысит 250 МБ. Через 8 часов они составляют 1,1 ГБ или больше для каждого запускаемого процесса php-fpm. Ставит сервер на колени. Приходилось перезапускать php-fpm каждый час. Чтобы смягчить ситуацию, мы уменьшили pm.max_requests до 1000 с 10000. Кажется, что это остановило рост каждого процесса, но у нас есть другие проблемы.
Каждый раз, когда вы сохраняете продукт в админке, мы получаем ошибку сервера 500. Продукт сохраняет, но это сильно напрягает.
наш скрипт импорта magento из stoneedge не импортирует заказы и выдает ошибку 503 Bad Gateway Error. Поэтому мы не можем импортировать заказы. Эта ошибка есть в nginx для скрипта импорта
31.01.2013 07:45:30 [ошибка] 15417 # 0: * 435945 recv () не удалось (104: сброс соединения одноранговым узлом) при чтении заголовка ответа от восходящего потока, клиент: 173.14.230.102, сервер: www.campsaver. com, запрос: «POST /magento-import.php HTTP / 1.1», исходящий поток: «fastcgi: //127.0.0.1: 9000», хост: «www.campsaver.com»
31.01.2013 23:53:06 [ошибка] 15430 # 0: * 1176895 recv () не удалось (104: сброс соединения одноранговым узлом) при чтении заголовка ответа от восходящего потока, клиент: 209.85.238.209, сервер: www.campsaver. com, запрос: «GET / mens-clothing / men-s-shirts? brand = 254 HTTP / 1.1», исходящий поток: «fastcgi: //127.0.0.1: 9000», хост: «www.campsaver.com»
31 января 23:56: 40.551917 [ПРЕДУПРЕЖДЕНИЕ] [pool www] дочерний элемент 32011 завершился по сигналу 7 SIGBUS через 8332,830655 секунд с начала 31 января 23:56: 40.552514 [УВЕДОМЛЕНИЕ] [pool www] дочерний элемент 935 запущен 31 января 23:56: 51.018778 [ПРЕДУПРЕЖДЕНИЕ] [бассейн www] ребенок 675 вышел по сигналу 7 SIGBUS через 1080.377420 секунд с начала 31 января 23: 56: 51.019400 [УВЕДОМЛЕНИЕ] [бассейн www] ребенок 936 запущен 31 января 23: 57: 07.588714 [ПРЕДУПРЕЖДЕНИЕ] [бассейн www] ребенок 601 вышел по сигналу 7 SIGBUS через 1456,255594 секунды с начала 31 января 23: 57: 07,589324 [УВЕДОМЛЕНИЕ] [бассейн www] ребенок 940 запущен 31 января 23: 57: 51.147662 [ПРЕДУПРЕЖДЕНИЕ] [бассейн www] ребенок 32037 вышел по сигналу 7 SIGBUS после 8302,292151 секунды с начала 31 января 23:57: 51.148279 [УВЕДОМЛЕНИЕ] [pool www] дочерний 942 запущен 31 января 23:58: 33.067957 [WARNING] [pool www] дочерний элемент 843 завершился по сигналу 7 SIGBUS через 430,257647 секунд с начала 31 января 23: 58: 33.068582 [УВЕДОМЛЕНИЕ] [бассейн www] дочерний 944 запущен
Есть идеи, что не так с настройкой моего сервера?
SIGBUS
Сигнал SIGBUS отправляется процессу, когда он вызывает ошибку шины. Условия, которые приводят к возникновению сигнала, - это, например, неправильное выравнивание доступа к памяти или несуществующий физический адрес.
Похоже, вы слишком загружаете память, и из-за этого PHP падает.
Вы можете подтвердить, посмотрев последние сообщения ядра
dmesg
Или просто проверив выделенную память - и сравнив ее с тем, сколько памяти вы фактически есть в наличии.
cat /proc/meminfo | grep Committed_AS
Похоже, ваша проблема связана с утечкой памяти в расширении PHP или просто с плохим программированием Magento - последнее более вероятно.
К счастью, первое легко проверить. Просто отключи все Расширения PHP, помимо минимума, необходимого для Magento (например, APC / Source Guardian / Ioncube и т. Д.).
Последний можно проверить, просто следуя стандартному Процесс отладки Magento.
В настоящее время вы просто маскируете проблему, уменьшая максимальное количество запросов. Если у вас нет хорошего опыта работы с Nginx и PHP-FPM - не трудитесь пить Magento kool-aid что Nginx / PHP-FPM - это святой Грааль производительности. Это не. И это явно вызывает у вас проблемы. Мое предложение - вернуться к более управляемой конфигурации Apache / mod_php, что даст такую же производительность и быть стабильнее.