Andy Melnikov (nponeccop) wrote,
Andy Melnikov
nponeccop

Category:

I/O Blender

Немного ресерча показало, что проблема взаимного влияния IO известна с "доклаудных" времён. Но пытались её решить для энтерпрайз-окружений (в противоположность хипсторским), где надо пускать legacy workload as it is no matter what.

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

И борятся лишь "надсистемными" методами, не затрагивая архитектуры приложения и гостевой ОС. Типа "а давайте в линух сделаем хитрую файловую систему". Или "а давайте сделаем хитрый NAS/SAN/DAS". Вплоть до rack-level PCIe switches не как supercomputer interconnect, а чисто для нужд scalabla SAN. Ну чтоб LAMP-сайтики в впсках под KVM нормально продолжали бегать, когда их становится много.

Усугубляет эту ситуацию то, что в ОС и хардвари понаставили невероятное количество подпорок, чтобы говнокод существ, недостойных гордого звания обезьяны, работал с удовлетворительной скоростью.

В результате у нас есть говноапи ввода-вывода, задизайненный когда не то что TCQ, а UDMA не было и в помине. Т.е. когда диски не обладали не то что очередями и умными контроллерами, но даже автономностью от цпу.

Я так и представляю - пишем в три порта номер головки, цилиндра и сектора. В четвертом устанавливаем битик. Поллим в цикле пока новый битик не появится. Читаем байты в цикле, отбитом до нужных задержек нопами. Прочитали? Следующие CHS-координаты грузим и ждем пока головки переместятся и заголовок нужного сектора по кругу до нас доедет. Ещё можно вспомнить что баз не было и люди реально использовали файлы структов с именами и фамилиями отбитыми нуликами до фиксированной длины.

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

Давайте же брать пример с Алана Кея и редизайнить весь стек! Тем более что гипервизоры позволяют творить в своём огороде что угодно. Собственно, идея в том, что сохраняем условный AWS, но гостей редизайним нахуй. В идеале конечно и интерфейс гиперколлов, но пока в его качестве можно использовать IP.

В одном из пейперов я увидел пример с тем, во что превращается фрагментация диска после блендера.

Допустим, у нас хорошее приложение и пишет на диск большими блоками. Т.к. у нас нет оверпровижионинга, диск почти заполнен. В этой ситуации экстенты не помогаеют и блоки начинают дробиться, так что случайная запись рандомизируется. Что было и до блендера.

Далее в дело вступает thin provisioning. Поскольку файловая система у нас лежит не на физическом оверпровижонед диске, а на диске, аллоцируемом по требованию, по сути получается файловая система внутри файла лежащего на другой файловой системе (не важно, физически это реальная файловая система с VMDK/VXD-файликами или же thin provisioned scsi). И возможна фрагментация второго порядка.

Далее это все лежит у нас на каком-то log structured smart san, который структурирует все операции записи в колбасу. И там как в любом log structured storage своя фрагментация третьего порядка и непрерывная дефрагментация.

И наконец этот smart san использует SSD-диски у которых свой собственный NIH log structured storage под названием FTL. И там своя фрагментация четвертого порядка.

Часть из этого конечно неизбежное зло. Типа FTL. Есть статьи по дискам, которые умеют отдавать свой FTL наружу чтобы его могла использовать файловая система. Но самих таких дисков в виде COTS пока нету. Но что-то делать можно.

Например, если писать сразу в object store (это такой key value store, в котором ключи типа гуиды рандомные) - то благодаря отсутствию промежуточных файловых системы и тонкого тома у нас пропадают первые две фрагментации. Остается только "верх" и "низ" - код приложения (потенциально плохой т.к. object store APIs могут не поддерживать групповые операции) и всё что ниже smart log structured san

Но задача стоит не просто сделать object store с групповыми "длинными" операциями, а такой сторе, поверх которого можно пустить и файловые системы, и RDBMS, и лигаси блочную нагрузку, и все будут знать о всех слоях и уметь под это оптимизить, и в котором всё это не будет дробиться в смузи и друг другу мешать.
Tags: io optimization, programming
Subscribe

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 9 comments