PostgreSQL на VPS: как да оразмерите паметта и диска

Започнете от полезния обем

Паметта на един сървър за бази данни служи преди всичко за кеш: страница, прочетена от паметта, се обслужва много по-бързо от страница, прочетена от диска, дори NVMe. Затова въпросът не е само „колко тежи базата?“, а „каква част от нея се чете често?“. База от 50 GB, в която се търсят само последните дванадесет месеца, може би работи с 8 GB.

За съществуваща база две заявки дават общия обем и най-големите таблици, с индексите им:

SELECT pg_size_pretty(pg_database_size(current_database()));

SELECT relname AS tablitsa,
       pg_size_pretty(pg_total_relation_size(relid)) AS razmer_s_indeksi
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 10;

За бъдеща база направете оценка таблица по таблица: очакван брой редове след една година × среден размер на един ред, след това добавете индексите, които обикновено тежат от 30 до 100 % от данните. Пример: 2 милиона реда на месец, по 500 байта всеки, правят 12 GB данни след една година и 18 до 24 GB с индексите.

Паметта: началните настройки

PostgreSQL пази прочетените страници на две нива: собствения си кеш (shared_buffers) и файловия кеш на системата. Документацията му препоръчва да се започне от 25 % от паметта за shared_buffers на посветен сървър и отбелязва, че над 40 % ползата рядко нараства: останалото е от полза за кеша на системата и за сортиранията.

Тези стойности предполагат база, която е сама на сървъра. Ако приложението работи до нея, извадете първо неговата памет (процеси, кеш, компилиране) и приложете процентите към остатъка: сървър с 8 GB, на който работи приложение с 3 GB, се настройва като база с 5 GB.

shared_buffers = 2GB
effective_cache_size = 6GB
work_mem = 16MB
maintenance_work_mem = 512MB
random_page_cost = 1.1

shared_buffers влиза в сила едва след рестартиране на PostgreSQL; останалите параметри се презареждат без прекъсване с SELECT pg_reload_conf();.

За да разберете дали паметта стига, прочетете дела на четенията от кеша. При бизнес приложение или сайт той надхвърля 99 %:

SELECT round(100.0 * blks_hit / nullif(blks_hit + blks_read, 0), 2) AS dyal_ot_kesha
FROM pg_stat_database
WHERE datname = current_database();

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

PostgreSQL отваря по един процес на връзка и приема 100 по подразбиране (max_connections). Всеки процес заема няколко мегабайта в покой, повече, когато сортира или хешира данни (work_mem, понякога по няколко пъти в една и съща заявка). Да вдигнете max_connections на 500, за да следвате едно „бъбриво“ приложение, означава да изложите сървъра на риск да остане без памет при първия пик.

Правилният отговор е инструмент за споделяне на връзки (connection pooler): PgBouncer в режим transaction кара стотици връзки на приложението да делят няколко десетки реални връзки. Фреймуърците също имат собствен пул (SQLAlchemy, Prisma, HikariCP): настройте размера му според броя vCPU на сървъра на базата, а не според броя на потребителите.

Дискът: обем, резерв и журнал

Дискът на един PostgreSQL сървър носи повече от таблиците:

• Данните и индексите и техният растеж за една година.
• Журналът на транзакциите (WAL): 1 GB по подразбиране между две контролни точки (max_wal_size), повече при масов импорт и още повече, ако архивирането на журнала изостава.
• Временните файлове на сортиранията, които надхвърлят work_mem.
• Мястото за реорганизация: VACUUM FULL и повторното изграждане на индекс записват пълно копие, преди да освободят старото.
• Локалните експорти, ако пазите резервни копия на сървъра, преди да ги изпратите другаде.

Правилото: обемът след една година, плюс поне 30 % резерв. Това не е въпрос на удобство: когато дискът, на който е журналът на транзакциите, се запълни, PostgreSQL спира, за да защити данните си. Следете заетостта и разширявайте преди 80 %.

Що се отнася до производителността, всяко потвърждаване на транзакция чака записа на журнала на диска: латентността на хранилището определя скоростта на запис. Именно тук NVMe SSD прави разликата, много повече, отколкото при четенията, които паметта вече обслужва.

Процесорът: една заявка, едно ядро

Една PostgreSQL заявка се изпълнява на едно ядро, с изключение на големите четения, които двигателят паралелизира. Затова броят на vCPU определя броя на тежките заявки, обработвани едновременно: 2 vCPU стигат на бизнес приложение при старта, 4 до 8 са подходящи за силно натоварени бази и тежки отчети.

Преди да добавите vCPU, намерете заявките, които ги консумират. Разширението pg_stat_statements ги подрежда по общо време:

shared_preload_libraries = 'pg_stat_statements'

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

SELECT calls, round(total_exec_time) AS ms_obshto,
       round(mean_exec_time::numeric, 1) AS ms_sredno, query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

На същия сървър като приложението или на отделен сървър?

При старта базата на същия сървър като приложението е правилният избор: никаква мрежова латентност между двете, връзка през Unix сокет, един сървър за архивиране и наблюдение. Разделят се, когато двете си оспорват ресурсите: компилиране или пик на трафика, които изпразват кеша на базата, база, която се нуждае от цялата памет за данните си, или различни изисквания за резервните копия.

Сигурност и резервни копия

• Локално слушане: listen_addresses = 'localhost', докато само приложението на сървъра се свързва с базата. Ако друг сървър трябва да има достъп, отворете порт 5432 само за неговия адрес, в защитната стена и в pg_hba.conf.
• Удостоверяване: метод scram-sha-256 в pg_hba.conf, по една роля на приложение, без права на суперпотребител.
• Ежедневно логическо резервно копие с pg_dump, копирано извън сървъра.
• Възстановяване към точен момент: непрекъснатото архивиране на журнала (pgBackRest, WAL-G) позволява връщане с точност до минута преди грешката, докато ежедневният експорт връща към предишния ден.
• Тествано възстановяване: резервното копие се доказва, като се възстанови в тестова база на редовни интервали.

pg_dump -Fc -d moyata_baza -f moyata_baza-$(date +%F).dump
createdb moyata_baza_test
pg_restore -d moyata_baza_test moyata_baza-2026-10-29.dump