1. Введение

С развитием информационных технологий всё более остро стоит проблема эффективной обработки больших объёмов данных. Современные системы управления базами данных (СУБД) всё чаще сталкиваются с необходимостью обеспечивать высокую скорость выполнения запросов при одновременном увеличении объёмов хранимой информации. Одним из ключевых факторов, влияющих на производительность таких систем, является аппаратная конфигурация вычислительной платформы, в особенности характеристики оперативной памяти.

Оперативная память типа Double Data Rate Synchronous Dynamic Random-Access Memory (DDR SDRAM [1], [2]) играет важную роль в обеспечении быстрого доступа к данным, используемым процессором. С развитием технологии появилось несколько поколений этой памяти, каждое из которых предлагает улучшенные параметры: тактовая частота, тайминги, пропускная способность. Однако вопрос о том, насколько значимо влияние этих параметров на реальную производительность СУБД при обработке запросов, остаётся открытым [3]. Более того, с экономической точки зрения не всегда очевидно, насколько целесообразно приобретение более дорогих модулей памяти с улучшенными характеристиками.

Целью данной работы является исследование влияния аппаратных характеристик оперативной памяти типа DDR4 на скорость выполнения SQL-запросов в системе управления базами данных PostgreSQL [4]. На основе экспериментальных данных предполагается оценить степень влияния таких параметров памяти, как частота, тайминги и пропускная способность, а также определить экономическую целесообразность перехода на более высокопроизводительные модули памяти.

Для достижения поставленной цели решаются следующие задачи:

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 является критически важной [5], [6].

В JEDEC входят сотни компаний, включая производителей полупроводников, разработчиков технологий и поставщиков оборудования (например, Samsung, Micron Technology, Intel, Advanced Micro Devices, NVIDIA, SK Hynix, Texas Instruments, Qualcomm).

Главной отличительной особенностью нового стандарта является одноименный принцип DDR (Double Data Rate), реализация которого основана на считывании данных не только по фронту, но и по срезу тактового сигнала. Таким образом, если тактовая частота DDR SDRAM составляет 100 МГц, эффективная частота передачи данных будет 200 МГц (рисунок 1).

Частота, тайминги и напряжение

—[7][8]

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

—

- сигнал выбора столбца матрицы ячеек памяти (англ. Column Address Strobe, CAS);

- сигнал выбора строки матрицы ячеек памяти (англ. Row Address Strobe, RAS).

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

Задержка строба адреса столбца (англ. CAS Delay, tCL)

—

Задержка между активацией строки и выбором столбца (англ. RAS to CAS Delay, tRCD)

—

Задержка между командой на подзарядку precharge до момента закрытия строки (англ. Row Precharge Time, tRP)

—

tRAS (Row Active Time) это время между активацией строки до срабатывания команды precharge.

Для простоты восприятия можно воспользоваться картой с рассчитанными значениями зависимости времени доступа к памяти в наносекундах от частоты работы и задержек CAS (рисунок 2).

3. Особенности работы PostgreSQL с оперативной памятью

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

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

В отличие от in-memory, СУБД PostgreSQL не хранит все данные в RAM по умолчанию, эти ограничения прописаны в конфигурационном файле, однако существуют множество механизмов для кэширования и оптимизации администрирования баз данных. Основными механизмами, которые взаимодействуют с оперативной памятью являются shared_buffers, work_mem и maintenance_work_mem.

- shared_buffers

—

- work_mem

—

- maintenance_work_mem

—

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

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

4. Конфигурация выбранного аппаратного обеспечения

Аппаратно-программная конфигурация (рисунок 4) представлена рядовыми компонентами для современных персональных компьютеров (см. таблицу 1).

[9][10]

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

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

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

В дальнейших исследованиях используются именно одноранговые модули по причине их дешевизны и распространённости (рисунок 6).

Стоит отметить, что все модули памяти характеризуются одинаковым объемом, составляющим 8 ГБ. Данное решение обусловлено тем, что применение модулей различного объема может стать причиной снижения производительности системы при заполнении модуля с меньшим объемом возникает переход в одноканальный режим работы, что негативно сказывается на скорости передачи данных и общем быстродействии системы.

——[11][12]

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

Значения пропускных способностей и задержек памяти в профиле XMP-3200 представлены на рисунке 7.

[13][14]

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

Команда «Тест быстродействия» в утилите WinRAR позволяет сравнивать производительность алгоритма сжатия RAR на разных компьютерах

[15][16]

Она генерирует случайные данные, вызывающие повышенную нагрузку на процессор и память. Затем данные сжимаются и распаковываются по алгоритму RAR, после чего результат распаковки сравнивается с исходными данными. Если обнаруживается какое-либо различие, в окне команды в строке «Ошибки» выводится сообщение «Да». Такие ошибки могут свидетельствовать о проблемах с аппаратурой, например о нестабильной работе памяти. Кроме того, отображается объём обработанных данных и скорость сжатия

—

С помощью параметра «Многопоточность» можно сравнить производительность обычной однопоточной и многопоточной (оптимизированной для мультипроцессорных архитектур) версий алгоритма сжатия RAR.

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

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

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

Далее была изменена частотная характеристика и тайминги модулей памяти (рисунок 8). Все изменения производились через унифицированный расширяемый интерфейс встроенного программного обеспечения (англ. Unified Extensible Firmware Interface, UEFI

[17][18]

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

Снижение таймингов в нашем случае не приведет к увеличению скорости доступа из-за некоторых особенностей. Хотя тайминги в конфигурации XMP-3200 выше в тактах, но в пересчёте в наносекунды они всё равно оказываются ниже из-за более высокой эффективной частоты памяти.

Для расчёта используем формулу [LATEX_FORMULA]$T=\frac{t}{f} \times 1000$[/LATEX_FORMULA].

Тайминги в наносекундах для 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.

5. Генерация базы данных и проведение измерений

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

[19][20]

Дальнейшая подготовка инфраструктуры требует обновления библиотек (рисунок 11).

Также было принято решение об использовании библиотеки asyncpg для работы с СУБД.

Asyncpg

—[21][22]

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 (попадания в кэш): оранжевая линия отражает количество блоков, найденных в кэше без обращения к диску.

Для генерации базы данных (рисунок 13) объёмом 4 ГБ написана программа на Python с применением библиотеки Faker, которая позволяет генерировать правдоподобные данные, для демонстрации наиболее репрезентативных результатов по итогам исследования.

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

Итоговый вариант базы данных объёмом 4 ГБ был записан на твердотельный накопитель Samsung SSD 980 EVO 500ГБ, чтобы обеспечить максимальную производительность, а также свести к минимуму недостатки дисковых СУБД.

Произведены измерения скорости последовательных и случайных чтений накопителя, где хранится база данных произведены в условиях его заполнения на 70%, что несколько снижает скорость доступа к памяти из-за заполнения Single Level Cell

[23][24]

pgbench

—

Для дальнейшего тестирования был написан 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).

—

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

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

Далее для сравнения конфигураций в условиях повышенной нагрузки был написан запрос с еще более сложной структурой, который представляет собой, как и CTE, так и объединение таблиц, агрегацию и генерацию данных.

Наиболее ресурсоёмким является использование функции generate_series (1, 100) в CTE temp_large_data, так как она приводит к увеличению числа строк в 100 раз относительно исходных данных в таблице products.

Помимо этого, использование оператора COUNT(DISTINCT ...) в нескольких CTE и в основном запросе приводит к подсчёту уникальных значений и созданию временных данных, таких как хэш-таблицы или деревья (рисунок 19).

В рамках тестирования были зафиксированы ключевые показатели производительности системы при двух различных конфигурациях оперативной памяти: XMP-3200 и пониженной 1333 МГц. В частности, производительность, выраженная в количестве транзакций в секунду (TPS), составила 12492 для конфигурации XMP-3200 и 11876 для конфигурации 1333 МГц. Средняя задержка обработки запроса в первом случае равнялась 1,596 мс, тогда как во втором увеличивалась до 1,679 мс. Разница в TPS составила около 4,9%, а рост задержек

—

Для подтверждения статистической значимости этих различий применялись стандартные методы анализа, включая расчёт относительных изменений, доверительных интервалов и стандартного отклонения. Повторные измерения позволили получить репрезентативные выборки, на основе которых можно было провести t-тест Стьюдента. При уровне значимости 0,05 различия в производительности оказались статистически значимыми, что указывает на достоверное влияние изменения частоты оперативной памяти на производительность PostgreSQL.

Также наблюдалась тенденция увеличения времени выполнения ресурсоёмких SQL-запросов в условиях пониженной пропускной способности и возросших таймингов. Запросы с использованием оконных функций, агрегаций и генерации массивов данных с помощью generate\_series показали чувствительность к изменениям в латентности и пропускной способности памяти. В случае конфигурации 1333 МГц фиксировалось увеличение времени обработки сложных выборок, несмотря на то, что общая логика выполнения запросов оставалась неизменной.

Сопоставление с результатами других исследований показало, что полученные данные находятся в рамках существующих научных представлений о влиянии оперативной памяти на производительность СУБД. Так, исследования

[25][26][27][28][29][30]

Однако стоит учитывать, что по сравнению с 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 в качестве основной СУБД.

The additional file for this article can be found as follows: