Sorun Giderme · Veritabanları
PostgreSQL Lock Wait ve Deadlock Sorun Giderme
Lock wait başka işlem tamamlanana kadar beklemedir; deadlock işlemlerin birbirini döngüsel beklemesidir. PostgreSQL deadlock tespitinde işlemlerden birini hata ile sonlandırabilir. Yavaş…
Teknik gözden geçirme:
Mimari ve çalışma modeli
Lock wait başka işlem tamamlanana kadar beklemedir; deadlock işlemlerin birbirini döngüsel beklemesidir. PostgreSQL deadlock tespitinde işlemlerden birini hata ile sonlandırabilir. Yavaş sorgu her zaman kötü query plan değildir; blocked işlem yalnız kilit bekliyor olabilir.
pg_stat_activity, pg_blocking_pids ve transaction başlangıç zamanını birlikte inceleyin. Query metni hassas veri içerebilir; görüntüleme yetkisini ve rapor kapsamını sınırlandırın. Idle in transaction, uygulamanın sorgu yapmadığı halde transaction’ı açık bıraktığını gösterebilir.
Önce blocker sahibini, iş amacını ve rollback etkisini bulun. pg_cancel_backend yalnız çalışan statement’ı iptal eder; oturumun transaction durumu ayrıca ele alınır. Rastgele session terminate büyük rollback ve uygulama retry fırtınası yaratabilir. Kalıcı çözüm tutarlı lock sırası ve kısa transaction’dır.
- 1Yavaş işlem
- 2Bekleme türü
- 3Root blocker
- 4Dar müdahale ve tasarım düzeltmesi
Tasarım parametreleri
- Zaman ayrımı
- Query süresi ile transaction süresini ayrı okuyun.
- Blokaj grafiği
- Bekleyen→blocker zincirini root blocker’a kadar takip edin.
- Timeout
- lock_timeout ile statement_timeout farklıdır; uygulama hata yönetimini birlikte sınayın.
Hesap ve uygulama örneği
Oturum A önce hesap 1’i, B önce hesap 2’yi güncellesin; ardından A hesap 2’yi, B hesap 1’i isterse döngü oluşabilir. Her iki işlemin hesapları artan ID sırasıyla kilitlemesi riski azaltır. Deadlock sonrası bütün transaction retry ve dış yan etkileri kontrol edin.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
SELECT pid, application_name, state, wait_event_type, wait_event,
clock_timestamp()-xact_start AS transaction_age,
pg_blocking_pids(pid) AS blockers
FROM pg_stat_activity
WHERE wait_event_type = 'Lock' OR state = 'idle in transaction';Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Lock wait sürekli | Uzun veya idle transaction. | xact_start ve blocker uygulamasını inceleyin. |
| 40P01 tekrar ediyor | Farklı lock sırası. | İki transaction’ın erişim sırasını karşılaştırın. |
Kabul ve doğrulama kontrolleri
- Bekleme türünü doğrulayın.
- Root blocker’ı bulun.
- Müdahale sahibini belirleyin.
- Rollback etkisini değerlendirin.
- Lock sırasını standardize edin.
- Retry fırtınasını engelleyin.
İlgili kavramlar
Kilit, bekleme ve deadlock
Eşzamanlı işlemler veri bütünlüğü için kilit veya sürümleme mekanizmaları kullanır. Uzun açık transaction, diğer işleri bekletebilir; deadlock ise birbirini bekleyen işlemler arasındaki döngüdür. Ürün bazı işlemlerden birini sonlandırabilir ve uygulamanın güvenli tekrar deneme yapması gerekebilir. Bekleyen sorgu ile onu bloke eden sorguyu birlikte inceleyin. İzolasyon seviyesini rastgele düşürmek veri tutarlılığını değiştirebilir. Transaction süresini kısaltma, tutarlı erişim sırası ve uygun indeks gibi seçenekleri aynı iş yükünde doğrulayın.
Transaction sınırı
Transaction, uygulamanın belirli işlemleri birlikte başarılı veya başarısız kabul ettiği mantıksal birimdir. Veritabanı içindeki atomiklik, e-posta gönderimi veya farklı servislerdeki değişikliklerin otomatik olarak aynı atomik kapsamda olduğu anlamına gelmez. Commit noktası ve hata sonrasında tekrar denemenin davranışı açık olmalıdır. Aynı isteğin iki kez işlenmesini önlemek için idempotency gereksinimini değerlendirin. Testte ağ kesintisi ve bağlantı kopmasını commit öncesi ve sonrasında ayrı uygulayın; istemcinin hata alması işlemin kesinlikle başarısız olduğu anlamına gelmeyebilir.
Kuyruk ve eşzamanlılık
Kuyruk, bir kaynağın işleyebildiğinden daha hızlı gelen işleri tutar. Eşzamanlılığı artırmak belirli bir noktaya kadar kapasite kullanımını yükseltir; sonra bekleme süresini büyütür. Durağan durumda Little yasası L = λ × W ilişkisidir: ortalama sistemdeki iş sayısı, tamamlanan iş hızı ile ortalama toplam sürenin çarpımıdır. Birimler tutarlı olmalıdır. 2.000 işlem/s ve 5 ms toplam süre yaklaşık 10 eşzamanlı iş demektir. Bu ilişki tasarım tahminidir; kuyruk sınırları, ani yük ve çok değişken servis süreleri ayrıca ölçülmelidir.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci sırası ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; log yokluğu, olay yokluğu şeklinde yorumlanmamalıdır.
Kaynak rekabeti
Kaynak rekabeti, birden fazla iş yükünün aynı CPU, bellek, disk veya bağlantıyı paylaşırken birbirini bekletmesidir. Boş görünen toplam kapasite, tek bir sıcak çekirdek veya tek kuyruk üzerindeki darboğazı gizleyebilir. Aynı anda çalışan backup, antivirüs taraması, indeks bakımı ve kullanıcı trafiğini zaman çizelgesinde karşılaştırın. Kaynak eklemeden önce darboğazın yerini doğrulayın. Testte bir işi tek başına ve diğerleriyle birlikte çalıştırarak paylaşılan kaynağın etkisini ayırın; ortalama kullanım kadar yoğun saatlerdeki gecikmeyi de raporlayın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.