Могу ли я различать смену, а также не подкуп высокой задержкой IO как-то?

vmstat— это традиционная команда Linux для отслеживания памяти, подкачки и операций ввода-вывода. Например. vmstat 5будет печатать строку статистики каждые 5 секунд.

atop— это новый, очень мощный инструмент. Запуск atopпохож на top, но содержит гораздо больше информации. Если вам нужен журнал, atop -w <file>вместо этого запишет двоичный журнал, который можно прочитать с помощью atop -r <file>. Пакет atopтакже включает службу для автоматической записи журналов с использованием 10-минутных интервалов (по умолчанию ).

В обновлении:atop2.4.0 добавлена ​​поддержка Linux Информация о остановке под давлением . Я ожидаю, что это поможет обнаружить киоски из-за нехватки памяти. Статистика нехватки памяти (, отображаемая как msили mfв atop), может обнаруживать перегрузку подкачки и без -подкачки. Технически это означает, что это не помогает отличить -своп от свопа :-). Но хотелось бы получить эту информацию. У меня не было много подтверждений, что тряска была моей проблемой... и как выяснилось в обновлении, тряска была на самом деле не главной проблемой.

Что касается основной проблемы, с которой я столкнулся :, я думаю, что собрать информацию о ней сложнее. Существует один общий подход к отслеживанию, который может помочь :offcputime --state 2. Хотя для установки этого инструмента потребовались некоторые усилия.

Предыдущий ответ

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

Журналы службы atopмогут быть очень информативными,если у вас длительная проблема с потреблением памяти. Более короткие проблемы (могут быть пропущены из-за 10-минутного интервала регистрации по умолчанию ).

• Похоже, моя проблема длилась 10 -20 минут.
• Использование подкачки выросло с 1,4 Гб в предыдущем примере до 2 Гб (100 % ).
• Сами потоки qemu-imgне имели большого размера в оперативной памяти. Процесс qemu-imgимел только 25M резидентов.
• swoutбыло 175735. Это измеряется в страницах по 4096 байт, что означает, что было выгружено около 0,7 ГБ.

В то же время cacheвырос с 0,8 Гб до 2,3 Гб. freeпамять осталась на уровне 0,1 ГБ.

Я подозреваю, что qemu -img выполняет кэшированный ввод-вывод, кэш вытесняет другую память, и это вызывает подкачку. Если бы у меня не было места подкачки, я ожидаю, что все равно возникнут проблемы; вместо этого будет удален загруженный программный код и другие кеши.

Если я drop_caches, а затем cp16-гигабайтный файл, я могу вызвать довольно много свопинга. Я думаю, что та же проблема воспроизводится с cp; Я не думаю, что это ограничивается какой-то конкретной деталью qemu-img convert.