Очень важно правильно подбирать умолчания. Да и вообще всегда максимально конкретно и полно указывать, а что именно тебе нужно. И не только в программировании, кстати. Иначе, случайно можно проделать много лишней работы.
Что общего у запросов из 1С, конструкции IN (VALUES ...) и безобидного выражения x + 0? Все они способны превратить выполнение запроса из миллисекундного дела в многоминутное ожидание, потому что стандартный планировщик PostgreSQL на них «спотыкается». Разбираем, как расширение pgpro_planner переписывает неудобные куски дерева запросов в дружелюбный вид еще до того, как оптимизатор успеет выбрать неудачный план, и почему некоторые из этих решений уже попали в ванильный PostgreSQL 18.
Serverless — это не отсутствие серверов. Это состояние, когда вы перестаете о них думать. Вы не патчите ядра Linux, не настраиваете Nginx и не мониторите свободное место на дисках. Вы пишете функцию, загружаете код в облако, и платформа сама решает, где и как это запустить.
Звучит идеально. Но на практике Serverless — это сделка. Вы отдаете контроль над инфраструктурой в обмен на удобство. И часто цена этой свободы — новые, совершенно неочевидные архитектурные проблемы.
Для начала давайте убедимся, что наш VPS находится в самом актуальном и обновленном состоянии. Подключаетесь к VPS через SSH. Запустите следующие команды, чтобы обновить систему и установить необходимые пакеты...
Приложение тормозит. Это жалоба номер один, которую слышат разработчики и архитекторы. Но "тормозит" — это не диагноз. Это симптом. За этим простым словом может скрываться что угодно: от плохо написанного SQL-запроса до "шумного соседа" в облаке или неправильной настройки сборщика мусора.
Оптимизация производительности — это не магия и не набор случайных твиков. Это инженерная дисциплина. Это бесконечный поиск узких мест, компромиссов и баланса между скоростью, стоимостью и сложностью поддержки. Нельзя оптимизировать то, что нельзя измерить. Поэтому, прежде чем менять хоть строчку кода, нужно вооружиться инструментами профилирования и мониторинга.
Этот пост станет глубоким разбором того, как мы снизили задержки P95 конечной точки API с 5 до 0,3 секунды при помощи нишевого трюка computer science под названием «фильтр Блума».
Мы расскажем о том, почему конечная точка была медленной, о решениях, которые мы рассматривали для повышения её скорости, и о критериях выбора между ними. Также мы объясним, как всё это устроено внутри.
Влияет ли типизация данных на скорость работы PHP? Варианты конфигурации JIT. Не самые комплексные тесты, но результат понятен.
В современном мире облачных технологий производительность инфраструктуры напрямую влияет на качество услуг и удовлетворенность клиентов. Когда перед нами встала задача миграции клиентов Serverspace с устаревшего кластера в DataSpace на новую площадку в IXcellerate, мы решили не просто обновить оборудование, а создать решение, которое задаст новый стандарт производительности для российского рынка.
Несмотря на обилие различных онлайн-конструкторов сайтов (вроде Tilda), WordPress остаётся одним из самых популярных движков. Однако сайт, созданный на WP, нужно где-то размещать, и в этом отлично помогает VPS-сервер. Благодаря гибкости в выборе конфигурации, можно легко собрать сервер под проект любого масштаба. И в этой статье мы бы хотели рассмотреть несколько конфигураций VPS под разные проекты на WordPress.
Разбираемся, как контроль над инфраструктурой превращается в бизнес-преимущество в новой экономической и регуляторной реальности, а также делимся, как в этом поможет серверное решение Selectel.
Привет! Меня зовут Brent «Brentmeister» Randall (Брент Рэндалл). Я — инженер из команды Gameplay Integrity, которая занимается игрой VALORANT. В сферу нашей ответственности входит система сборки игры, фреймворки, используемые для автоматизации различных задач, производительность игрового клиента и серверов. Именно последнему пункту этого списка и посвящена данная статья. Я поделюсь с вами историей поиска подходов, позволивших вывести производительность наших серверов на оптимальный уровень.
На самых ранних этапах разработки проекта мы уже знали о том, что VALORANT отличается весьма жёсткими требования к производительности игровых серверов. Надеюсь, мне удастся дать вам некоторое представление о том, почему это так, и о том, как были достигнуты наши амбициозные цели. В самом начале серверный кадр (server frame, цикл обработки данных на сервере) длился 50 мс. А после завершения оптимизации нам удалось сократить это время до менее чем 2 мс. Всё это сделано благодаря анализу и оптимизации кода проекта, а так же — благодаря подстройке «железа» и тюнингу ОС.
Отобрал для вас несколько крайне интересных, но малоизвестных проектов, реализующих работу с XML и JSON. Кроссплатформенных и без зависимостей. На чистом С и ассемблере.
Рано или поздно один сервер перестает справляться. Вы можете купить ему больше памяти, больше CPU, более быстрые диски (вертикальное масштабирование), но в конце концов вы упретесь в потолок. Самый большой сервер конечен. Горизонтальное шардирование — это признание этого факта.
Это философия разделяй и властвуй, примененная к данным. Вместо одной гигантской таблицы users на одном сервере, вы создаете 10, 100 или 1000 маленьких таблиц users, разбросанных по разным серверам (шардам). Это дает почти безграничную масштабируемость на запись и чтение.
Истории из реальных аудитов, где всё пошло «чуть‑чуть не так».
Мы бываем в десятках компаний в год — от заводов и банков до IT‑стартапов. Кто‑то зовёт нас «для галочки», кто‑то «перед проверкой Роскомнадзора», кто‑то просто «посмотреть, всё ли у нас нормально».
И каждый раз мы приезжаем в уверенную, стабильную, «защищённую» компанию. Админы показывают аккуратные схемы сети, SIEM светится зелёным, политики паролей лежат в папке "ИБ_утверждено.pdf".
Но чем глубже смотришь - сервера, забытые VPN, бэкапы, которые съедают прод, и принтеры, через которые можно войти в почту директора.
И самое поразительное - почти никогда нет злого умысла. Только спешка, удобство и уверенность, что «оно же работает, зачем трогать».
Мы собрали несколько историй, которые особенно запомнились. Все они реальные, из аудитов последних месяцев. Ошибки — неочевидные, но каждая могла обернуться катастрофой.
1. История про Wi-Fi, который слышал всё
Обычный корпоративный Wi-Fi. Для сотрудников — одна сеть, для гостей — другая, через VLAN. На бумаге всё идеально.
Но когда мы посмотрели arp -a, внезапно появился контроллер домена.
Трассировка показала, что гостевая сеть идёт тем же маршрутом, что и внутренняя. А DNS-запросы обслуживает корпоративный DNS с SRV-записями Kerberos.
Любой гость с ноутом в переговорке мог поднять responder, перехватить NTLM-хэши и начать брутить офлайн.
Многие команды работают с кластерами Kubernetes побольше нашего. В них больше узлов, больше подов, больше ingress и так далее. По большинству размерностей нас кто-нибудь, да побеждает.
Но есть одна размерность, по которой, как мы подозреваем, мы почти на вершине: это пространства имён. Я думаю так, потому что мы постоянно сталкиваемся со странным поведением во всех процессах, которые их отслеживают. В частности, все процессы, выполняющие их listwatch, занимают на удивление много памяти и подвергают apiserver серьёзной нагрузке. Это стало одной из сложностей масштабирования, которую замечаешь, только достигая определённого порога. При увеличении оверхеда памяти эффективность снижается: каждый байт, который нам нужно использовать для управления — это байт, отнятый у пользовательских сервисов.
Проблема сильно усугубляется, когда daemonset должен выполнять listwatch пространств имён или сетевых политик (netpol), которые мы определяем для каждого пространства имён. Так как daemonset запускают под в каждом узле, каждый из этих подов выполняет listwatch одних и тех же ресурсов, из-за чего объём используемой памяти увеличивается при росте количества узлов.
Хуже того — эти вызовы listwatch серьёзно нагружали apiserver. Если одновременно перезапускалось множество подов daemonset, например, при развёртывании, то они могли перегрузить сервер запросами и вызвать реальный вылет.
Облачная инфраструктура должна одинаково эффективно работать с корпоративными ERP-системами, современными контейнеризованными приложениями и базами данных. Выбор процессоров для такой универсальной платформы превращается в комплексную задачу, где необходимо учитывать производительность, экономическую целесообразность, гибкость архитектуры и возможности масштабирования.
Рынок серверных процессоров эволюционировал от универсальных решений первых поколений Intel Xeon Scalable до современных специализированных CPU пятого и шестого поколений с встроенными ускорителями. Понимание этой эволюции и правильная интерпретация характеристик процессоров становится критически важным навыком при построении облачной инфраструктуры.
Вы уже научились отслеживать среднюю скорость запросов на проекте, и это большой шаг. Без преувеличений и какой либо иронии.
И теперь, когда вы перешли от "не измеряем ничего" до "измеряем среднее" — вы попали в ловушку.
Пока вы с удовольствием наблюдаете в отчетах красивые 200ms — ваши пользователи стучат в службу поддержки со словами "у меня все висит".
И они не врут, у них действительно TTF порядка 6 секунд. Но и вы не врете, у вас действительно 200ms в отчете!
Врет метрика, а вы ей верите.
Давайте разбираться.
База данных — это сердце системы. И в какой-то момент это сердце начинает давать сбои. Не от объема данных, а от их разнородности. Таблица users разрастается до 200 колонок. Одни нужны для логина каждую секунду, другие — для годового отчета раз в год. В итоге, чтобы прочитать два "горячих" поля, база тащит с диска целый блок с "холодными" данными. Это неэффективно.
Во всех устройствах YADRO, будь то системы хранения данных, серверы или коммутаторы, есть система BMC, через которую администраторы гибко управляют серверами.
Мы поддерживаем продукты в конкурентоспособном состоянии и выпускаем обновления с исправлениями багов, поддержкой новых стандартов безопасности и новой функциональностью. Но чем больше новшеств, тем больше места бинарный код занимает на накопителе с прошивкой устройства. На старых платформах уже нет возможности расширить накопитель, поэтому мы ищем, как уменьшить прошивку, сохранив всю нужную функциональность.
Меня зовут Максим Гончаров, и я расскажу, как мы оптимизировали кодовую базу на C++ по размеру конечного образа, чтобы новые фичи были доступны на всех уже работающих у заказчиков серверах.
Каждая контейнерная платформа — Docker, Podman, Kubernetes — реализует собственную DNS-архитектуру со специфическими особенностями, преимуществами и подводными камнями. Понимание этих различий критически важно для построения надежных и производительных контейнерных инфраструктур. С чем мы и попробуем разобраться в этой статье.
