13 494
правки
Изменения
м
Ceph — это SDS, его Примерным ориентиром наилучшей возможной задержки всегда выше, чем у устройств при прямом доступе, и от этого никуда не денешься. В интернете есть Ceph служит доклад Nick Fisk «Low-Latency Ceph», в его исполнении Low latency это 0.7ms. Это и есть ориентир, то есть на лучший результат рассчитывать особенно не приходится. 0.7ms — 7ms — это всего лишь примерно ~1500 iops в 1 поток (хорошая новость — другие SDS и просто SAN-ы тоже тормозят :)).
Также qperfнаписан криво: 1) всегда использует для tcp_lat размер сообщения 1 байт!!! 2) не использует TCP_NODELAY. На одной ноде просто <tt>qperf</tt>. На второй <tt>qperf -vvs SERVER_IP tcp_lat -m 4096</tt>Так что его юзать, только если возьмёте его с моим патчем отсюда: [[Мой Debian репозиторий]].
В общемКто задолбался со спилловерами? Все задолбались со спилловерами! :) Спилловер — это когда вы собрали Bluestore на SSD+HDD, выделив SSD под базу (block.db), но при этом эта самая база постоянно частично утекает на HDD. При этом она, вроде бы, даже влезает в SSD с запасом — но всё равно утекает. Начиная, кажется, с Ceph 14 Nautilus, о спилловерах предупреждает <tt>ceph -s</tt>, а с Ceph 15 Octopus авторы попытались победить spillover-ы через дополнительные «allocation hint»-ы RocksDB (надо потестировать: коммит 5f72c376deb64562e5e88be2f22339135ac7372b, добавили опцию bluestore_volume_selection_policy). Когда случается спилловер в SSD+HDD конфигурациях, работа кластера замедляется — в большей или меньшей степени, в зависимости от размеров RocksDB и паттерна нагрузки, так как всегдакогда метаданных не очень много, «есть небольшой нюанс»они влезают в кэш OSD — либо onode cache, либо rocksdb cache, либо, если включено bluefs buffered io — то ещё и в системный page cache. Нюанс Если кэш-промахов достаточно много, или если OSD упирается в compaction RocksDB, могут даже появляться slow ops-ы. Так в чём же дело и как это победить? А дело в том, что с выбором раздела для очередного файла БД (RocksDB организована в виде набора файлов) «есть нюанс», точнее, даже два. '''Нюанс № 1:''' RocksDB кладёт файл на быстрый диск только когда считает, что на быстром диске хватит места под все файлы этого же уровня(для тех, кто ещё не в курсе — RocksDB это [https://github.com/facebook/rocksdb/wiki/Leveled-Compaction LSM база]).
А L3 она положит на block.dbИными словами, имеют смысл только если размеры раздела block.db размером хотя бы 25600+2560+4 ГБ, 30 ГБ, 286 ГБ. Все промежуточные значения бессмысленны — место сверх предыдущего граничного значения использоваться не будет. Например, если БД занимает 10 ГБ, а раздел SSD — 20 ГБ, то фактически на SSD ляжет только WAL (1 ГБ), L1 и L2 (256МБ +1000 Мб = около 30 Гб2.56 ГБ). L3, составляющий бОльшую часть базы, уедет на HDD и будет тормозить работу.
А L4При этом 4 ГБ — слишком мало, соответственно286 ГБ — слишком много. Так что, если ещё +256по сути, то есть итого 286 Гбправильно делать block.db размером 30 ГБ для OSD любого размера.
Иными словамиКстати, имеют смысл только размеры раздела из этого же следует то, что официальная рекомендация — выделять под block.db 4 Гбто ли 2 %, 30 Гб, 286 Гб. Все промежуточные значения бессмысленны — место сверх предыдущего граничного значения использоваться не будетто ли 4 % от размера устройства данных — полный отстой.
При Но что делать, если у вас разделы другого размера? Например, 80 ГБ, и вы по каким-то причинам не хотите делать bcache, но хотите использовать эти 80 ГБ по максимуму. В этом случае можно поменять базовый размер уровня RocksDB (max_bytes_for_level_base). multiplier менять не будем, оставим по умолчанию 10 — его значение влияет на итоговое количество уровней RocksDB, а это уже более тонкая материя. Теоретически, меньшее число уровней снижает read и space amplification, но замедляет compaction и из-за этого может сильно повысить итоговый write amplification. Также есть тема с уменьшением размера отдельных memtable и кратным увеличением общего их числа, то есть, например, установки 32*32 МБ вместо дефолтных 4 Гб — слишком мало*256 МБ и min_write_buffer_to_merge=8, 286 Гб — слишком многоно эффект от этого тоже не совсем понятен (возможно, немного экономится CPU при compaction-е), так что это тоже пока лучше не трогать. Так чтокак каждый уровень отличается от предыдущего в 10 раз, общий размер раздела БД должен быть равен k*X, где k — коэффициенты из ряда: 1, 11, 111, 1111 и т. п. (по сутичислу уровней RocksDB). Значит, правильно делать мы можем взять размер нашего block.db размером 30 гб , вычесть из него 1 ГБ WAL (лучше даже вычесть с запасом 2 ГБ) и делить его последовательно на каждую из цифр до тех пор, пока не получим значение, близкое к 256 МБ … 1 ГБ. Это значение округлить вниз, принять за базовый размер уровня RocksDB и прописать в конфиг как max_bytes_for_level_base. База компактится по 256 МБ за раз, так что меньше 256 МБ размер первого уровня ставить точно смысла нет. Например, для всех 80 ГБ раздела это будет 719 МБ, только не забываем считать всё в двоичных мегабайтах — MiB. Остаётся прописать это значение в конфигурацию (bluestore_rocksdb_options = …,max_bytes_for_level_base=719MB), перезапустить OSDи сделать ручной compaction (можно дважды). '''Нюанс № 2:''' При ручном compaction-е RocksDB переписывает уровни целиком. Если при этом на SSD нет запаса места в размере этого уровня, то уровень, опять-таки, утечёт на HDD и так там и останется, ибо перемещать после compaction-а его обратно она не умеет. Теоретически, если после этого сделать compaction ещё раз, то уровень должен вернуться на SSD (поэтому выше дана рекомендация делать ручной compaction дважды). Однако по сведениям из чата якобы бывает так, что один-два файла *.sst на SSD не возвращается. Чтобы это побороть на 100 %, можно предусмотреть на SSD-разделе ещё и запас в размере первого + последнего уровня БД. В этом случае коэффициенты вместо 1-11-111-1111 превращаются в 2-22-212-2112 и т. п. == RGW vs Minio == Вопрос частый, так как Ceph и Minio — две наиболее распространённые реализации S3. Сравнение, как всегда, не совсем честное, так как в Minio «бесконечного масштабирования» и произвольных схем избыточности нет. Есть только erasure коды, которые оперируют группами дисков, кратными по количеству 4 или 16 дискам. Расширения кластера в Minio раньше не было вообще, потом в каком-то смысле появилось через создание дополнительных зон. Таких же гарантий целостности, как в Ceph, в Minio тоже нет. Minio работает поверх обычных ФС, даже не делая fsync данных. На практике ext4, правда, делает sync автоматически раз в 5 секунд, да и Minio пишет с O_DIRECT, так что не совсем всё плохо — но тем не менее, потенциально небольшие потери при отключении питания возможны. Особенно классный перл был в баге https://github.com/minio/minio/issues/3478: <blockquote>Minio in this case is working as intended, minio cannot be expanded or shrinkable in this manner. Minio is different by design. It is designed to solve all the needs of a single tenant. Spinning minio per tenant is the job of external orchestration layer. Any addition and removal means one has to rebalance the nodes. When Minio does it internally, it behaves like blackbox. It also adds significant complexity to Minio. Minio is designed to be deployed once and forgotten. We dont even want users to be replacing failed drives and nodes. Erasure code has enough redundancy built it. By the time half the nodes or drives are gone, it is time to refresh all the hardware. If the user still requires rebalancing, one can always start a new minio server on the same system on a different port and simply migrate the data over. It is essentially what minio would do internally. Doing it externally means more control and visibility. Minio is meant to be deployed in static units per tenant.</blockquote> Короче, всё работает как надо, в минио нет возможности расширения, если у вас будут ломаться диски — не меняйте, просто дождитесь, пока из строя выйдет половина дисков и пересоздайте кластер. На самом деле всё не так печально, можно заменить диск и запустить heal, но, конечно, без той же прозрачности, что в Ceph — оно будет просто сканировать все объекты и проверять отсутствующие. Если дисков много, это очень накладно. Ещё Minio хранит объекты в виде обычных файлов, даже не шардируя каталоги (соответствующие бакетам) по подкаталогам, плюс на каждый объект ещё создаёт директорию с парой файлов метаданных. Ну а директории в ФС по миллиону файлов — это, естественно, удовольствие ниже среднего. Хотя просто для раздачи оно, благодаря всяким dir_index-ам, работает. Для представления о производительности проведём простой тест Ceph (bluestore) vs Minio (ext4) на 1 HDD. Да, я знаю, что это тупо и нужно ещё хотя бы посравнивать их на SSD. Но всё-таки результаты довольно показательны. Да и объектное хранилище чаще холодное/прохладное и строится на HDD, а не на SSD. Тест делался через [https://github.com/vitalif/hsbench hsbench]. Заключался в заливке примерно 1.1 миллиона объектов в 1 бакет, потом сброса кэшей и перезапуска Ceph/Minio, и потом — их раздачи в случайном порядке, а также проверки скорости выполнения операций листингов. Результаты:* Заливка в 32 потока: Minio — 305 объектов в секунду, RGW — 135 объектов в секунду. RGW indexless — 288 объектов в секунду.* Раздача в 32 потока: Minio — 45 объектов в секунду, RGW — 78 объектов в секунду* Листинги в 32 потока: Minio — после сброса кэша 35 сек, после прогрева — 2.9 сек с разбросом от 0.5 до 16 сек. RGW — стабильно — 0.4 сек Да, заливка в Minio быстрее. Но, во-первых, меньшая скорость заливки — это цена, во-первых, консистентности (fsync), а во-вторых, bucket index-а и bucket index log-а, которые позволяют RGW, например, делать геосинхронизацию (multisite), чего в Minio нет. Кроме того, индексы в RGW можно положить на отдельные SSD (как обычно все и делают), а если же вам совсем не нужны листинги, синхронизация и прочее, в Ceph бакеты можно сделать безиндексными (indexless), и тогда оверхед bucket index-а вообще исчезает, как и возможные проблемы с его шардированием.
TL;DR:
* ceph.conf [global]: '''rbd cache writethrough until flush = false'''
* qemu: '''bus=virtio cache=writeback'''. Если у вас SSD, СУБД и нужны random iops — то '''bus=virtio cache=none'''.
* Внутри ВМ: '''mount -o lazytime'''.
* На пустом RBD-образе '''cache=writeback''' бесполезен, если не сделать '''rbd feature disable <pool>/<image> object-map'''. А если сделать — rbd du, rm и многие другие команды будут тормозить. Два стула.
==== Данные тестов ====
Нет описания правки
[[en:Ceph performance]][[File:Ceph-funnel.svg|500px|right]]Ceph — это SDS (по-русски — программная СХД), которая по некоторым параметрам является уникальной в своём роде, и в целом, умеет очень многое — S3, диски виртуалок, кластерную FS + огромный багаж дополнительных фич. И всё было бы хорошо — бери, ставь, запускай своё облако и руби бабло — если бы не один маленький нюанс: ПРОИЗВОДИТЕЛЬНОСТЬ. Терять 95 % производительности в Production-е разумным людям обычно жалко. «Облакам» типа AWS, GCP, Яндекса, по-видимому, не жалко — у них тоже собственные крафтовые SDS и они тоже тормозят примерно так же :-) но этот вопрос оставим — кто мы такие, чтобы их судить. В данной статье описано, каких показателей производительности можно добиться от цефа и как. Но сразу предупрежу: локальный SSD вы не догоните. Локальные SSD сейчас ОЧЕНЬ быстрые (особенно NVMe), порядок их задержки — 0.05ms. Догнать эту цифру SDS-ке крайне трудно (одна только сеть сожрёт те же 0.05ms), перегнать — наверное, вообще невозможно. '''UPDATE: Догнать можно. Я это сделал в своём собственном проекте — Vitastor: https://vitastor.io :-) это блочная SDS с архитектурой, похожей на Ceph, но при этом БЫСТРАЯ — в тесте на SATA SSD кластере задержка и чтения, и записи составила 0.14 мс. На том же кластере задержка записи у Ceph была 1 мс, а чтения — 0.57 мс. Детали есть в [https://yourcmc.ru/git/vitalif/vitastor/src/branch/master/README.md README] — смотрите по ссылке.'''
== Бенчмаркинг ==
Задержки обычно важнее простой пиковой производительности случайного чтения/записи, так как далеко не каждое приложение может загрузить диск при большом параллелизме / глубокой очереди (32-128 запросов).
=== Тестирование дисков ===
*: Или https://github.com/vitalif/ceph-bench, что примерно то же самое. Родоначальник идеи — @socketpair Марк Коренберг ([https://github.com/socketpair/ceph-bench оригинал]). Бенчилка тестирует ''отдельные OSD'', что очень помогает понять, кто же из них тупит-то.
*: Перед запуском надо создать пул без репликации {{Cmd|ceph osd pool create bench 128 replicated; ceph osd pool set bench size 1; ceph osd pool set bench min_size 1}} и с числом PG, достаточным, чтобы при случайном выборе туда попали все OSD (ну или прибить их вручную к каждому OSD upmap-ами)
* CephFS
** Нормальных инструментов для тестирования ФС, сцуко, нет!!!
** «Нормальный» инструмент — это такой инструмент, который вёл бы себя, как файловый сервер: случайно открывал, создавал/писал/читал и закрывал маленькие файлы среди большого общего количества, разбитые по набору каталогов
** Всё, что есть, какое-то кривожопое: bonnie++, например, зачем-то тестирует запись по 1 байту. iometer, fs_mark не обновлялись лет по 10, но и паттерн файл сервера не умеют. Лучшее, что умеют — это тест создания файлов.
** Пришлось написать свой ioengine для fio: https://github.com/vitalif/libfio_fileserver :)
* S3 (rgw):
** [https://github.com/intel-cloud/cosbench cosbench] — очень толстый, Java с Web-интерфейсом, XML-настройки** [https://github.com/markhpcvitalif/hsbench hsbench] — ссылка дана на исправленную версию (!). Максимально простой, консольное Golang приложение. Оригинальная версия пока что имеет 2 неприятных бага: во-первых, вместо чтения объектов целиком читает только первые 64 КБ, во-вторых, производит последовательное, а не случайное, чтение. Что, например, с minio приводит к слишком оптимистичным результатам тестов.** [https://github.com/minio/warp minio warp] — тестов чуть больше, чем в hsbench, но зато тестирует только 1 бакет и при каждом тесте загружает данные заново
Примечания:
* dd и hdparm для бенчмаркинга не использовать вообще никогда.!!!* rados bench использовать тоже не надо, т.к. так как он создаёт для тестирования очень мало объектов (в 1 поток всего 2, в 128 — 128 — несколько сотен). "Случайная" «Случайная» запись в такое число объектов не очень-то и случайная.
* rbd bench использовать можно, но fio лучше.
* Не надо удивляться, что Ceph не может загрузить диски на 100 100 % при случайной записи. Он тормоз :)
=== Тестирование сети ===
sockperf. На одной ноде запускаем сервер: <tt>sockperf sr -i IP --tcp</tt>. На другой клиент в режиме ping-pong: <tt>sockperf pp -i SERVER_IP --tcp -m 4096</tt>. Нормальная средняя цифра в районе 0.0505мс (50us, плюс-0минус 20us).07мс <s>Также qperf.На одной ноде просто <tt>qperf</tt>. На второй <tt>qperf -vvs -m 4096 SERVER_IP tcp_lat</tt>.</s>
[[Файл:Warning icon.svg|32px|link=]] Внимание: в Ubuntu на сетевую задержку негативно влияет AppArmor, его лучше отключить. Картина примерно такая (Intel X520-DA2):
== О транзакционности записи ==
[[Файл:Warning icon.svg|32px|link=]] Плохая новость!
Важная особенность Ceph — ''вся запись, даже та, для которой никто этого явно не просит, ведётся транзакционно''. То есть, никакая операция записи не завершается, пока она не записана в журналы всех OSD и не сделан fsync() диска. Так сделано, чтобы предотвращать [[#RAID WRITE HOLE]]-подобные ситуации рассинхронизации данных между репликами при отключении питания, потере сети и т.п…
=== Про размер block.db ===
Дефолтные настройки цефа:
* 1 Гб WAL = 4x256 Мб
* max_bytes_for_level_base и max_bytes_for_level_multiplier не изменены, поэтому равны 256 Мб и 10 соответственно
* соответственно , L1 = 256 Мб
* L2 = 2560 Мб
* L3 = 25600 Мби т. д.
…Соответственно!
Rocksdb положит L2 на block.db, только если раздел имеет размер хотя бы 2560+256+1000 Мб (Мб — округлим вверх до '''4 Гб)ГБ'''. А L3 она положит на block.db, только если block.db размером хотя бы 25600+2560+256+1000 МБ = около '''30 ГБ'''. А L4, соответственно, если ещё +256 ГБ, то есть итого '''286 ГБ'''.
== Снапшоты ==
В общем, наговнокодили — мама не горюй…
== EC ==
EC ещё больше снижает iops-ы, так как добавляется цикл Read-Modify-Write. [[#RAID WRITE HOLE]] в цефе закрыт, поэтому при записи все OSD сначала делают вторые копии объекта (по-видимому, виртуальные, через тот же механизм virtual clone bluestore), а потом удаляют старые.
В моём примере на NVMe-шках — write iops с репликацией Q=1 примерно 1500, а с EC — примерно 500. Q=128 — примерно 25000 с репликацией и 10000 с EC.
== Контроллеры ==
: а) используется медленная эмуляция lsi-контроллера
: б) неправильно настроен кэш
=== Драйвер виртуального диска и ФС ===
* lsi — самый медленный
* virtio — самый быстрый, но до QEMU 4.0 не умел TRIM. Юзать надо его.
* virtio-scsi — достаточно быстрый. На самом деле, умеет multiqueue и поэтому на быстром хранилище (например, при прямом доступе к локальной NVMe) должен быть быстрее virtio — но в случае с Ceph это не так, так как цеф не настолько быстрый, чтобы multiqueue бессмыслениграл роль
=== cache=writeback ===
=== O_SYNC vs fsync vs hdparm -W 0 ===
У SATA и SCSI дисков есть два способа сброса кэша: команда FLUSH CACHE и флаг FUA (Force Unit Access) на команде записи. Первый — это явный сброс кэша, второй — это указание записать операцию на диск, минуя кэш. Точнее, у SCSI оно есть, а с SATA ситуация точно не ясна: в спецификации NCQ бит FUA есть, но по факту FUA большинством дисков вроде как не поддерживается и, соответственно, эмулируется ядром/контроллером (если контроллер не кривой).
По всей видимости, fsync() отправляет диску команду FLUSH CACHE, а открытие файла с O_SYNC устанавливает бит FUA на все команды записи.
# Блюстор блокирует запись в журнал записью на HDD. Когда включен спец.кэш, HDD начинает рандомно писать сильно быстрее, и блокировки при сбросе уходят. Действует кэш, естественно, временно — когда он кончится, производительность случайной записи опять упадёт. Однако плюс в том, что в Ceph-е этого, скорее всего, не произойдёт, так как скорость случайной записи ограничивается, собственно, самим Ceph-ом и распределяется по всем дискам кластера :).
# Однако, для обычных дисков без SSD-кэша отключение кэша тоже даёт выигрыш… есть гипотеза, что из-за того же тормоза с bluefs (проверю).
Более свежие тесты бенчилкой ceph-gobench на том же самом стенде. Версия Ceph Mimic 13.2.2, Bluestore, журналы на SSD.
osd.14 | 302 | 229 | 135 | Hitachi Ultrastar A7K2000 | HUA722020ALA330
</tab>
==== Примечания ====
Toshiba MG07ACA14TE тоже замечены в подобном поведении, см. обсуждение в списке рассылки: https://www.spinics.net/lists/ceph-users/msg60753.html
== Почему вообще Bluestore такой медленный? ==
* с prefer_deferred_size и min_alloc_size они, видимо, не игрались
* обновлённые диски не играют никакой роли гарантированно. 260000 или 310000 iops — для цефа никакой разницы нет.
=== Бонус: висян (vSAN) ===
[https://media-www.micron.com/-/media/client/global/documents/products/other-documents/micron_vsan_6,-d-,7_on_x86_smc_reference_architecture.pdf Micron Accelerated All-Flash SATA vSAN 6.7 Solution]
Конфигурация серверов:
* 384 GB RAM 2667 MHz
* 2X Micron 5100 MAX 960 GB (randread: 93k iops, randwrite: 74k iops)
* 8X Micron 5200 ECO 3.84TB (randread: 95k iops, randwrite: 17k iops)
* 2x Xeon Gold 6142 (16c 2.6GHz)
* Mellanox ConnectX-4 Lx
* Connected to 2x Mellanox SN2410 25GbE switches
«Соответствует конфигурации VMWare AF-6, по заявлениям дающей от 50K iops чтения на каждый сервер»
* 2 реплики (аналог size=2 в цефе)
* 4 сервера
* 4 ВМ на каждом сервере
* 8 диска на каждую ВМ
* 4 потока на каждый диск
Суммарный параллелизм ввода/вывода: 512
100%/70%/50%/30%/0% write
* «Baseline» (данные умещаются в кэш): 121k/178k/249k/314k/486k iops
* «Capacity» (не умещаются): 51k/66k/90k/134k/363k
* Задержка равна 1000*512/IOPS миллисекунд во всех тестах (1000мс * параллелизм / iops)
* '''Нет тестов задержки с низким параллелизмом'''
* '''Нет тестов линейного чтения/записи'''
Заключение:
* ~3800 iops на запись в пересчёте на каждый диск данных
* ~1600 iops на запись в пересчёте на диск, если данные не влезают в кэш
* ~15000 iops на чтение в пересчёте на каждый диск данных
* ~11400 iops на чтение в пересчёте на диск, если данные не влезают в кэш
* Итого: при параллельной нагрузке в данном тесте vSAN смотрится хуже, чем Ceph
* С другой стороны, vSAN гиперконвергентный, а Ceph, в идеале, нет — или тормозит сильнее, чем мог бы
== Модели ==
* В случае HDD — полезны HDD со встроенным SSD-кэшем. Например, почти все большие Seagate EXOS таковы, хоть на них это часто и не заявлено.
* …и им тоже бывает полезно отключить кэш (hdparm -W 0). Только проверьте, что это улучшает iops-ы, а не ухудшает.
* SMR HDD не использовать под Ceph никогда.
* Отключить powersave: cpupower frequency-set -g performance, cpupower idle-set -D 0
* Отключить электронные подписи: <br /><tt>cephx_require_signatures = false<br />cephx_cluster_require_signatures = false<br />cephx_sign_messages = false</tt><br />(и монтировать rbd map / cephfs ядерным драйвером с опциями <tt>-o nocephx_require_signatures,nocephx_sign_messages</tt>)
* min_alloc_size=16384 (так и было по умолчанию, в последних версиях поменяли на 4096 и я рекомендовал 4096, а похоже, что зря)
* Актуально для версий до Nautilus включительно — <tt>[global] debug objecter = 0/0</tt> (там большой тормоз на клиентской стороне)
* В QEMU юзать virtio* Если у вас All-flash кластер и вам критичны либо iops-ы случайной ''синхронной'' записи (fsync/O_SYNC, например в случае СУБД), либо суммарные iops-ы ''параллельной'' случайной записи, то нужно отключить rbd cache (в qemu опция cache=none). Если не критичныили у вас HDD, лучше установить поставить cache=writeback.* Чтобы мог работать cache=unsafe, поставить <tt>[global] rbd cache writethrough until flush = false</tt>
* <s>Для HDD-only или Bad-SSD-Only и версий до Nautilus включительно — снять ручник https://github.com/ceph/ceph/pull/26909</s> - уже влит
* Внутри ВМ: <tt>mount -o lazytime</tt>
== Примечание ==
Написанное в статье актуально для версий Ceph, доступных на момент последней правки (см. «История» вверху страницы). Конкретно — для 12 -15 luminous-octopus. Различия между версиями минимальны, 13 mimic, да и 14 nautilus тоже — всё пока что актуально. Если вдруг в будущем что-то пофиксят и всё вдруг станет чудесно быстрым — сам побегу обновляться первым и поправлю статью :).
== См. также ==
* https://www.ixsystems.com/community/resources/list-of-known-smr-drives.141/ - список SMR дисков (вероятно, не полный)
* http://vasilisc.com/bluestore-ceph-2017 - кое-что про bluestore, местами не совсем верно, но тем не менее
* https://amarao-san.livejournal.com/3437997.html - «IOPS не существует» — сказ о latency
