PostgreSQL pg_stat_activity COMMIT değerini gösteriyor

Son zamanlarda veritabanı sunucumuzu, 4 x dört çekirdekli CPU'lar ve 32Gb ram ile yükseltilmiş bir makine ile değiştirdik. Eski kutumuzu, çoğaltma akışıyla bir köle olarak hizmet etmek için de yeniden tasarladık. Her iki kutu da CentOS 6.3 ve PostgreSQL 9.2 çalıştırıyor. Postgres, kutuların her birinde çalışan tek şeydir.

Bu yapılandırma yaklaşık bir aydır yürürlüktedir, aniden trafik artmaya başladığında bazı sorunlarla karşılaştık. Görmeye başladığımız zaman zaman son derece yüksek bir CPU yüküdür (üstte 270 ortalama yük ortalaması gösterilir) ve bakabildiğimizde pg_stat_activitybağlantılarımızın çoğunun COMMITdurumda olduğunu göreceğiz . Yalnız bırakıldığında, bu sonunda bitecek ve sistem, bağlantıların oluşmasıyla yanıt verecektir.IDLE . Sorunun bu olup olmadığını görmek için çoğaltmayı devre dışı bırakmayı denedik, ancak sorun hala devam ediyor.

Neler olduğunu teşhis etmeye çalıştık ve biraz kaybolduk. Çalışmanın sonucu perfaşağıdakine benzer bir şey gösterir ve neyi 0x347ba9temsil ettiği hakkında hiçbir fikrim yok .

+  41.40%       48154  postmaster  0x347ba9         f 0x347ba9                                   ◆
+   9.55%       10956  postmaster  0x2dc820         f set_config_option                          ▒
+   8.64%        9946  postmaster  0x5a3d4          f writeListPage     
+   5.75%        6609  postmaster  0x5a2b0          f ginHeapTupleFastCollect                    ▒
+   2.68%        3084  postmaster  0x192483         f build_implied_join_equality                ▒
+   2.61%        2990  postmaster  0x187a55         f build_paths_for_OR                         ▒
+   1.86%        2131  postmaster  0x794aa          f get_collation_oid                          ▒
+   1.56%        1822  postmaster  0x5a67e          f ginHeapTupleFastInsert                     ▒
+   1.53%        1766  postmaster  0x1929bc         f distribute_qual_to_rels                    ▒
+   1.33%        1558  postmaster  0x249671         f cmp_numerics

Uygulama tarafından gerçekleştirilen sorguların hiçbiri özellikle karmaşık değildir, açıklama planları en fazla 1 saniye sürmektedir (çoğu daha hızlıdır). Buna ek olarak, bu trafik toplanmaya başladığında olsa da, büyük bir trafik yükünden bahsetmiyoruz (Eski makine bunu kolayca idare edebiliyordu).

Bu noktada, bir sonraki adımda ne denemem gerektiği konusunda biraz şaşırdım. Herhangi bir yardım veya öneri takdir edilecektir. Yardımcı olacak herhangi bir ek bilgi varsa, sadece sorun ve soruyu değiştirebilirim.

Disk Yapılandırması:

Perc 6i RAID Denetleyicisi
5 x 146 GB 15K SAS sürücü
WAL için 2x146GB RAID-1 ve Sistem ve Veriler için 3x146GB RAID-5 olarak yapılandırıldı

Güncelleme:

Sistem normal çalıştığında ve CPU açıldığında VMStat çıkışı aşağıdadır. Bir sorun olduğunda, kesintiler hızla artmaktadır.

Normal çalışma sırasında:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 18938590 303763 21947154    0    0    28    52 7466 12649  2  1 97  0  0   2013-01-14 16:03:25 EST
 0  0      0 18938396 303763 21947154    0    0     0    19 7107 12679  2  0 98  0  0   2013-01-14 16:03:35 EST
 1  0      0 18938904 303763 21947162    0    0     0    54 7042 12708  1  1 99  0  0   2013-01-14 16:03:45 EST
 1  0      0 18938520 303763 21947260    0    0    33    66 7120 12738  1  1 99  0  0   2013-01-14 16:03:55 EST

CPU kullanımı yüksek olduğunda:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
343 0      0 32680468 226279 11339612    0    0     0   214 26692 12225 80  20  0  0  0   2013-01-11 16:45:53 EST
374 1      0 32673764 226291 11340345    0    0     0    77 54893 11572 80  20  0  0  0   2013-01-11 16:46:03 EST
383 0      0 32616620 226304 11340956    0    0     0   102 55540 12922 82  18  0  0  0   2013-01-11 16:46:13 EST
315 0      0 32602038 226320 11341378    0    0     0    79 54539 12441 82  18  0  0  0   2013-01-11 16:46:23 EST

postgresql

— jcern
kaynak

Yeni kutunun ne tür diskleri var? Bu her iki düğümde mi, yoksa sadece birinde mi?

— Trygve Laugstøl

@trygvis - Soruyu disk özellikleriyle güncelledim. Sorun Ana düğümde oluyor. Köle ve doğrudan trafiğini tanıtmaya çalışmadım, bu yüzden aynı koşullar altında orada bir sorun olup olmadığından emin değilim. Bir köle olarak, makine herhangi bir sorun yaşamıyor gibi görünüyor.

— jcern

perfBazı sistem çapında profiller ve bazı PostgreSQL profilleme yapmak için aracı kullanmayı düşünün . CPU kullanımının nerede gerçekleştiğini görün. BTW, 2'nizin biçimlendirmesi vmstatumutsuzca karıştırılıyor ve ilkinin sütunları yanlış hizalanmış, bu yüzden okunması zor. Bir commit_delayşey eklemenin iyileştirip iyileştirmediğini test edin . RAID denetleyicinizde pil destekli geri yazma önbelleği olup olmadığını kontrol edin ve yoksa bir tane alın. Çok zaman harcanıyor iowaitmu? Bu görünür , bazı raporlarda CPU kullanımı , ancak gerçekte değil.

— Craig Ringer

@CraigRinger denetleyicinin pil destekli yazma önbelleği var ve şu anda etkin. Iostattan beklemek tek veya düşük çift haneli kaldı. Perf ile biraz daha profillemeyi denemeye devam edeceğiz. İkinci VMStat'ın biçimlendirmesini de düzelttim, işaret ettiğiniz için teşekkür ederim.

— jcern

Daha fazla teşhis ve bir miktar Google'dan sonra , yaşadığımız aynı semptomların çoğunu açıklayan bu makaleye rastladık . Sorunlarının temel nedeni (ve bizim de anlatabildiğimiz kadarıyla) Transparent Huge Pagesuygulama ile ilgiliydi .

Transparent Huge PagesBu komutla devre dışı bıraktıktan sonra :

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

Sorun çözülmüş gibi görünüyor. Son iki haftadır artan bir iş yükü altında çalışıyoruz ve sorun yeniden ortaya çıkmadı. Sistemin bağlamları ve kesintileri sürekli olarak bulunduklarının 1 / 10'u kadardır ve ortalama sistem süresi de azalmıştır.

Herkes için çözüm olup olmadığından emin değilim, ancak başkalarının benzer bir sorunu çözmesine yardımcı olması durumunda bunu olası bir neden olarak gönderiyorum.

— jcern
kaynak