Как-то, анализируя дефект в разрабатываемом продукте, я наткнулся на архитектурную особенность менеджера памяти, который мы использовали. Дефект приводил к увеличению времени создания некоторых объектов. Особенность архитектуры заключалась в использовании паттерна Singleton при работе с менеджером памяти (далее X allocator). Схематично это выглядит так:
Рисунок 1 – Структурная схема работы X allocator
Из схемы видно, что доступ к глобальной куче защищен мьютексом. Такая архитектура, при интенсивном создании однотипных объектов из нескольких потоков, может привести к тому, что потоки будут вставать в очередь на этом мьютексе. А ведь одна из главных особенностей продукта – это возможность его масштабирования за счет увеличения количества потоков обработки (потоков выполняющих одинаковые действия). Поэтому такой подход потенциально может стать узким местом.
Осознав масштаб угрозы, я решил просветиться и полез в Интернет искать информацию про многопоточные менеджеры памяти (multi-threaded pooled allocators). Пока искал, наткнулся на несколько проектов:
• Hoard (http://www.hoard.org/), распространяемый под лицензией GPL v.2.0;
• TBB Memory Allocator от Intel (отбросил, т.к. библиотека платная);
• Thread-Caching Malloc из состава gperftools от Google (https://code.google.com/p/gperftools/).
Также в процессе поиска нашел очень интересную статью, в которой описываются различные подходы при работе с динамической памятью – www.realcoding.net/article/view/2747.
Имея на руках несколько решений, я решил поэкспериментировать: сравнить производительность различных менеджеров памяти и подсмотреть решение для оптимизации X allocator.
Когда я проанализировал реализацию Hoard и TCMalloc, у меня сложилось понимание, что реализованные в них менеджеры памяти используют кеширование по потокам (альтернатива такого подхода – использование lock-free списков). Кеширование позволяет при удалении объекта возвращать память не в глобальную кучу, а помещать в кэш этого потока. Так что при повторном создании такого же объекта потоку не придется лезть под мьютекс в общую кучу. Схематично этот подход можно изобразить следующим образом (рисунок 2):
Рисунок 2 – Структурная схема работы X allocator с использование кеширования потоков
Реализовав на коленке кеширование в X allocator (далее pooled X allocator), я приступил к сравнению производительности.
Исследование поведения менеджеров памяти проводилось при интенсивном потреблении CPU. Тест заключался в создании X объектов на N потоках, при этом проверялась гипотеза, что время выполнения теста обратно пропорционально количеству потоков. Пример для идеального мира: создание 1000 объектов на 1 потоке будет выполняться в 2 раза дольше, чем создание 1000 объектов на 2х потоках (по 500 объектов на поток).
Проводимые тесты можно разбить по следующим категориям:
1. Тип ОС:
a. Windows;
b. Linux.
2. Размер объектов:
a. 128b;
b. 1Kb;
c. 1Mb.
3. Менеджер памяти:
a. системный менеджер памяти;
b. TCMalloc (Google);
c. Hoard;
d. pooled X allocator (заменил X allocator singleton на массив X allocator’ов, при выделении и освобождении памяти номер X allocator’а высчитывается по tid потока).
e. X allocator;
4. Количество потоков: от 1 до 8;
5. Каждый эксперимент я проводил по 5 раз, после рассчитал среднее арифметическое значение.
Ниже приведу только один график (рисунок 3) и результаты эксперимента для него (таблица 1), так как для всех случаев результаты получились похожими. Результаты приведены для ОС Linux объекты размером 1 Kb.
Рисунок 3 – Результаты исследования производительности менеджеров памяти
На графике ось абсцисс – это количество потоков, ось ординат – это относительное время выполнения теста (за 100% берется время выполнения теста на одном потоке с использованием системного менеджера памяти).
Таблица 1 — Результаты исследования производительности менеджеров памяти
По полученным результатам можно сделать следующие выводы:
1. X allocator, который мы используем, показал хорошую производительность только на 1 потоке, при увеличении количества потоков производительность падает (из-за конкуренции на мьютексе);
2. остальные менеджеры памяти справились с задачей распараллеливания, действительно, при увеличении количества потоков задача стала выполняться быстрее;
3. TCMalloc показал лучшую производительность.
Конечно, я понимал, что эксперимент искусственный и в реальных условиях рост производительность не будет таким же значительным (некоторые тесты показали рост производительности в 80 раз). Когда я заменил в своем проекте X allocator на TCMalloc и провел эксперимент на реальных данных, увеличение производительности составило 10%, и это достаточно хороший прирост.
Производительность – это, конечно, замечательно, но X allocator предоставляет возможность анализировать потребляемую память и искать утечки. А как с этим обстоят дела у остальных менеджеров памяти? Это сравнение я постараюсь подробно раскрыть в следующей статье.
Автор: MI7
