Ускорение дисковой подсистемы Qemu KVM в Linux +35







Иногда я берусь за различные задачи по настройке серверов. Некоторое время назад ко мне обратился владелец небольшой хостинговой компании, с интересной проблемой. Он хотел бы на своих серверах, где уже стоял Ubuntu 18.04, запускать виртуальные машины с Windows под KVM.

Однако проведённое им тестирование показало, что дисковая система KVM прилично отставала от показателей, которые у него были под Hyper-V. Он хотел раскочегарить qemu на своих Ubuntu серверах, чтобы избежать закупок дорогих серверных лицензий Windows (бесплатная версия Microsoft Hyper-V Server не устраивала из-за своих ограничений).

0. Диспозиция


Для тестирования использовался SSD Samsung 970 Pro 1TB. Заказчик проверял результаты работы в CrystalDiskMark, поэтому далее в статье все графики из него.

Windows 10 LTSC Hyper-V
2 CPU
KVM
2 CPU
Следовало в первую очередь улучшить производительность случайного ввода/вывода. Именно этот тип нагрузки характерен для виртуальных машин, в особенности тех из них, в которых используются различные БД.

В Ubuntu (16.04 LTS и 18.04) до сих пор используется qemu версии 2.11. Поэтому некоторые плюшки самых последних qemu в этой статье не рассмотрены.

Мы решили что нам нужно избежать привязывания железа к виртуальной машине, так как это осложняет переносимость виртуальных машин, поэтому варианты с прокидыванием SSD/физических дисков/разделов в виртуалки были признанны нежелательными.

О размере тестового файла для CrystalDiskMark
Внимательный читатель может заметить, что использовались разные по размеру области для тестирования от 100МБ до 4ГБ. Дело в том, что размер области очень влияет на время выполнения теста: чем больше область, тем длиннее шёл тест.

Однако, так как каждый раз виртуальная машина запускалась заново, кеш Windows сбрасывался и не оказывал влияние на результаты. Результаты для области 100МБ и 4ГБ отличались в пределах погрешности, но время было в 40 раз больше.

Тестирований за время настройки было проведено огромное количество, чтобы задача не затянулась на месяцы, основная часть испытаний была проведена с областями размером 100МБ-1ГБ. И только решающие испытания были проведены с областями 4ГБ.

1. Используем LVM-тома, а не файлы для хранения дисков виртуальных машин.


Логика такая. Файл с виртуальным диском хранится в файловой системе Linux, внутри самого файла находится NTFS. Каждая файловая система потребляет ресурсы при дисковых операциях. Поэтому чем меньше глубина матрёшки, тем быстрее ввод/вывод.

Если же говорить о файлах qcow2, то их название расшифровывается как «Qemu Copy-On-Write» и, фактически, внутри них есть своя таблица трансляции, которая отвечает за то какие блоки заняты, какие нет и где что находится.

Слой LVM потребляет значительно меньше процессорных ресурсов, чем файловая система. Одна из причин этого то, что блоки в нём значительно больше, чем типичный блок файловой системы (4КБ). Чем больше блок (extent) на физическом устройстве LVM, тем более быстро происходит IO и тем меньше фрагментация.

А ведь даже для SSD случайный ввод/вывод значительно медленнее, чем последовательный. Поэтому при создании Volume Group мы укажем очень большую величину extent: 256MB.

Read ahead на логическом томе стоит отключить, так как он расходует IO без выигрыша, так как теперь никто не занимается дефрагментацией дисков в Windows на SSD.

LVM довольно удобно использовать для хостинга виртуальных машин. LVM-тома легко переносимы между физическими дисками, есть снимки (snapshot), изменение размера в режиме онлайн. Тем более, что virt-manager (libvirt) умеет из коробки создавать логические тома под диски виртуальных машин из Volume group (группы томов).

Привлекательной выглядит также возможность создать thin volumes («тонкие» тома), но если учесть, что тонкий том — это дополнительный слой абстракции, то, очевидно, что он будет ухудшать производительность IO. К тому же в libvirt нет элегантного пути автоматического создания дисков для виртуальных машин в «тонком» пуле.

# Инициализируем физический раздел SSD для группы томов (volume group)
pvcreate /dev/nvme1n1p1

# Создаёт группу том win с размером блока (extent) 256МБ.
vgcreate -s 256M win_pool /dev/nvme1n1p1

# Создаём логический том vm1. Подойдёт для диска C
lvcreate -n vm1 -L 100G win_pool

# Отключаем упреждающее кеширование при чтении (read ahead)
lvchange -r none /dev/win_pool/vm1

1.1. Thin volume как диск и/или настройки логических томов для снимков


Если вы хотите использовать thin pool, в котором будете создавать тонкие тома, то имеет смысл установить размер чанка у пула в 4МБ, что значительно больше размера по-умолчанию в 64КБ.
Что повлечёт более быструю работу этого слоя абстракции.

Механизм снимков в LVM работает практически на том же самом коде, что и тонкие тома, поэтому для увеличения скорости снимков (snapshot) настройки будут теми же самыми.

lvcreate -c 4m -L 300G -T -Zn win_pool/thin

Опция -Zn отключает перезапись чанка нулями при выделении, что повышает скорость работы.

Настройки для lvm.conf или подобного файла (например lvmlocal.conf):

thin_pool_chunk_size = 4096
thin_pool_zero = n

Вы можете сами определить оптимальный размер чанка выполнив тестирование следующей командой, подобрав величину --blocksize:

fio --name=randwrite --filename=/dev/nvme0n1p9 --size=10G --ioengine=libaio --iodepth=1 --buffered=0 --direct=1 --rw=randwrite --blocksize=4m

Посмотреть текущий размер чанка можно командой:

lvs -ao name,chunksize

2. Увеличение количества логических процессоров, выделяемых на каждую виртуальную машину KVM, улучшает дисковую производительность


10 CPU 8 CPU 4 CPU

Понятно, что вряд ли кто будет выделять на виртуалку 10 процессоров, но было интересно посмотреть на крайний случай.

Тут уже зависит от числа свободных процессоров. На мой взгляд больше 4-х выделять нецелесообразно. При числе потоков равному 8 мы получили максимальную производительность случайного чтения и записи. Это специфика CrystalDiskMark 6.0.2, в котором второй тест проводит 8-ю потоками.

Из чего можно сделать вывод, что хорошо иметь по одному логическому процессору на каждую задачу, активно использующую IO.

3. Используем огромные страницы оперативной памяти (hugepages), чтобы избежать снижения производительности из-за фрагментации RAM


Этот пакет может пригодиться, когда нам понадобится различная информация о hugepages в процессе эксплуатации.

apt install hugepages

Правим /etc/default/grub:

GRUB_CMDLINE_LINUX="default_hugepagesz=1GB hugepagesz=1G hugepages=64"

В данном случае было выделено 64ГБ памяти для всех виртуальных машин в виде hugepages. В вашем случае может быть меньше/больше.

Применяем эти настройки для GRUB, чтобы при следующей загрузке системы они стали активны:

grub-mkconfig -o /boot/grub/grub.cfg

Редактируем конфиг виртуальной машины:

virsh edit vm_name

Добавляем:

<memoryBacking>
  <hugepages/>
</memoryBacking>

4. Добавляем в каждую виртуальную машину выделенный поток для обслуживания IO


Нужно добавить то, что выделено жирным. Используем virsh, как и в предыдущем пункте.

<iothreads>1</iothreads>

<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none' io='threads' iothread='1'/>
<source dev='/dev/win/terminal'/>
<target dev='vda' bus='virtio'/>
<boot order='2'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</disk>


4.1. Для ускорения случайной записи используем кеширование writeback


Для ускорения случайной записи на диск, но с увеличением риска потери данных, можно использовать cache=writeback в предыдущем пункте. Можно использовать только если есть большая уверенность в качестве и резервировании питания и при наличии бэкапов.

5. Настройки дисковой подсистемы в В Virt Manager


Disk bus: VirtIO
Storage format: raw
Cache mode: writeback
IO mode: threads

5.1. Настройка дисковой подсистемы через конфигурационный файл


Qemu 2.11 (который сейчас используется в Ubuntu) поддерживает два типа дисковых виртуальных устройств: virtio-blk и virtio-scsi. Когда в Virt Manager указывается Disk bus: VirtIO — это означает использование устройства virtio-blk.

Во всех случаях по скорости лучше virtio-blk, несмотря на то что в тестируемой версии qemu он ещё не поддерживал TRIM в отличии от virtio-scsi (с версии 5.x уже поддерживает).

С точки зрения скорости дискового IO virtio-scsi имеет смысл использовать лишь в экзотических случаях, например, когда нужно подключать сотни дисков к виртуальной машине.

6. В процессе инсталляции Windows устанавливаем драйвер VirtIO


Иначе диск не будет доступен для ОС. Для этого используем образ с драйверами, который предварительно подключаем к виртуальной машине.

7. Результаты после применения всех твиков


На самом деле твик 4.1 не был применён, так как я не был уверен в надёжности питания у клиента.
Hyper-V
2 CPU
KVM
2 CPU
KVM
4 CPU

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

KVM из коробки
2 CPU
KVM после твиков
2 CPU

Мы видим, что удалось существенно ускорить работу дисковой подсистемы в qemu (kvm) при одном и том же числе ядер. Запись была ускорена в среднем на 58%, а чтение на 25%.

Основные элементы успеха: использование LVM-томов вместо файлов qcow2, отдельный поток ввода/вывода и hugepages.

Замеченные ошибки направляйте в личку. Повышаю за это карму.

P.S. vhost-user-blk и vhost-user-nvme


В ходе экспериментов были также и скомпилированы Qemu 2.12 и 3-й версии. Тестировалась опция vhost-user-blk для диска.

В итоге она работала хуже, чем virtio-blk.

vhost-user-blk
4 CPU
virtio-blk
4 CPU

Для использования vhost-user-nvme нужно было патчить qemu, этот вариант усложнял автоматическое обновление серверов в продакшене, поэтому не был протестирован.

P.P.S. SPDK


Intel разработала этот фреймворк для достижения выдающихся показателей производительности у дисковых систем в виртуальных машинах, которые должны работать на её процессорах.

Чтобы заставить spdk хорошо работать идут на массу ухищрений — выделяют ему отдельные ядра, размещают ядра spdk и виртуальной машины в одном сокете. Загружают виртуальную машину в непрерывный кусок памяти. Если такие меры применять к обычному virtio-blk, то он тоже будет быстрее работать.

SPDK способен работать в 3-х режимах: vhost-user-scsi, vhost-user-blk и vhost-user-nvme. Второй режим доступен только в qemu от 2.12, который ещё не доступен в ubuntu. Режим vhost-user-nvme вообще мегаэкспериментальный — для него нужно патчить qemu. На текущий момент работает только эмуляция scsi и она медленная.

Есть ещё одно серьёзное ограничение для режима vhost-user-scsi — диск spdk не может быть загрузочным.
Make sure bootindex=2 Qemu option is given to vhost-user-scsi-pci device.
Рекорды ставятся, когда они с помощью своего драйвера разделяют SSD на несколько устройств и прокидывают их как vhost-user-nvme. Подход с прокидыванием железа нам не подходил.

Сложилось впечатление, что нормально использовать SPDK можно только с их реализацией логических дисков (которая совершенно отличается от стандартных lvm). Это такой самопальный велосипед со своими снимками и клонированием. Команды все отличаются от LVM.

Сложность в настройке SPDK, поддержке и переносимости виртуальных машин, а также привязанность к процессорам Intel отвернула от его использования.

Благодарности


За изображение спасибо TripletConcept. Его лучше смотреть в полном размере в отдельном окне.

За разрешение поделиться рабочими материалами — st_neon




Вы можете заказать виртуальную машину с SSD у RUVDS по купону ниже.



Замеченные ошибки направляйте в личку. Повышаю за это карму.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (99):

  1. Silnur
    /#21426616

    чтобы избежать закупок дорогих серверных лицензий Windows.

    Так вроде Microsoft Hyper-V Server бесплатен.

    • inetstar
      /#21426630

      Он ставится на голое железо и управляется из консоли, что было неудобно для заказчика. В в составе Windows Server с ролью Hyper-V нужно платить за сам Windows Server.

      • Silnur
        /#21426640

        Мне кажется вы путаете Windows Server с ролью Hyper-V и Microsoft Hyper-V Server.

      • Hardened
        /#21427612 / +1

        "Он хотел бы на своих серверах, где уже стоял Ubuntu 18.04, запускать виртуальные машины с Windows под KVM."


        "Он хотел раскочегарить qemu на своих Ubuntu серверах, чтобы избежать закупок дорогих серверных лицензий Windows Server"


        Я вас поздравляю — нарушает правила лицензирования Microsoft. Чтобы иметь право использовать Windows Server в гостевой системе должен быть корректно отлицензирован хост. И не важно, какой гипервизор используется…

        • edo1h
          /#21427828

          … и сколько ядер доступно виртуалке — лицензировать надо все физические.

        • inetstar
          /#21427850 / +1

          Я вас поздравляю — нарушает правила лицензирования Microsoft.

          А меня за что? Я только настраивал сервер.

          Чтобы иметь право использовать Windows Server в гостевой системе должен быть корректно отлицензирован хост.

          Кстати, в гостевых системах использовалась Windows 10 Pro, а не Server.

          • NoOne
            /#21428472

            Для клиентский Windows в среде виртуализации требуется Software Assurance или отдельные лицензии VDA

            • Hardened
              /#21429410

              Все сложнее. Multitenant Hosting десктопной Windows требует отдельной авторизации от Microsoft. В России я только РТК знаю с такой

              • navion
                /#21430238

                Это разве не про сдачу в аренду? А то получается, что VDI у всех развёрнут незаконно.

                • Hardened
                  /#21436426

                  Multitenant Hosting Rights for Windows 10
                  Customers who buy Windows Per User licenses through Microsoft Volume Licensing will need to engage with an Authorized QMTH Partner to make use of their multitenant hosting rights for Windows 10 to host their Windows virtual machines on third-party multitenant hardware.

                  In addition, a customer who buys qualifying Windows 10 subscriptions with virtualization use rights via Microsoft Cloud Agreement subscription will need to engage with an Authorized QMTH Partner to make use of their multitenant hosting rights for Windows 10.

                  Customers do not need to engage an Authorized QMTH Partner for the following scenarios for qualifying Windows 10 products:

                  • Microsoft Azure environment
                  • Customers with on-premise dedicated use rights

                  www.microsoft.com/en-us/CloudandHosting/licensing_sca.aspx

            • Hardened
              /#21436324

              Это если компания на собственной инфраструктуре делает виртуализацию рабочих столов. С переносом к хостерам все несколько сложнее.

          • P6i
            /#21433690

            Товарищу майору будите рассказывать, что вы, только, настраивали сервер

        • Loggus66
          /#21431262 / +1

          Хост лицензирован корректно, согласно условиям GNU GPL, не так ли?

          • Hardened
            /#21436476

            Гостевой Windows Server лицензируется по физическому хосту. Если на хост не назначены лицензии Microsoft в необходимом количестве, то гость Windows Server вы не имеете права использовать.

  2. amarao
    /#21426778 / -1

    Зашёл увидеть совет "включите writeback". Увидел. Ожидаемо.


    Плюс увидел неожиданную ахинею про тормоза файлового бэкэнда из-за "блоков по 4к".

    • Hamer13
      /#21427468

      Так ведь writeback, по итогу, был выключен. И разве использование раздела LVM напрямую не будет быстрее файлов? Лет 6 назад в proxmox переход с qcow2 на raw давал заметный прирост в скорости. Или тут дело именно в qcow2?

      • amarao
        /#21427586

        Вы знаете, всё очень интересно. Во-первых, qcow2 файловый бывает raw и thin. По-умолчанию делается thin, так что вы с большой вероятностью бенчмаркали first write (которая, очевидно, медленнее). raw (который примерный эквивалент обычного тома lvm) имеет производительность мало отличающуюся от производительности голого устройства. Однако, надо учитывать, что файловые системы более тщательно относятся к flush'ам, так что если у вас SSD из г-на и палок, но честные, то флаши их тормозят радикально.


        … Разницу между файловым и блочным выводом, наверное, можно найти на синтетике и очень чувствительных бенчмарках, но точно не на уровне "на глаз видно". А вот разницу между raw и thin видно, особенно, если диски консьюмерского уровня.

        • Hamer13
          /#21427898

          Спасибо за разъяснение. Судя по всему тогда был как раз thin qcow2, тем более что, на сколько я помню, у пары виртуалок были снэпшоты на основе этого же qcow2.
          А производительность LVM vs RAW file я на глаз не измерял. :-) Просто предположил что раз один уровень абстракции убрали, то и какой-то, хоть и незначительный, прирост должен быть. Тем более что у нас в офисном proxmox сервере не SSD вовсе.

          • amarao
            /#21428562

            Файловые операции внутри открытого файла практически такие же по скорости, как и блочное устройство. Вы же когда блочное устройство открываете, у вас всё равно такой же файл. Да, там есть кеширующая подсистема, но делает она хуже или лучше — вопрос открытый. А для фанатов вообще можно сделать O_DIRECT, и тогда её не будет.

        • inetstar
          /#21430618

          Во-первых, qcow2 файловый бывает raw и thin.

          Qcow2 расшифровывается как Qemu Copy-On-write. Он всегда thin.

          Есть просто формат raw, а не «qcow2 raw». Но его мало кто использует по причине непрактичности и огромного занимаемого места.

          И ещё меня интересует кое-что насчёт fallocate. В каких файловых системах достоверно известно, что этот вызов реально ищет самые длинные последовательные участки?

          Если они, конечно, остаются у нагруженного сервера. Я сильно сомневаюсь, что там будет много таких участков.

          Даже если это и так, то всё равно слой ext4, btrfs, xfs файловой системы Linux более ресурсоёмкий, чем слой LVM. Так как в LVM нет ни журналирования, ни B-tree, ни COW при обычной операции записи. А raw файл лежит в обычной ФС и, как минимум, работает журналирование каждой записи.

    • akhkmed
      /#21427984

      Спасибо, зашёл увидеть Ваш комментарий на тему writeback. Прошу пояснить из Вашего опыта, каким способом включать его точно безопасно в qemu с базой данных на виртуалке, а каким — точно не избежать провала.

      • amarao
        /#21428602

        Не бывает безопасного writeback. Writeback — это когда часть данных не пишется, а хранится в памяти. Если память теряется, что-то на диск не сохраняется.


        Дальше есть техники спецпротокола между софтом и дисковым устройством (flush/sync), которая позволяет софту обеспечить сохранность данных в условиях условного про… ба. Чаще всего этот протокол используют СУБД. Однако, это не панацея, потому что результатом про… ба будет удаление всех незавершённых транзакций. Что иногда ОК, а иногда — не очень.

        • akhkmed
          /#21428926

          Спасибо. Из тривиального безопасного writeback я встречал батарейные контроллеры, которые не теряют данные из кэша записи при падении электропитания, а записывают их на флешку за счёт заряда суперконденсатора.
          Возможно ли эту тактику применить для виртуалок, когда flush/sync, инициированные вируалкой не теряются, но запись идёт не напрямую на медленный диск, а на какую-то быструю и безопасную, но небольшую ssd-ку? Не приходилось встречать такие конфигурации?

    • inetstar
      /#21428138

      Производительность qcow2 raw будет хуже в сравнении с правильно настроенным LVM. Детали.

    • snd3r
      /#21428940 / -1

      Еще и все результаты сводятся к манипулированию размером записываемого блока в CrystalMark.


        • snd3r
          /#21429052

          Сколько я пользовался CrystalMark это всегда играло значение:


          • inetstar
            /#21429086 / -1

            Попробуйте после каждого теста перезагружать компьютер. Тогда кеш Windows будет сброшен.

            • snd3r
              /#21429116 / -1

              Кеш чего? Случайных данных которые генерирует CrystalDisk Mark?

              • inetstar
                /#21429148 / -1

                По-умолчанию CrystalDiskMark делает 5 проходов. А потом усредняет результаты. При небольшом размере тестового файла он в итоге целиком загружается в кеш. И скорость вырастает.

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

                Вот и на ваших скриншотах видно, что для небольшой области (100МБ) скорости чтения выше.

                • snd3r
                  /#21429244

                  О том и речь, как можно доверять вашим скриншотам, если там очевидно разные тесты? Вы сами говорите о нерелевантности тестирования небольшим размером файла, при этом статья пестрит именно ими.


                  Я не против вашей методологии "быстрого" тестирования для получения какого-то промежуточного результата, но итоговые тесты, которые стремятся что-то подтвердить, должны проходить в одинаковых условиях.

                  • inetstar
                    /#21429274 / -1

                    Прошу вас, сделайте свои тесты каждый с предварительной перезагрузкой Windows, и давайте посмотрим как это повлияет на результаты.

                    • gecube
                      /#21437788

                      Еще раз — нарушена методика тестирования, следовательно garbage in — garbage out.
                      К Вам же просьба — протестируйте нормально, с одинаковым размером блока. Либо делайте полноценное тестирование (как раньше делали) — в зависимости от размера блока скорость/IOps.

  3. Naves
    /#21426780

    Используем LVM-тома, а не файлы для хранения дисков виртуальных машин.

    Задам странный вопрос, а заказчик готов к такому повороту, что теперь, чтобы скопировать образ диска его любимой виртуалки, нужно использовать непонятные команды вместо простого копирования файла.
    Во всех случаях по скорости лучше virtio-blk. Использовать virtio-scsi имеет смысл в экзотических случаях, например, когда нужно подключать сотни дисков к виртуальной машине.

    Странно, а все говорят про обратное
    pve.proxmox.com/wiki/Qemu/KVM_Virtual_Machines
    Скрытый текст
    If you aim at maximum performance, you can select a SCSI controller of type VirtIO SCSI single which will allow you to select the IO Thread option. When selecting VirtIO SCSI single Qemu will create a new controller for each disk, instead of adding all disks to the same controller.

    The VirtIO Block controller, often just called VirtIO or virtio-blk, is an older type of paravirtualized controller. It has been superseded by the VirtIO SCSI Controller, in terms of features.

    • inetstar
      /#21426868

      По тестам virtio-scsi медленнее. Так как scsi-слой подразумевает выполнение различных scsi-команд, которые снижают скорость.

      Тем более что «IO Thread» есть и у virtio-blk.

  4. edo1h
    /#21426786

    небольшой хостинговой компании

    так


    CrystalDiskMark

    ?!?


    SSD Samsung 970 Pro 1TB

    ?!?!?


    можно использовать cache=writeback в предыдущем пункте. Можно использовать только если есть большая уверенность в качестве и резервировании питания и при наличии бакапов.

    На самом деле твик 4.1 не был применён, так как я не был уверен в надёжности питания у клиента.

    writeback — это дефолтный и как бы не самый безопасный способ (из доки к цефу: Without cache=writeback, QEMU will not send flush requests to librbd; уверен, что и в случаях отличных от librdb аналогично).


    Использовать virtio-scsi имеет смысл в экзотических случаях, например, когда нужно подключать сотни дисков к виртуальной машине

    работающий трим — это экзотический случай?


    удалось существенно ускорить работу дисковой подсистемы

    в статье ни разу не сказано по каким параметрам шла оптимизация. параметры тестирования (размер области) на разных скриншотах разные, 100Мб совсем никуда не годится.

    • inetstar
      /#21426894

      Я же в статье объяснил, что клиент проверял результаты работы в CrystalDiskMark.
      А то что хостеры часто используют не самое дорогое железо типа Oracle F640 — это сплошь и рядом. Иначе им трудно будет обеспечить выгодные цены.

      работающий трим — это экзотический случай?

      Теперь и в virtio-blk есть. Для клиента была важнее всего скорость. virtio-scsi по тестам был значительно медленней.

      в статье ни разу не сказано по каким параметрам шла оптимизация. параметры тестирования (размер области) на разных скриншотах разные, 100Мб совсем никуда не годится.

      Решающие тесты были сделаны на областях размером 4ГБ. Тестов было так много, что часто использовались области по 100МБ потому, что иначе можно было состариться, пока дождёшься результатов.

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

      • gecube
        /#21437792

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

        Влияние кэша нижележащей операционной системы (суть гипервизора) — можете оценить?

        • inetstar
          /#21440516 / -1

          Я не понял вопроса.
          Я не считаю сутью гипервизора кэш нижележащей операционной системы.

          Как я понимаю, CrystalDiskMark резервирует место, а не создаёт случайный файл.
          В противном случае всё чтение было бы некорректным и из кеша.

          А при резервировании места кешируются физические сектора диска в RAM.
          Поэтому (при большом размере RAM) каждый следующий запуск должен давать более хорошие результаты при чтении.

          Во всяком случае у меня так получалось при использовании рейд-контроллера с кешем 4ГБ на машине с 32ГБ RAM.

  5. savostin
    /#21426942
    • inetstar
      /#21431018

      Отличие в предпочтении virtio-blk.

  6. zuborg
    /#21427110

    Использовать релиз конца 2017-го года для достижения максимальной производительности выглядит немного странно…

    Для проброса блочных устройств io=native дает обычно лучший результат, чем io=thread

    Также можно исключить и LVM — пробрасывать сразу GPT-раздел.

    • inetstar
      /#21427354

      Использовать релиз конца 2017-го года для достижения максимальной производительности выглядит немного странно…

      Это специфика Ubuntu. В ней почти не обновляют qemu. Вручную скомпилированный свежий qemu не дал выигрыша тоже.

      Для проброса блочных устройств io=native дает обычно лучший результат, чем io=thread

      Возможно, но проброс был нежелателен. А без проброса native работал хуже.

      Также можно исключить и LVM — пробрасывать сразу GPT-раздел.

      Можно, но тогда всё становится жутко неудобно: ни снимков, ни удобного перемещения на другие физические носители, ни безопасного онлайн-ресайза.

    • equand
      /#21429932

      C NVME можно пробрасывать сразу namespace, что еще круче :). Проброс GPT и ns правда отбирает снепшоты и бекапы соответственно и смену размера

  7. SandmanBrest
    /#21427472

    Может, все-таки, ускорение дисковой подсистемы? Или увеличение производительности?

  8. justhabrauser
    /#21427736

    Основные элементы успеха: использование LVM-томов

    Обязательно томов именно LVM?
    Обыкновенные разделы или даже физические диски — не?

    • inetstar
      /#21427742

      Можно было и их использовать, но это привязка виртуальных машин к железу, которой хотелось бы избежать. LVM-том можно легко перемещать с одного железа на другое, менять размер онлайн, делать снимки. Это ценные возможности.

      • justhabrauser
        /#21427748

        Но это дополнительная матрешка.
        Если сравнивается скорость винды на голом диске со скоростью виртуальной винды на том же голом диске — это было бы действительно честно.

        • inetstar
          /#21427758 / +1

          Цель была поднять производительность qemu, чтобы он работал не хуже, чем Hyper-V. Практическая задача.

          CrystalDiskMark тестирует файл. Поэтому даже в случае голой винды в тестирование вовлекается NTFS. Именно эту программу использовал заказчик для оценки моей работы.

  9. CarrolCox
    /#21428108

    Спасибо, прочёл с удовольствием.


    • lvm thin действительно может дать прирост в сравнении с qcow2 thin, но не в случае qcow2 raw и вовсе не в случае хороших SAS дисков с FastTier на SAS-SSD/NVMe.
    • На мой вкус отличный вариант — использовать iscsi поверх пула блочных устройств — позволит подключать и локально и по сети, управление и бэкапирование не на много сложнее lvm.
      ps: как делают nutanix (не к ночи будут помянуты):
      Для VMware ESXi это NFS-storage, для 2012R2 Hyper-V — storage по протоколу SMB3, а для KVM — iSCSI

    • inetstar
      /#21428118

      qcow2 raw всё равно находится в пространстве ext4, у которой 4КБ блок по-умолчанию, и которая скорее всего будет фрагментирована. Не вижу причин по которым ext4 с размером блока в 4КБ будет быстрее LVM с размером блока в 4МБ (как я советую в статье).

      • CarrolCox
        /#21428182

        Я не говорил об ext4 с блоком в 4КБ на хосте, простите, это вы додумали сами.
        Есть XFS, которая создавалась и развивалась для работы с большими файлами в больших количествах.
        Ну и можно выбросить lvm из-за 'оверхеда' и использовать только btrfs subvolume + nodatacow.


        PS:


        и которая скорее всего будет фрагментирована

        фрагментация ФС в linux based операционках — тема для отдельного холивара, не надо набрасывать.

        • apro
          /#21428200

          Есть XFS,

          А в ней можно создать блок больше размера страницы? Просто 4КБ это ограничения из-за страничного кэша используемого в vfs linux kernel, а xfs как и все файловые системы "подключены" через vfs к ядру.


          https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/xfs/libxfs/xfs_sb.c?h=v5.6-rc7#n356

          • amarao
            /#21428628

            Что такое "блок"? Можно ли записать через vfs больше 4к за раз? Запросто. Берёте и пишите. Возьмите blktrace да посмотрите, какие куски в устройство снизу уходят. 4k важны только для вопросов управления кешом.


            А ещё, внезапно, все SSD отлично умеют делать coalesce, если у них max_queue_depth больше 1.

      • amarao
        /#21428608

        С какой стати qcow2 raw будет фрагментирован, если его создают с помощью fallocate'а? Файловая система видит размер блока и выделяет его полностью, предпочтительнее нефрагментированным образом. Даже если в файле будет несколько фрагментов, на общую производительность это не повлияет, потому что если разрывов в фрагментах мало, они пренебрежимы для современных SSD.


        ЗЫ Несколько лет назад был баг в 3.14, который приводил к тому, что конкурентный доступ к fallocate'нутым данным был очень тормозным. Но это было в 3.14, что актуально только для ценителей копролитов.

        • equand
          /#21429962

          qcow2 и raw медленнее LVM и LVM-Thin, многочисленные тесты подтверждают это.

          • amarao
            /#21430304

            А можно это увидеть? А то я вот гонял нагрузку и никакой радикальной разницы не заметил. Если не мухлевать с flush'ами, конечно.

            • equand
              /#21430548 / +1

              www.ilsistemista.net/index.php/virtualization/47-zfs-btrfs-xfs-ext4-and-lvm-with-kvm-a-storage-performance-comparison.html?start=3

              Собственно на нагруженной ноде, где кешу нет вообще места (RAM 98%) с NVME 4kn падение qcow2 в 4 раза по сравнению с чистым LVM. Мы с него по тому и мигрировали в thin (ради снепшотов)

              • inetstar
                /#21430638

                Думаю, эти результаты для LVM можно было бы ещё улучшить, если увеличить размер экстентов и чанков с дефолтного.

              • amarao
                /#21430654 / +1

                Я посмотрел, за вычетом инсталляции, остальные тесты prepovision qcow2@xfs и lvm практически нос в нос. С учётом, что в каких-то тестах побеждает xfs без каких-либо оснований, можно говорить, что у тестов большой error bar и они равны с его учётом.


                А, я понял, вы сравниваете с ext4. Не, разумеется, снизу xfs.

          • edo1h
            /#21430484

            "медленнее" может быть на 50%, а может быть на 0.5%.

    • amarao
      /#21428618

      Я не знаю как сейчас, а много лет назад open-iscsi был ОЧЕНЬ тормознутым. В 2011 году я по iscsi с нулевого устройства выжимал не больше 300Мб/с на 10G, и упиралось всё в 100% CPU одного ядра. Возможно, с тех лет стало лучше.

    • snd3r
      /#21429078

      У Hyper-V с iSCSI всё очень хорошо.

  10. le9i0nx
    /#21428120

    у virtio-scsi есть важный плюс он поддерживает проброс trim

    • zuborg
      /#21429000

      ровно такой же плюс уже давно есть и в virtio-blk ;)

      • le9i0nx
        /#21430758

        Ну не знаю для меня условие kernel >5.0 и qemu > 4.0 и ubuntu 18 lts невыполнимо т.к. там ещё 2.11. так что можно считать что в промышленой эксплатации этой фичи нет.

  11. Ion_Storm
    /#21428354

    Хм… На первое место, по моему опыту, я бы вывел установка корректных драйверов внутри винды и пакета qemu-ga-tools. Прям по инструкции, стандартные драйвера, то как это видит себе винда — минус 100500 к производительности.
    Второй момент, разобраться с memmory overcommit и Ballooning, это позволит не лезть лишний раз к дисковой подсистеме за счет перераспределения памяти и снижения swap.
    Ну и в третьих надо смотреть что выведено в качестве гостевых систем. Если у вас там крутится БД с большим IO, её надо вытаскивать в отдельный сторадж, чтобы все остальные об нее не запинались.
    Вообще измерять что-то изнутри ВМ это странно до неприличия. Смотреть в первую очередь надо со стороны KVM. Может быть, что вы упираетесь в ресурсы контроллера и массива, например, за счет не верного модуля-драйвера на контроллер. Тип файловой системы и параметры журналирования. Нагрузка от типа операций (чего больше, чтения или записи). Чем вызваны потребности в этих операциях?
    Эххх, хотел продолжить свой цикл статей, но руки так и не дошли. Может в карантине продолжу.

  12. Varim
    /#21428526

    типичный блок файловой системы (4КБ). Чем больше блок (extent) на физическом устройстве LVM, тем более быстро происходит IO и тем меньше фрагментация.
    Это значит что при использовании LVM с большим блоком — SSD диск будет изнашиваться быстрее?

    • inetstar
      /#21428652

      Наоборот, медленнее. Так как будет меньше фрагментация.
      В статье я приводил команду для нахождения оптимального размера чанка.
      Этот размер будет примерно равен размеру страницы NAND.

      • Varim
        /#21429518

        Я не в курсе как работает LVM, потому и интересуюсь. Допустим мне нужно записать 100 блоков по 4к в разные места (рандомное расположение блоков), если размер блока LVM тоже 4к, то 100*4 = 400к, то есть нет оверхеда при записи. Если же размер блока 256MB, то умножить его на 100 блоков будет как то много оверхеда записи = 25600 МБ, что в 64 раза больше, то есть в 64 раза ssd изнашивается быстрее, или LVM как то умеет правильно обрабатывать такую ситуацию?

        • inetstar
          /#21429528

          Записано будет только 400k, если логический том создан с опцией -Zn. А выделен полный объём.

  13. Cache
    /#21428616

    В thin lvm использование больших чанков ведёт к большим накладным расходам при работе со снимками. При первом доступе к чанку он весь заполняется нулями, что тоже не подходит безследно для производительности. Можно отключить zeroing, но тогда внутри будет встречаться мусор. Не зря там по умолчанию 64кб. Writeback (не беру во внимание надёжность) в реальной задаче нужен когда нужно больше писать на диск, чем читать.

    • inetstar
      /#21428638

      А какой смысл в заполнении нулями? И без него всё прекрасно работает.
      Вот взять практически любую ФС. После удаления файла на автомате место не перезаписывается нулями. И что? Разве это мешает в дальнейшем?

      • Cache
        /#21429888

        Смысл хотя бы в безопасности, что бы новый клиент которому посчастливилось попасть на место предыдущего не получил доступ к его данным. Заполнение нулями это не хорошо и не плохо, так это работает. И его можно отключить.

  14. Tangeman
    /#21429756

    Чем больше блок (extent) на физическом устройстве LVM, тем более быстро происходит IO и тем меньше фрагментация.

    Фрагментация — да (неактуально для SSD), скорость — нет. Размер экстента не влияет на скорость обмена (и не может), о чём явно говорится в документации (man vgcreate):


    If the volume group metadata uses lvm2 format those restrictions do not apply, but having a large number of extents will slow down the tools but have no impact on I/O performance to the logical volume.

    Если кто-то (файловая система) хочет читать из (или писать в) LVM устройства блок в 4K, будет читаться/писаться 4K, вне зависимости от размера экстента и типа (think или нет). На что он влияет так это на размер метаданных — чем меньше размер, тем больше метаданных.

    • inetstar
      /#21429798

      неактуально для SSD

      Актуально. Для SSD скорость линейного чтения почти всегда выше, чем случайного чтения.

      having a large number of extents

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

      Также нужно учитывать, что типичный размер страницы NAND — 2-4МБ. При меньших размерах происходит write amplification, что замедляет запись.

      • Tangeman
        /#21429898

        Со временем любой SSD всё равно сильно фрагментируется (внутри, в FTL), при размерах операции ввода-вывода от 1MiB вы эту разницу вряд ли почувствуете на уровне доступа из ОС. Свежезаписанный SSD при линейном чтении даст высокую скорость, а уже поработавший — гораздо ниже, потому что линейными оно будет только для вас.


        Насчёт цитаты — "having large number of extents" эквивалентно "having small extents" (так как чем они меньше тем их больше).


        В любом случае размер экстента не влияет на размер операции ввода-вывода, если приложение или FS пишет маленькими блоками, на SSD оно уйдёт тоже только маленькими блоками (при directio или fsync), в лучшем случае вам повезет и одновременно много модифицированных блоков будут сброшены из кэша — но это всё на что можно расчитывать.


        Можете использовать iostat или ebpf и убедитесь что размер экстента не влияет на размер I/O, и, соответственно, на write amplification.

        • inetstar
          /#21429936

          Насчёт цитаты — «having large number of extents» эквивалентно «having small extents» (так как чем они меньше тем их больше).

          Не эквивалентно. Это вы так трактуете. На мой взгляд это эквивалентно вот чему «если у вас много блоков, то скорость диска от этого не ухудшается».

          о чём явно говорится в документации

          Это явно неявно.

          Проведите тесты с разным размером экстента и/или чанка и увидите сами, что это сильно влияет на результаты.

          • Tangeman
            /#21430128 / -1

            Хорошо, применим логику. У меня N блоков, размер устройства 1TiB, и у меня N*10 блоков — при том же размере устройства. В соответствии с документацией это не влияет производительность, верно? Ведь "много блоков — не ухудшается", хотя размер блока у нас стал в 10 раз меньше.


            При начальном распределении экстентов (в случае thin) могут быть неприятности, и то при записи, потом всё нормализуется, также фрагментация существенно влияет в случае не-SSD, и тут да, косвенно размер экстента имеет значение — чем они меньше тем больше фрагментация, при постоянных allocate/discard.


            Тесты я как раз проводил (хотя и не из KVM), никакой разницы (в пределах погрешностей). Если тесты в KVM показывают другие результаты — это явно не связано с LVM и размером экстентов.

            • inetstar
              /#21430146

              Это фикция, а не логика.
              В документации подразумевается один и тот же размер блока. И скорее всего подразумевается одинаковый дефолтный размер. Нигде не говорится, что он разного размера, а диск фиксированной ёмкости.

              Тесты я как раз проводил (хотя и не из KVM)

              Для чанков или экстентов? Какие размеры тестировались?

              • Tangeman
                /#21430646

                Если вы заглянете в реализацию LVM, вы поймете почему размер экстента не может влиять на производительность. Точнее, можно создать сценарий использования когда влияние проявится (частое создание-удаление thin устойств, равномерность их заполнения, использование discard etc).


                Но если мы создали устройство, заполнили его данными и работаем с ними, то с этого момента практически неизмерима разница в скорости доступа при размере экстентов от 4 до 256 MiB.


                Тесты проводились для размеров экстентов в диапазоне от 4 до 256MiB, на Samsung SSD 850 Pro 1TB, с помощью ioping и pgbench. К сожалению результаты не сохранились, это было почти год назад — а проводил я их как раз для одного неверующего клиента.

                • inetstar
                  /#21430666

                  Сейчас работать без thin томов — очень расточительное и неудобное дело.

                  • Tangeman
                    /#21430814

                    Кому как. Если вам нужен высокопроизводительный сервер с гарантированными ресурсами — то гораздо проще выделить их сразу и не заморачиваться с thin. Даже если у вас бюджет не позволяет сразу получить всё, но потребление будет только расти — всё равно thin имеет мало смысла, не говоря уже о всех проблемах с ним связанными (метаданные, их потенциальная порча и всё такое). Для снапшотов thin не нужен, они и так прекрасно берутся.


                    С другой стороны, если вы хостинг-провайдер или очень бюджетная организация с кровавым over-provisioning, да, тогда без thin всё может быть очень расточительно.

        • edo1h
          /#21430530 / +1

          Со временем любой SSD всё равно сильно фрагментируется (внутри, в FTL), при размерах операции ввода-вывода от 1MiB вы эту разницу вряд ли почувствуете на уровне доступа из ОС. Свежезаписанный SSD при линейном чтении даст высокую скорость, а уже поработавший — гораздо ниже, потому что линейными оно будет только для вас.

          я на своих устройствах такого не наблюдаю, только сейчас проверил на стареньком intel s3510 — последовательное чтение 500Мб/с, случайное в 1 поток 30Мб/с, случайное во много потоков — 250Мб/с (всё блоком 4к)

          • Tangeman
            /#21430774

            Возможно, вы не учли тот факт что ОС может объединять много запросов на последовательное чтение в один (или даже сам диск делать внутри read ahead) — даже если это один поток, так что чтение мегабайта с размером блока в 4KiB может оказаться одним чтением блоком в 1MiB.


            Но даже без объединения, логично что чем меньше размер блока тем больше операций, а каждый syscall (или его эквивалент в Windows) имеет накладные расходы, вы меряете не только производительность диска но и производительность ядра и всей подсистемы ввода-вывода.


            В вашем случае результат в 500 Mib/s при блоке 4KiB и одном потоке очень подозрителен, очень похоже на read merge (скорее даже кэш), по крайней мере для SATA SSD — потому что даже Intel Optane 905P выдаёт меньше 300 MiB/s.


            Вот к примеру результаты от Seagate Nytro 1551 SSD 960GB (не очень поношенный):


            # ioping -s4k -S1G -L -A -D -i0 -q -c100000 /dev/sda
            
            --- /dev/sda (block device 894.3 GiB) ioping statistics ---
            100.0 k requests completed in 5.89 s, 390.6 MiB read, 17.0 k iops, 66.3 MiB/s
            generated 100 k requests in 6.19 s, 390.6 MiB, 16.2 k iops, 63.1 MiB/s
            
            # ioping -s4k -S10G -A -D -i0 -q -c100000 /dev/sda
            
            --- /dev/sda (block device 894.3 GiB) ioping statistics ---
            100.0 k requests completed in 8.39 s, 390.6 MiB read, 11.9 k iops, 46.6 MiB/s
            generated 100 k requests in 8.72 s, 390.6 MiB, 11.5 k iops, 44.8 MiB/s
            min/avg/max/mdev = 30.9 us / 83.9 us / 1.22 ms / 51.5 us

            Всего-то 66 MiB/s при последовательном чтении (первый), и хоть ощутимо, но не в разы меньше при рандомном (второй), хотя это и не самый слабый SSD. При размере блока в 256 KiB разница ещё меньше (360 и 335 соответственно).

            • edo1h
              /#21431178

              Возможно, вы не учли тот факт что ОС может объединять много запросов на последовательное чтение в один (или даже сам диск делать внутри read ahead) — даже если это один поток, так что чтение мегабайта с размером блока в 4KiB может оказаться одним чтением блоком в 1MiB.

              я проверял fio.
              да, вы правы, обращение к диску при последовательном чтении в fio (без direct=1) идёт блоками по 128Кб даже при указании bs=4k:


              Device            r/s     w/s     rMB/s     wMB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util
              nvme0n1       16033.00    0.00   2004.13      0.00     0.00     0.00   0.00   0.00    0.08    0.00   0.00   128.00     0.00   0.06 100.00

              оно и понятно, дефолтный read ahead в linux как раз 128Кб (отключать или уменьшать смысла не вижу: ядро достаточно умное, чтобы отключать ra при случайном доступе).


              однако, какое это всё имеет отношение к


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

              ?


              хотите сказать, что новый диск выдавал у вас гораздо больше?

              • Tangeman
                /#21431256

                Именно, новый диск выдавал больше. Тот который я привёл ещё относительно новый (там всего порядка 4 TiB записано), а вот поношенный уже Samsung Pro 1T вначале (~ 2 TiB записано) давал около 500 (средняя скорость после чтения всего диска, блоками по 1M) а после 100 TiB снизился до 300 (тоже средняя скорость за весь диск, без других нагрузок).


                Если же TRIM недоступен (с железыми RAID частное явление), то ситуация может быть и хуже, сборка мусора хоть и помогает, но сильно снижает производительность по мере того как он изнашивается.


                Если запись производится в основном последовательно и большими блоками (бэкапы & co), это почти незаметно, а если это что-то вроде нагруженого сервера с базой данных или простой банальный хост для виртуалок с разными паттернами использования — то чем больше записано, тем тормознее он становится со временем, за счёт внутренней фрагментации и ремаппинга.


                Если сделать бэкап хорошо потрёпанного SSD, потом полный TRIM (на весь объём) и восстановить, можно вернуть часть производительности, на какое-то время (зависит от контроллера и ещё нескольких факторов).


                Впрочем, даже потрёпанные SSD на порядки быстрее чем HDD, так что кроме особо чувствительных к производительности задач (и бенчмарков) все эти проседания не особо бросаются в глаза.

                • edo1h
                  /#21431404

                  поношенный уже Samsung Pro 1T вначале (~ 2 TiB записано) давал около 500 (средняя скорость после чтения всего диска, блоками по 1M) а после 100 TiB снизился до 300 (тоже средняя скорость за весь диск, без других нагрузок)

                  может это особенность именно самсунга? не наблюдал такого на своих дисках.


                  пример со своим интелом на десктопе, который выдаёт примерно столько же, сколько новый диск, я уже приводил.
                  вот, например тошиба KXG50ZNV512G в хетценере:


                  # nvme smart-log /dev/nvme1n1|grep written
                  data_units_written                  : 351,512,495
                  # dd if=/dev/nvme1n1p3 of=/dev/null bs=1M count=2048
                  2048+0 records in
                  2048+0 records out
                  2147483648 bytes (2.1 GB, 2.0 GiB) copied, 0.909372 s, 2.4 GB/s

                  вот такая же в более свежем сервере:


                  # nvme smart-log /dev/nvme0n1|grep written
                  data_units_written                  : 33,391,560
                  # dd if=/dev/nvme0n1p2  bs=1M of=/dev/null  status=progress count=2048
                  2048+0 records in
                  2048+0 records out
                  2147483648 bytes (2.1 GB, 2.0 GiB) copied, 0.937572 s, 2.3 GB/s

                  где разница?!?

                  • Tangeman
                    /#21431660

                    Для более адекватных результатов добавьте iflag=direct — чтобы исключить кэш, хотя в вашем примере SSD даже один раз не были записаны полностью (при объеме в 512G записано около 160 GiB), значит, до фрагментации и ремаппинга не дошло.


                    Насчёт особенности самсунга не уверен — у меня есть два Crucial MX300 750G, ведут себя точно также — в начале было ~450 Mib/s, через пару лет (и всего 1.5 TiB) уже ~330 MiB.


                    Но, как я уже говорил выше, всё зависит от того как именно на него пишутся данные и как они удаляются (используется TRIM или нет). Если это происходит большими кусками, эффект может и не проявится, если сравнительно маленькими (как у меня) — вполне может.

                    • edo1h
                      /#21432596

                      Для более адекватных результатов добавьте iflag=direct — чтобы исключить кэш

                      я сбрасывал кэш перед тестом, так что добавление iflag=direct ничего не меняет


                      # dd if=/dev/nvme1n1p1 of=/dev/null bs=1M count=2048 iflag=direct
                      2048+0 records in
                      2048+0 records out
                      2147483648 bytes (2.1 GB, 2.0 GiB) copied, 0.923611 s, 2.3 GB/s

                      хотя в вашем примере SSD даже один раз не были записаны полностью (при объеме в 512G записано около 160 GiB)

                      вы неправы, единица измерения тут — тысяча секторов, так что записано >>150Tb.


                      Если это происходит большими кусками, эффект может и не проявится, если сравнительно маленькими (как у меня) — вполне может.

                      на первом диске основная нагрузка — mysql, так что случайной записи мелкими блоками достаточно.

                      • Tangeman
                        /#21432912

                        Вероятно, у этой модели работа даже с фрагментированными данными более эффективна, хотя скорость в 2.3 GB/s явно ниже заявленной в спецификации 2.9 GB/s.


                        Второе предположение — на обоих дисках достаточно много свободного места и используется TRIM (fstrim или монтирован с discard), а чтение из нераспределенных секторов идёт на максимальной скорости, таким образом влияя на среднюю.


                        Как оказалось у меня почти такой же диск в ноутбуке (XG5, только 250G), вот что показывает AIDA:
                        image


                        Средняя скорость около 1400, хотя первые 15% (как раз примерно использованное пространство) скорость явно ощутимо ниже. Всего на диск было записано 1.45 TiB.

        • edo1h
          /#21438394

          Со временем любой SSD всё равно сильно фрагментируется

          вы побудили меня проверить, не на любом это имеет значение
          https://habr.com/ru/post/494614/

  15. Naves
    /#21430830

    сервер 1

    pveversion --verbose
    proxmox-ve: 5.2-2 (running kernel: 4.15.17-3-pve)
    pve-manager: 5.2-2 (running version: 5.2-2/b1d1c7f4)
    pve-kernel-4.15: 5.2-3
    pve-kernel-4.15.17-3-pve: 4.15.17-12
    pve-kernel-4.13.13-4-pve: 4.13.13-35
    pve-kernel-4.13.13-2-pve: 4.13.13-33
    corosync: 2.4.2-pve5
    criu: 2.11.1-1~bpo90
    glusterfs-client: 3.8.8-1
    ksm-control-daemon: 1.2-2
    libjs-extjs: 6.0.1-2
    libpve-access-control: 5.0-8
    libpve-apiclient-perl: 2.0-4
    libpve-common-perl: 5.0-32
    libpve-guest-common-perl: 2.0-16
    libpve-http-server-perl: 2.0-9
    libpve-storage-perl: 5.0-23
    libqb0: 1.0.1-1
    lvm2: 2.02.168-pve6
    lxc-pve: 3.0.0-3
    lxcfs: 3.0.0-1
    novnc-pve: 1.0.0-1
    proxmox-widget-toolkit: 1.0-18
    pve-cluster: 5.0-27
    pve-container: 2.0-23
    pve-docs: 5.2-4
    pve-firewall: 3.0-11
    pve-firmware: 2.0-4
    pve-ha-manager: 2.0-5
    pve-i18n: 1.0-6
    pve-libspice-server1: 0.12.8-3
    pve-qemu-kvm: 2.11.1-5
    pve-xtermjs: 1.0-5
    qemu-server: 5.0-28
    smartmontools: 6.5+svn4324-1
    spiceterm: 3.0-5
    vncterm: 1.5-3
    zfsutils-linux: 0.7.9-pve1~bpo9

    • inetstar
      /#21430958

      А что такое img-ssd-one?

      И что ссд у вас стоят на серверах?

      • Naves
        /#21431194

        забыл исправить копипасту из конфига, Volume Group так называется.

        еще раз virtio



        • edo1h
          /#21431202

          так что сравнивать несравнимое?!?

          • Naves
            /#21431246

            Я не сравниваю сервер1 и сервер2 друг с другом.

  16. bzzz00
    /#21434836

    интересно было бы увидеть _отдельные_ бенчмарки для каждого отдельного изменения.