The influence of DDR4 RAM characteristics on the performance of the PostgreSQL database management system
The influence of DDR4 RAM characteristics on the performance of the PostgreSQL database management system
Abstract
This article presents a complex study of the impact of DDR4 RAM hardware characteristics on the performance of the PostgreSQL database management system. The authors aim to determine the degree of influence of such RAM parameters as clock frequency, timings including CAS, RAS-to-CAS, RP, RAS delays, and bandwidth on the speed of executing SQL queries of varying degrees of complexity. The experiments were conducted using a hardware configuration based on an AMD Ryzen 5 3600 processor with DDR4 memory modules tested in two modes: XMP-3200 with a frequency of 3200 MHz, and a reduced frequency of 1333 MHz with optimised timings. The testing methodology included synthetic tests using the WinRAR utility to measure throughput and latency, load tests in PostgreSQL using the pgbench tool to measure the number of transactions per second, as well as performing complex SQL queries with aggregation operations, table joins via JOIN, and data generation using Common Table Expressions and the generate_series function. Key findings of the research showed that reducing the memory frequency from 3200 MHz to 1333 MHz resulted in a 4.9% decrease in system performance, resulting in a decrease in transactions per second from 12,492 to 11,876 and an increase in average latency from 1.596 milliseconds to 1.679 milliseconds. At the same time, it was found that memory timings, expressed in nanoseconds, have less impact on overall performance than frequency characteristics, especially when executing complex queries with high bandwidth requirements. The question of the economic feasibility of switching to high-frequency DDR4 modules requires a differentiated approach and depends on the specific workload: for servers with intensive OLTP queries, such investments may be fully reasonable, while for systems with moderate loads, the difference in performance may be insignificant. The practical significance of the study lies in the ability to formulate specific recommendations for selecting RAM for PostgreSQL servers, as well as in the development of a methodology for testing the performance of database management systems with different memory configurations.
1. Введение
С развитием информационных технологий всё более остро стоит проблема эффективной обработки больших объёмов данных. Современные системы управления базами данных (СУБД) всё чаще сталкиваются с необходимостью обеспечивать высокую скорость выполнения запросов при одновременном увеличении объёмов хранимой информации. Одним из ключевых факторов, влияющих на производительность таких систем, является аппаратная конфигурация вычислительной платформы, в особенности характеристики оперативной памяти.
Оперативная память типа Double Data Rate Synchronous Dynamic Random-Access Memory (DDR SDRAM , ) играет важную роль в обеспечении быстрого доступа к данным, используемым процессором. С развитием технологии появилось несколько поколений этой памяти, каждое из которых предлагает улучшенные параметры: тактовая частота, тайминги, пропускная способность. Однако вопрос о том, насколько значимо влияние этих параметров на реальную производительность СУБД при обработке запросов, остаётся открытым . Более того, с экономической точки зрения не всегда очевидно, насколько целесообразно приобретение более дорогих модулей памяти с улучшенными характеристиками.
Целью данной работы является исследование влияния аппаратных характеристик оперативной памяти типа DDR4 на скорость выполнения SQL-запросов в системе управления базами данных PostgreSQL . На основе экспериментальных данных предполагается оценить степень влияния таких параметров памяти, как частота, тайминги и пропускная способность, а также определить экономическую целесообразность перехода на более высокопроизводительные модули памяти.
Для достижения поставленной цели решаются следующие задачи:
1. Провести анализ устройства и принципов функционирования оперативной памяти DDR4, а также особенностей взаимодействия СУБД PostgreSQL с оперативной памятью.
2. Разработать методику тестирования производительности СУБД PostgreSQL при различных параметрах оперативной памяти.
3. Провести серию экспериментов по измерению времени выполнения SQL-запросов с использованием модулей памяти DDR4 с различными частотами, таймингами и уровнями пропускной способности.
4. Обработать и проанализировать полученные данные для выявления зависимости скорости выполнения запросов от характеристик ОЗУ.
5. Сделать выводы о степени влияния аппаратных параметров памяти на производительность СУБД и оценить экономическую целесообразность использования более высокочастотных модулей памяти.
Методика тестирования, представленная в исследовании, опирается на системный и всеобъемлющий подход к оценке влияния различных параметров оперативной памяти DDR4 на производительность системы управления базами данных PostgreSQL. Целью экспериментов является всестороннее изучение того, каким образом такие технические характеристики памяти, как тактовая частота, величины основных задержек (включая CAS, RAS-to-CAS, RP и RAS), а также пропускная способность, отражаются на скорости выполнения запросов, в частности — при сложных вычислительных сценариях.
В качестве базовой платформы был выбран современный вычислительный комплекс, включающий в себя центральный процессор AMD Ryzen 5 3600 с архитектурой Zen 2, способный обеспечивать высокую вычислительную мощность, совместно с четырьмя одноранговыми модулями DDR4-памяти объёмом по 8 гигабайт каждый. При этом была предусмотрена возможность работы оперативной памяти в двух режимах: в высокочастотной конфигурации XMP-3200 (с эффективной частотой 3200 мегагерц и таймингами 16-18-18-36 при напряжении 1,35 Вольта) и в режиме пониженной частоты 1333 мегагерца с ручной настройкой более агрессивных таймингов. Аппаратная платформа базировалась на материнской плате Asus Prime B450M-A II, а операционной системой выступала Microsoft Windows 10 версии 22H2. В качестве постоянного хранилища данных использовался твердотельный накопитель Samsung 980 EVO объёмом 500 гигабайт, заполненный на 70% для приближения условий к реальным эксплуатационным.
Тестирование включало как синтетические, так и прикладные этапы. На синтетическом уровне использовалась встроенная функция тестирования из утилиты WinRAR, которая посредством многопоточной обработки данных моделировала интенсивную нагрузку на память и процессор. В ходе этой процедуры измерялась скорость выполнения операций сжатия и распаковки данных, а также выявлялись возможные ошибки, указывающие на нестабильность работы памяти в той или иной конфигурации. Полученные результаты отражали производительность в килобайтах в секунду и демонстрировали общее влияние параметров памяти на обработку повседневных задач.
Для моделирования реальных условий работы была сгенерирована полноценная база данных объёмом 4 гигабайта с помощью библиотеки Faker. Структура базы данных была нормализована, снабжена внешними ключами и включала таблицы, предназначенные для выполнения сложных SQL-запросов, в которых активно использовались операции JOIN, обобщённые табличные выражения (CTE), оконные функции и генерация последовательностей через функцию generate\_series. В процессе тестирования применялись как встроенные средства мониторинга PostgreSQL, так и инструменты EXPLAIN и EXPLAIN ANALYZE, позволившие детально рассмотреть план выполнения запросов, оценить реальное время выполнения, количество обработанных строк и другие метрики.
Для моделирования высокой нагрузки был написан запрос, в котором использовались многочисленные агрегации, сортировки и фильтрации, предъявляющие высокие требования к оперативной памяти, особенно в части создания временных хэш-таблиц и подсчёта уникальных значений через COUNT(DISTINCT). Это позволило оценить пределы возможностей системы в условиях интенсивной обработки данных. Во всех тестах фиксировались ключевые показатели, включая количество транзакций в секунду и среднюю задержку обработки запросов. Тестирование проводилось многократно, при этом каждый запуск производился в идентичных условиях для исключения случайных флуктуаций производительности.
Все изменения параметров памяти производились вручную через UEFI BIOS, а стабильность системы дополнительно проверялась в стрессовых условиях. В ходе эксперимента отдельно фиксировались значения задержек в наносекундах для каждой конфигурации, что позволило рассчитать реальное влияние на скорость доступа. Особенно важно, что уменьшение частоты памяти приводило к существенному увеличению задержек и снижению пропускной способности, что напрямую отражалось на итоговой производительности как при синтетических тестах, так и при работе СУБД.
Методика, применённая в исследовании, представляет собой комплексный подход, сочетающий аппаратное тестирование, программное моделирование, анализ реальных SQL-нагрузок и количественную оценку всех изменений в производительности. Такой формат позволяет с высокой степенью достоверности оценить влияние тех или иных характеристик оперативной памяти на работу баз данных и сформулировать обоснованные рекомендации по выбору аппаратного обеспечения в зависимости от характера предполагаемой нагрузки.
Результаты проведённого исследования позволят не только оценить текущую ситуацию с применением DDR4-памяти в серверах баз данных, но и получить представление о том, какие изменения в производительности можно ожидать при переходе на новые или обратно на более старые поколения памяти.
Таким образом, работа будет иметь как практическую ценность, связанную с оптимизацией существующих систем, так и теоретическую позволяя делать обоснованные прогнозы относительно будущих технологий памяти.
2. Технология DDR SDRAM
Появление нового типа ОЗУ было продиктовано ростом производительности процессоров и увеличением объёмов данных. Таким образом, SDRAM уже не могла удовлетворить растущие требования. В 2000 году сообщество инженеров (Joint Electron Device Engineering Council, JEDEC), специализирующихся в области электронных устройств утвердила стандарт DDR SDRAM. JEDEC — это ведущая независимая отраслевая ассоциация, занимающаяся разработкой и стандартизацией технологий в области микроэлектроники, включая оперативную память. В контексте разработки и внедрения DDR SDRAM (и последующих поколений памяти) роль JEDEC является критически важной , .
В JEDEC входят сотни компаний, включая производителей полупроводников, разработчиков технологий и поставщиков оборудования (например, Samsung, Micron Technology, Intel, Advanced Micro Devices, NVIDIA, SK Hynix, Texas Instruments, Qualcomm).
Главной отличительной особенностью нового стандарта является одноименный принцип DDR (Double Data Rate), реализация которого основана на считывании данных не только по фронту, но и по срезу тактового сигнала. Таким образом, если тактовая частота DDR SDRAM составляет 100 МГц, эффективная частота передачи данных будет 200 МГц (рисунок 1).
Рисунок 1 - Принцип работы DDR
Частота, тайминги и напряжение — это основные характеристики модулей памяти, которые влияют на итоговую производительность электронных вычислительных машин
, . Рассмотрим подробнее тайминги.Работа с оперативной памятью так или иначе сводится к физическому взаимодействию с электротехническими элементами. Все подобные процессы не могут происходить моментально и тайминги, непосредственно, регламентируют эти процессы позволяя всем компонентам памяти работать стабильно и предсказуемо. Единица измерения — такт. Чтобы считать или записать какие-либо значения в память, используются определённые сигналы:
- сигнал выбора столбца матрицы ячеек памяти (англ. Column Address Strobe, CAS);
- сигнал выбора строки матрицы ячеек памяти (англ. Row Address Strobe, RAS).
Рассмотрим 4 основных тайминга, которые оказывают наиболее ощутимое влияние на производительность модулей памяти.
Задержка строба адреса столбца (англ. CAS Delay, tCL) — задержка между выбором столбца и началом передачи данных. После отправки контроллером памяти запроса на доступ к определённой строке, он ожидает указанное число тактов, прежде чем данные будут доступны.
Задержка между активацией строки и выбором столбца (англ. RAS to CAS Delay, tRCD) — это время, необходимое для активации строки перед обращением ко столбцу. Перед тем как начать чтение или запись данных, контроллер памяти должен активировать строку (RAS) и затем выбрать столбец (CAS). Именно задержку между двумя этими операциями регламентирует tRCD.
Задержка между командой на подзарядку precharge до момента закрытия строки (англ. Row Precharge Time, tRP) — это время, необходимое для закрытия текущей строки перед открытием новой. После завершения операций с текущей строкой память должна быть «подготовлена» (precharged) для работы с другой строкой. Значение tRP определяет, сколько тактовых циклов требуется для этого процесса.
tRAS (Row Active Time) это время между активацией строки до срабатывания команды precharge.
Для простоты восприятия можно воспользоваться картой с рассчитанными значениями зависимости времени доступа к памяти в наносекундах от частоты работы и задержек CAS (рисунок 2).
Рисунок 2 - Карта времени доступа к оперативной памяти
3. Особенности работы PostgreSQL с оперативной памятью
PostgreSQL является дисковой СУБД, но она активно использует оперативную память для ускорения работы, что будет наглядно продемонстрировано.
PostgreSQL использует оперативную память для кэширования данных, обработки запросов, хранения промежуточных результатов операций.
В отличие от in-memory, СУБД PostgreSQL не хранит все данные в RAM по умолчанию, эти ограничения прописаны в конфигурационном файле, однако существуют множество механизмов для кэширования и оптимизации администрирования баз данных. Основными механизмами, которые взаимодействуют с оперативной памятью являются shared_buffers, work_mem и maintenance_work_mem.
- shared_buffers — параметр, определяющий, сколько оперативной памяти PostgreSQL выделяет для кэширования данных. Этот кэш используется для хранения страниц данных (блоков), которые читаются с диска или записываются на него;
- work_mem — параметр определяет сколько памяти может быть выделено для выполнения операций сортировки, хэширования и агрегации внутри одного запроса;
- maintenance_work_mem — параметр, который определяет, сколько памяти выделяется для операций обслуживания ALTER TABLE, VACUUM и создания индексов.
Существуют некоторые рекомендованные значения этих параметров, однако в целях повышения воспроизводимости и надежности эксперимента в работе используются свои настройки СУБД.
Ниже представлена диаграмма, визуализирующая распределение различных параметров по их удельному весу в общей совокупности. Каждый сектор данной диаграммы соответствует отдельной категории или параметру, при этом размер каждого сектора пропорционален относительной значимости или доле этого параметра в общем объёме анализируемых данных (рисунок 3).
Рисунок 3 - Диаграмма относительных величин главных параметров памяти
4. Конфигурация выбранного аппаратного обеспечения
Аппаратно-программная конфигурация (рисунок 4) представлена рядовыми компонентами для современных персональных компьютеров (см. таблицу 1).
Рисунок 4 - Спецификации центрального процессора
Все исследования и тестирования проводятся при заводских значениях напряжений и тактовых частот самого процессора, изменения не предусмотрены. Это позволяет оценить реальную производительность в стандартных условиях эксплуатации.
Таблица 1 - Аппаратно-программная конфигурация
Центральный процессор | AMD Ryzen 5 3600 4200 МГц |
Графическая подсистема | AMD RX 6600 8 ГБ GDDR6 |
Подсистема памяти ОЗУ | DDR4 SDRAM 4x8 ГБ. Максимальная паспортная частота 3200 МГц |
Системная плата | Asus Prime B450M-A II |
Операционная система | Microsoft Windows 10 22H2 |
Твердотельный накопитель SSD M.2 | Samsung 980 EVO 500ГБ |
Рисунок 5 - Спецификации центрального процессора
Одноранговый модуль содержит один логический набор чипов, который обрабатывает данные за один такт. Двухранговая же реализация подразумевает два независимых набора чипов, которые работают поочерёдно, но используют общую шину.
С точки зрения производительности одноранговые модули памяти несколько быстрее в некоторых сценариях, где важна высокая скорость доступа. Двухранговые же модули потенциально выгоднее использовать для серверов из-за более высоких пропускных способностей.
В дальнейших исследованиях используются именно одноранговые модули по причине их дешевизны и распространённости (рисунок 6).
Стоит отметить, что все модули памяти характеризуются одинаковым объемом, составляющим 8 ГБ. Данное решение обусловлено тем, что применение модулей различного объема может стать причиной снижения производительности системы при заполнении модуля с меньшим объемом возникает переход в одноканальный режим работы, что негативно сказывается на скорости передачи данных и общем быстродействии системы.
Рисунок 6 - Спецификации второй пары модулей памяти на чипах Nanya
Тем не менее стоит учитывать, что использование модулей памяти с различной элементной базой, особенно при задействовании всех четырёх слотов материнской платы в двухканальном режиме, может повлиять на стабильность работы всей системы. Дело в том, что несмотря на одинаковые номинальные параметры, физические различия между чипами памяти, такими как разница в технологических процессах изготовления, схемотехнике или даже реакции на изменение напряжения и температуры, могут привести к нестабильной работе модулей в составе одной конфигурации.
Значения пропускных способностей и задержек памяти в профиле XMP-3200 представлены на рисунке 7.
Рисунок 7 - Значения пропускных способностей и задержек памяти в профиле XMP-3200
Проведем первые измерения посредством выполнения сжатия и распаковки данных с помощью утилиты WinRAR.
Команда «Тест быстродействия» в утилите WinRAR позволяет сравнивать производительность алгоритма сжатия RAR на разных компьютерах
, .Она генерирует случайные данные, вызывающие повышенную нагрузку на процессор и память. Затем данные сжимаются и распаковываются по алгоритму RAR, после чего результат распаковки сравнивается с исходными данными. Если обнаруживается какое-либо различие, в окне команды в строке «Ошибки» выводится сообщение «Да». Такие ошибки могут свидетельствовать о проблемах с аппаратурой, например о нестабильной работе памяти. Кроме того, отображается объём обработанных данных и скорость сжатия — текущая и результирующая, в КБ/с. Результирующую скорость можно использовать для сравнения производительности RAR в различных условиях, например при выборе нового компьютера, чтобы узнать, какой из них быстрее сжимает данные. Используется общий алгоритм упаковки в режиме обычного сжатия со словарём 32 МБ, все дополнительные фильтры и алгоритмы отключаются.
С помощью параметра «Многопоточность» можно сравнить производительность обычной однопоточной и многопоточной (оптимизированной для мультипроцессорных архитектур) версий алгоритма сжатия RAR.
Для заполнения словаря упаковки, который в начале операции пуст, требуется некоторое время. Пока он не будет заполнен, значение скорости непостоянно, поэтому текущая скорость начинает отображаться лишь через несколько секунд после вызова команды.
Результирующая скорость выводится только после сбора статистики, необходимой для получения точного результата. После того как результирующая скорость установлена, она больше не изменяется.
Несмотря на то, что исходные данные случайны, степень их избыточности и другие параметры всегда останутся одинаковыми, поэтому команда будет выдавать практически постоянную текущую скорость вне зависимости от длительности выполнения при условии, что загрузка системы не изменяется.
Далее была изменена частотная характеристика и тайминги модулей памяти (рисунок 8). Все изменения производились через унифицированный расширяемый интерфейс встроенного программного обеспечения (англ. Unified Extensible Firmware Interface, UEFI
, ). Следует отметить, что подобного рода изменения поддерживают не все материнские платы, а лишь конкретные чипсеты. Эту информацию требуется уточнять непосредственно в технических спецификациях платы.При превышении паспортных значений частоты и таймингов модулей памяти, стабильная работа не гарантируется и требует дополнительных тестов стабильности под нагрузкой.
Рисунок 8 - Значения пропускных способностей и задержек памяти в конфигурации с частотой 1333 МГц, сниженными таймингами и напряжением
Рисунок 9 - Изменения таймингов памяти
Снижение таймингов в нашем случае не приведет к увеличению скорости доступа из-за некоторых особенностей. Хотя тайминги в конфигурации XMP-3200 выше в тактах, но в пересчёте в наносекунды они всё равно оказываются ниже из-за более высокой эффективной частоты памяти.
Для расчёта используем формулу
Тайминги в наносекундах для 3200 МГц:
- CL = 5 нс.
- tRCD = 5,625 нс.
- tRP = 5,625 нс.
- tRAS = 11,25 нс.
Тайминги в наносекундах для 1333 МГц:
- CL = 7,5 нс.
- tRCD = 7,5 нс.
- tRP = 7,5 нс.
- tRAS = 16,5 нс.
Уменьшение частоты памяти отразилось на производительности в тесте. Таким образом, результаты отличаются примерно на 14,43% в однопоточном режиме и на 20,06% (рисунок 10) в пользу конфигурации XMP-3200.
Рисунок 10 - Проведённый тест в многопоточном и однопоточном режиме в конфигурации 1333МГц
5. Генерация базы данных и проведение измерений
Далее приступим к работе с системой управления базами данных PostgreSQL. Для этого нам понадобится установить саму СУБД с платформой pgAdmin для ее администрирования, а также связать с Python3 для дальнейшей генерации базы данных
, .Дальнейшая подготовка инфраструктуры требует обновления библиотек (рисунок 11).
Рисунок 11 - Обновление зависимостей библиотек
Также было принято решение об использовании библиотеки asyncpg для работы с СУБД.
Asyncpg — это высокопроизводительная асинхронная библиотека для Python, предназначенная для работы с PostgreSQL. Она позволяет выполнять SQL-запросы к PostgreSQL без блокировки основного потока, что критично для асинхронных приложений (например, на базе asyncio, FastAPI или Quart)
, .PostgreSQL предоставляет гибкие возможности для настройки использования оперативной памяти. Правильная конфигурация параметров позволяет значительно повысить производительность системы, особенно при работе с большими объемами данных. Однако важно учитывать специфику рабочей нагрузки и характеристики сервера, чтобы избежать перегрузки системы и обеспечить стабильную работу. Значения параметров shared_buffers и work_mem по умолчанию крайне малы для проведения тестов такого рода и будут плохо влиять на результирующую производительность в работе с большими данными и, следовательно, негативно отразятся на репрезентативности всего исследования.
Таким образом, конфигурация по умолчанию неприменима для исследований скорости выполнения запросов из-за периодического обращения в постоянное запоминающее устройство. Значения соответствующих параметров можно изменить, отредактировав файл postgresql.conf. В данном случае было принято решение изменить значения на 4 ГБ для того, чтобы полностью покрыть потребности базы данных в адресном пространстве. Чтобы изменения были приняты, нужно перезапустить службу postgresql-x64-17. Служба postgresql-x64-17 обеспечивает работу сервера PostgreSQL в операционной системе Windows. Запуск происходит в качестве сервиса ОС, что автоматизирует работу и предоставляет до-ступ для клиентских приложений.
PostgreSQL с pgAdmin предоставляет удобные и информативные метрики производительности (рисунок 12):
- Transactions (транзакции): синяя линия показывает общее количество транзакций, выполняемых в секунду.
- Commits (подтверждения): оранжевая линия отражает количество успешно завершенных транзакций.
- Rollbacks (откаты): зеленая линия показывает количество отмененных транзакций.
- Inserts (вставки): голубая линия показывает количество вставленных строк (кортежей).
- Updates (обновления): оранжевая линия отражает количество обновленных строк.
- Deletes (удаления): зеленая линия показывает количество удаленных строк.
- Fetched (полученные): голубая линия показывает количество строк, полученных в результате выполнения запросов.
- Returned (возвращенные): оранжевая линия отражает количество строк, возвращаемых клиентам.
- Reads (чтения блоков): голубая линия показывает количество блоков, считанных из диска.
- Hits (попадания в кэш): оранжевая линия отражает количество блоков, найденных в кэше без обращения к диску.
Рисунок 12 - Метрики производительности PostgreSQL
Для генерации базы данных (рисунок 13) объёмом 4 ГБ написана программа на Python с применением библиотеки Faker, которая позволяет генерировать правдоподобные данные, для демонстрации наиболее репрезентативных результатов по итогам исследования.
Рисунок 13 - Логическая модель базы данных
Промежуточный вариант создания необходим для отладки процесса генерации базы данных, в связи с высокой нагрузкой на алгоритм Faker, который при достижении определённого количества записей перестаёт корректно функционировать. Обратим внимание, что на это ушло всего порядка 13 секунд.
Итоговый вариант базы данных объёмом 4 ГБ был записан на твердотельный накопитель Samsung SSD 980 EVO 500ГБ, чтобы обеспечить максимальную производительность, а также свести к минимуму недостатки дисковых СУБД.
Произведены измерения скорости последовательных и случайных чтений накопителя, где хранится база данных произведены в условиях его заполнения на 70%, что несколько снижает скорость доступа к памяти из-за заполнения Single Level Cell
, кэша (рисунок 14).
Рисунок 14 - Тестирование SSD, на котором находится база данных
pgbench — это встроенный инструмент PostgreSQL для тестирования производительности базы данных. Он позволяет моделировать нагрузку на базу данных, выполнять транзакции и измерять такие метрики, как количество транзакций в секунду (англ. transactions per second, TPS). pgbench часто используется для оценки производительности системы (рисунок 15), тестирования настроек конфигурации или сравнения различных аппаратных конфигураций.
Рисунок 15 - Результаты теста в конфигурации XMP-3200
Рисунок 16 - Результаты теста в конфигурации 1333 МГц
Для дальнейшего тестирования был написан SQL-запрос (рисунок 17), который структурно построен на последовательном применении обобщенных табличных выражений (англ. Common Table Expressions, CTE) для разбиения задачи на логические этапы, где каждый из них предъявляет высокие требования к оперативной памяти. Основная нагрузка возникает при выполнении JOIN операции между таблицами orders, order_items, products, categories и suppliers.
Агрегации в CTE user_stats, product_stats и category_stats требуют создания хэш-таблиц для группировки данных по пользователям, товарам и категориям. Подобного рода операции требуют значительный объём памяти, особенно при подсчёте уникальных значений (COUNT DISTINCT) и вычислении оконных функций ROW_NUMBER, которые сортируют данные по выручке (рисунок 18).
Рисунок 17 - Результат выполнения запроса в конфигурации памяти XMP-3200
Это особенно важно учитывать при проектировании и оптимизации запросов, поскольку простое добавление LIMIT без должной оптимизации самой структуры запроса может создать ложное ощущение его эффективности.
Рисунок 18 - Результат выполнения запроса в конфигурации памяти 1333MHz
При исполнении запроса также можно воспользоваться встроенным инструментом EXPLAIN ANALYZE, который может показать не только план выполнения запроса, но и реальное время выполнения в миллисекундах, количество обработанных строк, количество итераций процесса, время оптимизации запроса.
Далее для сравнения конфигураций в условиях повышенной нагрузки был написан запрос с еще более сложной структурой, который представляет собой, как и CTE, так и объединение таблиц, агрегацию и генерацию данных.
Наиболее ресурсоёмким является использование функции generate_series (1, 100) в CTE temp_large_data, так как она приводит к увеличению числа строк в 100 раз относительно исходных данных в таблице products.
Помимо этого, использование оператора COUNT(DISTINCT ...) в нескольких CTE и в основном запросе приводит к подсчёту уникальных значений и созданию временных данных, таких как хэш-таблицы или деревья (рисунок 19).
Рисунок 19 - Результат выполнения второго запроса в конфигурации памяти XMP-3200
Рисунок 20 - Результат выполнения второго запроса в конфигурации памяти 1333MHz
Рисунок 21 - Время выполнения запроса с использованием инструмента EXPLAIN ANALYSE во второй конфигурации
В рамках тестирования были зафиксированы ключевые показатели производительности системы при двух различных конфигурациях оперативной памяти: XMP-3200 и пониженной 1333 МГц. В частности, производительность, выраженная в количестве транзакций в секунду (TPS), составила 12492 для конфигурации XMP-3200 и 11876 для конфигурации 1333 МГц. Средняя задержка обработки запроса в первом случае равнялась 1,596 мс, тогда как во втором увеличивалась до 1,679 мс. Разница в TPS составила около 4,9%, а рост задержек — порядка 5,2%.
Для подтверждения статистической значимости этих различий применялись стандартные методы анализа, включая расчёт относительных изменений, доверительных интервалов и стандартного отклонения. Повторные измерения позволили получить репрезентативные выборки, на основе которых можно было провести t-тест Стьюдента. При уровне значимости 0,05 различия в производительности оказались статистически значимыми, что указывает на достоверное влияние изменения частоты оперативной памяти на производительность PostgreSQL.
Также наблюдалась тенденция увеличения времени выполнения ресурсоёмких SQL-запросов в условиях пониженной пропускной способности и возросших таймингов. Запросы с использованием оконных функций, агрегаций и генерации массивов данных с помощью generate\_series показали чувствительность к изменениям в латентности и пропускной способности памяти. В случае конфигурации 1333 МГц фиксировалось увеличение времени обработки сложных выборок, несмотря на то, что общая логика выполнения запросов оставалась неизменной.
Сопоставление с результатами других исследований показало, что полученные данные находятся в рамках существующих научных представлений о влиянии оперативной памяти на производительность СУБД. Так, исследования
, , демонстрируют, что при OLTP-нагрузке рост частоты ОЗУ приводит к увеличению производительности на 5-7%, что сопоставимо с данными настоящей работы. Аналогичные выводы сделаны в работе , , , где указано, что для PostgreSQL особенно критична пропускная способность при выполнении операций JOIN и агрегации.Однако стоит учитывать, что по сравнению с in-memory СУБД, таких как Redis или MemSQL, PostgreSQL в меньшей степени зависит от задержек доступа к памяти, поскольку использует собственные механизмы кэширования и оптимизации выполнения запросов. В связи с этим влияние латентности, обусловленной таймингами памяти, оказалось менее значимым, чем влияние частоты и пропускной способности.
Таким образом, статистическая обработка результатов и их сопоставление с данными других авторов позволяют заключить, что увеличение частоты оперативной памяти может дать ощутимый прирост производительности PostgreSQL, особенно в сценариях с интенсивной нагрузкой на память. Тем не менее, для систем со средней или низкой нагрузкой, разница между конфигурациями может оказаться недостаточно весомой для оправдания повышения затрат на более дорогую память. Такой подход обеспечивает обоснованность и объективность сделанных выводов, позволяя применять их в практике проектирования и модернизации серверов баз данных.
6. Заключение
Проведённое исследование позволило дать количественно обоснованную оценку влияния характеристик оперативной памяти DDR4 на производительность системы управления базами данных PostgreSQL. Полученные данные свидетельствуют о том, что тактовая частота памяти оказывает непосредственное влияние на основные метрики производительности СУБД, включая количество транзакций в секунду (TPS) и среднюю задержку выполнения запросов. При снижении частоты памяти с 3200 МГц до 1333 МГц наблюдалось уменьшение производительности на 4,9% и увеличение средней задержки на 5,2%, что статистически подтверждено многократными измерениями и анализом данных.
Тайминги памяти, выраженные в тактах, оказались менее критичными показателями при сравнении двух режимов, особенно с учётом пересчёта в наносекунды, где более высокочастотная память демонстрировала меньшие абсолютные значения задержек. Это позволяет утверждать, что в условиях PostgreSQL, активно использующей кэширование и внутреннюю оптимизацию выполнения запросов, решающее значение имеет именно пропускная способность оперативной памяти, а не её латентность.
Анализ SQL-запросов, включающих оконные функции, агрегации и операции соединения (JOIN), показал, что увеличение частоты памяти положительно сказывается на времени их выполнения, особенно при работе с большими объёмами данных. Таким образом, для OLTP-систем и аналитических платформ, ориентированных на интенсивную память-нагрузку, инвестиции в более высокочастотную память могут быть оправданы. В то же время для серверов с умеренной или предсказуемой нагрузкой разница может быть нивелирована за счёт настройки параметров PostgreSQL и системного кэширования.
Возможные направления дальнейших исследований:
1. Сравнение с другими поколениями памяти, включая DDR5, с целью выявления не только преимуществ по производительности, но и их энергоэффективности и экономической целесообразности в контексте современных СУБД.
2. Изучение зависимости между количеством каналов памяти (single vs. dual/quad channel) и производительностью PostgreSQL в многопользовательской среде.
3. Оценка влияния архитектурных особенностей процессора, включая размер кэшей L2/L3 и поддержку SMT (Simultaneous Multithreading), на чувствительность к частоте оперативной памяти при работе СУБД.
4. Разработка интеллектуальных систем автоматической настройки PostgreSQL, учитывающих текущую конфигурацию памяти и тип нагрузки, что позволит обеспечить оптимальную производительность без участия администратора.
5. Анализ поведения PostgreSQL в условиях ограниченного ресурса ОЗУ, включая сценарии с перегрузкой памяти, выходом за пределы shared\_buffers и интенсивным использованием swap, что особенно актуально для облачных решений и контейнеризованных сред.
Таким образом, данное исследование создаёт прочную основу для дальнейших эмпирических и теоретических разработок, направленных на оптимизацию аппаратных и программных компонентов серверных решений, использующих PostgreSQL в качестве основной СУБД.