У меня есть облачный сервер Rackspace под управлением Ubuntu с 2 ГБ памяти, который используется в качестве сервера приложений (файлы html и php загружаются с этого сервера, а база данных mysql находится на другом сервере в том же центре обработки данных).
Когда количество пользователей моего веб-приложения увеличивается (10000 + / день), нагрузка возрастает до 1,00, а иногда и до 2,00. Логически это имеет смысл, но я не могу понять, откуда взялось узкое место. Используя команду «top», я вижу, что загрузка ЦП почти всегда составляет около 1%, и она использует только около 500 МБ из 2 ГБ общей памяти (почти все для процессов apache). У меня также установлен munin, и похоже, что эти цифры примерно точны для всего дня (нет никаких серьезных скачков ни в одной статистике).
Если проблема не в процессоре или памяти, то что мне следует отслеживать и / или оптимизировать, чтобы подготовиться к большему трафику? (Не знаю, что улучшить, так как не знаю причину нагрузки!)
Спасибо! Пожалуйста, дайте мне знать, если вам нужна другая информация о настройке моего сервера.
В планировщике Linux процессы могут находиться в одном из нескольких состояний. В новых ядрах есть причудливые, но базовые (из include/linux/sched.h):
#define TASK_RUNNING 0
#define TASK_INTERRUPTIBLE 1
#define TASK_UNINTERRUPTIBLE 2
#define TASK_STOPPED 4
Первое должно быть очевидным; последнее - фактически остановленные задачи. Состояние прерывания предназначено для спящих задач. Бесперебойные задачи обычно ожидают системного ресурса, такого как диск или другой ввод-вывод.
Предположительно, поскольку обычно ожидается, что выполнение непрерывных задач будет запланировано очень скоро, они считаются находящимися в очереди выполнения.
И числа loadavg, которые вы видите в /proc/loadavg (И в top и другие инструменты) - это просто средний размер этой очереди выполнения - процессов, ожидающих своего расписания - с интервалом в 1, 5 и 15 минут. Если на самом деле у вас много процессов в TASK_RUNNING, это приведет к увеличению loadavg, но процессы, застрявшие в TASK_UNINTERRUPTIBLE, тоже сделают это. (На самом деле, по моему опыту, это обычно виновник смехотворно высоких значений нагрузки.)
Итак, если вы видите высокую нагрузку без особой загрузки ЦП, вам нужно поискать io. iotop - удобный инструмент для этого. Однако для этого требуется ядро 2.6.20. В старых системах или просто для альтернативного просмотра iostat (из sysstat пакет) и vmstat (из procps) может показать некоторую общую статистику. С другой стороны, если вы используете NFS, застрявший процесс может на самом деле очень мало выполнять реальный io, но все равно застрять. (Ура, NFS.)
Если вы не видите ничего из этого, возможно, что-то не так в инфраструктуре виртуальной машины.
«Нагрузка» происходит не только от загрузки процессора. Это количество процессов, ожидающих ресурсов.
Первое, что вам нужно сделать, это выяснить, оказывает ли это какое-либо влияние на ваше приложение, которое вы обслуживаете. Нагрузка меньше, чем количество имеющихся у вас ЦП, обычно считается хорошей.
Когда вы это видите, что говорит Top о вашем iowait?
Что значит free -m шоу?
Вы также можете посмотреть iostat.
Контролируйте операции дискового ввода-вывода и размеры дисковых операций ввода-вывода.
Это скажет вам
Я не уверен, какой у вас контроль над конфигурацией диска в вашей среде, но похоже, что это ваше узкое место.