+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Странное время сборки мусора, Proxmox Backup Server

markc

Guest

30.09.2024 11:51:00

У меня запущен Proxmox Backup Server на Terramaster F2-423 с 32 ГБ ОЗУ. В системе стоят два NVMe-диска — один под хост Proxmox VE, другой под хранилище Ceph. Основное хранилище — это два 8 ТБ диска Seagate CRM, настроенные в зеркальном пуле ZFS. Я пробросил их в установку PBS, которая работает внутри LXC-контейнера, и этот пул не используется другими виртуалками или контейнерами. Сейчас я занимаю примерно 56% выделенного хранилища Datastore (2,10 ТБ из 3,76 ТБ).

Основная проблема — процесс Garbage Collection в PBS. Он часто занимает много часов и, кажется, "застревает" на 98–99%. Такое наблюдаю регулярно, последние пару процентов он обрабатывает очень долго. Для диагностики я недавно запустил zpool scrub, который занял около 5 часов 10 минут. После этого запустил Garbage Collection снова — прошло быстрее, чем обычно, но в конце всё равно заметная задержка.

Думаю, это может быть вызвано несколькими факторами: взаимодействием ZFS и PBS, усилением записи из-за copy-on-write в ZFS вместе с дедупликацией PBS, а может, и ограничениями ресурсов на моём Terramaster. Также подозреваю, что по мере роста заполненности может возрастать фрагментация. Использовать NVMe под кэширование не могу, так как эти диски уже заняты, поэтому полагаюсь только на обычные вращающиеся диски для производительности.

Кто-нибудь может объяснить, почему в основном процесс идёт нормально, а вот последние несколько индексных файлов требуют очень много времени на GC? Кто сталкивался с похожими проблемами или может посоветовать, как улучшить ситуацию?

Код:
2024-09-30T17:08:41+10:00: отмечено 90% (234 из 260 индексных файлов)
2024-09-30T17:08:41+10:00: отмечено 91% (237 из 260 индексных файлов) <- 3 файла за 1 секунду
2024-09-30T17:08:42+10:00: отмечено 92% (240 из 260 индексных файлов) <- 3 файла за 1 секунду
2024-09-30T17:08:47+10:00: отмечено 93% (242 из 260 индексных файлов) <- 2 файла за 5 секунд
2024-09-30T17:12:05+10:00: отмечено 94% (245 из 260 индексных файлов) <- 3 файла за 3 минуты 18 секунд
2024-09-30T17:12:05+10:00: отмечено 95% (247 из 260 индексных файлов) <- 2 файла за 0 секунд
2024-09-30T17:12:47+10:00: отмечено 96% (250 из 260 индексных файлов) <- 3 файла за 42 секунды
2024-09-30T17:13:47+10:00: отмечено 97% (253 из 260 индексных файлов) <- 3 файла за 1 минуту
2024-09-30T17:37:25+10:00: отмечено 98% (255 из 260 индексных файлов) <- 2 файла примерно за 21 минуту
2024-09-30T17:51:52+10:00: отмечено 99% (258 из 260 индексных файлов) <- 3 файла примерно за 13 минут
2024-09-30T18:00:22+10:00: отмечено 100% (260 из 260 индексных файлов) <- 2 файла примерно за 9 минут
2024-09-30T18:00:22+10:00: старт второй фазы GC (сбор неиспользуемых чанков)
2024-09-30T18:00:30+10:00: обработано 1% (8813 чанков)
2024-09-30T18:00:37+10:00: обработано 2% (17629 чанков)
2024-09-30T18:00:43+10:00: обработано 3% (26463 чанка)
[...]
2024-09-30T18:20:16+10:00: обработано 98% (855508 чанков)
2024-09-30T18:20:38+10:00: обработано 99% (864290 чанков)
2024-09-30T18:20:59+10:00: удалено мусора: 1,397 ГиБ
2024-09-30T18:20:59+10:00: удалено чанков: 1002
2024-09-30T18:20:59+10:00: исходное использование данных: 14,544 ТиБ
2024-09-30T18:20:59+10:00: использование на диске: 1,899 ТиБ (13,05%)
2024-09-30T18:20:59+10:00: чанков на диске: 871911
2024-09-30T18:20:59+10:00: фактор дедупликации: 7,66
2024-09-30T18:20:59+10:00: средний размер чанка: 2,283 МиБ
2024-09-30T18:20:59+10:00: ЗАДАЧА УСПЕШНО ЗАВЕРШЕНА

Общее время: 3 часа 15 минут 9.3 секунды

Mirmanium

Guest

05.03.2025 07:58:00

В итоге я использую вложенную схему ZFS (Zvol truenas -> iscsi share -> PBS ext4) с 3 дисками по 4 ТБ в RAIDZ1, и теперь GC занимает около 6-8 минут при примерно 2 ТБ записанных данных. EXT4 справляется с вводом-выводом гораздо быстрее, а слой Zvol со снапшотами добавляет дополнительную защиту на случай ошибок. Я всегда проверяю резервные копии, чтобы убедиться, что ext4 не подвел. Знаю, что вложенная схема далека от идеала, но ждать 4-5 часов—это с точки зрения здоровья и ресурса дисков для меня слишком долго.

VictorSTS

Guest

05.03.2025 10:23:00

По моему мнению, с этим замером что-то не так: просто невозможно, чтобы механические диски обеспечивали 8 минут на GC для 2ТБ хранилища, независимо от файловой системы. Может, там какой-то кэш используется? У меня есть хранилища на 2-4 ТБ — либо на одиночных дисках с EXT4, либо на зеркалах ZFS — и у всех чистка занимает намного больше 8 минут.

JensF Guest	#4 0 05.03.2025 11:08:00 Почему бы и нет? Очистка мусора на нашем 600 ГБ хранилище на обычных жёстких дисках (6 штук по 146 ГБ SAS в BTRFS-RAID 0) занимает всего 9 секунд.

fluxX04

Guest

05.03.2025 11:47:00

Время, вероятно, зависит от того, сколько данных резервных копий хранится в хранилище. «Медленное» оффсайт-хранилище на 10x16TB в ZFS RAID-Z2: 27 м 37 с
Код: 2021-08-20T03:27:37+02:00: Использование исходных данных: 58,28 ТиБ
2021-08-20T03:27:37+02:00: Занято на диске: 5,15 ТиБ (8,83%)
2021-08-20T03:27:37+02:00: Число чанков на диске: 2 555 945
2021-08-20T03:27:37+02:00: Коэффициент дедупликации: 11,32
2021-08-20T03:27:37+02:00: Средний размер чанка: 2,11 МиБ

против 1 ч 31 м 54 с
Код: 2025-03-04T12:31:54+01:00: Использование исходных данных: 313,848 ТиБ
2025-03-04T12:31:54+01:00: Занято на диске: 34,846 ТиБ (11,10%)
2025-03-04T12:31:54+01:00: Число чанков на диске: 18 360 872
2025-03-04T12:31:54+01:00: Коэффициент дедупликации: 9,01
2025-03-04T12:31:54+01:00: Средний размер чанка: 1,99 МиБ

Mirmanium Guest	#6 0 05.03.2025 11:51:00 Конечно, объем данных, с которым нужно работать, — ключевой фактор увеличения времени, но я реально боролся с тем, как сократить время GC с 2–4 часов (точно не помню) до всего нескольких минут. В моем случае это удалось, сменив обычную работу с ZFS dataset через SMB-шару на PBS, потом на ZVOL с iSCSI-шарой и вложенную ext4 в PBS. Для офлайн-бэкапов я просто реплицирую верхний слой ZFS на внешний сервер, как только создается ZFS-снимок после бэкапа PBS.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры