Здравствуйте, в настоящее время на поддержку большая нагрузка, много запросов. Время ответа может быть значительно увеличено. Напишите ID запроса, попробуем помочь
Мы живы. Поддержка отвечает в порядке очередности. Когда запросов становится слишком много, поддержка закрывает возможность отправки запроса. Но это только на время, чтобы обработать уже накопившиеся. Затем ограничение снимается. Так что нужно просто немного подождать. Это стандартная практика во время повышенного числа обращений. Вся актуальная информация, которая регулярно обновляется, есть в новости на сайте. Для оперативного получения информации можно перейти в наш тг-канал.
Приоритетно мы оповестили клиентов, которых затронула уязвимость, в Личном кабинете и социальных сетях. Кроме того, выложили новость на сайте, которую регулярно апдейтим. Расследование инцидента еще не закончено. Когда оно завершится, мы опубликуем постмортем в блоге на сайте. И, вероятнее всего, выложим дополнительно на Хабр.
В настоящее время продолжается расследование инцидента. Все подробности опубликуем в постмортеме, когда оно завершится. Информация будет доступна на нашем сайте и в тг-канале.
1. Надёжность и стабильность — внешние сенсоры на TTP223 дают более предсказуемый порог срабатывания и лучше защищены от наводок и изменения условий окружающей среды (влажность, температура, близость рук/корпуса). Встроенные каналы ESP32-S3 чувствительны к этим факторам и часто требуют дополнительной калибровки и фильтрации.
2. Развязка и удобство монтажа — отдельные модули позволяют разместить сенсоры на удобном расстоянии от основной платы и корпуса, не тянуть длинные проводники чувствительных линий.
3. Простота и повторяемость — для читателей статьи (многие из которых не углубляются в тонкости touch-калибровки) готовые модули TTP223 дают «plug-and-play» решение без необходимости подбирать пороговые значения, настраивать фильтры и бороться с ложными срабатываниями.
Официально оператор ЦОД IXcellerate не раскрывает детали внедрения специализированных систем защиты из соображений безопасности и конфиденциальности. Все открытые детали, характеристики и документы площадок можно посмотреть напрямую на сайте ЦОДа https://ixcellerate.ru/
От автора статьи: Это не рекомендуемый референс-дизайн и не финальная архитектура мечты, а минимальный стартер пак под конкретные ограничения: бюджет, сроки и доступное железо. Если отбросить академическую картинку идеального Clos, схема остаётся полностью рабочей для нашего профиля нагрузки. В такой модели отказ одного Leaf не означает остановку серверов, потому что второй линк остаётся рабочим. Отказ Spine тоже не равен остановке клиентского сервиса, потому что Leaf'ы не завязаны на общий IRB, EVPN multihoming/ESI-LAG и общий L2-сегмент, который надо синхронно обслуживать с двух сторон. Это минимальная промежуточная схема, которая переживает реалистичные аварийные сценарии и не требует покупать дополнительное железо, поэтому я считаю что, она вполне имеет право на жизнь. И вопрос скорее не в том, "что же тут не так", а в том, какая цена у более правильной схемы на старте и какой риск она реально закрывает.
По словам автора статьи, да, один Spine — это осознанный компромисс, а не эталонная целевая схема. Но в нашем конкретном дизайне его отказ не означает остановку клиентского сервиса. Даже если вынести за скобки прямой горизонтальный линк между Leaf, который мы оставили как аварийную страховку, сама схема не слишком чувствительна к потере синхронизации Leaf между собой. У нас нет общих IRB-интерфейсов, нет EVPN multihoming/ESI-LAG и нет сценария, где два Leaf должны синхронно обслуживать один общий L2-сегмент. Каждый Leaf имеет собственный default-route, независимый BGP-пиринг с апстримом и отдельную связность с внутренними route-reflector'ами, которые отвечают за достижимость виртуальных машин. Поэтому при проблеме со Spine мы в первую очередь теряем оптимальность части путей и балансировку исходящего трафика в сторону апстрима, а не саму возможность пересылки клиентского трафика. Ну и да, второй Spine нужен и остаётся логичным следующим шагом при увеличении количества Leaf'ов.
Спасибо за конструктивный комментарий! Действительно, термин «антипаттерн» может звучать немного категорично. Я ориентировался прежде всего на начинающих разработчиков и хотел выделить такие кейсы как «красные флаги» — сигналы для того, чтобы заглянуть в EXPLAIN ANALYZE и проверить свои гипотезы. Обязательно добавлю в выводы оговорку про осознанное использование нескольких CTE. Благодарю — замечание полезное.
P.S. Кстати, «любовь» PostgreSQL к сортировкам и отличие от Oracle/MPP — отличная тема для отдельной статьи. Было бы здорово увидеть ваш материал на Habr.
Отвечает автор: Полезнее всего здесь получился чек-лист по плану, особенно связка actual rows, loops и temp written. Я бы добавил еще одну проверку перед переписыванием CTE: сравнить план не на одном литерале, а на нескольких значениях с разной селективностью. В приложении тот же SQL часто выполняется как prepared statement, и после нескольких запусков PostgreSQL может перейти от custom plan к generic plan. Тогда пример с узким диапазоном работает через индекс, а широкий диапазон получает тот же усредненный план и внезапно проседает уже в проде. Поэтому рядом с EXPLAIN ANALYZE полезно смотреть распределение значений, расхождение estimated/actual rows и при подозрении сравнивать force_custom_plan с force_generic_plan. Проверяли ли вы эти четыре примера в режиме prepared statements, особенно первый с диапазоном customer_id?
Приветствуем! Нам жаль, что вам пришлось столкнуться с такой ситуацией.
Действительно, летом 2026 года в дата-центре нашей локации «Амстердам» (Qupra DC2) произошла серия отказов системы охлаждения, что послужило причиной недоступности серверов. Пострадавшие клиенты могут получить компенсации и бонусы. Подробнее о происшествии и мерах помощи рассказали в подробном разборе.
Чтобы подобного не повторилось, мы приняли решение о переезде в более стабильный ДЦ. Сейчас ведем работы: обо всем рассказываем в своем тг-канале.
Приветствуем! Спасибо за детальный разбор, в FirstVDS всегда рады аргументированной критике.
Но хотим уточнить нюансы по методологии обзора. Десктопная AIDA64 не подходит для оценки VDS на виртуализации KVM: обозначенная задержка L3-кэша на деле является откликом планировщика гипервизора. А тесты GPGPU без видеокарты оторваны от реальных серверных задач.
Давайте протестируем VPS на реальной нагрузке? Мы готовы бесплатно выдать более мощный инстанс или продлить текущий. Предлагаем развернуть ваш проект, прогнать yabs.sh или нагрузить БД через sysbench. Напишите, пожалуйста, нам в личные сообщения на Хабре или в поддержку для маркетинга — сделаем честный тест, результаты которого не стыдно добавить в ваш рейтинг.
Здравствуйте! Сейчас проверки у нас выполняются из двух российских локаций: Москва и Санкт-Петербург. Это позволяет оценивать доступность сайта из локальных точек внутри РФ, а не из зарубежных дата-центров, где кратковременные проблемы на маршруте действительно могут давать ложные срабатывания.
Дополнительно у нас используется время жизни инцидента: если недоступность была кратковременной и длилась всего несколько секунд, такой сбой не сразу переходит в инцидент. Это помогает отсекать ложные срабатывания, связанные с временными сетевыми проблемами на маршруте, у провайдера или в DNS. Если же проблема держится дольше заданного порога и/или подтверждается из нескольких точек, это уже более похоже на реальную недоступность сайта.
Здравствуйте, забрали, попробуем помочь
Здравствуйте, напишите ID тикета, пожалуйста, попробуем ускорить
Отключили службу ag_server.service -- вам надо в том же тикете, не создавая новый, еще раз написать, что сервер тормозит. Должны подхватить
Код забрали, попробуем ускорить
Здравствуйте, в настоящее время на поддержку большая нагрузка, много запросов. Время ответа может быть значительно увеличено. Напишите ID запроса, попробуем помочь
Мы живы. Поддержка отвечает в порядке очередности. Когда запросов становится слишком много, поддержка закрывает возможность отправки запроса. Но это только на время, чтобы обработать уже накопившиеся. Затем ограничение снимается. Так что нужно просто немного подождать. Это стандартная практика во время повышенного числа обращений. Вся актуальная информация, которая регулярно обновляется, есть в новости на сайте. Для оперативного получения информации можно перейти в наш тг-канал.
Приоритетно мы оповестили клиентов, которых затронула уязвимость, в Личном кабинете и социальных сетях. Кроме того, выложили новость на сайте, которую регулярно апдейтим. Расследование инцидента еще не закончено. Когда оно завершится, мы опубликуем постмортем в блоге на сайте. И, вероятнее всего, выложим дополнительно на Хабр.
Заказ VDS снова доступен. Работы над устранением уязвимости пока продолжаются. В нашем тг-канале можно посмотреть последний апейт.
По срокам пока не можем сориентировать, работы еще ведутся
В настоящее время продолжается расследование инцидента. Все подробности опубликуем в постмортеме, когда оно завершится. Информация будет доступна на нашем сайте и в тг-канале.
Ответ автора:
1. Надёжность и стабильность — внешние сенсоры на TTP223 дают более предсказуемый порог срабатывания и лучше защищены от наводок и изменения условий окружающей среды (влажность, температура, близость рук/корпуса). Встроенные каналы ESP32-S3 чувствительны к этим факторам и часто требуют дополнительной калибровки и фильтрации.
2. Развязка и удобство монтажа — отдельные модули позволяют разместить сенсоры на удобном расстоянии от основной платы и корпуса, не тянуть длинные проводники чувствительных линий.
3. Простота и повторяемость — для читателей статьи (многие из которых не углубляются в тонкости touch-калибровки) готовые модули TTP223 дают «plug-and-play» решение без необходимости подбирать пороговые значения, настраивать фильтры и бороться с ложными срабатываниями.
Официально оператор ЦОД IXcellerate не раскрывает детали внедрения специализированных систем защиты из соображений безопасности и конфиденциальности. Все открытые детали, характеристики и документы площадок можно посмотреть напрямую на сайте ЦОДа https://ixcellerate.ru/
От автора статьи: Это не рекомендуемый референс-дизайн и не финальная архитектура мечты, а минимальный стартер пак под конкретные ограничения: бюджет, сроки и доступное железо. Если отбросить академическую картинку идеального Clos, схема остаётся полностью рабочей для нашего профиля нагрузки. В такой модели отказ одного Leaf не означает остановку серверов, потому что второй линк остаётся рабочим. Отказ Spine тоже не равен остановке клиентского сервиса, потому что Leaf'ы не завязаны на общий IRB, EVPN multihoming/ESI-LAG и общий L2-сегмент, который надо синхронно обслуживать с двух сторон. Это минимальная промежуточная схема, которая переживает реалистичные аварийные сценарии и не требует покупать дополнительное железо, поэтому я считаю что, она вполне имеет право на жизнь. И вопрос скорее не в том, "что же тут не так", а в том, какая цена у более правильной схемы на старте и какой риск она реально закрывает.
По словам автора статьи, да, один Spine — это осознанный компромисс, а не эталонная целевая схема. Но в нашем конкретном дизайне его отказ не означает остановку клиентского сервиса. Даже если вынести за скобки прямой горизонтальный линк между Leaf, который мы оставили как аварийную страховку, сама схема не слишком чувствительна к потере синхронизации Leaf между собой. У нас нет общих IRB-интерфейсов, нет EVPN multihoming/ESI-LAG и нет сценария, где два Leaf должны синхронно обслуживать один общий L2-сегмент. Каждый Leaf имеет собственный default-route, независимый BGP-пиринг с апстримом и отдельную связность с внутренними route-reflector'ами, которые отвечают за достижимость виртуальных машин. Поэтому при проблеме со Spine мы в первую очередь теряем оптимальность части путей и балансировку исходящего трафика в сторону апстрима, а не саму возможность пересылки клиентского трафика. Ну и да, второй Spine нужен и остаётся логичным следующим шагом при увеличении количества Leaf'ов.
Ответ автора:
Спасибо за конструктивный комментарий! Действительно, термин «антипаттерн» может звучать немного категорично. Я ориентировался прежде всего на начинающих разработчиков и хотел выделить такие кейсы как «красные флаги» — сигналы для того, чтобы заглянуть в EXPLAIN ANALYZE и проверить свои гипотезы. Обязательно добавлю в выводы оговорку про осознанное использование нескольких CTE. Благодарю — замечание полезное.
P.S. Кстати, «любовь» PostgreSQL к сортировкам и отличие от Oracle/MPP — отличная тема для отдельной статьи. Было бы здорово увидеть ваш материал на Habr.
Отвечает автор:
Полезнее всего здесь получился чек-лист по плану, особенно связка actual rows, loops и temp written. Я бы добавил еще одну проверку перед переписыванием CTE: сравнить план не на одном литерале, а на нескольких значениях с разной селективностью. В приложении тот же SQL часто выполняется как prepared statement, и после нескольких запусков PostgreSQL может перейти от custom plan к generic plan. Тогда пример с узким диапазоном работает через индекс, а широкий диапазон получает тот же усредненный план и внезапно проседает уже в проде. Поэтому рядом с EXPLAIN ANALYZE полезно смотреть распределение значений, расхождение estimated/actual rows и при подозрении сравнивать force_custom_plan с force_generic_plan. Проверяли ли вы эти четыре примера в режиме prepared statements, особенно первый с диапазоном customer_id?
Приветствуем! Нам жаль, что вам пришлось столкнуться с такой ситуацией.
Действительно, летом 2026 года в дата-центре нашей локации «Амстердам» (Qupra DC2) произошла серия отказов системы охлаждения, что послужило причиной недоступности серверов. Пострадавшие клиенты могут получить компенсации и бонусы. Подробнее о происшествии и мерах помощи рассказали в подробном разборе.
Чтобы подобного не повторилось, мы приняли решение о переезде в более стабильный ДЦ. Сейчас ведем работы: обо всем рассказываем в своем тг-канале.
Приветствуем! Спасибо за детальный разбор, в FirstVDS всегда рады аргументированной критике.
Но хотим уточнить нюансы по методологии обзора. Десктопная AIDA64 не подходит для оценки VDS на виртуализации KVM: обозначенная задержка L3-кэша на деле является откликом планировщика гипервизора. А тесты GPGPU без видеокарты оторваны от реальных серверных задач.
Давайте протестируем VPS на реальной нагрузке? Мы готовы бесплатно выдать более мощный инстанс или продлить текущий. Предлагаем развернуть ваш проект, прогнать yabs.sh или нагрузить БД через sysbench. Напишите, пожалуйста, нам в личные сообщения на Хабре или в поддержку для маркетинга — сделаем честный тест, результаты которого не стыдно добавить в ваш рейтинг.
Здравствуйте! Сейчас проверки у нас выполняются из двух российских локаций: Москва и Санкт-Петербург. Это позволяет оценивать доступность сайта из локальных точек внутри РФ, а не из зарубежных дата-центров, где кратковременные проблемы на маршруте действительно могут давать ложные срабатывания.
Дополнительно у нас используется время жизни инцидента: если недоступность была кратковременной и длилась всего несколько секунд, такой сбой не сразу переходит в инцидент. Это помогает отсекать ложные срабатывания, связанные с временными сетевыми проблемами на маршруте, у провайдера или в DNS. Если же проблема держится дольше заданного порога и/или подтверждается из нескольких точек, это уже более похоже на реальную недоступность сайта.
Рады, что материал понравился :)