PostgreSQL yavaş işlem performansı


9

PostgreSQL yapılandırmasında bazı sorunlar yaşıyoruz. Bazı kıyaslamalardan sonra, çok basit sorguların nispeten uzun zaman aldığını öğrendim, daha fazla inceleme sonrasında gerçek COMMIT komutunun gerçekten yavaş olduğu görülüyor.

Aşağıdaki tabloyu kullanarak çok basit bir test yaptım:

CREATE TABLE test (
    id serial primary key,
    foo varchar(16),
);

Tüm ifadelerde günlüğe kaydetmeyi açtıktan sonra aşağıdaki sorguyu 10000 kez çalıştırdım:

BEGIN;
INSERT INTO test (a) VALUES ('bar');
COMMIT;

BEGIN ve INSERT tamamlanması <1ms sürüyor, ancak COMMIT tamamlanması ortalama 22ms sürüyor.

Çok daha yavaş olan kendi bilgisayarımda aynı karşılaştırmayı çalıştırmak, BEGIN ve INSERT ifadeleri için aynı ortalamayı verir, ancak ortalama COMMIT yaklaşık 0,4 ms'dir (20 kat daha hızlıdır).

Biraz okuduktan sonra pg_test_fsyncsorunu tespit etmek için aracı denedim . Sunucuda şu sonuçları alıyorum:

$ ./pg_test_fsync -o 1024
1024 operations per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                      14.875 ops/sec
        fdatasync                          11.920 ops/sec
        fsync                              30.524 ops/sec
        fsync_writethrough                            n/a
        open_sync                          30.425 ops/sec

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                      19.956 ops/sec
        fdatasync                          23.299 ops/sec
        fsync                              21.955 ops/sec
        fsync_writethrough                            n/a
        open_sync                           3.619 ops/sec

Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB
in different write open_sync sizes.)
        16kB open_sync write                5.923 ops/sec
         8kB open_sync writes               3.120 ops/sec
         4kB open_sync writes              10.246 ops/sec
         2kB open_sync writes               1.787 ops/sec
         1kB open_sync writes               0.830 ops/sec

Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written
on a different descriptor.)
        write, fsync, close                34.371 ops/sec
        write, close, fsync                36.527 ops/sec

Non-Sync'ed 8kB writes:
        write                           248302.619 ops/sec

Kendi bilgisayarımda:

$ ./pg_test_fsync -o 1024
1024 operations per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                      69.862 ops/sec
        fdatasync                          68.871 ops/sec
        fsync                              34.593 ops/sec
        fsync_writethrough                            n/a
        open_sync                          26.595 ops/sec

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                      26.872 ops/sec
        fdatasync                          59.056 ops/sec
        fsync                              34.031 ops/sec
        fsync_writethrough                            n/a
        open_sync                          17.284 ops/sec

Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB
in different write open_sync sizes.)
        16kB open_sync write                7.412 ops/sec
         8kB open_sync writes               3.942 ops/sec
         4kB open_sync writes               8.700 ops/sec
         2kB open_sync writes               4.161 ops/sec
         1kB open_sync writes               1.492 ops/sec

Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written
on a different descriptor.)
        write, fsync, close                35.086 ops/sec
        write, close, fsync                34.043 ops/sec

Non-Sync'ed 8kB writes:
        write                           240544.985 ops/sec

Sunucunun yapılandırması:

CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
RAM: 32GB
Disk: 2x 2TB SATA disk in Software RAID 1

Karşılaştırma için kullanılan makine, 16 GB RAM ve düz SATA diskleri (baskın yok) olan bir i5'tir.

Daha fazla bilgi:

  • İşletim Sistemi: Ubuntu server 12.10
  • Çekirdek: Linux ... 3.5.0-22-jenerik # 34-Ubuntu SMP Sal 8 Ocak 21:47:00 UTC 2013 x86_64 x86_64 x86_64 GNU / Linux
  • Yazılım RAID 1
  • Dosya sistemi ext4
  • Başka montaj seçeneği belirtilmedi.
  • Postgres sürüm 9.1
  • Linux mdadm baskını

Dump2efs çıktısı:

dumpe2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          16e30b20-0531-4bcc-877a-818e1f5d5fb2
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              182329344
Block count:              729289039
Reserved block count:     36464451
Free blocks:              609235080
Free inodes:              182228152
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      850
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   256
RAID stride:              1
Flex block group size:    16
Filesystem created:       Sat Jan 19 12:42:19 2013
Last mount time:          Wed Jan 23 16:23:11 2013
Last write time:          Sat Jan 19 12:46:13 2013
Mount count:              8
Maximum mount count:      30
Last checked:             Sat Jan 19 12:42:19 2013
Check interval:           15552000 (6 months)
Next check after:         Thu Jul 18 13:42:19 2013
Lifetime writes:          257 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           128
Journal inode:            8
First orphan inode:       17304375
Default directory hash:   half_md4
Directory Hash Seed:      a71fa518-7696-4a28-bd89-b21c10d4265b
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x000df5a4
Journal start:            31733

Mdadm - detay çıktı:

/dev/md2:
        Version : 1.2
  Creation Time : Sat Jan 19 12:42:05 2013
     Raid Level : raid1
     Array Size : 2917156159 (2782.02 GiB 2987.17 GB)
  Used Dev Size : 2917156159 (2782.02 GiB 2987.17 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Fri Mar 22 11:16:45 2013
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : rescue:2
           UUID : d87b98e7:d584a4ed:5dac7907:ae5639b0
         Events : 38

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       8       19        1      active sync   /dev/sdb3

2013-03-25 Güncellemesi : Her iki diskte de uzun bir akıllı test yaptım, bu da sorun göstermedi. Her iki disk de Seagate'ten, model: ST3000DM001-9YN166.

2013-03-27 Güncellemesi : En son sürümün (9.2.3) pg_test_fsync'ini tamamen boş bir makinede çalıştırdım:

$ ./pg_test_fsync -s 3
3 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                      39.650 ops/sec
        fdatasync                          34.283 ops/sec
        fsync                              19.309 ops/sec
        fsync_writethrough                            n/a
        open_sync                          55.271 ops/sec

Eskisinden biraz daha iyi, ama yine de içler acısı. Her iki diskteki bölümler hizalanır:

$ sudo parted /dev/sdb unit s print
Model: ATA ST3000DM001-9YN1 (scsi)
Disk /dev/sdb: 5860533168s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start      End          Size         File system  Name  Flags
 4      2048s      4095s        2048s                           bios_grub
 1      4096s      25169919s    25165824s                       raid
 2      25169920s  26218495s    1048576s                        raid
 3      26218496s  5860533134s  5834314639s                     raid

Mount -v çıkışı:

$ mount -v | grep ^/dev/
/dev/md2 on / type ext4 (rw,noatime)
/dev/md1 on /boot type ext3 (rw)

Testler için md2 cihazı kullanılıyor. Takas bölümünü yok edecek ve ayrı disklerde pg_test_fsync çalıştıracak.

Her iki diskte de ayrı ayrı pg_test_fsync çalıştırırsam, kabaca aynı performansı elde ederim, bölüm noatime ile monte edildi:

$ pg_test_fsync/pg_test_fsync -s 3

3 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                      75.111 ops/sec
        fdatasync                          71.925 ops/sec
        fsync                              37.352 ops/sec
        fsync_writethrough                            n/a
        open_sync                          33.746 ops/sec

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                      38.204 ops/sec
        fdatasync                          49.907 ops/sec
        fsync                              32.126 ops/sec
        fsync_writethrough                            n/a
        open_sync                          13.642 ops/sec

Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB
in different write open_sync sizes.)
         1 * 16kB open_sync write          25.325 ops/sec
         2 *  8kB open_sync writes         12.539 ops/sec
         4 *  4kB open_sync writes          6.207 ops/sec
         8 *  2kB open_sync writes          3.098 ops/sec
        16 *  1kB open_sync writes          1.208 ops/sec

Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written
on a different descriptor.)
        write, fsync, close                27.275 ops/sec
        write, close, fsync                20.561 ops/sec

Non-Sync'ed 8kB writes:
        write                           562902.020 ops/sec

Testi hem dizide hem de tek diskte birkaç kez çalıştırdıktan sonra, sayılar çılgınca değişiyor gibi görünüyor. En kötü durum, burada yayınladığımın yaklaşık% 50'sidir (ilk test için 30 ops / s civarında bir yerde.) Bu normal mi? Makine her zaman tamamen boşta.

Ayrıca, dmesg çıkışına göre kontrolör AHCI modundadır.


Bu yazılım RAID'i hakkında bazı ayrıntılar verebilir misiniz? Hangi yazılım? Linux mdadmveya dmraid? Satıcıya özgü bir şey mi? Başka bir şey? PostgreSQL sürümünüz ve ana işletim sistemi sürümünüz de yardımcı olacaktır.
Craig Ringer

Yanıtlar:


6

Sunucu inanılmaz, açıklanamayan, inanılmaz derecede yavaş bir fsyncperformansa sahip. Yazılım RAID 1 kurulumunuzda çok kötü bir şey var. Korkunç fsyncperformans neredeyse kesinlikle performans sorunlarınızın sebebidir.

Masaüstü sadece çok yavaş fsync.

Sen ayarlayarak kazadan sonra bazı verileri kaybetme pahasına performans sorunları çalışabilirsiniz synchronous_commit = offve bir ayar commit_delay. Sen gerçekten o çenesi droppingly yavaş olsa da, sunucuda disk performansını sıralamak gerekir.

Karşılaştırma için, dizüstü bilgisayarımda aldığım şey (i7, 8GB RAM, orta sınıf 128G SSD, 9.2'den pg_test_fsync):

Compare file sync methods using one 8kB write:

        open_datasync                    4445.744 ops/sec
        fdatasync                        4225.793 ops/sec
        fsync                            2742.679 ops/sec
        fsync_writethrough                            n/a
        open_sync                        2907.265 ops/sec

Kuşkusuz bu SSD muhtemelen güç-güç-kaybı-güvenli değil, ama sunucu maliyetlerinden bahsederken iyi bir güç-arıza-güvenli SSD'nin büyük bir maliyeti olmadığı gibi.


1
Evet, ama kötü fsync performansına ne sebep oluyor?
Blubber

Kendi SSD'imde pg_test_fsync çalıştırmayı denedim ve karşılaştırılabilir performans rakamları elde ediyorum. Senkronizasyon işlemlerini devre dışı bırakabileceğimi biliyorum, ancak soru devam ediyor, bu sorunun nedeni nedir?
Blubber

@Blubber Hangi RAID yazılımını kullanıyorsunuz? Hangi dosya sistemi? Hangi ana bilgisayar işletim sistemi ve sürümü? Hangi dosya sistemi bağlama seçenekleri? Bunların hepsi kök nedeni araştırıyorsanız kritik bilgilerdir; lütfen sorunuzu güncelleyin. Ayrıca sabit diskler SMART sağlık kontrolleri yapmak (gerektiğini smartctl -d ata -a /dev/sdx|lessve smartctl -d ata -t long /dev/sdxardından bir tarafından sleep 90mya da her türlü smartctlbaşka izledi söyler -d ata -asonuçları almak için).
Craig Ringer

Eğer RAID sorunları gidermek @Blubber bile performans hala oldukça kötü olacaktır olarak bad. Sade eski 7200RPM (veya daha kötüsü 5400RPM) diskler , özellikle denetleyicinin gruplandırmasına ve arabellek yazmasına olanak tanıyan, pil destekli önbelleğe sahip uygun bir donanım RAID denetleyicisi olmadan veritabanı performansı için kötü bir seçimdir.
Craig Ringer

Soruyu dosya sistemi ve raid config hakkında daha fazla ayrıntıyla güncelledim. Bu makinenin mevcut yapılandırmasında asla çok iyi bir performans vermeyeceğini anlıyorum. Ancak mevcut performans gerçekten kötü.
Blubber

1

Bu, pg_test_fsyncsunucumda çok benzer yapılandırmayla çıktı - 2 tüketici sınıfı diskte Linux yazılımı RAID1 ( WD10EZEX-00RKKA0):

# ./pg_test_fsync -s 3
Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                     115.375 ops/sec
        fdatasync                         109.369 ops/sec
        fsync                              27.081 ops/sec
        fsync_writethrough                            n/a
        open_sync                         112.042 ops/sec
...

Bunu tamamen boş sunucuda test ettiniz, değil mi?


Belki ayrılmamış bölümleriniz var. Kontrol:

parted /dev/sda unit s print

Bu sunucumun çıktısı:

Model: ATA WDC WD10EZEX-00R (scsi)
Disk /dev/sda: 1953525168s
Sector size (logical/physical): 512B/4096B
Partition Table: msdos

Number  Start       End          Size         Type     File system     Flags
 1      2048s       67110911s    67108864s    primary  ext4            boot, raid
 2      67110912s   603981823s   536870912s   primary                  raid
 3      603981824s  608176127s   4194304s     primary  linux-swap(v1)
 4      608176128s  1953523711s  1345347584s  primary                  raid

StartSütundaki her sayının 2048 ile bölünebilir olduğunu kontrol edin (1MiB anlamına gelir). İyi 4096B için 4'e bölünebilir hizalama yeterli olacaktır, ancak hizalama farkında yardımcı programlar 1MiB sınırlarında bölümler başlatır.


Ayrıca data=journal, performans üzerinde büyük etkisi olan varsayılan olmayan bağlama seçeneklerini de kullanıyor olabilirsiniz . Şovunuz: mount -v | grep ^/dev/. Bu benim:

/dev/md0 on / type ext4 (rw,barrier,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0)
/dev/md2 on /home type ext4 (rw,barrier,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0)
/dev/md1 on /var type ext4 (rw,barrier,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0)

Belki disklerinizden biri bozuk. RAID olmadan her diskte bir bölüm oluşturun (belki her iki diskte de bazı swap bölümleri ayırdınız - bunları kullanın - yine de takasta RAID için bir kullanım yoktur). Orada dosya sistemleri oluşturun ve pg_test_fsyncher sürücüde çalışın - eğer bir problem varsa iyi bir tane her ikisi de yansıtıldığında onu beklemek zorunda kalacaktır.


BIOS'unuzun IDE modu yerine AHCI modunu kullanacak şekilde ayarlandığını kontrol edin. Bir sunucu IDE modunda bulunmayan Yerel Komut Kuyruğundan yararlanır .


SSD ile karşılaştırmayı yoksayın. Karşılaştırmak saçma.


İyi performans gösteren (normal sata disklerinden beklediğiniz kadar iyi) bonnie ++ çalıştırdım. Ayrıca, bölümler hizalanır. Ben bir VM üzerinde ilk kez pg_test_fsync koştum. Sonra diğer tüm işlemleri (VM'ler dahil) kapattıktan sonra gerçek donanımda çalıştırdım. Performans biraz daha iyiydi, yaklaşık 40 ops / sn. Bugün zamanım olursa ayrı bölümlerde biraz daha test yapacağım. Tüm önerileriniz için teşekkürler.
Blubber

Orijinal sorumu takma seçenekleri ve bölüm hizalama hakkında ek bilgilerle değiştirdim.
Blubber

1

Bunu cevaplamak için çok geç olabileceğimi biliyorum. O_DIRECT kullanırken PostgreSQL ve MySQL ile benzer performans sorunları görüyorum. Senkronize yazma (- + r seçeneği) ve O_DIRECT (-I seçeneği) ile ve olmadan iozon kullanarak sistemi mikro olarak karşılaştırdım. Kullandığım iki komut aşağıdadır:

iozone -s 2g -r 512k -+r -I -f /mnt/local/iozone_test_file -i 0

ve

iozone -s 2g -r 512k -+r    -f /mnt/local/iozone_test_file -i 0

Birincisi O_SYNC + O_DIRECT, ikincisi sadece O_SYNC. Birincisi yaklaşık 30MB / sn ve ikincisi yaklaşık 220MB / sn (SSD sürücü) alıyordum. Ne buldum soruna neden ext4 dikiş has_journal seçeneği oldu. Neden bilmiyorum ...

Filesystem features:      has_journal 

Bu seçeneği çıkardığımda işler iyi çalışmaya başladı, her iki test de 220MB / saniyeye ulaştı ve devam etti. Seçeneği çıkarmak için aşağıdaki gibi bir şey kullanabilirsiniz:

tune2fs -O ^has_journal /dev/sdX

Bunu test edebilir ve performans sorunlarınızı çözüp çözmediğini görebilirsiniz.


1
Derginin ext3 / 4'te devre dışı bırakılması, dikkatli bir değerlendirme ve etkinin çok iyi anlaşılması olmadan yapılacak bir şey değildir.
ThatGraemeGuy

2
Katılmıyorum. Bir DBMS, işlemlerin dayanıklılığını ve atomikliğini sağlamak için kendi günlük kaydını ve kurtarmasını yapar. FS dergisi bu bakımdan tamamen işe yaramaz. Fsync düzgün çalıştığı sürece, taahhüt edilen işlemlerin etkileri her zaman geri yüklenebilir.
Caetano Sauer
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.