Вопросы Теги

как отсортировать «зависание» ввода-вывода диска Linux в масштабе всей системы

У меня есть ящик, который периодически "выходит на обед". Симптомы - это все, что требует фактического зависания ввода-вывода диска на 30+ секунд, и кажется, что все, что уже загружено, не затронуто. Проблема возникает периодически, до нескольких раз в час), и до сих пор не была связана с какой-либо запущенной программой или поведением пользователя.Повторное отображение коробки сейчас было бы большим нарушением, поэтому я надеюсь изолировать проблему и, надеюсь, доказать, что в этом нет необходимости. Система Ubuntu 20.04 с btrfs-on-luks nvme root fs.

описания пользователей + анализ журнала ( dmesg и journalctl ) не показывают никакого поведения, связанного с проблемой, кроме сообщений, связанных с тайм-аутом io через 10 секунд, которые явно кажутся быть симптомы / последствия. Коробка использовалась (без каких-либо обнаруженных случаев этой проблемы) в течение ~ 6 месяцев с ubuntu 20.04, прежде чем была повторно отображена несколько месяцев назад, поэтому у меня есть эти незначительные данные о том, что проблема не в hw. btrfs scrub и bios smart не сообщают об ошибках.

с использованием iotop -o live во время воспроизведения я вижу, что фактическая пропускная способность диска падает до ~ нуля за исключением пары потоков ядра [kworker /.* events-power -fficient ] .

Пожалуйста, порекомендуйте следующие шаги для сортировки / определения причины зависания ввода-вывода.

интеллектуальный вывод в соответствии с запросом: 

#> smartctl -a /dev/nvme0n1` as requested:
[...]
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        33 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    4,339,623 [2.22 TB]
Data Units Written:                 7,525,333 [3.85 TB]
Host Read Commands:                 23,147,319
Host Write Commands:                69,696,108
Controller Busy Time:               1,028
Power Cycles:                       98
Power On Hours:                     3,996
Unsafe Shutdowns:                   25
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0

Error Information (NVMe Log 0x01, max 256 entries)
No Errors Logged

с использованием netdata в соответствии с рекомендациями @anx, я приближаюсь: следующий симптом в памяти ядра кажется на 100% коррелированным с воспроизведением во всех случаях, которые я вижу. В течение ~ 1 минуты невозвратная память, выделенная ядром, удваивается . Пока все это распределяется, все операции ввода-вывода зависают. Когда память освобождается, ввод-вывод разблокируется во время спада. Центральный пик / удвоение очень стабильны, меньшие пики до и после немного различаются.

kernel memory usages doubles in a spike, than returns to normal at same rate

Кроме того, это поведение происходит с (прерывистой) почасовой частотой: enter image description here

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

3
задан 22 January 2021 в 17:13
1 ответ

Шаблоны (, когда происходит ухудшение?) И коррелированные метрики (резко ли падает / увеличивается какая-либо другая метрика во время ухудшения?) Часто являются самым быстрым путем к идентификация триггера .

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

Шаги сортировки:

  1. Используйте такой инструмент, как netdata , чтобы визуально определять шаблоны и / или коррелированные показатели. Что-то происходит с метриками производительности при возникновении проблемы? Наиболее полезные из них могут появиться раньше , чем снижение производительности - проблема, которую вы видите, вполне может быть на этапе восстановления некорректного поведения какого-либо драйвера или программы.
  2. Если вы не можете определить триггер и, следовательно, не воспроизвести его намеренно, вы все равно можете определить способ определения, когда проблема возникнет снова (например, при следующей записи большого диска, каждый день 12:00, ..)
  3. задача расписания, которая гарантирует получение снимка (или одного снимка каждые X единиц времени) соответствующего состояния системы во время события (например, top или даже echo t> / proc / sysrq-trigger; dmesg ).Запустите запланированное задание вручную хотя бы один раз, чтобы его зависимости были кэшированы

Идеи для общих объяснений:

  1. неправильная конфигурация подкачки или файл подкачки на каком-то неподходящем стеке блочного устройства
  2. плохой жесткий диск, не обязательно тот содержащую корневую файловую систему
  3. , некоторые оставленные задачи отладки, такие как удаление кешей в cronjob
  4. базе данных, которая во время служебных задач потребляет невероятную память или обращается к огромному каталогу
  5. Обрезка SSD ( отбрасывать ]) или его отсутствие в сочетании с огромными объемами записи, заставляющими систему ждать завершения диска
0
ответ дан 23 April 2021 в 23:59

Теги

Похожие вопросы