Вопрос или проблема
Моя машина всегда запускается с потреблением всей памяти, кроме 200-500 МБ, и как-то так получается, что активна только одна группа объемов, что и является проблемой. Никакой процесс не указан как использующий значительное количество памяти.
- Это присутствует, когда/если я могу загрузиться в ОС на этой группе объемов.
- Это присутствует, если я загружаюсь с живого ISO.
- Это присутствует, если я заменю планки ОЗУ. Изменение общего объема ОЗУ не изменяет, сколько ОЗУ свободно.
- Я не могу деактивировать группу объемов
vgchange -an VGNAME
, команда зависает бесконечно.pkill -9
не выполняет ничего. Только отключение машины помогает. shutdown now
доходит до задачиpowering off
systemd и затем зависает бесконечно. Только отключение машины помогает.- Отключение любого физического объема группы объемов решает проблему с ОЗУ, потому что это заставляет группу объемов стать неактивной.
- Хотя, как сказано выше, я не могу запустить машину с присутствующими всеми физическими объемами, а затем деактивировать группу объемов.
Моя рабочая теория на данный момент заключается в том, что система LVM находится в плохом состоянии, которое потребляет почти всю мою память, а ядро резервирует минимальное количество. Последнее изменение LVM, которое я смог успешно запустить, заключалось в удалении большого (1 ТБ) кеша LVM из логического объема. Этот процесс занимал вечность, и именно тогда я заметил увеличивающееся использование памяти. Я не мог остановить процесс и пришлось выключить систему (пункт 4 выше). Сказав это, я подозревал некую проблему ранее, которую считал кешем lvm, из-за чего я пытался его удалить. Я не знаю, насколько высоким было использование памяти, прежде чем я начал удалять кеш.
Что именно происходит с моей системой и как я могу это исправить? Буду признателен за любые предложения по дальнейшему расследованию. Пожалуйста, помогите.
обновление
Я смог деактивировать все логические объемы в группе объемов, кроме двух. Последние два – это большой объем bigdata
и его кеш, bigcache
, который я пытался удалить ранее. Вот их вывод из lvdisplay
--- Логический объем ---
LV Path /dev/cheez/bigdata
LV Name bigdata
VG Name cheez
LV UUID 8CFDDm-2jCQ-v8r0-uLJZ-ttkh-OiFo-Qb9Xi8
LV Write Access чтение/запись
LV Creation host, time cheez, 2018-04-28 00:54:11 +0000
LV Cache pool name bigcache_cpool
LV Cache origin name bigdata_corig
LV Status доступен
# open 0
LV Size 8.00 TiB
Cache used blocks 99.89%
Cache metadata blocks 1.53%
Cache dirty blocks 100.00%
Cache read hits/misses 69746 / 6529
Cache wrt hits/misses 7366 / 90
Cache demotions 0
Cache promotions 0
Current LE 2097152
Segments 1
Allocation наследование
Read ahead sectors авто
- currently set to 131072
Block device 254:19
--- Логический объем ---
LV Path /dev/cheez/bigcache_cpool_meta0
LV Name bigcache_cpool_meta0
VG Name cheez
LV UUID 8FkoNO-6JvF-bKge-6KOw-qFll-Nbnb-A235Fg
LV Write Access только чтение
LV Creation host, time cheez, 2020-11-04 17:09:53 +0000
LV Status доступен
# open 0
LV Size 28.00 MiB
Current LE 7
Segments 1
Allocation наследование
Read ahead sectors авто
- currently set to 256
Block device 254:22
Ответ или решение
Проблема с высоким потреблением оперативной памяти в LVM Volume Group
Введение
Вы описали ситуацию, в которой ваша система использует почти всю оперативную память из-за активной группы томов (Volume Group, VG) в LVM. Это создает ненужные затруднения как при загрузке ОС, так и при работе с ней. В данной статье мы анализируем причину данной проблемы и предлагаем шаги для ее решения.
Анализ проблемы
Признаки проблемы
- Высокое потребление RAM: По вашим наблюдениям, система всегда загружает почти всю доступную оперативную память, оставляя всего 200-500 Мб свободной.
- Блокировка команд: Команды
vgchange -an
иshutdown now
не работают должным образом, зависая в процессе выполнения. - Физические изменения: Категорически, проблема исчезает только при отключении физических томов, что указывает на прямую зависимость между состоянием VG и использованием памяти.
- Кэширование LVM: Вы упомянули, что пытались удалить кэш (1 Тб) из логического тома и наблюдали за увеличением использования памяти в процессе.
Возможные причины
Судя по всему, отображаемое поведение связано с проблемой в системе LVM, возможно, произошел сбой в кэше логического тома. Кэш в LVM, когда он заполнен, может увеличивать потребление ресурсов, и любые проблемы с кэшированием могут приводить к утечкам памяти или блокировкам.
Шаги для диагностики
-
Проверка состояния LVM: Используйте
lvscan
,lvs
, иpvs
для диагностики состояния логических и физических томов. Возможно, вы увидите неактивные или поврежденные тома. -
Логи системы: Проверьте системные логи через
dmesg
иjournalctl
на предмет ошибок, связанных с LVM и ошибками кэширования, которые могли произойти при последнем изменении. -
Мониторинг ресурсов: Используйте инструменты, такие как
top
илиhtop
, для контроля за использование процессов и анализируйте, какие модули могут потреблять ресурсы. Следует обратить внимание на процессы, связанные сlvm2
иudev
.
Решение проблемы
-
Отключение кэша: Существует возможность активного использования команды
lvchange --set-attr 'cache=off' /dev/cheez/bigdata
, чтобы отключить кэш для логического тома. Это может помочь в отключении ресурсоемких функций кэширования LVM. -
Ручное восстановление: Если стандартные команды не помогают, попробуйте использовать
lvremove
для удаления кэша, если он вызывает проблемы, и будет безопасно его отключить. -
Использование загрузочного ISO: Если вы все еще не можете деактивировать объем, загрузитесь с live ISO и попробуйте выполнить диагностику и управление LVM через реальный интерфейс без зависания.
-
Проверка файловой системы: Убедитесь, что с файловой системой нет проблем, выполнив проверку через
fsck
. Гарантируйте, что нет повреждений, которые могут также привести к аномальному поведению. -
Обновление системного ПО: Убедитесь, что ваш LVM и ядро операционной системы обновлены до последних версий. Исправления ошибок могут разрешить многие проблемы с управлением памятью.
Заключение
Проблема с высоким потреблением оперативной памяти в вашей LVM Volume Group может возникать из-за ошибки при управлении кэшем или неактивных/поврежденных логических томов. Принимая во внимание ваши наблюдения и описанные шаги, вы сможете диагностировать и решить проблему. Если все методы не помогут, может потребоваться извлечение данных и повторная установка системы, но это крайний шаг. Регулярное резервное копирование ваших томов LVM также поможет избежать подобных ситуаций в будущем.