Методы получения высокой производительности систем
На связи Денис Волков из команды платформы данных в Yandex Cloud. В предыдущей статье мы рассказали, как устроен SPQR (Stateless Postgres Query Router): архитектура, компоненты и принципы. Красивая теория. Эта статья — про то, что происходит, когда теорию начинаешь применять к живому продакшену с десятками таблиц, набором микросервисов и новогодней нагрузкой. Про грабли, решения и конечно же проблемы.
Если говорить о производительности вне существующих решений в железе, то интуиция будет подсказывать достаточно простую модель выполнения, когда процессор обрабатывает инструкции, а память поставляет данные, и чем быстрее и то и другое, тем быстрее работает программа.
Но процессоры научились выполнять миллиарды операций в секунду, а память наращивает скорость доступа намного медленнее, и разрыв между скоростью вычислений и доступа к данным стал настолько большим, что именно ожидание памяти, превратилось в главный источник потерь производительности.
Ответом на это стало не ускорение памяти, а усложнение самих процессоров, которые перестали быть просто пассивными исполнителями кода и стали решать задачи управления потоком данных: выполнять инструкции вне порядка, переупорядочивать зависимости и на каком-то этапе подошли к идее спекулятивно исполнять код, который, возможно, вообще не понадобится.
Предсказание ветвлений стало один из ключевых механизмов в этой системе, которая должна была снять часть времени простоя потока вычислений, но если удачное предсказание стало возможностью начать дорогие загрузки заранее и скрыть их латентность, то ошибка предсказания скрывает не только потерянные такты, но и зря использованные ресурсы памяти: шину, буферы загрузки, пропускную способность контроллера и сами кэш-линии, которые могли бы быть заняты полезными данными.
Именно здесь возникает интересный и неочевидный компромисс, позволяющий с одной стороны, писать branchless-код и полностью избавиться от ошибок предсказания, а с другой лишающий процессор возможности работать на опережение и запускать доступ к памяти раньше времени. Но в зависимости от того, где находятся данные в памяти выигрывать будет то один, то другой подход.
Если вы собираетесь писать branchless код, надо помнить как именно спекулятивное выполнение и предсказание ветвлений взаимодействуют с подсистемой памяти, потому что “лишняя работа” иногда ускоряет программу, а в некоторых случаях попытка сделать код более “предсказуемым” приводит к обратному эффекту.
Если вы хоть раз занимались корпоративной разработкой на Java, вы наверняка слышали про CUBA Platform. И нет — это не про Карибы.
CUBA — это full-stack Java-фреймворк для быстрой разработки бизнес-приложений: CRM, документооборот, ERP-подобные системы, внутренние инструменты и всё то, что принято называть словом «enterprise».
Я работал с ним на нескольких хакатонах и в паре реальных проектов. И у меня к нему сложные чувства — поэтому и пишу.
695 строк конфига, одна валидация, 10 GB upload limit по умолчанию и env-переменная, которая никогда не срабатывает. Десять ошибок управления конфигурацией, собранных из реальных проектов.
Банк как игровая площадка: обзор геймификации в российском банкинге.
Первый материал из серии обзорных статей «Геймификация по отраслям»
Привет, Хабр! 26 марта прошёл AntiDDoS-митап Wildberries & Russ. Поговорили про перфоманс-тесты и почему они спасают от сюрпризов в продакшене, про мощную защиту без ущерба для скорости и удобства интерфейса (UX), про то, как VM-обфускация меняет правила игры.
С 1947 года, когда появилась первая память с произвольным доступом — трубка Уильямса, — базовый принцип хранения данных в оперативной памяти фундаментально почти не изменился. За это время процессоры стали на порядки быстрее, но по-прежнему значительную часть времени они тратят на ожидание данных. Этот разрыв известен как «стена памяти» (Memory Wall), и именно он всё сильнее влияет на экономику современной инфраструктуры. Достаточно посмотреть, какую долю в стоимости сервера сегодня занимает RAM.
Мы покупаем терабайты памяти, но существенная её часть нередко остаётся «холодной»: ресурсы зарезервированы, потребляют энергию и стоят дорого, но используются далеко не полностью. В эпоху дефицита памяти, in-memory-приложений, искусственного интеллекта и других высоконагруженных систем такая неэффективность обходится слишком дорого.
А что, если эффективный объём доступной памяти можно заметно увеличить за считаные минуты — без замены оборудования?
В этой статье я коротко пройду по истории RAM, объясню, почему проблема Memory Wall стала особенно острой именно сейчас, и покажу, к какой новой вехе может привести подход, который условно можно назвать Software-Defined Memory. Разберем, как технологии MEXT используют AI для оптимизации инфраструктуры под AI- и data-intensive-нагрузки.
Спойлер: иногда, чтобы «увеличить» память, не нужно покупать новую — достаточно радикально лучше использовать ту, что уже установлена.
Всем привет, меня зовут Николай Голубев, я — техлид из компании HFLabs. Эта статья написана по мотивам моего выступления на конференции Saint HighLoad++.
В этой статье мы поговорим о том, как при помощи Debezium было реализовано резервирование Postgres для одного из наших заказчиков. Решение успешно внедрили и уже несколько лет оно используется в продакшене.
Мы обсудим постановку задачи, архитектуру и из каких компонентов состоит система, поговорим о штатном и аварийном переключении, а затем об адаптации и эксплуатации решения. В конце мы подведём итоги и попробуем понять, в каких случаях такой подход подойдёт или не подойдёт.
Многие слышали, что разные модели видеокарт имеют разную экономическую эффективность, например, в майнинге, где часто используется понятие «хэш/Ватт». Однако, даже одна и та же видеокарта может работать с сильно разной экономической эффективностью в зависимости от настроек Power Limit и частоты. И это касается любых длительных вычислительных задач.
Давайте же посмотрим, как помощью простой школьной формулы Энергия = Время × Мощность оптимально настроить видеокарту и получить за каждый потраченный киловатт максимум полезной работы.
80k RPS и 25 Гбит/с трафика тайлов с одного сервера — звучит как мечта для картографического сервиса? На самом деле это реально — если ваш способ отдачи тайлов спроектирован для этого.
С момента появления первых веб‑карт подходы к хранению картографических данных сильно изменились. В этой статье я разберу эволюцию от классических методов до современных облачных форматов и расскажу о нашем собственном решении с интересными алгоритмами индексации, а также зачем нам для этого понадобились деревья и алгоритмы цифровой сортировки.
Поделюсь опытом того, как мы отказались от сложного рендеринга на бэкенде, упростили инфраструктуру и эксплуатацию, а заодно перестали бояться пиковой нагрузки. Покажу, как это позволило нам отдавать сотни экспериментальных вариантов подложки Карт, используя в качестве бэкенда только S3.
Добрый день, дорогие читатели!
Поделюсь с вами опытом составления артефакта, который объединяет уровни абстракции проектируемого решения в одном месте: развертка вариантов использования по статусной модели с маппингом на API.
Статья родилась в ходе наблюдения за одной из систем на Postgres, что у нас на поддержке. Результаты наблюдения несколько удивили, поэтому делюсь, ибо причинно-следственные связи далеко не очевидны.
Триггером к изучению, можно сказать, даже к расследованию, послужило событие, когда однажды утром сервер PG завалился, потому что процессы postgres заняли всю память.
Привет, Хабр!
Меня зовут Елизавета Колесникова, и вот уже 4 года я работаю системным аналитиком СПАО «Ингосстрах»
Этой статьёй я бы хотела начать серию материалов для аналитиков и разработчиков, которые только начинают свой путь в ИТ.
Когда-то я сама жестко плавала в бульоне ИТ-терминов, а также тыкалась по разным сайтам в поисках подходящей информации, как слепой котенок, без возможности соединить воедино полученные данные таким образом, чтобы моих интеллектуальных ресурсов хватило для написания ТЗ. Толковых гайдов и памяток я не находила, в основном попадалась или сухая теория, или жидкая вода. Поднабравшись немного опыта, я решила составить серию памяток, где буду расписывать ключевые вопросы, которые помогут начинающим специалистам разобраться, как писать ТЗ по интеграциям.
Если вам прилетала задачка, в рамках которой необходимо продумать, как Kafka будет взаимодействовать с вашей системой, но вы не особо знакомы с этой платформой, то моя памятка — как раз для такого случая.
Чем покупка букета на 8 Марта через Яндекс Еду отличается от покупки, собственно, еды? С точки зрения пользователя — ничем. Выбрал, оплатил, доставили. А вот с точки зрения разработчика бэкенда заказ уникальных букетов превращается в нетривиальную инженерную задачу синхронизации складских запасов. Задержка синхронизации хотя бы в 10 минут трансформируется в звонок и сборщиков заказов, сообщающих о том, что именно такого букета на складе больше нет.
Меня зовут Виталий Московкин, я занимаюсь ритейлом в Яндекс Еде. В статье я расскажу, как мы синхронизировали состояние складов с 18 миллионами уникальных товаров: сначала с помощью PostgreSQL, а затем с помощью YDB. Такое количество товаров превращается на бэкенде в 4 миллиарда записей о ценах и стоках, которые нельзя просто так кешировать. Но и замена монолитной СУБД на распределённую тоже задача не на десять минут. Подробности — под катом.
Apache AGE добавляет графы и Cypher в PostgreSQL. Мы написали бенчмарк, прогнали три типа нагрузки и обнаружили, что поиск кратчайшего пути выдаёт 7 TPS, а вставка вершин деградирует из-за SeqScan в функции проверки существования. Один патч — и TPS вырос в 15 раз. Рассказываем, как до этого докопались.
Индустрия генеративного искусственного интеллекта больна. Симптомы этой болезни видны невооруженным глазом: шесть пальцев на руках, нарушенная геометрия объектов в движении и рассинхрон звука с артикуляцией (AV-desync). Но вместо того, чтобы лечить причину математикой, техногиганты пытаются заглушить боль грубой силой, заливая проблему деньгами и сжигая мегаватты энергии на кластерах Nvidia H100.
Сегодня мы наблюдаем классическую архитектурную ошибку: попытку решить фундаментальный математический изъян экстенсивным наращиванием "железа". И эта гонка приведет к неизбежному краху текущей бизнес-модели монополистов.
Почему эксплуатация современных баз данных всё чаще напоминает сборку сложного карточного домика, я уже разбирал в прошлых статьях. Теперь самое интересное: как построить движок, чтобы этих проблем избежать.
В этой статье я открываю капот своей OLTP-базы данных, которую пишу с нуля на Rust.
Это не обзор готового коробочного решения, а честный рассказ про инжиниринг на раннем этапе. Я покажу, как абстрактные идеи вроде «fail-closed контрактов» превращаются в работающий код, почему я выбрал UNDO-log MVCC вместо Multi-version Heap и зачем всё это упаковывается в PostgreSQL-wire протокол. Архитектура ещё подвижна, и сейчас — лучшее время, чтобы обсудить её с теми, кто каждый день эксплуатирует БД в продакшене.
Если вы администрируете Postgres Pro Enterprise и ваша инфраструктура охватывает несколько дата-центров, вы наверняка сталкивались с одной и той же проблемой: репликация начинает «есть» межцодовый канал и нагружать основной сервер. В новой версии BiHA появилось решение — каскадная репликация. Рассказываем, как она работает и когда стоит использовать её.
Если API начинает тормозить, первое решение обычно очевидно — добавить Redis. Но иногда оказывается, что проблема гораздо проще. В одном из сервисов PostgreSQL начал упираться в повторяющиеся запросы. Одни и те же данные запрашивались тысячами клиентов. Практически каждый HTTP-запрос заканчивался одинаковым SQL-запросом. Любопытство победило — вместо готового решения был написан небольшой кэш прямо внутри сервиса. На это ушло примерно полчаса. Результат оказался неожиданным: некоторые эндпоинты ускорились почти в 7 раз. Вот, почему это произошло и как работает такая схема.
Логирование есть практически в каждом C++ проекте. Почти любой сервис, демон или библиотека рано или поздно обрастает строками вроде LOG_INFO(...) или logger.debug(...).
Чаще всего библиотека выбирается по привычке или популярности — spdlog, quill, easylogging++ и т.п. При этом редко кто проверяет, какую цену приложение платит за логирование.
В высоконагруженных системах логирование может выполняться: