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

Какое-то время назад у меня возник инцидент с IOPS в продакшене (я уже писал о нём). Однако у меня не было никакой возможности замерить происходившее. Так как EBS скрывает от меня все механизмы, я решил замерить поведение того запроса в контролируемой мной среде. План такой: я выполняю один и тот же запрос трижды, каждый раз замеряя показания (сначала со страницами в общих буферах, затем со страницами, которые находятся только в кэше страниц операционной системы и, наконец, при чтении всего с диска). После этого я сравню результаты с двумя дисками, скрытыми под облачными абстракциями: с томом EBS из инцидента и с сервером Hetzner, бенчмарк которого я уже проводил.

Система довольно проста: моя домашняя машина с Debian. У меня работает Postgres 17 в Docker с shared_buffers = 16MB, track_io_timing = on. В качестве накопителя используется локальный SSD NVMe с ext4. Я намеренно создал таблицу такого размера, чтобы она не умещалась в кэш.

Есть привычная ошибка в техническом аудите больших сайтов: открыть краулер, поставить лимит побольше и просканировать всё.

На сайте в пару тысяч страниц это работает. На сайте с семизначным инвентарём URL — нет. Полный краул упирается в память, диск, сетевые таймауты, rate limit, JavaScript-рендеринг, дубли, параметры, бесконечные фасеты и в то, что через двое суток вы получаете таблицу на миллионы строк, которую всё равно придётся сегментировать с нуля.

Поэтому я начинаю не с краулера. Я начинаю с sitemap.

В статье показываю sitemap-first подход: как скачать sitemap graph, превратить URL в датасет, разобрать слаги на смысловые группы, сматчить паттерны со спросом, найти пустые посадочные, проверить рендеринг и потом подтвердить гипотезы через GSC, Яндекс.Вебмастер, Метрику и серверные логи.

На одном из проектов заказчика объём базы 1С:ERP достиг 16 ТБ, а регистр накопления «СебестоимостьТоваров» вырос до 4 ТБ и 2 млрд строк. При таких объёмах оптимизация перестала быть опцией и превратилась в обязательную задачу.

Симптомы были типичными для системы, которая упёрлась в пределы физического хранения: запросы к себестоимости выполнялись десятки минут, расчёт себестоимости тормозил, а серверный диск работал на пределе возможностей.

Были применены стандартные подходы к оптимизации: работа с индексами и статистикой, а также дефрагментация. Существенного эффекта они не дали.

Для решения задачи использовалось секционирование (партиционирование) таблиц на уровне MS SQL Server. Но, как оказалось, у 1С и секционирования сложные отношения. 

Меня зовут Владимир Андрейков, я руководитель группы разработки в GRI. Эта статья — разбор практического кейса из проекта заказчика. Она будет полезна тем, кто работает с крупными внедрениями 1С:ERP и упирается в ограничения SQL Server при больших объёмах данных.

_id в MongoDB кажется мелочью, пока не попадает в API, события и миграции.

Разбираем, когда оставить стандартный ObjectId, когда нужен UUID, почему его лучше хранить как BSON Binary subtype 4 и зачем иногда разделять внутренний и публичный идентификатор.

Одними из первых в России выпустили патчи безопасности в SELECTOS и закрыли уязвимости в ядре Linux. Расширили список моделей в FMC, чтобы вы могли автоматизировать больше задач. Больше деталей — под катом.

Она умерла в воскресенье вечером, и никто не услышал ни звука. Детективная история о том, как поставить прослушку на собственное приложение: Prometheus, Grafana, Micrometer, алерты, SLO. Все улики в комплекте, демо-проект прилагается. Совпадения с вашим продакшеном не случайны.

В базах данных в качестве первичных ключей часто используют случайные UUID. Один из известных недостатков случайных UUID заключается в том, что их неупорядоченность (UUID4) может вызывать большое количество дополнительных обращений к страницам кластеризованных индексов (clustered index), потому что строки вставляются в случайные места B-дерева, и его приходится постоянно перебалансировать. В этой статье я попытаюсь помочь вам выработать более интуитивное понимание того, как влияют на производительность все эти дополнительные операции со страницами.

Хотя статья посвящена конкретно SQLite, проблема случайных UUID касается и других баз данных, использующих кластеризованные индексы.

Привет, Хабр! На связи команды Рег.облака и ispmanager. Не так давно в Рег.облаке мы запустили программу Free Tier — бесплатный облачный сервер, и разбирали в отдельной статье, что реально помещается в один-два гигабайта оперативной памяти. Теперь у программы вторая фаза, FT2: тот же бесплатный сервер, но уже с предустановленной панелью управления ispmanager. Это меняет сценарий — из песочницы для пет-проектов Free Tier превращается в готовый способ перенести рабочий сайт с классического хостинга в облако.

Поэтому в этой статье говорим не про тесты ради тестов, а про миграцию.

varchar(255) выглядит как аккуратное ограничение и часто воспринимается как способ сэкономить место.
Но в PostgreSQL это не так: база хранит фактическую строку, а не заранее выделяет память под весь лимит.

Разбираемся, что на самом деле делает VARCHAR(N), чем он отличается от text, когда ограничение полезно, а когда просто превращается в число, которое притворяется архитектурой.

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

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 ЦОД. И это лишь малая часть обновлений. Все подробности — ниже.