PostgreSQL降低提交性能

PostgreSQL配置存在一些问题。经过一些基准测试后，我发现非常简单的查询会花费相对较长的时间，经过进一步检查，看来实际的COMMIT命令确实很慢。

我使用下表运行了一个非常简单的测试：

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

打开所有语句的登录后，我运行以下查询10000次：

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

BEGIN和INSERT花费的时间少于1毫秒，而COMMIT花费的平均时间为22毫秒。

在我自己的PC上运行相同的基准测试（速度要慢得多），BEGIN和INSERT语句的平均结果相同，但是COMMIT的平均时间约为0.4毫秒（快20倍以上）。

经过一番阅读后，我尝试使用该pg_test_fsync工具来解决问题。在服务器上，我得到以下结果：

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

在我自己的PC上，我得到：

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

服务器的配置：

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

用于比较的机器是具有16GB RAM和普通SATA磁盘的i5（无RAID）。

更多信息：

操作系统：Ubuntu server 12.10
内核：Linux ... 3.5.0-22-通用＃34-Ubuntu SMP Tue Jan 8 21:47:00 UTC 2013 x86_64 x86_64 x86_64 GNU / Linux
软件RAID 1
文件系统是ext4
没有指定其他安装选项。
Postgres 9.1版
Linux mdadm突袭

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-详细输出：

/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：我在两个磁盘上都进行了长时间的智能测试，没有发现任何问题。两个磁盘均来自Seagate，型号：ST3000DM001-9YN166。

更新2013-03-27：我在完全空闲的计算机上运行了最新版本（9.2.3）的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                      39.650 ops/sec
        fdatasync                          34.283 ops/sec
        fsync                              19.309 ops/sec
        fsync_writethrough                            n/a
        open_sync                          55.271 ops/sec

它比以前好一些，但仍然令人遗憾。两个磁盘上的分区均对齐：

$ 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

挂载-v输出：

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

md2设备正在用于测试。打算破坏交换分区并在单个磁盘上运行pg_test_fsync。

如果我分别在两个磁盘上运行pg_test_fsync，我将获得大致相同的性能，则该分区将使用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

在阵列和单个磁盘上运行测试两次后，数字似乎变化很大。最坏的情况是性能大约是我在此处发布的性能的50％（第一次测试大约为30 ops / s。）这正常吗？机器一直处于完全空闲状态。

另外，根据dmesg输出，控制器处于AHCI模式。

— 大声哭
source

您可以提供有关该软件RAID的一些详细信息吗？什么软件？Linux的mdadm还是dmraid？特定于供应商的东西？还有别的吗您的PostgreSQL版本和主机OS版本也会有所帮助。

— Craig Ringer 2013年

Answers:

该服务器具有令人难以置信的，令人难以置信的缓慢的fsync性能。您的软件RAID 1设置存在非常严重的错误。糟糕的fsync性能几乎可以肯定是导致性能问题的原因。

桌面速度非常慢fsync。

您可以通过设置synchronous_commit = off并设置来解决性能问题，但以崩溃后丢失一些数据为代价commit_delay。但是，您确实需要理清服务器上的磁盘性能，这真是惊人的慢。

为了进行比较，这是我在笔记本电脑上获得的东西（i7、8GB RAM，中端128G SSD，9.2版的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

诚然，此SSD可能不是硬性掉电安全的，但是当我们谈论服务器成本时，它并不像一个体面的断电安全SSD会花费很多。

— 克雷格·林格
source

是的，但是是什么原因导致fsync性能下降？

— 2013年

我尝试在自己的SSD上运行pg_test_fsync，并且获得了可比的性能数据。我知道可以禁用同步提交，但是问题仍然存在，此问题的原因是什么？

— 2013年

@Blubber您正在使用什么软件RAID？什么文件系统？什么主机操作系统和版本？哪些文件系统挂载选项？如果您正在寻找根本原因，这些都是至关重要的信息。请更新您的问题。你也应该做的硬盘SMART健康检查（smartctl -d ata -a /dev/sdx|less和smartctl -d ata -t long /dev/sdx后跟一个sleep 90m或任何smartctl告诉你，紧接着又-d ata -a得到结果）。

— Craig Ringer 2013年

@Blubber即使您修复RAID问题你的表现仍然会不好，只是不太为坏。普通的旧7200RPM（或更糟糕的是5400RPM）磁盘对于数据库性能而言是一个糟糕的选择，尤其是在没有具有电池后备缓存的适当硬件RAID控制器的情况下，该控制器可以使控制器分组并缓冲写操作。

— Craig Ringer 2013年

我已经更新了有关文件系统和raid配置的更多细节的问题。我知道这台机器在当前配置下永远不会提供非常好的性能。但是目前的表现确实很差。

— 2013年

这是pg_test_fsync在服务器上输出的，其配置非常相似-2个消费级磁盘（WD10EZEX-00RKKA0）上的Linux软件RAID1 ：

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

您确实在完全空闲的服务器上对此进行了测试，对吗？

也许您有未对齐的分区。校验：

parted /dev/sda unit s print

这是我的服务器的输出：

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

检查Start列中的每个数字是否可被2048整除（这意味着1MiB）。对于良好的4096B对齐方式，可以将其除以4就足够了，但是可以识别对齐方式的实用程序从1MiB边界开始分区。

另外，也许您使用的是非默认安装选项，例如data=journal，会对性能产生重大影响。显示您的：mount -v | grep ^/dev/。这是我的：

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

也许您的磁盘之一坏了。在没有RAID的每个磁盘上创建一个分区（也许您在两个磁盘上都保留了一些交换分区-使用这些分区-无论如何，交换时RAID都没有用）。在其中创建文件系统并pg_test_fsync在每个驱动器上运行-如果一个驱动器有问题，那么当两个驱动器都被镜像时，一个好的驱动器将必须等待。

检查您的BIOS是否设置为使用AHCI模式而不是IDE模式。服务器将受益于本机命令队列，该模式在IDE模式下不可用。

忽略与SSD的比较。比较起来很荒谬。

— 托梅斯基
source

我运行的bonnie ++表现出良好的性能（与您对常规sata磁盘的期望一样好）。而且，分区是对齐的。当我第一次运行pg_test_fsync时，它是在VM上。然后，在关闭所有其他进程（包括VM）之后，我在实际的硬件上运行它。性能稍好一些，约为40 ops / sec，这仍然令人遗憾。如果今天有时间，我将在单独的分区上运行更多测试。感谢所有的建议。

— 2014年

我已经用有关安装选项和分区对齐的其他信息修订了原始问题。

— 2014年

我知道回答这个问题可能为时已晚。使用O_DIRECT时，我已经看到PostgreSQL和MySQL出现类似的性能问题。我使用带有同步写入（-+ r选项）以及是否带有O_DIRECT（-I选项）的iozone对系统进行了微基准测试。以下是我使用的两个命令：

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

第一个是O_SYNC + O_DIRECT，第二个只有O_SYNC。首先，我的速度大约为30MB /秒，第二次我的速度大约为220MB /秒（SSD驱动器）。我发现是ext4接缝上的has_journal选项导致了问题。真的不知道为什么...

Filesystem features:      has_journal

一旦我选择了此选项，一切就开始正常运行，测试都达到并保持了220MB /秒的速度。要删除该选项，可以使用以下方法：

tune2fs -O ^has_journal /dev/sdX

您可以进行测试，看看它是否可以解决您的性能问题。

— 涂鸦
source

如果没有仔细考虑并充分了解其影响，就无法在ext3 / 4上禁用日志。

— ThatGraemeGuy 2013年

我不同意。DBMS自己进行日志记录和恢复，以提供事务的持久性和原子性。FS杂志在这方面完全没有用。只要fsync正常工作，就可以始终恢复已提交事务的影响。

— Caetano Sauer 2014年