11 мая 2022 г.

Mystery of link imbalance #2: как можно починить MRU-пул

Я не удержался, и еще поэкспериментировал с симуляцией link imbalance из предыдущего поста. Там есть вопрос: как эту проблему исправить? Как сделать так, чтобы трафик не собирался на один-единственный канал?

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

Но у MRU есть преимущества: пул с такой стратегией минимизирует количество активных соединений. Это уменьшает нагрузку на сервер БД, плюс небольшое число активных соединений вероятнее будет горячим в кэше, как на стороне клиента, так и на стороне сервера БД. В статье не пишут, почему изначально в фейсбуке был выбран MRU-пул, но можно предположить, что именно поэтому.

Однако кажется, что можно сохранить преимущества MRU, но предотвратить link imbalance.

8 мая 2022 г.

Mystery of link imbalance (metastable failure)

Я люблю системы, где из простых элементов возникает какое-то нетривиальное поведение. Последний месяц я игрался с симуляцией одной такой системы из статьи "Metastable Failures in Distributed Systems"1

В статье целый ряд примеров мета-стабильных сбоев, но почти все они ретроспективно устроены довольно понятно. А зацепил меня пример от инженеров фейсбука: в их случае группы серверов в дата-центре связаны агрегированным сетевым линком – т.е. логический линк состоит из нескольких физических кабелей, по которым маршрутизатор распределяет сетевые соединения. В теории, распределение нагрузки по кабелям должно быть более-менее сбалансированным – но на практике инженеры постоянно наблюдали, как весь трафик непонятным образом кучкуется в один-единственный кабель, этот кабель оказывается перегруженным, растут задержки и потери пакетов. Сетевые инженеры меняют алгоритм распределения на маршрутизаторе, нагрузка пераспределяется по кабелям равномерно – но через короткое время весь снова трафик кучкуется в какой-то один кабель, и все повторяется.

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

30 января 2022 г.

Are You Sure You Want to Use MMAP in Your Database Management System?

Кажется, что отображение файлов в память (mmap) удобно использовать для реализации баз данных, потому что можно не реализовывать пул страниц, а бесплатно использовать всю машинерию виртуальной памяти, уже существующую в ОС – работать с данными как будто они лежат в памяти, и ОС позаботится почти обо всех деталях.

В статье Are You Sure You Want to Use MMAP in Your Database Management System?1 авторы аргументируют, что это удобство – иллюзия. Memory mapped files только выглядят удобно, у них есть неочевидные на первый взгляд недостатки, аккуратный обход которых потребует усилий, сравнимых с самостоятельной реализацией пула страниц.

Самая интересная и неожиданная для меня часть: одним из крупных преимуществ mmap часто называют производительность – отображение файлов в память позволяет уменьшить количество syscalls, и избежать копирования kernel -> user space, и потому должно быть быстрее обычных методов IO.

Авторы показывают, что и это тоже иллюзия: на скоростях современных SSD/NVM и при современных объемах данных пропускная способность чтения данных с диска через отображаемые в память файлы в 2-20 раз уступает пропускной способности прямого чтения в обход файлового кэша. Происходит это потому, что на больших скоростях и больших объемах ОС приходится очень часто загружать и выгружать страницы, и узким местом становится сама машинерия виртуальной памяти – обновление таблицы страниц (page table) и выгрузка страниц на диск (page eviction).