load average per process logging
Доброго времени суток.
Знаю что тема лишена смысла, т.к. load average высчитывается для системы в целом, однако по отдельным процессам есть информация, исходя из которой он высчитывается (косвенно) - /proc/
link
/proc/
/schedstat
----------------
schedstats also adds a new /proc/
/schedstat file to include some of
the same information on a per-process level. There are three fields in
this file correlating for that process to:
1) time spent on the cpu
2) time spent waiting on a runqueue
3) # of timeslices run on this cpu
т.е. второе число - это "время" ожидания процесса в очереди на выполнение.
Вопрос в том как его логгировать?
Пока процесс выполняется все хорошо - можно смотреть за ним, но проверять каждую секунду (и это еще хорошо будет если исследуемый процесс не успеет отработать быстрее, т.е. не попадет в логи) как-то не вариант вообще.
Следить нужно за проприетарными процессами, так что добавить в конец сохранение этого параметра возможности нет.
Знаю об sys-process/acct, но он эту информацию не сохраняет.
В теории мне нужен демон, который будет перехватывать exit вызов и сохранять нужную мне информацию. Перехватывать умеет sys-process/audit, но как сохранить в лог именно этот параметр пока не понял.
А возможно я не там ищу, опишу первоначальную проблему:
1. Есть web портал, который использует postgresql, elasticsearch, redis, memcached, mongo, и еще часть других самописных мелких сервисов.
2. Есть тесты, которые тестируют функциональность этого портала.
часть этих тестов используют selenium, т.е. используют браузеры (на данный момент это chrome и firefox)
3. Есть эти браузеры
Задача стоит ускорить работу этих тестов. Утилита, которая будет выполнять действия выше поможет вычислить звено, процессы которого долго выполняются из-за того, что им не хватает ресурсов, а не из-за того что они ждут ответа от других звеньев этой цепочки (тесты -> браузеры -> web портал -> postgresql,elasticsearch,redis,...). Вычислив узкое горлышко можно будет его расширить, но пока не понятно что расширять, в слепую добавлять сервера для любого звена не очень хочется, т.к. результата может и не быть.
Буду признателен за любую помощь.
- Для комментирования войдите или зарегистрируйтесь
Открой для себя
Открой для себя
app-admin/sysstat
! :)А если серьезно, то это не имеет смысла для отдельного процесса, т.к. все они конкурируют за одни и те же ресурсы: кто первый захватил, тот его и "танцует" - т.е. в один момент времени это может быть один процесс, а в другой момент совершенно иной... Поэтому это и оценивается на системном уровне. Тебе надо найти тех, кто долго не возвращает ресурс(ы) и оптимизировать (приоритеты и пр.).
Чтобы локализовать "пожирателя" можно использовать (в том числе и в пакетном режиме)
*top
программы, например что-то типа:Также можно использовать аудиторские программы (типа
sys-process/audit
,app-forensics/aide
и т.д.) и анализировать их логи на предмет того, кто, как долго и какие использует/удерживает ресурсы. Но это не такая простая задача (сразу не запустишь!), поскольку требует написания кучи правил и пр.не имеет смысла для
имеет - процессы разных звеньев выполняются на разных серверах, но на этих же серверах есть и другие приложения, так что глобально load average смотреть там нет смысла (не чистый он будет).
про *top утилиты знаю, далеко не все из списка использую и видел, но суть понял - мне не подойдет, потому как *top показывают на текущий момент, а нанять целый отдел для 24/7 слежения за нагрузкой, как-то это ну не правильно что ли.
по поводу audit - не понял как его могу использовать для нужных мне целей (отслеживать системные вызовы это да, но только cpu - не /dev/ устройство, приложение его не открывает когда начинает выполняться и не закрывает когда стает на паузу).
aide - контроль взлома, тоже не понял как может быть полезен для выявления перегруженности системы.
к тому же, в шапке не описал (додумал уже позже) - cpu не единственная проблема, дисковую подсистему тоже нужно отслеживать, а с ней не все так интуитивно как с процессором, например, одна утилита может последовательно читать файл с hdd со скоростью 100 Мб/с, тогда как если две одновременно захотят сделать то же самое суммарная скорость будет ниже 100, знаю что это зависит от многих факторов (кэш, фрагментация, приоритеты, и т.д.), но суть от этого не изменяется: по iotop'у я буду видеть что наблюдаемая утилита читает со скоростью 1 Мб/с, но будет это означать что она сама читает с такой скоростью (и ей не нужно быстрее), либо она может быстрее, но система так же обрабатывает и другие приложения и не может дать её большую скорость. В iotop есть колонка IO>, но что с неё толку? - когда нагрузка на hdd превышает его возможности, у почти всех утилит, которые с ним начинают работать значение этой колонки подскакивает до 99% - кто виновник без бубна не разобраться.
Еще раз:
Еще раз: не имеет смысла для отдельного процесса, и неважно на одной машине или на многих. Просто в последнем случае задача разбивается на множество подзадач, которые я описал.
Вот именно! Ты имеешь реальное использование ресурса процессом!
Для этого существуют скрипты! :)
Аудиторские системы позволяют контролировать и операции ВВ также, и я говорил, что это не просто.
Опечатка! :( не все вытер из списка.
А никто и не говорит, что есть одна кнопка "сделать хорошо"! :) Оптимизация ресурсов всегда есть не детерминированный, а вероятностно-оценочный процесс.
Могу больше сказать, в оценки/анализ надо бы еще добавлять и стоимость ресурсов, а также не забыть и o стоимости самого процесса оптимизации! :D
SysA написал(а): NFS_Daemon
Хорошо, не имеет, но определив процессы, которые 100% (или около того) времени выполняются и забирают под себя весь процессор (это при условии что на серверах будут только эти процессы, в моем случае это не так), можно будет понять что нужно выделить дополнительное "железо" именно под эти процессы (распараллелить нагрузку можно в любом звене).
мне этого не достаточно: система мониторинга не должна сильно нагружать сервер(а) (и мешать основным его задачам), если буду слишком редко снимать показания - нагрузка будет минимальная, но и детализации будет не достаточно, если наоборот часто снимать показания - упадет производительность всего звена.
вспомнил об atop, точнее что он умеет работать как демон (сохранять периодически информацию о процессах), попробую использовать его, хотя это все-равно не то, что искал.
Что бы понять, какие процессы
Что бы понять, какие процессы основные потребители процессора, нужно не load average, а соотношение между временем с запуска процесса и временем его работы (cpu time).
Все очень сильно зависит от характера нагрузки, если она долговременная, то load average хорошее начало (что бы поймать момент и увидеть проблему в живую), все равно на первой итерации дело не завершиться )
И все параметры, которые захочется увидеть при анализе в логи не запишешь
Записать можно все, только
Вообще-то я говорил о
*top
-типа программах, не оload average
.А записать можно все, только это требует времени, конечно.
Весь процесс тонкой настройки всегда интерактивен, но в конце-концов приводит к приемлемому результату, как правило.