Как увеличить размер диска lvm на proxmox ve proxmox

ВНИМАНИЕ!!!

Всем, кто решит использовать BTRFS + lvmcache на хосте ProxMox нужно помнить следующее:

lvmcache НЕ совместим с различными вариантами hibernate. Если вы попытаетесь выполнить pm-hibernate на хосте кешированными томами, то никакого hibernate не произойдет. Система просто перезагрузится, а данные на дисках будут повреждены. Я пробывал.
использование BTRFS с флагом nodatacow (то есть отключение Copy-On-Write) наверное, немного поднимет производительность, но взамен сделает и без того не самую надежную файловую систему абсолютно неремонтопригодной. Отключится весь функционал, обеспечивающий надежность хранения (CoW и контрольные суммы). В результате, при повреждения файловой системы даже btrfs check использовать не получится (по причине отсутствия ctree).

Оптимизация Apache.

Самая лучшая оптимизация Apache — это использовать что-то полегче, чем Apache . Но известность и популярность Апача немаловажные вещи. Решено поставить именно его, но настроить его под низкие требования малочисленных администраторов.

У нас не высоконагруженный проект, а сайт с вебмордами админок. В общем, параметры такие:

StartServers 1
MinSpareServers 1
MaxSpareServers 2
MaxClients 5
MaxRequestsPerChild 300

StartServers определяет количество процессов сервера, запускаемых изначально, сразу после его старта. MinSpareServers и MaxSpareServers определяют минимальное и максимальное количество дочерних «запасных» процессов Apache. Такие процессы находятся в состоянии ожидания входящих запросов и не выгружаются, что даёт возможность ускорить реакцию сервера на новые запросы. MaxClients определяет максимальное количество параллельных запросов, одновременно обрабатываемых сервером. Когда количество одновременных соединений превысит это количество, новые соединения будут поставлены в очередь на обработку. MaxClients определяет максимально-допустимое число дочерних процессов Apache, запущенных одновременно. MaxRequestsPerChild определяет количество запросов, которое должен обработать дочерний процесс Apache, прежде чем завершить своё существование. Когда обработанных запросов станет больше MaxRequestsPerChild, то дочерний процесс будет перезапущен и это помогает при возможных утечках кривых скриптов.

Связано нитью рассуждений:Proxmox VE.Решения в плане безопасности внедрены во все версии Ubuntu и делают её безопасной и надёжной.Ускорение Убунту.

Дата последней правки: 2013-05-27 07:52:12

Советы IBM по вопросам работы памяти.

IBM считает, и наверное не безосновательно, что для бо́льшой производительности нужно отключить zone_reclaim_mode и выставить swappiness=0.

NUMA (Non-Uniform Memory Access — неравномерный доступ к памяти или Non-Uniform Memory Architecture — Архитектура с неравномерной памятью) — схема реализации компьютерной памяти, используемая в мультипроцессорных системах, когда время доступа к памяти определяется её расположением по отношению к процессору.

Оборудование большинства операционных систем — это системы NUMA, со своей штрафом-платой (NUMA penalty) при удалённом доступе к памяти.

NUMA penalty = CPI_remote / CPI_local , где CPI — cycles per instruction.

Если NUMA penalty становится высокой, то операционная система осуществляет очистку (zone reclaim).

Для примера, операционная система выделяет память в ноде NUMA, но нода NUMA полна. В таком случае, операционная система начинает очистку памяти локальной ноды NUMA, а не выделяет немедленно память на удалённой ноде NUMA. Выигрыш в выделении памяти на локальной ноде перевешивает недостаток скорости при очистке памяти (reclaiming memory).

Однако, в некоторых ситуациях очистка памяти (reclaiming memory) снижает производительность до такой степени, что верно и обратное. Иными словами, выделение памяти на удалённой ноде NUMA будет быстрее, чем очищение памяти на локальной ноде.

Гостевые операционные системы могут вызывать zone reclaim в следующих случаях:

гостевая операционная система использует гигантские страницы (huge pages).
используется Kernel SamePage Merging (KSM) для слияния одинаковых страниц памяти гостевых операционных систем.

Настройка huge pages, использование KSM и отключение zone reclaim эти шаги IBM считает хорошей практикой при использовании виртуализации KVM.

zone_reclaim_mode.

Для отключения zone_reclaim_mode на KVM хосте, нужно убедиться в текущем состоянии дел.

Моя Proxmox VE нода выдала 0 и значит разработчики Proxmox VE уже решили нашу задачу. Если у вас не ноль, то в /etc/sysctl.conf нужно указать vm.zone_reclaim_mode=0 и рестарт.

swappiness.

Дефолтное значение swappiness = 60. Можно выставить от 0 до 100. Когда выставлен swappiness = 0 на системах Intel Nehalem, то менеджер виртуальной памяти удаляет страничный кеш (page cache) и кеш буфера (buffer cache), а не скидывает программу из памяти в swap.

Платформа Intel Nehalem использует расширенные таблицы страниц Extended Page Table (EPT). EPT не устанавливает бит доступа к страницам, которые используются гостевыми операционными системами. Таким образом, менеджер виртуальной памяти Linux не может использовать свой алгоритм LRU (least recently used), чтобы точно определить какие страницы не нужны. Точнее сказать, алгоритм LRU не может точно определить какие страницы в гостевых операционных системах являются лучшими кандидатами на вытеснение в swap. В это ситуации, во избежание ненужного своппинга лучше выставить swappiness=0.

Системы с процессорами Advanced Micro Devices (AMD) и с технологией Nested Page Table (NPT) не имеют описанной выше проблемы.

Узнайте текущее значение

Для KVM хоста в /etc/sysctl.conf нужно указать vm.swappiness=0.

huge pages.

Приложения, которые используют много непрерывных участков памяти, получат максимальную выгоду от huge pages, поскольку будет генерироваться меньше промахов Translation Lookaside Buffer (TLB).

Процессор чаще находит нужное отображение в TLB и реже сканирует таблицу страниц.

Таким образом, huge pages увеличивает производительность приложений, которые используют большие и непрерывные участки памяти.

Приложения, которые используют маленькие и непрерывные блоки памяти, не получат от huge pages выгоды.

Huge pages нужно настраивать в ручную и знать необходимость приложения в огромных блоках памяти. По этой причине, пока не стал связываться с ними.

Ext4.

Я выбрал всё таки файловую систему ext4, хотя многие тесты упорно рекомендуют ext3. Журналирование в файловых системах, естественно, не прибавляет скорости в I/O, но с ним можно разобраться, а сама ext4, помимо журнала, тоже получила множество улучшений и жаль было бы их терять. Ведь Google не зря перешёл с ext3 на ext4 без журнала!

К этому времени мне уже было известно о благотворном влиянии отключения шлагбаумов barrier=0 (или nobarrier). Это давным давно было описано у меня в .

Что за шлагбаумы? Код файловой системы обязан перед созданием записи фиксации быть абсолютно уверенным, что вся информация о транзакции помещена в журнал. Просто делать запись в правильном порядке недостаточно; современные диски имеют кэш большого объёма и меняют порядок записи для оптимизации производительности. Поэтому файловая система обязана явно сообщить диску о необходимости записать все журнальные данные на носитель перед созданием записи фиксации; если сначала будет создана запись фиксации, журнал может быть повреждён. Блокирующая система ввода-вывода ядра предоставляет такую возможность благодаря использованию механизма ?»шлагбаумов» (barriers); проще говоря, «шлагбаум» запрещает запись любых блоков, посланных после него, до того момента, как всё, что было прислано перед «шлагбаумом», будет перенесено на носитель. При использовании «шлагбаумов» файловая система может гарантировать, что всё, что находится на диске, целостно в любой момент времени. Отключая шлагбаум barrier=0, мы ускоряем операции записи на разделы ext4.

В одной из англоязычных статей, её автор приводил тесты для файловых систем для MySQL сервера и с barrier=0 ext4 была не хуже ext3.

Кроме barrier=0, добавлены такие опции как relatime и commit=600.
relatime — атрибут времени доступа (atime) обновляется, но только в том случае, если изменились данные файла (атрибут mtime) или его статус (атрибут ctime).
commit – время между сбросами буферов на диск.

Естественно, такие манипуляции проводятся, так как точно будет использоваться источник бесперебойного питания. То есть UPS это один из ускоряющих элементов сервера.

Создание кешированного тома LVM

Пример конфигурации такой.
два диска — /dev/vdb (SSD) и /dev/vdc (HDD).
Создаем физичесике тома и группу томов test:

pvcreate /dev/vdb
pvcreate /dev/vdc
vgcreate vgname /dev/vdb /dev/vdc

Создаем том с кешем на SSD:

lvcreate --type cache-pool -L1G -n cache vgname /dev/vdb

Создаем том с данными:

lvcreate -L9G -n data vgname /dev/vdc

И теперь собираем конструкцию:

lvconvert --type cache --cachepool vgname/cache vgname/data
Do you want wipe existing metadata of cache pool volume test/cache? [y/n]: y
Logical volume vgname/data is now cached.

Отсоединить кеш от тома можно командой:

lvconvert --splitcache vgname/data

Состояние тома можно поглядеть командой:

dmsetup -v status vgname/data

Тип кеша можно поменять командами:

lvchange --cachemode writeback vgname/data
lvchange --cachemode writethrough vgname/data

Получение информации от гостевой системы.

Для передачи информации из гостевой системы на хост можно воспользоваться virtio-serial механизмом. Подробней про него можно прочитать тут и тут. Для совсем тестового примера работы с памятью воспользуемся каналом (pipe) между гостем и хостом. Связь схематично показана на рисунке ниже.

Для создания подобного virtio интерфейса необходимо создать два fifo файла и прописать необходимые параметры qemu

# mkfifo mon.in # mkfifo mon.out # mkfifo mem_pipe.in # mkfifo mem_pipe.out # qemu-kvm -m 3000 -balloon virtio -monitor pipe:mon \        -device virtio-serial \        -chardev pipe,path=mem_pipe,id=our_pipe,nowait \        -device virtserialport,chardev=our_pipe,name=mem \        -drive file=/dev/vg_virt/test_fedora,if=virtio,boot=on

Теперь qemu monitor доступен через файлы mon.in и mon_out, файлы mem_pipe.in и mem_pipe.out служат для сообщений с гостевой системой через созданный канал. На гостевой системе при этом создается устройство /dev/virtio-ports/mem, служащее для приема и передачи сообщений к хост системе.

Чтобы получать информацию о потреблении памяти виртуальной машины в гостевой системе будет работать следующий простейший скрипт (возможности которого можно неограничено расширять)

#!/bin/shMEM_PIPE=/dev/virtio-ports/memif ; then    $0 -- 1> /dev/null 2> /dev/null &exit 0fiwhile read LINE < $MEM_PIPEdo      if ; then        free -m| grep "Mem" | awk '{print $4}' > $MEM_PIPE      fidone

Скрипт выполняет простейшую задачу — при приеме сообщения mem, он отсылает хост системе количество свободной памяти (с учетом «условно свободных» кешей). Простестируем работу скрипта

# echo mem > mem_pipe.in# cat mem_pipe.out100

Полученное значение обозначает количество свободной памяти в Мб. Наконец, можно настроить автоматическую подстройку количества памяти для вирт машины в зависимости от использования. Приведенный ниже скрипт имеет огромное количество недостатков, он предназначен прежде всего для демонстрации возможностей.

#!/bin/shMPIPE_IN=mem_pipe.inMPIPE_OUT=mem_pipe.outMONITOR=mon.outMEM=2000while truedo    echo mem > $MPIPE_IN            # Send request to guest    read FREE_MEM < $MPIPE_OUT      # Receive amount of used memory    sync    # Some logic about $BALLOON_MEM    if ; then        let MEM=$MEM-31    fi    if ; then        let MEM=$MEM+18    fi    echo balloon $MEM > $MONITOR    # Set new balloon value    sleep 1done

Разумеется в реальных задачах логика управления памятью должна опираться на более подробные данные анализа, включая в себя оценки роста потребления памяти и прогнозы дальнейшего использования, но включение этих возможностей принципиально осуществимо уже с имеющимися механизмами. Надо отметить, что доработка патчей для balloon драйвера позволит получать данные о потреблении памяти не из гостевой системы, а напрямую из qemu monitor.