PostgreSQL'de havuz büyüklüğü ve veritabanı bağlantıları arasındaki tatlı nokta nasıl belirlenir

Veritabanı sunucumuzun yoğun saatlerde trafiğini işlemede sorun yaşıyoruz. Donanımı geliştirmek istiyoruz (işlerin bu tarafıyla ilgili bu soruya bakın ), ancak havuz yapılandırması ve sunucu ayarlaması üzerinde de çalışmak istiyoruz.

Üzerinde çalıştığımız uygulama, arka ucun veritabanı olarak Unicorn ve PostgreSQL 9.1 ile Raylardan oluştuğu akıllı telefonlar için sıra tabanlı çok oyunculu bir oyundur . Şu anda 600.000 kayıtlı kullanıcımız var ve oyun durumu veritabanında saklandığından, her birkaç saniyede birkaç binlerce yazma yapılmaktadır. PostgreSQL'in günlük dosyalarını PgBadger kullanarak analiz ettik ve kritik saatler boyunca

FATAL: remaining connection slots are reserved for non-replication superuser connections

Bu soruna karşı koymak için naif çözüm , postgresql.conf dosyasındaki max_connections (şu anda 100 olan) artırmak olacaktır . Http://wiki.postgresql.org/wiki/Number_Of_Database_Connections bu yapmak için doğru bir şey olmayabilir gösteren okudum . Yukarıda bahsedilen makalede max_connections ve havuz büyüklüğü arasındaki tatlı noktayı bulmaktan bahsedilmektedir .

Bu tatlı noktayı bulmak için ne yapılabilir? Farklı max_connections ve havuz boyutu değerleri için G / Ç performansını ölçmek için iyi araçlar var mı?

Mevcut kurulumumuz, her biri 16 tek boynuzlu işçi ve 5 havuz büyüklüğüne sahip 4 oyun sunucusudur.

Kullandığımız varsayılan olmayan postgres ayarları şunlardır:

version                      | PostgreSQL 9.1.5 on x86_64-unknown-linux-gnu,compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit
checkpoint_completion_target | 0.9
checkpoint_segments          | 60
checkpoint_timeout           | 6min
client_encoding              | UTF8
effective_cache_size         | 2GB
lc_collate                   | en_US.UTF-8
lc_ctype                     | en_US.UTF-8
log_destination              | csvlog
log_directory                | pg_log
log_filename                 | postgresql-%Y-%m-%d_%H%M%S.log
log_line_prefix              | %t
log_min_duration_statement   | 200ms
log_rotation_age             | 1d
log_rotation_size            | 10MB
logging_collector            | on
max_connections              | 100
max_stack_depth              | 2MB
server_encoding              | UTF8
shared_buffers               | 1GB
ssl                          | on
TimeZone                     | localtime
wal_buffers                  | 16MB
work_mem                     | 8MB

Buradaki kısa cevap, "izleme ve performans metriklerinin yol açtığı deneme yanılma" şeklindedir.

Başlamanız gereken belirsiz alanı bulmanıza yardımcı olacak bazı genel kurallar vardır, ancak bunlar çok geneldir. "CPU sayısı artı bağımsız disk sayısı vardır" genel yönergeleri sıklıkla belirtilir, ancak bu yalnızca inanılmaz derecede kaba bir başlangıç ​​noktasıdır.

Gerçekten yapmanız gereken, uygulamanız için sağlam performans metrikleri oluşturmaktır. İstatistikleri kaydetmeye başlayın.

Bunun için entegre takımların yolunda çok fazla şey yoktur. Nagios check_postgresbetiği, Cacti sistem performans sayacı günlüğü, PostgreSQL istatistik toplayıcısı vb. Gibi şeyler vardır ... Ne yazık ki, bunu biraz kendin yapmalısın. PostgreSQL tarafı için PostgreSQL kılavuzundaki izlemeye bakın . EnterpriseDB'nin Postgres Enterprise Monitor gibi bazı üçüncü taraf seçenekleri mevcuttur .

Burada belirtilen uygulama düzeyi metrikleri için bunları paylaşılan veri yapılarına veya Redis gibi dayanıklı olmayan harici bir DB'ye kaydetmek ve bunları kaydettiğinizde veya PostgreSQL DB'nize yazmadan önce toplamak istersiniz. Doğrudan Pg'de oturum açmaya çalışmak, ölçümleri kaydederek oluşturulan ek yük ile ölçümlerinizi bozar ve sorunu daha da kötüleştirir.

En basit seçenek, muhtemelen uygulama istatistiklerini kaydetmek için kullandığınız her uygulama sunucusundaki tek bir seçenektir. Muhtemelen sürekli güncellenen bir min, maks, n, toplam ve ortalama tutmak istersiniz; bu şekilde her bir istatistik noktasını saklamak zorunda kalmazsınız, sadece toplanır. Bu singleton, toplam istatistiklerini her x dakikada bir Pg'ye yazabilir, bu da performans etkisinin en az olacağı kadar düşük bir orandır.

İle başla:

• İstek gecikmesi nedir? Başka bir deyişle, uygulamanın istemciden istemciye yanıt vermesini istemesi ne kadar sürer. Bunu tek tek kayıtlar yerine bir süre boyunca toplam olarak kaydedin. İstek türüne göre gruplandırın; mesela, sayfaya göre.

• Uygulamanın yürüttüğü her sorgu veya sorgu türü için veritabanı erişim gecikmesi nedir? DB'den bilgi istemekten / bilgi depolamadan, tamamlanana ve bir sonraki göreve geçene kadar ne kadar sürer? Yine, bu istatistikleri uygulamada toplayın ve yalnızca toplu bilgileri DB'ye yazın.

• Veriminiz nasıl? Belirli bir x dakikada, uygulamanızın yürüttüğü her ana sınıftan kaç sorgu DB tarafından hizmet alır?

• Aynı x dakika aralığı için kaç müşteri isteği vardı?

• Birkaç saniyede bir örnekleme ve DB'deki aynı x dakikalık pencerelerde toplama, kaç tane DB bağlantısı vardı? Kaç tanesi boş kaldı? Kaç tanesi aktifti? Eklerde? Güncellemeler? seçer? siler? O dönemde kaç işlem yapıldı? İstatistik toplayıcı belgelerine bakın

• Yine aynı zaman aralığında örnekleme ve toplama, ana bilgisayar sisteminin performans metrikleri nasıldı? Kaç okuma ve kaç yazma diski IO / saniye? Saniyede megabayt okuma ve yazma? CPU kullanımı? Ortalama yük mü? RAM kullanımı?

Artık verileri ilişkilendirerek, grafiklerle vb. İlişkilendirerek uygulamanızın performansını öğrenmeye başlayabilirsiniz. Kalıpları görmeye başlayacak, darboğazları bulmaya başlayacaksınız.

Saniyede megabayt cinsinden oldukça düşük disk G / Ç değerine rağmen , sisteminizin şişe boyunlu olduğunu INSERTve UPDATEyüksek işlem oranlarında olduğunu öğrenebilirsiniz . Bu, pil destekli geri yazma önbellekleme RAID denetleyicisi veya bazı yüksek kaliteli güç korumalı SSD'lerle disk temizleme performansınızı artırmanız için bir ipucu olacaktır. synchronous_commit = offSunucu çökmesi sırasında birkaç işlemi kaybetmek ve / veya a commit_delay, senkronizasyon yükünün bir kısmını çıkarmak için de uygunsa kullanabilirsiniz .

Saniyede işlemlerinizi eşzamanlı bağlantı sayısına göre grafiğe eklediğinizde ve uygulamanın gördüğü değişken talep oranına göre düzelttiğinizde, iş hacmi tatlı yerinizin nerede olduğu hakkında daha iyi bir fikir edinebilirsiniz.

Hızlı temizleme depolama alanınız (BBU RAID veya hızlı dayanıklı SSD'ler) yoksa, oldukça az sayıda aktif yazma bağlantısından daha fazlasını istemezsiniz, belki de sahip olduğunuz disk sayısının en fazla 2 katı, RAID düzenlemesine bağlı olarak daha az , disk performansı vb. Bu durumda deneme yanılma değerine bile değmez; Sadece hızlı disk basması ile birine depolama alt sistemini yükseltmek .

Bunun pg_test_fsyncsizin için bir sorun olup olmadığını belirlemenize yardımcı olacak bir araç arayın. Çoğu PostgreSQL paketi bu aracı katkıda bulunmanın bir parçası olarak kurar, bu yüzden derlemenize gerek yoktur. Eğer saniyede birkaç bin ops / saniyeden az pg_test_fsyncalırsanız, acilen depolama sisteminizi yükseltmeniz gerekir. SSD donanımlı dizüstü bilgisayarım 5000-7000 alır. İş istasyonum 7200 rpm SATA diskler ve yazma (önbelleğe yazma olmayan) ile 4 diskli RAID 10 dizisi ile çalışırken, yaklaşık 80 ops / saniye f_datasync, 20 ops / saniye alır fsync(); bu kadar yavaş yüzlerce kez . Karşılaştırma: yazma (önbelleğe yazma olmayan) RAID 10 ile ssd ve iş istasyonuna sahip dizüstü bilgisayar. Bu dizüstü bilgisayarın SSD'si ucuz ve güç kaybında yazma önbelleğini yıkamak için ona kesinlikle güvenmiyorum; İyi yedeklemeler saklıyorum ve önem verdiğim veriler için kullanmam. Kaliteli SSD'ler daha iyi olmasa da iyi performans gösterir ve yazmaya dayanıklıdır.

Başvurunuzda, aşağıdakileri incelemenizi şiddetle tavsiye ederim:

• Hızlı yıkamalara sahip iyi bir depolama altsistemi. Bunu yeterince vurgulamıyorum. Kaliteli elektrik kesintisi korumalı SSD'ler ve / veya güç korumalı geri yazma önbelleğine sahip bir RAID denetleyicisi.
• UNLOGGEDKaybetmeyi göze alabileceğiniz veriler için tabloları kullanma . Periyodik olarak günlüklenmiş tablolara toplayın. Örneğin, devam etmekte olan oyunları bloke edilmemiş masalarda tutun ve puanları normal dayanıklı masalara yazın.
• Kullanarak commit_delay(hızlı yıkama depolama ipucu ile daha az yararlı - ipucu)
• synchronous_commitKaybetmeyi göze alabileceğiniz işlemlerin kapatılması (hızlı yıkama depolamasında daha az kullanışlı - ipucu ipucu)
• Bölümleme tabloları, özellikle verinin “eskidiği” ve temizlendiği tablolar. Bölümlenmiş bir tablodan silmek yerine bir bölüm bırakın.
• Kısmi dizinler
• Oluşturduğunuz dizin sayısını azaltma. Her indeksin yazma maliyeti vardır.
• İşleri daha büyük işlemlere topluyor
• Ana DB'den okuma yükünü almak için salt okunur etkin bekleme kopyalarını kullanma
• Daha az sıklıkta değişen veya eski gibi gelebilecek veriler için memcached veya redis gibi bir önbellek katmanı kullanma. Sen kullanabilirsiniz LISTENve NOTIFYPostgreSQL tabloları tetikleyicileri kullanarak geçersizlik önbelleği yerine getirmektir.

Şüpheniz varsa: http://www.postgresql.org/support/professional_support/