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

Если вы эксплуатируете 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, разберём типичные причины деградации производительности и реальные кейсы, когда результаты тестов могут вводить в заблуждение.

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

А потом смотришь внимательнее и понимаешь, что основная дыра вообще не там. Токены уходят не на полезную работу, а на служебную движуху вокруг нее. Cron-задачи, проверки, диагностика, статусные запросы, огромные списки инструментов “на всякий случай” - все это тихо ест бюджет каждый день. Агент еще ничего толком не сделал, а счетчик уже крутится. Примерно как если бы мастер пришел поменять розетку, но сначала выгрузил из газели весь строительный рынок, два перфоратора и почему-то бетономешалку.

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

Как я ускорил работу с тулингом на своем проекте в среднем более чем в 10 раз, заменив JS-инструменты на нативные.

Это первая (после нулевой) статья из серии Нейро сети для самых маленьких, в которой мы разбираем инфраструктуру для запуска нейронных сетей.

Для обучения и инференса нейросетей и для любых видов High Performance Computing используются специализированные технологии: GPU/TPU, RDMA, Kernel bypass, NVLink, InfiniBand, RoCE и другие. Про некоторые из них большинство только что-то слышали, но сталкиваться с ними не приходилось.

Нельзя просто взять ванильный стек Linux, воткнуть в него 400Gb Ethernet+IP и получить рабочее решение. Почему?

Потому что общее решение на масштабе в большинстве случаев проигрывает специализированным как в скорости, так и в стоимости. Как бы странно последнее ни звучало.

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

Привет, Хабр! Меня зовут Тимур Исламгулов. Я преподаватель МФТИ и ведущий вебинаров по PostgreSQL. За годы работы я насмотрелся, как разработчики поднимают лишнюю инфраструктуру там, где хватило бы самой базы, — об этом и поговорим.

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

Моё изначальное предложение прозвучало просто: «Ему вполне должно хватить одного ядра и 2 ГБ RAM. Это же всего лишь лаунчер». Хотя даже 2 ГБ казалось будто бы мало, ведь речь о продакшене, а не о каких-то экспериментах на личном ноутбуке. Но как раз в таком мышлении и кроется проблема. В процессе развития сферы вычислений мы постепенно перестали всерьёз воспринимать небольшие числа при обсуждении ресурсов, так как дорожим устойчивостью системы. Но в продакшене нужно, наоборот, распоряжаться ресурсами более аккуратно.

Представьте, что вы едете в ночном поезде. Чтобы гарантированно выйти на нужной станции, придется не спать всю ночь и внимательно отслеживать остановки. Свою станцию вы не пропустите, но сойдете с поезда уставшим. Другой способ: узнать из расписания предполагаемое время прибытия поезда, поставить будильник на нужное время с небольшим запасом и лечь спать. Этого вполне достаточно, чтобы не пропустить свою станцию, но, если поезд задержится, пробуждение окажется слишком ранним. Идеальным решением было бы лечь спать, положившись на то, что кто-нибудь или что-нибудь разбудит вас незадолго до реального прибытия поезда на нужную станцию...

Какое отношение этот пример имеет к работе с потоками в программировании? Дело в том, что решить задачу синхронизации конкурентных операций можно также несколькими способами, близкими к ситуации выше. Меня зовут Александр, я разработчик на С++ в YADRO, и в этой статье я разберу несколько вариантов эффективной организации ожидания потоков. 

«HTAP», «единая платформа для OLTP и OLAP», «никаких ETL» — такие обещания в индустрии делают каждые полгода. Обычно за этим следуют компромиссы: либо транзакции деградируют, либо аналитика тормозит, либо архитектура превращается в Франкенштейна. Мы расскажем, что конкретно сделали в Postgres Pro AXE — и почему это работает иначе.

История о том, как я загнал главную страницу форума с 88 запросов до 15, выяснил, что половину работы делал впустую один невинный аддон, и в конце снял ещё четверть серверного времени строчкой в конфиге — не сломав при этом ничего из того, что работало. А заодно — полная документация на стек из четырёх своих расширений и preload, на которых форум сейчас и держится.