Blu*_*ber 9 postgresql linux performance hard-drive
我们在 PostgreSQL 配置方面遇到了一些问题。经过一些基准测试后,我发现非常简单的查询需要相对较长的时间,经过进一步检查,实际的 COMMIT 命令似乎非常慢。
我使用下表进行了一个非常简单的测试:
CREATE TABLE test (
id serial primary key,
foo varchar(16),
);
Run Code Online (Sandbox Code Playgroud)
在打开所有语句的登录后,我运行了以下查询 10000 次:
BEGIN;
INSERT INTO test (a) VALUES ('bar');
COMMIT;
Run Code Online (Sandbox Code Playgroud)
BEGIN 和 INSERT 需要 < 1ms 才能完成,但 COMMIT 平均需要 22ms 才能完成。
在我自己的 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
Run Code Online (Sandbox Code Playgroud)
在我自己的电脑上,我得到:
$ ./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
Run Code Online (Sandbox Code Playgroud)
服务器的配置:
CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
RAM: 32GB
Disk: 2x 2TB SATA disk in Software RAID 1
Run Code Online (Sandbox Code Playgroud)
用于比较的机器是具有 16GB RAM 和普通 SATA 磁盘(无突袭)的 i5。
更多信息:
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
Run Code Online (Sandbox Code Playgroud)
Mdadm --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
Run Code Online (Sandbox Code Playgroud)
2013 年 3 月 25 日更新:我对两个磁盘进行了长时间的智能测试,没有发现任何问题。两个磁盘都来自希捷,型号:ST3000DM001-9YN166。
2013 年 3 月 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
Run Code Online (Sandbox Code Playgroud)
比以前稍微好一点,但仍然令人遗憾。两个磁盘上的分区对齐:
$ 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
Run Code Online (Sandbox Code Playgroud)
挂载 -v 输出:
$ mount -v | grep ^/dev/
/dev/md2 on / type ext4 (rw,noatime)
/dev/md1 on /boot type ext3 (rw)
Run Code Online (Sandbox Code Playgroud)
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
Run Code Online (Sandbox Code Playgroud)
在阵列和单个磁盘上运行几次测试后,数字似乎变化很大。最坏的情况下,性能大约是我在这里发布的性能的 50%(第一次测试大约 30 ops/s。)这正常吗?机器一直处于完全空闲状态。
此外,根据 dmesg 输出,控制器处于 AHCI 模式。
服务器具有令人难以置信的、难以形容的、令人惊讶的缓慢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
Run Code Online (Sandbox Code Playgroud)
诚然,这个 SSD 可能不是硬断电安全的,但当我们谈论服务器成本时,它不像一个像样的断电安全 SSD 成本很高。
归档时间: |
|
查看次数: |
12057 次 |
最近记录: |