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

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

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

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

Это первая часть цикла статей о разработке системы публикации структурированных интерактивных постов через Telegram Bot API. В следующих частях — архитектура, рендеринг шаблонов и управление доступом к закрытым чатам.

С чего всё начинается

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

На первый взгляд — ничего сложного. Telegram Bot API умеет отправлять текст, прикреплять медиа, рисовать inline-кнопки. Но именно в этот момент начинается то, что разработчики называют «дьявол в деталях».

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

На днях я стряхнул пыль с небольшого пет-проекта. Это простой блог, наверняка каждый из вас хотя бы думал о таком для себя.
В 2015 году я бы просто закинул файлы по FTP на хостинг за 100 рублей. Время деплоя: 30 секунд.
В 2026 году я потратил 4 часа. Я настраивал Edge Middleware, дебажил рассинхрон HTML между клиентом и сервером (hydration mismatch) и разбирался, почему облако не хочет дружить с моей базой данных из-за долгого пробуждения функций (холодного старта).

Где мы свернули не туда?
Это колесо Сансары, которое дало новый оборот.

В позапрошлом году вышла статья https://habr.com/ru/articles/814529/ про синхронизацию позиции персонажа между клиентом и сервером в Lineage 2. После прочтения появилось желание перенести эту логику в свои сырцы от когда-то разрабатываемого сервера и, возможно, запустить его где-то для себя и старых друзей поразвлекаться. Понятное дело, что современного ПК с кучей рам, хорошим процом и nvme дисками при желании было бы за глаза даже для запуска тысяч игроков, но заниматься организацией доступа из дикого интернета на свой ПК желания не было, да и обеспечивать постоянный доступ - дело такое себе. В наличии была самая дешманная впска у хостера F с доменом, но с сильно ограниченными ресурсами: одно ядро и 512Мб рам. Мягко скажем, памяти маловато.

Наспех восстановил сырцы, актуализировал сборку под современные версии java и либ, запустил - потребление хипа примерно 400Мб на старте. Без геодаты. А с геодатой - 1200Мб.

И тут появился спортивный интерес влезть в 512Мб, да еще и с геодатой.

Результатом стал оптимизированный драйвер геодаты, зашаренный на гитхабе https://github.com/mosinnik/l2-geo, репорт о потенциальном баге в JDK и эта статья.

Я занимаюсь разработкой компиляторов, то есть, пишу программы, преобразующие программы в программы. Иногда требуется нацелиться на более высокоуровневый язык, чем, скажем, простой ассемблер, и зачастую именно в таком качестве удобно взять язык C. Генерировать C не так страшно как писать от руки — в частности, потому, что генератор умеет не попадать в ловушки, связанные с неопределённым поведением. А когда пишешь на C вручную, именно неопределённого поведения следует особенно остерегаться. Здесь я опишу некоторые паттерны, которые обнаружил сам, и которые помогают мне результативно работать.

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

Здесь рассказано, как именно Linux обрабатывает системные вызовы в архитектуре x86-64, и почему при профилировании они выглядят как дорогостоящие операции.

Привет, Хабр! В первый месяц 2026 года команда Selectel выпустила из беты сетевые диски для выделенных серверов, обновила работу с Karpenter и реализовала еще несколько полезных опций. Обо всех обновлениях читайте под катом.

Привет постоянным и не очень читателям :)

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

Ремарка! Я не против конкретных цифр и конфигураций — я против попытки выдать их за универсальный рецепт. Так что этот подход оставим для SEO-статей.

В этом же лонгриде я затрону ошибки мышления при подборе серверов на 5+ лет и сдвиги, которые произошли за последние годы (и особенно хочу поговорить про огромное влияние CXL). Я плотно работаю в этой индустрии больше 6 лет и прошел подобный цикл на практике, да и админы-старожилы рассказали много интересного о том, что было раньше.

Присаживаемся, ложимся или в какой там позе вы читаете — и начинаем.

Решил один мой коллега (не разработчик) заняться пет-проектом: создать платформу с элементами соцсети и встроенным картографическим плагином. И вот приходит этот коллега ко мне с вопросом по части фронтенда: «А как бы мне отрендерить страницы: на сервере или на клиенте?», описывая то решение, которое он уже сделал и которое в целом работает.

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