У меня есть сервер с 8 отсеками для дисков, заполненными дисками по 3 ТБ. При использовании 4-х зеркальных виртуальных машин по 2 диска на каждом, это дает мне 12 ТБ избыточного хранилища.
Вот в чем проблема - я где-то читал, что мне нужно «x ГБ ОЗУ на каждый ТБ извлеченных данных» (перефразируя). Я глупо принял это за то, что если мой пул содержит в основном данные, которые нельзя дедупить, он не будет использовать много оперативной памяти. К моему разочарованию, похоже, что под «дедуплированными данными» он имел в виду все данные в пуле, для которых дедупликация была включена.
В результате моя система недавно начала блокироваться, предположительно из-за нехватки оперативной памяти, и ее необходимо было сбросить. Когда я осознал свою ошибку, я подумал, что могу исправить ее, создав новый набор данных с отключенной дедупликацией, скопировав все мои данные в новый набор данных, а затем уничтожив старый набор данных. К счастью, я заполнил только 35% своего пула. Прежде чем пытаться это сделать, я отключил дедупликацию для всех своих наборов данных.
К сожалению, каждый раз, когда я пытаюсь удалить что-то из старого набора данных, все 16 потоков в моей системе переходят на 100%, и все 24 ГБ оперативной памяти внезапно заполняются (я вижу это через htop) тогда моя система зависает.
Есть ли способ выкарабкаться из этой ямы, не разрушив весь бассейн и не начав заново?
На самом деле я понял это самостоятельно, просто возясь. Моя система автоматически монтировала тома ZFS во время загрузки. Если бы я загрузил свою систему нормально, она зависла бы во время загрузки с текстом «Выполняется задание запуска для монтирования наборов данных ZFS ...» или что-то в этом роде. Если бы я загрузился в режиме восстановления, он загрузился бы нормально и получил бы подсказку, но ZFS будет молча пытаться смонтировать мои наборы данных в фоновом режиме, в конечном итоге блокируя мою машину через 10-15 минут. Кроме того, это запретило мне вносить какие-либо изменения в мой пул.
Я обошел это, отключив задачу systemd zfs-mount.service и перезагрузка в режиме восстановления. Теперь я мог выборочно монтировать наборы данных и вносить изменения в свой пул, не блокируя машину.
Но я все еще не решил свою проблему. Несмотря на то, что я отключил дедупликацию, скопировал все данные из моего дедуплицированного набора данных в новый и удалил старый набор данных, у меня все еще есть огромный DDT:
dedup: DDT entries 29022001, size 975 on disk, 315 in core
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 27.7M 2.78T 2.78T 2.78T 27.7M 2.78T 2.78T 2.78T
2 1.65K 191M 191M 191M 3.30K 382M 382M 383M
4 71 4.27M 4.27M 4.39M 310 19.4M 19.4M 19.8M
8 132 16.3M 16.3M 16.3M 1.18K 149M 149M 149M
16 3 32.5K 32.5K 36K 51 537K 537K 600K
4K 1 16K 16K 16K 6.61K 106M 106M 106M
128K 1 128K 128K 128K 146K 18.3G 18.3G 18.3G
Total 27.7M 2.78T 2.78T 2.78T 27.8M 2.80T 2.80T 2.80T
Однако, поскольку я выяснил, что такое "нехватка ОЗУ", я буду считать эту проблему решенной и, если необходимо, позже опубликую новый вопрос.
Быстрое редактирование: Мой ДДТ сокращается, и притом довольно быстро. Возможно, в свое время он сморщится и исчезнет. Мы увидим.
Еще одно быстрое редактирование: Потрясающие! ДДТ сокращался все быстрее и быстрее, пока наконец команда zpool status -D tank возвращается dedup: no DDT entries.