İlk olarak, daima PostgreSQL'in en son sürümünü kullanın. Performans iyileştirmeleri her zaman geliyor, bu nedenle eski bir sürümü ayarlıyorsanız muhtemelen zamanınızı boşa harcıyorsunuz. Örneğin, PostgreSQL 9.2, hızını önemli ölçüde artırırTRUNCATE ve elbette yalnızca dizin taramaları ekler. Küçük sürümler bile daima takip edilmelidir; bkz sürüm politikası .
Yapılmaması Gerekenler
Do DEĞİL RamDisk'i veya diğer dayanıksız depolama bir bir tablo koydu .
Bir tablo alanını kaybederseniz, tüm veritabanı zarar görebilir ve önemli bir iş yapmadan kullanımı zor olabilir. Bunun sadece UNLOGGEDtabloları kullanmak ve zaten önbellek için çok fazla RAM'e kıyasla çok az avantajı var .
Gerçekten ramdisk tabanlı bir sistem istiyorsanız, ramdisk initdbüzerinde initdbyeni bir PostgreSQL örneği oluşturarak ramdisk üzerinde tamamen yeni bir küme istiyorsanız, tamamen tek kullanımlık bir PostgreSQL örneğine sahip olursunuz.
PostgreSQL sunucu yapılandırması
Test yaparken sunucunuzu dayanıklı olmayan ancak daha hızlı çalışacak şekilde yapılandırabilirsiniz .
Bu, fsync=offPostgreSQL'deki ayar için kabul edilebilir tek kullanımdan biridir. Bu ayar, PostgreSQL'e sıralı yazma işlemleri veya diğer kötü veri bütünlüğü koruma ve çarpışma güvenliği öğelerinden herhangi birini rahatsız etmemesini söyler, böylece güç kaybederseniz veya bir OS çökmesi varsa verilerinizi tamamen çöpe atmasına izin verir.
Söylemeye gerek yok, fsync=offPg'yi başka bir yerden yeniden oluşturabileceğiniz veriler için geçici bir veritabanı olarak kullanmadığınız sürece asla üretimde etkinleştirmemelisiniz . Eğer sadece fsync'i kapatmaya çalışıyorsanız, full_page_writesartık o kadar iyi olmadığı için de kapanabilir. O sakının fsync=offve full_page_writesen geçerli küme onlar etkileyen seviyesi, bu nedenle tüm PostgreSQL örneğinde veritabanlarını.
Üretim kullanımı synchronous_commit=offiçin commit_delay, fsync=offdev veri bozulma riski olmadan aynı avantajların çoğunu alacağınız için muhtemelen bir a kullanabilirsiniz . Zaman uyumsuzluğu etkinleştirirseniz, son veri kaybı için küçük bir pencereniz vardır - ancak bu kadar.
UNLOGGEDDDL'yi biraz değiştirme seçeneğiniz varsa, WAL günlüğünden tamamen kaçınmak ve sunucu çöktüğünde tabloların silinmesi pahasına gerçek bir hız artışı elde etmek için Pg 9.1+'deki tabloları da kullanabilirsiniz . Tüm tabloların bloke edilmesini sağlayacak bir yapılandırma seçeneği yoktur, sırasında ayarlanmalıdır CREATE TABLE. Test için iyi olmanın yanı sıra, güvenli olması gereken şeyler içeren bir veritabanında oluşturulan veya önemsiz verilerle dolu tablolarınız varsa bu kullanışlıdır.
Günlüklerinizi kontrol edin ve çok fazla kontrol noktası hakkında uyarı alıp almadığınızı görün. Eğer öyleyse, kontrol noktanızı_segmentlerinizi artırmalısınız . Ayrıca düzgün yazma işlemleri için checkpoint_completion_target'ınızı ayarlamak isteyebilirsiniz.
Ayarlama shared_buffersiş yükünüzü sığdırmak için. Bu işletim sistemine bağlıdır, makinenizde başka neler olup bittiğine bağlıdır ve biraz deneme yanılma gerektirir. Varsayılanlar son derece muhafazakardır. shared_buffersPostgreSQL 9.2 ve altı sürümlerde yükselirseniz işletim sisteminin maksimum paylaşılan bellek sınırını artırmanız gerekebilir ; 9.3 ve üstü, bundan kaçınmak için paylaşılan belleği kullanma biçimlerini değiştirdi.
Çok fazla iş yapan sadece birkaç bağlantı kullanıyorsanız, work_memonlara vb. Oynamak için daha fazla RAM vermek için artırın . Çok yüksek bir work_memayarın bellek yetersiz sorunlara neden olabileceğine dikkat edin, çünkü bir sorguda çok sayıda iç içe sıralama olabilir. Yalnızca gerçekten artırmalıyız work_memsen diske dökülmesini türlü görürse EXPLAINveya birlikte günlüğe log_temp_filesayarı (önerilir), ancak daha yüksek bir değer de Pg akıllı planlar almak izin verebilir.
Burada başka bir posterde de belirtildiği gibi, xlog ve ana tabloları / dizinleri mümkünse ayrı HDD'lere koymak akıllıca olacaktır. Ayrı bölümler oldukça anlamsız, gerçekten ayrı sürücüler istiyorsun. Bu ayrıştırma ile çalışıyorsanız çok daha az fayda sağlar fsync=offve UNLOGGEDtablo kullanıyorsanız neredeyse hiç yoktur .
Son olarak, sorgularınızı ayarlayın. Emin olun random_page_costve seq_page_costsisteminizin performansını yansıtın effective_cache_size, doğru olduğundan emin olun vb. EXPLAIN (BUFFERS, ANALYZE)Tek tek sorgu planlarını incelemek için kullanın ve auto_explaintüm yavaş sorguları bildirmek için modülü açın. Genellikle uygun bir dizin oluşturarak veya maliyet parametrelerini düzenleyerek sorgu performansını önemli ölçüde artırabilirsiniz.
AFAIK, bir veritabanının veya kümenin tamamını olarak ayarlamanın bir yolu yoktur UNLOGGED. Bunu yapabilmek ilginç olurdu. PostgreSQL posta listesini sormayı düşünün.
Ana bilgisayar işletim sistemi ayarı
İşletim sistemi düzeyinde de yapabileceğiniz bazı ayarlamalar var. Yapmak isteyebileceğiniz en önemli şey, işletim sistemini yazma işlemlerini diske agresif bir şekilde akıtmamaya ikna etmektir, çünkü diske ne zaman / yaptıklarını gerçekten umursamıyorsunuz.
Linux size bu kontrol edebilirsiniz sanal bellek alt sisteminin 'ın dirty_*gibi seçenekleri dirty_writeback_centisecs.
Geri yazma ayarlarının çok gevşek olmasıyla ilgili tek sorun, başka bir program tarafından yapılan bir yıkamanın, tüm PostgreSQL'in biriken arabelleklerinin de temizlenmesine ve her şey yazarken blokların durmasına neden olabilmesidir. PostgreSQL'i farklı bir dosya sisteminde çalıştırarak bunu hafifletebilirsiniz, ancak bazı kızarmalar dosya sistemi düzeyinde değil cihaz düzeyinde veya tüm ana makine düzeyinde olabilir, bu nedenle buna güvenemezsiniz.
Bu ayar, iş yükünüz için neyin en iyi olduğunu görmek için ayarlarla oynamayı gerçekten gerektirir.
Daha yeni çekirdeklerde, vm.zone_reclaim_modePostgreSQL'in yönetme şekliyle etkileşimler nedeniyle NUMA sistemleriyle (günümüzde çoğu sistemde) ciddi performans sorunlarına neden olabileceğinden sıfıra ayarlandığından emin olmak isteyebilirsiniz shared_buffers.
Sorgu ve iş yükü ayarı
Bunlar kod değişiklikleri gerektiren DO şeyler; size uymayabilirler. Bazıları uygulayabileceğiniz şeyler.
Daha büyük işlemlere toplu iş yapmıyorsanız başlayın. Birçok küçük işlem pahalıdır, bu nedenle mümkün olduğunda ve pratik olduğunda bir şeyler topluyor olmalısınız. Zaman uyumsuzluk taahhüdü kullanıyorsanız, bu daha az önemlidir, ancak yine de şiddetle tavsiye edilir.
Mümkünse geçici tablolar kullanın. WAL trafiği oluşturmazlar, bu nedenle ekler ve güncellemeler için çok daha hızlıdırlar. Bazen bir grup veriyi geçici bir tabloya dönüştürmek, ancak gereken şekilde manipüle etmek, ardından INSERT INTO ... SELECT ...son tabloya kopyalamak için bir yapmak gerekir. Geçici tabloların oturum başına olduğunu unutmayın; oturumunuz sona ererse veya bağlantınızı kaybederseniz geçici tablo kaybolur ve başka hiçbir bağlantı bir oturumun geçici tablolarının içeriğini göremez.
PostgreSQL 9.1 veya daha yenisini kullanıyorsanız UNLOGGED, oturum durumu gibi kaybetmeyi göze alabileceğiniz veriler için tabloları kullanabilirsiniz . Bunlar farklı oturumlarda görülebilir ve bağlantılar arasında korunur. Sunucu temiz olmayan bir şekilde kapanırsa kesilirler, böylece yeniden oluşturamayacağınız bir şey için kullanılamazlar, ancak önbellekler, materyalleştirilmiş görünümler, durum tabloları vb.
Genel olarak, yapma DELETE FROM blah;. TRUNCATE TABLE blah;Bunun yerine kullanın ; bir tablodaki tüm satırları boşaltırsanız çok daha hızlı olur. TRUNCATEMümkünse , bir çağrıda birçok tabloyu kısaltın . Yine de TRUNCATEStekrar tekrar birçok küçük masa yapıyorsanız bir uyarı var ; bakınız: Postgresql Kesme hızı
Yabancı anahtarlar üzerinde dizinleriniz yoksa, DELETEbu yabancı anahtarların başvuruda bulunduğu birincil anahtarları içeren anahtarlar çok yavaş olacaktır. DELETEReferans verilen tablolardan beklediğinizde bu tür dizinler oluşturduğunuzdan emin olun . İçin dizinler gerekli değildir TRUNCATE.
İhtiyacınız olmayan dizinler oluşturmayın. Her endeksin bir bakım maliyeti vardır. Çok az sayıda büyük, pahalı çok sütunlu dizin tutmak yerine, çok az sayıda dizin dizini kullanmaya ve bitmap dizin taramasının bunları birleştirmesine izin verin. Dizinler gerektiğinde, önce tabloyu doldurmaya çalışın, ardından sonunda dizinler oluşturun.
Donanım
Eğer tüm veritabanı tutmak için yeterli RAM olması onu yönetebilir eğer büyük bir kazançtır.
Yeterli RAM'iniz yoksa, daha hızlı depolama alanı daha iyi olabilir. Ucuz bir SSD bile, eğirme pası üzerinde büyük bir fark yaratır. Ancak üretim için ucuz SSD'lere güvenmeyin, genellikle güvenli değildir ve verilerinizi yiyebilir.
Öğrenme
Greg Smith'in PostgreSQL 9.0 Yüksek Performans adlı kitabı, biraz daha eski bir versiyona atıfta bulunulmasına rağmen alakalı olmaya devam ediyor. Yararlı bir referans olmalıdır.
PostgreSQL genel posta listesine katılın ve takip edin.
Okuma: