О вреде неправильных оптимизаций

[yleo]

Не надо такие статьи писать, это сильно мешает естественному отбору (а он — мудрый)!

;)

[outlingo]

Ну, отбор отбором, а людей таки слегка жалко.

[justhabrauser]

А сисадмины не люди?
Кто же их еще кормить будет?

[aamonster]

Э… Я правильно понял, что в облаке, даже не выставляя "nobarrier" у своей vm — не можешь быть уверен, что он не выставлен уровнем выше?

[gecube]

Абсолютно верно.

[outlingo]

Не совсем. Таки сервис-провайдеры достаточно разумны чтобы совсем уж в экстрим не влезать

[gecube]

Разные есть сервис провайдеры. Есть крупные, к которым клиенты идут, потому что они крупные. А есть мелкие, региональные. У которых даже своего ДЦ и нет, но клиенту деваться некуда — он не готов переплачивать *3 (опять же вспомню сравнения хетцнер вс амазон).
К тому же, проверить провайдера на то, что у него корректно реализован весь стек хранения… Попросту невозможно. Остается доверять. И это… Мы еще не говорим про самые обыкновенные баги в ПО...

[outlingo]

При построении облака провайдер сервиса понимает все эти факторы, поэтому экстремальных кейсов у него вряд ли будет — то есть посланый flush гипервизор нормально отадресует на сторадж, поэтому если вы отправили в виртуальной машину flush на диск и получили на него ответ — то данные сохранены. Главное, чтобы ваша виртуальная машина этот flush сделала.

[akhkmed]

Спасибо за статью, очень важную тему подняли.
Бытует мнение, что nobarrier допустим и оправдан для контроллеров с батарейным кешем. Как по-вашему, для серверных ssd с суперконденсатором он тоже работает без потерь данных?

[gecube]

Мне кажется, что вопрос не верен. Серверные ssd с супер конденсатором и с, и без nobarrier ничего не гарантируют. Я уж не говорю о ситуации, когда накопитель после аварийного выключения просто превращается в тыкву из-за ошибки в фирмваре, например. Слава Богу, такое не каждый день происходит

[akhkmed]

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

[outlingo]

В физической среде — да, SSD с power loss protection хватает. В виртуальной среде не факт, нужно чтобы все уровни корректно отработали. То есть если вы подадите такой SSD в виртуальную машину и укажете io=threads + cache=writeback|unsafe то nobarrier в гостевой машине создает риски, а если cache=writethrough|none или гостевая система нормально выдает flush — то опять всё становится нормально

[akhkmed]

Как понимаю, всё зависит от того, как подать SSD. И тут безопасный, но непрактичный вариант, как понимаю — отдать его целиком, как устройство.
Не могли бы порекомендовать другие безопасные, но более практичные способы «подачи»?

[outlingo]

Если у вас SSD с PLP, то тут скорее дело в настройках гипервизора. Несовместимые настройки это nobarrier в виртуалке в сочетании с cache=writeback или cache=unsafe на гипервизоре. Ну и вообще cache=unsafe — он аналогичен безальтернативно включенному nobarrier в гостевой машине. Всё остальное работает нормально.

[yleo]

Проще и сложнее одновременно:

• От приложения до условной поверхности диска у вас могут быть несколько посредников: какой-нибудь asyncio-фреймворк, ядро, гипервизор, кеширующий контроллер с батарейкой или без, контроллер диска с батарейкой/конденсатором или без.
• Если хотя-бы кто-то из посредников "без батарейки" пере-упорядочивает запись, то целостность данных не гарантируется.

[gecube]

Так рекомендации какие? Я для себя вижу так.

1. Обращение в техпод облака. Да, мы узнаем настройки в моменте, но они могут поменяться в любой момент, и мы об этом не узнаем.
2. Строить распределенной систему с репликацией и пр. При этом мы теряем в быстродействии — rtt никто не отменял.
3. Использовать managed решения. Те же БД. Они "как бы" гарантируют определенной уровень целостности и у нас не болит голова о низкоуровневых вещах вроде nobarrier.
4. Ваш вариант

[outlingo]

Любой вариант на ваше усмотрение — все имеют право на жизнь. Если с инфраструктурой не хочется заморочек — managed DB. Если надо чего то необычного от БД типа установки нетиповых расширений — то вариант 2. А техподдержка ответит «не надо отключать nobarrier, это категорически не рекомендуется»

[akhkmed]

Есть ещё и такая сторона вопроса: если ты уже сидишь на виртуалке в чужом облаке, по каким-то признакам можно понять, что всё настроено правильно и данные не пропадут из-за кривых настроек гипервизора?

[yleo]

Никак, кроме как попросить посадить вас на медленные HDD и мониторить latency ;)

[Sly_tom_cat]

К сожалению это тоже ничего не гарантирует.

[outlingo]

Понять невозможно.

Можно предположить что «что-то не так» если виртуалка показывает нереально хорошие цифры в коротком тесте fio --rw=randwrite --runtime=1 --direct=1 и те же цифры с fio --rw=randwrite --runtime=1 --direct=1 --fsync=1. Естественно, тестировать напрямую на блочном устройстве а не на файле на файловой системе, то есть тест «деструктивный».

Но даже тогда достоверно сказать что «меня кидают» нельзя — может вашу машину положили на супер-пупер SSD локально на гипервизоре.

[amarao]

поправки:
1) unsafe в qemu разрешает ему игнорировать запросы на синхронизацию (даже когда они приходят).
2) SSD, которая может сделать 2000 flush'ей в секунду (во время записи) — это крутая энтерпрайзная SSD. Консьюмерские выдают порядка 100 или даже меньше.

[outlingo]

Самые убогие которые я видел меньше 250 не выдавали, а хоть сколь-нибудь приемлемые 500-600 и выше. Микрон который сейчас в десктопе отдает ~1000

[amarao]

А как вы бенчмаркали? Выше вы приводили хорошую строчку, вот её полная версия: fio --rw=randwrite --runtime=1 --direct=1 --fsync=1 --iodepth=32 --filename=/test --size 4G--ioengine=libaio Важно запускать её на файловую систему, а не на блочное устройство, потому что на блочное устройство не проходил fsync когда я проверял это.

[outlingo]

Без синка 36K IOPS: fio direct.fio --filename=/dev/mailbox/xxx --rw=randwrite --iodepth=1 --runtime=30

С синком 1K IOPS: fio direct.fio --filename=/dev/mailbox/xxx --rw=randwrite --iodepth=1 --runtime=30 --fsync=1 --fdatasync=1

[amarao]

fsync/fdatasync взаимоисключающие (fdatasync облегчённая версия fsync). В списке ключей ещё добавить --direct=1 и --blocksize=4k. Ваша цифра выглядит довольно крутой, и я не думаю, что какие-то устройства покажут сильно больше без мухлежа с writeback'ом.

[outlingo]

При тесте на устройстве что fsync, что fdatasync равнозначны — результаты одни и те же. Мы взяли за основную практику не делать тестов поверх ФС, чтобы не добавлять оверхеда и спецэффектов от файловой системы.

[amarao]

У вас получилось сделать SCSI-команду SYNCHRONIZE CACHE при использовании --fsync=1 для блочных устройств? Я вот, сколько не смотрел scsi-логгинг, ни разу не сумел добиться.

Я пребываю в уверенности, что без использования файловой системы заставить делать SYNCHRONIZE CACHE с помощью fio не получится. Если кто-то найдёт как — я буду очень благодарен.

[outlingo]

Не занимались этим. Ограничились тем, что убедились что выставляется pre-flush на запросы — тем более, что у нас virtio-blk а не virtio-scsi

[amarao]

Так вот, вы уверены, что fio по блочному устройству хоть что-то такое отправляет и оно транслируется уровнем ниже? У меня большие сомнения.

[outlingo]

Я внимательно прочёл документацию к ядру в Documentation/block касающуюся writeback cache, запустил fio без синков и с синками и действительно увидел обещание поведение когда на устройство отправляются пустые bio с флагом pre-flush — поэтому да, я уверен что запросы на сброс кэша на устройство отправляются. Не вижу причин не доверять увиденному

[amarao]

Окей, я перепроверю. В тот момент у меня оказалось, что fio на блочном устройстве с fsync не может воспроизвести нагрузку от ceph'а на OSD (т.к. на OSD идёт много flush'ей). Возможно, либо я сделал там какую-то ошибку, либо что-то с тех пор поменялось.

[outlingo]

Насчет cache='unsafe' — да, оно разрешает игнорировать flush'и, просто описывать его логику не показалось необходимым.

[amarao]

Я к тому, что если виртуалка запущена в режиме cache-unsafe, дальше уже не важно, есть там barrier или нет.