Посмотрим, как повысить производительность работы сервера на Windows Server 2016, 2019 или 2022 в среде с ограниченными ресурсами (2−4 ГБ RAM, 2 vCPU), то есть типичного VPS.
Оптимизация сервера — стандартная процедура, которую имеет смысл запускать каждый раз после регистрации нового VPS. Цель — выжать максимум производительности из железа без больших финансовых затрат.
Карты OpenStreetMap ежедневно загружаются на сотни миллионов устройств. На таких объёмах даже маленькая оптимизация на пару процентов даёт существенную экономию трафика, диска, вычислительных ресурсов. А если улучшение в десятки процентов, то это грандиозное достижение.
В октябре 2025 года разработчики представили новый формат хранения данных GOB («Geo-Object Bundle», пакет геообъектов). Это вспомогательный формат для библиотеки GOL (Geo-Object Library), которая была раньше. В новом формате реализовано сжатие zlib и другие оптимизации, что позволило существенно уменьшить размер файлов, скорость загрузки и обработки карт. Работа с нашей Землёй стала гораздо быстрее, если можно так сказать.
Посмотрим, что представляют собой форматы GOL и GOB, как удалось добиться такой оптимизации и как это выглядит в реальных условиях.
В современных высокопроизводительных системах используются мощные вычислительные компоненты с высоким тепловыделением, при этом требования к энергоэффективности дата-центров ограничивают реальный тепловой режим работы сервера. Задача инженеров здесь — снизить риск перегрева компонентов и избежать потери производительности.
Меня зовут Анатолий Белановский, я старший инженер по методикам тестирования. В прошлом занимался спинтроникой, работал над разработкой STTMRAM, ReRAM, а также в области сверхпроводниковых кубитов. В статье расскажу о методике, которая позволит быстро определить тепловые ограничения процессоров, модулей памяти, накопителей, сетевых контроллеров и элементов питания. Инженеры могут использовать ее при аудите существующей инфраструктуры, оптимизации компоновки и нагрузок, приемочных испытаниях и ускоренного прототипирования систем охлаждения.
Как ускорить серверную часть мобильной MMO-игры в 2,5 раза и при этом сократить инфраструктурные расходы в 5 раз? В этом кейсе рассказал опыт проекта The Firstborn: почему виртуальная машина перестала справляться с нагрузкой ещё до релиза, зачем мы отказались от геораспределённой базы данных, как выбор точки размещения повлиял на пинг по всему миру и почему переход на выделенный сервер с NVMe кардинально изменил стабильность, деплой и скорость серверного просчёта боёв.
Очень важно правильно подбирать умолчания. Да и вообще всегда максимально конкретно и полно указывать, а что именно тебе нужно. И не только в программировании, кстати. Иначе, случайно можно проделать много лишней работы.
Что общего у запросов из 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 пятого и шестого поколений с встроенными ускорителями. Понимание этой эволюции и правильная интерпретация характеристик процессоров становится критически важным навыком при построении облачной инфраструктуры.
