home.social

#высокая_нагрузка — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #высокая_нагрузка, aggregated by home.social.

fetched live
  1. chunk() пропустил половину рассылки

    Раз в минуту четыре фоновые команды обходят таблицу на сотни тысяч чатов и решают, кому бот напишет первым: у кого обновились суточные лимиты, кто начал разговор и замолчал, у кого кончилась подписка. Год назад выяснилось, что за один проход каждая обслуживает ровно половину тех, кого сама же выбрала. Ошибок при этом нет, лог чистый, метрика отправленных растёт. Виноват chunk(), который листает выборку через OFFSET: обработанная строка из этой выборки выпадает, и окно уезжает. Разбор на живом проекте с 300 тысячами пользователей в месяц: как chunk() теряет строки и чем его заменить, почему withoutOverlapping() по умолчанию блокирует команду на сутки, откуда берутся дубли рассылки и зачем пришлось переворачивать порядок колонок в составном индексе.

    habr.com/ru/articles/1084640/

    #php #laravel #крон #очереди #высокая_нагрузка #telegram_bot #рассылки

  2. Вебхук, в котором нельзя работать

    Каждое нажатие кнопки в телеграм-боте — это HTTP-запрос от Telegram к вам. Около трёхсот тысяч человек в месяц, у каждого в сессии десятки нажатий, и всё это приходит в один POST-эндпоинт, у которого нет ни права на пятисотку, ни права подумать. Пропускная способность считается до обидного просто: max_connections, делённое на время ответа. Отвечаете за 200 мс при сорока соединениях — двести апдейтов в секунду. Отвечаете за две секунды — двадцать. И ждёт при этом не абстрактный клиент, а конкретный пользователь, у которого следующее нажатие просто не доедет. Что осталось внутри вебхука и что уехало в очередь, почему дедупликация по update_id обязана быть атомарной, зачем в ответ на вебхук можно вернуть вызов метода API — и четыре бага, которые нашлись в собственном коде, пока я это писал.

    habr.com/ru/articles/1084650/

    #laravel #telegram_bot_api #webhook #высокая_нагрузка #идемпотентность #php

  3. PostgreSQL и временные таблицы. Часть 2: почему 1024 счётчиков бывает мало

    В 2023 году мы писали о временных таблицах в PostgreSQL и о том, как перенести их на RAM-диск. Это помогло: в наших измерениях доля ext4 в профиле процессора упала с 13,5% до 1,6%, и про диск мы с тех пор не вспоминали. Однако создание, очистка и удаление временных таблиц остались обычным DDL — с изменениями системного каталога и сильными блокировками, которые держатся до конца транзакции. Оказалось, что это отдельная цена, и платить её приходится в самых неожиданных местах. На одном сервере активные бэкенды периодически застревали в ожиданиях LWLock:LockManager . На другом отставала логическая репликация и накапливался WAL. Выглядело это совершенно по-разному, а разбираться в обоих случаях пришлось в одном и том же: в том, что происходит в PostgreSQL, когда временные таблицы создаются и очищаются тысячами. Начнём с блокировок — там обнаружился массив из 1024 счётчиков, который занимает четыре килобайта, не настраивается и не менялся с 2011 года, и выяснилось, что временные таблицы одной сессии могут лишать обычные запросы всех остальных сессий быстрого пути получения блокировок.

    habr.com/ru/articles/1080150/

    #postgresql #временные_таблицы #высокая_производительность #высокая_нагрузка

  4. База встала под нагрузкой: как найти, кто кого блокирует в PostgreSQL

    CPU и диск свободны, а сервис уже задыхается: транзакции ждут блокировок, соединения заканчиваются, база перестаёт отвечать. Разберём, как найти корневой процесс в PostgreSQL, отличить длинную транзакцию от конкуренции за строки и остановить каскадный сбой.

    habr.com/ru/companies/otus/art

    #PostgreSQL #блокировки #транзакции #дедлоки #pg_stat_activity #pg_blocking_pids #idle_in_transaction #LWLock #пул_соединений #высокая_нагрузка

  5. Ускоряем импорт цен и остатков в 1С-Битрикс: от часов к секундам

    Стандартный обмен данными в 1С-Битрикс часто превращается в ночной кошмар: полная выгрузка остатков на больших каталогах может занимать от 1 до 8 часов. Когда бизнес требует обновлять данные каждые 15 минут, штатные методы API и XML-импорт просто перестают справляться. В этой статье я покажу, как с помощью прямого SQL запроса и временных таблиц в памяти (ENGINE=MEMORY) ускорить импорт в сотни раз. Это реальный кейс с продакшена, который стабильно работает уже 4 года на проекте с миллионом товаров и десятками складов.

    habr.com/ru/articles/1019126/

    #1cbitrix #1cбитрикс #импорт_данных #оптимизация #высокая_нагрузка

  6. Миллиард записей и 8 Марта: как YDB спас праздник

    Чем покупка букета на 8 Марта через Яндекс Еду отличается от покупки, собственно, еды? С точки зрения пользователя — ничем. Выбрал, оплатил, доставили. А вот с точки зрения разработчика бэкенда заказ уникальных букетов превращается в нетривиальную инженерную задачу синхронизации складских запасов. Задержка синхронизации хотя бы в 10 минут трансформируется в звонок и сборщиков заказов, сообщающих о том, что именно такого букета на складе больше нет. Меня зовут Виталий Московкин, я занимаюсь ритейлом в Яндекс Еде. В статье я расскажу, как мы синхронизировали состояние складов с 18 миллионами уникальных товаров: сначала с помощью PostgreSQL, а затем с помощью YDB. Такое количество товаров превращается на бэкенде в 4 миллиарда записей о ценах и стоках, которые нельзя просто так кешировать. Но и замена монолитной СУБД на распределённую тоже задача не на десять минут. Подробности — под катом.

    habr.com/ru/companies/yandex/a

    #яндекс #ydb #базы_данных #работа_с_данными #микросервисы #высокая_нагрузка

  7. Управляем облаком, не привлекая внимания пользователей: разбор примеров из жизни One-cloud

    Привет, Хабр! Меня зовут Алексей Волков, я руковожу группой core-разработки внутреннего облака VK — One-cloud. Хочу поделиться примерами из эксплуатации: какие были проблемы в проде на Java при высоких нагрузках, как мы это чинили и какие выводы сделали. Никакой теории на бумаге, только реальные истории из жизни крупной облачной платформы.

    habr.com/ru/companies/vk/artic

    #performance #облако #облачное_хранилище #облачный_сервис #миграция #onecloud #высокая_нагрузка

  8. Эмуляция вместо имитации, или То, чего обычно не хватает нагрузочным тестам

    Всем привет, меня зовут Андрей Матвеев, я разработчик в команде платформы надёжности Яндекс Такси. Если проще — я занимаюсь тем, чтобы Такси работало стабильно. А ещё я техлид проекта virtual‑orders — это наша система нагрузочных учений. Изначально она была для Такси, но теперь мы активно внедряем её в Еду и Лавку. В статье я расскажу, как мы проводим интеграционные нагрузочные тесты: что эмулируем, как настраиваем окружение, на какие метрики и дашборды смотрим. Поделюсь болями и находками — от первых тестов до регулярных прогонов с участием десятков команд.

    habr.com/ru/companies/yandex/a

    #нагрузочное_тестирование #тестирование #высокая_нагрузка #эмуляция #метрики #яндекс_такси

  9. «Мы падаем, а клиенты не замечают» или подходы к раздаче редко изменяемых данных

    Всем привет! Меня зовут Кирилл Грищук, я Tech Lead в команде Инфомодели в Авито . Мы развиваем платформу объявлений и их характеристики. В предыдущей статье я рассказал , как мы строим отказоустойчивые системы при работе с многомиллионным трафиком. В этой статье рассказываю, почему, даже когда всё падает, никто этого не замечает. Статья будет полезна всем, кто хочет погрузиться в проблему раздачи и обработки редко изменяемых данных.

    habr.com/ru/companies/avito/ar

    #avito #9999 #highload #высокая_нагрузка #высоконагруженные_системы #backend #sli #отказоустойчивые_системы #отказоустойчивые_решения #редко_изменяемые_данные

  10. Как обрабатывать 5 млн изменяющихся форм в минуту с SLI 99.99%

    Всем привет! Меня зовут Кирилл Грищук , я Tech Lead в команде Инфомодели в Авито . Мы занимаемся тем, что обрабатываем формы от пользователей: от 5 млн до 15 млн форм в минуту, а это более 150 тысяч в секунду. В этой статье на примере Авито я рассказываю, зачем мы стремимся к SLI 99.99%. Внутри — обзор и сравнение решений по доставке неизменных данных, учитывая специфику нашего сервиса. Показываю на примере форм, какие интересные доработки мы придумали, чтобы достичь этих четырёх девяток, и какие ошибки совершали по пути. Статья будет полезна всем, кто хочет погрузиться в проблему раздачи и обработки редко изменяемых данных.

    habr.com/ru/companies/avito/ar

    #avito #sli #highload #высокая_нагрузка #высоконагруженные_системы #запросы #sql #backend

  11. Глубокое погружение в архитектуру Kafka: от простых сценариев до геокластера

    Привет, Хабр! Меня зовут Андрей Комягин, я CTO компании STM Labs. Мы занимаемся разработкой очень больших распределённых высоконагруженных систем для различных отраслей, включая налоговое администрирование, телеком, track & trace и многие другие. В своей работе мы широко используем open-source-решения, в том числе Apache Kafka. Этот распределённый программный брокер сейчас применяется практически во всех наших проектах, и сегодня я предлагаю заглянуть внутрь чёрного ящика, чтобы понять, как там всё внутри устроено. В своей работе мы широко используем open-source-решения, в том числе Apache Kafka. Этот распределённый программный брокер сейчас применяется практически во всех наших проектах, и сегодня я предлагаю заглянуть внутрь чёрного ящика, чтобы понять, как там всё внутри устроено. Этот текст написан на основе моего доклада на конференции SaintHighload++ 2025 в Санкт Петербурге. Так что, если вы были там в качестве слушателя, информация не будет для вас новой. Впрочем, повтор полезного материала никогда не бывает лишним. Поехали!

    habr.com/ru/articles/972788/

    #архитектура #kafka #highload #highload++ #высокая_нагрузка #высокая_производительность #брокер_сообщений #mirrormaker

  12. Нейросеть против PostgreSQL: системные ошибки AI в прогнозировании производительности под нагрузкой

    Использование нейросетей для оптимизации баз данных кажется перспективным направлением, но реальная эффективность таких систем требует тщательной проверки. В данном исследовании проанализирована способность нейросетевой модели точно прогнозировать производительность СУБД PostgreSQL в условиях экстремальной параллельной нагрузки. Результаты демонстрируют систематические ошибки AI, связанные с неспособностью учесть динамические аспекты работы СУБД. ℹ️ Новый инструмент с открытым исходным кодом для статистического анализа, нагрузочного тестирования и построения отчетов доступен в репозитории GitFlic и GitHub kznalp/PG_EXPECTO: Комплекс статистического анализа производительности СУБД PostgreSQL pg-expecto/pg_expecto: Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL

    habr.com/ru/articles/969082/

    #postgresql #postgresql_performance #искусственный_интеллект #нейросети #прогнозирование #анализ_производительности #индексы #высокая_нагрузка #статистический_анализ #deepseek

  13. Высоконагруженный reverse-proxy на YARP

    Привет, Хабр! Сегодня поговорим о том, как на практике построить высоконагруженный обратный прокси-сервер на основе YARP, отличной библиотеки от Microsoft для .NET. К статье

    habr.com/ru/companies/otus/art

    #C# #ASPNET #обратный_прокси #высокая_нагрузка #балансировка_нагрузки #высоконагруженные_системы #YARP #отказоустойчивость

  14. Разбор системы: Доставка котировок

    Привет, Хабр. В этой статье рассмотрим один из типов систем: доставка котировок от биржи до клиента. Здесь акцент на отказоустойчивость и скорость доставки данных. Будем двигаться поэтапно: от сбора требований и базовой конструкции до нюансов работы с данными.

    habr.com/ru/companies/otus/art

    #доставка_котировок #фондовый_рынок #высокая_нагрузка #низкая_задержка #ultralow_latency #архитектура_системы #system_design

  15. Не Pgbouncer, но пулер. Не Odyssey, но с корутинами

    Если вы настраивали отказоустойчивый кластер Postgres, то сталкивались с необходимостью перенаправления пользовательского трафика на пишущий узел после аварии на основном узле и переключения на резервный. Мы разработали расширение Proxima, которое снимает необходимость в настройке и администрировании дополнительного программного обеспечения. Разработчик программного обеспечения Postgres Professional Тофиг Алиев расскажет, как мы делали Proxima, какие архитектурные решения заложены в расширение, почему мы выбрали именно такой подход. Разберет тонкости реализации, которые позволили нам обрабатывать более 10 тысяч одновременных клиентских сессий. Рассмотрит примеры использования и ответит на вопросы.

    habr.com/ru/companies/postgres

    #высоконагруженные_проекты #высокая_нагрузка #высокая_производительность #highload #высокая_доступность #postgresql #proxima #biha #postgres_pro

  16. Алгоритмы консенсуса Paxos, Raft и Zab в распределённых системах

    В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – Paxos , Raft и Zab – стали основой для построения отказоустойчивых систем. Они гарантируют, что при наличии кворума узлов (обычно большинства) все узлы придут к единому решению и последовательности операций, сохраняя консистентность данных. В данной статье мы рассмотрим устройство этих алгоритмов «под капотом», их этапы (выбор лидера, репликация журнала, обработка сбоев и восстановление), области применения в реальных системах (от координаторов в кластерах Kubernetes и Apache Kafka до распределённых баз данных), а также сравним готовые реализации (такие как etcd, ZooKeeper, Consul и др.) по ключевым характеристикам.

    habr.com/ru/articles/903792/

    #paxos #raft #микросервисы #sql #nosql #распределенные_системы #высоконагруженные_проекты #высоконагруженные_приложения #высокая_доступность #высокая_нагрузка

  17. Настройка Apache Kafka для высоконагруженных систем

    Apache Kafka является одной из самых популярных платформ для обработки потоков данных, обеспечивая высокую пропускную способность и низкие задержки при передаче сообщений. В высоконагруженных системах, где необходимо обрабатывать миллионы сообщений в секунду, важность правильной настройки Kafka трудно переоценить. Без оптимизации её параметров можно столкнуться с серьёзными проблемами, такими как рост задержек, потеря сообщений и переполнение очередей. Эффективная настройка Kafka критична для обеспечения бесперебойной работы в условиях высокой нагрузки и стабильной обработки данных в реальном времени. Цель этой статьи — рассмотреть основные аспекты настройки Apache Kafka, которые влияют на производительность системы. Мы сосредоточимся на оптимизации параметров брокеров и продюсеров для достижения максимальной пропускной способности, минимальных задержек и надежности. Также рассмотрим важность мониторинга и тестирования системы для своевременного выявления и устранения узких мест.

    habr.com/ru/articles/901200/

    #apache_kafka #nosql #распределенные_системы #высоконагруженные_проекты #высокая_производительность #highload #высокая_нагрузка #высоконагруженные_приложения #высокая_доступность

  18. High Availability в Postgres Pro без головной боли

    Для тех, кто устал от «зоопарка» решений по созданию отказоустойчивых кластеров, расскажем, как добиться нужной функциональности одним решением. BiHA позволяет данным «выжить», даже если один из ЦОДов был физически уничтожен. Как же мы этого добились?

    habr.com/ru/companies/postgres

    #postresql #postrgres #biha #отказоустойчивость #отказоустойчивые_системы #резервирование #высокая_производительность #высокая_нагрузка #высокая_доступность

  19. Так ли плох Go в глазах C++ разработчика: пишем микросервис и учимся на ошибках

    Миллионы пользователей ежедневно заходят на Яндекс Маркет. И одна из ключевых задач сервиса — показывать им точные сроки доставки на поиске и в корзине. При пиковых нагрузках это около 40 тысяч запросов в секунду. Как обеспечить столь быструю и точную обработку данных о доставке? Привет, Хабр! Меня зовут Никита Деревянко. Я руковожу разработкой логистической платформы Яндекс Маркета. Люблю играть в шахматы, бильярд и программировать. Изучаю японский язык, чтобы тренировать мозг и смотреть аниме в оригинале. Расскажу о том, как построить логистический runtime на Go, не являясь Golang-разработчиком. Рассмотрим, как справиться с большим объёмом данных и какие преимущества может (или не может) предложить Golang для масштабной задачи.

    habr.com/ru/companies/yandex/a

    #golang #высокая_нагрузка #концепции #подходы #указатели #аллокация #grpc #syncpool #слайсы #профилирование

  20. 13 млрд счётчиков и 220 000 RPS на запись: проектируем Key-Value-хранилище для Спамообороны

    Привет! Меня зовут Тимур Нургалиев, я тимлид в команде Спамообороны. Яндекс Почта обрабатывает миллиарды писем, из них около 20–30% — спам. Технологии, которые мы создаём в команде, блокируют массовые рассылки и отправляют вредоносные письма в соответствующую папку. В статье я расскажу про архитектуру нашего высоконагруженного сервиса, немного погружу в контекст и расскажу, как мы спроектировали Key‑Value‑хранилище, которое в режиме реального времени хранит и отдаёт признаки массовости письма.

    habr.com/ru/companies/yandex/a

    #датацентр #яндекс_360 #спамооборона #почта #высокая_нагрузка #спам_и_антиспам

  21. Балуемся кластеризацией и синхронизацией: как устроена мгновенная загрузка фото в Яндекс Диске

    Всем привет! Меня зовут Дима, я тимлид команды Яндекс Диска. Сегодня расскажу, как обрабатывать сотни терабайт загружаемого контента в день и быстро доставлять его в ленту со всеми фотографиями пользователя. Лента выглядит как локальная галерея на телефоне, но может содержать в себе сотни тысяч фотографий, хранящихся в облаке, и быстро переходить к любой точке среди огромного количества контента. В статье подробно расскажу про технический челлендж, наш подход к реализации задачи и про особенности синхронизации, используемой в этом случае.

    habr.com/ru/companies/yandex/a

    #архитектура #highload #высокая_нагрузка #яндекс_360

  22. Как работает поисковое ранжирование для миллионов объявлений Авито

    Привет! Меня зовут Илья Валяев, я data science team lead поискового ранжирования в Авито. В статье расскажу, как у нас всё устроена система ранжирования, какие технологии используем и как именно улучшаем поисковые выдачи. Статья будет интересна ML-инженерам, которые владеют базовой теорией машинного обучения и хотят разобраться в том, как устроено поисковое ранжирование.

    habr.com/ru/companies/avito/ar

    #sphinx #поисковые_технологии #mlмодели #обучение_моделей #высокая_нагрузка #поисковые_системы #поисковые_алгоритмы #ранжирование_поиска #авито #объявления

  23. Как вырастить динозавра: масштабирование платформы YTsaurus от 200 до 20 000 хостов. Доклад Яндекса

    Привет! Меня зовут Паша Сушин. Уже больше десяти лет я занимаюсь в Яндексе развитием платформы YTsaurus — нашего внутреннего инструмента, который в марте 2023 года вышел в опенсорс и теперь доступен всем на GitHub по лицензии Apache 2.0. Сегодня мой рассказ будет о том, какие ограничения архитектуры мы преодолели, чтобы масштабировать наши кластеры больше чем в сотню раз.

    habr.com/ru/companies/yandex/a

    #ytsaurus #datalake #opensorce #опенсорс #yt #высокая_производительность #высокая_нагрузка

  24. Как устроен рекомендательный сервис, который выдерживает 700 тысяч запросов в секунду. Доклад Яндекса

    «Баннерная крутилка» — один из самых высоконагруженных сервисов в Яндексе. Он умеет переживать 700 тысяч RPS, а иногда и больше. Каждый раз, когда приходит запрос, крутилка должна просмотреть базу из миллиарда документов и выбрать из них самые релевантные для пользователя. При этом выдерживаются весьма жесткие временные рамки: 99% всех запросов обрабатываются менее чем за 200 миллисекунд. Какими принципами стоит руководствоваться при построении подобных высоконагруженных систем? Как устроены стадии отбора документов? Какое участие в ранжировании принимает ML? Обо всём этом на недавнем мероприятии для разработчиков в Ереване рассказал Артём Ваншулин, руководитель разработки ранжирования в команде баннерной системы. Сегодня мы делимся с сообществом текстовой версией его доклада. Передаём ему слово.

    habr.com/ru/companies/yandex/a

    #доклад_яндекса #высокая_нагрузка #высоконагруженные_сервисы #машинное_обучение #рекомендательные_системы #разработка_сервисов #проектирование

  25. Распределенная трассировка с Jaeger и Clickhouse

    Привет! Меня зовут Филипп Бочаров, я руководитель центра мониторинга и наблюдаемости в МТС Digital. Мы делаем распределённую трассировку, чтобы контролировать качество наших сервисов и предотвращать аварии. В этой статье разберём, как добиться понятной и прозрачной работы от сложных распределённых систем. За время, прошедшее с прошлого доклада, количество обрабатываемых в единицу времени спанов выросло в несколько раз. Рассмотрим, какие архитектурные решения начали «поджимать», и как команда МТС их исправляла.

    habr.com/ru/companies/oleg-bun

    #распределенная_трассировка #clickhouse #jaeger #elasticsearch #ускорение #оптимизация #chproxy #distributed_таблицы #высокая_нагрузка #мониторинг

Share on Mastodon

Enter the server where you have an account.