16 GB RAM'li VPS: bellekte veritabanları, arama ve yerel yapay zekâ modelleri
On altı gigabayt, belleğin bir kısıtlama olarak değil, bir hızlandırıcı olarak çalışmaya başladığı miktardır. Onu almanın asıl nedeni verilerdir: tamamen önbelleğe sığan bir veritabanı, bir arama dizini, analitik, bir dil modeli. 8 GB'ta belleği servisler arasında bölüyordunuz; 16 GB'ta ise aslan payını hangisine vereceğinize karar verirsiniz.
16 GB hangi yükler için alınır
- 10–30 GB veritabanlı PostgreSQL veya MySQL. Verilerin sıcak kısmı — aktif siparişler, kullanıcılar, dizinler — belleğe sığar ve sorgular diski beklemeyi bırakır. Sunucunun veritabanına göre nasıl ayarlanacağı PostgreSQL için VPS bölümünde ele alınıyor.
- Elasticsearch veya OpenSearch, tek düğümde: yığına 8 GB verilir, geri kalanı dosya önbelleği için Lucene'e gerekir. Birkaç on gigabayta kadar dizinler kabul edilebilir hızda çalışır; bkz. Elasticsearch için VPS.
- İşlemcide dil modelleri. 4 bit nicelemeli 7–8 milyar parametreli bir model 5–6 GB, 13–14 milyar parametreli bir model ise 9–10 GB kaplar. Her ikisi de web arayüzüyle birlikte 16 GB'a sığar. Yanıt hızını bellek değil, işlemci sınırlar; ayrıntılar Ollama için VPS bölümündedir.
- İstemci-sunucu modunda 1C, 15–30 kullanıcı için: aynı makinede 1C kümesi ve PostgreSQL.
- Kubernetes düğümü veya bir düzine mikroservis, izleme ve günlük kaydı içeren bir k3s ortamı.
- CI sunucusu, Node.js, Java veya Go ile birkaç projeyi paralel olarak derleyen.
Sunucuda bir dizi küçük site ve bot varsa 16 GB gereksiz harcamaya dönüşür: onların bu kadar önbelleğe ihtiyacı yoktur ve aynı çekirdek sayısına sahip 8 GB'lık bir paket de aynı işi görür. Belleği artırmadan önce mevcut belleğin nereye harcandığına bakın: «yetersizlik» çoğu zaman sızıntısı olan tek bir süreç veya tabloları baştan sona okuyan dizinsiz bir veritabanı çıkar. Çalışan veri kümesi gerçekten tampona sığdığından daha hızlı büyüyorsa bir sonraki adım 32 GB veya veritabanı için ayrı bir sunucudur.
16 GB veritabanı için nasıl dağıtılır
Ayrılmış bir veritabanı sunucusu için klasik referanslar şunlardır: PostgreSQL'de shared_buffers yaklaşık 4 GB (%25), effective_cache_size 11–12 GB; çünkü geri kalanını çekirdek, Postgres'in de okuduğu dosya önbelleği için kullanır. work_mem eşzamanlı sıralama işlemlerinin sayısıyla çarpılır; bu yüzden yüz bağlantıda 64 MB kolayca tüm belleği tüketir — bağlantı havuzunu PgBouncer üzerinden yönetin. InnoDB'li MySQL için, sunucuda başka ağır servis yoksa tampon 10–11 GB'a kadar çıkarılabilir.
Elasticsearch için kural terstir: yığın belleğin en fazla yarısı olmalı, öbür yarısı işletim sistemi önbelleği için boş kalmalıdır. 16 GB'ın 14 GB'ını yığına vermek sık yapılan bir hatadır; bunun sonucunda arama hızlanmaz, yavaşlar.
16 GB'ta disk ve çekirdekler
16 GB genellikle 4–8 sanal çekirdek ve 160–320 GB diskle gelir. Veritabanları ve arama için yalnızca NVMe'li VPS seçin: bellek okumayı hızlandırır, ama işlem günlüğünün yazılması ve dizin segmentlerinin birleştirilmesi yine de diske dayanır. Yapay zekâ modelleri için çekirdekler ve nesilleri daha önemlidir: AVX2 veya AVX-512 desteği model çıkarımını kat kat hızlandırır; bunu grep -o 'avx[^ ]*' /proc/cpuinfo | sort -u komutuyla kontrol edebilirsiniz.
Garanti edilen bellek, OOM ve swap
16 GB'ın alındığı görevler ne konteynerlerin burst belleğini ne de swap'ı iyi tolere eder. Garanti edilmeyen miktara doğru büyüyen bir veritabanı, bu bellek geri alındığında en yoğun anda OOM ile karşılaşır; yığını swap'a düşen Elasticsearch ise çöp toplama için on saniyelerce durmaya başlar. Bu yüzden:
- burst'lü OpenVZ veya LXC değil, belleği tamamen ayrılmış KVM alın;
- Elasticsearch için
bootstrap.memory_lockseçeneğini açın, Postgres için ise belgelerin önerisine görevm.overcommit_memory=2ayarlayın; - swap'ı 2–4 GB ile küçük tutun ve büyümediğini izleyin.
Satın aldıktan sonra kontrol
free -hvenproc— yaklaşık 15,6 GB bellek ve pakete uygun çekirdek sayısı.stress-ng --vm 2 --vm-bytes 14G --timeout 120s— sunucu belleğin doldurulmasını donmadan kaldırmalıdır.- 4 KB'lık bloklarla rastgele yazma yapan
fio— bir veritabanı için bu, sıralı okuma hızından daha önemlidir. - Bir haftalık çalışmadan sonra sıcak verilerin boyutunu tamponlarla karşılaştırın:
pg_stat_databaseiçindeki önbellek isabet oranı %99'un altındaysa veriler için bellek yetmiyordur.