Рабочий режим недоступен с mod_php для Apache. потому что, если известно, что PHP5 поддерживает многопоточность, это действительно не относится ко всем библиотекам и расширениям PHP (например, вызов локали принудительно установит настройки локали для всех потоков PHP в процессе apache).
Итак, не используйте рабочую модель. За исключением, может быть, если вы используете PHP вне Apache (с php-fpm). И в Windows вы можете столкнуться с теми же проблемами порчи потоков (но официально дистрибутивы PHP в Windows считаются поточно-ориентированными, если вы не добавляете самоскомпилированный внешний компонент PHP ...).
Когда вы говорите:
память вообще не освободится
Я не уверен, что вы полностью понимаете, что происходит. Apache разветвляет большое количество дочерних процессов. Если вы используете приложение Drupal6 для этих детей и разрешите большой memory_limit для PHP, вы можете быть совершенно уверены, что Drupal будет использовать этот предел памяти, поэтому если вы указали 128M ваш дочерний процесс apache, запуск PHP займет эту RAM (если Drupal попросит об этом , но Drupal с представлениями является хорошим потребителем оперативной памяти, конечно). Когда запросы заканчиваются, подпроцесс Apache не освобождает ОЗУ, поскольку для следующего запроса может потребоваться столько же. Таким образом, если вы разрешите Apache 100 MaxClients и ограничение памяти 128 МБ, вы можете получить 128 М * 100 = 12,5 ГБ ОЗУ. Теперь в Linux тот факт, что доступная оперативная память используется, не является проблемой, вы можете подумать об этом как о хорошей вещи. У вас есть оперативная память, почему бы не использовать ее? Возможно, ваша проблема в том, что у вас нет этого количества оперативной памяти (здесь 12,5G, только для Apache)
Вы можете принудительно запустить матрицу подпроцесса apache с помощью MaxRequestsPerChild , скажем, со значением 100, затем после 100 запросов, обработанных дочерним процессом apache, он будет уничтожен и создан заново. Но если всем вашим запросам требуется 128 МБ ОЗУ, вы скоро столкнетесь с той же проблемой.
- установить низкие значения для MaxClients (меньше доступного ОЗУ / среднего ОЗУ одного процесса),
- перенести сервер MySQL на другой сервер, а также большой объем памяти RAM
- попытайтесь найти нижний предел для memory_limit (это может быть довольно сложно с Drupal, но проверьте все модули профилирования Drupal и проверьте все настройки видимости ваших блоков, вы получите хорошие подсказки)
- если ваш проект достаточно большой, купите несколько серверов Apache и создайте решение с балансировкой нагрузки http.
- используйте php в режиме fastcgi (например, php-fpm ), так что по крайней мере все не-php страницы будут использоваться с рабочим сервером apache (но вы получите те же проблемы использования оперативной памяти внутри ваш php сервер fastcgi)