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

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

Как я ускорил работу с тулингом на своем проекте в среднем более чем в 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, на которых форум сейчас и держится.

Как мы спасали Magento 2 с 1 млн товаров и 10 млн CMS страниц от 504 ошибок.

Разбор реального кейса оптимизации Magento 2-магазина с более чем 1 миллионом товаров и 10 миллионами CMS-страниц. Покажу, почему возникали ошибки 504 Gateway Timeout, какие узкие места были обнаружены в архитектуре, и как использование Redis, Varnish, MariaDB и OpenSearch позволило добиться стабильной работы системы под высокой нагрузкой.

Какое-то время назад у меня возник инцидент с 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%, без изменений в прикладном коде.