Серверная оптимизация *

Я много думал о том, как проектируются промежуточные представления (IR) для компилятора. В этом посте я поделюсь с вами некоторыми идеями, к которым я пришёл, и поясню, почему считаю их важными.

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

Она существует примерно в паре трактовок. Исходим из того, что в каждый момент времени компилируем один какой-то метод, а не занимаемся чем-то сближающимся с трассировкой (трассировка, трейслеты, версионирование базовых блоков, т.д.).

Для ясности: я бывший инженер и учёный НАСА с докторской степенью в области космической электроники. Я также проработал в Google 10 лет в различных подразделениях компании, включая YouTube и тот отдел облачных технологий, который отвечал за развёртывание ИИ-ресурсов, поэтому я вполне компетентен высказать своё мнение по этому вопросу.

Краткая версия статьи: это абсолютно ужасная идея, которая действительно не имеет никакого смысла. Для этого есть множество причин, но все они сводятся к тому, что электроника, необходимая для работы центра обработки данных, особенно развёртывающего ИИ-ресурсы на основе графических процессоров (GPU) и тензорных процессоров (TPU), является полной противоположностью тому, что работает в космосе. Если вы раньше не работали конкретно в этой области, я бы предостёрег вас от поспешных выводов, потому что реальность обеспечения функционирования космического оборудования в космосе не всегда интуитивно очевидна.

Привет, Хабр! На связи команда Рег.облака. Мы запустили программу Free Tier полнофункционального облака с бесшовным переходом в основную инфраструктуру. Теперь любой желающий может заказать абсолютно бесплатно облачный сервер с минимальной конфигурацией с одним виртуальным ядром, 1 ГБ оперативной памяти и 10 ГБ пространства на NVMe-накопителе на срок до 6 месяцев и с возможностью ее расширения по запросу. 

Но статья не об этом. Один-два гигабайта — ресурс ограниченный. И сегодня мы попытаемся разобраться, что в него помещается, какой стек выбрать, на чем можно сэкономить, а на чем не стоит. Будет полезно всем, кто работает с недорогими VPS или оптимизирует расходы на ИТ-инфраструктуру.

Теги: Инфраструктура, LLM, Python, Прокси-серверы, Оптимизация

Когда GPU-кластер с vLLM задыхается от пиковых нагрузок, классический Rate Limiting и блокировка пользователей — это худший UX из возможных. А что если не отбрасывать запросы, а заставить саму языковую модель «сжать» свои промпты и стать предельно лаконичной, выдавая только самую суть? В этой статье мы разбираем архитектуру LazyGate — open-source шлюза, который в фоновом режиме читает метрики видеокарты и с помощью системных промптов динамически регулирует «болтливость» нейросети, кардинально спасая метрику Time-to-First-Token.

В серверной разработке кэш влияет не только на скорость ответа. От него напрямую зависят стоимость обработки запроса, нагрузка на базу, поведение системы под пиком и предсказуемость масштабирования. Именно поэтому практика кэширования имеет сегодня столько нюансов и разновидностей, если вы хотите реализовать что-то особенное или применить сложную схему кэширования, от ваших специалистов потребуются специальные навыки и умения. Под катом — рассказ о том, как мы ушли от кастомного кода к использованию гибридного кэша из .Net Framework, с какими сложностями столкнулись на этапе масштабирования системы, и как решали вопросы инвалидации кэша в процессе развития нашего проекта API Hub.

Привет, Хабр.

Хотим поделиться с вами новостью о том, что завершаем более чем годичный фундаментальный проект - готовимся к выпуску русского издания знаменитой книги Дениса Бахвалова "Performance Analysis and Tuning on Modern CPUs: Learn to write fast software like a pro". Денис теснейшим образом взаимодействовал с нашими редакторами, мы составили глоссарий к русскому изданию и уверены, что книга на долгие годы станет де-факто главным пособием по оптимизации производительности CPU. Книга выросла из многочисленных практических исследований, которыми Денис занимается в компании "Intel", и в качестве анонса мы хотим предложить вам перевод статьи автора, которая вышла ещё в 2019 году и может считаться рассказом о том, как зародилась идея будущей книги. В тексте под катом содержатся многочисленные ссылки на статьи Дениса из блога https://easyperf.net/notes/, который также рекомендуем пристально изучить. Русскую книгу ждите в мае. Далее - от автора.

Доброго времени суток, уважаемые хаброжители! Сегодня поговорим о данных — о той самой основе, без которой в классическом машинном обучении да и в deeplearning, по большому счёту, не происходит вообще ничего, от слова совсем: ни обучения моделей, ни проверки гипотез, ни сколько-нибудь осмысленных выводов, ни построение пайплайнов. И в квантовом машинном обучении история, в сущности, та же самая. Только вот сами данные здесь устроены несколько иначе — и вот здесь как раз начинается самое интересное ;) Когда впервые слышишь словосочетание квантовые данные, реакция, как правило, одна из двух: либо это звучит как что-то из научной фантастики, где сейчас из-за угла выйдет кот Шрёдингера и испортит вам датасет, либо как "ну хорошо, ещё один датасет, просто теперь с модной квантовой приставкой" и всякими наворотами. Сразу скажу: на практике всё интереснее и более вариативно. Именно, последнее и приобретает особо важную роль в современном мире ИИ.

В этой статье мы разберём следующие важные положения:

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

Я инженер, и у меня есть эдакий фетиш - все, что важно, должно находиться под моим контролем. Локально, в железе, которое можно измерить осциллографом, нагрузить до упора и при необходимости перепаять. Когда ты привык работать со схемами, сигналами и источниками питания, становится странно отдавать вычисления куда-то наружу и надеяться, что там “все нормально работает”.

В этой статье собираем локальный вычислительный кластер для дома, тихий чтобы стоять дома, максимально эффективный по соотношению цена-вычислительная мощность.

С 1947 года, когда появилась первая память с произвольным доступом — трубка Уильямса, — базовый принцип хранения данных в оперативной памяти фундаментально почти не изменился. За это время процессоры стали на порядки быстрее, но по-прежнему значительную часть времени они тратят на ожидание данных. Этот разрыв известен как «стена памяти» (Memory Wall), и именно он всё сильнее влияет на экономику современной инфраструктуры. Достаточно посмотреть, какую долю в стоимости сервера сегодня занимает RAM.

Мы покупаем терабайты памяти, но существенная её часть нередко остаётся «холодной»: ресурсы зарезервированы, потребляют энергию и стоят дорого, но используются далеко не полностью. В эпоху дефицита памяти, in-memory-приложений, искусственного интеллекта и других высоконагруженных систем такая неэффективность обходится слишком дорого.

А что, если эффективный объём доступной памяти можно заметно увеличить за считаные минуты — без замены оборудования?

В этой статье я коротко пройду по истории RAM, объясню, почему проблема Memory Wall стала особенно острой именно сейчас, и покажу, к какой новой вехе может привести подход, который условно можно назвать Software-Defined Memory. Разберем, как технологии MEXT используют AI для оптимизации инфраструктуры под AI- и data-intensive-нагрузки.

Спойлер: иногда, чтобы «увеличить» память, не нужно покупать новую — достаточно радикально лучше использовать ту, что уже установлена.

Асинхронное логирование давно считается “очевидной оптимизацией”: вынесли запись в отдельный поток — и всё стало быстрее.

Но если копнуть глубже, оказывается, что это не совсем так.

В предыдущей статье я разбирал производительность популярных C++ логгеров и показывал реальные цифры:
👉 https://habr.com/ru/articles/1012874/

Там уже было видно, что хорошо оптимизированное синхронное логирование может быть очень быстрым.

В этой статье разберёмся, почему async logging не делает логирование быстрее само по себе, и что на самом деле происходит внутри:

Многие слышали, что разные модели видеокарт имеют разную экономическую эффективность, например, в майнинге, где часто используется понятие «хэш/Ватт». Однако, даже одна и та же видеокарта может работать с сильно разной экономической эффективностью в зависимости от настроек Power Limit и частоты. И это касается любых длительных вычислительных задач.

Давайте же посмотрим, как помощью простой школьной формулы Энергия = Время × Мощность оптимально настроить видеокарту и получить за каждый потраченный киловатт максимум полезной работы.

Загрузка процессора под 100% на сервере 1С – одна из самых частых и критичных проблем. Это приводит к торможению работы пользователей и, как следствие, к простою и убыткам для бизнеса. Причины могут быть как в прикладном коде, так и в особенностях работы платформы и серверного оборудования. В этой статье структурируем все основные причины высокой нагрузки на CPU, дадим краткий алгоритм диагностики и предоставим ссылки на детальные руководства по решению.

Это статья моего коллеги Андрея Бурмистрова, эксперта в сфере оптимизации производительности 1С.

Всем привет. Я Backend разработчик, в основном на Python и немного Go. Хотел бы рассказать про свой опыт оптимизации docker образов и написать некий «туториал». Он скорее будет полезен для разработчиков или начинающим DevOps. Для опытных DevOps инженеров, возможно будет мало интересного и полезного.

Логирование есть практически в каждом C++ проекте. Почти любой сервис, демон или библиотека рано или поздно обрастает строками вроде LOG_INFO(...) или logger.debug(...).

Чаще всего библиотека выбирается по привычке или популярности — spdlog, quill, easylogging++ и т.п. При этом редко кто проверяет, какую цену приложение платит за логирование.

В высоконагруженных системах логирование может выполняться:

Коротко для ленивых

В MariaDB 12.3 binlog можно хранить внутри InnoDB через binlog_storage_engine=innodb.

Главный эффект: вместо двух fsync() на commit остаётся один, поэтому на write-heavy нагрузке резко растут TPS и снижается tail latency.

В тестах из статьи прирост на полном durability-профиле составил примерно 2.4x–3.3x.

Backup, restore и ресинк реплик становятся проще, потому что binlog и данные теперь консистентны на уровне одного механизма хранения.

Цена за это: обязателен GTID, Galera пока не поддерживается, а innodb_log_file_size нужно подбирать внимательнее из-за роста объёма redo.

Если у вас обычная схема primary + async replica на InnoDB, эту возможность точно стоит хотя бы протестировать.

Привет, Хабр! У нас в Selectel самый короткий месяц года запомнился большими обновлениями. Пополнили линейку конфигураций мощными флагманскими серверами для AI-тренинга и кластерных задач, добавили поддержку ephemeralStorage в Cluster Autoscaler и Karpenter и выпустили новую версию SELECTOS. Делимся новостями под катом!

Когда у компании много сервисов и данных, то лучше всего иметь план Б на любую ситуацию, например когда нужно быстро оптимизировать ресурсы и работать в режиме «минус один дата‑центр» без просадок, в то время как утилизация серверов при этом стремится к 100%. Смертельный номер? Вполне посильная задача, с которой справилась команда Яндекс Go. 

Мы провели аудит и поняли, что у нас очень много синхронных походов из критичных сервисов в некритичные, а ещё и поллинг. И это требовало внедрения событийной модели. Тысяча микросервисов, 150 команд разработки, несколько языков программирования, и у каждого разработчика своё представление о том, как правильно читать сообщения из Kafka. Библиотека, которую мы раздали командам, быстро бы обросла форками, заплатками и костылями.

За шесть месяцев командой из шести человек мы превратили эту библиотеку в централизованную платформу Немезида. Сейчас на ней крутится больше 500 интеграций, а новую можно запустить меньше чем за четыре часа. 

Меня зовут Алексей Терентьев, я руководитель одной из служб отдела эффективности Яндекс Go. В этой статье я расскажу, как мы прошли путь от простого «прочитал — обработал — закоммитил» к по‑настоящему масштабной архитектуре: со всеми граблями, факапами и конкретными решениями.

Итак, у вас есть свой бизнес и IT-инфраструктура. А еще есть несколько проблем: сервис зависает под наплывом пользователей, соседи по облаку «крадут» ресурсы, виртуальная машина ждет, когда освободятся ресурсы процессора. Наверняка вы уже пробовали добавлять ядер и оперативной памяти: в итоге только получили счет побольше, а проблемы остались, да еще и утилизация ресурсов упала. Давайте разберемся, что могло пойти не так, почему увеличение ресурсов не всегда гарантирует лучшую производительность сервера и что сделать с облаком, чтобы повысить его эффективность и не выкидывать деньги на ветер.

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

Привет, Хабр! Меня зовут Андрей Шукшов. Я пишу YNMT в Яндекс R&D — это движок инференса, на котором работают почти все наши большие языковые модели (LLM). Бо́льшую часть времени я пытаюсь понять, почему некоторые вещи работают медленно и как сделать так, чтобы у них это получалось чуточку быстрее.

Если вы запускали локальную LLM, то, возможно, тоже удивлялись: почему железо, способное рендерить фотореалистичные миры в реальном времени, работает в темпе печатной машинки? В своей статье я попробую хотя бы отчасти ответить на этот вопрос. Под микроскопом посмотрим на механизм Attention в режиме генерации (декодирования) и, вооружившись лучшими современными практиками ускорения на GPU, объединим всю математику в один эффективный kernel, который выжмет максимум производительности из имеющегося у нас железа.