Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    Оптимизация использования ЦП во время живой миграции.

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Оптимизация использования ЦП во время живой миграции., Proxmox Виртуальная Среда
     
    Simryc
    Guest
    #1
    0
    01.08.2024 21:40:00
    Привет,
    У нас появилась задача мигрировать машины между узлами, но нужно сделать это быстро. Есть ли возможность оптимизации? Есть ли какие-то волшебные параметры? Похоже, что у нас процессор — узкое место. При начале миграции он использовал весь CPU, из-за чего мы не можем в полной мере загрузить диск и сетевой интерфейс (только 50%), и миграция занимает относительно много времени. У каждого диска VM всего по одному терабайту. Сервер кажется относительно новым, но нам всё равно кажется, что это не оптимально. Нам бы хотелось, чтобы и диски, и сеть были полностью загружены. Что можно сделать, чтобы ускорить процесс? Может, что-то вроде RDMA? Скриншот прилагается.
     
     
     
    velocity08
    Guest
    #2
    0
    04.01.2025 02:23:00
    Всем привет! Подключаюсь к этой теме с той же проблемой. Proxmox - 8.3, последняя версия, 20 ГБ сетевой пропускной способности доступно.

    Когда выполняю прямую миграцию, хост загружается на 100% CPU, дисковая активность бешеная, и это приводит к сбоям или зависаниям VM. Фактически, мы не можем мигрировать на этот хост или с него, не обрушив других клиентов на нем.

    Это нужно срочно решить, если это ошибка, потому что прямая миграция не должна влиять на другие VM на любом исходном или целевом хосте. @Simryc тебе когда-нибудь удалось найти рабочее решение этой проблемы? Или какой-то обходной путь?

    Cheers, G
     
     
     
    UdoB
    Guest
    #3
    0
    04.01.2025 09:23:00
    Да, стабильность намного важнее чистой производительности. У меня нет решения для тебя, но хочу упомянуть возможный обходной путь: можно намеренно ограничить используемую пропускную способность. Это уменьшит общую нагрузку на систему и, возможно, устранит сбои. Посмотри Datacenter --> Options --> Bandwidth Limits. Удачи!
     
     
     
    velocity08
    Guest
    #4
    0
    04.01.2025 09:32:00
    Спасибо, @UdoB. Хорошее предложение, в голову мне это не приходило. Посмотрю, что можно сделать. Моя первоначальная обеспокоенность — высокий уровень нагрузки на процессор. Ты предлагаешь, что ограничение скорости миграционной сети снизит нагрузку на процессор и дисковый ввод-вывод? Я подозреваю, что высокий дисковый ввод-вывод — часть проблемы. Один из нашей команды упомянул, что они видели более 45 ГБ/с ввода-вывода на одном из ВМ перед тем, как они упали. Сами ВМ ничего не делали, это была активность диска хоста, которую видели ВМ. Придется снова спросить у них, чтобы убедиться, что я правильно понял, что они видели. Чёс, G
     
     
     
    UdoB
    Guest
    #5
    0
    04.01.2025 09:44:00
    Да, именно так и задумывалось. Мысленный эксперимент: представь, что пропускная способность ограничена до очень низкого (нерабочего) значения. Это не создаст нагрузки на твою систему, правда? Конечно, ты захочешь протестировать несколько значений с помощью тестовой VM и постепенно увеличивать их, чтобы получить приемлемую скорость, сохраняя стабильность. Этот итеративный процесс оптимизации может быть проблематичным само по себе, ведь можно случайно снова переборщить…
     
     
     
    velocity08
    Guest
    #6
    0
    04.01.2025 12:51:00
    Спасибо за методологию, начну с 50% текущей полосы пропускания и посмотрю, как это пойдет на тестовой виртуальной машине. Ты тестировал с несекретным режимом? Даже в этой ветке мы видим смешанные результаты. Логично, что безопасный режим будет иметь больше накладных расходов, чем несекретный, из-за шифрования/дешифрования "на лету". Но почему мы получаем смешанные результаты при тестировании несекретного режима? Есть какие-нибудь идеи? Чёс.
     
     
     
    UdoB
    Guest
    #7
    0
    04.01.2025 12:56:00
    Нет, извините.
     
     
     
    velocity08
    Guest
    #8
    0
    05.01.2025 13:38:00
    @UdoB, немного поигрался с этим сегодня и ограничил скорость задач репликации. Похоже, это помогло с высоким потреблением ЦП, но при этом сильно замедляет миграцию, особенно если речь идет о ВМ объемом 3+ ТБ или с несколькими дисками по 1 ТБ. Сегодня тестировал репликацию с ВМ, чтобы посмотреть, можно ли это сделать лучше, особенно когда ВМ большая и с кроссплатформенным ЦП, например, Intel > AMD. Оказалось, когда репликация синхронизирована и выполняется живая миграция, в конце делается небольшой снимок, копируются дифференциальные данные ВМ, делается снимок в памяти, копируется, ВМ останавливается на исходном сервере и запускается на целевом. Это позволяет избежать некоторого времени простоя и других проблем, в общем, решил поделиться. Спасибо за совет. ""Cheers G
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

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