load average per process logging

Доброго времени суток.
Знаю что тема лишена смысла, т.к. load average высчитывается для системы в целом, однако по отдельным процессам есть информация, исходя из которой он высчитывается (косвенно) - /proc/
/schedstat
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 программы, например что-то типа:

* app-admin/apachetop
* app-admin/ngxtop
* dev-db/innotop
* dev-db/mtop
* dev-db/mytop
* dev-db/pg_top
* dev-ml/utop
* dev-ros/rqt_top
* net-analyzer/jnettop
* net-analyzer/nettop
* net-analyzer/ntop
* net-dns/dnstop
* net-firewall/pftop
* net-proxy/hatop
* sys-process/atop
* sys-process/iotop
* sys-process/latencytop
* sys-process/tiptop
* sys-process/unixtop

Также можно использовать аудиторские программы (типа 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% - кто виновник без бубна не разобраться.

Еще раз:

NFS_Daemon написал(а):
не имеет смысла для отдельного процесса, т.к. все они конкурируют за одни и те же ресурсы

имеет - процессы разных звеньев выполняются на разных серверах, но на этих же серверах есть и другие приложения, так что глобально load average смотреть там нет смысла (не чистый он будет).

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

NFS_Daemon написал(а):
про *top утилиты знаю, далеко не все из списка использую и видел, но суть понял - мне не подойдет, потому как *top показывают на текущий момент,

Вот именно! Ты имеешь реальное использование ресурса процессом!

NFS_Daemon написал(а):
а нанять целый отдел для 24/7 слежения за нагрузкой, как-то это ну не правильно что ли.

Для этого существуют скрипты! :)

NFS_Daemon написал(а):
по поводу audit - не понял как его могу использовать для нужных мне целей (отслеживать системные вызовы это да, но только cpu - не /dev/ устройство, приложение его не открывает когда начинает выполняться и не закрывает когда стает на паузу).

Аудиторские системы позволяют контролировать и операции ВВ также, и я говорил, что это не просто.

NFS_Daemon написал(а):
aide - контроль взлома, тоже не понял как может быть полезен для выявления перегруженности системы.

Опечатка! :( не все вытер из списка.

NFS_Daemon написал(а):
к тому же, в шапке не описал (додумал уже позже) - cpu не единственная проблема, дисковую подсистему тоже нужно отслеживать, а с ней не все так интуитивно как с процессором, например, одна утилита может последовательно читать файл с hdd со скоростью 100 Мб/с, тогда как если две одновременно захотят сделать то же самое суммарная скорость будет ниже 100, знаю что это зависит от многих факторов (кэш, фрагментация, приоритеты, и т.д.), но суть от этого не изменяется: по iotop'у я буду видеть что наблюдаемая утилита читает со скоростью 1 Мб/с, но будет это означать что она сама читает с такой скоростью (и ей не нужно быстрее), либо она может быстрее, но система так же обрабатывает и другие приложения и не может дать её большую скорость. В iotop есть колонка IO>, но что с неё толку? - когда нагрузка на hdd превышает его возможности, у почти всех утилит, которые с ним начинают работать значение этой колонки подскакивает до 99% - кто виновник без бубна не разобраться.

А никто и не говорит, что есть одна кнопка "сделать хорошо"! :) Оптимизация ресурсов всегда есть не детерминированный, а вероятностно-оценочный процесс.

Могу больше сказать, в оценки/анализ надо бы еще добавлять и стоимость ресурсов, а также не забыть и o стоимости самого процесса оптимизации! :D

SysA написал(а): NFS_Daemon

SysA написал(а):
NFS_Daemon написал(а):
не имеет смысла для отдельного процесса, т.к. все они конкурируют за одни и те же ресурсы

имеет - процессы разных звеньев выполняются на разных серверах, но на этих же серверах есть и другие приложения, так что глобально load average смотреть там нет смысла (не чистый он будет).

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

Хорошо, не имеет, но определив процессы, которые 100% (или около того) времени выполняются и забирают под себя весь процессор (это при условии что на серверах будут только эти процессы, в моем случае это не так), можно будет понять что нужно выделить дополнительное "железо" именно под эти процессы (распараллелить нагрузку можно в любом звене).

SysA написал(а):
NFS_Daemon написал(а):
а нанять целый отдел для 24/7 слежения за нагрузкой, как-то это ну не правильно что ли.

Для этого существуют скрипты! :)

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

вспомнил об atop, точнее что он умеет работать как демон (сохранять периодически информацию о процессах), попробую использовать его, хотя это все-равно не то, что искал.

Что бы понять, какие процессы

Что бы понять, какие процессы основные потребители процессора, нужно не load average, а соотношение между временем с запуска процесса и временем его работы (cpu time).
Все очень сильно зависит от характера нагрузки, если она долговременная, то load average хорошее начало (что бы поймать момент и увидеть проблему в живую), все равно на первой итерации дело не завершиться )
И все параметры, которые захочется увидеть при анализе в логи не запишешь

Записать можно все, только

Вообще-то я говорил о *top-типа программах, не о load average.
А записать можно все, только это требует времени, конечно.
Весь процесс тонкой настройки всегда интерактивен, но в конце-концов приводит к приемлемому результату, как правило.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".