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

Apache не хватает памяти на

У меня есть VPS с 768 МБ ОЗУ и процессором 1,13 ГГц. У меня есть сайт знакомств php / mysql, производительность отличная, а нагрузка на сервер, как правило, очень низкая.

Иногда я размещаю рекламу в Facebook, и в часы пик я могу получить 100-150 кликов за несколько секунд - это приводит к нехватке памяти на сервере:

Невозможно выделить память: не удалось создать дочерний процесс: / opt / suphp / sbin / suphp ....

И все пользователи получают ошибку 500 страница.

Мне просто интересно, звучит это разумно или нет - мне 100-150 не кажется числом, которое должно вызывать у apache нехватку памяти.

Любые советы / рекомендации по диагностике проблемы приветствуются.

Оптимизация объема памяти обычно достигается за счет уменьшения (и ограничения) следующих факторов:

  • количество одновременных процессов Apache (я бы порекомендовал переключиться на предварительную версию MPM, которая отчасти более управляема в среде с ограничением памяти)
  • переходя от mod_php или php_cgi к fastcgi, mod_cfgid работает нормально. Уменьшение количества разрешенных порожденных процессов php с помощью FcgidMaxProcesses и удаление длинных таймаутов (см. http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html )
  • "поточность" сервера, особенно за счет сокращения излишне длинных тайм-аутов ((отключение) таймаутов подключения, сообщений поддержки активности, ...)

Если нагрузка становится действительно большой, вам также следует изучить скорость обработки запроса (более быстрая загрузка улучшает общий размер * время памяти, необходимое для одного запроса)

  • оптимизация кода вашего веб-сайта (улучшение PHP-кода, чтобы он был быстрее и / или более эффективным с точки зрения памяти)
  • оптимизация выполнения PHP (xcache может ускорить работу в несколько раз)
  • кеширование целых запросов тоже творит чудеса, см. mod_cache

Возможно, если ваш веб-сайт совсем не загружает процессор и вам нужен экстремальный Req / S, попробуйте какой-нибудь другой веб-сервер (например, nginx или lighttpd), который лучше себя ведет в таких ситуациях.

Первое, что нужно сделать, это привести в порядок вашу текущую систему. По умолчанию apache обычно настроен с множеством расширений, которые вам, вероятно, не нужны (в частности, auth и proxy, также, если вы используете SSL, но только изредка, тогда рассмотрите возможность удаления mod_ssl и запуска stunnel вместо этого). Включите mod_deflate. Посмотрите на все остальное, что работает в вашей системе - выключите (и отключите) все службы, которые вам не нужны.

Далее, запуск suphp на выделенной машине через CGI обычно очень глупая идея - используйте mod_php или fastCGI.

Ускоряя работу вашей системы, вы не только улучшаете обслуживание своих клиентов, но и сокращаете объем памяти. Так....

Установите кеш кода операции PHP, если у вас его еще нет.

Начните копаться в производительности вашей системы - измените конфигурацию httpd, чтобы начать регистрацию% D, и посмотрите на произведение частоты URL-адреса и% D, чтобы определить, какие URL-адреса вызывают больше всего проблем.

Снизьте порог в журнале медленных запросов в MySQL - используйте это парсер или аналогичным образом для анализа данных (обратите внимание, что опять же, вам следует расставить приоритеты на основе произведения частоты и времени выполнения).

Добавьте автоматическое добавление, чтобы включить сжатие выходного буфера gz.

Начните записывать количество запущенных процессов httpd и сравните это с доступным меньшим количеством кешей / буферов из «бесплатного» - сопоставьте данные и изобразите их, чтобы определить, сколько процессов httpd вы можете разумно запустить - затем измените свой httpd.conf, чтобы обеспечить это предел. Обратите внимание, что дисковый ввод-вывод феноменально медленный - значит, для кэширования необходим достаточный объем памяти.

Начните смотреть, предоставляет ли ваш сервер хорошую информацию о кешировании с контентом - или клиенты и прокси должны продолжать возвращаться за вещами, которые не изменились (mod_expires, mod_headers)

Но иногда вам просто нужно больше оборудования. Я бы рекомендовал подумать о втором сервере, а не просто обновлять тот, который у вас есть - добавление циклического DNS тривиально - и вы получите дополнительную выгоду в виде лучшей доступности (как только вы выясните, как обрабатывать репликацию базы данных) .

Требование к памяти для каждого экземпляра Apache составляет около 10 МБ, хотя точный объем зависит от вашей конфигурации. Таким образом, если вы хотите обслуживать 100 одновременных подключений с Apache, вам понадобится как минимум 1 ГБ ОЗУ плюс все, что необходимо системе, MySQL и всему остальному, что вы используете.

Если вы хотите остановить состояние «вне ошибки», вы можете настроить MaxClients Параметр конфигурации Apache на соответствующий уровень. Чтобы получить оценку памяти для каждого экземпляра Apache, посмотрите top вывести и вычесть столбцы RES и SHR всех команд httpd. Обязательно вычтите всю память, необходимую MySQL и остальной системе. Обратите внимание, что вы можете получить относительно небольшое количество MaxClients на этой машине (30-50).

Другие ответы дали хорошее резюме того, что вы можете сделать, чтобы улучшить количество одновременных запросов, которые вы можете обработать. Имейте в виду, что на такой младшей системе может быть сложно, хотя и не обязательно невозможно, подогнать Apache / PHP / MySQL плюс lighttpd / nginx / memcached / caching. Насколько легко или сложно, будет зависеть от вашего приложения и вашей целевой производительности. Подумайте о переходе на более крупный сервер ... вам будет намного проще собрать все, что нужно для 2 или 4 ГБ.

Управлять пиковым трафиком сложно. Альтернативы включают: более легкий HTTP-сервер (lighttpd, nginx и др.); больше физической RAM; балансировщик нагрузки и дополнительные хосты, что дает дополнительное преимущество в виде более высокой доступности; выгрузка кода приложения в систему, отдельную от вашего HTTP-сервера, обычно через FastCGI; динамическое выделение вычислительных ресурсов для удовлетворения нагрузки через облачный сервис, такой как EC2; или тонны других идей, которые я забыл или не придумал. Есть несколько отличных ресурсов по этому поводу; в Высокая масштабируемость блог, например, охватывает большую часть этой территории. Надеюсь это поможет!