PostgreSQL ayrılmış vCPU'lu bir VPS'te ne kadar CPU ve RAM gerektirir?

PostgreSQL kaç vCPU kullanır?

PostgreSQL, çalışan her sorgu için bir CPU iş parçacığı kullanır, çünkü her bağlantı kendi backend sürecini alır. Dokümantasyon bunu "kullanıcı başına süreç" modeli olarak adlandırır: postmaster her bağlantı için yeni bir backend başlatır. Bu nedenle bir veritabanının ihtiyaç duyduğu CPU, açık bağlantıların sayısıyla değil, aynı anda yürütülen sorguların sayısıyla belirlenir. Boşta duran bir bağlantı bellek harcar, CPU harcamaz.

Sorgularınızın üstüne iş parçacığı ekleyen üç şey vardır:

• Paralel sorgu. Büyük bir tarama yardımcı işçiler toplar: max_parallel_workers_per_gather varsayılan olarak 2, max_parallel_workers ise 8'dir ve bunlar max_worker_processes (varsayılan 8) havuzundan alınır.
• Autovacuum. Arka planda tabloları autovacuum_max_workers sürece kadar (varsayılan 3) temizler.
• Uygulama, aynı VPS üzerinde çalıştığında.

2 vCPU'lu bir VPS'te paralelleşen tek bir rapor, uygulamanın kısa sorguları arkasında beklerken tüm iş parçacıklarını meşgul edebilir. Raporlama rolü için max_parallel_workers_per_gather değerini düşürmek ya da bir üst plana geçmek bunu çözer. Bu sayıların arkasındaki iş parçacığı-çekirdek kuralı ayrılmış bir vCPU bir çekirdek midir yoksa bir iş parçacığı mı sayfasında açıklanmıştır.

PostgreSQL bir VPS'te ne kadar RAM gerektirir?

shared_buffers'ı VPS'in RAM'inin %25'inde başlatın ve geri kalanın çoğunu işletim sisteminin sayfa önbelleğine bırakın. PostgreSQL 18 dokümantasyonu bu başlangıç değerini 1 GB veya daha fazla RAM'e sahip ayrılmış bir veritabanı sunucusu için verir ve %40'ın üzerinin daha iyi çalışmasının olası olmadığını ekler, çünkü PostgreSQL çekirdeğin önbelleğine de güvenir. Paketle gelen varsayılan değer 128 MB'tır.

RAM'den iki ayar daha çıkar:

• effective_cache_size yalnızca planlayıcı için bir tahmindir (varsayılan 4 GB). İndeks taramaları doğru maliyetlensin diye bunu shared_buffers ile sayfa önbelleğinin birlikte tuttuğu değere ayarlayın.
• work_mem (varsayılan 4 MB) her oturumdaki her sıralama veya hash adımı için geçerlidir. Tek bir karmaşık sorgu bunu birkaç kez kullanır ve birçok oturum bunu aynı anda yapar, bu yüzden dikkatle büyütülür.

Cobaltfell'in 2 Kasım 2026 tarihli incelemesine göre, kimlik kontrolü olmadan kripto kabul eden barındırıcılarda kayda geçen 202 ayrılmış CPU planının 106'sı vCPU başına 4 GB veya daha fazla RAM verdi. Bir veritabanı için vCPU başına RAM, vCPU sayısı kadar önemlidir.

Bu sayının arkasındaki planlar Kasım 2026'da ayrılmış CPU'lu bir VPS'in çekirdek başına maliyeti nedir sayfasında listelenmiştir.

CPU steal PostgreSQL p99 gecikmesini nasıl etkiler?

CPU steal, ortalamayı oynatmadan çok önce sorguların en yavaş %1'ini uzatır. Linux çekirdeği steal'i istemsiz bekleme olarak tanımlar: bir vCPU'nun işi varken hypervisor'un başka birini çalıştırdığı zaman. Sorgunun ortasında duraklayan bir backend öylece durur ve o sorguyu ya da o sorgunun tuttuğu bir kilidi bekleyen her istemci de onunla birlikte durur.

Duraklamalar kısa ve düzensizdir, bu yüzden yalnızca o anda CPU'da olan sorguları vururlar. Bir ölçüm değil, bir örnek olarak: bir vCPU arada bir komşusuna birkaç on milisaniye kaybettiğinde, o pencerelerden birine denk gelen 2 ms'lik bir sorgu on kat daha uzun sürer, çevresindeki binlerce sorgu ise normal hızda çalışır. Ortalama neredeyse hiç değişmez; maliyetin tamamını 99. yüzdelik taşır.

Bu yüzden paylaşımlı bir vCPU üzerindeki bir veritabanı ortalamalarda sağlıklı görünür ama yine de zaman aşımları üretir. Üç okuma bunu ortaya çıkarır:

• Steal: en yoğun saatte mpstat komutunun %steal sütunu, CPU steal süresi nedir ve bir VPS'te nasıl kontrol edilir sayfasında açıklanmıştır.
• En kötü durumlar: pg_stat_statements her ifade için max_exec_time ve stddev_exec_time raporlar, yüzdelik raporlamaz.
• Yüzdelikler: log_min_duration_statement (örneğin 250ms) yavaş ifadeleri günlüğe yazar; uygulamadaki bir gecikme histogramı p99'un kendisini verir.

# queries on the CPU right now (run at your busiest hour)
psql -c "SELECT count(*) FROM pg_stat_activity WHERE state = 'active';"

# statements with the worst single run (needs pg_stat_statements in shared_preload_libraries)
psql -c "SELECT left(query, 60) AS query, calls,
  round(mean_exec_time::numeric, 2) AS mean_ms,
  round(max_exec_time::numeric, 2) AS max_ms
  FROM pg_stat_statements ORDER BY max_exec_time DESC LIMIT 10;"

# steal per vCPU, every 5 seconds (package sysstat)
mpstat -P ALL 5 6

Ayrılmış bir vCPU bir veritabanı için neyi değiştirir?

Ayrılmış bir vCPU, VPS'in içinden ayarlanamayan tek kuyruk gecikmesi kaynağını ortadan kaldırır. Yavaş planlar, eksik indeksler ve kilit çekişmesi operatörün çözmesi gerekenlerdir; paylaşımlı bir çekirdek üzerindeki komşunun toplu işi değil. Genel durum paylaşımlı ve ayrılmış vCPU arasındaki fark nedir sayfasında anlatılmıştır. Bir Cobaltfell VPS'inde:

• CPU: Bir vCPU, ana makine işlemcisinin bir donanım iş parçacığıdır. Sizinkiler VPS'nize bire bir sabitlenir ve başka bir müşteriye asla ödünç verilmez; fiziksel bir çekirdeğin iki iş parçacığı bir arada kalır, böylece her 2 vCPU, hiçbir komşunun paylaşmadığı tam bir çekirdek oluşturur.
• Steal: Ayrılmış bir vCPU'da steal time sıfırda veya sıfıra yakın olmalıdır. Kendi makinelerimizde ölçtüğümüz değeri tarihiyle birlikte yayımlayacağız, asla bir tahmin değil.
• Bellek: Planınızın RAM'i VPS'nize ayrılır ve aşırı taahhüt edilmez.
• Disk: Her planda NVMe depolama.
• Yük: İşiniz gerektirdiği süre boyunca tam yük serbesttir: CPU kredisi yok, ani yük penceresi yok ve %100'de birkaç dakika geçtikten sonra kısıtlama yok. Uzun bir VACUUM ya da indeks oluşturma tam kapasite çalışır.

İşlemci ailesi AMD EPYC 9004/9005 (Zen 4 / Zen 5).

Bir VPS PostgreSQL için ne zaman yanlış evdir?

Her dakika sorgulanan veri, en büyük planın RAM'inden çok daha büyükse ya da replikalar ve yedekler sizin adınıza yönetilmeli ise bir VPS yanlış evdir. Fell 16'nın 32 GB var. Belleğe sığmayan bir çalışma kümesi her sorguyu disk okumasına çevirir ve o zaman hızı vCPU değil depolama verimliliği belirler.

Yedekler operatörde kalır: Yedeklemeler hiçbir plana dahil değildir: verilerinizin bir kopyasını başka bir yerde tutun. Gecede bir pg_dump ya da başka bir yerdeki depolamaya gönderilen bir WAL arşivi küçük veritabanlarının çoğunu kapsar; geri yükleme testi ihtiyaç duyulmadan önce takvime konmalıdır.

İki veya üç VPS arasında streaming replication ile failover çalışır, ama kendi yönetiminizdedir. Cobaltfell sunucuları satar, yönetilen bir veritabanı satmaz. Her boyutun fiyatı ayrılmış çekirdekli bir VPS ne kadar altında listelenmiştir.