Индекс в базе данных — это вспомогательная структура (чаще всего B-дерево; хеш-индексы, GiST, GIN и другие типы применяются в узких специфических сценариях), которая ускоряет выборку строк по заданным колонкам. По аналогии с оглавлением книги: вместо перелистывания всех страниц СУБД сразу переходит к нужной главе. Но если оглавление построено плохо, пользы от него нет — а вот накладные расходы на поддержку остаются.

В этой статье разберём семь самых разрушительных ошибок индексации в production-SaaS: от параноидального создания индексов «на всякий случай» до игнорирования раздутия и особенностей мультитенантных схем. Каждая ошибка — с примерами SQL, метриками и конкретным фиксом.

Индексы — это налог на запись: каждый INSERT, UPDATE и DELETE обновляет все индексы таблицы.

Индекс на колонке с низкой селективностью (boolean, статус) почти бесполезен — используйте частичные (partial) индексы.

В составном индексе порядок колонок критичен: PostgreSQL может использовать (a, b, c) только если условие начинается с a.

Раздутые индексы на высокоизменяемых таблицах могут занимать в 8 раз больше места, чем нужно — планируйте REINDEX CONCURRENTLY.

В мультитенантных системах индекс по tenant_id один часто недостаточен: добавляйте диапазон времени или тип события.

Внешние ключи в PostgreSQL не индексируются автоматически — после каждого FOREIGN KEY создавайте индекс вручную.

Без EXPLAIN ANALYZE индексы создаются вслепую. Проверяйте реальный план выполнения перед деплоем.

Ошибка 1. Индексировать всё подряд «на всякий случай»

Самая распространённая ошибка — не недостаток индексов, а их избыток из тревожности. Особенно часто в неё попадают junior-разработчики: добавляют индекс на каждую колонку, которая встречается в WHERE, «на всякий случай». Кажется ответственным, но на самом деле вредно.

Каждый индекс — это налог на запись. При INSERT, UPDATE и DELETE PostgreSQL (или MySQL) вынуждена обновлять все индексы таблицы. На таблице с 8 индексами каждая запись трогает 8 структур данных. При низкой нагрузке это невидимо, но при 10 000 записей в минуту это становится узким местом.

Аудит неиспользуемых индексов в PostgreSQL:
Запрос к pg_stat_user_indexes покажет, сколько раз каждый индекс применялся с момента сброса статистики. Если idx_scan = 0 — индекс кандидат на удаление.

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

Ошибка 2. Не понимать селективность

Индекс на булеву колонку — почти всегда бесполезен. Селективность измеряет, сколько различных значений содержится относительно общего числа строк. У boolean всего два значения. Если 95% строк имеют is_active = true, планировщик запросов проигнорирует индекс и сделает Seq Scan — и будет прав.

Правило большого пальца: если у колонки меньше 10–20 уникальных значений относительно размера таблицы, простой индекс по ней один не справится. Используйте частичные или составные индексы.

Ошибка 3. Неверный порядок колонок в составном индексе

Составные индексы мощны, но часто неправильно понимаются. PostgreSQL может использовать индекс (a, b, c) для фильтрации по a, a и b, a, b и c. Но не может эффективно использовать его, если запрос фильтрует только по b или c — ведущая колонка пропущена.

Решение: первыми ставьте колонки с equality-условиями, затем — по селективности, и проектируйте индексы вокруг реальных паттернов запросов, а не вокруг схемы таблицы. Также учитывайте ORDER BY и необходимость покрывающего индекса. Перед созданием обязательно запускайте EXPLAIN ANALYZE.

Ошибка 4. Игнорировать раздутие индексов

Индексы деградируют со временем. Многие инженеры воспринимают их как «поставил и забыл», но это заблуждение. В PostgreSQL при обновлении или удалении строки старые записи в индексе устаревают и накапливаются как раздутие (bloat); их физическое удаление происходит при выполнении VACUUM. На высокоизменяемых таблицах (заказы, события, логи, сессии) раздутие накапливается стремительно.

Таблица с 1 млн живых строк может иметь индекс, раздутый до размеров 8 млн записей. Каждый запрос через такой индекс делает в 8 раз больше работы, чем должен.

REINDEX CONCURRENTLY — ключевое слово. Обычный REINDEX блокирует таблицу, а в production-SaaS это прямой путь к инциденту. CONCURRENTLY перестраивает индекс без блокировок, хотя и медленнее.

Также убедитесь, что autovacuum настроен под вашу реальную нагрузку на запись. Значения по умолчанию в PostgreSQL консервативны и часто недостаточны для SaaS с высокой интенсивностью записи.

Ошибка 5. Индексы на колонках с малым числом уникальных значений в мультитенантных системах

В мультитенантной архитектуре почти каждый запрос фильтрует по tenant_id. Естественное желание — проиндексировать эту колонку. Но для крупных тенантов индекс по tenant_id вернёт слишком много строк, и планировщик предпочтёт Seq Scan. Для маленьких тенантов отдельный индекс по tenant_id может быть полезен.

На серьёзном масштабе правильное решение — партиционирование таблиц по tenant_id, но это архитектурное решение. Практический первый шаг — составные индексы с временными диапазонами.

Ошибка 6. Не индексировать внешние ключи

В PostgreSQL внешние ключи не индексируются автоматически. При удалении родительской строки СУБД должна проверить все дочерние таблицы на наличие ссылающихся записей — и без индекса на внешнем ключе это Seq Scan по каждой дочерней таблице. На таблице orders с 50 млн строк удаление пользователя вызывает полное сканирование.

Сделайте это командным соглашением: в чек-листе миграций обязательный пункт «после каждого FOREIGN KEY — CREATE INDEX».

Ошибка 7. Не использовать EXPLAIN ANALYZE перед деплоем

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

На что обращать внимание:
• Seq Scan на большой таблице при выборке малой доли строк — возможно, пропущен индекс или планировщик не может использовать существующий индекс.
• Rows Removed by Filter в десятки тысяч — индекс есть, но неправильные колонки или низкая селективность.
• Buffers: shared hit=0 read=45000 — данные не закэшированы (cold cache), страницы читаются с диска. Для диагностики раздутия смотрите общее число буферов и сравнивайте размер индекса с ожидаемым.
• Высокое actual time — проверьте раздутие, актуальность статистики, количество буферов, дисковую подсистему и наличие блокировок. Запустите ANALYZE tablename, чтобы обновить статистику планировщика.

Чек-лист индексации для SaaS

• У каждой колонки внешнего ключа есть индекс?
• Составные индексы упорядочены по селективности, а не по удобству?
• Булевы и низкокардинальные фильтры используют частичные индексы вместо полных?
• Вы запускали EXPLAIN ANALYZE на 10 самых медленных запросов за неделю?
• Есть процесс поиска и удаления неиспользуемых индексов?
• Высокоизменяемые таблицы регулярно проходят REINDEX CONCURRENTLY?
• Autovacuum настроен под реальный объём записи, а не под значения по умолчанию PostgreSQL?
• В мультитенантных таблицах индексы начинаются с tenant_id и включают диапазон времени?

Выводы

Индексы — не фича производительности, которую добавляют, когда всё начинает тормозить. Это проектное решение, которое принимается вместе со схемой, и пересматривается по мере эволюции паттернов запросов. Команды, которые уверенно масштабируются, — не те, у кого больше всего индексов, а те, кто понимает, что каждый индекс стоит, что даёт и когда его пора убирать.

База данных, которая быстра на 10 000 строках и быстра на 50 миллионах, — не случайность. Это результат того, что кто-то считал планирование запросов первоклассной инженерной задачей, а не рутинным дополнением.

Проверьте свои самые медленные запросы этой недели — возможно, одна из этих семи ошибок уже сидит в вашей production-базе.

Источник и материалы:
• Database Indexing Mistakes That Kill SaaS Performance at Scale — оригинальная статья OutworkTech
• PostgreSQL Index Types — официальная документация
• REINDEX — документация по перестроению индексов

Пора перестать смотреть на GPU как на экзотику для геймеров и IT-гигантов. Сегодня это — стратегический актив. Он существенно ускорит ключевые бизнес-процессы. Вопрос лишь в том, как грамотно подойти к вложениям и не слить бюджет.

Тревожные звоночки: пора покупать GPU?

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

Если рендеринг видео или сложной 3D-графики растягивается на ночь, заставляя дизайнеров и инженеров простаивать в ожидании. Если модели машинного обучения обучаются неделями, не позволяя оперативно тестировать гипотезы и улучшать продукт. Если анализ больших данных или сложные финансовые симуляции не дают инсайтов для принятия решений. Это не просто технические неудобства — это прямые потери денег и конкурентных позиций. Компании, которые уже используют GPU-ускорение, попросту двигаются быстрее.

Где GPU приносят реальные деньги

Мощность сама по себе бессмысленна. Ценность появляется, когда она решает конкретные бизнес-задачи.

Возьмём, к примеру, искусственный интеллект. Скорость здесь — это всё. Сокращение времени обучения модели с десяти дней до одного означает не просто экономию времени. Это возможность запустить на 30% больше экспериментов и быстрее выйти на рынок с уникальным продуктом. Выгода становится очевидна.

В индустрии дизайна и медиа GPU творят чудеса. Студия, сократившая время рендера кадра с часа до пяти минут, увеличивает свою пропускную способность в разы. Это позволяет брать больше проектов без расширения штата, повышать качество картинки и соблюдать самые сжатые сроки. Здесь окупаемость считается в дополнительных контрактах и лояльности клиентов.

CAPEX или OPEX: финансовая развилка

Итак, решение принято. Но как поступить — построить собственную инфраструктуру или воспользоваться облачной арендой? Это фундаментальный выбор между двумя финансовыми моделями.

Покупать свои GPU (CAPEX). Это стратегия основателя крепости. Вы владеете всем: от процессора до системы охлаждения. Плюсы? Полная независимость и предсказуемые расходы в будущем. Минусы? Огромный первоначальный взнос, а техника имеет привычку устаревать буквально на глазах. Плюс к этому — штат инженеров для ее содержания. Выбор для тех, у кого работа кипит 24/7 и планы расписаны на годы вперед.

Арендовать в облаке (OPEX). Это стратегия мобильной команды. Нужны мощности — включил. Закончил проект — выключил и перестал платить. Главный козырь — невероятная гибкость. Сегодня тестируете модель на одной видеокарте, а завтра для нового клиента разворачиваете целый кластер за считанные минуты.

Считаем выгоду: простая формула ROI

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

Выгода (₽) = (Сэкономленное время сотрудников × почасовую ставку) + (Ускорение вывода продукта × потенциальный доход) + Снижение операционных издержек.

Затраты (₽) = Стоимость оборудования / аренды + Электроэнергия + Обслуживание.

ROI (%) = ((Доход – Затраты) / Затраты) × 100.

Рассмотрим гипотетический пример. Допустим, инженерная команда тратила на симуляции 200 часов в месяц. Внедрение GPU сократило это время до 20 часов. При стоимости часа работы инженера в $50 экономия на фонде оплаты труда составляет $9000 в месяц. Если аренда необходимых GPU-мощностей обходится в $4000, ежемесячная чистая выгода — $5000. Простой ROI в этом случае превышает 120%. Цифры условны, но они наглядно демонстрируют, что при правильном подходе инвестиции могут окупаться очень быстро.

Резюмируя: шаг к осознанным инвестициям

GPU давно перестали быть узкопрофильной технологией. Они превратились в мощный бизнес-инструмент и дают конкурентное преимущество через скорость. Инвестиции в них оправданы. Но важно чётко понимать, какие процессы ускорятся и как это повлияет на финансовые результаты.

Выбирайте строительство собственного кластера (CAPEX) для стабильных, непрерывных рабочих нагрузок. Аренда в облаке (OPEX) — более гибкий и менее рискованный путь для старта и тестирования идей. Начните с пилотного проекта, соберите данные и посчитайте. Возможно, ваша главная победа над конкурентами лежит не в найме еще одного сотрудника, а в покупке или аренде нескольких видеокарт.

Чек-лист для принятия решения:

• Выявлен бизнес-процесс, который тормозит развитие (AI, рендеринг, симуляции).
• Измерены текущие временные и финансовые потери.
• Оценена потенциальная выгода от ускорения.
• Проанализирован характер нагрузки (постоянная/пиковая).
• Проведено сравнение CAPEX и OPEX на основе реалистичных расчетов ROI.

ELK — аббревиатура от Elasticsearch, Logstash, Kibana. Это названия опенсорс-проектов, которые разрабатываются и поддерживаются компанией Elastic.

Стек ELK позволяет быстро и безопасно извлекать данные в нужном формате из любых источников и работать с этой информацией в режиме поиска, анализа или визуализации в режиме реального времени. Специалисты часто называют стек «эластичным» — небольшая пасхалочка.

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

Узнаем, что собой представляет ELK-стек, как он работает, каковы его преимущества и как правильно настроить настроить и оптимизировать этот программный инструмент.

Из чего состоит ELK-стека

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

Извлечение данных происходит по принципу «пришел последним, вышел первым» по аналогии с пассажирами в вагонах метро — кто заходит позже других, вынужден выходить на остановке первым. По такому принципу работают все стеки.

Программный продукт ELK-стек — это связка из приложений Elasticsearch, Logstash, Kibana, а также Filebeat (доставщик лог-сообщений, отвечающий за мониторинг и сбор данных и их пересылку).

С помощью стека разработчики без труда собирают журналы всех систем и приложений, анализируют их и создают визуализацию. Это необходимо, чтобы мониторить продукты и инфраструктуру, быстро устранять неполадки, тестировать систему безопасности и проделывать другие операции с данными. ELK-стек предоставляет все необходимые сведения об обслуживаемой системе, выполняет свою работу оперативно и наглядно.

Рассмотрим в подробностях каждый из компонентов ELK.

Elasticsearch

Основа стека ELK. В техническом плане это распределенная RESTful-система (инструмент для взаимодействия веб-приложений и серверов) на базе JSON — текстового формата для обмена данными, созданного на JavaScript. Компонент Elasticsearch сочетает в себе функции базы данных NoSQL, поисковика и системы аналитики.

Изначально инструмент разрабатывался как поисковая утилита библиотеки Apache Lucene с дополнительными возможностями в виде репликации, масштабирования и некоторых других опций. Эта многофункциональность плюс простота применения и повышенная производительность сделали Elasticsearch крайне удобным инструментом для проектов с высокой нагрузкой, массивами данных и усложненными поисковыми системами.

Постепенно инструмент стал использоваться не только для реализации внутреннего поиска на сайтах, но и для разработки систем централизованного хранения логов и оперативной аналитики. Благодаря разнообразной функциональности решение стало востребованным во многих направлениях, что привлекло внимание разработчиков из самых разных сфер ИТ. Вокруг ES сформировалось компетентное сообщество — специалисты всегда помогут настроить кластер для решения любых задач.

Статус Elasticsearch в настоящий момент — обширное, быстродействующее, масштабируемое хранилище с функциями поисковика и анализатора журналов. Мощность, простота, документация JSON, поддержка всех актуальных языков программирования и геолокации — все эти достоинства позволяют системе в скоростном режиме работать с большими массивами данных, индексировать логи по мере их поступления и реализовывать запросы в онлайн-формате.

В коммерческих проектах разработчиков Elasticsearch решает следующие задачи:

• агрегирует данные любого формата и объема с различных площадок (например, информацию о товарах из множества онлайн-магазинов), выполняет фильтрацию и поиск по заданным свойствам продуктов;
• шардирует (разделяет) данные и распределяет их на автономные хосты для экономии места, при этом группы автоматически выравниваются для соблюдения баланса;
• обрабатывает данные из множества онлайн-опросников и анкет;
• оперативно вычисляет заданные параметры в массивах данных, собранных из разных систем — такие задачи важны в комплексной аналитике бизнес-процессов;
• анализирует обширные объемы неструктурированных статистических данных;
• хранит информацию и управляет записью с помощью API.

Можно назвать Elasticsearch распределенным поисковым движком, который используется для широкого круга задач в рамках аналитики, поиска, распределения и хранения данных. Установить его проще всего через Docker.

Logstash

В стеке ELK Logstash выступает в роли конвейера для парсинга — автоматизированного сбора и структурирования данных (в нашем случае логов событий), которые приходят из многих источников, с целью их обработки и последующего применения в Elasticsearch.

Эта утилита с открытым кодом позволяет выделять отдельные поля с их значениями в сообщениях о системных событиях, распределять данные с помощью фильтров и редактировать их. Настройка выполняется через конфигурационные файлы.

В системе Logstash очередность событий разделяется на три фазы:

1. Input. Журналы передаются для обработки в машинно-понятный формат. Можно установить последовательность чтения файлов из папок, путь и протокол для извлечения логов.
2. Filter. Поле управления сообщениями, приходящими на Logstash. Здесь задан набор условий для выполнения конкретных действий или событий. Настраивается также парсер логов — можно редактировать значения, добавлять и удалять новые параметры.
3. Output. Фаза настройки места, куда будет отправлен обработанный лог. Если непосредственно в Elasticsearch, потребуется документальный запрос. Если это дебаг (код для исправления ошибки), он просто записывается в файл.

Задача Logstash — централизованная и оперативная обработка обширного объема событий, различных данных со структурой и без нее. Чтобы подключаться к разным способам ввода, утилита использует более 200 плагинов для упрощения доступа.

Через Logstash данные из источников поступают в Elasticsearch. По пути они могут быть преобразованы в нужный формат. Встроенные фильтры и модули обеспечивают юзерам простой и быстрый доступ к данным независимо от их типа.

На GitHub в свободном доступе находится более 20 моделей — высока вероятность, что там уже есть именно тот инструмент, который подойдет для настройки нужного вам конвейера данных. Если такого модуля нет, вы без особого труда сможете создать его самостоятельно. Как и ES, Logstash можно установить и запустить в Docker.

Kibana

Этот компонент представляет собой веб-панель (пользовательский интерфейс) для взаимодействия с логами. Он отвечает за визуализацию проиндексированных данных в Elasticsearch в формате графиков и разного рода диаграмм. Благодаря гибким настройкам мониторинга с помощью Kibana можно путешествовать по ELK-стеку, отслеживая маршруты, по которым запросы проходят через конкретное приложение.

Инструмент подходит для сложного анализа данных и визуализации этого процесса, а также для администрирования баз данных. Есть возможность контролировать несколько панелей мониторинга с сохранением настроек для каждой из них.

Есть несколько методов поиска по данным Кибана в режиме реал-тайм:

• текстовый поиск определенной строки;
• поиск в формате поля;
• логические матрицы для объединения нескольких поисков;
• поиск близких по смыслу терминов.

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

Как работает ELK-стек

Elasticsearch занимается хранением и поиском данных, Logstash обрабатывает, фильтрует и структурирует логи, в Kibana визуализирует поисковые операции и занимается администрированием.

Все три компонента расположены на сервере пользователя, который выполняет функцию клиента. За логами следит доставщик Filebeat, он же пушит логи в Logstash. Последний компонент выполняет с логами определенные манипуляции и помещает их в нужный столбец таблицы Elasticsearch. Далее с помощью визуализации Kibana пользователь с легкостью ищет нужные события.

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

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

Стеком пользуются не только разрабы, но и инженеры DevOps (актуальная концепция непрерывной разработки). Специалисты получают полезную информацию, выполняя диагностику сбоев, аналитику производительности софта и мониторинг инфраструктуры.

Настройка и применение ELK-стека на практике

Есть несколько способов установки стека ELK в разных ОС и средах. Это делается локально, в облачных сервисах, через Docker и системы управления конфигурацией. Рассмотрим универсальные этапы установки на примере ОС Linux.

Для развертывания понадобятся определенные системные ресурсы: около 10 Гб памяти и примерно столько места на жестком диске. Для Elasticsearch и Logstash потребуется Java 8. А еще нужно заранее установить агент Filebeat — сейчас он стал неотъемлемой частью экосистемы ELK.

Основные этапы развертывания:

1. Установка Filebeat из отдельных пакетов, репозитория или через Docker Compose.
2. Установка Elasticsearch. Этот этап довольно простой и быстрый благодаря готовым пакетам — есть версии для всех востребованных операционных систем. Потребуется скачать публичный ключ репозитория и подключить Elasticsearch.
3. Настройка ES. Все необходимые настройки находятся в специальном файле. Промежуточные результаты можно наблюдать на локальном интерфейсе.
4. Очистка индексов в ES. Это автоматический процесс, за который отвечает встроенный инструмент Index Lifecycle Policies. Его тоже можно настроить под конкретные задачи.
5. Установка Kibana. Есть пакеты и репозиторий для всех популярных платформ.
6. Настройка Kibana. Все нужные параметры находятся в специальном файле. Не забудьте настроить безопасность и авторизацию.
7. Установка Logstash. Компонент устанавливается из того же репозитория, что и Elasticsearch и Kibana.
8. Настройка Logstash. Конфигурационные файлы для настройки находятся в соответствующих файлах. Фильтры можно расположить на свое усмотрение.

В качестве наглядного примера использования стека ELK можно привести банковские сервисы, которые делают по требованию клиентов выписки по счету в личных онлайн-кабинетах. Пользователи могут выполнить полнотекстовый гибкий поиск по транзакциям. Такая опция реализована, в частности в веб-приложении Альфа-Банке.

ELK используют и многие другие компании, среди которых Mozilla, GitHub и Netflix. Везде, где нужно работать с Big Data, разработчики отдают предпочтение Elastic, поскольку он закрывает большинство потребностей по поиску, обработке и аналитике.

В чем преимущества использования ELK для мониторинга

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

Перечислим все плюсы ELK:

• способен быстро и без последствий для системы извлекать, обрабатывать, анализировать данные и визуализировать их независимо от формата;
• позволяет вести журнал из одного центра, отслеживать все проблемы в приложении и на серверах, сравнивать журналы на разных серверах и делать выводы;
• прост и удобен в настройке и использовании, доступен для освоения начинающим ИТ-специалистам;
• в набор компонентов входят программные продукты с открытым исходным кодом;
• предоставляет гибкие поисковые фильтры, в том числе для работы с азиатскими языками;
• встроенные преобразователи текста выполняют токенизацию, леммматизацию и другие преобразования контента в соответствии с задачами пользователя;
• стек можно развернуть в любых масштабах независимо от технической структуры компании;
• для решения характерна стабильность, отказоустойчивость и надежность — данные при сборе не теряются и не исчезают;
• большой выбор настроек под конкретные задачи проекта;
• есть официальные клиенты с профессиональной поддержкой, предоставленные разработчиками на востребованных языках программирования;
• стек универсален и подходит для работы с СУБД, файлами любого типа, приложениями и другими данными;
• контейнер для загрузки компонентов стека есть на Docker.

Но эксперты отмечают и недостатки:

• В ELK нет встроенной опции авторизации с управлением правами доступа. Это потенциальная проблема с информационной безопасностью. Базу данных нужно в обязательном порядке защищать паролем, поскольку движок по умолчанию можно открыть через любые интерфейсы.
• Масштабирование в некоторых проектах требует значительных ресурсов и может оказаться нерентабельным.
• Размеры индексов могут превысить лимиты хранилища узла, индексация начинает сбоить — есть риск потери данных.

При этом установка и грамотный запуск стека — довольно ответственный и непростой процесс. Организациям, у которых нет собственных специалистов, придется нанять сотрудника со стороны, который будет управлять развертыванием.

Итоги

Годы практики и активное комьюнити создали из ELK перспективный многофункциональный инструмент, у которого нет достойной альтернативы. Стек ELK широко используется для мониторинга производительности приложений, поиска аномалий и ошибок в системе, выяснения причин багов и дефектов с целью их устранения на программном уровне.

Это современное решение позволяет инженерам и разработчикам настраивать мониторинг динамических сред с распределением и выполнять профессиональную аналитику. ELK — мощная платформа, которая умеет собирать данные из разных источников, помещать в централизованное хранилище и обрабатывать. По мере роста базы систему легко масштабировать, а многие трудности при настройке решаются через привлечение активного и доброжелательного сообщества.

Основные концепции виртуальной памяти

Оперативная (физическая) память компьютера — это реальное хранилище, где размещаются исполняемый код и данные активных процессов. Однако использование физической памяти сопряжено с ограничениями:

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

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

Такой подход обеспечивает 3 ключевых преимущества:

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

Каждый процесс имеет собственное виртуальное адресное пространство. Оно разделено на фиксированные блоки данных — страницы. Их размер 4 КБ или 8 КБ в зависимости от архитектуры системы. Физическая память также разделена на блоки того же размера — фреймы.

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

Страничный файл (файл подкачки или swap file) — это область на жестком диске, которая используется для хранения страниц виртуальной памяти, когда они не помещаются в физическую память. С помощью файла подкачки ОС освобождает физическую память, перемещая неактивные страницы на диск, и загружает их обратно при необходимости.

Механизм работы виртуальной памяти

Процесс преобразования виртуальных адресов в физические состоит из следующих этапов:

1. Разделение памяти. Как виртуальное адресное пространство, так и физическая память разделены на страницы и фреймы соответственно.
2. Таблица страниц. Для каждого процесса создается таблица страниц, которая содержит информацию о соответствии между виртуальными страницами и физическими фреймами.
3. Преобразование адресов. Когда процесс обращается к виртуальному адресу, ОС использует таблицу страниц для определения соответствующего физического адреса.
4. Обработка страничных ошибок. Если запрашиваемая страница отсутствует в физической памяти, возникает страничная ошибка (page fault). ОС загружает требуемую страницу с диска в память.
5. Обновление таблицы страниц. После загрузки страницы таблица обновляется, чтобы отразить новое местоположение данных.

Для оптимизации процесса преобразования адресов используется аппаратное устройство — Translation Lookaside Buffer. TLB представляет собой кэш, который хранит недавно использованные преобразования виртуальных адресов в физические, что значительно ускоряет доступ к памяти.

Алгоритмы управления виртуальной памятью

Когда физическая память заполнена и требуется загрузить новую страницу, ОС должна решить, какую страницу выгрузить на диск. Для принятия решения используются алгоритмы:

• FIFO. Выгружает страницу, находящуюся в памяти дольше всего. FIFO не учитывает частоту использования страниц.
• LRU. Выгружает страницу, которая не использовалась дольше всего. LRU эффективнее FIFO, но требует больше ресурсов для отслеживания времени последнего использования каждой страницы.
• LFU. Выгружается страница, которая использовалась реже всего. LFU необходим, когда к данным обращаются часто, поэтому их желательно хранить в кэше.
• Clock. Похож на алгоритм LRU. Использует бит доступа для каждой страницы и циклически проверяет страницы, сбрасывая бит доступа, пока не найдет страницу для выгрузки.

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

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

Чтобы сократить количество страничных ошибок, используются следующие техники:

• Предварительная подкачка. ОС пытается предугадать, какие страницы понадобятся процессу в ближайшем будущем, и загружает их заранее.
• Группировка страниц. При загрузке страницы с диска система загружает несколько соседних страниц, предполагая, что они также потребуются в ближайшем будущем.
• Адаптивное управление рабочим набором. Система отслеживает набор страниц, активно используемых процессом, и старается удерживать его в памяти для минимизации страничных ошибок.

Роль ОС в управлении виртуальной памятью

Операционная система управляет виртуальной памятью и отвечает за:

• Создание и поддержание таблиц страниц для каждого процесса.
• Управление физической памятью и страничным файлом.
• Обработку страничных ошибок и загрузку страниц с диска.
• Реализацию алгоритмов замещения страниц.
• Оптимизацию использования памяти и минимизацию фрагментации.
• Изоляцию и защиту памяти между процессами.

Реализация виртуальной памяти различается в разных ОС.

• Windows использует файл подкачки (pagefile.sys), размер которого может динамически изменяться. Windows также поддерживает механизм приоритетного ввода/вывода для страниц виртуальной памяти.
• Linux использует выделенный раздел диска (swap partition) или файл подкачки (swap file) для виртуальной памяти. Linux предоставляет гибкие настройки для управления swap-пространством и позволяет использовать несколько swap-устройств с разными приоритетами.
• MacOS использует механизм компрессии, который сжимает неиспользуемые страницы в памяти перед их выгрузкой на диск. Это уменьшает количество операций ввода/вывода.

Операционная система также отвечает за очистку и освобождение хранилища:

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

Преимущества и недостатки виртуальной памяти

Плюсы:

• Многозадачность. Одновременно выполняется больше программ, чем позволяет физическая память.
• Эффективное использование памяти. Только активно используемые данные хранятся в физической памяти.
• Безопасность. Изоляция процессов и контроль доступа к памяти повышают общую безопасность системы.
• Упрощение разработки ПО. Разработчики создают программы, не учитывая физические ограничения памяти конкретного устройства.
• Поддержка больших адресных пространств. Позволяет процессам работать с объемами данных, превышающими физическую память.

Минусы:

• Снижение производительности при чрезмерном использовании swap. Когда система часто обращается к страничному файлу, это значительно замедляет работу из-за низкой скорости дисковых операций по сравнению с оперативной памятью.
• Проблемы с фрагментацией. Со временем может возникнуть фрагментация как физических, так и виртуальных участков памяти, что снижает эффективность использования ресурсов.
• Сложность настройки. Настройка виртуальной памяти — это непростая задача, особенно в системах с ограниченными ресурсами.
• Увеличение износа диска. Интенсивное использование виртуальной памяти может привести к ускоренному износу накопителя из-за большого количества операций записи.

Виртуальная память может стать узким местом производительности системы в следующих случаях:

• Недостаточный объем физической памяти. Если физической памяти недостаточно для хранения рабочих наборов активных процессов, система будет часто обращаться к страничному файлу, что приведет к значительному снижению производительности.
• Интенсивные операции с большими объемами данных. Приложения, работающие с большими наборами данных, могут вызвать частые страничные ошибки, если их рабочий набор не помещается в физическую память.
• Неоптимальные настройки. Неправильно настроенный размер страничного файла или неэффективные алгоритмы управления памятью могут привести к снижению производительности.
• Фрагментация памяти. Сильная фрагментация может привести к неэффективному использованию как физической, так и виртуальной памяти.

Советы по оптимизации виртуальной памяти

Файл подкачки — основной компонент виртуальной памяти в Windows. Он расположен в корневой директории жесткого диска. Системный файл pagefile.sys выступает резервным хранилищем данных. Оно активируется при недостатке оперативной памяти для предотвращения сбоев в работе приложений.

В Windows 8-11 есть взаимосвязанные системные файлы: pagefile.sys и swapfile.sys. Первый отвечает за общее управление виртуальной памятью, второй обслуживает приложения из Microsoft Store. При полном отключении файла подкачки оба компонента удаляются из файловой системы.

Доступ к настройкам файла подкачки возможен через системные интерфейсы. Можно воспользоваться встроенным поиском Windows, утилитой «Выполнить» или стандартным меню «Пуск».

Можно корректировать размер файла подкачки, перемещать его между дисками или полностью отключить. Рекомендуется не вмешиваться в настройки страничного файла. Операционная система самостоятельно определяет оптимальные режимы работы.

Объем виртуальной памяти напрямую зависит от физических характеристик оперативной памяти, но не является их прямой пропорцией. Некорректное уменьшение или отключение файла подкачки может привести к нестабильной работе компьютера.

Лучшим решением будет перемещение файла подкачки на твердотельный накопитель. Скорость чтения и записи SSD-дисков оптимизирует систему при работе с виртуальной памятью. Риски преждевременного износа накопителя при таком подходе минимальны.

Не рекомендуется полностью отключать файл подкачки. В большинстве сценариев такой подход провоцирует сбои в работе ОС. Оптимальная стратегия работы с файлом подкачки — сохранение настроек по умолчанию.

Настройка виртуальной памяти в Linux

Настройка пространства подкачки в Linux осуществляется двумя основными методами: через выделенный раздел диска и создание файла подкачки.

Процесс формирования раздела подкачки начинается на этапе установки операционной системы. Программы установки Linux автоматически определяют аппаратную конфигурацию и предлагают оптимальную схему разметки диска, включающую раздел подкачки.

При необходимости можно добавить раздел подкачки после завершения первоначальной инсталляции. Для этого применяются утилиты неразрушающего форматирования дисков, например, GParted. Принципиально важно выбрать файловую систему типа «Linux swap».

Технология подготовки раздела подкачки включает несколько последовательных шагов:

1. Форматирование раздела с помощью утилиты mkswap.
2. Редактирование системного файла /etc/fstab для автоматического монтирования при загрузке.
3. Активация пространства подкачки командой swapon.

Альтернативный подход — файлы подкачки

Файловый механизм подкачки представляет собой более гибкий инструмент конфигурирования виртуальной памяти. Преимущества данного метода проявляются при работе в следующих сценариях:

• Использование виртуальных машин.
• Работа со встраиваемыми системами.

Создание файла подкачки реализуется через несколько подходов:

• Метод с использованием утилиты fallocate:

sudo fallocate -l 2G /path/to/swapfile

• Метод с применением команды dd:

dd if=/dev/zero of=swapfile bs=1024k count=2048

Планирование объема виртуальной памяти Linux

Настройка поведения подкачки осуществляется через параметр ядра «swappiness». Шкала значений варьируется от 0 до 100:

• 0 — полное торможение использования swap;
• 60 — штатное поведение большинства дистрибутивов;
• 100 — максимальное применение виртуальной памяти.

Временное изменение параметров производится командой:

sudo sysctl vm.swappiness=20

Постоянная конфигурация реализуется правкой файла /etc/sysctl.conf путем внесения записи вида:

sudo vm.swappiness=20

Что запомнить?

• Виртуальная память решает проблемы ограничений физической памяти, изоляции процессов и контроля доступа.
• Каждый процесс имеет собственное виртуальное адресное пространство, разделенное на страницы.
• ОС преобразует виртуальные адреса в физические с помощью таблицы страниц.
• Страничный файл используется для хранения неактивных страниц на диске.
• Процесс преобразования адресов включает разделение памяти, использование таблицы страниц, обработку страничных ошибок.
• ОС отвечает за создание таблиц страниц, управление памятью, обработку ошибок, реализацию алгоритмов замещения: FIFO, LRU, LFU, Clock.
• Параметры виртуальной памяти можно изменять.
• Система по умолчанию выбирает оптимальный режим работы исходя из конфигурации компьютера.

В этом материале разберем, как устроено выделение памяти под объекты в Python. Потом кратко о том, как работает очистка памяти от неиспользуемых объектов. И, наконец, о разнице в занимаемой памяти на примере типов list, dict и tuple. Эта статья — часть нашего полного путеводителя по Python. Эта статья — часть нашего полного путеводителя по Python.

Выделение памяти

Напрямую из кода память не выделяется. Вся работа по выделению памяти перекладывается на менеджеров памяти. Есть один общий менеджер «верхнего» уровня, который отвечает за выделение большого блока из выделенной программе памяти — «арена». Занимает 256Кб.

Далее арена делится на «пулы» по 4Кб. Каждый пул может содержать в себе только блоки заранее определенного для этого пула размера — от 8 байт до 512 байт. Арена может содержать в себе пулы разных размеров, а вот блоки в одном пуле всегда одного размера. И вот на уровне блоков работают менеджеры памяти каждого конкретного типа данных.

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

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

Освобождение памяти

В Python нет необходимости в ручной очистке памяти. Если объект больше не используется, все это перекладывается на сам интерпретатор и два механизма: счетчик ссылок и сборщик мусора.

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

Счетчик ссылок

Каждый созданный объект имеет специальное поле — счетчик ссылок. Он хранит в себе количество ссылающихся на него объектов. Увеличивает свое значение, например, когда используется операция присваивания, или когда объект становится частью списка. При удалении переменной или же при использовании del счетчик ссылок уменьшается на 1. Например, при завершении работы функции, где эта переменная была объявлена.

Разберем на примере небольшой кусок кода:

В данном случае 1000 — это неизменяемый объект, один на всю программу. После инициализации двух переменных счетчик ссылок равен 5.

Почему 5? Потому что на объект 1000 ссылаются не только эти две переменные, а все переменные со значением 1000 во всех используемых модулях. Далее удаляем переменную b и счетчик ссылок меняет свое значение на 4. Как только счетчик достигает 0, объект освобождает блок.

Сборщик мусора

У счетчика ссылок есть большой недостаток — невозможность отловить циклические ссылки. Если объект или несколько объектов ссылаются друг на друга, счетчик никогда не опустится ниже 1.

Специально для обработки таких случаев был создан модуль gc. Его работа заключается в том, чтобы периодически сканировать объекты контейнерного типа и определять наличие циклических ссылок.

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

Сканирование первого поколения начинается, когда количество созданных объектов контейнерного типа превышает количество удаленных на заданный порог. Например, сканирование второго поколения начнется, когда количество сканирований первого поколения превысит заданный порог. По умолчанию, пороги срабатывания — это 700, 10 и 10, соответственно.

Посмотреть их можно через gc.get_threshold(). Изменить через gc.set_threshold().

Все это актуально для list, dict, tuple и еще для классов. Не для простых типов. Базовый обзор типов данных — в нашем гайде для начинающих.

Что там по типам данных

List

Начнем сравнения с list. Поскольку он изменяемый и будет интересно посмотреть, как он ведет себя при изменении количества элементов. Список представляет из себя массив не фиксированного размера, с возможностью произвольной вставки или удаления любого элемента. Элементом списка может быть любой тип данных. С точки зрения хранения списка в памяти, он состоит из двух блоков. Один блок фиксированного размера и хранит информацию о списке. Другой же хранит ссылки на элементы и может переходить из блока в блок, если количество элементов меняется.

Размер занимаемого объектом блока памяти можно посмотреть через sys.getsizeof().

Как мы видим, пустой объект списка уже занимает 64 байта.

При обычном создании списка через перечисление элементов он всегда будет занимать: 64 байта пустой список + 8 байт на каждый элемент, т.к. список представляет из себя массив ссылок на объекты.

При создании через list comprehension размер будет уже 96. Что больше, чем размер пустого списка + 8 байт на каждый элемент. Работа этого механизма сводится к вызову метода append у создаваемого объекта списка. append работает следующим образом: в зависимости от уже присутствующего в списке количества элементов он заранее резервирует больше памяти при добавлении элемента. Дополнительно выделяемый объем памяти не всегда увеличивает список вдвое. Может быть выделено место всего под несколько элементов. Например, если к списку из 8-ми элементов добавляют еще один, будет зарезервировано место еще под восемь элементов. А при добавлении к списку из 16-ти элементов будет зарезервировано место всего под 9 элементов. Это позволяет избежать затрат на изменение размера списка при частых вызовах append. При этом неиспользуемая, но уже выделенная, память недоступна для чтения.

При создании списка на основе кортежа получившийся список будет занимать 112 байт. В данном случае заранее резервируется место под еще 3 элемента списка, помимо уже присутствующих в кортеже.

Итого получаем 64 байта, + 8 * 3 — это элементы из кортежа, + 8 * 3 зарезервированное место под новые элементы.

Tuple

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

Пустой кортеж занимает блок из 48 байт. Помним, что кортежи неизменяемы. Если в памяти уже есть такой же кортеж, то новый объект создан не будет. Вместо этого переменной присваивается ссылка на существующий объект.

На примере видно, что адреса в памяти у двух кортежей совпадают. Аналогичное сравнение для списков вернуло бы False.

В случае непустого кортежа с памятью так же все просто. Объем блока будет равен 48 байтам + по 8 байт на каждый элемент.

С созданием кортежа из списка или другой коллекции тоже нет таких неожиданностей, как со списком. Т.к. не надо закладывать место под изменение количества элементов.

Dict

Словарь представляет из себя массив ключей и массив значений, где каждый ключ связан с одним значением. На ключ накладывается ограничение по уникальности в пределах словаря. Поэтому ключами могут быть объекты только неизменяемых типов. Значением же может быть объект любого типа.

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

Как видно в примере, словарь занимает 240 байт. При создании словаря выделяется место под несколько элементов, а не только после добавления элемента, как это было со списком.

Если вызвать метод clear, очищаются не только все элементы. Изначально зарезервированная память тоже будет освобождена.

В итоге словарь стал занимать всего 72 байта. Гораздо меньше, чем при создании.

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

Заключение

Знать, какой объем памяти будет занимать тот или иной объект, полезно. Например, в условиях проекта или задачи указаны жесткие ограничения по памяти. Или кусок кода вызывается очень часто, необходимо понять, не будет ли выделение/освобождение памяти являться узким местом вашей системы.

Поэтому рекомендую, прикидывать примерные затраты памяти, еще на момент написания кода. И никто не отменяет переиспользование уже существующих объектов.

Если вы заинтересовались этой темой и решили углубиться в нее, то обратите внимание на следующие материалы:

— Memory management in Python. Тут подробно описан механизм работы менеджеров памяти и организации блоков.

— Memory Management. Не забываем про официальную документацию.

— Garbage Collection for Python. Здесь детальнее рассказывают про алгоритм работы сборщика мусора.

— The Garbage Collector. И еще один материал о сборщике мусора. Базовый обзор типов — в нашем гайде по типам данных в Python.

В этой статье мы поговорим о том, какой язык программирования стоит изучать в 2021 году, в чём его особенности, и причем тут highload.

На какой язык программирования стоит обратить внимание в 2021 году

Сейчас есть большое количество языков программирования: какие-то более универсальные, какие-то заточены под определённые задачи. Основываясь на текущих тенденциях IT-рынка, я бы рекомендовал изучать язык программирования С++.

Почему нужно изучать С++

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

Насколько сейчас востребован язык С++

Достаточно взглянуть, как изменился YouTube за последние несколько лет. То количество трафика, которое он обрабатывает, растёт по экспоненте. И таких примеров много. Когда мы упираемся в «потолок» вертикального масштабирования серверов, а горизонтально масштабироваться не получается, то тут на помощь и может прийти язык С++. Так как этот язык является прямым наследником языка Си, то мы получаем большой спектр оптимизаций, при помощи которых можно выжать максимум из железа.

При этом С++ продолжает активно развиваться: добавляются механизмы и инструменты, позволяющие упростить написание кода. Если эта тенденция сохранится, то мы сможем увидеть снижение порога вхождения, что может значительно улучшить позиции языка С++ в рейтинге самых востребованных языков. И как раз в этот момент хорошо уже быть «прокачанным» специалистом.

Какими особенностями обладает С++ по сравнению с другими языками

Работа с памятью в С++

Одна из ключевых особенностей С++, которая, однако, является и минусом, и плюсом — это работа с памятью. Так как С++ является наследником языка Си, то есть возможность управлять памятью напрямую, добиваясь максимальной производительности вашей программы.

К примеру, в операционной системе Linux используется страничная адресация памяти, где каждая страница занимает около 4 KB. Когда ваше приложение использует 2 GB памяти, то вам будет выделено 2 GB/4 KB страниц. Эти страницы мапятся на физическую память.

Вся эта виртуализация требует накладных расходов, но у неё есть значительное преимущество — вашему приложению сразу же не будет выделена вся память, а только то количество, которое необходимо в данный момент. Но если ваше приложение потребляет основную часть ресурсов сервера, то вы можете выделить память не стандартного страничного размера 4 KB, а, например, целиком 2 GB, что позволит нам избавиться от накладных расходов на страничную адресацию в рамках большой страницы, она же huge pages в рамках нашего приложения.

Также стоит отметить, что C++ предоставляет нам возможность использования разного рода аллокаторов памяти при работе с объектами.

Аллокаторы памяти — это специализированный класс, реализующий и инкапсулирующий малозначимые детали распределения и освобождения ресурсов компьютерной памяти. Они позволяют, например, избежать повторного обращения к операционной системе за новой памятью.

Но у этого механизма есть и обратная сторона: вам придётся тщательно следить за утечками памяти. Ведь кто выделил память, тот и должен её освободить. И эта проблема решена в С++. Для этого используются умные указатели — класс, предназначенный для управления динамически выделенной памятью и обеспечения её освобождения (удаления). Рекомендую самостоятельно прочитать про это, механизм достаточно интересный.

Семантика перемещения

Одна из самых интересных, на мой взгляд, возможностей С++ — это перемещение временных объектов в место копирования. Временные объекты  — это те объекты, которые были сконструированы во время выполнения каких-либо операций. Таким объектом может быть возвращаемое значение.

Пропуск копии (Copy elision)

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

Рассмотрим пример:

В зависимости от настроек оптимизации компилятора у нас могут быть следующие результаты:

Нам интересен последний случай. Возвращаемое значение функции f() будет сконструировано на месте объекта obj — это одна из оптимизаций, называемая return value optimization. А самое интересное, что если мы реализуем операторы перемещения, как, например, в семантике перемещения, то компилятор (с 17 стандарта) нам гарантирует, что копий не будет сделано, и объекты будут перемещены. Тем самым можно добиться результата, когда у вас в рамках приложения не создаётся ни одной копии объектов.

Использование системных вызовов

Одним из главных преимуществ языка С++ является возможность использования системных вызовов «как есть». Как я уже говорил, язык С++ происходит от языка Си, а именно на этом языке написано ядро Linux. Опираясь на это, мы, например, можем написать такой код в рамках С++:

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

Не знаю, можно ли так же просто в каком-либо другом языке программирования получить значительный буст производительности, просто дописав четыре строчки кода.

Выводы

С++ последние годы не находится в топе самых востребованных языков программирования. Оно и понятно, порой в нем используется сложный синтаксис со сложными конструкциями, тем самым порог вхождения выше, чем для более высокоуровневых языков. Тем не менее, спрос разработчиков на С++ высок, практически все крупные решения так или иначе строятся с использованием именно этого языка. При этом C++ продолжает развиваться, что в перспективе может привести к упрощению конструкций языка без потери производительности.

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

Приходилось ли вам использовать C++?

На последних стадиях разработки могут возникнуть проблемы, связанные с производительностью, в частности утечки памяти. Мы нашли такую и в нашей системе. В этой статье я расскажу, как исследовать утечку памяти в Go, описав шаги, которые мы предприняли для её поиска.

Набор инструментов Golang имеет свои ограничения, и самое большое из них — невозможность исследовать полные дампы памяти. Полный дамп памяти — это содержимое памяти, занятое процессом, выполняющим программу.

Отображение памяти можно представить в виде дерева. Проход по этому дереву проведёт вас через различные размещения объектов в памяти. Всё, что находится в корне дерева, удерживает память от очистки сборщиком мусора. В Go нет простого способа проанализировать дамп, поэтому сложно добраться до корней объекта, который не очищается как мусор.

На момент написания статьи в Интернете не удалось найти какой-либо способ, который помог бы найти корневой объект, препятствующий освобождению памяти. Поскольку у дампов памяти существует формат, и есть достаточно простой способ экспортировать его из отладочного пакета, вероятно, есть хотя бы один подобный инструмент, который используется в Google. Судя по тому, что можно найти в сети, для Go планируется разработать инструмент для просмотра дампов памяти, но не похоже, чтобы кто-то над этим работал.

Утечки памяти

Утечки памяти (или давление памяти) могут принимать разные формы. Обычно мы считаем их багами, но истинная причина возникновения может крыться ещё на стадии проектирования.

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

• слишком большое количество выделений памяти, неверное представление данных;
• интенсивное использование рефлексии или строк;
• использование глобальных переменных;
• «осиротевшие», бесконечные горутины.

Самый простой способ создать утечку памяти в Go — определить глобальную переменную, массив, и добавить в него данные.

Golang предлагает инструмент с именем pprof. Он может помочь обнаружить проблемы с памятью. Он также может быть использован при обнаружении проблем в работе процессора.

pprof создаёт файл дампа, в который кладёт сэмпл кучи. Этот файл можно потом проанализировать/визуализировать, чтобы получить карту:

• текущего выделения памяти;
• общего (накопительного) выделения памяти.

У инструмента есть возможность сравнивать снимки, сделанные в разное время. Это может быть полезно при стрессовых сценариях для определения проблемных областей кода.

Профили pprof

pprof работает с использованием профилей.

Профиль — это набор трассировок стека, показывающих последовательности вызовов, которые привели к появлению определённого события, например к выделению памяти.

Файл runtime/pprof/pprof.go содержит подробную информацию и реализацию профилей.

Go имеет несколько встроенных профилей, которые можно использовать в обычных случаях:

• goroutine — следы всех текущих горутин;
• heap — выборка выделений памяти живых объектов;
• allocs — выборка всех прошлых выделений памяти;
• threadcreate — следы стека, которые привели к созданию новых потоков в операционной системе;
• block — следы стека, которые привели к блокировке примитивов синхронизации;
• mutex — следы стека держателей конфликтующих мьютексов.

Профиль allocs идентичен heap в отношении сбора данных. Разница заключается в том, как pprof читает во время запуска. Allocs запустит pprof в режиме, который отображает общее количество байтов, выделенных с момента запуска программы (включая байты, являющиеся мусором). Нам нужно знать выделение памяти по каждому объекту отдельно, поэтому сосредоточимся на профиле heap.

Heap

Heap (куча) — это абстрактное представление места, где операционная система хранит объекты, которые использует код. Впоследствии эта память очищается сборщиком мусора или освобождается вручную в языках программирования без сборки мусора.

Куча — не единственное место, где происходит выделение памяти. Часть также выделяется на стеке. Его цель — быстрый доступ к памяти. В Go стек обычно используется для присвоений, которые происходят в рамках функции. Другой момент, где Go использует стек, — когда компилятор «знает», сколько памяти необходимо зарезервировать перед выполнением (например для массивов фиксированного размера).

Данные кучи должны быть освобождены с использованием сборки мусора, в то время как данные стека — нет. Поэтому гораздо эффективнее использовать стек там, где это возможно.

Получение данных кучи с помощью pprof

Есть два основных способа полученить данные. Первый обычно используют в качестве части теста, и он включает импорт runtime/pprof и затем вызов pprof.WriteHeapProfile(some_file) для записи информации в кучу.

WriteHeapProfile() существует для обратной совместимости. Остальные профили не имеют таких возможностей, и вы должны использовать функцию Lookup(), чтобы получить данные профилей.

Второй, более интересный способ — пустить его через HTTP (по веб-адресу). Это позволит извлекать конкретные данные из запущенного контейнера в тестовой или e2e-среде или даже из продакшна. Всю документацию пакета pprof можно не читать, но как его включить, следует знать.

«Побочным эффектом» импорта net/http/pprof является регистрация конечных адресов на веб-сервере в корневом каталоге /debug/pprof. Используя curl, можно получить файлы с информацией для анализа.

Добавление http.ListenAndServe() в примере выше требуется только в случае, если ваша программа ранее не имела прослушивателя HTTP-сервера. Существуют также способы настроить его с помощью ServeMux.HandleFunc(), который понятнее для более сложной программы с поддержкой HTTP.

Использование pprof

Есть две основные стратегии анализа памяти с помощью pprof. Одна из них называется inuse и заключается в рассмотрении текущих выделений памяти (байтов или количества объектов). Другая носит название alloc и заключается в просматривании всех выделенных байтов или количества объектов во время выполнения программы.

Профиль heap является выборкой выделения памяти. «За кулисами» pprof использует функцию runtime.MemProfile(), которая по умолчанию собирает информацию о предоставлении памяти на каждые 512 КБ выделенных байтов. Можно изменить MemProfile() для сбора информации обо всех объектах, но скорее всего это замедлит работу приложения.

Как только файл профиля собран, пришло время загрузить его в интерактивную консоль pprof.

Посмотрим на отображаемую информацию:

Здесь важно отметить Type: inuse_space. Мы смотрим на данные выделения памяти в определённый момент (когда мы захватили профиль). Тип является значением конфигурации sample_index, а возможными значениями могут быть:

• inuse_space — объём выделенной и ещё не освобождённой памяти;
• inuse_object s — количество выделенных и ещё не освобождённых объектов;
• alloc_space — общий объём выделенной памяти (независимо от освобождённой);
• alloc_objects — общее количество выделенных объектов (независимо от освобождённых).

Теперь введите top в интерактивной консоли, и на выводе будут главные потребители памяти.

Можно увидеть строку, показывающую Dropped Nodes (сброшенные узлы). Узел — это выделение объекта или «узел» в дереве. Удаление узлов — хорошая идея, чтобы уменьшить количество мусора, но иногда это может скрывать основную причину утечек памяти.

Если хотите включить все данные профиля, добавьте опцию -nodefraction=0 при запуске pprof или введите nodefraction=0 в интерактивной консоли.

В выводимом списке можно увидеть два значения — flat и cum.

• flat означает, что память выделена функцией и удерживается ей;
• cum означает, что память выделена функцией или функцией, которая была вызвана стеком.

Этой информации может быть достаточно, чтобы понять, есть ли проблема. Например, функция отвечает за выделение большого объёма памяти, но не удерживает её. Это значит, что какой-то другой объект указывает на эту память и удерживает её, то есть может возникнуть утечка памяти или баг.

Команда top в интерактивной консоли по умолчанию выводит первые 10 позиций потребителей памяти. Но эта команда поддерживает формат topN, где N — количество записей, которые вы хотите увидеть. Например, при наборе top70, будут выведены все узлы.

Графическое представление потоков выделения памяти

Команда topN предоставляет текстовый список, но есть несколько полезных опций для визуального представления, которые есть в pprof. Можно использовать .png или .gif и многое другое (полный список можно увидеть по команде go tool pprof -help).

В нашей системе визуализация по умолчанию выглядит примерно так:

Это визуализация потоков выделения памяти в программе согласно трассировкам стека. Прочитать график не так сложно, как кажется. Белый квадрат с номером показывает выделенное пространство и совокупный объём памяти, который он занимает прямо сейчас. А каждый более широкий прямоугольник показывает выделившую память функцию.

Стоит отметить, что png-изображение выше было снято в режиме inuse_space. Ещё обратите внимание на inuse_objects, это также может помочь в поиске проблем с выделением.

Копаем глубже, чтобы найти первопричину

В нашем случае membuffers (библиотека сериализации данных) удерживает память. Но это не значит, что обязательно есть утечка в сегменте кода. Это значит, что память удерживается функцией. Важно понимать, как читать граф и вывод pprof в целом. В случае сериализации данных выделяется память для структур и примитивных объектов (int, string) и никогда не освобождается.

Неверно истолковав график, можно предположить, что один из узлов на пути к сериализации отвечает за сохранение памяти, например:

Где-то в цепочке можно увидеть библиотеку логирования, занимающую > 50 Мб выделенной памяти. Это память, которая выделяется функциями. Логгер в процессе своей работы вызывает выделение памяти, поскольку ему необходимо сериализовать данные для вывода их в журнал.

Из графа также видно, что память удерживается только сериализацией и больше ничем. Объём памяти самого логгера составляет около 30 % от общего объёма. Это значит, что проблема не в писателе. Он регистрирует что-то, чего не должно быть. А значит, утечка памяти не в журнале логов.

Знакомьтесь с командой list. Она принимает регулярное выражение, которое будет фильтровать то, что надо отобразить. Список (list) в действительности представляет собой исходный код с комментариями, относящийся к выделению. В контексте изучаемого логгера выполним list RequestNew, чтобы увидеть вызовы, сделанные в регистраторе. Эти вызовы поступают из двух функций, которые начинаются с одного и того же префикса.

Выделения памяти находятся в столбце cum. Это значит, что выделенная память сохраняется в стеке вызовов. Это соответствует тому, что показывает график. Причина выделения памяти писателем заключается в том, что мы отправили ему весь «блокирующий» объект. Нужно было как минимум сериализовать некоторые его части.

List может найти исходный код, если искать его в среде GOPATH. В случаях, когда корневой объект не совпадает (зависит от вашего сборщика), вы можете использовать опцию -trim_path. Она поможет исправить код и позволит увидеть аннотированный исходный код. Не забудьте установить свой Git на правильный коммит, который работал во время захвата профиля heap.

Так почему память удерживается?

В случае с Java или .Net можно использовать какой-нибудь анализатор корневых объектов и добраться до объекта, который создаёт утечку. Но с Go это невозможно из-за проблем со встроенными инструментами и из-за низкоуровневого представления памяти.

Не вдаваясь в детали, мы не думаем, что Go запоминает, какой объект по какому адресу хранится (за исключением, возможно, указателей). Для понимания, по какому адресу памяти хранится член объекта (структуры), потребуется карта вывода из профиля heap. Значит, перед захватом полного дампа ядра следует также захватить профиль heap, чтобы адреса могли быть сопоставлены с выделившими память строкой и файлом, а следовательно и объектом, представленным в памяти.

Установив значение nodefraction=0, можно увидеть всю карту выделенных объектов, включая самые маленькие.

У нас есть два новых поддерева. Более длинное новое дерево зеленого цвета, которое полностью отсоединено от остальной системы, является тестовым прогоном, оно нам не интересно.

Небольшое поддерево синего цвета, соединённое ребром со всей системой, — это inMemoryBlockPersistance. Это бэкенд, который хранит все данные в памяти, но не сохраняет их на диске. Можно сразу увидеть, что в нём находятся два больших объекта. Два — потому что размер объекта составляет 1,28 Мб, а функция сохраняет 2,57 Мб, то есть в два раза больше.

Теперь проблема отчётливо ясна. Можно использовать отладчик и увидеть, что всему виной массив, который удерживает все блоки для постоянства памяти.

Что можно исправить?

Десериализованные данные занимали слишком много памяти. Откуда взялось 142 Мб для чего-то, что должно занимать существенно меньше памяти? Здесь может помочь pprof — он существует именно для того, чтобы точно отвечать на такие вопросы.

Чтобы просмотреть исходный код функции, запустим lazyCalcOffsets(). Теперь можем увидеть, что flat и cum одинаковы. Это указывает на то, что выделенная память также сохраняется этими точками выделения. Функция make() тоже занимает немного памяти, т. к. это указатель на структуру данных. Ещё можно увидеть, что занимает память выделение в строке 43.

Следует отметить, что функция make() в Go позволяет делать не только отображения, но и срезы. Присвоение отображению не то же самое, что присвоение простой переменной — использование переменных предполагает большие издержки ресурсов. Чем больше элементов, тем больше будут эти издержки по сравнению со срезом.

При использовании map[int]T когда данные не редки или могут быть преобразованы в последовательные индексы и потребление памяти является важным фактором, для большей эффективности следует использовать срез. Однако большой срез при расширении данных может замедлить операцию, в то время как для отображения это замедление будет незначительным. Как вы уже поняли, не существует волшебной формулы для оптимизации.

В нашей системе мы теперь используем срез вместо отображения. Из-за способа получения данных и того, как мы получаем к ним доступ, кроме пары строк и структуры данных, никаких других изменений кода не потребовалось. Посмотрим, как это повлияло на потребление памяти.

Взглянем на benchcmp для пары тестов.

Тесты на чтение инициализируют структуру данных, которая создаёт выделения. Время выполнения улучшилось на ~30 %, выделение сократилось на 50 %, а потребление памяти > 90 %.

Поскольку отображение (теперь уже срез) никогда не было заполнено большим количеством элементов, цифры показывают то, что мы увидим в продакшене. Результат зависит от энтропии данных, но могут быть случаи, когда улучшение как выделения, так и потребления памяти было бы ещё больше.

Ещё раз задействовав pprof и захватив профиль heap из того же теста, можно увидеть, что теперь потребление памяти фактически сократилось на ~90 %.

Вывод прост — для небольших наборов данных не следует использовать отображения, достаточно срезов. Отображения имеют большие издержки.

Полный дамп памяти

Именно здесь можно наблюдать самое большое ограничение инструментов Go. Этот язык развивается большими темпами, но это развитие имеет свою цену в случае полного дампа и выделения памяти. Формат полного дампа кучи по мере своих обновлений является обратно не совместимым. Помните это, когда будете использовать последнюю версию. Для записи полного дампа кучи вы можете использовать debug.WriteHeapDump().

Следует также отметить, что не существует хорошего решения для изучения полных дампов. Вот некоторые вещи, которые стоит игнорировать, если собираетесь попробовать открыть полный дамп самостоятельно, начиная с Go 1.11:

• В macOS нет способа открыть и отладить полный дамп ядра, это работает только в Linux.
• Инструменты в этом репозитории предназначены для Go 1.3. Существует форк для 1.7+, но он также не работает должным образом (не полностью).
• ViewCore из репозитория Go на самом деле не компилируется. Это достаточно легко исправить, указав внутренние пакеты на golang.org вместо github.com. Но это также не работает на macOS и может быть работает на Linux.
• Также corelib не работает на macOS.

Ещё одна важная деталь о pprof — это его интерфейс. Он может сэкономить много времени при исследовании проблем профилей, созданных с помощью pprof.