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

Улучшить процесс верификации — заменить процессор., Proxmox Backup Server

pszemek

Guest

27.02.2024 11:35:00

Привет, я сейчас занимаюсь оптимизацией процесса проверки резервных копий, и судя по всему, очень большие ВМ (от 4 ТБ и больше) вызывают проблемы. Ниже результаты бенчмарка. Код: # proxmox-backup-client benchmark --repository backup
Загружено 388 чанков за 5 секунд.
Время на запрос: 12978 микросекунд.
Скорость TLS: 323,16 МБ/с
Скорость SHA256: 212,31 МБ/с
Скорость сжатия: 253,78 МБ/с
Скорость распаковки: 320,11 МБ/с
Скорость AES256/GCM: 560,31 МБ/с
Скорость проверки: 132,93 МБ/с

┌───────────────────────────────────┬───────────────────┐
│ Название │ Значение │
╞═══════════════════════════════════╪═══════════════════╡
│ TLS (максимальная скорость загрузки бэкапа) │ 323,16 МБ/с (26%) │
├───────────────────────────────────┼───────────────────┤
│ Скорость вычисления SHA256 │ 212,31 МБ/с (11%) │
├───────────────────────────────────┼───────────────────┤
│ Скорость сжатия ZStd уровня 1 │ 253,78 МБ/с (34%) │
├───────────────────────────────────┼───────────────────┤
│ Скорость распаковки ZStd уровня 1 │ 320,11 МБ/с (27%) │
├───────────────────────────────────┼───────────────────┤
│ Скорость проверки чанков │ 132,93 МБ/с (18%) │
├───────────────────────────────────┼───────────────────┤
│ Скорость шифрования AES256 GCM │ 560,31 МБ/с (15%) │
└───────────────────────────────────┴───────────────────┘

Подскажите, стоит ли мне брать более мощный одноядерный процессор или лучше поискать проблему на стороне ввода-вывода?

Моя конфигурация:
CPU: Intel® Xeon® CPU E5-2650 0 @ 2.00GHz
RAM: 256 ГБ
Хранилище: HW RAID6, 16x16TB + 2x1.8T NVMe для специального устройства на ZFS

pszemek

Guest

12.04.2024 15:17:00

Здравствуйте, мы поменяли процессор на старом сервере, но результат не оправдал ожиданий. Время на проверку резервных копий и копирование данных с виртуализатора на систему бэкапа не сократилось. Нужно менять политику бэкапа и менять сервер для создания резервных копий на «первом уровне». @shanreich, у меня вопрос. Есть ли у тебя какие-нибудь хорошие документы по оптимизации производительности ZFS на SSD/NVMe для PBS? Мы заменили сервер, и хотя время бэкапа значительно уменьшилось, я заметил, что количество IOPS для любых операций не увеличилось.

shanreich

Guest

15.04.2024 09:36:00

Какие SSD/NVMe вы используете и какую схему (RAID10, RAIDZ и т.д.)? Мы рекомендуем использовать RAID10 вместо RAIDZn, так как RAIDZn не увеличивает количество IOPS при добавлении новых дисков. Помимо рекомендаций по раскладке дисков, мы не советуем никаких специфических настроек производительности ZFS — при правильном выборе дисков и схемы размещения производительность ZFS «из коробки» уже очень хорошая. Единственное исключение — если вы используете HDD, тогда можно добавить специальное устройство, но это имеет смысл только для HDD.

tomstephens89

Guest

04.07.2024 22:29:00

У меня тоже плохая производительность резервного копирования, хотя у меня мощное серверное оборудование с all flash хранилищем в аппаратном RAID 10... Думаю, узким местом является проверка чанков. При том, что в моих хостах стоят современные Xeon Platinum....

┌───────────────────────────────────┬────────────────────┐
│ Название │ Значение │
╞═══════════════════════════════════╪════════════════════╡
│ TLS (максимальная скорость загрузки резервной копии) │ не тестировалось │
├───────────────────────────────────┼────────────────────┤
│ Скорость вычисления контрольной суммы SHA256 │ 494.71 MB/s (24%) │
├───────────────────────────────────┼────────────────────┤
│ Скорость сжатия ZStd уровень 1 │ 539.17 MB/s (72%) │
├───────────────────────────────────┼────────────────────┤
│ Скорость распаковки ZStd уровень 1 │ 850.95 MB/s (71%) │
├───────────────────────────────────┼────────────────────┤
│ Скорость проверки чанков │ 305.07 MB/s (40%) │
├───────────────────────────────────┼────────────────────┤
│ Скорость шифрования AES256 GCM │ 1715.09 MB/s (47%)│
└───────────────────────────────────┴────────────────────┘

https://forum.proxmox.com/threads/pbs-performance-improvements-enterprise-all-flash.150514/

fabian Guest	#5 0 05.07.2024 10:02:00 https://lists.proxmox.com/pipermail/pbs-devel/2024-April/009162.html и последующая работа по настройке большего параллелизма могут улучшить ситуацию там.

tomstephens89 Guest	#6 0 05.07.2024 10:12:00 Интересно, но это, похоже, касается только PBS на уровне хранилища данных для проверки «jobs». А не процесса проверки контрольных сумм чанков, который происходит во время резервного копирования на хосте.

fabian

Guest

05.07.2024 10:35:00

да — отсюда и «и последующая работа». Мы внутри обсуждали, как убрать «узкие места» в системах, где большее распараллеливание действительно улучшило бы производительность (потому что для большинства железа, на котором запускается PBS, будет наоборот — слишком большое распараллеливание вызывает нехватку ресурсов, и всё начинает работать медленнее).

tomstephens89 Guest	#8 0 05.07.2024 10:46:00 Ну, это хорошо слышать, буду держать ситуацию под контролем.

lucius_the Guest	#9 0 14.03.2024 02:37:00 Мне было бы интересно увидеть результаты теста pbs после переконфигурации вашего хранилища на исключительно ZFS. Не могли бы вы, пожалуйста, выложить их, когда это будет готово?

Читают тему

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