LARRY终于发话了：）
刚发了一个帖子，贴过来继续
如何判断存储设备已经达到性能瓶颈？

主机为P690(14CPU 24GB)，外连FASTT700,10块15000转73.4GB硬盘，做成RAID0+1，分成4个LUN.存储关键数据库数据，数据均衡分布在4个LUN上。

假设数据库层面没有问题（其实TMD的都是些很恶劣的查询），单从存储设备来讲，如何判断存储设备已经达到性能瓶颈？

从操作系统的nmon监控可以达到以下性能指数：
CPU TOTAL
disk total kb/s
disk busy%
disk adapater (KB/s)
disk adapter(tps)
请参见附件。
是否可以从tps上可以判断目前的FASTT700已经无法满足现在的I/O性能？

纠正一下以前的错误，目前FT700的segment size设的是64K

从NMON里看到adapter的tps已经得到1600左右，但吞吐量也就20MB/S，是否意味着由于I/O请求已经达到FT700（现有配置和硬盘个数下）的顶峰？
如果是这样那只有通过扩充磁盘（增加EXP700柜）来提高tps了，不知这样理解是否正确。

[[i] 本帖最后由 balefired 于 2006-3-22 17:53 编辑 [/i]]

你的吞吐量读写比率如何？

:lol  如larry说的，跟应用对IO的使用有关。

学习到了。。。
应用对IO的使用的确很关键。

[quote]原帖由 [i]darkbug[/i] 于 2006-3-21 21:38 发表


如果只有一个阵列的话：
从控制器角度考虑，可以建2个以上的LUN，IO也可以分散在2条控制器路径上，但是当LUN多过2个的时候，这种分散就没有实际性能的意义了吧，就算IO分散到多个LUN上又有什么意义？反正是同 ... [/quote]

大量随机IO的情况下，肯定是尽量将IO尽可能分布到更多的physical drive上。
比如EMC的阵列建立了多个RG，每个RG又分出了多个LUN，不同RG的LUN就是应该作stripe的。

[quote]原帖由 [i]larryh[/i] 于 2006-3-22 17:40 发表


条带化提高IOPS承受能力是讲物理硬盘的条带化的，跟LUN上LV条带化应该没什么关系吧。

我认为，LUN的LV级别条带化对如下条件同时达成时有用：
1、LUN平均分配在两个控制器上，可以充分利用控制器处理能力， ... [/quote]

的确，应用层设计（包括数据库的规划）对IO产生的影响更大一些。但是实际中很多客户的DBA对底层的阵列，OS的设备层次没有一个好的认识，导致很多数据库的性能低下。

我好像也回过帖子，好像也没了。

给大家一个绝对真理，你不要不相信：
一个磁盘能承受的iops只有70-150，如果在没有cache缓存的情况下，10快磁盘在最好的数据分散情况下，最多支持1500 iops

如果有cache, 几个4k如果能恰好落在一个64k里，则可以提高一些iops，但需要看数据的随机性

磁盘的顺序写入，单盘通常可以达到至少30-80MB/s以上

如果iops达到极限，可以：
增加磁盘，合理分散io
提高每次写入的数据量（由于每次写入的数据一定是连续的,增大oracle io size)

[quote]原帖由 [i]orian[/i] 于 2006-3-26 14:19 发表
我好像也回过帖子，好像也没了。

给大家一个绝对真理，你不要不相信：
一个磁盘能承受的iops只有70-150，如果在没有cache缓存的情况下，10快磁盘在最好的数据分散情况下，最多支持1500 iops

如果有cache,  ... [/quote]


强烈支持，见到很多客户都是这样。这种情况下，客户数据库的IO的分布更加重要，而不是阵列的性能真的不行。

突然想起一个问题：
在aix/hp下，建立lv时不选条带化，写入的数据顺序为：写满第一块后再写第二块，直到写满最后一块硬盘。建lv时选条带化，数据同时往n块硬盘上写。
假设在划分LUN时，把多个lun平均取自多个raid group以提高性能。
在数据量很小的情况下，条带化与否对写入性能影响不大。
数据量大到GB级或者数据容量占用多个磁盘后，条带化后的lv可以提高写入速度。

今日测试条件如下：
>hp 4440机器，单HBA卡通过H08连接AMS500，存储上划分10个33G大小的LUN（来自4个7D+1P的RAID5 Group）。
>测试时，从本地将一个8G文件写入建立在盘阵上的文件系统。

1.lv不做条带化，由于数据只往单个硬盘上写，写入速度只有8-12M之间；
2.lv条带化（跨8个lun），数据同时往8个硬盘写，写入速度为8x(8-12)M，大概在80M/s；

因此，我想lv条带化还是很有用的。

以上为顺序操作。随机操作没测试，但以前曾在590一分区（8c16g，双hba卡+hdlm，usp1100）上测过，不做条带化，db2数据库在高峰期做业务时写入速度在60-70M/s左右；条带化后，速度提高到180M/s（从usp1100上监控得出的值，存储层上无其他系统影响）；

[quote]原帖由 [i]balefired[/i] 于 2006-3-22 17:47 发表
LARRY终于发话了：）
刚发了一个帖子，贴过来继续
如何判断存储设备已经达到性能瓶颈？

主机为P690(14CPU 24GB)，外连FASTT700,10块15000转73.4GB硬盘，做成RAID0+1，分成4个LUN.存储关键数据库数据，数据均 ... [/quote]

这种配置，单个扩展柜时合理的吞吐量应该在80MB/S左右，试着调整一下队列深度!

[quote]原帖由 [i]wildhorse[/i] 于 2006-3-28 17:31 发表
突然想起一个问题：
在aix/hp下，建立lv时不选条带化，写入的数据顺序为：写满第一块后再写第二块，直到写满最后一块硬盘。建lv时选条带化，数据同时往n块硬盘上写。
假设在划分LUN时，把多个lun平均取自多个ra ... [/quote]

[b]假设在划分LUN时，把多个lun平均取自多个raid group以提高性能。[/b]

这个是最重要的前提。我前面的意见都是基于单个RAID10 group说的。

另外，测RAID5会人为拉大条带与否的差距，因为你跨不同的RAID5 GROUP做写操作，等于大大减轻了RAID5写惩罚。如果这些数量的硬盘组成一个RAID5 GROUP，条带与否的性能差距我想没那么大。

最好还是用单个RAID10测，用IOMETER做，用文件系统做结果容易受文件系统CACHE影响。多个LUN跨多个RAID GROUP，做条带化不用说性能都有提高的。

以上测试顺序写时用的是RAID5的盘，随机写用的是RAID10的盘。
下一步会测试IOMETER，有结果会及时放上来。哈。

[quote]原帖由 [i]larryh[/i] 于 2006-3-28 23:25 发表


[b]假设在划分LUN时，把多个lun平均取自多个raid group以提高性能。[/b]

这个是最重要的前提。我前面的意见都是基于单个RAID10 group说的。

另外，测RAID5会人为拉大条带与否的差距，因为你跨不同的RAI ... [/quote]

很显然，在不同的RG的LUN之间做条带化会提高性能，在同一个RG的LUN之间做条带化，是没有意义的，甚至会增加物理硬盘的不必要的磁头定位时间

[b]如果暂时不考虑RAID内部结构，主机层面的条带化，是在不同LUN之间做RAID0：[/b]
假设存储有两个RAID1的 RG，每个RG有2块物理盘，每个RG分配1个LUN，结果是LUN0和LUN1。这个时候在主机上对LUN0和LUN1做条带化，其实等于 “RAID1+0”，不过RAID1在盘阵时间，RAID0在存储实现。如果把物理盘，RG数量放大，也是同样的道理。至于应用如何使用，那就是应用，主机，存储之间规划的问题；
比如HDS USP上，4D+4D就是通过concatenation选项把两个2D+2D RG 条带化实现的，concatenation还可以实现4个 RAID5 RG之间的条带化；
在主机层面和在存储层面的条带化，其实目的是一样的，都是基于性能考虑

[b]不同RAID10上的LUN做条带化和不同RAID5上的LUN做条带化对性能提高的程度跟应用和它们本身的技术特点有关系[/b]

larryh 是不是要排砖了! :lu1:

[[i] 本帖最后由 papaya 于 2006-3-29 11:20 编辑 [/i]]

[quote]原帖由 [i]orian[/i] 于 2006-3-26 14:19 发表
我好像也回过帖子，好像也没了。

给大家一个绝对真理，你不要不相信：
一个磁盘能承受的iops只有70-150，如果在没有cache缓存的情况下，10快磁盘在最好的数据分散情况下，最多支持1500 iops

如果有cache,  ... [/quote]
没办法测试没cache缓存的情况。目前简单换算得到的单盘iops大概在120左右，（12000 iops，12个lun（raid10 4d+4d，146G 15K）但我想这不会是性能极限，至少目前还没有write pending。

[quote]原帖由 [i]wildhorse[/i] 于 2006-3-29 13:12 发表

没办法测试没cache缓存的情况。目前简单换算得到的单盘iops大概在120左右，（12000 iops，12个lun（raid10 4d+4d，146G 15K）但我想这不会是性能极限，至少目前还没有write pending。 [/quote]
如果是顺序读写的话，这个意义不大

[quote]原帖由 [i]darkbug[/i] 于 2006-3-29 16:38 发表

如果是顺序读写的话，这个意义不大 [/quote]


的确，顺序写的测试没有很大的必要。但是随机IO的情况，很难去模拟测试！:L

[[i] 本帖最后由 nfdx 于 2006-3-29 18:44 编辑 [/i]]

顺序写，对文件系统的规划也很重要，测试也有必要。

[quote]原帖由 [i]papaya[/i] 于 2006-3-29 11:17 发表
larryh 是不是要排砖了! [/quote]

不懂，为什么我要拍砖？你这段说了什么自认可能不正确的话吗？:P

[quote]原帖由 [i]wildhorse[/i] 于 2006-3-29 20:30 发表
顺序写，对文件系统的规划也很重要，测试也有必要。 [/quote]

有关单个硬盘的iops其实用平均寻道时间估算比较公道

大规模的顺序写在实际应用中还是比较少

碰到TB级的文件系统，或者BT的数据加载，都是对顺序写的考验。。。:lol

[quote]原帖由 [i]wildhorse[/i] 于 2006-3-30 12:26 发表
碰到TB级的文件系统，或者BT的数据加载，都是对顺序写的考验。。。:lol [/quote]
谁没事天天搞这个？:lol

[quote]原帖由 [i]darkbug[/i] 于 2006-3-30 17:16 发表

谁没事天天搞这个？:lol [/quote]
:lu3::lu3::lu3:有人没事就搞，俺痛苦呀。。。
陪人搞。。。:lu2:

对不住楼上的，我眼花了，有错！

看成bei人搞哦

我忏悔！:lol

[quote]原帖由 [i]wildhorse[/i] 于 2006-3-30 12:26 发表
碰到TB级的文件系统，或者BT的数据加载，都是对顺序写的考验。。。:lol [/quote]


还真是想不到有什么应用会有TB级的顺序写，有这么大的文件吗？