Загрузка процессора Ubuntu Server 12.04

Мне кажется, это нормально.

У вас 12 ядер ... на двух 6-ядерных процессорах. Таким образом, при 100% производительности средняя загрузка должна быть 12.

Средняя нагрузка смешная. Я не думаю, что это означает то, что вы думаете.

Средняя нагрузка на самом деле является показателем того, сколько процессов выполняется одновременно, в среднем за 1, 5 и 15 минутные окна.

Мне кажется, ты немного перегружен, но не сильно.

Возможно использование http://mysqltuner.pl/mysqltuner.pl чтобы получить некоторое представление о том, как ваши настройки mysqld соответствуют реальным объемам использования.

Следующим логическим шагом, конечно же, является разделение MySQL и Apache на разные блоки. Я еще не уверен, что вы на этом уровне, потому что у вас еще есть штаны оперативной памяти, свободной для MySQL. Вы можете найти некоторую выгоду в увеличении кешей запросов и ключевых буферов и, вероятно, более внимательно изучить Журнал медленных запросов MySQLи посмотрите, сможете ли вы вообще оптимизировать таблицы.

Существует масса информации о том, как считывать средние значения нагрузки, и на самом деле более разумно разделить среднее значение нагрузки на количество ядер, чтобы вы имели некоторое представление о том, как на самом деле используется сервер.

Теперь я вижу, что у вас 33% iowait. Я подозреваю ... что у вас довольно большая база данных для записи, и это приводит к блокировке таблиц, когда вы пишете, а это означает, что одновременная запись невозможна.

Имея понюхал на my.cnf похоже, что max_connections довольно велико, но это не вызывает большого беспокойства, но это означает, что если вы используете их все, вам понадобится 27 ГБ ОЗУ, чтобы это разрешить. Это много, но опять же не большая проблема.

Рассматривать превращение на PHP APC Opcode кеширование.

** редактировать **

Теперь, просмотрев журнал запросов, я склонен думать, что есть несколько вещей, которые могут принести пользу серверу.

1. Кэширование кода операции PHP APC (в целом делает apache более эффективным)
2. Преобразуйте все таблицы в InnoDB, если у вас нет действительно хорошая причина. ЕСЛИ это причина полнотекстового поиска, найдите лучший способ сделать это и перейдите к InnoDB.
3. Купите другой сервер и сделайте его выделенным хостом БД. Совместите его с дисками SAS и разделите на разделы, чтобы журналы и данные находились на отдельных шпинделях (или, скорее, в массивах RAID).

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

Возможно, стоит попробовать NewRelic для PHP. Это бесплатно в течение месяца и дает хорошее представление о неприятных запахах кода.

Кроме того, я доступен для консультации;)

В вашем главном выводе есть одна поразительная особенность - это количество процессов в состоянии D. Хороший кусок apache2 и даже kjournald даже в состоянии D. Известно, что процессы состояния D увеличивают нагрузку на ЦП.

Чаще всего процесс переходит в состояние D, когда ожидает ввода-вывода. После получения IO он снова переходит в состояние R или состояние S из D. Следующее, что вы можете сделать для выполнения отладки в реальном времени, - это проверить, сколько времени выполняются эти процессы состояния D. Если на какое-то время проблема.

В любом случае, ваша проблема, если это высокая средняя нагрузка, заключается в IOwait, поскольку 33,1% - это значение iowait, указанное top. % usr и% sys не так уж и много, поэтому мы можем спокойно игнорировать тот факт, что процессы выходят из строя, либо процессор не работает, либо есть узкое место с памятью. Проблема, видимо, в iowait. Я в основном работаю с RHEL, поэтому я не уверен на 100% в Ubuntu и в наличии встроенных инструментов.

В основном я собираю несколько итераций top, vmstat в течение некоторого времени, iostat в течение некоторого времени (с соответствующими переключателями, которые показывают разрушение устройства), одну итерацию ps и ps -xv и проверяю их. Часто из этого можно сделать первый уровень отладки. Затем я мог бы собрать некоторые выходные данные oprofile, perf в зависимости от версии RHEL, но это уже другая история.

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

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

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

Top не использовал процесс, который потребляет слишком много оперативной памяти или процессора. Но настораживает сервер Лаод и время ожидания процессора. Как и в вашем случае это 33%.

В моем случае проблема оказалась в компании, занимающейся хостингом серверов. Их SAN работала очень медленно в течение нескольких недель, прежде чем они наконец решили сменить хранилище. Только после того, как мой сервер заработал нормально.

У меня был VPS, а не выделенный сервер.

У меня была аналогичная проблема с настольной версией Ubuntu 12.04 (она использовалась в качестве сервера (не мой выбор)).

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

Unity dm вызывал у меня постоянно повышенную нагрузку на процессор, и я мгновенно отключил vsync, и это исправило. Я не знаю, вызывают ли эту проблему и другие DM.