Увеличение оперативной памяти proxmox
Данная небольшая заметка посвящена использованию virtio balloon драйвера для "горячего" изменения количества оперативной памяти в гостевых системах. Технология появилась достаточно давно, и использовать её довольно просто, но при этом возникает множество интересных вопросов.
Получение информации от гостевой системы.
Для передачи информации из гостевой системы на хост можно воспользоваться virtio-serial механизмом. Подробней про него можно прочитать тут и тут. Для совсем тестового примера работы с памятью воспользуемся каналом (pipe) между гостем и хостом. Связь схематично показана на рисунке ниже.
Для создания подобного virtio интерфейса необходимо создать два fifo файла и прописать необходимые параметры qemu
Чтобы получать информацию о потреблении памяти виртуальной машины в гостевой системе будет работать следующий простейший скрипт (возможности которого можно неограничено расширять)
Полученное значение обозначает количество свободной памяти в Мб. Наконец, можно настроить автоматическую подстройку количества памяти для вирт машины в зависимости от использования. Приведенный ниже скрипт имеет огромное количество недостатков, он предназначен прежде всего для демонстрации возможностей.
Разумеется в реальных задачах логика управления памятью должна опираться на более подробные данные анализа, включая в себя оценки роста потребления памяти и прогнозы дальнейшего использования, но включение этих возможностей принципиально осуществимо уже с имеющимися механизмами. Надо отметить, что доработка патчей для balloon драйвера позволит получать данные о потреблении памяти не из гостевой системы, а напрямую из qemu monitor.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
zmeister
New Member
I am just starting out with Proxmox / LXC / ZFS. I have tried Proxmox before and loved it, however this time I have a different setup!
Server specs:
16 GB RAM (DDR4)
2x 450GB NVME SSD (ZFS Mirror)
Intel Xeon E3-1230v6 - 4c/8t - 3.5GHz
I am only using one empty LXC container at the moment - it is not using any RAM (30MB). The node reports that 9GB of RAM is used! And only ~500MB in buffers/cache.
Previously on this same (brand new) node I created another 4-5 containers (they are all stopped now) with variable RAM set - allocated over the 16GB of physical RAM I have, however all of those containers were never used as they were empty and they all reported ~20-30MB RAM used.
The question I have is why an empty node has such high RAM usage. I only have 16GB of RAM, so if ZFS is caching some disk accesses then I don't really need it. I have a very fast NVME SSD drive.
Would you please have a look at the below data to see where this RAM is going? I am not technical enough in this configuration.
Please see the attachment with htop memory screenshot.
I thought this is a bit odd as I would expect the node to only be around 1GB in use. Because buffers/cache is only reporting 500MB, I believe the 8.5GB is active memory in use? This means it will not be freed for the containers to use?
If I only have 6GB of workable memory from 16GB physical RAM, it is very cost inefficient for me with this server.
I would really appreciate your help if you could help me pinpoint where exactly this RAM is being used, and whether any optimisations should be made?
Attachments
zmeister
New Member
An addition: after reboot the node is reporting 1.2 GB RAM usage.
I will try to replicate the high RAM usage again.
Anyone have any idea of what might be happening though?
dietmar
Proxmox Staff Member
ZFS uses this as cache. See
Best regards,
Dietmar
Do you already have a Commercial Support Subscription? - If not, Buy now and read the documentation
LnxBil
Famous Member
So in short: Linux caches a lot . with ZFS, the normal free command is not enough, because as @dietmar pointed out, ZFS does things a little differently. The lesson to learn here is that free RAM is always bad and windows reports all buffers and caches as free, so people believe in this "I need free ram" nonsense.
RobFantini
Renowned Member
I like the info on this thread.As usual great advice from pve support and linux bill.
on most nodes we use rpool + have 10 ceph OSD's .
since pve > datacenter > summary can not be used to determine if a node is low on memory, what would you use to determine that?
AND
with a system having just a few containers and plenty of ram:
pve shows memory usage at 90%
htop shows some swap was used:
no kvm's are used
pce memory config:
LnxBil
Famous Member
Normally, you should monitor swap in/out instead of absolute values. Swapping on your PVE host (or any other server) is always bad. To get better performance while swapping, we often use zram to have a first in-RAM compressed swap layer. You should avoid swapping to disk at all costs. You should also monitor your wait times of your CPU.
Otherwise monitor the free space and buffer/cache. The sum should not be lower than approx. 10% of your system, if you use ZFS, you should also monitor your arc max size. We nowadays use influx and grafana to graph all hosts and find bottlenecks over time. It is important to find and then define your baseline. If you're using CEPH and ZFS, you should have more RAM reserved than using other "simpler" filesystems.
RobFantini
Renowned Member
we normally use zram, will recheck that it is installed on all nodes.
I'll look at those tools, we currently use zabbix I'll check if that has something we can use.
also it seems that since Meltdown and Spectre patches to kernel that cpu and memory requirements have increased. the fix for us is to just add ram to pve systems and vm's .
RobFantini
Renowned Member
I checked with 'systemctl status systemd-swap' and zram is working on all systems.
Question: is there a cli tool similar to htop that shows actual free memory available for virtual machines?
LnxBil
Famous Member
Question: is there a cli tool similar to htop that shows actual free memory available for virtual machines?
You mean free inside of your PVE QEMU hosts?
free shows on your host its available space. This is from a big database system which as actually no free space and that is on purpose, but a lot is available if it is demanded (this machine has also 200GB of hugepages, more on that further down):
If Linux needs memory, it takes memory and if there is nothing left (free empty and all possible buffers cleared), not recently used parts get swapped out. There are some tweakable settings like vm.swapiness and vm.min_free_kbytes to define when this happens. You can also monitor /proc/buddyinfo for contiguous memory segments. You can also run out of memory, if there are no contiguous segments left, e.g. you require a contiguous 4 MB block, but there is nothing free, your malloc will also fail despite having GBs of free space. Unfortunately, memory fragmentation is a real thing.
One thing I can suggest (only for the sake of completeness) is to improve this a little bit is to use hugepages (2M instead of 4K pages) for your VMs. If you use hugepages, you can monitor used pages more easily, but you have to decide in advance how many GB of RAM go into this. Performance-wise hugepages are in general approx. at least 10% faster for bigger equipped RAM machines due to less overhead in memory maps and fragmentation. Yet I still don't know what the official status on this is. I did some benchmarks with PVE 3.4 back in the days . but it was a long time ago. The drawback of hugepages is that acclaimed hugepages cannot be used with system application and are reserved or split from the normal memory, so you have some kind of second class memory system, so you can end up with a system that has enough hugepages, but not enough normal pages and you will swap aggressively. This is often a tradeoff between performance and maintainability.
Не вполне стандартные задачи, с которыми мне приходится сталкиваться по работе и способы их решения.
Обзор графического интерфейса
Пользовательский интерфейс Proxmox VE состоит из четырех областей:
Верхняя панель
На ее левой стороне, первое, что вы видите, это логотип Proxmox. Рядом находится версия запущенной Proxmox VE. В строке поиска рядом вы можете искать определенные объекты (виртуальные машины, контейнеры, узлы, . ). Иногда это происходит быстрее, чем выбор объекта в дереве ресурсов.
Справа от строки поиска мы видим идентификатор (имя пользователя). Символ шестеренки - кнопка, открывающая диалоговое окно "Мои настройки". Там вы можете настроить некоторые параметры пользовательского интерфейса на стороне клиента (сбросить сохраненный логин или макет).
Самая правая часть заголовка содержит четыре кнопки:
Мои Настройки
В окне "Мои настройки" можно задать локально сохраняемые настройки. К ним относятся панели мониторинга хранилищ, которые позволяют включать или отключать определенные хранилища для подсчета общего объема, отображаемого в сводке центра обработки данных. Если ни одно хранилище не выбрано, отображается сумма объемов всех хранилищ, так же как и при включении каждого из них.
Под настройками панели мониторинга вы найдете сохраненное имя пользователя и кнопку для его очистки, а также кнопку для сброса ваших настроек GUI к макету по умолчанию.
На правой стороне есть настройки xterm.js. Они содержат следующие параметры:
Дерево Ресурсов
Это главная панель с деревом навигации. В верхней части этого дерева вы можете выбрать некоторые предопределенные представления, которые изменяют структуру дерева ниже. Представление по умолчанию - это представление сервера, в котором отображаются следующие типы объектов:
Датацентр | Содержит настройки кластера (применяются ко всем узлам) |
Узел | Представляет хосты кластера, на них запускаются гостевые системы |
Гость | VM, контейнеры и шаблоны |
Хранилище | Хранилища Данных |
Пул | Для упрощения управления гости могут группироваться в пулы |
Доступны следующие типы представлений:
Панель Журнала
Основная цель панели журнала-показать вам, что в настоящее время происходит в вашем кластере. Такие действия, как создание новой виртуальной машины, выполняются в фоновом режиме, и мы называем такое фоновое задание задачей.
Любой вывод из такой задачи сохраняется в отдельном файле журнала. Вы можете просмотреть этот журнал, просто дважды щелкнув запись журнала задач. Там также можно прервать выполнение задачи.
Панель Содержимого
Датацентр
- Поиск: можно искать что-либо в кластере, это может быть узел, виртуальная машина, контейнер, хранилище или пул.
- Сводка: дает краткий обзор работоспособности кластера.
- Кластер: позволяет создать/присоединиться к кластеру и показывает информацию о присоединении.
- Параметры: можно показать и установить значения по умолчанию, которые применяются в масштабах кластера.
- Хранилище: здесь хранилище можно добавить/настроить/удалить.
- Резервное копирование: доступ к планировщику резервного копирования. Это общие настройки кластера, поэтому для расписания не важно, где находится виртуальная машина/контейнер в вашем кластере.
- Репликация: показывает задания репликации и позволяет создавать новые.
- Разрешения: здесь можно настроить разрешение пользователя и группы, LDAP, MS-AD и двухфакторную аутентификацию.
- HA: управление высокой доступностью в Proxmox VE
- Брандмауэр: на этом уровне брандмауэр Proxmox работает по всему кластеру и делает шаблоны доступными для всего кластера.
- Поддержка: здесь вы получите всю информацию о Вашей подписке на поддержку.
На этом уровне Узлы кластера могут управляться индивидуально.
Гости
Есть два различных типа гостей, и оба могут быть преобразованы в шаблон. Один из них-это виртуальная машина на основе ядра (KVM), а другой-контейнер Linux (LXC). Как правило, навигация одинакова, только некоторые параметры отличаются.
В главном центре управления навигация по виртуальной машине начинается, если виртуальная машина выбрана в левом дереве.
Верхний заголовок содержит важные команды работы виртуальной машины, такие как запуск, выключение, сброс, удаление, перенос, консоль и справка. Некоторые из них имеют скрытые кнопки, такие как Shutdown has Stop, а консоль содержит различные типы консолей SPICE, noVNC и xterm.js.
Справа содержимое изменяется в зависимости от выбранного параметра.
С левой стороны. Все доступные опции перечислены одна под другой.
- Сводка: дает краткий обзор состояния виртуальной машины.
- Консоль: интерактивная консоль для виртуальной машины.
- (KVM)оборудование: показывает и устанавливает оборудование виртуальной машины KVM.
- (LXC)ресурсы: определяет аппаратные возможности LXC.
- (LXC)сеть: параметры сети LXC.
- (LXC)DNS: параметры DNS LXC.
- Опции: все опции для гостей настраиваются здесь.
- История задач: здесь будут показаны все предыдущие задачи от выбранного гостя.
- Монитор (KVM): это интерактивный коммуникационный интерфейс для процесса KVM.
- Резервное копирование: показывает доступные резервные копии из выбранного гостя, а также создает резервную копию.
- Репликация: показывает задания репликации для выбранного гостя и позволяет создавать новые задания.
- Моментальные снимки: управление моментальными снимками виртуальной машины.
- Брандмауэр: управление брандмауэром на уровне виртуальной машины.
- Разрешения: управление пользовательским разрешением для выбранного гостя.
Хранилища
- Сводка: показывает важную информацию о хранилищах, таких как использование, тип, содержание, активный и включен.
- Содержимое: Здесь отображается содержимое сгруппированное по типу.
- Разрешения: управление разрешениями пользователя для этого хранилища.
- Сводка: Показывает описание пула.
- Члены: Здесь будут перечислены все члены этого пула и доступно управление ими.
- Разрешения: управление разрешениями пользователя для этого пула.
22 комментария:
Фантастика. Новая глава - не прошло и недели. Александр, спасибище. А как быть если у меня появляются практические вопросы по проектированию/установке/настройкам/практической работе с Proxmox? Именно практические, ответы на которые, возможно, очевидны практикам, уже работающим с Proxmox продолжительное время? Можно ли завести в блоге некий FAQ для всех и дополнять его периодически?
Ну тогда начну с самых простеньких но для меня как начавшего работать практически с Proxmox c месяц назад пока что безответных. Кстати, опыта работы с Linux у меня тоже нет и потому конечно же наверняка эти вопросы могут быть интересны опять же только таким же как и я, имеющие таковой опыт наверняка уже давным-давно знают на них ответы, но всё же.
1. Насколько интенсивно работает с диском где он сам установлен Proxmox? Может ли он сам быть установлен на промышленного типа DOM-носитель (SATA или USB 2.0) а его логи и конфигурационные файлы вынесены отдельно (если в этом есть смысл)? Оправдана ли будет его установка на SSD? Сейчас у меня он установлен на старый SATA HDD 160 Gb.
2. Как правильно разбивать на разделы диск для установки Proxmox? Нужен ли ему SWAP-раздел и какой именно объём в зависимости от установленной RAM? Имеет ли смысл изначальная установка самого Proxmox сразу на создаваемый непосредственно при инсталляции том ZFS (а инсталлятор такое позволяет сейчас)?
3. Установил NVME диск для размещения дисков виртуальных машин, при подключении нужно выбрать файловую систему для него, xfs или ext4 - что выбрать и почему именно? На что это будет влиять? Какой образ диска виртуальной машины предпочтительнее: raw или qcow2? Как его переносить между хранилищами на одной и той же ноде (нечто вроде миграции по прямому указанию администратора) Почему формат образа диска при переносе может самопроизвольно поменяться (например из raw в qcow2)?
4. Я так понял что после создания пула дисков zfs добавить к ним новые нельзя даже если только для конвертации имеющегося raid-z1 в raid-z2 или raid-z3. А что тогда делают команды add и attach?
Пока хватит вопросов, буду признателен за ответы, Александр!
1. Я для Proxmox использую старые SAS Диски 32/72Gb. Файловая система ZFS - у меня был пост по сравнению производительности FS. В более ранних установках использовал настройки по умолчанию. Есть установки на SSD. Был случай выхода SSD из строя, после которого я начал добавлять в планировщике принудительный трим. Интенсивность использования ресурсов можно смотреть в разделе сводка ноды.
2. Я использую маленькие диски 30-120Gb(SAS или SSD), которые Полностью используются только Proxmox, поэтому разбиваю по умолчанию, на SSD своп выключаю, чтоб не умер, на шпиндельных делаю 1-2Gb(у меня в серверах минимум 96Gb RAM)
3. Для хранилища я использую только ZFS или Ceph, так как мне важна высокая доступность, образы использую raw, какой предпочтительнее не скажу.
4. В пулы диски добавлять можно, некоторые типы пулов можно преобразовывать из одного в другой.
4. На самом деле большинство Ваших вопросов достаточно подробно освещены в руководстве.
Убить разметку помогает dd if=/dev/zero of=/dev/sd[X] bs=1M count=1024
С xfs дела не имел, возможно ваш дитк имеет MBR разметку, а требуется GPT.
Нет, диск изначально был виден как GPT, а я ещё раз принудительно его повторно инициализировал как GPT из GUI Proxmox - это точно.
Про эту команду почитаю и попробую, спасибо!
Спасибо за сверхоперативные ответы, правда мне пока не всё понятно, к примеру как отделить интенсивность работы с диском самого Proxmox для своей работы от работы дисковой подсистемы ноды для виртуальных машин - график-то один на всё (вроде как, нет сейчас перед глазами)!
Так-то у меня в планах как раз и наладить постоянный бекап образов виртуальных машин с накопителя NVME на пул ZFS для их надёжного хранения - тогда можно будет безбоязненно работать с единственным диском NVME зная что пару раз за день он бэкапится и не переживать, но это всё будет описано в следующих главах перевода так что я пока что жду его. Кстати о размерах RAM на сервере - у меня тоже будет 96 Gb - купил и жду когда доставят, к сожалению это максимальный объём для этого сервера (Supermicro X8DTL-iF) - если считать что этот сервер планируется сделать гиперконвергентным и отдавать половину памяти виртуальным машинам то с оставшейся половиной каков объём дисковой подсистемы ZFS возможен для комфортной работы? Влияет ли число дисков на этот показатель? - тут я имею в виду есть ли разница для производительности и потребления памяти между, к примеру, 8 дисками по 2 ТБ или 4 дисками по 4 ТБ?
Советы по улучшению производительности ZFS
ZFS использует много памяти, поэтому лучше всего добавить дополнительную оперативную память, если вы хотите использовать ZFS. Хороший расчет-это 4 ГБ плюс 1 ГБ оперативной памяти для каждого ТБ необработанного дискового пространства.
Привет!
Есть кластер серверов на Proxmox. На них виртуалки, по большей части на Linux, но есть и на Windows (2013, 2019)
Столкнулся с проблемой что скорость обращения к дискам на windows виртуалках - никакая. Не более 40MB/s на запись и 80MB/s на чтение
Пробовал ставить VirtIO драйверы: - стало еще хуже. Скорость записи упала до 8MB/s
Подскажите, какие у вас параметры виртуалок и какие действия делали чтоб скорость дисков нормальной была? А то это, ну ни в какие ворота
Штатная скорость дисков на хосте, после установки была в районе 500 MB/s
Коллеги! Если у вас нет Windows виртуалок - не тратьте мое и свое время.
Мне нужны просто параметры виртуалок и какие драйверы ставили.
Простой 15 комментариев
Владимир, Диски SAS собраны в кластер CEPH.
Но не суть, я проверял на других хостах, там диски виртуалок лежат на обычном LVM - там скорость такая же
2. Ничего не произошло. Как я понял, скорость изначально была такая. Просто раньше не придавали значения, потому что не до нее было. А теперь, когда нагрузка стала расти - обратили внимание.
3. Проверял этим. Запускал на виртуалке непосредственно
Я практически уверен что дело не в хостах и не в том как там диски собраны. И даже не в самих дисках
Скорее всего дело в настройках виртуалок, какие параметры железа на них. А так же какие драйверы установлены
Вот и спросил, какие они у вас, что устанавливали?
Да сколько можно уже говорить то - CEPH это хранилка.
Там в принципе не может быть быстрой записи и чтения, она не для этого сделана.
Она для отказаустойчивости.
awsswa159, Эксперимента ради, перенес диск виртуалки на LVM на хосте и ничего не поменялось. Как было 40MB/s, так и осталось
В то же время hdparm запущенный на самом хосте говорит что скорость на этом LVM 305 MB/s
Получается не в CEPH дело
1 используя CEPH вы сами отказались от скорости тк как он про надеждность и масштабируемость.
2 если у вас LVM тонкий(thin) то тоже там большие проблемы со скоростью изза особеностей хранения метаданных
3 вы так и не ответили про утилизацию(нагрузку на диски) запустите iostat -x3 на гипервизоре и понаблюдайте пару минут
4 может у CEPH сейчас идет скраббинг и ему не до вас и вашей нагрузки ?
5 какая сеть используется для CEPH ? 1G? или 10G?
З.Ы, с виндовс виртуалками не работал только с линукс, для линукс наилучшую скорость из того что у вас есть вы бы получили из рейд 10 на 4 или 8 дисков, с фс ext4 или xfs, вмки хранить в qcow, драйвер виртИО
Владимир, С линукс виртуалками проблем нет. Только что проверил скорость - 221MB/s на чтение
В 5 раз быстрее чем на виндовс.
Потому не вижу смысла делать что вы просите. Не в хосте дело.
Сеть 10 гигабит
Если у вас нет Windows виртуалок - то врядли вы поможете
Владимир, Тестирование делали. Но уже не помню как. И помню что цифры были приятные около 200MB/s на дисках и итп.
Но по прошествии времени не уверен что мы именно в Windows вируталках тестировали.
Ок. Я планирую развернуть чистую виртуалку 2019 сервер и буду подбирать разные параметры железа. Надеюсь найду оптимальный вариант.
Иначе придется все переделывать. Так как с текущими скоростями жить не получится
Тест 1 - тест жесткого диска С:\ в ВМ под упправлением на госте Windows 10. При этом в этом случае Windows установлена на виртуальный жесткий диск SATA, а проще говоря в файл, который базируется на 2.5" SATA SSD Kingston 480GB, вместе с хостом.
Тест 2 - тестирование проброшенного физического жесткого диска SATA HDD WD Red 4TB в ВМ.
никаких Ceph и рейд-массивов. Оба диска подключены к игровой материнке в SATA разъемы. В файле-конфиге ВМ прописаны как SATA-устройства. Драйвера в госте установлены virt-io. Нашел случайно где-то диск с набором дров с сайта то ли Арча, то ли Красной шляпы и вот пользуюсь.
Драйвера в госте установлены virt-io. Нашел случайно где-то диск с набором дров с сайта то ли Арча, то ли Красной шляпы и вот пользуюсь.
Да, Красношляпа сама и разработала VirtIO. Не знаю, в одиночку или с чьим-то ещё участием, но это их проект.
А они точно использовались? В диспетчере устройств должно быть примерно так:
И да, то что написал Виктор, write back очень заметно ускоряет, это точно; discard должен trim'ить SSD (тоже применяю, но лично не исследовал, насколько велико влияние discard).
+ если raid аппаратный обратить внимание на его настройки:
read policy
write policy
IO policy
Disk cache policy
Пользовался windows server 2012R2, т.к. 2016 и 2019 слегка притормаживали.
awsswa159, точно, это больше хранилка под бэкапы, не для ВМ. Если нужно прям быстро быстро), то только локальное хранилище.
Пол года назад собирал кластер Proxmox из трёх серверов на старом железе intel.
Железного рейдмассива нет, софтово-аппаратный не поддерживается. Установил Debian 10, собрал софтовый Raid-1 массив, LVM не стал делать, т.к. 2 диска по 500 ГБ планировал заменить на диски 1 ТБ. LVM - не нужен, т.к. такие вещи решил делать в виртуалках, а хост-систему не ковырять лишний раз, да и для увеличения производительности и отсутствия всякого геморроя. Плюс софтовый Raid-1 на mdraid можно переставить на любое оборудование, т.к. фиг его знает сколько эти старые сервера проживут.
Вообще проксмокс расчитан на использование удаленного файлового хранилища для гибкой миграции ВМ и контейнеров. У меня такое счастье в бюджет не входило.
Далее протестировал работу клиентских ОС:
1. WinXPSP3 - нет дров, не поддерживается, забыли (x32)
2. Win7SP1Pro (0EndOfSupport) - отлично работает, дрова можно и в дистрибутив через susprep засунуть (X64)
3. Windows 10 Enterprise 1803 - идеально (x64)
Вывод: Виртуальный десктоп организовать можно, но пока не нужно)
Естественно в первую очередь тестировались серверные ОС:
1. Openwrt - на 128 МБ оперативки - это чудо, и tor-прокси и маршрутизация - идеально для обхода всякой роскомнадзоровской защиты и организации VPN до квартиры системного администратора. Использовать обязательно, мало гемора, много плюшек.
2. Windows Server 2008 R2 - работает как и Win7, но уже устарел морально как в качестве Контроллера домена, так и в качестве вообще рядового сервера.
3. Windows Server 2012 R2 - идельно по функционалу, производительности и плюшкам
4. Windows Server 2016 - пробовал использовать его под WSUS пару месяцев, очень много жрёт ресурсов, пока сырой, нужны еще обновления для стабильной работы, а их пока нет, как у 2012R2. От WSUS пришлось отказаться и удалить ВМ.
5. Windows Server 2019 - очень сырая и требовательная ОС, а моя цель минимум потребления дискового пространства и ОЗУ, максимум производительности и пользы.
6. Debian 9 - отлично, берём на вооружение.
7. Debian 8 - отлично, берём на вооружение.
8. CentOS 7 - отлично, беру в работу под почтовый сервер.
9. Windows Server 2003R2 - каким то образом в нетрезвом виде мне всё таки удалось установить какие-то драйвера и оптимизировать работу системы, и даже выпустить образ в прод для запуска древних DOS-приложений)).
Вывод: с линуксами проблем нет, Windows2012R2 - идеальный вариант как файлового, так и всего остального.
После трёхмесячного полёта заметил, что проксмокс активно использует swap хост системы, хотя свободной физической ОЗУ больше половины, и, как оказалось, это тоже настраивается.
В общем, после работы с VMWare Vsphere (ESXI) и Hyper-V проксмокс мне показался вообще мечтой сисадмина, а недавно еще и proxmox-бэкапсервер появился.
Чаще всего «слабым звеном» в работе виртуальной машины Windows на Proxmox является дисковая подсистема. Ниже собран несколько советов, которые помогут приблизиться к максимально возможным скоростям.
Здесь собраны советы только по ускорению дисковой подсистемы программными методами. Использование SSD в single или raid — отдельная тема для обсуждения.
Рекомендуется использовать устройства virtio там, где это возможно. Это обеспечит лучшую производительность. К примеру, использование VirtIO Generic Disk Controller по сравнению с эмулируемым IDE -контроллером увеличит последовательную запись в 2 раза. Использование сетевого интерфейса VirtIO увеличит производительность сетевого интерфейса в 3 раза по сравнению с эмулируемой сетевой картой Intel E1000.
Как это использовать?
Использование balloon драйвера - один из основных способов динамического изменения количества оперативной памяти, выделенной виртуальной машине. Необходимо отметить, рассматриваемый механизм не является аналогом memory hot plug, и требует поддержки со стороны ядра операционной системы; для этого для Linux и Windows систем разработаны соответсвующие драйверы. В подавляющем большинстве дистрибутивов Linux поддержка virtio-balloon включена по умолчанию. Скачивание и установка virtio balloon драйверов для Windows описано тут
Для включения ballooning необходимо запускать qemu с опцией -balloon virtio.
Узнать количетво памяти, выделенное для вирт машины можно при помощи команды info balloon в консоли qemu monitor
В гостевой системе (Linux) можно воспользоваться командой free для получения информации об использовании оперативной памяти
Для изменения количества оперативной памяти используется команда balloon
В гостевой системе
Аналогичным образом можно и увеличить размер памяти, но не превышая того предела, который установлен при запуске (параметр -m)
Для Windows систем процесс полностью аналогичен
После урезания памяти
Дисковый контроллер
В качестве SCSI Controller выбираем VirtIO SCSI . Далее качаем ISO -образ vitio-win.iso с последними драйверами, добавляем CD/DVD драйвер для машины. Монтируем скаченный образ. Загружаем ОС и устанавливаем необходимые драйвера. После всех манипуляций должно получиться вот так:
Создание жесткого диска
При создании Hard Disk у виртуальной машины, выбираем SCSI (последний пункт), в не VirtIO Block. VirtIO blk — это предыдущий «этап» развития. Если сервер подключен к надежному источнику бесперебойного питания, то тип кэша ставим в — write back. Если ИБП нет, то покупаем ИБП и ставим Write Back.
Если образы виртуальных машин размещены на SSD , то обязательно ставим галки Discard и SSD emulation, чтобы правильно работала технология TRIM . Эмуляция SSD не поддерживается на дисках VirtIO Block.
Включаем IO thread. Опция IO Thread работает только если в качестве контроллера установлено значение VirtIO SCSI или VirtIO SCSI single. Если этот параметр включен, Proxmox будет создавать один поток ввода-вывода для каждого контроллера хранения, а не один поток для всех операций ввода-вывода. Это позволяет повысить производительность. Особенно виден прирост скорости при использовании нескольких дисков.
Как это работает?
Balloon драйвер создает в ядре специальный процесс, который по команде с хоста может изменять количество потребляемой им памяти. Оставшаяся память может быть использована всеми остальными процессами в гостевой системе для собственных нужд.
Если необходимо уменьшить количество памяти выделяемое машине, то сначала balloon процесс "раздувается" до необходимого размера, а потом позволяет хосту освободить нужное количество памяти
Увеличение количества памяти происходит аналогичным образом.
При таком методе работы количество памяти, используемое вирт машиной, ограничивается общим количеством памяти указанным в параметре -m.
Необходимо отметить, что в текущей реализации balloon драйвер не обращает никакого внимания на количество свободной памяти в системе, поэтому при чрезмерном ограничении в использовании памяти можно легко столкнуться с потерей производительности (хотя бы за счет дисковых кешей) или с полным зивисанием машины. При недостатке памяти операционная система начинает использовать swap, что приводит к активному использованию диска и значительно тормозит работу.
Поэтому для эффективного использования balloon драйвера необходимо каким-то образом получать информацию об реальном использовании памяти в гостевой системе и на основе полученных данных принимать решение об ограничениях. Подобный механизм разрабатывается в настоящий момент. Адам Литке (Adam Litke) Разработал серию патчей для qemu и balloon драйвера, которые позволяют получать дополнительную информацию об использовании памяти. (Делается это при помощи команды info balloon в qemu мониторе.) Последние версии libvirt уже содержат код, который парсит обновленный вывод команды info balloon для получения информации об оперативной памяти гостевой системы. Но по словам Адама пока что эти патчи содержат некоторые проблемы связанные с взаимодействием с qemu, и в настоящее время идет активная работа по их доработке.
Но уже сейчас есть несколько способов получения информации от гостевой системы. Например, можно передавать данные об использовании памяти по сети (разумеется в этом случае сеть должна быть настроена в виртуальной машине). Такой способ используется в проекте MoM. Далее я опишу немного другой способ связи между хост системой и виртуальной машиной, при помощи которого мы сможем управлять balloon драйвером более эффективно.
Особенности
Графический интерфейс пользователя
Поскольку мы используем файловую систему кластера Proxmox (pmxcfs), вы можете подключиться к любому узлу для управления всем кластером. Каждый узел может управлять всем кластером. Нет необходимости в выделенном узле диспетчера.
Вы можете использовать веб-интерфейс администрирования с любым современным браузером. Когда Proxmox VE обнаруживает, что вы подключаетесь с мобильного устройства, вы перенаправляетесь на более простой, сенсорный пользовательский интерфейс.
Формат образа жесткого диска
Используем образы машин только в формате raw. Есть мнение, что qcow2 только немного уступает в скорости raw, но нам важна максимальная скорость. Из минусов использования RAW — нет снапшотов для резервного копирования. Если это критично, то выбираем qcow2. Нужна скорость — выбираем RAW .
Ограничиваем работу swap
Узнаем при каком проценте занятости ОЗУ , наш Proxmox начинает скидывать в swap:
Это стандартное значение. При такой настройке от 40% занятой ОЗУ , начинается заполнение свопа.
Для сервера нужно установить это значение близким к нулю. При нуле область подкачки использоваться вообще не будет. Можно установить это значение в 10, что позволит Proxmox’у использовать до 90% оперативной памяти без задействования механизма своппинга. При загрузке ОЗУ более 90% часть данных будет переносится в swap. Можно поставить это значение и в 5 и в 1.
Чтобы установить это значение, выполняем команду:
Если запустить эту команду без -w , то команда примениться до первой перезагрузки. Удобно для тестов.
Если знаете еще способы увеличения скорости дисковой подсистемы, то прошу оставлять их в комментариях.
Руководство администратора Proxmox VE R 6.0 Глава 5.
понедельник, 11 ноября 2019 г.
Отключение swap в Proxmox
Отключить swap достаточно просто. Узнаем название раздела swap:
В нашем примере это /dev/nvme0n1p3.
Далее отключаем swap:
Эта команда временно отключит swap. Чтобы отключить его навсегда, нужно в /etc/fstab закомментировать строку с его монтированием:
Настраиваем swap в Proxmox
Чтобы добиться максимального быстродействия дисковой подсистемы у сервера Proxmox стоит отключить swap или снизить процент его использования.
Часто на сервере Proxmox можно наблюдать картину:
Это все из-за того, что Debian по умолчанию при использовании более 40% ОЗУ , начинает пользоваться swap. Для рабочей станции с небольшим количеством ОЗУ – это нормально, но для сервера, где оперативной памяти в разы больше этот параметр не совсем подходит.
- отключить swap в Proxmox вообще;
- ограничить процент использования swap в Proxmox.
Читайте также: