Ласкаво просимо назад! Якщо ви пропустили Частину 1, обов'язково перегляньте її тут. У першій частині ми досліджували архітектуру процесів PostgreSQL. Тепер ми зосередимося на архітектурі пам'яті. Для ясності, я ще раз надам зміст статті разом із візуальним представленням архітектури PostgreSQL.
1. Що таке PostgreSQL?
2. Основна архітектура PostgreSQL
3. Архітектура процесів PostgreSQL
3.1. Процес клієнта
3.2. Процес Postmaster
3.3. Процес Backend
3.4. Допоміжні процеси (Фонові або утилітарні)
3.5. Інші процеси
4.Архітектура пам'яті PostgreSQL
4.1. Локальна пам'ять
4.2. Спільна пам'ять
5. Фізичні файли PostgreSQL
5.1. Файли даних
5.2. WAL файли
5.3. Файли архіву WAL
5.4. Конфігураційні файли
5.5. Лог-файли
Ось візуальне представлення, яке зображує архітектуру PostgreSQL, включаючи області пам'яті, процеси та фізичні файли бази даних.
4. Архітектура пам'яті PostgreSQL
Архітектура пам'яті PostgreSQL може бути розділена на дві основні області: локальна пам'ять та спільна пам'ять. Кожна з цих областей має свої специфічні функції і грає важливу роль у забезпеченні ефективної роботи системи бази даних.
4.1. Локальна пам'ять
У PostgreSQL локальна пам'ять позначає пам'ять, виділену для окремих з'єднань або сесій бази даних. Кожне підключення клієнта до бази даних отримує свою власну приватну область пам'яті в межах локальної пам'яті. Локальна пам'ять є важливою для керування ресурсами і даними, що належать кожному з'єднанню клієнта. Вона дозволяє кільком сесіям працювати незалежно одна від одної, не заважаючи даним або операціям інших сесій. Коли клієнт відключається від бази даних, локальна пам'ять, виділена для цього з'єднання, звільняється і стає доступною для інших з'єднань.
Іншими словами, немає попередньо виділеної пам'яті для кожного з'єднання, яку адміністратор бази даних (DBA) міг би визначити. Замість цього виділення пам'яті є динамічним і залежить від типу використання. Кожна сесія динамічно виділяє необхідну пам'ять або використовує спільну пам'ять, виділену під час запуску сервера, залежно від її специфічних вимог.
Область локальної пам'яті розділена на кілька підобластей, розміри яких можуть бути фіксованими або змінними. Основні підобласті — це пам'ять для роботи, пам'ять для обслуговування, пам'ять для автоматичної очистки (autovacuum) та тимчасові буфери.
Тепер давайте розглянемо пояснення для кожної з цих підобластей.
Пам'ять для роботи
Пам'ять, що виділяється для операцій сортування та хеш-таблиць у запитах PostgreSQL, називається пам'яттю для роботи (або пам'ять для запитів). Операції сортування, такі як ORDER BY, DISTINCT або злиття за допомогою об'єднання (merge joins), а також хеш-таблиці, що використовуються у хеш-з'єднаннях, агрегаціях за допомогою хешування або обробці підзапитів IN, покладаються на цю пам'ять. Параметр workmem_ контролює кількість пам'яті, що виділяється для цих операцій у запитах до того, як дані будуть записані у тимчасові файли на диску. Якщо значення вказано без одиниць вимірювання, воно інтерпретується як кілобайти. За замовчуванням значення workmem_ становить 4 МБ, і воно може бути налаштоване як на рівні системи, так і на рівні сесії.
Термін "пам'ять для роботи" часто неправильно розуміють як єдину виділену пам'ять, яка охоплює всю роботу, що виконується PostgreSQL під час виконання запиту. Однак це неправильне уявлення. Насправді складний запит може включати кілька операцій сортування або хеш-таблиць, кожна з яких потребує окремого виділення пам'яті. Параметр workmem_ визначає розмір цих часток пам'яті, і для кожної операції створюється окреме виділення в межах з'єднання користувача.
Наприклад, якщо workmem встановлено на 32 МБ і запит включає 8 операцій сортування/хешування/ORDER BY/GROUP BY/DISTINCT, то загальне використання пам'яті для цього запиту становитиме приблизно 256 МБ (32*8).
Операції на основі хешування зазвичай більш чутливі до доступної пам'яті, ніж еквівалентні операції сортування. Пам'ять, доступна для хеш-таблиць, обчислюється шляхом множення workmem на hashmemmultiplier. Це дає змогу операціям на основі хешування використовувати кількість пам'яті, що перевищує звичайну базову кількість workmem.
Важливо уникати встановлення занадто великого значення для workmem, оскільки це може спожити значну частину доступної пам'яті, потенційно позбавляючи операційну систему необхідної RAM для інших процесів. Параметр maxconnections_ також впливає на використання пам'яті, оскільки він визначає кількість одночасно виконуваних сесій. Крім того, слід враховувати, що кожне неактивне з'єднання споживає приблизно 2–3 МБ спільної пам'яті. Збільшення значення max_connections дозволяє мати більше одночасних з'єднань, але це призводить до більшого використання пам'яті.
Нарешті, окрім пам'яті для роботи з запитами, PostgreSQL виділяє додаткову пам'ять для підтримки кешу системного каталогу та підготовлених планів запитів.
Пам'ять для обслуговування
Для операцій обслуговування, які виконуються користувачами або явно запланованими задачами, виділяється максимальна кількість оперативної пам'яті. Ці операції можуть включати VACUUM, CREATE INDEX або ALTER TABLE ADD FOREIGN KEY. Виділення пам'яті контролюється параметром, відомим як maintenanceworkmem. Якщо значення цього параметра вказано без одиниць вимірювання, воно вважається в кілобайтах. Значення за замовчуванням встановлено на 64 МБ, і його можна налаштувати як на рівні системи, так і на рівні сесії.
Оскільки сесія бази даних може виконувати тільки одну операцію обслуговування за раз, а одночасні операції, як правило, обмежені, зазвичай безпечно встановлювати maintenanceworkmem на значно більше значення, ніж workmem. Великі налаштування можуть покращити продуктивність вакуумування та відновлення дампів бази даних, оскільки ці операції з обслуговування можуть бути вимогливими до пам'яті та виконуватимуться швидше, коли працюють повністю в RAM. Зазвичай це значення встановлюється на рівні 1 ГБ або навіть 2 ГБ.
Варто зазначити, що коли працює автоприбиральник (autovacuum), він може виділяти пам'ять до _autovacuummaxworkers разів більше, ніж значення maintenanceworkmem. Тому не рекомендується встановлювати значення за замовчуванням занадто високим, щоб уникнути надмірного використання пам'яті. Для контролю цього можна окремо налаштувати autovacuumworkmem.
Маючи окремі параметри, такі як maintenanceworkmem і autovacuumworkmem_, PostgreSQL дозволяє контролювати виділення пам'яті для ручних операцій обслуговування та операцій автоприбиральника незалежно. Це дає змогу оптимізувати використання пам'яті залежно від конкретних потреб кожного типу операції.
Пам'ять для роботи автоприбиральника (AND Буфери вакууму)
Перед тим, як зануритись у концепції пам'яті для роботи автоприбиральника та буферів вакууму, варто зазначити, що деякі розділи документації PostgreSQL можуть бути не зовсім зрозумілими, що ускладнює адміністратору, включаючи мене, повне розуміння загального процесу. Крім того, важливо підкреслити, що буфери вакууму не слід вважати підобластю локальної пам'яті. Для того, щоб зрозуміти повний процес і його зв'язок з пам'яттю для роботи автоприбиральника, я надам детальне пояснення тут.
Почнемо з пам'яті для роботи автоприбиральника:
Пам'ять для роботи автоприбиральника позначає максимальну кількість пам'яті, яку використовує кожен процес робітника автоприбиральника. Вона контролюється параметром бази даних autovacuumworkmem. Якщо одиниці вимірювання не вказано, значення вважається в кілобайтах. За замовчуванням значення встановлено на -1, що означає, що слід використовувати значення maintenanceworkmem.
Налаштування autovacuumworkmem повинно бути обережно налаштоване, оскільки значення autovacuummaxworkers визначає кількість пам'яті, яка буде виділена з оперативної пам'яті для кожного процесу робітника автоприбиральника. Ці параметри набирають чинності лише тоді, коли активовано демон автоприбиральника (autovacuum); в іншому випадку вони не впливають на поведінку VACUUM в інших контекстах. Потрібно підкреслити, що ця частина пам'яті не є спільною для будь-якого іншого фоново-сервісного або користувацького процесу. Що стосується збору ідентифікаторів мертвих кортежів, автоприбиральник може використовувати максимум 1 ГБ пам'яті. Тому встановлення autovacuumworkmem на значення більше цього не вплине на кількість мертвих кортежів, які автоприбиральник може зібрати під час сканування таблиці.
Тепер давайте обговоримо буфери вакууму:
Буфери вакууму — це буфери, виділені з sharedbuffers, спеціально для операцій VACUUM та ANALYZE. Розмір _Buffer Access Strategy, що використовується командами VACUUM та ANALYZE, визначається параметром vacuumbufferusagelimit_ (версія 16). Встановлення цього значення на 0 дозволяє операціям використовувати будь-яку кількість sharedbuffers. Дійсні розміри варіюються від 128 кБ до 16 ГБ. Якщо вказаний розмір перевищує 1/8 розміру sharedbuffers, то значення автоматично обмежується цим розміром. За замовчуванням значення встановлено на 256 кБ, що є достатньо малим для того, щоб вміститися в кеш L2, сприяючи ефективному переносу сторінок з кешу операційної системи в кеш спільних буферів. Якщо одиниці вимірювання не вказано, то значення вважається в кілобайтах. Цей параметр можна налаштувати в будь-який час, і його можна перекрити для операцій VACUUM та ANALYZE, використовуючи опцію BUFFERUSAGELIMIT. Вищі значення можуть дозволити VACUUM та ANALYZE виконуватися швидше, але занадто велике значення може призвести до витіснення занадто багатьох інших корисних сторінок із спільних буферів.
Примітки щодо стратегії доступу до буферів:
У вихідному коді PostgreSQL термін "Buffer Access Strategy" використовується як синонім до "Buffer Ring Replacement Strategy". Обидва терміни відносяться до однієї й тієї ж концепції.
Стратегія доступу до буферів запобігає надмірному витісненню сторінок зі спільних буферів під час операцій, що потребують доступу до великої кількості сторінок. Без стратегії доступу до буферів, якщо бекенд-процес зчитує велику таблицю, це може призвести до витіснення всіх збережених сторінок із спільних буферів, що знижує коефіцієнт попадання в кеш. Для вирішення цієї проблеми стратегія доступу до буферів надає тимчасову буферну область спеціально для великої таблиці. Ця виділена буферна область звільняється негайно після використання.
Стратегія доступу до буферів налаштовує посилання на обмежену кількість спільних буферів і повторно використовує їх за круговим принципом (кільцевий буфер ). Коли операція потребує нової сторінки, з буферів стратегії кільця вибирається буфер-жертва. Цей вибір може включати очищення брудних даних сторінки та, можливо, незаписаних журналів Write-Ahead Log (WAL) на постійне сховище.
Стратегії доступу до буферів використовуються в різних операціях, включаючи послідовні сканування великих таблиць, VACUUM, COPY, CREATE TABLE AS SELECT, ALTER TABLE, CREATE DATABASE, CREATE INDEX і CLUSTER. Ці стратегії допомагають оптимізувати управління буферами та покращують загальну продуктивність цих операцій.
Підсумовуючи, Буфери вакууму використовуються в кеші спільних буферів для тимчасового зберігання змінених сторінок даних. Натомість Пам'ять для роботи автоприбиральника визначає максимальну пам'ять, виділену для кожного процесу робітника автоприбиральника під час операцій автоприбиральника, служачи внутрішньою пам'яттю роботи. Іншими словами, ці виділення пам'яті служать різним цілям: буфери вакууму обробляють зміни сторінок даних, а пам'ять для роботи автоприбиральника управляє внутрішньою пам'яттю для процесів автоприбиральника.
Тимчасові буфери
База даних може мати одну або кілька тимчасових таблиць, для яких потрібне окреме виділення пам'яті для обробки їхніх даних (сторінок).
Тимчасові буфери виконують цю задачу, використовуючи частину оперативної пам'яті, яка визначається параметром tempbuffers. Цей параметр вказує максимальний обсяг пам'яті, виділений для тимчасових буферів в межах кожної сесії бази даних, і ці буфери будуть очищені при закритті з'єднання. Ці буфери є специфічними для сесії та використовуються виключно для доступу до тимчасових таблиць. Якщо значення вказано без одиниць вимірювання, воно розглядається в блоках, зазвичай 8 кБ (BLCKSZ байт). За замовчуванням значення складає 8 МБ. Це налаштування можна змінювати в межах окремих сесій, але тільки до першого використання тимчасових таблиць у цій сесії. Будь-які подальші спроби змінити значення не впливатимуть на сесію.
Слід зазначити, що немає прямого зв'язку між тимчасовими буферами в пам'яті та тимчасовими файлами, які створюються в директорії pgsqltmp під час великих операцій сортування та хеш-таблиць.
4.2. Спільна пам'ять
Окрім локальної пам'яті, сервер PostgreSQL виділяє область shared memory (спільної пам'яті) з оперативної пам'яті при запуску. Ця область спільної пам'яті дублює частини файлів бази даних, забезпечує тимчасову область для записів Write-Ahead Log (WAL) і зберігає додаткову загальну інформацію. Важливо пам'ятати, що спільна пам'ять пов'язана з усім екземпляром PostgreSQL, а не з окремою базою даних.
За замовчуванням PostgreSQL виділяє дуже малу кількість системної пам'яті типу V, а також значно більшу кількість анонімної спільної пам'яті mmap. При використанні семафорів системи V PostgreSQL використовує один семафор для кожного дозволеного з'єднання (maxconnections), дозволеного процесу робітника автоприбиральника (autovacuummaxworkers) та дозволеного фоново процесу (maxworkerprocesses).
Найбільшим компонентом спільної пам'яті є _shared buffers (спільні буфери), які використовуються для дублювання частин даних файлів, організованих у сторінки. Коли сторінка змінюється, вона вважається "брудною" (dirty page), поки не буде записана назад у файлову систему.
Як і в локальній пам'яті, область спільної пам'яті також розподіляється на підобласті фіксованого розміру, кожна з яких виконує певну роль. Основні підобласті включають shared buffers (спільні буфери), WAL буфери, CLOG буфери та lock space (простір для блокувань).
Спільні буфери
Це спільна пам'ять, виділена PostgreSQL для доступу до даних для читання або запису. Коли дані запитуються, вони спочатку зчитуються з диска в shared buffers (спільні буфери) для кешування, а потім передаються клієнту. Той самий процес застосовується для операцій запису. Виняток становлять тимчасові таблиці, де дані доступні в просторі tempbuffer_ настільки, наскільки це можливо, оскільки лише створюючий бекенд може посилатися на тимчасову таблицю. Доступ до локальної пам'яті процесу, як це, є швидшим, оскільки не потрібно турбуватися про фіксацію або блокування даних, оскільки вони не є спільними.
До спільних буферів мають доступ всі фонові сервери та користувацькі процеси, які підключаються до бази даних для таких діяльностей, як кешування даних, кешування з'єднань та операції з маніпуляцією даними (Data Manipulation Language, DML). Дані, записані або змінені в цьому місці, називаються "брудними даними" (dirty data), а одиницею операції є блоки бази даних або сторінки, які також називаються "брудними блоками" (dirty blocks) або "брудними сторінками" (dirty pages).
Кількість оперативної пам'яті, необхідної для спільних буферів, завжди заблокована для екземпляра PostgreSQL на весь його життєвий цикл. На відміну від інших баз даних, PostgreSQL не надає прямого I/O.
Спільні буфери контролюються параметром sharedbuffers, який встановлює кількість пам'яті, що використовується сервером бази даних для спільних буферів пам'яті. За замовчуванням це значення становить зазвичай 128 МБ, але може бути меншим, якщо налаштування вашого ядра не підтримують цього (як визначено під час _initdb). Це налаштування повинно бути не менше 128 кБ. Однак для оптимальної продуктивності зазвичай потрібні значення, що перевищують мінімум. Якщо значення вказано без одиниць вимірювання, воно вважається в блоках, зазвичай 8 кБ (BLCKSZ байт).
Цей параметр можна встановити лише під час запуску сервера.
Для виділеного сервера бази даних з 1 ГБ або більше оперативної пам'яті розумним початковим значенням для sharedbuffers є 25% від загальної пам'яті системи. Для деяких навантажень більші налаштування для sharedbuffers можуть бути ефективними, але оскільки PostgreSQL також залежить від кешу операційної системи, виділення більше ніж 40% оперативної пам'яті для sharedbuffers, ймовірно, не дасть кращих результатів, ніж менша кількість. Більші налаштування sharedbuffers зазвичай вимагають відповідного збільшення maxwalsize для рівномірного розподілу процесу запису великої кількості нових або змінених даних на більший період часу. На системах з менше ніж 1 ГБ оперативної пам'яті підходить менший відсоток пам'яті, щоб залишити достатньо місця для операційної системи.
WAL Buffers
У PostgreSQL буфер Write-Ahead Log (WAL) є компонентом спільної пам'яті бази даних, який призначений для тимчасового зберігання записів WAL перед їх записом на диск. Буфер WAL діє як проміжна зона для записів WAL, які генеруються під час операцій запису в базу даних, таких як INSERT, UPDATE і DELETE. Коли транзакція змінює дані в PostgreSQL, вона спочатку записує відповідні записи WAL у буфер WAL в пам'яті. Ці записи фіксують зміни, зроблені транзакцією, у форматі журналу.
Процес запису WAL у PostgreSQL відповідає за запис записів WAL з буфера WAL на диск. Ці записи зберігаються в файлах, які називаються WAL files, WAL segments, або WAL segment files.
Основною метою буфера WAL є забезпечення довговічності та відновлення після аварій. Записи WAL у буфері, які не були скинуті до файлів WAL під час аварії, вважаються "нескинутими" або "брудними" (dirty) записами WAL. Ці несмивні записи мають важливе значення для відновлення, оскільки вони містять найсвіжіші зміни, внесені до бази даних.
Під час процесу відновлення PostgreSQL зчитує як несмивні записи WAL з буфера, так і записи WAL, збережені в файлах WAL на диску. Він використовує цю комбінацію записів для відновлення стану бази даних на момент аварії. Застосовуючи записи WAL, PostgreSQL може відновити базу даних до консистентного та транзакційно правильного стану.
Розподіл пам'яті для буферів WAL у PostgreSQL контролюється параметром walbuffers, який визначає кількість пам'яті, виділеної з оперативної пам'яті. Хоча ця область пам'яті доступна для всіх фонових серверів і користувацьких процесів, вона відрізняється від спільних буферів. Буфери WAL існують окремо від спільних буферів і за розміром є відносно меншими порівняно з ними.
Параметр _walbuffers_ має значення за замовчуванням -1, що вибирає розмір, рівний 1/32 частини (близько 3%) від sharedbuffers. Це гарантує, що розмір не буде меншим за 64 кБ і не перевищить розмір одного сегмента WAL, зазвичай 16 МБ. Якщо автоматично обраний розмір занадто великий або занадто малий, це значення можна вручну встановити. Однак будь-яке позитивне значення, менше ніж 32 кБ, буде розглядатися як 32 кБ. Якщо значення вказано без одиниць вимірювання, воно розглядається як блоки WAL, зазвичай 8 кБ (XLOGBLCKSZ байт). Цей параметр можна встановити лише під час запуску сервера.
Зміст буферів WAL записується на диск при кожному коміті транзакції, тому дуже великі значення, ймовірно, не принесуть значної користі. Однак встановлення цього значення хоча б на кілька мегабайт може покращити продуктивність запису на сервері з великою кількістю клієнтів, що одночасно здійснюють коміти. У більшості випадків автоматичне налаштування, вибране значенням -1, повинно дати розумні результати.
CLOG Buffers
PostgreSQL зберігає статуси транзакцій у Commit Log, також відомому як CLOG. CLOG buffers (буфери CLOG) — це буфери пам'яті, які використовуються для тимчасового зберігання даних CLOG перед їх записом на диск. CLOG відіграє важливу роль у обробці транзакцій, оскільки містить статуси комітів всіх транзакцій, вказуючи, чи була транзакція завершена (завершена комітом).
Не існує конкретного параметра для контролю за виділенням пам'яті для буферів CLOG. Двигун бази даних автоматично керує цією областю за допомогою невеликих виділень пам'яті. Буфери CLOG є компонентом спільної пам'яті, доступним для всіх фонових серверів і користувацьких процесів у базі даних PostgreSQL.
Під час вимикання PostgreSQL або коли виконується процес контрольної точки (checkpoint), дані з буферів CLOG записуються у файли, що зберігаються в підкаталозі pgxact (або pgclog у версіях 9.6 або раніше). Ці файли CLOG мають імена «0000», «0001» і так далі. Кожен файл має максимальний розмір 256 КБ. Наприклад, якщо CLOG використовує вісім сторінок (загальний розмір 64 КБ), його дані будуть записані в файл «0000» (64 КБ). Якщо CLOG потребує 37 сторінок (296 КБ), його дані будуть записані в файли «0000» і «0001», з розмірами 256 КБ і 40 КБ відповідно.
Під час запуску PostgreSQL дані, що зберігаються у файлах pg_xact, завантажуються для ініціалізації буферів CLOG. Розмір файлів CLOG постійно збільшується, оскільки нові сторінки додаються, коли існуючий простір заповнюється. Однак не всі дані в CLOG є необхідними. Регулярно процес vacuum (очищення) видаляє старі дані, включаючи як сторінки CLOG, так і самі файли.
Lock Space (пам'ять для блокувань)
Lock space (простір для блокувань) відноситься до області спільної пам'яті, що використовується для керування і відстеження блокувань, які є критично важливими для підтримання цілісності даних у багатокористувацькому середовищі, де одночасно можуть бути доступні та змінюватися однакові дані різними транзакціями.
У PostgreSQL lock space відповідає за зберігання інформації про різні типи блокувань, такі як блокування на рівні рядків, блокування на рівні таблиць і блокування на рівні транзакцій. Коли транзакція запитує блокування ресурсу, менеджер блокувань перевіряє lock space, щоб визначити, чи не конфліктує запитане блокування з будь-якими існуючими блокуваннями, що утримуються іншими транзакціями. Ці блокування є спільними для всіх фоновых серверів і користувацьких процесів, підключених до бази даних.
PostgreSQL керує lock space динамічно, виділяючи та звільняючи пам'ять за потребою, щоб задовольнити змінювані вимоги блокувань активних транзакцій. Lock space є важливою частиною механізму керування паралельністю PostgreSQL, що забезпечує безпечний та консистентний доступ до спільних даних у багатокористувацькому середовищі.
Два параметри бази даних, а саме maxlockspertransaction_ і maxpredlockspertransaction, впливають на розмір цього компоненту пам'яті. Загальна кількість блокувань і предикатних блокувань у системі обмежена добутком значень цих параметрів: maxpredlockspertransaction × maxconnections_ та maxlockspertransaction × maxconnections відповідно. Пам'ять для цих блокувань виділяється при запуску сервера, і спроба перевищити цей ліміт призведе до помилки. Вид вікна pg_locks надає доступ до інформації про блокування, утримувані активними процесами в межах сервера бази даних.
5. Фізичні файли PostgreSQL
Щоб забезпечити всебічне розуміння архітектури PostgreSQL, я коротко розповім про фізичні файли, що беруть участь.
Ось основні фізичні файли, які використовуються в PostgreSQL:
5.1. Файли даних
Файли даних зберігають фактичні дані таблиць бази даних, індексів та інших об'єктів бази даних. Кожна таблиця та індекс у базі даних, як правило, має свій відповідний файл даних. Коли користувач запитує дані, PostgreSQL шукає їх у спільному буфері, і якщо їх там немає, він завантажує дані з файлів даних до спільного буфера та обробляє їх далі.
5.2. Файли WAL
Файли WAL (Write-Ahead Log) є послідовними записами всіх змін, внесених до бази даних. Вони слугують журналом транзакцій, фіксуючи модифікації, такі як вставки, оновлення та видалення. Файли WAL забезпечують довговічність, гарантуючи, що зміни записуються перед їх застосуванням до самих даних бази. Вони також забезпечують відновлення після аварій та реплікацію, дозволяючи відновити базу даних до консистентного стану або реплікувати її на інші інстанси за допомогою записів журналу.
Файли WAL є критично важливими для цілісності даних, відмовостійкості та високої доступності в PostgreSQL.
5.3. Архівні файли WAL
Архівні файли WAL у PostgreSQL є копіями файлів WAL. Коли база даних налаштована для використання архівації WAL, копія кожного заповненого файлу WAL створюється та зберігається в окремому місці поза директорією даних бази даних. Це додає додатковий рівень захисту від втрати даних і дає можливість відновлення на певний момент часу.
5.4. Конфігураційні файли
Конфігураційні файли PostgreSQL — це текстові файли, що містять налаштування та параметри для конфігурації поведінки сервера бази даних. Основні файли — це postgresql.conf (налаштування сервера), postgresql.auto.conf (автоматичні налаштування сервера), pghba.conf (автентифікація клієнтів) і pgident.conf (відображення користувачів). Ці файли контролюють такі аспекти, як продуктивність, безпека та автентифікація, дозволяючи адміністраторам налаштовувати та оптимізувати роботу сервера бази даних.
5.5. Лог-файли
Лог-файли — це записи подій та повідомлень, які фіксують важливу інформацію про роботу системи бази даних. Вони слугують діагностичним інструментом для адміністраторів і розробників для усунення проблем, моніторингу продуктивності та аналізу активності бази даних. Лог-файли надають інформацію про помилки, попередження, запити та інші відповідні події, допомагаючи адміністраторам ідентифікувати та вирішувати проблеми з конфігурацією, продуктивністю та безпекою. Адміністратори можуть налаштовувати детальність логування, місце збереження та формат для задоволення своїх потреб. Лог-файли відіграють критичну роль у розумінні здоров’я бази даних, оптимізації продуктивності та ефективному підтриманні системи.
Висновок
У цій статті ми детально розглянули процеси та архітектуру пам'яті PostgreSQL. Керування пам'яттю відіграє важливу роль в оптимізації продуктивності бази даних PostgreSQL. Завдяки належному налаштуванню параметрів виділення пам'яті, PostgreSQL може більш ефективно читати та записувати дані, що сприяє швидшому виконанню запитів. Важливо ретельно оцінювати навантаження та конфігурацію системи при внесенні змін до цих параметрів.
Спрощуючи інформацію з різних джерел документації, я прагнув прояснити ці концепції. Ми розглянули основи PostgreSQL, його процесну архітектуру та розподіл пам'яті, а також візуальне уявлення для покращення розуміння його компонентів і фізичних файлів. Дякую за читання, сподіваюся, цей посібник стане корисним ресурсом у вашій подорожі з PostgreSQL.
Бонус: Загальні питання та відповіді
-
Як PostgreSQL використовує пам'ять для операцій читання?
Коли клієнт здійснює запит на читання, PostgreSQL спочатку перевіряє, чи є запитувані дані вже в кеші буфера (shared_buffers). Якщо дані не знайдені там, система перевіряє кеш операційної системи. Якщо дані все ще недоступні, PostgreSQL зчитує їх з диска і зберігає в кеші буфера.
Для керування кешем буфера PostgreSQL використовує алгоритм «найменш нещодавно використовуваних» (LRU), щоб визначити, які буфери потрібно вивести, коли потрібно звільнити місце для нових даних. Це означає, що буфер, який не використовувався найдовше, буде видалений першим. Однак PostgreSQL прагне уникнути видалення буферів, які, ймовірно, будуть використані знову найближчим часом. -
Як PostgreSQL використовує пам'ять для операцій запису?
Коли виконується операція запису, PostgreSQL спочатку зберігає дані в буферах WAL для підтримання консистентності та довговічності даних. Після того, як транзакція зафіксована або буфери WAL досягають максимального обсягу, PostgreSQL надсилає сигнал fsync для збереження змін у директорії pgxlog/pgwal. WAL діє як послідовний журнал всіх змін, внесених у базу даних, що забезпечує консистентність і довговічність.
Після запису змін у WAL, PostgreSQL оновлює відповідні сторінки даних у пам'яті (shared_buffers).
Ці зміни не записуються безпосередньо на диск, а зберігаються в пам'яті деякий час, що називається «кешуванням за записом» (write-behind caching) або «ледачим записом» (lazy write).
PostgreSQL використовує «контрольні точки» (checkpoints), щоб періодично записувати брудні дані з пам'яті на диск. Під час контрольної точки PostgreSQL записує всі брудні дані на диск і оновлює WAL, щоб відобразити ці зміни, забезпечуючи збереження даних навіть у разі збою системи. -
Як виконати запити з кількома базами даних у PostgreSQL?
Хоча ви не можете безпосередньо запитувати базу даних, відмінну від тієї, що зараз використовується, існує кілька підходів, які допомагають подолати це обмеження, як описано нижче.
Підтримка SQL/MED в PostgreSQL дозволяє створювати «обгортку для зовнішніх даних» (foreign data wrapper), яка зв'язує таблиці з віддаленої бази даних з локальною базою даних. Ця віддалена база даних може перебувати на тій самій інстанції PostgreSQL або знаходитися в будь-якому іншому місці світу. Функція postgresfdw, доступна з PostgreSQL 9.3, підтримує як читання, так і запис даних.
Інший варіант — це розширення _dblink, яке дозволяє виконувати запити між базами даних через виклики функцій і сумісне з більш старими версіями PostgreSQL. Однак на відміну від postgresfdw, _dblink не може «переносити» умови на віддалений сервер, що може призвести до отримання більше даних, ніж необхідно.
Крім того, клієнт може встановити одночасні з'єднання з кількома базами даних і об'єднати результати на стороні клієнта.
Я був би радий почути ваші думки в коментарях нижче! Не соромтеся поділитися своїм відгуком!
Перекладено з: Process and Memory Architecture of PostgreSQL — Part 2