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

Разработка отказоустойчивых систем представляет собой важнейшую компетенцию для инженеров, занятых созданием распределённых и масштабируемых приложений. Под отказоустойчивостью понимается способность системы сохранять работоспособность в условиях сбоев отдельных компонентов или недоступности внешних сервисов. В данной статье рассматриваются практики обеспечения устойчивости на уровне программного кода, в частности в контексте серверных приложений, реализованных на языках Python и Java.

Особое внимание уделяется методам повышения надёжности при временных сбоях, включая: повторные попытки выполнения операций с экспоненциальной задержкой (exponential backoff), использование шаблона circuit breaker, механизмы плавной деградации функциональности (graceful degradation), задание таймаутов, реализация идемпотентности, ограничение одновременных вызовов (bulkhead isolation), а также внедрение систем мониторинга и алертинга. Приводимые примеры охватывают типовые сценарии — обращение к внешним API, взаимодействие с базами данных и выполнение фоновых задач.

Вышел новый релиз Varnish Cache 7.7, в котором добавлен новый параметр, позволяющий ускорить время ответа и исключить внезапные зависания Varnish, вызванные большими вычислениями в момент обработки клиентского запроса. В этой статье я расскажу о расследовании самого загадочного инцидента в моей практике, по результатам которого я предложил внести изменения в механизм инвалидации кэша Varnish.

Привет, ХАБР! Я Хаймин Владимир, эксперт по системам управления базами данных PostgreSQL в ВТБ. Когда размеры таблиц становятся большими — обслуживание и доступ к данным становятся непростой задачей. Я хочу поделиться методикой организации секционирования в PostgreSQL, которая существенно упростила нам жизнь с таблицами большого размера, хранящие, например, исторические данные по датам. Назовем ее условно «Корзинным секционированием» (Basket partitioning). Данная технология реализована архитектурно, без необходимости расширения функционала сторонними инструментами или расширениями только штатными средствами ванильных версий PostgreSQL. Такая система хранения реализована, например, в проекте мониторинга pg_awr для упрощения удаления старых данных.

Секционирование в PostgreSQL

Секционирование — это техника разбиения одной большой таблицы базы данных (БД) на несколько меньших, логически связанных частей, называемых секциями. При этом, такая таблица с точки зрения ППО выглядит как одна большая таблица. 

Современные версии PostgreSQL имеют достаточно развитые средства для работы с секционированными таблицами. При этом, несмотря на то что страдает автоматизация, например, создания и удаления секций, при правильной организации хранения данных работать с такой БД достаточно удобно. И эти удобства минимизируют вероятные ошибки.

PostgreSQL начиная с 10 версии, помимо наследования, поддерживается декларативное секционирование: диапазонное, списочное, хэш-секционирование.

Какие бывают базы данных по методу их наполнения и использования?

Привет! На связи Дима Гоголев. Я развиваю CMP-платформу Cloudlink в Orion soft, и за последний год у нас произошли довольно крупные изменения. Я уже писал о том, что такое CMP-платформы и как они могут сэкономить время практически всем, кто работает с системами виртуализации, от админов и системных инженеров до руководства ИТ-департаментов. А в этой статье хочу рассказать, какие фичи мы добавляем в платформу и зачем они нужны. 

Если вы еще не знакомы с CMP-платформами, эта статья поможет лучше понять, какой функциональностью они должны обладать и какие задачи закрывать. А если вы уже изучали CMP-решения, то составите представление о том, какие фичи делают их более зрелыми с точки зрения пользователя.

Когда речь заходит о стоимости облачных ресурсов, каждый лишний рубль может стать решающим для бюджета компании. В условиях растущей неопределенности, вызванной резкими изменениями в рыночной конъюнктуре, любая организация стремится сократить издержки.

В этой статье мы разберем преимущества и риски резервного потребления (CVoS) от Yandex Cloud и подскажем, как FinOps-практики могут помочь максимально эффективно использовать этот инструмент.

Решение зрело уже давно, но постоянно получал один ответ: «Не трогай, работает же». Но на этот раз, когда цифры перерасхода уже были выведены жирным шрифтом и показаны директору Бизнес-центра (БЦ), ситуация изменилась. Нам дали зеленый свет на «оптимизацию».

За полгода с июля 2024 года большинство аудиторных и технических показателей RUTUBE выросло в разы: количество ежедневных пользователей выросло почти в 4 раза; количество видео, ежедневно загружаемых на видеохостинг — в 3 раза, с 330 тыс. до 1 млн единиц контента; CDN-трафик — в 4 раза и в пиковые часы превышает 7 Тбит/с. Как архитектура сервиса показала себя в условиях продолжительного «нагрузочного тестирования» и как команда переживала такой рост нагрузки, читайте в этой статье.

Уважаемые читатели, в своей разработческой деятельности я люблю творчески рассуждать за пределами общепринятых рамок, ограничений, постулатов, мнений влиятельных экспертов и т. п., пытаясь рассуждать как можно шире, заглядывать за «горизонт». Увлечение такое. Не только на работе (там, конечно, приходится считаться с ограничениями — с дисциплиной и самодисциплиной у меня всё в порядке ещё с армии), но особенно в личное время, где полёт мысли ничто не сдерживает. Хотя и на работе эти мои творческие особенности иногда позволяли продуцировать весьма эффективные решения, было такое и не раз. Но описываемое явление скреативилось в личное время.

Кто-то в личное время покоряет Эверест, кто-то стрит-драйвит, кто-то на нижней Волге ловит спиннингом судаков и жерехов (я тоже, кстати, раз в году), кто-то разводит мадагаскарских шипящих тараканов, а кто-то развлекает себя эзотерикой. А я вот внерабочее время развлекаю себя тем, что напрягаю свой мозг математическими и алгоритмическими проблемами. Придумываю что-нибудь эдакое, необычное. Жаль, что за эту деятельность не платят. Говорят, такое напряжение мозга поможет в старости спастись от болезни Альцгеймера. Во всяком случае, весьма на это надеюсь.

И, рассуждая совсем о другой проблеме, но где имеет место быть сортировка большого количества объектов, в плане алгоритма сортировки объектов, меня осенило. Быстренько проверил кодом — ого, работает! Рассчитываю, что вам понравится.

Как обеспечить высокую производительность PostgreSQL и эффективно управлять соединениями? В этой статье мы разберёмся, как правильно настроить пул соединений, какие преимущества он даёт и как избежать распространённых ошибок. Делимся нашим опытом перехода с MongoDB на PostgreSQL и работы с пулом в Go с использованием pgx.

Привет! Меня зовут Олег Кретинин, и я разработчик в команде общих компонентов в Яндекс Еде. Сегодня я расскажу о том, как мы смогли успешно снять нагрузку с нашей базы данных, а также уменьшить её размер.

Помимо сервисов, написанных на C++, Go и Python, у нас есть монолит, он же «кора», на PHP, который всё ещё представляет огромную кодовую базу, хранит кучу логики и предоставляет данные по API для 120 сервисов.

После обновления фреймворка и версии PHP мы принялись за решение другой проблемы, которая всё чаще и чаще давала о себе знать. В тот период у нас возросло количество инцидентов, связанных с базой данных, и нам нужно было что‑то придумать, чтобы стабилизировать проект максимально быстро. Случалось, что всё сыпалось во время праздничных дней, когда количество заказов увеличивалось на 30–40%, или во время разовых массовых операций, например когда однажды в большую сеть ресторанов добавлялся бесплатный соус к каждой позиции меню.

Привет! Сегодня мы выложили в опенсорс Perforator — систему непрерывного профилирования (continuous profiling), которую используем внутри Яндекса для анализа производительности большинства сервисов.

В Github-репозитории доступен исходный код системы и инфраструктура для развёртывания своей инсталляции Perforator на кластере Kubernetes. Кроме того, Perforator можно использовать на своём компьютере как более простую замену perf record: профили получаются точнее, а оверхед меньше. Исходный код доступен под лицензией MIT (и GPL для eBPF-программ) и запускается под x86-64 Linux.

При помощи Perforator и прошлых подходов к задаче профилирования мы регулярно оптимизируем самые крупные сервисы в Яндексе, например Баннерную крутилку или Поиск, на десятки процентов. Кроме того, Perforator реализует недостающий в опенсорсе компонент профилирования для простой автоматической оптимизации программ с использованием profile-guided optimization. Наши тесты показывают, что использование PGO даёт ускорение около 10% в разных сценариях.

Под катом поговорим про профилирование под Linux, опишем вызовы и сложности, возникающие при профилировании, изучим, как устроен Perforator внутри, и обсудим, как можно использовать полученную систему.

Что происходит на веб-сервере

В продолжение цикла статей Отладка сервера для начинающих, сегодня мы познакомимся с различными операционными системами и процессом их установки. Особое внимание было уделено созданию разделов (partition) на дисках, было много перечитано и переспрошено, чтобы понять, для чего надо отделять, сколько памяти выделять и, самый главный ответ на вопрос, зачем и в каком случаи. Мы обсудили, какие разделы стоит выделять, а какие не являются необходимыми. Кроме того, мы немного углубимся в теорию, чтобы лучше понять, как это работает.

Есть люди, которые начинают задумывается об приватности/конфиденциальности в необъятном интернете или уже её практикуют. Есть те, кто не хочет платить за сервисы и считает, что подписочная модель по текущим ценам — не самый выгодный вариант. Тогда появляеться гениальная идея об «self-hosted» решений и покупка домашнего сервера.

В этом цикле статей мы будем говорить о настройке такого сервера и установке сервисов на него. Опыт по использованию этих сервисов, нужны они ли вам, или выбрать более простые аналоги, которые так еще окажутся быстрее в тех или иных задачах. Статьи будут интересны тем, кто задумывался о покупке домашнего сервера (и целесообразности такого решения) или те, кто уже имеет, но нету достаточного опыта/знаний в его настройке. В цикле акцентируется внимание на моментах, где мне пришлось перечитать много статей, как наших, так и иностранных, спрашивать у знакомых и друзей, чтобы собрать в единое целое ответ на простые вопросы: «Почему так?», «А зачем мне это?».

Я ненавижу код бенчмаркинга, как и любой другой человек. Гораздо веселее притвориться, что твоё кэширование значения увеличило производительность на 1000%, чем проверять это тестами. Увы, бенчмаркинг JavaScript по-прежнему необходим, особенно потому, что JavaScript используется (когда не должен?) во всё более чувствительных к производительности приложениях. К сожалению, из-за множества базовых архитектурных решений языка, JavaScript никак не упрощает выполнение бенчмаркинга.

Ассемблерные вставки, используемые компиляторами GCC и Clang, опосредуют взаимодействие высокоуровневых и низкоуровневых языков программирования. Это тонкая и коварная штука. Многие попадают в расставленные здесь капканы, зачастую совершенно неожиданно для себя. В сущности, ключевое слово asm можно перевести на C и C++ как unsafe. Почти в любых руководствах по встроенному ассемблеру, в том числе, и на ужасной странице ibilio, которая десятилетиями попадает в самый верх поисковой выдачи, неисправимо фигурируют фундаментальные серьёзные ошибки, а примеры в большинстве своём некорректны. Наиболее опасно, что эти примеры обычно приводят к ожидаемым результатам! Ситуация плачевная. Эта статья — не руководство, а подборка элементарных правил, которые помогут вам избежать самых распространённых ошибок либо отловить их при ревью кода.

Здесь мы сосредоточимся сугубо на расширенном, а не на базовом ассемблере, а правила в этих версиях отличаются. На первом пишут любые инструкции, относящиеся к встроенному ассемблеру, с ограничениями или затираемыми. То есть, имеем токен : в обрамлении asm. Базовый ассемблер — тупой инструмент, который используется сравнительно нечасто, в основном в самом верху файла с кодом или в “голых” функциях. Поэтому злоупотребления базовым ассемблером на практике маловероятны.

Привет, Хабр! 

Зима пришла стремительно, и принесла с собой много новых идей, ключевых решений, а самое главное, пересмотр уже устоявшихся концепций и парадигм. Одной из таких идей на первый план вышла FinOps (Financial Operations), практика по управлению расходами, применительно к облачным технологиям. Этот подход ставит целью проведение глубокого анализа облачных расходов и работу с реализацией продуктовых задач компаний. Он помогает видеть комплексно процессы компании и объединять усилия команд, для оптимизации операционных процессов. Зачем это нужно? Цифры подскажут: