Comments 14
Еще полезная ncdu
и она есть почти везде в репозиториях.
и она есть почти везде в репозиториях.
+4
Не совсем в тему, но ещё есть pg_activity, можно посмотреть, какой конкретно sql-запрос грузит дисковую подсистему в БД Postgres.
0
duf просто ужасен.
за остальное спасибо
за остальное спасибо
0
Пользуюсь nmon. Неплох для меня.
+1
Пример в статье
watch -n 5 iostat
неверный. Так как согласно мануалу
The first report generated by the iostat command provides statistics concerning the time since the system was booted, unless the -y option is used (in this case, this first report is omitted)
Но и просто опции -y недостаточно. Нужна следующая конструкция
watch -n 5 iostat -y 1 1
тогда отображаемые данные будут соответствовать "правильному" выводу через
iostat 5
0
UFO just landed and posted this here
А где наблюдение за S.M.A.R.T.?
-1
И ни один из представленных тулзов не показывает достаточно важные метрики — backlog (время ожидания запросов в очереди) или среднее время выполнения операций.
0
В htop, который часто ставится по умолчанию, можно в настройках добавить колонку с i/o rate
0
полезно, неделю назад исследовал почему диски не спят в домашнем nas, как раз бы пригодилась статья)
0
А как же без этого: sudo fatrace
0
Использую:
Также atop делает снимок каждые 10 минут (легко поменять на раз в минуту), что позволяет днём, запустив команду «atop -r имя_лога» и проматывая время вперёд-назад с помощью клавиш «t/T» понять, что конкретно происходило ночью, какие процессы (или группы процессов) и в какой последовательности создали ситуацию приведшую к тормозам/падению.
atop -p -DЭто позволяет легко понять что именно «жрёт диск». Опция "-p" группирует процессы по имени, что позволяет видеть суммарную нагрузку на диск всеми процессами php, а не каждым по отдельности и потом мысленно суммировать.
Также atop делает снимок каждые 10 минут (легко поменять на раз в минуту), что позволяет днём, запустив команду «atop -r имя_лога» и проматывая время вперёд-назад с помощью клавиш «t/T» понять, что конкретно происходило ночью, какие процессы (или группы процессов) и в какой последовательности создали ситуацию приведшую к тормозам/падению.
+2
Sign up to leave a comment.
Кунг-фу стиля Linux: мониторинг дисковой подсистемы