Назад | Перейти на главную страницу

Конфигурация Magento Apache и проблемы с памятью

У меня есть установка Magento на VPS, которая вызывает у меня головную боль.

Этот конкретный VPS имеет разумные характеристики - 2 ГБ памяти и 50 ГБ хранилища. Он работает с одним доменом с одной установкой Magento - и ничего больше.

Около 5 месяцев назад у нас начались проблемы. Время от времени (примерно раз в 2 или 3 недели) VPS падал - все процессы останавливались, и единственный способ перезапустить контейнер - через ПК Р-Виртуализация.

Сейчас, правда, 2 или 3 раза в неделю. Мои хосты VPS подтверждают, что я нарушаю ограничение памяти в 2 ГБ, после чего все процессы VPS прекращают работу, чтобы остановить отключение всего узла.

Я вообще не вносил никаких изменений в конфигурацию - я какое-то время запускал на нем New Relic, но удалил его на случай, если он усугубил проблемы. Я не вижу в журналах ничего, что указывает на проблему, и у нас нет заданий CRON, запущенных на момент сбоя.

Сайт генерирует стабильный, но небольшой объем трафика (в среднем обычно менее 100 посещений в день).

Есть ли что-нибудь, что я должен был сделать с конфигурациями Apache или PHP, чтобы помочь? Я не очень опытный администратор Apache, но знаю более чем достаточно, чтобы решить большинство проблем ...

В противном случае, какие-нибудь другие идеи, которые могут помочь? Не могу позволить, чтобы этот сайт так сильно упал.

Еще одна полезная вещь, на которую стоит обратить внимание при установке MAXCLIENTS, - это ApacheBuddy.

Видеть https://github.com/gusmaskowitz/apachebuddy.pl

Это в основном просматривает статистику и ваши файлы конфигурации и дает вам рекомендации относительно того, какой должна быть настройка MAXCLIENTS. Честно говоря, я никогда не смогу позволить себе опускаться так низко, как они рекомендуют, но это, вероятно, «правильный» ответ.

Для использования / установки:

wget https://raw.github.com/gusmaskowitz/apachebuddy.pl/master/apachebuddy.pl

perl apachebuddy.pl

Полезные параметры включают -p (для порта, например, если вы используете varnish) и -P (то есть с заглавной буквы «P»), чтобы также учесть настройки памяти PHP.

Вместо этого вы можете попробовать apache-mpm-worker с php5-fpm. Я заметил резкую разницу, когда переключился со стандартной комбинации prefork / mod_php.

Еще несколько предложений:

  1. Проверьте конфигурацию mysql, запустив tuning-primer.sh сценарий. Это обеспечит хорошую основу, чтобы убедиться, что ваш mysql настроен правильно и вы не тратите на него память.

  2. Вы пользуетесь преимуществами компонентов компиляции и кеширования Magento?

  3. Поскольку у вас есть только 2 ГБ оперативной памяти, убедитесь, что ваш Apache MaxClients находится на разумном уровне. Начните с небольшого числа (например, 25) и отслеживайте использование ОЗУ, чтобы увидеть, можете ли вы его немного увеличить.

  4. 2 ГБ - не так уж много памяти для сервера Magento с приличным объемом трафика. Вы пытались увеличить объем оперативной памяти или, возможно, получить второй сервер для выделенного mysql, чтобы освободить эту оперативную память для Apache?

  5. Проверяли ли вы с помощью анализатора журналов (например, webalizer, awstats и т. Д.) Или, возможно, даже просто расширенного модуля состояния Apache, что Apache является проблемой во время чрезмерного использования памяти?

Немногое о чем я могу думать прямо сейчас:

1) Убедитесь, что у вас запущен prefork MPM, а не рабочий MPM 2) Отредактируйте apache2.conf (в Debian он находится в /etc/apache2/apache2.conf:

Убедитесь, что есть следующая конфигурация (кажется, лучше для нас :)

Timeout 30
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 2

# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_prefork_module>
    StartServers          10
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          150
    MaxRequestsPerChild   2000
</IfModule>

3) Посмотрите на использование Varnish в качестве механизма кэширования, который снизит нагрузку на Apache 4) Установите APC / Memcache

Как правило, это простая математика того, что нужно установить в вашем файле конфигурации apache. У вас есть 2 гигабайта оперативной памяти и, вероятно, 1,5 из них могут использоваться apache.

так что это ~ 1500 мегабайт. Убедитесь, что ваш файл .htaccess для Magento работает нормально.

php_value memory_limit 128M php_value max_execution_time 120

(Если честно, у нас установлено значение 512 м, потому что многие пользователи получали пустые страницы. Прочтите var / log / exception.log, чтобы узнать, так ли это)

В этом сценарии вы можете поддерживать только MaxClients, равное 12! И, честно говоря, я думаю, что ограничение по умолчанию для magento теперь составляет 256. Что означает максимальное количество клиентов 6! Я бы также предложил использовать меньше MaxRequestsPerChild. Возможно, всего 100. Я бы увидел, как несколько процессов становятся все больше и больше. По моему опыту, дети Apache не освобождают память, пока не будут уничтожены. Это то, что делает этот параметр. Возродить дочерний процесс после 100 запросов.

У меня было много проблем с apache. У нас есть сервера с 7 гигами, которые падают как вы описали. Однако наш трафик намного больше, чем ваш.

Я только что видел, как вы запускали mysql и на этом компьютере. Не хорошо. Вы можете изучить запуск nginx с помощью php-fastcgi. У меня он работает довольно хорошо и использует гораздо меньше памяти. Единственным препятствием для нас было то, что у нас было расширение, использующее ионный куб, который нам нужен, и я не мог с ним сотрудничать. (Я также использовал xcache вместо apc в качестве нашего кеша опкодов, потому что слышал, что apc не будет делить память между процессами cgi)

Я также использовал nginx в качестве обратного прокси для обслуживания всего статического контента. Это также может сработать для вас. Это было намного лучше, и мы использовали его долгое время, пока не решили применить лак.

По крайней мере, вам нужно реализовать какое-то решение для кеширования для Magento.