Обнаружение нагрузки на систему с акцентом на "переброс" в Linux - PullRequest
1 голос
/ 19 июля 2010

Я создал приглашение Bash, которое, когда рабочим каталогом является Git-репозиторий, отображает имя текущего репозитория. Кроме того, он содержит текущую текущую задачу и время, потраченное на ее выполнение (из доморощенного инструмента хронометража). Это, конечно, означает, что просто отображение приглашения означает запуск двух процессов.

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

Итак, сейчас подсказка отключена по умолчанию и включена только по требованию, но это не так удобно. Было бы лучше обнаружить нагрузку в .bashrc и включать запрос только в том случае, если система работает нормально (т.е. с приемлемой задержкой диска).

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

Подсказка: /proc может иметь что-то полезное. Например. /proc/loadavg решил бы мою проблему, если бы узкие места вызывал процессор, а не диск.

Ответы [ 2 ]

2 голосов
/ 19 июля 2010

Самый простой способ - проверить первый байт /proc/loadavg и продолжить, только если это 0

Это будет работать

loadavg=$(</proc/loadavg)
if [ "${loadavg:0:1}" = "0" ]; then echo "all clear"; fi

Но у вас все еще есть test (или [), который может быть запущен, хотя это может быть встроенный bash. edit ^ 2 это встроенный по крайней мере в bash 3.2.39, но я подозреваю, что он был встроен в течение длительного времени. Так что все это может произойти без другого процесса.

edit ^ 3: update, для мелкозернистого контроля:

if [ "${loadavg:0:1}${loadavg:2:2}" -lt "60" ]; then echo "below 0.6"; fi

edit ^ 4: Я не могу представить, что дисковый ввод-вывод является узким местом для рассматриваемой проблемы. Пока вы не пишете, а читаете только из тех мест, которые все равно кэшируются, это проблема чистой памяти / процессора.

edit ^ 5: Конечно, это для случая 1 процессор, умножьте пороговый процент на количество ядер (для процессоров HT, возьмите половину «ядер», чтобы убедиться)

2 голосов
/ 19 июля 2010

vmstat может помочь вам.Если вы не хотите его использовать, вся информация находится на

  • / proc / meminfo
  • / proc / stat
  • / proc / PID / stat
...