Есть ли проблема с тем, что всегда выполняется большое количество резервных процессов httpd? Я провел тест, где увеличил StartServers и MinSpareServers на 1000 и измерил увеличение использования памяти, и оно составило всего 500 МБ.
В свете этого я подумал, что, поскольку у нас много оперативной памяти, для достижения оптимальной производительности во время периодов скачкообразного трафика мы могли бы также иметь StartServers и MinSpareServers установить около 1000 и, конечно, установить ServerLimit и MaxRequestWorkers (ранее MaxClients) к чему-то более высокому.
Есть ли какие-либо недостатки в этом, о которых я не знаю, если предположить, что наш сервер способен обрабатывать такое количество запросов одновременно, и мы используем MaxConnectionsPerChild в качестве меры предосторожности против утечки памяти?
В качестве побочного примечания для тех, кто думает, что 0,5 МБ на процесс httpd неверно, из того, что я прочитал, причина, по которой использование памяти Apache намного меньше, чем то, что сообщается для отдельного процесса от top в том, что он использует разделяемые библиотеки.
Нет проблем с тем, что всегда выполняется большое количество резервных процессов httpd. На самом деле это хорошая идея.
Суть в том, что если вы хотите, чтобы httpd достиг такого количества процессов, вам лучше сразу обратиться к нему и убедиться, что он работает. Другими словами, не масштабируйте автоматически, а просто предварительно масштабируйте. Меньше сюрпризов.
Второй момент: если вам не нужно совместно использовать ресурсы (в данном случае в основном ОЗУ) или адаптироваться к различным службам, запущенным в разное время на вашем сервере, нет смысла изменять количество процессов с течением времени. Выделите бюджет оперативной памяти для httpd и создайте экземпляры, необходимые для обработки такого количества одновременных запросов.
15 лет назад люди могли делиться множеством вещей на одном сервере, и это имело смысл адаптировать количество httpds к рабочей нагрузке. В настоящее время большинство людей используют один сервер для каждого приложения: большую часть времени не используют все его ресурсы, но производительность более предсказуема, а анализ и настройка производительности намного проще.
Хотя в конкретной ситуации, которая на самом деле очень распространена, есть подводный камень: Apache + mod_php (или любой другой интерпретатор, встроенный в любой httpd). Здесь mod_php полностью меняет сделку, потому что тогда возникает вопрос о масштабировании приложения, а не о масштабировании httpd, что является другой (продолжительной) темой, и требует другого подхода (предварительно созданный воркер 1000 работать не будет).
Чего вы пытаетесь избежать, так это входящих запросов, вызывающих разветвление новых процессов с более высокой скоростью, чем старые процессы могут обслуживать старые соединения. Этот риск вызывает ситуацию, когда система продолжает создавать новые процессы, которые потребляют доступную память, и начинает увеличивать частоту, с которой операционная система использует подкачку. Что, в свою очередь, приводит к значительному увеличению дискового ввода-вывода, когда система просто переключает страницы из физической памяти в виртуальную (на диске) и наоборот, без какой-либо реальной выгоды для рабочей нагрузки.
Общая формула для начала:
(Общая память - Операционная память - память базы данных) / Размер на процесс Apache.
Формула - это только часть уравнения. Чем больше вы даете системе и MySQL памяти, тем больше они кэшируют файловую систему и избегают попадания на диск, что очень дорого. Если база данных не находится в той же системе, это не проблема.
Другой сценарий, который происходит, если вы не настроите Apache должным образом и частота обмена увеличивается, - это когда пользователи начинают нажимать кнопку остановки и перезагружать, искусственно увеличивая нагрузку на сервер. Вы можете контролировать MaxRequestWorkers настройте так, чтобы ваш сервер не порождал столько дочерних элементов, что он начал бы подкачку. Это кажется простым в том смысле, что вы просто определяете размер вашего среднего процесса Apache, просматривая список процессов с помощью такого инструмента, как top или smem, а затем делите его на общую доступную память, оставляя достаточно памяти для других процессов, которые вы будете получить более точную картину.
Другой ключевой параметр в этом сценарии - ServerLimit. Если ServerLimit установлено значение, намного превышающее необходимое, будет выделена дополнительная неиспользуемая общая память. Если оба ServerLimit и MaxRequestWorkers установлены на высокий уровень. Производительность Apache httpd и общая общая стабильность Apache httpd могут стать проблемой.
Меня беспокоит ваша методология тестирования. Похоже, вы просто запускаете целую кучу процессов, а затем просматриваете их использование памяти. Проблема в том, что когда они впервые появляются, они совместно используют максимальный объем памяти и не хранят никаких локальных данных для каждого процесса.
Когда вы начнете их использовать, вы обнаружите, что этим процессам требуется больше памяти. Это верно даже при отсутствии утечек памяти, но если вы используете какие-либо негерметичные расширения, проблема становится очень серьезной, очень быстро.
Я бы рекомендовал провести много реалистичного нагрузочного тестирования в различных условиях, прежде чем оставлять такую конфигурацию для работы без тщательного контроля.