Neden PostgreSQL sorguları, ilk istekte sonraki istekler sırasında ilk istekte daha yavaştır?

Question

Neden PostgreSQL sorguları, ilk istekte, sonraki istekler sırasındaki ilk istekte daha yavaştır?

Postgresql veritabanına bağlanmak için birkaç farklı teknolojiyi kullanma. İlk istek 1,5 saniye sürebilir. Tam olarak aynı sorgu ikinci kez .03 saniye sürecektir. Uygulamamın ikinci bir örneğini (aynı veritabanına bağlanıyor) açın ve ilk istek 1.5 saniye ve ikinci .03 saniyeyi alır.

Kullandığımız farklı teknolojiler nedeniyle farklı noktalara bağlanıyor ve farklı bağlantı yöntemleri kullanıyorlar, bu yüzden yazdığım herhangi bir kodla ilgili bir şey olduğunu düşünmüyorum.

Bağlantı açmanın, ilk istek alana kadar 'her şey' yapamayacağını düşünüyorum. Bu nedenle, isteğin bazı ek yükü vardır.

Veritabanını kullandım ve sunucuyu her şey bellekte tuttuğundan dizin ve benzeri bir sorun olmamalıdır.

Düzenle Açıklayıcı - sorguyu anlatır ve dürüstçe sorguyu oldukça iyi gösterir (dizinlenmiş, vb.). Gerçekten de postgresql'in yeni bir bağlantının ilk sorgusunda bir çeşit yükü olduğunu düşünüyorum.

Bunu nasıl kanıtlayacağımı/onaylayacağımı bilmiyorum. PG Admin III (pgAdmin sürüm 1.12.3) kullansaydım, tüm sorgular hızlı görünüyor. İlk sorguya sahip olduğum diğer araçlardan herhangi biri yavaş. Çoğu zaman fark edilmeyecek kadar yavaş değil ve eğer her zaman koçu indeksle güncellemeye karar verdim. Ama bu kesinlikle böyle değil. Araçlarımı açarsam ve sonuçları döndüren başka bir sorgu yaparsam ikinci sorgu çok hızlı olmaz. İlk sorgu sonuç vermezse, ikincisi hala yavaş, sonra üçüncü hızlıdır. Ben sorguyu sanmıyorum rağmen

düzenlemek 2 gecikmeyle ilgisi var burada açıklayın çalışmasını iki sonuç

EXPLAIN ANALYZE 
select * from company 
where company_id = 39 

(ANALİZ AÇIKLAYINIZ) vardır (her ilk sorgu yavaş) Çıktı:

"Seq Scan on company (cost=0.00..1.26 rows=1 width=54) (actual time=0.037..0.039 rows=1 loops=1)" 
" Filter: (company_id = 39)" 
"Total runtime: 0.085 ms" 

ve:

EXPLAIN ANALYZE 
select * from group_devices 
where device_name ilike 'html5_demo' 
and group_id in (select group_id from manager_groups 
where company_id in (select company_id from company where company_name ='TRUTHPT')) 

çıkışı:

"Nested Loop Semi Join (cost=1.26..45.12 rows=1 width=115) (actual time=1.947..2.457 rows=1 loops=1)" 
" Join Filter: (group_devices.group_id = manager_groups.group_id)" 
" -> Seq Scan on group_devices (cost=0.00..38.00 rows=1 width=115) (actual time=0.261..0.768 rows=1 loops=1)" 
"  Filter: ((device_name)::text ~~* 'html5_demo'::text)" 
" -> Hash Semi Join (cost=1.26..7.09 rows=9 width=4) (actual time=0.297..1.596 rows=46 loops=1)" 
"  Hash Cond: (manager_groups.company_id = company.company_id)" 
"  -> Seq Scan on manager_groups (cost=0.00..5.53 rows=509 width=8) (actual time=0.003..0.676 rows=469 loops=1)" 
"  -> Hash (cost=1.26..1.26 rows=1 width=4) (actual time=0.035..0.035 rows=1 loops=1)" 
"    Buckets: 1024 Batches: 1 Memory Usage: 1kB" 
"    -> Seq Scan on company (cost=0.00..1.26 rows=1 width=4) (actual time=0.025..0.027 rows=1 loops=1)" 
"     Filter: ((company_name)::text = 'TRUTHPT'::text)" 
"Total runtime: 2.566 ms" 

Answer 1

İlk isteği arabelleklerine diskten blokları okuyacaktır. İkinci istek, arabelleklerden okuyacaktır.

Kaç bağlantı yapıldığı önemli değil, sonuç, bu sorgunun zaten ayrıştırılıp ayrılmamış olmasına bağlıdır.

Unutmayın ki değişmezler, sorgusunu yeniden değerlendirecektir. Ayrıca, sorgu bir süredir çalıştırılmamışsa, birçok değişkene bağlı olarak fiziksel okumaların hala devam edebileceğini unutmayın.