磁盘性能基准 [英] disk performance benchmarks
问题描述
我一直试图为我公司的数据库指定一台新服务器
几周，其中一个我遇到的最大问题是试图找到有关PostgreSQL如何在各种磁盘配置下执行
的有意义的性能信息。
但是，我们现在已经采取了一些措施，我可以做一些
基准测试来实际获得一些数据。基本上我想知道是否
其他人对
最有用的基准测试有任何特别的建议（或要求）。
硬件我将进行基准测试是...
服务器1：单个2.8Ghz Xeon，2Gb RAM。 Adaptec 2410SA SATA硬件
RAID，带4 x 200Gb 7200rpm WD SATA硬盘。 RAID5中的RAID和
RAID10（目前是RAID5，但想在RAID10中试验写入性能
）。 Gentoo Linux
服务器2：单个2.6Ghz Xeon，2Gb RAM，单个80Gb IDE驱动器。 Redhat
Linux
服务器3：双2.6Ghz Xeon，6Gb内存，带4 x 36Gb的软件RAID10
10kRPM U320 SCSI驱动器，RedHat Linux
我意识到这些盒子并不完全相同 - 但是那些
的一些基准测试应该为其他任何人指出一些基准数据。 >
低中频盒子，想要IDE和IDE的一些性能数据
RAID vs SCSI RAID
我会超过很高兴将任何结果发回到列表中，如果
其他任何人都可以贡献任何其他数据点，那将是非常好的。
否则，任何指向快速/简单设置的一些模糊有用的
基准测试将会非常棒。目前我正在考虑''pgbench -c 10 -s 100 -v'的
行。
干杯
Shane
>>>>> " SW" == Shane Wright< Shane>写道：
SW>但是，我们现在已经采取了暴跌，我可以做一些
SW>基准测试以实际获取一些数据。基本上我想知道是否
SW>其他人对
SW>有任何特别的建议（或要求）。最有用的基准测试。
我在14磁盘SCSI RAID阵列上进行了一系列基准测试比较了
RAID 5,10和50。我的测试包括完全恢复
30Gb数据库（包括索引）并比较执行
恢复的时间，制作索引的时间以及真空的时候。然后我就给b $ b运行了一堆查询。
几乎不可能选择更好的RAID配置，所以我只是
使用RAID5。
你可以在列表档案中找到关于这个主题的很多帖子来自
关于八月 - 十月八月一年。
基本上，你必须全面接近它来调整系统：Pg
配置参数，内存和磁盘速度是主要因素。
那和你的架构不需要愚蠢。 :-)
-
= - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - =
Vivek Khera，博士Khera Communications，Inc。
互联网： kh***@kciLink.com Rockville，MD + 1- 301-869-4449 x806
AIM：vivekkhera Y！：vivek_khera http://www.khera.org/~vivek/
-------------------- -------（广播结束）---------------------------
提示8：解释分析是你的朋友
在星期二，2004-09-14在10:28，Vivek Khera写道：< blockquote class =post_quotes>>> " SW" == Shane Wright< Shane>写道：
SW>但是，我们现在已经采取了暴跌，我能够做一些
SW>基准测试以实际获取一些数据。基本上我想知道是否
SW>其他人对
SW>有任何特别的建议（或要求）。最有用的基准测试。
我对14个磁盘SCSI RAID阵列进行了一系列基准测试，比较了RAID 5,10和50.我的测试包括进行完全恢复一个30Gb数据库（包括索引）和比较恢复时间，制作索引的时间和真空时间。然后我运行了一堆查询。
几乎不可能选择更好的RAID配置，所以我只是选择使用RAID5。
你可以在去年十月八月份的名单档案中找到关于这个主题的很多帖子。
基本上，你必须从整体上接近它来调整系统：Pg
配置参数，内存和磁盘速度是主要因素。
那和你的架构不需要愚蠢。 ： - ）
我最近对这个话题感到沮丧，因为看起来你好像b $ b可以设计出一个地狱系统，使用micro
和宏观基准调整所有内容，但是当你把它投入生产时，东西会下降
。
当前问题：
双64位Opteron 244机器，8GB主内存，两个4磁盘RAID5
阵列（一个用于数据库，一个用于数据库） xlogs）。 PG'的配置极其优雅，而且在单独的基准测试中它非常快。
但实际上，性能是不可靠的。有一些关于什么
PG在提交和检查点内部将Linux发送到一个紧张的状态
状态。比如这里是一个平行重的
选择/插入负载时vmstat的快照：
procs -----------记忆---------- --- swap-- ----- io ---- --system-- ---- cpu ----
rb swpd免费buff缓存si所以bi bo in cs us sy id wa
3 0 216 13852 39656 7739724 0 0 820 2664 2868 2557 16 2 74 7
0 0 216 17580 39656 7736460 0 0 3024 4700 3458 4313 42 6 52 0
0 0 216 16428 39676 7737324 0 0 840 4248 3930 4516 0 4 89 8
0 1 216 18620 39672 7736920 0 0 7576 516 2738 3347 1 4 55 39
0 0 216 14972 39672 7738960 0 0 1992 2532 2509 2288 2 3 93 3
0 0 216 13564 39672 7740592 0 0 1640 2656 2581 2066 1 3 97 0
0 0 216 12028 39672 7742292 0 0 1688 3576 2072 1626 1 2 96 0
0 0 216 18364 39680 7736164 0 0 1804 3372 1836 1379 1 4 96 0
0 0 216 16828 39684 7737588 0 0 1432 2756 2256 1720 1 3 94 2
0 0 216 15452 39684 7738812 0 0 1188 2184 2384 1830 1 2 97 0
0 1 216 15388 39684 7740104 0 0 1336 2628 2490 1974 2 3 94 2
6 0 216 15424 39684 7740240 0 0 104 3472 2757 1940 3 2 92 2
0 0 216 14784 39700 7741856 0 0 1668 3320 2718 2332 0 3 97 0
你可以看到那里进展不大。在一个非常可怜的写作中，有一小块磁盘
读取，用户空间没有任何进展，内核不是很忙，而且很多过程都在iowait。那么到底是怎么回事？
只要检查点子流程
处于活动状态，这种非进展状态就会持续存在。我确定有一些神奇的方法可以改善这一点，但是我还没有发现它是
。
PS这是用Linux做的2.6.7。
问候，
jwb
----------- ----------------（广播结束）---------------------------
提示3：如果通过Usenet发布/阅读，请发送适当的
subscribe-nomail命令到 ma ******* @ postgresql.org 这样你的
消息可以干净利落地进入邮件列表
2004年9月14日星期二上午11:11:38 -0700，Jeffrey W. Baker写道：procs ---------- -memory ---------- --- swap-- ----- io ---- --system-- ---- cpu ----
rb swpd free buff缓存si所以bi bo in cs us sy id wa
3 0 216 13852 39656 7739724 0 0 820 2664 2868 2557 16 2 74 7
0 0 216 17580 39656 7736460 0 0 3024 4700 3458 4313 42 6 52 0
0 0 216 16428 39676 7737324 0 0 840 4248 3930 4516 0 4 89 8
0 1 216 18620 39672 7736920 0 0 7576 516 2738 3347 1 4 55 39
0 0 216 14972 39672 7738960 0 0 1992 2532 2509 2288 2 3 93 3
0 0 216 13564 39672 7740592 0 0 1640 2656 2581 2066 1 3 97 0
0 0 216 12028 39672 7742292 0 0 1688 3576 2072 1626 1 2 96 0
0 0 216 18364 39680 7736164 0 0 1804 3372 1836 1379 1 4 96 0
0 0 216 16828 39684 7737588 0 0 1432 2756 2256 1720 1 3 94 2
0 0 216 15452 39684 7738812 0 0 1188 2184 2384 1830 1 2 97 0
0 1 216 15388 39684 7740104 0 0 1336 2628 2490 1974 2 3 94 2
6 0 216 15424 39684 7740240 0 0 104 3472 2757 1940 3 2 92 2
0 0 216 14784 39700 7741856 0 0 1668 3320 2718 2332 0 3 97 0
你可以看到那里不是很大的进展正在取得那里。在
这些IO数字看起来很高，没有任何事情发生。你确定
你不是IO界限吗？
-
Jim C. Nasby，数据库顾问 de ***** @ decibel.org
给你的电脑一些大脑糖果！ www.distributed.net 团队＃1828
Windows：你今天想去哪里？
Linux：明天你想去哪里？
FreeBSD：你呢？伙计们来了，还是什么？"
---------------------------（...结束广播）---------------------------
提示1：订阅和取消订阅命令转到 ma ******* @ postgresql.org
Hi,
I''ve been trying to spec a new server for my company''s database for a
few weeks and one of the biggest problems I''ve had is trying to find
meaningful performance information about how PostgreSQL will perfom
under various disk configurations.
But, we have now taken the plunge and I''m in a position to do some
benchmarking to actually get some data. Basically I was wondering if
anyone else had any particular recommendations (or requests) about the
most useful kinds of benchmarks to do.
The hardware I''ll be benchmarking on is...
server 1: single 2.8Ghz Xeon, 2Gb RAM. Adaptec 2410SA SATA hardware
RAID, with 4 x 200Gb 7200rpm WD SATA drives. RAID in both RAID5 and
RAID10 (currently RAID5, but want to experiment with write performance
in RAID10). Gentoo Linux
server 2: single 2.6Ghz Xeon, 2Gb RAM, single 80Gb IDE drive. Redhat
Linux
server 3: dual 2.6Ghz Xeon, 6Gb RAM, software RAID10 with 4 x 36Gb
10kRPM U320 SCSI drives, RedHat Linux
I realise the boxes aren''t all identical - but some benchmarks on those
should give some ballpark figures for anyone else speccing out a
low-mid range box and wanting some performance figures on IDE vs IDE
RAID vs SCSI RAID
I''d be more than happy to post any results back to the list, and if
anyone else can contribute any other data points that''d be great.
Otherwise, any pointers to a quick/easy setup for some vaguely useful
benchmarks would be great. At the moment I''m thinking just along the
lines of ''pgbench -c 10 -s 100 -v''.
Cheers
Shane
>>>>> "SW" == Shane Wright <Shane> writes:
SW> But, we have now taken the plunge and I''m in a position to do some
SW> benchmarking to actually get some data. Basically I was wondering if
SW> anyone else had any particular recommendations (or requests) about the
SW> most useful kinds of benchmarks to do.
I did a bunch of benchmarking on a 14 disk SCSI RAID array comparing
RAID 5, 10, and 50. My tests consisted of doing a full restore of a
30Gb database (including indexes) and comparing the times to do the
restore, the time to make the indexes, and the time to vacuum. Then I
ran a bunch of queries.
It was damn near impossible to pick a ''better'' RAID config, so I just
went with RAID5.
You can find many of my posts on this topic on the list archives from
about august - october of last year.
Basically, you have to approach it holistically to tune the system: Pg
config parameters, memory, and disk speed are the major factors.
That and your schema needs to be not idiotic. :-)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: kh***@kciLink.com Rockville, MD +1-301-869-4449 x806
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
On Tue, 2004-09-14 at 10:28, Vivek Khera wrote:>> "SW" == Shane Wright <Shane> writes:
SW> But, we have now taken the plunge and I''m in a position to do some
SW> benchmarking to actually get some data. Basically I was wondering if
SW> anyone else had any particular recommendations (or requests) about the
SW> most useful kinds of benchmarks to do.
I did a bunch of benchmarking on a 14 disk SCSI RAID array comparing
RAID 5, 10, and 50. My tests consisted of doing a full restore of a
30Gb database (including indexes) and comparing the times to do the
restore, the time to make the indexes, and the time to vacuum. Then I
ran a bunch of queries.
It was damn near impossible to pick a ''better'' RAID config, so I just
went with RAID5.
You can find many of my posts on this topic on the list archives from
about august - october of last year.
Basically, you have to approach it holistically to tune the system: Pg
config parameters, memory, and disk speed are the major factors.
That and your schema needs to be not idiotic. :-)
I''ve recently bee frustrated by this topic, because it seems like you
can design the hell out of a system, getting everything tuned with micro
and macro benchmarks, but when you put it in production the thing falls
apart.
Current issue:
A dual 64-bit Opteron 244 machine with 8GB main memory, two 4-disk RAID5
arrays (one for database, one for xlogs). PG''s config is extremely
generous, and in isolated benchmarks it''s very fast.
But, in reality, performance is abyssmal. There''s something about what
PG does inside commits and checkpoints that sends Linux into a catatonic
state. For instance here''s a snapshot of vmstat during a parallel heavy
select/insert load:
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
3 0 216 13852 39656 7739724 0 0 820 2664 2868 2557 16 2 74 7
0 0 216 17580 39656 7736460 0 0 3024 4700 3458 4313 42 6 52 0
0 0 216 16428 39676 7737324 0 0 840 4248 3930 4516 0 4 89 8
0 1 216 18620 39672 7736920 0 0 7576 516 2738 3347 1 4 55 39
0 0 216 14972 39672 7738960 0 0 1992 2532 2509 2288 2 3 93 3
0 0 216 13564 39672 7740592 0 0 1640 2656 2581 2066 1 3 97 0
0 0 216 12028 39672 7742292 0 0 1688 3576 2072 1626 1 2 96 0
0 0 216 18364 39680 7736164 0 0 1804 3372 1836 1379 1 4 96 0
0 0 216 16828 39684 7737588 0 0 1432 2756 2256 1720 1 3 94 2
0 0 216 15452 39684 7738812 0 0 1188 2184 2384 1830 1 2 97 0
0 1 216 15388 39684 7740104 0 0 1336 2628 2490 1974 2 3 94 2
6 0 216 15424 39684 7740240 0 0 104 3472 2757 1940 3 2 92 2
0 0 216 14784 39700 7741856 0 0 1668 3320 2718 2332 0 3 97 0
You can see there''s not much progress being made there. In the
presence of a farily pathetic writeout, there''s a tiny trickle of disk
reads, userspace isn''t making any progress, the kernel isn''t busy, and
few processes are in iowait. So what the heck is going on?
This state of non-progress persists as long as the checkpoint subprocess
is active. I''m sure there''s some magic way to improve this but I
haven''t found it yet.
PS this is with Linux 2.6.7.
Regards,
jwb
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly
On Tue, Sep 14, 2004 at 11:11:38AM -0700, Jeffrey W. Baker wrote:procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
3 0 216 13852 39656 7739724 0 0 820 2664 2868 2557 16 2 74 7
0 0 216 17580 39656 7736460 0 0 3024 4700 3458 4313 42 6 52 0
0 0 216 16428 39676 7737324 0 0 840 4248 3930 4516 0 4 89 8
0 1 216 18620 39672 7736920 0 0 7576 516 2738 3347 1 4 55 39
0 0 216 14972 39672 7738960 0 0 1992 2532 2509 2288 2 3 93 3
0 0 216 13564 39672 7740592 0 0 1640 2656 2581 2066 1 3 97 0
0 0 216 12028 39672 7742292 0 0 1688 3576 2072 1626 1 2 96 0
0 0 216 18364 39680 7736164 0 0 1804 3372 1836 1379 1 4 96 0
0 0 216 16828 39684 7737588 0 0 1432 2756 2256 1720 1 3 94 2
0 0 216 15452 39684 7738812 0 0 1188 2184 2384 1830 1 2 97 0
0 1 216 15388 39684 7740104 0 0 1336 2628 2490 1974 2 3 94 2
6 0 216 15424 39684 7740240 0 0 104 3472 2757 1940 3 2 92 2
0 0 216 14784 39700 7741856 0 0 1668 3320 2718 2332 0 3 97 0
You can see there''s not much progress being made there. In the
Those IO numbers look pretty high for nothing going on. Are you sure
you''re not IO bound?
--
Jim C. Nasby, Database Consultant de*****@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org
这篇关于磁盘性能基准的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
