Комментарии 101
чтобы избежать закупок дорогих серверных лицензий Windows.
Так вроде Microsoft Hyper-V Server бесплатен.
"Он хотел бы на своих серверах, где уже стоял Ubuntu 18.04, запускать виртуальные машины с Windows под KVM."
"Он хотел раскочегарить qemu на своих Ubuntu серверах, чтобы избежать закупок дорогих серверных лицензий Windows Server"
Я вас поздравляю — нарушает правила лицензирования Microsoft. Чтобы иметь право использовать Windows Server в гостевой системе должен быть корректно отлицензирован хост. И не важно, какой гипервизор используется…
… и сколько ядер доступно виртуалке — лицензировать надо все физические.
Я вас поздравляю — нарушает правила лицензирования Microsoft.
А меня за что? Я только настраивал сервер.
Чтобы иметь право использовать Windows Server в гостевой системе должен быть корректно отлицензирован хост.
Кстати, в гостевых системах использовалась Windows 10 Pro, а не Server.
Все сложнее. Multitenant Hosting десктопной Windows требует отдельной авторизации от Microsoft. В России я только РТК знаю с такой
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
— совсем нестандартная архитектура с огромным количеством памяти и процессоров, при этом количество процессоров вообще может меняться потому что часть аппаратуры — что-то вроде FPGA и новые «процессоры» по запросу могут формировать и могут быть специфичными ускорителями или железом общего назначения, все это еще и геораспределенное, между странами. Даже примерные характеристики известны только узкому кругу лиц
— несколько тысяч экземпляров адаптированного bochs(даже не qemu — архитектура же совсем другая а железо у нас сверхмощное) запущенный поверх того что выше. Некоторые — имитируют суперкомпьютер более менее обычного типа(с кластерной сетью), некоторые — «обычные» серверы, в том числе и с Windows (или линуксом). Доступ к консолям виртуалок выдан достаточно большому количеству пользователей. Сколько сокетов/ядер и памяти будет видеть виртуалка — настраивается при желании пользователем (в рамках выделенного конкретному пользователю пула ресурсов, пользователь может и несколько виртуалок иметь с имитированной сетью).
Доступ в интернет все эти виртуалки имеют если хозяйство имеет если так решил администратор группы.
Никаких особых соглашений с MS у владельцев «хоста» — нет.
Каким способом обычные пользователи с доступом к виртуалкам могут корректно с точки зрения лицензий использовать десктопную и серверную Windows на такой системе? Такой способ вообще существует в данном случае?
Все достаточно просто с Windows Server.
1) Лицензируется физический хост
2) Следуя первому пункту инфраструктуру хостинга лицензирует провайдер, как владелец физического оборудования
3) Использование Windows Server для услуг хостинга регулируется MS SPLA, в том числе порядок отчётности провайдера перед MS.
4) Провайдер самостоятельно определяет политику работы (и тарифы) с конечными потребителями, но обязан доносить EULA MS до потребителей
Итого, согласно политикам MS вы не можете перетащить корп лицензии на не выделенное исключительно для вашей компании оборудование. Лицензирование в разделяемой инфраструктуре обеспечивает хостер
Зашёл увидеть совет "включите writeback". Увидел. Ожидаемо.
Плюс увидел неожиданную ахинею про тормоза файлового бэкэнда из-за "блоков по 4к".
Так ведь writeback, по итогу, был выключен. И разве использование раздела LVM напрямую не будет быстрее файлов? Лет 6 назад в proxmox переход с qcow2 на raw давал заметный прирост в скорости. Или тут дело именно в qcow2?
Вы знаете, всё очень интересно. Во-первых, qcow2 файловый бывает raw и thin. По-умолчанию делается thin, так что вы с большой вероятностью бенчмаркали first write (которая, очевидно, медленнее). raw (который примерный эквивалент обычного тома lvm) имеет производительность мало отличающуюся от производительности голого устройства. Однако, надо учитывать, что файловые системы более тщательно относятся к flush'ам, так что если у вас SSD из г-на и палок, но честные, то флаши их тормозят радикально.
… Разницу между файловым и блочным выводом, наверное, можно найти на синтетике и очень чувствительных бенчмарках, но точно не на уровне "на глаз видно". А вот разницу между raw и thin видно, особенно, если диски консьюмерского уровня.
Спасибо за разъяснение. Судя по всему тогда был как раз thin qcow2, тем более что, на сколько я помню, у пары виртуалок были снэпшоты на основе этого же qcow2.
А производительность LVM vs RAW file я на глаз не измерял. :-) Просто предположил что раз один уровень абстракции убрали, то и какой-то, хоть и незначительный, прирост должен быть. Тем более что у нас в офисном proxmox сервере не SSD вовсе.
Файловые операции внутри открытого файла практически такие же по скорости, как и блочное устройство. Вы же когда блочное устройство открываете, у вас всё равно такой же файл. Да, там есть кеширующая подсистема, но делает она хуже или лучше — вопрос открытый. А для фанатов вообще можно сделать O_DIRECT, и тогда её не будет.
Во-первых, qcow2 файловый бывает raw и thin.
Qcow2 расшифровывается как Qemu Copy-On-write. Он всегда thin.
Есть просто формат raw, а не «qcow2 raw». Но его мало кто использует по причине непрактичности и огромного занимаемого места.
И ещё меня интересует кое-что насчёт fallocate. В каких файловых системах достоверно известно, что этот вызов реально ищет самые длинные последовательные участки?
Если они, конечно, остаются у нагруженного сервера. Я сильно сомневаюсь, что там будет много таких участков.
Даже если это и так, то всё равно слой ext4, btrfs, xfs файловой системы Linux более ресурсоёмкий, чем слой LVM. Так как в LVM нет ни журналирования, ни B-tree, ни COW при обычной операции записи. А raw файл лежит в обычной ФС и, как минимум, работает журналирование каждой записи.
Не бывает безопасного writeback. Writeback — это когда часть данных не пишется, а хранится в памяти. Если память теряется, что-то на диск не сохраняется.
Дальше есть техники спецпротокола между софтом и дисковым устройством (flush/sync), которая позволяет софту обеспечить сохранность данных в условиях условного про… ба. Чаще всего этот протокол используют СУБД. Однако, это не панацея, потому что результатом про… ба будет удаление всех незавершённых транзакций. Что иногда ОК, а иногда — не очень.
Возможно ли эту тактику применить для виртуалок, когда flush/sync, инициированные вируалкой не теряются, но запись идёт не напрямую на медленный диск, а на какую-то быструю и безопасную, но небольшую ssd-ку? Не приходилось встречать такие конфигурации?
Теоретически можно использовать кэширующие тома в LVM (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/lvm_cache_volume_creation) — по идее как раз то, что вы сейчас описали, но на практике не пробовал.
Еще и все результаты сводятся к манипулированию размером записываемого блока в CrystalMark.
Сколько я пользовался CrystalMark это всегда играло значение:
Кеш чего? Случайных данных которые генерирует CrystalDisk Mark?
Когда я последовательно делаю тесты с небольшой областью, то у меня каждый раз вырастает и скорость чтения, и скорость записи.
Вот и на ваших скриншотах видно, что для небольшой области (100МБ) скорости чтения выше.
О том и речь, как можно доверять вашим скриншотам, если там очевидно разные тесты? Вы сами говорите о нерелевантности тестирования небольшим размером файла, при этом статья пестрит именно ими.
Я не против вашей методологии "быстрого" тестирования для получения какого-то промежуточного результата, но итоговые тесты, которые стремятся что-то подтвердить, должны проходить в одинаковых условиях.
Используем LVM-тома, а не файлы для хранения дисков виртуальных машин.
Задам странный вопрос, а заказчик готов к такому повороту, что теперь, чтобы скопировать образ диска его любимой виртуалки, нужно использовать непонятные команды вместо простого копирования файла.
Во всех случаях по скорости лучше virtio-blk. Использовать virtio-scsi имеет смысл в экзотических случаях, например, когда нужно подключать сотни дисков к виртуальной машине.
Странно, а все говорят про обратное
pve.proxmox.com/wiki/Qemu/KVM_Virtual_Machines
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.
www.ovirt.org/develop/release-management/features/storage/virtio-scsi.html
Задам странный вопрос, а заказчик готов к такому повороту, что теперь, чтобы скопировать образ диска его любимой виртуалки, нужно использовать непонятные команды вместо простого копирования файла.
Был готов. Тем более, что команды бывают и простые типа:
cat </dev/lvm/drive > backup.fileПо тестам virtio-scsi медленнее. Так как scsi-слой подразумевает выполнение различных scsi-команд, которые снижают скорость.
Тем более что «IO Thread» есть и у virtio-blk.
небольшой хостинговой компании
так
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Мб совсем никуда не годится.
А то что хостеры часто используют не самое дорогое железо типа Oracle F640 — это сплошь и рядом. Иначе им трудно будет обеспечить выгодные цены.
работающий трим — это экзотический случай?
Теперь и в virtio-blk есть. Для клиента была важнее всего скорость. virtio-scsi по тестам был значительно медленней.
в статье ни разу не сказано по каким параметрам шла оптимизация. параметры тестирования (размер области) на разных скриншотах разные, 100Мб совсем никуда не годится.
Решающие тесты были сделаны на областях размером 4ГБ. Тестов было так много, что часто использовались области по 100МБ потому, что иначе можно было состариться, пока дождёшься результатов.
На практике разница в результатах при разных областях была незначительной, потому что для каждого теста виртуальная машина запускась заново, т.е. кеш Windows был пуст.
На практике разница в результатах при разных областях была незначительной, потому что для каждого теста виртуальная машина запускась заново, т.е. кеш Windows был пуст.
Влияние кэша нижележащей операционной системы (суть гипервизора) — можете оценить?
Я не считаю сутью гипервизора кэш нижележащей операционной системы.
Как я понимаю, CrystalDiskMark резервирует место, а не создаёт случайный файл.
В противном случае всё чтение было бы некорректным и из кеша.
А при резервировании места кешируются физические сектора диска в RAM.
Поэтому (при большом размере RAM) каждый следующий запуск должен давать более хорошие результаты при чтении.
Во всяком случае у меня так получалось при использовании рейд-контроллера с кешем 4ГБ на машине с 32ГБ RAM.
Для проброса блочных устройств io=native дает обычно лучший результат, чем io=thread
Также можно исключить и LVM — пробрасывать сразу GPT-раздел.
Использовать релиз конца 2017-го года для достижения максимальной производительности выглядит немного странно…
Это специфика Ubuntu. В ней почти не обновляют qemu. Вручную скомпилированный свежий qemu не дал выигрыша тоже.
Для проброса блочных устройств io=native дает обычно лучший результат, чем io=thread
Возможно, но проброс был нежелателен. А без проброса native работал хуже.
Также можно исключить и LVM — пробрасывать сразу GPT-раздел.
Можно, но тогда всё становится жутко неудобно: ни снимков, ни удобного перемещения на другие физические носители, ни безопасного онлайн-ресайза.
Может, все-таки, ускорение дисковой подсистемы? Или увеличение производительности?
Основные элементы успеха: использование LVM-томов
Обязательно томов именно LVM?
Обыкновенные разделы или даже физические диски — не?
Спасибо, прочёл с удовольствием.
- 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
Я не говорил об ext4 с блоком в 4КБ на хосте, простите, это вы додумали сами.
Есть XFS, которая создавалась и развивалась для работы с большими файлами в больших количествах.
Ну и можно выбросить lvm из-за 'оверхеда' и использовать только btrfs subvolume + nodatacow.
PS:
и которая скорее всего будет фрагментирована
фрагментация ФС в linux based операционках — тема для отдельного холивара, не надо набрасывать.
Есть XFS,
А в ней можно создать блок больше размера страницы? Просто 4КБ это ограничения из-за страничного кэша используемого в vfs linux kernel, а xfs как и все файловые системы "подключены" через vfs к ядру.
Что такое "блок"? Можно ли записать через vfs больше 4к за раз? Запросто. Берёте и пишите. Возьмите blktrace да посмотрите, какие куски в устройство снизу уходят. 4k важны только для вопросов управления кешом.
А ещё, внезапно, все SSD отлично умеют делать coalesce, если у них max_queue_depth больше 1.
С какой стати qcow2 raw будет фрагментирован, если его создают с помощью fallocate'а? Файловая система видит размер блока и выделяет его полностью, предпочтительнее нефрагментированным образом. Даже если в файле будет несколько фрагментов, на общую производительность это не повлияет, потому что если разрывов в фрагментах мало, они пренебрежимы для современных SSD.
ЗЫ Несколько лет назад был баг в 3.14, который приводил к тому, что конкурентный доступ к fallocate'нутым данным был очень тормозным. Но это было в 3.14, что актуально только для ценителей копролитов.
А можно это увидеть? А то я вот гонял нагрузку и никакой радикальной разницы не заметил. Если не мухлевать с flush'ами, конечно.
Собственно на нагруженной ноде, где кешу нет вообще места (RAM 98%) с NVME 4kn падение qcow2 в 4 раза по сравнению с чистым LVM. Мы с него по тому и мигрировали в thin (ради снепшотов)
Я посмотрел, за вычетом инсталляции, остальные тесты prepovision qcow2@xfs и lvm практически нос в нос. С учётом, что в каких-то тестах побеждает xfs без каких-либо оснований, можно говорить, что у тестов большой error bar и они равны с его учётом.
А, я понял, вы сравниваете с ext4. Не, разумеется, снизу xfs.
"медленнее" может быть на 50%, а может быть на 0.5%.
Я не знаю как сейчас, а много лет назад open-iscsi был ОЧЕНЬ тормознутым. В 2011 году я по iscsi с нулевого устройства выжимал не больше 300Мб/с на 10G, и упиралось всё в 100% CPU одного ядра. Возможно, с тех лет стало лучше.
У Hyper-V с iSCSI всё очень хорошо.
у virtio-scsi есть важный плюс он поддерживает проброс trim
Второй момент, разобраться с memmory overcommit и Ballooning, это позволит не лезть лишний раз к дисковой подсистеме за счет перераспределения памяти и снижения swap.
Ну и в третьих надо смотреть что выведено в качестве гостевых систем. Если у вас там крутится БД с большим IO, её надо вытаскивать в отдельный сторадж, чтобы все остальные об нее не запинались.
Вообще измерять что-то изнутри ВМ это странно до неприличия. Смотреть в первую очередь надо со стороны KVM. Может быть, что вы упираетесь в ресурсы контроллера и массива, например, за счет не верного модуля-драйвера на контроллер. Тип файловой системы и параметры журналирования. Нагрузка от типа операций (чего больше, чтения или записи). Чем вызваны потребности в этих операциях?
Эххх, хотел продолжить свой цикл статей, но руки так и не дошли. Может в карантине продолжу.
типичный блок файловой системы (4КБ). Чем больше блок (extent) на физическом устройстве LVM, тем более быстро происходит IO и тем меньше фрагментация.Это значит что при использовании LVM с большим блоком — SSD диск будет изнашиваться быстрее?
В статье я приводил команду для нахождения оптимального размера чанка.
Этот размер будет примерно равен размеру страницы NAND.
В thin lvm использование больших чанков ведёт к большим накладным расходам при работе со снимками. При первом доступе к чанку он весь заполняется нулями, что тоже не подходит безследно для производительности. Можно отключить zeroing, но тогда внутри будет встречаться мусор. Не зря там по умолчанию 64кб. Writeback (не беру во внимание надёжность) в реальной задаче нужен когда нужно больше писать на диск, чем читать.
Чем больше блок (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 или нет). На что он влияет так это на размер метаданных — чем меньше размер, тем больше метаданных.
неактуально для SSD
Актуально. Для SSD скорость линейного чтения почти всегда выше, чем случайного чтения.
having a large number of extents
В цитате говорится о числе блоков, а не о размере. Чем больше блок — тем меньше фрагментация, а также меньше вычислительные ресурсы тратящиеся на трансляцию адресов через уровни абстракций.
Также нужно учитывать, что типичный размер страницы NAND — 2-4МБ. При меньших размерах происходит write amplification, что замедляет запись.
Со временем любой SSD всё равно сильно фрагментируется (внутри, в FTL), при размерах операции ввода-вывода от 1MiB вы эту разницу вряд ли почувствуете на уровне доступа из ОС. Свежезаписанный SSD при линейном чтении даст высокую скорость, а уже поработавший — гораздо ниже, потому что линейными оно будет только для вас.
Насчёт цитаты — "having large number of extents" эквивалентно "having small extents" (так как чем они меньше тем их больше).
В любом случае размер экстента не влияет на размер операции ввода-вывода, если приложение или FS пишет маленькими блоками, на SSD оно уйдёт тоже только маленькими блоками (при directio или fsync), в лучшем случае вам повезет и одновременно много модифицированных блоков будут сброшены из кэша — но это всё на что можно расчитывать.
Можете использовать iostat или ebpf и убедитесь что размер экстента не влияет на размер I/O, и, соответственно, на write amplification.
Насчёт цитаты — «having large number of extents» эквивалентно «having small extents» (так как чем они меньше тем их больше).
Не эквивалентно. Это вы так трактуете. На мой взгляд это эквивалентно вот чему «если у вас много блоков, то скорость диска от этого не ухудшается».
о чём явно говорится в документации
Это явно неявно.
Проведите тесты с разным размером экстента и/или чанка и увидите сами, что это сильно влияет на результаты.
Хорошо, применим логику. У меня N блоков, размер устройства 1TiB, и у меня N*10 блоков — при том же размере устройства. В соответствии с документацией это не влияет производительность, верно? Ведь "много блоков — не ухудшается", хотя размер блока у нас стал в 10 раз меньше.
При начальном распределении экстентов (в случае thin) могут быть неприятности, и то при записи, потом всё нормализуется, также фрагментация существенно влияет в случае не-SSD, и тут да, косвенно размер экстента имеет значение — чем они меньше тем больше фрагментация, при постоянных allocate/discard.
Тесты я как раз проводил (хотя и не из KVM), никакой разницы (в пределах погрешностей). Если тесты в KVM показывают другие результаты — это явно не связано с LVM и размером экстентов.
В документации подразумевается один и тот же размер блока. И скорее всего подразумевается одинаковый дефолтный размер. Нигде не говорится, что он разного размера, а диск фиксированной ёмкости.
Тесты я как раз проводил (хотя и не из KVM)
Для чанков или экстентов? Какие размеры тестировались?
Если вы заглянете в реализацию LVM, вы поймете почему размер экстента не может влиять на производительность. Точнее, можно создать сценарий использования когда влияние проявится (частое создание-удаление thin устойств, равномерность их заполнения, использование discard etc).
Но если мы создали устройство, заполнили его данными и работаем с ними, то с этого момента практически неизмерима разница в скорости доступа при размере экстентов от 4 до 256 MiB.
Тесты проводились для размеров экстентов в диапазоне от 4 до 256MiB, на Samsung SSD 850 Pro 1TB, с помощью ioping и pgbench. К сожалению результаты не сохранились, это было почти год назад — а проводил я их как раз для одного неверующего клиента.
Кому как. Если вам нужен высокопроизводительный сервер с гарантированными ресурсами — то гораздо проще выделить их сразу и не заморачиваться с thin. Даже если у вас бюджет не позволяет сразу получить всё, но потребление будет только расти — всё равно thin имеет мало смысла, не говоря уже о всех проблемах с ним связанными (метаданные, их потенциальная порча и всё такое). Для снапшотов thin не нужен, они и так прекрасно берутся.
С другой стороны, если вы хостинг-провайдер или очень бюджетная организация с кровавым over-provisioning, да, тогда без thin всё может быть очень расточительно.
Со временем любой SSD всё равно сильно фрагментируется (внутри, в FTL), при размерах операции ввода-вывода от 1MiB вы эту разницу вряд ли почувствуете на уровне доступа из ОС. Свежезаписанный SSD при линейном чтении даст высокую скорость, а уже поработавший — гораздо ниже, потому что линейными оно будет только для вас.
я на своих устройствах такого не наблюдаю, только сейчас проверил на стареньком intel s3510 — последовательное чтение 500Мб/с, случайное в 1 поток 30Мб/с, случайное во много потоков — 250Мб/с (всё блоком 4к)
Возможно, вы не учли тот факт что ОС может объединять много запросов на последовательное чтение в один (или даже сам диск делать внутри 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 соответственно).
Возможно, вы не учли тот факт что ОС может объединять много запросов на последовательное чтение в один (или даже сам диск делать внутри 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 при линейном чтении даст высокую скорость, а уже поработавший — гораздо ниже, потому что линейными оно будет только для вас.
?
хотите сказать, что новый диск выдавал у вас гораздо больше?
Именно, новый диск выдавал больше. Тот который я привёл ещё относительно новый (там всего порядка 4 TiB записано), а вот поношенный уже Samsung Pro 1T вначале (~ 2 TiB записано) давал около 500 (средняя скорость после чтения всего диска, блоками по 1M) а после 100 TiB снизился до 300 (тоже средняя скорость за весь диск, без других нагрузок).
Если же TRIM недоступен (с железыми RAID частное явление), то ситуация может быть и хуже, сборка мусора хоть и помогает, но сильно снижает производительность по мере того как он изнашивается.
Если запись производится в основном последовательно и большими блоками (бэкапы & co), это почти незаметно, а если это что-то вроде нагруженого сервера с базой данных или простой банальный хост для виртуалок с разными паттернами использования — то чем больше записано, тем тормознее он становится со временем, за счёт внутренней фрагментации и ремаппинга.
Если сделать бэкап хорошо потрёпанного SSD, потом полный TRIM (на весь объём) и восстановить, можно вернуть часть производительности, на какое-то время (зависит от контроллера и ещё нескольких факторов).
Впрочем, даже потрёпанные SSD на порядки быстрее чем HDD, так что кроме особо чувствительных к производительности задач (и бенчмарков) все эти проседания не особо бросаются в глаза.
поношенный уже 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где разница?!?
Для более адекватных результатов добавьте iflag=direct — чтобы исключить кэш, хотя в вашем примере SSD даже один раз не были записаны полностью (при объеме в 512G записано около 160 GiB), значит, до фрагментации и ремаппинга не дошло.
Насчёт особенности самсунга не уверен — у меня есть два Crucial MX300 750G, ведут себя точно также — в начале было ~450 Mib/s, через пару лет (и всего 1.5 TiB) уже ~330 MiB.
Но, как я уже говорил выше, всё зависит от того как именно на него пишутся данные и как они удаляются (используется TRIM или нет). Если это происходит большими кусками, эффект может и не проявится, если сравнительно маленькими (как у меня) — вполне может.
Для более адекватных результатов добавьте 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, так что случайной записи мелкими блоками достаточно.
Вероятно, у этой модели работа даже с фрагментированными данными более эффективна, хотя скорость в 2.3 GB/s явно ниже заявленной в спецификации 2.9 GB/s.
Второе предположение — на обоих дисках достаточно много свободного места и используется TRIM (fstrim или монтирован с discard), а чтение из нераспределенных секторов идёт на максимальной скорости, таким образом влияя на среднюю.
Как оказалось у меня почти такой же диск в ноутбуке (XG5, только 250G), вот что показывает AIDA:
Средняя скорость около 1400, хотя первые 15% (как раз примерно использованное пространство) скорость явно ощутимо ниже. Всего на диск было записано 1.45 TiB.
Со временем любой SSD всё равно сильно фрагментируется
вы побудили меня проверить, не на любом это имеет значение
https://habr.com/ru/post/494614/
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
сервер 2
pve-manager: 6.1-7 (running version: 6.1-7/13e58d5e)
pve-kernel-5.3: 6.1-4
pve-kernel-helper: 6.1-4
pve-kernel-4.15: 5.4-13
pve-kernel-5.3.18-1-pve: 5.3.18-1
pve-kernel-4.15.18-25-pve: 4.15.18-53
pve-kernel-4.15.18-24-pve: 4.15.18-52
pve-kernel-4.15.18-8-pve: 4.15.18-28
pve-kernel-4.13.13-5-pve: 4.13.13-38
pve-kernel-4.13.13-2-pve: 4.13.13-33
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.0.3-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.14-pve1
libpve-access-control: 6.0-6
libpve-apiclient-perl: 3.0-3
libpve-common-perl: 6.0-12
libpve-guest-common-perl: 3.0-3
libpve-http-server-perl: 3.0-4
libpve-storage-perl: 6.1-4
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 3.2.1-1
lxcfs: 3.0.3-pve60
novnc-pve: 1.1.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.1-3
pve-cluster: 6.1-4
pve-container: 3.0-19
pve-docs: 6.1-4
pve-edk2-firmware: 2.20191127-1
pve-firewall: 4.0-10
pve-firmware: 3.0-5
pve-ha-manager: 3.0-8
pve-i18n: 2.0-4
pve-qemu-kvm: 4.1.1-2
pve-xtermjs: 4.3.0-1
qemu-server: 6.1-5
smartmontools: 7.1-pve2
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.3-pve1
И что ссд у вас стоят на серверах?
на сервере 1 полка, 10Gb iSCSI — MD3800i
Enclosure, Drawer, Slot: Manufacturer: Product ID: Physical Disk Type: Capacity: Physical Disk firmware version: FPGA Version: (SSD only)
Enclosure 0, Slot 0 TOSHIBA PX05SMB040Y Serial Attached SCSI (SAS) 372.111 GB AS03 Not Available
Enclosure 0, Slot 1 TOSHIBA PX05SMB040Y Serial Attached SCSI (SAS) 367.111 GB AS03 Not Available
Enclosure 0, Slot 2 TOSHIBA PX05SMB040Y Serial Attached SCSI (SAS) 367.111 GB AS03 Not Available
Enclosure 0, Slot 3 TOSHIBA PX05SMB040Y Serial Attached SCSI (SAS) 367.111 GB AS03 Not Available
Enclosure 0, Slot 4 TOSHIBA PX05SMB040Y Serial Attached SCSI (SAS) 372.111 GB AS03 Not Available
Enclosure 0, Slot 5 TOSHIBA PX05SMB040Y Serial Attached SCSI (SAS) 367.111 GB AS03
Virtual Disk name: ssd-one-disk
Virtual Disk status: Optimal
Thin provisioned: No
Capacity: 1,468.445 GB
Virtual Disk world-wide identifier: 60:0a:09:80:00:bd:35:2d:00:00:15:63:5c:a0:40:08
Subsystem ID (SSID): 0
Associated disk group: ssd-one-group
RAID level: 6
LUN: 0
Accessible By: Host Group LOCAL_SERVERS
Physical Disk media type: Solid State Disk
Physical Disk interface type: Serial Attached SCSI (SAS)
Logical sector size: 512 bytes
Enclosure loss protection: No
Secure: No
Preferred owner: RAID Controller Module in slot 0
Current owner: RAID Controller Module in slot 0
Segment size: 128 KB
Capacity reserved for future segment size changes: Yes
Maximum future segment size: 2,048 KB
Modification priority: High
Read cache: Enabled
Write cache: Enabled
Write cache without batteries: Disabled
Write cache with mirroring: Enabled
Flush write cache after (in seconds): 10.00
Dynamic cache read prefetch: Enabled
Enable background media scan: Enabled
Media scan with consistency check: Enabled
Pre-Read consistency check: Disabled
на сервере 2
INTEL SSDPEDMW400G4 в md raid1
Ускорение дисковой подсистемы Qemu KVM в Linux