PostgreSQL 9.1.2 kullanarak
Aşırı CPU kullanımı ve postmaster görevlerden diske büyük miktarda yazma görüyorum. Bu benim uygulama neredeyse hiçbir şey (MINUTE başına 10s) yaparken bile olur. Bununla birlikte, makul sayıda bağlantı açıktır.
Uygulamamda buna neyin sebep olduğunu belirlemeye çalışıyorum. Postgresql ile oldukça yeniyim ve şimdiye kadar hiçbir yere ulaşmadım. Yapılandırma dosyamdaki bazı günlük seçeneklerini açtım ve pg_stat_activity tablosundaki bağlantılara baktım, ancak hepsi boş. Yine de her bağlantı ~% 50 CPU tüketir ve diske ~ 15M / s yazar (hiçbir şey okumaz).
Temelde çok az tweaks ile hisse senedi postgresql.conf kullanıyorum. Bunu izlemek için neler yapabileceğime dair herhangi bir tavsiyeye veya işaretçiye teşekkür ederim.
İşte top / iotop'un bana gösterdiği şeyin bir örneği:
Cpu(s): 18.9%us, 14.4%sy, 0.0%ni, 53.4%id, 11.8%wa, 0.0%hi, 1.5%si, 0.0%st
Mem: 32865916k total, 7263720k used, 25602196k free, 575608k buffers
Swap: 16777208k total, 0k used, 16777208k free, 4464212k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17057 postgres 20 0 236m 33m 13m R 45.0 0.1 73:48.78 postmaster
17188 postgres 20 0 219m 15m 11m R 42.3 0.0 61:45.57 postmaster
17963 postgres 20 0 219m 16m 11m R 42.3 0.1 27:15.01 postmaster
17084 postgres 20 0 219m 15m 11m S 41.7 0.0 63:13.64 postmaster
17964 postgres 20 0 219m 17m 12m R 41.7 0.1 27:23.28 postmaster
18688 postgres 20 0 219m 15m 11m R 41.3 0.0 63:46.81 postmaster
17088 postgres 20 0 226m 24m 12m R 41.0 0.1 64:39.63 postmaster
24767 postgres 20 0 219m 17m 12m R 41.0 0.1 24:39.24 postmaster
18660 postgres 20 0 219m 14m 9.9m S 40.7 0.0 60:51.52 postmaster
18664 postgres 20 0 218m 15m 11m S 40.7 0.0 61:39.61 postmaster
17962 postgres 20 0 222m 19m 11m S 40.3 0.1 11:48.79 postmaster
18671 postgres 20 0 219m 14m 9m S 39.4 0.0 60:53.21 postmaster
26168 postgres 20 0 219m 15m 10m S 38.4 0.0 59:04.55 postmaster
Total DISK READ: 0.00 B/s | Total DISK WRITE: 195.97 M/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
17962 be/4 postgres 0.00 B/s 14.83 M/s 0.00 % 0.25 % postgres: aggw aggw [local] idle
17084 be/4 postgres 0.00 B/s 15.53 M/s 0.00 % 0.24 % postgres: aggw aggw [local] idle
17963 be/4 postgres 0.00 B/s 15.00 M/s 0.00 % 0.24 % postgres: aggw aggw [local] idle
17188 be/4 postgres 0.00 B/s 14.80 M/s 0.00 % 0.24 % postgres: aggw aggw [local] idle
17964 be/4 postgres 0.00 B/s 15.50 M/s 0.00 % 0.24 % postgres: aggw aggw [local] idle
18664 be/4 postgres 0.00 B/s 15.13 M/s 0.00 % 0.23 % postgres: aggw aggw [local] idle
17088 be/4 postgres 0.00 B/s 14.71 M/s 0.00 % 0.13 % postgres: aggw aggw [local] idle
18688 be/4 postgres 0.00 B/s 14.72 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
24767 be/4 postgres 0.00 B/s 14.93 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
18671 be/4 postgres 0.00 B/s 16.14 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
17057 be/4 postgres 0.00 B/s 13.58 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
26168 be/4 postgres 0.00 B/s 15.50 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
18660 be/4 postgres 0.00 B/s 15.85 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
Güncelleme : Dosya yazma işlemlerinin çoğu $ PG_DATA / base / dizinindeki geçici (?) Dosyalara benziyor. Anladığım kadarıyla burada dosya yapısının her bir tablo temelde Adını tablosunun OSB olan bir dosya olarak saklanır olmasıdır. Bununla birlikte, adlandırılmış tonlarca dosya vardır tnn_nnnnnnnve bu dosyalar sürekli olarak yazılıyor (belki de yazılmıştır). Bu dosyalar ne için? Dosyaların ~ 4700 tanesi var ve hepsi 8K boyutunda:
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t12_1430975
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t16_1432736
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t28_1439066
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t24_1436243
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t24_1436210
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t19_1393372
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t28_1439051
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t8_1430334
Güncelleme : Postmaster süreçlerinde strace çalıştırmak temelde birçok dosya G / Ç öğesi gösterir:
open("base/16388/t24_1435947_fsm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435947_vm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435947", O_RDWR) = 9
lseek(9, 0, SEEK_END) = 8192
ftruncate(9, 0) = 0
lseek(9, 0, SEEK_END) = 0
open("base/16388/t24_1435941", O_RDWR) = 18
lseek(18, 0, SEEK_END) = 0
write(9, "\0\0\0\0\0\0\0\0\1\0\0\0000\0\360\37\360\37\4 \0\0\0\0b1\5\0\2\0\0\0"..., 8192) = 8192
lseek(18, 0, SEEK_END) = 0
close(9) = 0
open("base/16388/t24_1435947", O_RDWR) = 9
lseek(9, 0, SEEK_END) = 8192
close(18) = 0
close(9) = 0
open("base/16388/t24_1435944_fsm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435944_vm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435944", O_RDWR) = 9
lseek(9, 0, SEEK_END) = 0
close(9) = 0
Güncelleme : Yani bu sorun geçici tablolarla ilgili her şey gibi görünüyor. Geçici tabloların 'normal' tablolar olması ve tüm disk etkinliği ortadan kalkması ve performansın beklediğim yere geri dönmesi için kurulumumuzu değiştirdik. Şimdi, bu değişiklik sadece hızlı ve kirli bir testti: normal tabloları kullanmak için gerçekten değişeceksek, eşzamanlılık ve temizleme ile ilgili sorunlarımız var. Geçici tablolar gerçekten bu kadar kötü mü yoksa onları kötüye kullanıyor muyuz?
Güncelleme : Biraz daha arka plan. Kurum içi geliştirilmiş bir deyim tabanlı çoğaltma ara katmanı kullanıyorum . Oldukça olgun ve birkaç yıldır birçok projede kullanılıyor, ancak MySQL kullanıyor. PostgreSQL ile sadece son bir iki yıldır çalışıyoruz. Aslında geçici tabloları çoğaltma mekanizmasının bir parçası olarak kullanıyorduk. Yeni bir bağlantı kurulduğunda, veritabanındaki her tablo için geçici bir tablo oluştururuz. 10-20 (uzun ömürlü) bağlantılar ve ~ 50 tablo ile, bu çok fazla geçici tablo anlamına gelebilir. Tüm geçici tablolar şunlarla oluşturuldu:
CREATE TEMPORARY TABLE... ON COMMIT DELETE ROWS;
Geçici tabloların semantiği, çoğaltma şemamıza çok iyi uyuyor ve MySQL için kullanmamız gereken kodun çoğunu basitleştirdi, ancak uygulama da adil değildi. Yaptığım araştırmalardan, geçici tabloların gerçekten onları kullandığımız işlev için tasarlandığını düşünmüyorum.
Ben bu konuda şirket içi uzman değilim (yakın bile değil), sadece bir kullanıcı, bu yüzden açıklamam% 100 doğru olmayabilir, ama bence oldukça yakın.