Приложение, работающее с слабо загруженным Apache HTTPD 2.0, иногда имело проблемы, когда один (или несколько?) Процессов Apache занимал 100% ЦП. В настоящее время мы запускаем HTTPD 2.2, возможно, мы видели это и в 2.2. Я не уверен. В некоторых случаях загрузка ЦП была такой, что блокировал доступ к серверу Windows, на котором размещен HTTPD, кроме консольного. Мне никогда не удавалось отследить, что может заставить Apache делать это.
Среда - это Apache HTTPD, непосредственно обслуживающий статический контент, с использованием mod_rewrite, но не более того, настраиваемой конфигурации. HTTPD обращается к Apache Tomcat (5.x) через mod_jk (1.2.25).
Кто-нибудь еще сталкивался с этим и решил это? Обходной путь, который мы установили, - ограничить каждый подпроцесс Apache HTTPD максимальным количеством запросов со следующей конфигурацией:
MaxRequestsPerChild 1000
где, поскольку приложение использует HTTP / 1.1, это действительно более 1000 запросов на дочерний процесс и больше, чем 100 000 запросов на дочерний процесс.
Скорее всего, блокировка происходит в модуле, а не в самом Apache. Ваша настройка звучит довольно минималистично, поэтому я подозреваю mod_jk как виновник. Если ограничивающий MaxRequestsPerChild устраняет проблему, тогда я бы сказал, что это приемлемый обходной путь. Вполне возможно, что ошибка в модуле срабатывает только после долгого времени или большого количества запросов, и если вы действительно не заинтересованы в отслеживании этой ошибки, ее устранение, вероятно, будет достаточно.
Если вы хотите его отследить, первое, что нужно сделать, это настроить CoreDumpDirectory чтобы указать место, в которое пользователь сервера может писать. Если вы можете заставить оскорбительный процесс оставить основной файл, это должно помочь вам отследить причину проблемы. Вы можете найти несколько советов по этому поводу в Руководство по отладке Apache.
Когда я увидел это, это было потому, что: - размещенное приложение или скрипт вызывает проблему. Например, у него бесконечный цикл или что-то в этом роде - ОС стала нестабильной из-за блокировки или какой-либо другой проблемы, когда перезагрузка временно решила проблему.
Мое предложение: - перезагрузите машину. - подождите и посмотрите, не повторится ли это снова - перезапустите сервер без модов и т. д. - Начните включать каждый мод один за другим и каждый раз наблюдайте за использованием.
Ограничение MaxRequestsPerChild поможет с использованием памяти, но не должно влиять на процессор так, как вы говорите. Скорее всего, произойдет сбой вашего mod_jk, и, поскольку это модуль apache, он отображается в процессе httpd.
Я действительно видел, как это происходит, когда у вас есть каталог журналов, которого не существует. Я не уверен, почему они не справляются с этим лучше, но вы можете убедиться, что все каталоги журналов есть и процесс может писать в них.
установить mod_proctitle для apache
RLimitCPU не всегда помогает, потому что не все части кода apache проходят проверку.
MaxRequestsPerChild также может не помочь, поскольку я видел это с относительно «свежими» детьми.
В моем случае я подозреваю, что это как-то связано с используемым нами модулем (mod_perl) и, возможно, с нарушенным соединением сокета. Кажется, мы видим эту проблему только при подключении браузеров, а не через wget или curl (которые мы активно используем для «доставки данных»).
Я также столкнулся с той же проблемой, пока не выяснил основную причину проблемы ...
Проблема: В настоящее время мой веб-сайт работает на Wordpress с XAMPP на облачном сервере Windows, и загрузка ЦП увеличивается на 100%.
Решение: проверил мой файл журнала Apache (access.log), и кто-то постоянно пытался получить доступ к файлу xmlrpc.php и 10 запросов в секунду, что заставляет сервер Apache обрабатывать входящий запрос, поэтому здесь я предлагаю вам заблокировать входящий доступ в файл xmlrpc.php из вашего файла .htaccess, также заблокировал IP-адреса от моего хостинг-провайдера, в результате чего загрузка ЦП теперь составляет максимум 3-5%.
Примечание: это решение предназначено для веб-сайтов, на которых работает Wordpress.
http://devslounge.com/htaccess/can-cause-apache-httpd-use-100-cpu-indefinately/
https://wordpress.org/support/topic/xmlrpcphp-attack-on-wordpress-38