Hiệu suất cam kết chậm của PostgreSQL


9

Chúng tôi đang gặp một số vấn đề với cấu hình PostgreSQL. Sau một số điểm chuẩn tôi phát hiện ra rằng các truy vấn rất đơn giản đang mất một thời gian tương đối dài, khi kiểm tra nhanh hơn, có vẻ như lệnh CommIT thực sự rất chậm.

Tôi đã chạy một bài kiểm tra rất đơn giản bằng cách sử dụng bảng sau:

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

Sau khi bật đăng nhập vào tất cả các câu lệnh, tôi đã chạy truy vấn sau 10000 lần:

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

BEGIN và INSERT đang mất <1ms để hoàn thành, nhưng CAM KẾT đang mất trung bình 22ms để hoàn thành.

Chạy cùng một điểm chuẩn trên PC của tôi, tốc độ chậm hơn rất nhiều, mang lại mức trung bình tương tự cho các câu lệnh BEGIN và INSERT, nhưng CAMIT trung bình là khoảng 0,4ms (nhanh hơn 20 lần).

Sau khi đọc, tôi đã thử pg_test_fsynccông cụ để cố gắng khắc phục vấn đề. Trên máy chủ tôi nhận được các kết quả này:

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

Trên PC của riêng tôi, tôi nhận được:

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

Cấu hình của máy chủ:

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

Máy được sử dụng để so sánh là một i5 với 16GB RAM và các đĩa SATA đơn giản (không đột kích).

Thêm thông tin:

  • HĐH: Máy chủ Ubuntu 12.10
  • Hạt nhân: Linux ... 3.5.0-22-chung # 34-Ubuntu SMP Thứ ba ngày 8 tháng 1 21:47:00 UTC 2013 x86_64 x86_64 x86_64 GNU / Linux
  • Phần mềm RAID 1
  • Hệ thống tập tin là ext4
  • Không có tùy chọn gắn kết khác được chỉ định.
  • Phiên bản Postgres 9.1
  • Cuộc đột kích mdadm Linux

Đầu ra của 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 - đầu ra chi tiết:

/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

Cập nhật 2013-03-25 : Tôi đã chạy thử nghiệm thông minh dài trên cả hai đĩa, điều này cho thấy không có vấn đề gì. Cả hai đĩa đều từ Seagate, model: ST3000DM001-9YN166.

Cập nhật 2013-03-27 : Tôi đã chạy pg_test_fsync của phiên bản mới nhất (9.2.3) trên một máy hoàn toàn nhàn rỗi:

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

Nó là một chút tốt hơn trước đó, nhưng vẫn còn đáng trách. Các phân vùng trên cả hai đĩa được căn chỉnh:

$ 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

Đầu ra -v:

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

Thiết bị md2 đang được sử dụng cho các thử nghiệm. Sẽ phá hủy phân vùng trao đổi và chạy pg_test_fsync trên các đĩa riêng lẻ.

Nếu tôi chạy pg_test_fsync trên cả hai đĩa riêng lẻ, tôi sẽ có hiệu suất gần như nhau, phân vùng được gắn với 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

Sau khi chạy thử nghiệm một vài lần, cả trên mảng và trên đĩa đơn, các con số dường như thay đổi dữ dội. Trường hợp xấu nhất hiệu suất là khoảng 50% những gì tôi đã đăng ở đây (khoảng 30 ops / s cho thử nghiệm đầu tiên.) Điều này có bình thường không? Máy hoàn toàn nhàn rỗi, mọi lúc.

Ngoài ra, theo đầu ra dmesg, bộ điều khiển ở chế độ AHCI.


Bạn có thể cung cấp một số chi tiết về RAID phần mềm đó không? Phần mềm gì? Linux mdadmhay dmraid? Một cái gì đó nhà cung cấp cụ thể? Thứ gì khác? Phiên bản PostgreSQL của bạn và phiên bản hệ điều hành máy chủ cũng sẽ giúp ích.
Craig Ringer

Câu trả lời:


6

Các máy chủ có fsynchiệu suất cực kỳ, không thể tả, chậm đáng kinh ngạc . Có điều gì đó rất sai với thiết lập RAID 1 phần mềm của bạn. fsyncHiệu suất khủng khiếp gần như chắc chắn là nguyên nhân của vấn đề hiệu suất của bạn.

Máy tính để bàn chỉ có rất chậm fsync.

Bạn có thể giải quyết các vấn đề về hiệu suất với chi phí mất một số dữ liệu sau khi gặp sự cố bằng cách đặt synchronous_commit = offvà đặt a commit_delay. Bạn thực sự cần phải sắp xếp hiệu suất đĩa trên máy chủ, tuy nhiên, điều đó rất chậm.

Để so sánh, đây là những gì tôi nhận được trên máy tính xách tay của mình (i7, RAM 8GB, SSD 128G tầm trung, pg_test_fsync từ 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

Phải thừa nhận rằng ổ SSD này có thể không phải là mất điện cứng, nhưng nó không giống như một ổ SSD an toàn khi mất điện khá tốn kém khi chúng ta nói về chi phí máy chủ.


1
Có, nhưng điều gì gây ra hiệu suất fsync xấu?
Blubber

Tôi đã thử chạy pg_test_fsync trên ổ SSD của riêng tôi và tôi nhận được số liệu hiệu suất tương đương. Tôi biết rằng tôi có thể vô hiệu hóa cam kết đồng bộ hóa, nhưng câu hỏi vẫn còn, nguyên nhân của vấn đề này là gì?
Blubber

@Blubber Bạn đang sử dụng phần mềm RAID nào? Hệ thống tập tin gì? Hệ điều hành và phiên bản máy chủ nào? Những gì tùy chọn gắn kết hệ thống tập tin? Đây là tất cả các thông tin quan trọng nếu bạn đang tìm kiếm nguyên nhân gốc rễ; vui lòng cập nhật câu hỏi của bạn Bạn cũng nên thực hiện kiểm tra sức khỏe SMART trên các ổ đĩa cứng ( smartctl -d ata -a /dev/sdx|lesssmartctl -d ata -t long /dev/sdxtheo sau là một sleep 90mhoặc bất cứ điều gì smartctlcho bạn biết sau đó -d ata -ađể có kết quả khác).
Craig Ringer

@Blubber Thậm chí nếu bạn khắc phục những vấn đề RAID hiệu suất của bạn vẫn sẽ là xấu, chỉ là không hoàn toàn như xấu. Các đĩa 7200RPM cũ (hoặc tệ hơn là 5400RPM) là một lựa chọn không tốt cho hiệu năng cơ sở dữ liệu, đặc biệt là không có bộ điều khiển RAID phần cứng phù hợp với bộ đệm được hỗ trợ bằng pin cho phép bộ điều khiển nhóm và ghi bộ đệm.
Craig Ringer

Tôi đã cập nhật câu hỏi với nhiều chi tiết hơn về hệ thống tập tin và cấu hình đột kích. Tôi hiểu rằng máy này sẽ không bao giờ cho hiệu năng rất tốt trong cấu hình hiện tại của nó. Nhưng hiệu suất hiện tại là thực sự xấu.
Blubber

1

Đây là pg_test_fsyncđầu ra trên máy chủ của tôi, với cấu hình rất giống nhau - phần mềm Linux RAID1 trên 2 đĩa cấp độ người tiêu dùng ( 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
...

Bạn đã kiểm tra điều này trên máy chủ hoàn toàn nhàn rỗi, phải không?


Có thể bạn có phân vùng chưa được phân bổ. Kiểm tra:

parted /dev/sda unit s print

Đây là đầu ra của máy chủ của tôi:

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

Kiểm tra xem mỗi số trong Startcột có chia hết cho năm 2048 (có nghĩa là 1MiB). Để căn chỉnh 4096B tốt chia hết cho 4 sẽ đủ, nhưng các tiện ích nhận biết căn chỉnh bắt đầu phân vùng ở ranh giới 1MiB.


Ngoài ra, có thể bạn đang sử dụng các tùy chọn gắn kết không mặc định, như data=journal, có ảnh hưởng lớn đến hiệu suất. Hiển thị : mount -v | grep ^/dev/. Cái này của tôi ư:

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

Có thể một trong các đĩa của bạn bị hỏng. Tạo một phân vùng trên mỗi đĩa không có RAID (có thể bạn đã dành một số phân vùng trao đổi trên cả hai đĩa - sử dụng những phân vùng này - dù sao cũng không sử dụng RAID khi trao đổi). Tạo các hệ thống tập tin ở đó và chạy pg_test_fsynctrên mỗi ổ đĩa - nếu một cái có vấn đề thì một cái tốt sẽ phải đợi nó khi cả hai được nhân đôi.


Kiểm tra xem BIOS của bạn được đặt để sử dụng chế độ AHCI thay vì chế độ IDE. Một máy chủ sẽ được hưởng lợi từ Hàng đợi lệnh gốc , không có sẵn trong chế độ IDE.


Bỏ qua so sánh với SSD. Thật nực cười khi so sánh.


Tôi đã chạy bonnie ++ cho thấy hiệu năng tốt (tốt như bạn mong đợi từ các đĩa sata thông thường). Ngoài ra, các phân vùng được căn chỉnh. Khi tôi chạy pg_test_fsync lần đầu tiên trên VM. Sau đó, tôi chạy nó trên phần cứng thực tế, sau khi tắt mọi tiến trình khác (bao gồm cả VM). Hiệu suất tốt hơn một chút, khoảng 40 ops / giây, vẫn còn đáng trách. Tôi sẽ chạy thêm một số thử nghiệm, trên các phân vùng riêng nếu tôi có thời gian hôm nay. Cảm ơn tất cả những lời đề nghị.
Blubber

Tôi đã sửa đổi câu hỏi ban đầu của mình với thông tin bổ sung về các tùy chọn gắn kết và căn chỉnh phân vùng.
Blubber

1

Tôi biết tôi có thể đã quá muộn để trả lời điều này. Tôi đã thấy các vấn đề hiệu suất tương tự với PostgreSQL và MySQL, khi sử dụng O_DIRECT. Tôi đã điểm chuẩn hệ thống bằng iozone với ghi đồng bộ (tùy chọn - + r) và có và không có O_DIRECT (tùy chọn -I). Dưới đây là hai lệnh tôi đã sử dụng:

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

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

Đầu tiên là O_SYNC + O_DIRECT trong khi thứ hai chỉ là O_SYNC. Với lần đầu tiên tôi nhận được khoảng 30MB / giây và với lần thứ hai tôi nhận được khoảng 220 MB / giây (ổ SSD). Những gì tôi phát hiện ra là tùy chọn has_journal trên đường nối ext4 để gây ra sự cố. Không biết tại sao ...

Filesystem features:      has_journal 

Khi tôi đưa ra tùy chọn này, mọi thứ bắt đầu hoạt động tốt, cả hai thử nghiệm đều đạt và duy trì 220MB / giây. Để đưa ra tùy chọn, bạn có thể sử dụng một cái gì đó như:

tune2fs -O ^has_journal /dev/sdX

Bạn có thể đưa ra một bài kiểm tra và xem liệu nó có giải quyết được các vấn đề về hiệu suất của bạn không.


1
Vô hiệu hóa tạp chí trên ext3 / 4 không phải là việc cần làm mà không xem xét cẩn thận và hiểu rất rõ về tác động.
ThatGraemeGuy

2
Tôi không đồng ý. Một DBMS tự ghi nhật ký và phục hồi để cung cấp độ bền và tính nguyên tử của các giao dịch. Tạp chí FS hoàn toàn vô dụng trong vấn đề đó. Miễn là fsync hoạt động đúng, hiệu ứng của các giao dịch đã cam kết luôn có thể được khôi phục.
Caetano Sauer
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.