CrestVPS

postgresql vps

Veritabanları ve bellek içi iş yükleri

Diski önemsizleştirecek kadar bellek.

Biz ne dağıtırdık

€125,30/ay

€17930% yıllık

Belirli bir çalışma seti boyutunun ötesinde, önemli olan tek optimizasyon her şeyi RAM'e sığdırmaktır. FORGE, çekirdek başına on altı gigabayta kadar kayıtlı ECC belleği, önceden yapılandırılmış dev sayfalar ve NUMA farkında yerleşim sunar; PostgreSQL, Redis, ClickHouse ve büyük JVM yığınlarının istediği şey budur. Altında RAID10'da Gen5 NVMe vardır, bu nedenle diske ulaşan yazmalar da darboğaz değildir.

Neden bu yapılandırma

Tek NUMA yakınlığına sahip FORGE, bellek erişimini işi yapan sokete yerel tutar. Otuz geri yükleme noktasına sahip gece yedeklemeleri ekleyin, çünkü gerçekten karşılaşacağınız hata modu, ölü bir disk değil, kötü bir geçiştir.

Biz ne dağıtırdık

PlanFORGE F2
vCPU8 (dedicated)
RAM128 GB
Depolama800 GB
İmajDebian 13 Trixie

Boyutlandırma

RAM'i veritabanına değil, çalışma setine göre boyutlandırın. Çalışma seti, gerçekten erişilen satırlar artı sıcak dizin sayfalarıdır; genellikle 2 TB OLTP veri kümesinin %10-20'si. InnoDB havuz arabelleğini RAM'in %70-75'ine ayarlayın veya Postgres shared_buffers'ı %25'e ayarlayın ve sayfa önbelleğinin gerisini tutmasına izin verin. FORGE çekirdek başına 16 GB'a ulaşır, bu nedenle 512 GB'lık bir havuz arabelleği yaklaşık 700 GB RAM ve en az 44 çekirdek üzerinde oturur. Okumalar önbelleği zamanın %1'inden fazla kaçırırsa, RAM satın alın.

Dev sayfalar ve THP'nin neden aynı şey olmadığı

4 KB sayfalarda eşlenen 256 GB'lık bir arabellek havuzu yaklaşık 64 milyon sayfa tablosu girdisine ihtiyaç duyar. TLB bunun anlamlı bir kısmını tutamaz, bu nedenle rastgele erişim çoğu aramada sayfa yürüyüşü öder. Statik 2 MB dev sayfalar girdi sayısını 512 kat azaltır ve yürüyüşleri de azaltır - büyük havuzlarda sorgu başına CPU süresinde ölçülebilir bir düşüş bekleyin. Bunları vm.nr_hugepages ile önyüklemede ayırın, havuz artı yaklaşık %10 için boyutlandırın ve veritabanı kullanıcısına memlock limiti verin. Şeffaf dev sayfalar aynı eşlemeyi elde eder ancak bunu fırsatçı bir şekilde, kompaktlaştırma duraklamalarıyla yapar. THP'yi devre dışı bırakın ve açıkça ayırın.

Tahmin edilmek yerine ölçülen çalışma seti

Çalışma setini veri dizini boyutundan tahmin etmeyin. Ölçün. Postgres'te pg_buffercache size shared_buffers'ı hangi ilişkilerin kapladığını söyler ve pg_statio_user_tables'teki heap_blks_hit ile heap_blks_read oranı tablo başına önbellek isabet oranını verir. MySQL'de Innodb_buffer_pool_reads ile Innodb_buffer_pool_read_requests aynı sinyali verir. %99'un üzerinde bellek içindesiniz ve RAM eklemek çok az kazandırır. %95 ile %99 arasında uçurumun kenarındasınız ve tek bir dizine eklenmemiş sorgu sizi aşağı itebilir. %95'in altında sahip olduğunuz her gecikme sayısı gerçekte bir disk gecikme sayısıdır, kılık değiştirmiştir.

Ne gibi sorunlar çıkar

  • Şeffaf dev sayfaları etkin bırakmak. THP parçalama, süreci öngörülemeyen anlarda milisaniyeler boyunca durdurur ve bu, kimsenin açıklayamadığı p99 gecikmesi olarak görünür. Bunu asla olarak ayarlayın ve bunun yerine statik dev sayfalar ayırın.
  • İki soketli bir FORGE'da NUMA'yı yoksaymak. Arabellek havuzu bir düğüme yerleşir, çekirdeklerin yarısı ara bağlantı üzerinden okur ve MySQL boş belleğe rağmen takas edebilir. numactl --interleave=all kullanın veya açıkça bağlayın.
  • IOPS'u ortalama verimden boyutlandırma. Kontrol noktaları, vakum ve yedeklemeler önemli olan zirvelerdir. Kararlı durumu iyi idare eden bir havuz, bir kontrol noktası sırasında tüm örneği durdurabilir.

Makineyi ayarlayın

  • CPU zamanlamasıSingle-NUMA-node affinity · €14
  • YedeklerDaily backup, 30 restore points · €11
  • Diğer her şeySecond-resolution metrics + alerting · €5
  • Depolama ve şifrelemeZFS with hourly snapshots · €7