PostgreSQL σε VPS: διαστασιολόγηση μνήμης και δίσκου

Ξεκινήστε από τον ωφέλιμο όγκο

Η μνήμη ενός διακομιστή βάσης δεδομένων χρησιμεύει πρώτα ως cache: μια σελίδα που διαβάζεται από τη μνήμη εξυπηρετείται πολύ πιο γρήγορα από μια σελίδα που διαβάζεται από τον δίσκο, ακόμη και NVMe. Το ερώτημα λοιπόν δεν είναι μόνο «πόσο ζυγίζει η βάση;», αλλά και «ποιο μέρος της διαβάζεται συχνά;». Μια βάση 50 GB, από την οποία διαβάζονται μόνο οι τελευταίοι δώδεκα μήνες, μπορεί στην πράξη να δουλεύει με 8 GB.

Σε μια υπάρχουσα βάση, δύο ερωτήματα δίνουν τον συνολικό όγκο και τους μεγαλύτερους πίνακες, μαζί με τα ευρετήρια:

SELECT pg_size_pretty(pg_database_size(current_database()));

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

Για μια βάση που δεν υπάρχει ακόμη, κάντε εκτίμηση πίνακα προς πίνακα: αριθμός γραμμών που αναμένονται σε έναν χρόνο × μέσο μέγεθος γραμμής, και έπειτα προσθέστε τα ευρετήρια, που ζυγίζουν συνήθως από 30 έως 100 % των δεδομένων. Παράδειγμα: 2 εκατομμύρια γραμμές τον μήνα, των 500 byte η καθεμία, κάνουν 12 GB δεδομένων σε έναν χρόνο, και 18 έως 24 GB με τα ευρετήρια.

Η μνήμη: οι αρχικές ρυθμίσεις

Η PostgreSQL κρατά τις σελίδες που διαβάζει σε δύο επίπεδα: τη δική της cache (shared_buffers) και την cache αρχείων του συστήματος. Η τεκμηρίωσή της συνιστά να ξεκινήσετε από το 25 % της μνήμης για το shared_buffers σε αφιερωμένο διακομιστή, και παρατηρεί ότι πέρα από το 40 % το όφελος γίνεται σπάνιο: το υπόλοιπο ωφελεί την cache του συστήματος και τις ταξινομήσεις.

Οι τιμές αυτές προϋποθέτουν μια βάση μόνη της στον διακομιστή. Αν η εφαρμογή τρέχει δίπλα της, αφαιρέστε πρώτα τη μνήμη της εφαρμογής (διεργασίες, cache, μεταγλώττιση) και εφαρμόστε τα ποσοστά στο υπόλοιπο: ένας διακομιστής 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();.

Για να ξέρετε αν η μνήμη αρκεί, διαβάστε το ποσοστό ανάγνωσης από cache. Σε μια επιχειρηματική εφαρμογή ή μια ιστοσελίδα, ξεπερνά το 99 %:

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

Οι συνδέσεις: μία διεργασία η καθεμία

Η PostgreSQL ανοίγει μία διεργασία ανά σύνδεση, και δέχεται εξ ορισμού 100 (max_connections). Κάθε διεργασία καταλαμβάνει μερικά megabyte σε αδράνεια, περισσότερα όταν ταξινομεί ή κατακερματίζει δεδομένα (work_mem, μερικές φορές πολλές φορές μέσα στο ίδιο ερώτημα). Αν ανεβάσετε το max_connections στις 500 για να ακολουθήσετε μια «φλύαρη» εφαρμογή, εκθέτετε τον διακομιστή σε έλλειψη μνήμης με την πρώτη αιχμή.

Η σωστή απάντηση είναι ένα εργαλείο συγκέντρωσης συνδέσεων (connection pooler): το PgBouncer, σε λειτουργία transaction, κάνει εκατοντάδες συνδέσεις της εφαρμογής να μοιράζονται μερικές δεκάδες πραγματικές συνδέσεις. Τα frameworks έχουν επίσης τη δική τους δεξαμενή συνδέσεων (SQLAlchemy, Prisma, HikariCP): ρυθμίστε το μέγεθός της με βάση τον αριθμό των vCPU του διακομιστή της βάσης και όχι τον αριθμό των χρηστών.

Ο δίσκος: όγκος, περιθώριο και αρχείο καταγραφής

Ο δίσκος ενός διακομιστή PostgreSQL φιλοξενεί περισσότερα από τους πίνακες:

• Τα δεδομένα και τα ευρετήρια, και την αύξησή τους σε έναν χρόνο.
• Το αρχείο καταγραφής συναλλαγών (WAL): 1 GB εξ ορισμού ανάμεσα σε δύο σημεία ελέγχου (max_wal_size), περισσότερο κατά τη διάρκεια μιας μαζικής εισαγωγής, και ακόμη περισσότερο αν η αρχειοθέτηση του WAL καθυστερεί.
• Τα προσωρινά αρχεία των ταξινομήσεων που ξεπερνούν το 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 total_ms,
       round(mean_exec_time::numeric, 1) AS mean_ms, query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Στον ίδιο διακομιστή με την εφαρμογή, ή σε χωριστό;

Στην αρχή, η βάση στον ίδιο διακομιστή με την εφαρμογή είναι η σωστή επιλογή: καμία καθυστέρηση δικτύου ανάμεσά τους, σύνδεση μέσω Unix socket, ένας μόνο διακομιστής για αντίγραφα ασφαλείας και παρακολούθηση. Τις χωρίζετε όταν ανταγωνίζονται για τους πόρους: μια μεταγλώττιση ή μια αιχμή κίνησης που αδειάζει την cache της βάσης, μια βάση που χρειάζεται όλη τη μνήμη για τα δεδομένα της, ή διαφορετικές απαιτήσεις αντιγράφων ασφαλείας.

Ασφάλεια και αντίγραφα ασφαλείας

• Τοπική ακρόαση: listen_addresses = 'localhost' όσο μόνο η εφαρμογή του διακομιστή συνδέεται. Αν πρέπει να έχει πρόσβαση ένας άλλος διακομιστής, ανοίξτε τη θύρα 5432 μόνο για τη δική του διεύθυνση, στο τείχος προστασίας και στο pg_hba.conf.
• Ταυτοποίηση: μέθοδος scram-sha-256 στο pg_hba.conf, ένας ρόλος ανά εφαρμογή, χωρίς δικαιώματα υπερχρήστη.
• Λογικό αντίγραφο ασφαλείας κάθε μέρα με pg_dump, αντιγραμμένο εκτός διακομιστή.
• Επαναφορά σε συγκεκριμένη χρονική στιγμή: η συνεχής αρχειοθέτηση του αρχείου καταγραφής (pgBackRest, WAL-G) επιτρέπει την επιστροφή στο λεπτό πριν από ένα λάθος, ενώ μια ημερήσια εξαγωγή σας γυρίζει στην προηγούμενη μέρα.
• Δοκιμασμένη επαναφορά: ένα αντίγραφο ασφαλείας αποδεικνύεται με την επαναφορά του, σε μια δοκιμαστική βάση, σε τακτά διαστήματα.

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