Средняя загрузка системы чрезвычайно высока

MaxClients - это директива сервера Apache. Есть несколько связанных директив, но все они по-разному касаются установки ограничения на обработку запросов Apache.

Мотивом для этого является то, что Apache не потребляет так много ресурсов, чтобы поставить под угрозу общую стабильность системы. Поэтому, если вы увеличиваете MaxClients и другие подобные директивы, необходимо следить за системными ресурсами, такими как ОЗУ.

Узнайте больше здесь: Директива MaxClients

Но для начала, неясно, где именно проблема, даже если вы заметили некоторые симптомы (очевидно, или вы не будете публиковать). Возможно, Apache показывает вам проблему, которая лежит в другом месте.

Но в выводе вы сосредоточены на Apache, поскольку эта часть довольно проста, поэтому давайте начнем с нее.

Как вы прочитали в ссылке, MaxClients определяют максимальное количество запросов, которые выполняет httpd. Когда это заполняется, запросы помещаются в очередь в ListenBackLog. Когда это заполнено, клиенты отклоняются.

• Либо maxclients заполнен, потому что количество одновременных запросов было так много. Тогда вам нужно обеспечить то, что относительно легко. Увеличивайте и / или уменьшайте в слое Apache, пока не окажетесь на безопасной стороне, или пока уровень db не достигнет максимума.

• Или maxclients заполнены, потому что они не могут быть поданы достаточно быстро из-за нижележащих слоев. Поэтому запросы накапливались в Apache, пока больше не были приняты. Это не так легко решить, поскольку в первую очередь возникает множество вопросов. Вы мгновенно сосредотачиваетесь на слое базы данных, вероятно, по уважительной причине, даже если вы еще не сделали это полностью ясно (пока).

Также было бы интересно узнать, были ли отклонены клиенты, сколько и т. Д. Если вы добавляете коды статуса страницы в свои журналы, вы можете проанализировать...503 Я помню, но вам следует проверить это на Google. Это просто для того, чтобы узнать о вашей доставке и установить базовый уровень для сравнения со следующим случаем.

Вот несколько вопросов, которые приходят на ум. Я понимаю, найти ответы. легче сказать, чем сделать, если у вас нет инструментов, которые дают вам высшее понимание. Мы используем Dynatrace (Java-ориентированный), который очень дорогой, но может дать ответы на такие вопросы в считанные минуты и вплоть до уровня компонентов в коде, даже для системного администратора. Это делает процедуру быстрой определения причинно-следственной связи в коде, инфраструктуре или в комбинации. Я знаю, что на рынке есть другие инструменты и, возможно, альтернативы с открытым исходным кодом, которые делают это. У меня просто нет опыта работы с ними. Я полагаю, что можно отлаживать и отладку кода, и приложения, тоже самое, просто дело в том, что это отнимает гораздо больше рабочего времени.

Потребовалось ли больше времени на обработку запросов при обработке к описанной вами ошибке? Мои Apachelogs показывают мне, сколько времени потребовалось для обслуживания каждого запроса. Я не могу вспомнить, по умолчанию это или нет, но могу опубликовать такую ​​директиву в начале недели, если у вас ее нет.

Если они заняли больше времени, было ли это из-за разных шаблонов запросов или просто из-за больших чисел?

С точки зрения нагрузки на сервер Apache, вы обслуживаете много статического контента или он в основном динамический? Вы как-то описали только статические и просто динамические? Этот вопрос актуален, поскольку статический контент может быть разделен как на разные серверы доставки, так и на кэш-память RAM (Varnish упоминался в другом ответе). В некоторых случаях экономия может быть значительной, в других - нет.

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

Если посмотреть глубже, то тяжел ли код при его обработке? Можно ли исходить из того, что используются запросы, которые в основном вызывают логику, но относительно мало обращений к базе данных? Возможно, это код, который нужно оптимизировать или увеличить / уменьшить?

Оптимизированы или бесполезны вызовы базы данных как по количеству, так и по тому, как формулируются запросы? Каково было время ответа на каждый звонок во время большой нагрузки? Время отклика увеличилось? Количество звонков достигло больших объемов?

Вы видите, куда она направляется все ближе и ближе к базе данных, на каждом слое, рассматривая возможности оптимизации, кэширования, распределения (масштабирования), сырой мощности (масштабирования).

Может быть, у вас уже есть все эти ответы, и вы абсолютно правы в том, чтобы сосредоточиться на innodb, я не могу сказать с предоставленной информацией! Все, что я могу предоставить, это методические вопросы, которые могут быть актуальны или нет, и которые могут звонить в колокола или нет:-)

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

Основные статистические данные, такие как сетевой ввод, потребление оперативной памяти, потребление ресурсов процессора, дисковый ввод-вывод, сбои страниц и т. Д. Для участвующих машин также могут быть полезны для изучения.

Ответом на ваш вопрос является кэширование памяти рычага в максимально возможной степени. то есть memcache, varnish и т. д., а затем используйте nginx, который можно масштабировать по горизонтали, а за ним пул php-fpm, соответствующий размеру вашей нагрузки, полностью объединенный с блоками upsream nginx.

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

у вас не может быть сайта с очень высокой доступностью на одном VPS, если только его статический HTML, и даже тогда лак не идеален.

получите пару балансировщиков нагрузки внешнего интерфейса haproxy, распределяя их по лакам, вытягивая из nginx / php / memcache / redis / mysql (postgres)..... вот в двух словах:P