Это точно была моя проблема с ZFS на машине PX61. Ограниченное использование оперативной памяти, но она всё равно заполняла всю память и затем просто зависала. Никакого восстановления невозможно было сделать, пока сервер не был принудительно перезагружен. Тогда я решил отказаться от ZFS, так как не могу допустить такого неконтролируемого поведения. Я тестировал на Proxmox 5.1 в то время, когда ещё не выпустили второй ISO.

Мне очень интересно, что стало причиной перезагрузок. Были ли они вызваны каким-то событием? Зависанием процессора? Если в логах нет ничего, возможно, аппаратное обеспечение зависает и перезагружается, так что не успевает даже записывать в логи. Какую файловую систему вы используете? Какой репозиторий PVE?

Как я уже говорил, я ограничил использование оперативной памяти, но это совершенно ничего не изменило.

Спасибо за быстрый ответ. Что касается SWAP: пожалуйста, установите следующее на своем сервере и перезагрузите: "echo 'vm.swapiness=10' >> /etc/sysctl.conf; sysctl -p". У нас была такая же проблема с избыточным использованием SWAP без очевидной причины на наших машинах после обновления до PVE 5.x. После изменения этого значения использование swap снизилось. Я рекомендую использовать ZFS в качестве хранения для ВМ. Создание снимков во время работы ВМ происходит быстрее, и у ZFS есть еще много полезных функций. Мы планируем использовать функцию синхронизации снимков ZFS на резервный узел, чтобы создавать резервные копии каждые 15-30 минут на дополнительном интерфейсе 1Gbit/s. Hetzner устанавливает такие и даже предоставляет дополнительный uplink для них (вам, конечно, понадобится дополнительный публичный IP). Было бы здорово, если бы вы смогли протестировать следующее: (Если хотите, я могу провести эти тесты, если вы предоставите мне доступ к серверу через Hetzner Robot server support access, не к полному роботу!) ```...... RAID 1 ..... PART /boot    ext4   512M PART lvm      pve    48G LV pve root  /                  ext4    10G LV pve root  /var/logs     ext4     5G LV pve root  /mnt            ext4     500M LV pve swap  swap        swap    32G``` - После завершения установки вернитесь к командной строке и создайте еще один раздел на каждом диске/nvme, используя "Linux filesystem" в качестве формата. - Перезагрузите - Установите PVE, убедитесь, что установлены zfs-utils (из PVE, НЕ пакет из Debian) - Перезагрузите - С оставшимся пространством используйте ZFS для создания пула: ```zpool create -f -o ashift=12 zfsnvme1 mirror /dev/<пустой раздел на диске 1> /dev/<пустой раздел на диске 2> zfs set compression=lz4 zfsnvme1 zfs create zfsnvme1/vm-data zfs create zfsnvme1/sources # Ограничение использования RAM ZFS до 16 GB echo "options zfs zfs_arc_max=17179869184" >> /etc/modprobe.d/zfs.conf # Установите минимальное использование до 4GB echo "options zfs zfs_arc_min=4294967296" >> /etc/modprobe.d/zfs.conf``` Хранилище Proxmox: - Затем добавьте "zfsnvme1/vm-data" как хранилище ZFS - Добавьте /zfsnvme1/sources как директорию для ISO, шаблонов и всего, что хотите туда поместить, кроме данных ВМ. Извините за столько тестов. Но я пока не получил одобрение на заказ одного из этих красавцев, чтобы поиграться.

Нет проблем. Но я действительно рекомендую тебе переустановить узел и создать отдельные разделы для логов и mnt (в случае, если ты что-то монтируешь). ``` ...... RAID 1 ..... PART /boot ext4 512M PART lvm pve all LV pve root / ext4 10G LV pve root /var/logs ext4 5G LV pve root /mnt ext4 500M LV pve swap swap swap 32G ``` Затем создай thin-lvm пространство, когда система будет работать. Это быстрее и лучше, чем использовать стандартный plain lvm. ==> Это также экономит место на диске. Ты можешь использовать следующий скрипт для резервного копирования текущей конфигурации и просто восстановить её после изменения структуры диска. https://github.com/DerDanilo/proxmox-stuff Можешь сделать несколько тестов производительности с thin-lvm / ext4 и своими NVME дисками? Перейди, например, в /tmp и запусти следующие команды ``` /usr/bin/time dd if=/dev/zero of=sometestfile bs=4M count=1000 oflag=direct; /usr/bin/time dd if=sometestfile of=/dev/null bs=4M count=1000 oflag=direct; rm sometestfile /usr/bin/time dd if=/dev/zero of=sometestfile bs=128k count=100000 oflag=direct; /usr/bin/time dd if=sometestfile of=/dev/null bs=128k count=100000 oflag=direct; rm sometestfile /usr/bin/time dd if=/dev/zero of=sometestfile bs=1G count=15 oflag=direct; /usr/bin/time dd if=sometestfile of=/dev/null bs=1G count=15 oflag=direct; rm sometestfile ``` Если получишь ошибку с oflag=direct, попробуй oflag=sync. Спасибо!

Эта система имеет 128 ГБ ОЗУ, и по умолчанию, похоже, ограничена 64 ГБ, как видно из спойлера. В прошлый раз, когда система сбоила, потребление памяти было около 57 ГБ, так что я сомневаюсь, что потребление памяти является причиной краха. Никаких подсказок о том, что происходило перед сбоем, в kern.log или в сообщениях нет. Спойлер: ZFS ARC root@epyc1:~# cat /proc/spl/kstat/zfs/arcstats 13 1 0x01 95 4560 2810498817 3383178020078 имя тип данные успешные запросы 4 908845 числовые промахи 4 936288 успешные запросы по требованию 4 798631 промахи по требованию 4 845684 успешные запросы по метаданных 4 17365 промахи по метаданных 4 38324 успешные запросы предварительной выборки 4 77676 промахи по предварительной выборке 4 50904 успешные запросы по метаданным предварительной выборки 4 15173 промахи по метаданным предварительной выборки 4 1376 успехи mru 4 788774 успехи mru_ghost 4 0 успехи mfu 4 28574 успехи mfu_ghost 4 0 удаленные 4 45 пропуски мьютексов 4 0 пропуски выселений 4 1 недостаточно для выселения 4 0 кэшированные выселения l2 4 0 подходящие для выселения l2 4 642560 неподходящие для выселения l2 4 2048 пропуски выселений l2 4 0 элементы хеша 4 732935 максимальные элементы хеша 4 733572 коллизии хеша 4 68687 цепочки хеша 4 14849 максимальная цепочка хеша 4 3 p 4 33766153216 c 4 67532306432 c_min 4 4220769152 c_max 4 67532306432 размер 4 5206345616 сжатый размер 4 4762900480 не сжатый размер 4 6937823232 размер накладных расходов 4 184642560 размер заголовка 4 241655904 размер данных 4 4692599808 размер метаданных 4 254943232 размер dbuf 4 6576432 размер дузла 4 7758400 размер бонуса 4 2811840 размер анонимных 4 9252864 анонимные выселения данных 4 0 анонимные выселения метаданных 4 0 размер mru 4 4635673088 подлежащие выселению данные mru 4 4306005504 подлежащие выселению метаданные mru 4 96033280 размер mru_ghost 4 0 подлеж. выселению данные mru_ghost 4 0 подлежащие выселению метаданные mru_ghost 4 0 размер mfu 4 302617088 подлежащие выселению данные mfu 4 244883968 подлежащие выселению метаданные mfu 4 48320000 размер mfu_ghost 4 0 подлежащие выселению данные mfu_ghost 4 0 подлежащие выселению метаданные mfu_ghost 4 0 успехи l2 4 0 промахи l2 4 0 питание l2 4 0 конфликты l2_rw 4 0 байты чтения l2 4 0 байты записи l2 4 0 отправленные записи l2 4 0 завершенные записи l2 4 0 ошибки записи l2 4 0 повторные попытки записи блокировок l2 4 0 повторные попытки выселения блокировок l2 4 0 выселение чтения l2 4 0 выселение из кэша l2 4 0 освобождение при записи l2 4 0 ошибки низкой памяти l2 4 0 некорректные контрольные суммы l2 4 0 ошибки ввода-вывода l2 4 0 размер l2 4 0 размер l2_asize 4 0 размер заголовка l2 4 0 количество тормозов памяти 4 0 количество прямой памяти 4 0 количество косвенной памяти 4 0 общая память байты 4 135064612864 свободная память байты 4 95257186304 доступная память байты 3 93146804224 arc_no_grow 4 0 arc_tempreserve 4 0 arc_loaned_bytes 4 0 arc_prune 4 0 arc_meta_used 4 513745808 arc_meta_limit 4 50649229824 arc_dnode_limit 4 5064922982 arc_meta_max 4 514542184 arc_meta_min 4 16777216 sync_wait_for_async 4 909 прогноз успешного обращения 4 15185 arc_need_free 4 0 arc_sys_free 4 2110384576 Я сказал Хетцнеру заменить машину, чтобы исключить возможные аппаратные сбои.

Да, у меня тоже так было, но когда я смотрел, как загружается последние несколько %, оно вдруг зависло (UX / SSH), и мне пришлось либо ждать 1-3 часа, пока оно автоматически перезагрузится, либо перезагрузить его принудительно. В любом случае, сразу после восстановления системы использование ОЗУ снова начало расти и не останавливалось, пока память не заполнилась. Этот процесс повторялся по 3-5 раз в день. Причем на сервере не запускалось ничего серьезного. Единственная виртуальная машина — минимальный образ CentOS, который просто висел весь день. Даже без этой ВМ это происходило, просто запол llenar ОЗУ занимало на час больше, но всё равно происходило. Удаление всех машин не решило проблему. Переустановка Proxmox с нуля тоже не помогла, покупка подписки на корпоративный репозиторий и обновление до последней версии проблему не решило. Что бы я ни делал, использование ZFS приводило к непригодной системе, потому что можно было наблюдать, как она медленно умирает весь день. Затем я снова переустановил и выбрал LVM вместо этого. Эта конфигурация теперь работает с 4 ВМ в рабочем режиме уже несколько недель без проблем, с стабильным и логичным использованием ОЗУ, без скачков, без перезагрузок, вообще без ничего. Если сравнить все проблемы с ZFS в общем или в производительности на этом форуме с теми, кто сталкивался с проблемами при использовании LVM или классических настроек ext4, можно сделать вывод, что ZoL не так уж беззаботно и стабильно, как должно быть.