PostgreSQL yük testi: yük altında sorgu gecikmesi, bağlantılar ve salt okunur okumalar
PostgreSQL'de yük altındaki yavaşlık çoğu zaman birkaç sorgudan, bağlantı sınırından (max_connections) ya da kilit beklemelerinden gelir. Uygulamayı atlayıp veritabanına doğrudan, gerçekçi parametrelerle ve hedef eşzamanlılıkta sorgu göndermek hangisi olduğunu ayırır. Bu sayfa yöntemin PostgreSQL'e özgü kısmını anlatır; genel yöntem veritabanı yük testi rehberindedir.
PostgreSQL bağlantısı
| Varsayılan port | 5432 |
|---|---|
| Yer tutucu (parametre) | $1, $2… |
| Veritabanı / servis | veritabanı adı |
| TLS için sürücü parametresi | sslmode = require |
| Okumalar salt okunur transaction'da | Evet |
- Bağlantılar → Bağlantı ekle'ye tıklayın, Tür olarak PostgreSQL seçin ve bir ad verin (ör.
orders-db). - Sunucu, Port (boşsa 5432), Veritabanı / servis, Kullanıcı ve Parola'yı girin. Mümkünse yalnızca gerekli tablolarda
SELECTyetkisi olan ayrı bir kullanıcı kullanın; parola şifreli saklanır, testte yalnızca bağlantının adı geçer. - En çok açık bağlantı (runner başına): varsayılan 50. Toplam bağlantı ≈ runner sayısı × bu değer; veritabanının bağlantı sınırını aşmayacak şekilde ayarlayın.
- Kaydet, sonra Test et. Veritabanına yalnızca bir bastion üzerinden ulaşılıyorsa bağlantıya bir SSH tüneli ekleyin.
PostgreSQL için SQL adımı
Sorguyu Sorgu alanına sabit metin olarak yazın; değerleri $1 yer tutucusuyla Parametreler'de verin. Parametreler {{__VU}}, {{$randInt 1 100000}}, çıkarılmış değişkenler ya da CSV veri dosyasından değerler içerebilir; sorgu metninin içine şablon yazılamaz, böylece SQL enjeksiyonu olmaz. Check sekmesinde örneğin Satır sayısı = 1 ekleyin, Dene ile tek iterasyonu çalıştırıp dönen satırları görün, sonra Kaydet.
{"id": "order", "name": "Get order", "protocol": "sql", "connection": "orders-db",
"sql": {"query": "SELECT id, status, total FROM orders WHERE id = $1", "params": ["{{$randInt 1 100000}}"]},
"extract": [{"var": "status", "from": "jsonpath", "expr": "$[0].status"}],
"checks": [{"type": "rowCount", "op": "eq", "value": 1}]}Bir okumanın süresi pool'dan bağlantı beklemeyi, sorguyu ve bütün satırların alınmasını kapsar. Satırlar JSON nesneleri dizisi olarak kontrollere ve değişken çıkarmaya gider ($[0].status gibi). Hatalar türüne göre ayrılır: zaman aşımı, bağlantı reddi, yetki, bulunamayan tablo, kısıt ihlali, sözdizimi ve salt okunur ihlali.
Veriyi korumak
Spitfire bir sorgunun okuma mı yazma mı olduğunu kendisi anlar ve okuma sayamadığı her şeyi yazma sayar. Yazmalar adımda açıkça onaylanmadan test kaydedilmez, onaylanmışsa test her başlatıldığında ayrıca onay ister ve onay denetim kaydına yazılır (güvenlik beyanı).
PostgreSQL'de okuma sayılan her sorgu ayrıca salt okunur bir transaction içinde çalışır ve geri alınır. Okuma gibi görünüp veri değiştiren bir sorgu (yan etkili bir fonksiyon gibi) veritabanının kendisi tarafından reddedilir ve koşuda cannot execute … in a read-only transaction hatası görünür.
Hangi sorguları yüklemeli?
Hangi sorguların yükleneceğini pg_stat_statements eklentisi söyler: her sorgu kalıbının çağrı sayısını (calls) ve toplam süresini (total_exec_time) tutar. En çok çağrılan ve toplamda en çok süre alan birkaç sorgu, testin iskeletidir.
Bu istatistikleri elle aktarmanız gerekmez: pg_stat_statements çıktısı içe aktarılır ve en çok çağrılan sorgular çağrı sayılarıyla ağırlıklandırılmış tek bir SQL adımına dönüşür; kurulum yöneticileri istatistikleri doğrudan bağlantıdan da okuyabilir (query mix).
Sorguları elle yazmak yerine veritabanının kendi schema'sından önerilmesini de isteyebilirsiniz (kurulum yöneticileri; schema'dan query önerileri). PostgreSQL için gereken yetkiler: CONNECT, USAGE, SELECT ve varsayılan yetkileri olan bir LOGIN rolü; istatistikler için isteğe bağlı pg_read_all_stats. Her öneri EXPLAIN (asla ANALYZE değil) ile kontrol edilir: yalnızca plan alınır, sorgu çalıştırılmaz; her önerinin bir satır sınırı (LIMIT) vardır.
Ardından yük modelini seçin: beklenen eşzamanlılıkta sabit bir yük, ya da sınırı bulmak için basamaklı bir kırılma noktası testi. Sonuçları ortalamayla değil p95 ve p99 ile okuyun.
Sık karşılaşılan hatalar
password authentication failed for user …: kullanıcı adı ya da parola yanlış, ya dapg_hba.confcontroller'ın ve runner'ların IP'sine izin vermiyor.no pg_hba.conf entry … SSL off: sunucu şifreli bağlantı istiyor; Sürücü parametreleri'nesslmode=requireekleyin.remaining connection slots are reserved: runner sayısı × En çok açık bağlantı (runner başına) veritabanınınmax_connectionssınırını aşıyor; değeri düşürün ya da sınırı yükseltin.
Sık sorulan sorular
PostgreSQL yük testi canlı veriyi değiştirir mi?Testler
PostgreSQL için kaç bağlantı açılır?Testler
Sorgu süresi neyi kapsar?Testler
Spitfire tek komutla Docker'a ya da Kubernetes'e kurulur; ücretsiz sürümde bütün test özellikleri ve protokoller açıktır.