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

GitHub прогоняет регистровую свёртку по каждому байту кода, который попадает в индекс Blackbird, поэтому даже базовая текстовая операция быстро превращается в вопрос производительности. Инженеры обнаружили, что ранний выход из цикла мешает LLVM векторизовать обработку: после удаления break скорость на ASCII выросла до 45+ ГиБ/с на одном ядре. Дальше они пошли ещё глубже и научились сворачивать Unicode прямо в байтовом представлении UTF-8, обходясь без полноценного декодирования символов.

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

Полный self-hosted стек observability (Go-приложение + PostgreSQL + ClickHouse) живёт на VPS с 2 ядрами и 2 ГБ RAM. Но сначала стоковый ClickHouse занял 12 ГБ диска при 543 КБ полезных данных, держал 900 МБ памяти и мержил 11 миллионов строк каждые 30 секунд. Разбор с реальными замерами: куда всё ушло, какая гипотеза не подтвердилась, какая ошибка уронила прод и какие настройки в итоге вернули две трети памяти.

В отчете The State of AI 2025 агентство McKinsey заявляет, что 88% компаний уже используют ИИ хотя бы в одном бизнес-процессе. Grand View Research отмечает, что по их прогнозам глобальный рынок вырастет до 3,5 триллионов долларов к 2033. Уже сейчас мы можем отследить эту динамику.

Однако AI-сервисы не бесплатны. Компании, которые начали с токенизированных API, часто обнаруживают, что при реальной нагрузке их счета растут быстрее, чем польза от ИИ. Поэтому возникает вопрос: как развернуть искусственный интеллект на собственной инфраструктуре и не переплатить.

Привет! Привет! Меня зовут Сергей Ковалёв, я менеджер продукта в Selectel. В статье отвечу на этот вопрос, сравню токенизированные API с on-premise и разберу, когда собственное железо будет выгоднее арендованного. Подскажу, как выбрать модель в зависимости от задачи и GPU под разные сценарии: от простого чат-бота на L4 до многоагентных систем на HGX B300. А в конце дам пошаговый план, как перейти с токенов на собственную инфраструктуру и посчитать реальную стоимость запроса.

Повторяющиеся операции в облачной инфраструктуре — по отдельности совсем не сложные. Проверить доступные мощности, сверить параметры нового объекта, собрать данные об инциденте или рассчитать лимит IOPS — все это можно сделать вручную. Но когда количество кластеров, площадок, клиентов и запросов растет, а количество рук — не увеличивается, это становится проблемой.

Меня зовут Дмитрий, я руководитель службы поддержки виртуальной инфраструктуры в OXYGEN. В этой статье я рассказываю про личный опыт автоматизации мониторинга облака. Под катом разберу четыре задачи, которые мы последовательно автоматизировали — заглядывайте, если интересно.

Выкатили мы первый релиз в прод (100 камер), обрадовали клиентов, начали работать. Прошел где-то час, полетели алерты. Залезаю на сервак, смотрю htop – а там свободно 100 метров ОЗУ. Пу-пу-пу-пу. Нужно внести уточнение что боевой сервер имел 32 гига озу. Ожидаемое поведение было то что процессор отдыхает, сетевуха переваривает трафик, озу 250-300 МБ, диски нагружены не сильно. Так что, когда видишь такие цифры в htop, начинаешь винить себя и свои кривые руки, написавшие это "Г". Но все же решили пойти в Гугл, чатгпт и тому подобное. Благо, ответ нашелся быстро, и посыпать голову пеплом перестали.

Код оказался не вообще не причем, память сожрал сам Линукс. Если когда-нибудь вы писали тонны данных на диск, я думаю вы уже поняли в чем дело. Есть такой «невидимый враг» как страничный кэш (Page Cache). Вот именно он и был корнем этой проблемы.

Как работает страничный кеш и что с ним делать?

Когда ваша функция, которая должна писать данные на диск пишет данные, на самом деле она не пишет их на диск. Она пишет их в ОЗУ. Логика ядра Линукса проста и банальна, и она направленна на ускорение «отзывчивости» системы, всю суть можно объяснить так: «О, только что записали сотню гигабайт данных, наверное, скоро понадобится эти данные прочитать. Оставлю-ка я их в кеше, пользователь будет рад что так быстро смог их прочитать.» И так гигабайт за гигабайтом, пока в сервере не кончится физическая память.

Типичное решение проблемы – пишем скрипт, который раз в час делает echo 3 > /proc/sys/vm/drop_caches. Ну а кто-то просто забивает и позволяет системе убивать случайные процессы через OOM Killer. Но мы же пишем отказоустойчивую штуку. Нам такое не подходит. Задача объяснить ядру ОС, что наши fMP4 сегменты видеоархива — это write-only мусор на небольшое количество времени (т.к если клиент не хочет долго хранить записи, то архив чистится, а если хочет – мы отправляем архив после N времени хранения в S3, а локальную копию тоже чистим). Так что все должно работать по принципу – записал и забыл.

Мы знаем, что сегодняшние большие языковые модели основаны на архитектуре transformer, а самое важное понятие в трансформере это механизм attention.

Вычисление attention происходит путем многократного произведения матриц. Но как модели с миллиардами параметров вычисляют эти матрицы? Почему генерация происходит так быстро? Как можно вычислить следующий токен, без многомиллионного перемножения?

Сегодня вы узнаете об одном из самых важных понятий в современном ИИ — о KV cache.

Предисловие

Есть небольшой побочный профиль, которым я занимаюсь – ретрансляция сырых потоков RTSP, в HLS. По сути задача простая, чтобы любой простой юзер мог увидеть картинку со своих камер, не пользуясь проприетарным облачным ПО от производителя камер. Во-первых, это много денег, т.к многие клиенты хотят хранить достаточно долго записи с камер. Во-вторых, почти у всех производителей камер разное ПО, и это тупо не удобно иметь 10 разных приложений и/или порталов, где это все можно посмотреть. Ну и в-третьих мало где есть интеграции с ИИ (что для моих клиентов, критически важно). Даже если эта интеграция есть, она либо узкоспециализирована, либо опять-таки проприетарна, либо стоит много денег, а иногда и все это вместе. Решение - использование сырых RTSP потоков, их поддерживают и отдают 90% всех камер на рынке.

Так вот, схема была достаточно проста: несколько камер, простой бэк, выдаем на едином ресурсе для клиентов картинку по HLS, используя плеер hls.js. Всех все устраивало, всем все нравилось. Быстро, просто, удобно и не дорого. Тесты работали идеально, клиенты довольны. С каждым был чат, куда выдавали ссылку на просмотр, а также был общий чат со всеми клиентами – где обсуждались вопросы подключения, финансовые ну и прочее. И вот настает момент Х, кто-то по ошибке скидывает в общий чат ссылку…и конец. По ссылке кликнул видимо весь чат, 3 минуты, полетели алерты в боте, алярм, ахтунг, тревога. Смотрим железо, сервер в ауте, ООМ, все потоки отвалились. Через 20 минут чат разрывался от гневных сообщений, о неработоспособности у всех. Занавес.

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

В этой статье мы проследим путь одной записи лога — от поступления в VictoriaLogs до окончательного размещения на диске. Это поможет представить, что происходит внутри системы, и понять наблюдаемое поведение: почему запросы выполняются быстро, почему на диске иногда появляется множество файлов и какие флаги и метрики важны при поиске неполадок. Статья рассчитана на широкую аудиторию: не требуется ни опыт программирования, ни знание Go. Тем, кто захочет разобраться глубже, первоисточником послужит исходный код VictoriaLogs.

Как планировать ресурсы и балансировать нагрузки в облаке? Многие привыкли думать о нем как о каком‑то бесконечном ресурсе — нажал на кнопку, и через несколько секунд виртуальная машина готова. Но это ощущение безграничности, на самом деле, результат большой работы.

Привет, Хабр! Я — Анастасия Стоянова, менеджер эксплуатации K2 Cloud. В этой статье вас ждёт:

 — рассказ о физической и виртуальной инфраструктуре;

— пояснение, почему ВМ ≠ сервер;

— описание цикла capacity management с расчетом потребности по трендам, целевым запасом под рост, закупкой и вводом новых мощностей, сверкой плана с фактическим потреблением;

— механизмы помогающие пережить пики нагрузки;

— и многое другое.

У директив proxy_* и fastcgi_* совпадает 46 опций из 53 — буферизация, таймауты, кеш, next_upstream, с точностью до префикса и вплоть до значений по умолчанию. Два независимо написанных модуля так не сходятся.

Они и не независимы. Всё, чем proxy_pass отличается от fastcgi_pass, — девять указателей на функции в ngx_http_upstream_t. Соединение, таймауты, повторы, буферизация и отдача клиенту лежат в общих 7352 строках ngx_http_upstream.c, и восемь модулей — от proxy до свежего tunnel — дёргают один и тот же код.

Только контракт из этих девяти указателей врёт в обе стороны. Один из них, abort_request, ставят все восемь модулей — а машинерия не вызывает его ни разу: ноль вызовов во всём дереве и ни одного коммита с вызовом за всю публичную историю, с импорта 0.1.14 в январе 2005-го. Другой, pipe->input_filter, в контракте не объявлен вовсе — но обязателен, как только включена буферизация, и вызывается без проверки на NULL.

Разбираем по тегу release-1.31.3 со ссылками файл:строка: все места вызова каждого колбэка, включая тот, который разбирает заголовок не из сокета, а из файла кеша; матрица «кто какие указатели ставит» по всем восьми модулям; два сценария падения с разными стек-трейсами. Плюс свой рабочий upstream-модуль на 335 строк, собранный и проверенный curl'ом, и tunnel — самый маленький из восьми, приехавший в open source в апреле.

Java уже какое-то время витает в облаках. Всё больше приложений и сервисов переходят на облачную архитектуру. Мы решили не отставать и проверить один из главных проектов для разработки производительных облачных приложений на Java — Quarkus.

Я добавил в Quince AVX2, FMA и немного unsafe. По всем красивым схемам торговая VM после этого должна была полететь.

Она не полетела…

Сначала SIMD проиграл памяти. Потом кольцевым буферам. Затем выяснилось, что сама VM съедает часть ускорения. А в конце оказалось, что CI уверенно показывал результаты кода, который процессор вообще не исполнял.

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

Привет, Хабр! На связи команда Рег.облака, а это третья статья про Free Tier. В первой мы считали, что помещается в один‑два гигабайта памяти, во второй перевозили сайт с виртуального хостинга на бесплатный сервер с ispmanager.

В обеих статьях был раздел, где мы перечисляли, чего на Free Tier делать не стоит: тяжелые CMS, неоптимизированные проекты под трафиком, серьезные базы. Этот раздел пора переписывать. Стартовал третий этап программы: юрлица получают на два месяца сервер 2 vCPU / 4 ГБ RAM / 40 ГБ NVMe. Под каждую задачу своя конфигурация, и с четырьмя гигабайтами круг задач заметно шире. Разбираем, что на них живет.

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

Привет, Хабр! Меня зовут Илья Гуляев, я работаю в команде Рег.облака над облачными решениями. А в свободное время ковыряю MCP — Model Context Protocol, про него и будет текст. Про сам протокол на Хабре уже написано много, а вот про то, что начинается, когда MCP-серверов в инфраструктуре становится десяток, пока почти ничего.

Привет, Хабр! В этой статье я расскажу об эволюции подсистемы сериализации one-nio — фреймворка для создания высоконагруженных сервисов, работающего в Одноклассниках с 2012 года. Прошлой осенью я работал над обновлением подсистемы и добавил в нее новый режим работы, совместимый с актуальными версиями JDK.

Ситуация, с которой мы столкнулись, довольно прозаична. Библиотеке больше десяти лет, и экстремально быстрая сериализация (превращение объекта в последовательность байтов и обратно) с самого начала строилась в ней на внутренних лазейках JVM, к которым обычный прикладной код доступа не имеет. Когда one-nio только писали, это был стандартный паттерн для высоконагруженных фреймворков.

Сейчас же платформа методично «закручивает гайки»: старые бэкдоры помечаются как устаревшие, а затем безжалостно удаляются. И перед нами встал серьезный вызов: как перевести библиотеку на легальные API вплоть до JDK 25, сохранив производительность и не сломав то, что годами крутится в проде?

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

Как одна фича сократила число системных вызовов на TUN-интерфейсе моего VPN почти вдвое — а на bulk-трафике до 44 раз.

В этой статье пойдет речь о том как работает TUN GSO, зачем нужен virtio_net_hdr, какие подводные камни встретились во время реализации и почему эта технология способна заметно снизить нагрузку на VPN-сервер. Статья будет полезна разработчикам VPN серверов и клиентов.

Привет, Хабр! Мы протестировали zVirt 5.0 с функциональностью, которой нет в ванильном oVirt. Главное, что нужно знать: в 5.0 на каждом узле меняется гипервизорная операционная система, фактически выполняется переустановка хостов и системы управления. В статье подробно разберу, почему переход на новую версию – это не рядовое обновление пакетов, а отдельный проект со своими особенностями и подводными камнями.

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

В этой статье разберём, как интерпретировать результаты k6 и на какие метрики смотреть в первую очередь. Поговорим о перцентилях, сравнении прогонов с baseline, разберём типичные причины деградации производительности и реальные кейсы, когда результаты тестов могут вводить в заблуждение.