Вопрос или проблема
Я заметил, что несколько процессов, включая Acronis, MySQL, Java-приложения и Journal D, часто переходят в состояние D. Это состояние, похоже, связано с пейджингом, в частности с асинхронными сбоями страниц KVM.
Вот соответствующий трассировщик стека потока:
Стек потока:
[<0>] kvm_async_pf_task_wait_schedule+0x15c/0x1a0
[<0>] __kvm_handle_async_pf+0x4c/0x90
[<0>] do_page_fault+0x7b/0x12d
[<0>] page_fault+0x1e/0x30
Виртуальным гостям выделено фиксированное количество памяти, и в каждом госте доступно больше чем достаточно памяти (нет перерасхода). Кэширование диска в настоящее время настроено на writeback, но я рассматриваю возможность переключения на writethrough как более безопасный вариант, хотя не уверен, решит ли это проблему.
Кто-нибудь сталкивался с аналогичными проблемами или может предложить потенциальные причины этих сбоев, связанных с пейджингом?
Ответ или решение
Вопрос о частом нахождении процессов в состоянии D (зависание) в таких приложениях, как Acronis, MySQL, Java и Journal D, является серьезной проблемой, связанной с производительностью виртуализированных сред. Основная причина, которая может быть в этом случае, – это асинхронные faults страниц KVM (Kernel-based Virtual Machine). Рассмотрим подробнее данную проблему и предложим возможные решения.
Фоновые Знания
Состояние D (uninterruptible sleep, "непрерываемый сон") обозначает, что процесс находится в ожидании операций ввода-вывода, которые не могут быть завершены в данный момент. Когда процессы, такие как Acronis, MySQL и Java приложения, начинают часто входить в это состояние, это обычно указывает на задержки, вызванные неэффективной обработкой запросов к памяти или диску.
Стек вызовов
Из предоставленного вами стека вызовов видно, что процессы обращаются к операции обработки асинхронных faults страниц:
Thread Stack:
[<0>] kvm_async_pf_task_wait_schedule+0x15c/0x1a0
[<0>] __kvm_handle_async_pf+0x4c/0x90
[<0>] do_page_fault+0x7b/0x12d
[<0>] page_fault+0x1e/0x30Это указывает на то, что процесс активно ожидает завершения операции обработки faults страниц, что может быть вызвано различными причинами.
Возможные Причины
-
Недостаток Доступной Памяти: Хотя вы отметили, что доступной памяти достаточно и нет перегрузки по памяти, важно убедиться, что каждая виртуальная машина имеет достаточно ресурсов для обработки потока запросов. Проверьте настройки, чтобы убедиться, что память не фрагментирована и доступные страницы действительно могут быть выделены.
-
Производительность хранилища: Ваша настройка кеширования диска (writeback) может оказывать влияние на скорость обработки ввода-вывода. При использовании writeback данные сначала записываются в кеш, и только потом на диск, что может привести к возникновению задержек при больших объемах операций I/O. Рассмотрите возможность изменения режима кеширования на writethrough, который обеспечивает более надежный, но менее производительный способ обработки данных.
-
Параметры KVM и настройки виртуализации: Проверьте настройки, параметры производительности и политику управления ресурсами KVM. Убедитесь, что виртуальные машины не сталкиваются с конкуренцией за ресурсы хоста. Возможно, стоит задействовать более агрессивные параметры управления ресурсами, такие как cgroups или настройки I/O приоритета.
-
Задержки в сетевой подсистеме: Если ваши приложения активно используют сетевые ресурсы, убедитесь, что сетевые интерфейсы виртуальных машин должным образом настроены и не ограничивают пропускную способность. Проверьте наличие ошибок на сетевых интерфейсах и их конфигурацию.
-
Обновления и совместимость: Убедитесь, что используемые вами версии KVM, ядра Linux и приложений обновлены до последних стабильных версий, так как многие оптимизации работают на основе исправлений и новых функций, выпущенных в обновлениях.
Заключение
Частое попадание процессов в состояние D может быть вызвано множеством факторов, начиная от конфигураций хранилищ и памятей до настроек виртуализации. Необходимо провести комплексное мониторинг и анализ ситуации для выявления корневых причин проблемы. Рекомендуется использовать инструменты мониторинга, такие как top, htop, iotop, и vmstat, для получения более детального представления о состоянии системных ресурсов.
Также важно наблюдать за поведением приложений в новых конфигурациях. Если переключение режима кеширования на writethrough не даст ожидаемого результата, следует рассмотреть другие аспекты архитектуры решений виртуализации, которые могут влиять на производительность системы в целом.