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

«Зелёный коридор» (ЗК) — проект перестроения культуры потребления ресурсов в масштабах «цифрового государства». Чтобы вы понимали масштаб инфраструктуры, которой мы управляем:

8 000 000 физических ядер;

1,2 экзабайта данных в хранилищах;

Почти 600 000 серверов, считая виртуальные машины.

Когда работаешь с такими объёмами, даже микроскопическая погрешность в 1% лишней аллокации превращается в гору «мёртвого железа», на котором можно было бы запустить ещё один банк средних размеров. В начале наше фактическое потребление ресурсов находилось в районе 27%.

Каждый Java-объект в HotSpot начинается со служебного заголовка размером 12 байт. В JDK 27 по умолчанию он сжимается до 8 — это JEP 534, финальный шаг внедрения Compact Object Headers. Для типовых бэкендов это 5–15% экономии heap, для приложений с миллионами мелких объектов (особенно на Scala, Clojure и иммутабельных коллекциях) — до 30%, без изменений в прикладном коде.

Месяц назад я начал делать pet-приложение для государственных закупок: свайпай тендеры как в Tinder, видишь AI-скоринг заказчика — стоит ли вообще лезть. Для скоринга нужны данные обо всех контрактах заказчика. Источник один — ЕИС zakupki.gov.ru. И тут начались сюрпризы.

SOAP-API требует ЭЦП юр.лица — отвал на старте. FTP-сервер с XML-выгрузками закрыт с 1 января 2025. OpenData портал — красивый каталог датасетов, но без единой ссылки на скачиваемый файл. Часа три я экспериментировал и сдался.

Остаётся HTML-парсинг публичных страниц. Дальше всё интереснее: 44-ФЗ и 223-ФЗ имеют разную вёрстку, заказчик идентифицируется тремя разными форматами одновременно (real_inn / orgId / orgCode), а НМЦК и дата эл.акта приёмки лежат вообще не там, где подсказывает имя URL.

В статье — архитектура на Vapor + Redis + PostgreSQL, код канонизации ИНН, четыре грабли где я тормозил по нескольку часов, и реальные цифры: 128k+ строк контрактов в БД, ~340 уникальных заказчиков с полным скорингом, ~100ms средняя latency на feed-запрос.

Если кто-то знает легальный путь к данным ЕИС без ЭЦП юр.лица — буду благодарен в комментах. Может я что-то упустил.

Всем привет! Меня зовут Петя Портнов, я работаю в Ozon ведущим разработчиком в команде среднего поиска — слоя, который ранжирует поисковую выдачу.

Представьте, что вы вводите запрос в поисковую строку маркетплейса. За этим простым действием скрывается сложный поисковый пайплайн: миллионы товаров фильтруются, ранжируются и сортируются по релевантности. Но как именно система решает, что показать первым? В основе этого решения лежат вычисления, среди которых — сотни разнообразных формул, учитывающих цену, рейтинг, популярность, персонализацию и другие факторы. По мере развития системы таких формул становится всё больше, а сами они усложняются. В какой-то момент вычисления превращаются в узкое место: начинают потреблять значительную долю CPU, создают множество промежуточных объектов — и так для каждого поискового запроса. Возникает вопрос: как снизить стоимость таких вычислений в JVM?

В этой статье я расскажу, что сделали мы, чтобы снизить нагрузку на систему: как заменили интерпретирующий движок формул на динамический компилятор, выполняющий построение эффективного байт-кода, отлично векторизующегося JIT-компилятором. Это текстовая версия доклада с Joker 2025 с дополнениями, которые не вошли в выступление или появились в проекте уже после конференции.

Привет, Хабр! Меня зовут Дмитрий Гоголев, я директор по развитию платформы для управления виртуальной и облачной инфраструктурой Cloudlink в Orion soft. За последний год это решение прошло довольно заметную эволюцию. Если раньше это была классическая CMP (Cloud Management Platform) для управления виртуализацией, то сейчас платформа все больше становится универсальным слоем управления инфраструктурой и сервисами — как для on-prem, так и для публичных облаков.

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

Если вы хоть раз поднимали Laravel-проект в Docker Compose, наверняка сталкивались с ситуацией: контейнер с приложением стартует раньше, чем база данных успевает принять соединения, и миграции падают с ошибкой SQLSTATE[08006] или Connection refused. Перезапустишь — всё работает. На локалке терпимо, но в продакшене — это в падающие деплои.

По умолчанию Docker считает контейнер «живым», если его процесс запущен. Но это не всегда означает, что сервис внутри готов к работе.

Решение — правильно настроенные healthcheck’и и условие depends_on с параметром condition: service_healthy. В этой статье разберём, как это сделать для типичного стека Laravel: PHP-FPM, PostgreSQL, Redis и Nginx.

Провести честный тест на 30 000 ВРМ, сжечь 400 тысяч процессорных ядер-часов и доказать, что отечественная связка из RED OS, 1С и Postgres Pro Enterprise способна стабильно держать промышленную нагрузку в 1 Тб — выполнено. Рассказываем историю одного большого нагрузочного тестирования длиною в три месяца

Это вторая часть цикла про mTLS. В первой разобрали теорию: как работает рукопожатие, от каких атак защищает и где принципиально бессилен. Здесь — практика. Разберём реальный сценарий: homelab на одном сервере с Traefik и Dokploy. Пройдём путь от модели угроз до конкретных попыток атаковать собственный сервер — с командами и объяснениями, что происходит.

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

На майском HPC User Forum в Остине AMD рассказали о MI430X — ускорителе серии MI400, который позиционируется как инструмент для научных вычислений. Пока индустрия увлечена инференсом и считает токены в секунду на FP4, AMD напомнила, что CFD-код (Computational Fluid Dynamics) не интересует, насколько быстро чип умножает восьмибитные числа.

Привет, Хабр! Меня зовут Сергей Ковалёв, я менеджер выделенных серверов в Selectel. В этой статье мы мысленно «разберем» MI430X и обсудим, насколько новинка подходит для «ядерных расчетов» и машинного обучения. Подробности под катом!

Каждый раз, когда пользователь открывает страницу каталога или дашборд со статистикой, база данных заново считает одно и то же. Запрос к 800 тысячам строк ради одного числа — снова и снова. Расширение pgpro_result_cache в Postgres Pro Enterprise решает эту проблему на уровне СУБД: результат тяжёлого запроса сохраняется в разделяемой памяти и при повторном обращении возвращается за миллисекунду — без сканирования, без нагрузки на процессор, прозрачно для приложения. В этой статье разберём, как это работает, когда кэш действительно полезен и на что нужно обратить внимание при настройке.

Этот дайджест получился объемным! В апреле команда Selectel презентовала Foundation Models Catalog, запустила VDS и Enterprise-grade ЦОД. И это лишь малая часть обновлений. Все подробности — ниже.

Случалось мне работать с CV: запускаешь сорокаминутное видео, YOLO честно находит людей, машины, собак. На двадцатой минуте падает сеть или, что хуже, камера наблюдения выходит из строя. Перезапускаешь. Модель снова смотрит те же кадры, снова инференс, трекинг ID, пошла пахота GPU…

Так продолжаться не может — подключаю кеширование.

Сегодня разбираемся, как совместить YOLO и кэширование Redis с трекингом объектов так, чтобы каждый кадр считался ровно один раз и чтобы информация не терялась. В конце будут готовые сниппеты, которые можно сразу скопировать и запустить.

Актуальное на сегодняшний день поколение серверных ускорителей AMD — это MI350X и MI355X на архитектуре CDNA 4. Это уже серьезные машины для обучения и инференса больших моделей — с соответствующей ценой и требованиями к электроснабжению и охлаждению.

Несколько дней назад AMD анонсировали GPU Instinct MI350P — первую с 2022 года PCIe-карту серии Instinct, которая устанавливается в любой сервер с поддержкой двухслотовых GPU с воздушным охлаждением. Удобно и универсально, новинку точно стоит рассмотреть подробнее.

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

Я работаю контент-маркетологом в Scalehost и по работе регулярно разбираю темы, связанные с производительностью веб-проектов. Вопрос “нужен ли сайту NVMe или это просто маркетинговая галочка” возникает так часто, что мне захотелось собрать его в один технически внятный разбор.

Я много думал о том, как проектируются промежуточные представления (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/, который также рекомендуем пристально изучить. Русскую книгу ждите в мае. Далее - от автора.