PostgreSQL memperlambat kinerja komit

9

Kami mengalami beberapa masalah dengan konfigurasi PostgreSQL. Setelah beberapa tolok ukur saya menemukan bahwa permintaan yang sangat sederhana membutuhkan waktu yang relatif lama, setelah pemeriksaan lebih lanjut tampak bahwa perintah COMMIT yang sebenarnya sangat lambat.

Saya menjalankan tes yang sangat sederhana menggunakan tabel berikut:

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

Setelah mengaktifkan logging pada semua pernyataan, saya menjalankan permintaan berikut 10.000 kali:

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

BEGIN dan INSERT menyelesaikan <1 ms untuk menyelesaikan, tetapi KOMIT mengambil rata-rata 22 ms untuk menyelesaikan.

Menjalankan patokan yang sama pada PC saya sendiri, yang jauh lebih lambat, menghasilkan rata-rata yang sama untuk pernyataan BEGIN dan INSERT, tetapi rata-rata COMMIT adalah sekitar 0,4 ms (lebih dari 20 kali lebih cepat.)

Setelah membaca beberapa kali saya mencoba pg_test_fsyncalat untuk mencoba menjabarkan masalahnya. Di server saya mendapatkan hasil ini:

$ ./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

Di PC saya sendiri saya mendapatkan:

$ ./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

Konfigurasi server:

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

Mesin yang digunakan untuk perbandingan adalah i5 dengan 16GB RAM dan disk SATA biasa (tidak ada serangan).

Info lebih lanjut:

  • OS: Server Ubuntu 12.10
  • Kernel: Linux ... 3.5.0-22-generik # 34-Ubuntu SMP Sel 8 Jan 21:47:00 UTC 2013 x86_64 x86_64 x86_64 GNU / Linux
  • RAID Perangkat Lunak 1
  • Filesystem adalah ext4
  • Tidak ada opsi pemasangan lain yang ditentukan.
  • Postgres versi 9.1
  • Linux mdadm raid

Output dari dump2efs:

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 - output detail:

/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

Pembaruan 2013-03-25 : Saya menjalankan tes cerdas lama pada kedua disk, yang mengungkapkan tidak ada masalah. Kedua disk berasal dari Seagate, model: ST3000DM001-9YN166.

Pembaruan 2013-03-27 : Saya menjalankan pg_test_fsync versi terbaru (9.2.3) pada mesin yang benar-benar idle:

$ ./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

Ini sedikit lebih baik dari sebelumnya, tetapi masih menyedihkan. Partisi pada kedua disk diselaraskan:

$ 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 output:

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

Perangkat md2 digunakan untuk pengujian. Pergi untuk menghancurkan partisi swap dan menjalankan pg_test_fsync pada disk individu.

Jika saya menjalankan pg_test_fsync pada kedua disk secara terpisah, saya mendapatkan kinerja yang kurang lebih sama, partisi itu dipasang dengan noatime:

$ 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

Setelah menjalankan tes beberapa kali, baik pada array dan pada disk tunggal, angka-angka tersebut tampaknya sangat bervariasi. Kasus terburuk kinerjanya sekitar 50% dari apa yang saya posting di sini (sekitar 30 ops / s untuk tes pertama.) Apakah ini normal? Mesin benar-benar idle, sepanjang waktu.

Juga, sesuai dengan output dmesg, controller berada dalam mode AHCI.

linux performance postgresql hard-drive Lapisan lemak
sumber
Bisakah Anda memberikan beberapa detail pada RAID perangkat lunak itu? Perangkat lunak apa? Linux mdadmatau dmraid? Sesuatu yang spesifik vendor? Sesuatu yang lain Versi PostgreSQL Anda dan versi host OS akan membantu juga.
Craig Ringer

Jawaban:

6

Server memiliki fsynckinerja yang luar biasa, tidak terkatakan, dan sangat lambat . Ada sesuatu yang sangat salah dengan pengaturan RAID 1 perangkat lunak Anda. fsyncPerforma yang buruk hampir pasti merupakan penyebab masalah kinerja Anda.

Desktop hanya memiliki sangat lambat fsync.

Anda dapat mengatasi masalah kinerja dengan mengorbankan beberapa data setelah macet dengan menyetel synchronous_commit = offdan mengatur a commit_delay. Anda benar - benar perlu memilah-milah kinerja disk di server, meskipun, itu sangat lambat.

Sebagai perbandingan, inilah yang saya dapatkan di laptop saya (i7, 8GB RAM, mid-range 128G SSD, pg_test_fsync dari 9.2):

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

Memang SSD ini mungkin bukan hard-power-loss-safe, tetapi tidak seperti SSD yang layak daya-fail-safe yang harganya sangat mahal ketika kita berbicara tentang biaya server.

Craig Ringer
sumber
1
Ya, tetapi apa yang menyebabkan kinerja fsync buruk?
Blubber
Saya mencoba menjalankan pg_test_fsync pada SSD saya sendiri, dan saya mendapatkan angka kinerja yang sebanding. Saya tahu bahwa saya dapat menonaktifkan komitmen sinkronisasi, tetapi pertanyaannya tetap, apa penyebab masalah ini?
Blubber
@ Blubber RAID perangkat lunak apa yang Anda gunakan? Sistem file apa? Apa host OS dan versi? Opsi pemasangan sistem file apa? Ini semua adalah informasi penting jika Anda mencari akar penyebabnya; harap perbarui pertanyaan Anda. Anda juga harus melakukan pemeriksaan kesehatan SMART pada hard drive ( smartctl -d ata -a /dev/sdx|lessdan smartctl -d ata -t long /dev/sdxdiikuti oleh sleep 90matau apa pun yang smartctlmemberitahu Anda diikuti oleh orang lain -d ata -auntuk mendapatkan hasilnya).
Craig Ringer
@Blubber Bahkan jika Anda memperbaiki masalah RAID kinerja Anda masih akan buruk, hanya saja tidak cukup sebagai buruk. Disk 7200RPM (atau, lebih buruk, 5400RPM) biasa adalah pilihan yang buruk untuk kinerja basis data, terutama tanpa pengontrol RAID perangkat keras yang tepat dengan cache yang didukung baterai yang memungkinkan grup pengontrol dan penyangga menulis.
Craig Ringer
Saya telah memperbarui pertanyaan dengan rincian lebih lanjut tentang sistem file dan konfigurasi serangan. Saya mengerti bahwa mesin ini tidak akan pernah memberikan kinerja yang sangat baik dalam konfigurasi saat ini. Tetapi kinerja saat ini benar - benar buruk.
Blubber
1

Ini adalah pg_test_fsyncoutput di server saya, dengan konfigurasi yang sangat mirip - perangkat lunak Linux RAID1 pada 2 disk tingkat konsumen ( 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
...

Anda sudah menguji ini di server yang benar-benar siaga, bukan?

Mungkin Anda memiliki partisi yang tidak selaras. Memeriksa:

parted /dev/sda unit s print

Ini adalah output dari server saya:

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

Periksa bahwa setiap angka dalam Startkolom dapat dibagi pada tahun 2048 (yang berarti 1MiB). Untuk penyelarasan 4096B yang baik dibagi dengan 4 sudah cukup, tetapi utilitas penyelarasan mulai partisi pada batas 1MiB.

Mungkin juga Anda menggunakan opsi pemasangan non-standar, seperti data=journal, yang berdampak besar pada kinerja. Tampilkan Anda: mount -v | grep ^/dev/. Ini adalah milikku:

/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)

Mungkin salah satu disk Anda rusak. Buat satu partisi pada setiap disk tanpa RAID (mungkin Anda memesan beberapa partisi swap pada kedua disk - gunakan ini - toh tidak ada gunanya untuk RAID saat swap). Buat filesystem di sana dan jalankan pg_test_fsyncdi setiap drive - jika ada masalah maka yang baik harus menunggu ketika keduanya dicerminkan.

Periksa apakah BIOS Anda diatur untuk menggunakan mode AHCI alih-alih mode IDE. Server akan mendapat manfaat dari Antrian Perintah Asli , yang tidak tersedia dalam mode IDE.

Abaikan perbandingan dengan SSD. Sangat konyol untuk membandingkan.

Tometzky
sumber
Saya menjalankan Bonnie ++ yang menunjukkan kinerja yang baik (sebaik yang Anda harapkan dari disk sata biasa). Juga, partisi disejajarkan. Ketika saya menjalankan pg_test_fsync pertama kali pada VM. Kemudian saya menjalankannya pada perangkat keras yang sebenarnya, setelah mematikan setiap proses lainnya (termasuk VM). Performanya sedikit lebih baik, sekitar 40 ops / detik, yang masih menyedihkan. Saya akan menjalankan beberapa tes lagi, pada partisi terpisah jika saya punya waktu hari ini. Terima kasih atas semua sarannya.
Blubber
Saya telah mengubah pertanyaan awal saya dengan informasi tambahan tentang opsi pemasangan dan perataan partisi.
Blubber
1

Saya tahu saya mungkin sudah terlambat untuk menjawab ini. Saya telah melihat masalah kinerja yang serupa dengan PostgreSQL dan MySQL, ketika menggunakan O_DIRECT. Saya membuat patokan mikro sistem menggunakan iozone dengan sinkronisasi tulis (- opsi + r) dan dengan dan tanpa O_DIRECT (opsi -I). Di bawah ini adalah dua perintah yang saya gunakan:

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

dan 

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

Yang pertama adalah O_SYNC + O_DIRECT sedangkan yang kedua hanya O_SYNC. Dengan yang pertama saya mendapatkan sekitar 30MB / detik dan yang kedua saya mendapatkan sekitar 220MB / detik (drive SSD). Apa yang saya temukan adalah bahwa opsi has_journal pada lapisan ext4 menyebabkan masalah. Tidak tahu kenapa ...

Filesystem features:      has_journal

Begitu saya mengeluarkan opsi ini, semuanya mulai bekerja dengan baik, baik pengujian mencapai dan mempertahankan 220MB / detik. Untuk mengambil opsi, Anda dapat menggunakan sesuatu seperti:

tune2fs -O ^has_journal /dev/sdX

Anda dapat memberikan tes itu dan melihat apakah itu memecahkan masalah kinerja Anda.

juru tulis
sumber
1
Menonaktifkan jurnal pada ext3 / 4 bukanlah sesuatu yang harus dilakukan tanpa pertimbangan cermat dan pemahaman yang sangat baik tentang dampaknya.
ThatGraemeGuy
2
Saya tidak setuju. DBMS melakukan pencatatan dan pemulihan sendiri untuk memberikan daya tahan dan keaslian transaksi. Jurnal FS sama sekali tidak berguna dalam hal itu. Selama fsync berfungsi dengan baik, efek dari transaksi yang dilakukan selalu dapat dipulihkan.
Caetano Sauer