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

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

Причина в том, чтобы не позволить Apache потреблять столько ресурсов, чтобы это могло угрожать общей стабильности системы. Поэтому, если вы увеличиваете MaxClients и другие подобные директивы, необходимо следить за системными ресурсами, такими как RAM.

Подробнее здесь: Директива MaxClients

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Базовая статистика, такая как сетевой io, потребление оперативной памяти, потребление ЦП, дисковое io, сбои страниц и т. Д. Для задействованных машин, также может быть полезна для изучения.

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

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

у вас не может быть сайта сверхвысокой доступности на одном vps, если только его статический html, да еще и лак, не идеален.

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