Chinaunix

标题: VxVM的性能问题 [打印本页]

作者: mike79 时间: 2011-12-30 14:12
标题: VxVM的性能问题
本帖最后由 mike79 于 2011-12-30 14:29 编辑

环境是p650+AIX6106+VxVM5.1SP1RP1+2台2Gbps SAN交换机+CX600。p650的2块2Gbps HBA卡连接2台SAN交换机，CX600的每个控制器上各有2个2Gbps端口分别连接2台SAN交换机

CX600建了16个RAID5，每个RAID5中有8块磁盘。通过vxdmp聚合后，p650就识别到16个磁盘，每个磁盘有2条路径，也就是有2个hdisk。这些都很正常。
通过VxVM建立dg和volume，volume做条带化，跨4块磁盘，stripe size是2M。dd测试发现写volume很慢，才40MBPS。在排除了SAN交换机和存储控制器以及RAID的性能瓶颈之后，问题集中到VxVM设置上。

调整了vxio的vol_maxio和vol_iomemmxplsz参数，分别调整为2M和40M，没有效果。
将所有磁盘退出VxVM控制，建立LVM vg和lv。lv同样做条带化，跨4块磁盘，stripe size是2M。dd测试发现写lv可以将近100MBPS。

用LVM的一个问题是没有多路径。如果安装PowerPath的话，担心和VxVM的DMP有冲突，也不想卸载VxVM。看到DMP支持LVM，就修改dmp_native_support参数为on，果然可以使用DMP聚合后的设备名建立vg。
在vg中建立条带化的LV，重新测试速度，还是可以到100MBPS。

至此，可以确定性能问题应该是在VxVM层面。但是不知道问题在哪里。

作者: johnnyccna 时间: 2011-12-31 16:24
　　建立的DG(VG)是用同样的LUN吗，如果不一样，测试结果难免产生差异性，存储底层LUN的选择也难免对IO性能产生影响！

作者: wdbj 时间: 2011-12-31 16:50
这得看具体的dd命令了

作者: mike79 时间: 2011-12-31 22:49
一样的LUN，一样的dd命令。
就是用相同的一组LUN分两次测试，一次建立dg，另一次建立vg。甚至dg上建立volume和vg上建立lv都是类似的，条带化跨4个LUN，stripe size为2M

作者: wdbj 时间: 2012-01-01 12:03
dd的io size指定的多大，读写双方是否有文件系统

作者: mike79 时间: 2012-01-01 13:08
iosize测试过8M/16M/32M，VxVM基本维持在40MBPS，LVM维持在100MBPS左右，都没有很大变化。
测试的一方使用裸设备，另一方使用/dev/zero或者/dev/null。

作者: wdbj 时间: 2012-01-01 14:12

mike79 发表于 2012-01-01 13:08
iosize测试过8M/16M/32M，VxVM基本维持在40MBPS，LVM维持在100MBPS左右，都没有很大变化。
测试的一方使用 ...

你的io size 那么大，但vxvm最大的限制你设成了2mb, 当io 落到vxvm层，都被分割成2mb的，也就是说vxvm以2m，2m,2m,2m这么写，你的stripe unit 也是2m，那对于dd这个单线程的玩意，这其实和非stripe 没区别了，lvm 没有大小限制，每个io 下去是8m, 8m,8m,8m,每次都利用到4个盘一起干活，当然快了

你把dd的bs 用2m,保证lvm也慢下来

作者: mike79 时间: 2012-01-01 14:26

wdbj 发表于 2012-01-01 14:12
lvm 没有大小限制，每个io 下去是8m, 8m,8m,8m,每次都利用到4个盘一起干活，当然快了

这个分析我不太认同。LVM的IO有限制的，就是VG的LTG size属性，往该VG的PV中写入数据时，IO Size不会超过这个值。而这个值实际上是PV的属性决定的，VG只是在所有的PV中选择最小值。在VxVM测试时候，简单点用topas看的话，也可以看到TPS差不多就是40，那也就是1MB/IO。所以在这点上VxVM和LVM相差不大。
另外我也用bs=2m测试了，LVM中还是可以到100MBPS，TPS和bs=32m的测试也接近。

作者: wdbj 时间: 2012-01-01 14:34
本帖最后由 wdbj 于 2012-01-01 14:37 编辑

mike79 发表于 2012-01-01 14:26
这个分析我不太认同。LVM的IO有限制的，就是VG的LTG size属性，往该VG的PV中写入数据时，IO Size不会超过 ...

你确定你用bs 2m测过？那你试试把vxvm 的stripe unit 改成512k试试吧，dd bs还用2m

作者: mike79 时间: 2012-01-01 14:36

wdbj 发表于 2012-01-01 14:34
你确定你用bs 2m测过？那你试试把vxvm 的stripe unit 改成512k试试吧

我刚测过用bs=2m。现在上面已经有数据了，就不折腾它了。
PS 现在还这么热诚的回复技术帖子的，莫非也是在哪做年度处理之类的兄弟？

作者: wdbj 时间: 2012-01-01 14:38
呵呵闲着没啥事瞎看看

作者: 无牙 时间: 2012-01-01 23:23
路过学习一下

作者: magic_tianya 时间: 2012-01-03 20:46
回复 1# mike79

vxvm在aix上得performance还真不一定有native的lvm好。（也许我记错了），还是mark，学习下~

作者: 无牙 时间: 2012-01-04 11:51
有可能

作者: david5337 时间: 2012-01-06 09:09
把EMC的PowerPath也装上去试一下哦。
我曾经遇到类似的case，也是EMC的CX盘阵加Veritas SF；发现DMP和PowerPath都有的情况下，路径切换很慢，性能嘛倒是差不多。
最后的解决办法是，先安装SF，再安装PowerPath，SF使用PowerPath的psudo设备。

作者: taotao1240 时间: 2012-01-06 09:33
是不是缓存设置的问题，wt和wb性能相差很大？

作者: mike79 时间: 2012-01-06 10:10

david5337 发表于 2012-01-06 09:09
把EMC的PowerPath也装上去试一下哦。
我曾经遇到类似的case，也是EMC的CX盘阵加Veritas SF；发现DMP和Powe ...

没装PowerPath，已经有DMP了，就没必要PowerPath了。
Veritas也不太推荐这种做法了。

作者: mike79 时间: 2012-01-06 10:12

taotao1240 发表于 2012-01-06 09:33
是不是缓存设置的问题，wt和wb性能相差很大？

你是说CX层面的缓存设置还是VxVM层面的设置？CX层面如果缓存设置有问题的话，那LVM的写操作也会有问题。
VxVM层面的缓存设置调整过，但是没啥用，可能设置的不正确。

作者: taotao1240 时间: 2012-01-06 10:47
回复 18# mike79

肯定是存储层面的咯，因为我以前碰到过存储的写缓存的设置模式不对，导致写速度奇慢无比。

作者: mike79 时间: 2012-01-06 10:50
回复 19# taotao1240
存储层面如果设置有问题的话，那通过LVM写存储也应该很慢。但测试发现通过LVM写存储的速度要快多了。

作者: taotao1240 时间: 2012-01-06 11:13
回复 20# mike79

会不会是这么种情况，你退出vx的控制，建立LVM，但是这种情况默认写缓存是WB，所以能达到100MB/s，但是你在VX的控制下，它默认建卷的时候，默认就是WT。你可以具体查看下写缓存的模式。比如在一个存储上，一块sata盘有80-90MB/s，但是一块移动硬盘只有30-40MB/s。

作者: 无牙 时间: 2012-01-06 11:19
LZ有没有正确的加载ASL？如果这个不正确也会有类似的问题，是因为对控制处理上的问题。你有没有发现在CX控制器的日志中有控制器频繁切换的信息？

作者: wdbj 时间: 2012-01-06 11:29
本帖最后由 wdbj 于 2012-01-06 11:33 编辑

其实我还是强烈建议LZ用 dd的512k的stripe unit建卷来试一下vxvm，用time或timex来衡量时间，应能明确看到2m和512k的stripe unit的区别（保持8m的dd bs大小和2m的vol_maxio大小）

作者: mike79 时间: 2012-01-06 14:37
本帖最后由 mike79 于 2012-01-06 14:39 编辑

无牙发表于 2012-01-06 11:19
LZ有没有正确的加载ASL？如果这个不正确也会有类似的问题，是因为对控制处理上的问题。你有没有发现在CX控 ...

加载ALS应该是在DMP层面解决的吧？这个问题我也考虑过，但是现在用DMP作为多路径软件，然后建立LVM VG，再dd测试写性能的话也依然可以到100MBPS。另外控制器日志我也看过，没发现有什么异常的。
我用vxdmpadm看流量，发现如果用VxVM的话，写操作的响应时间要20多ms，将近30ms，这个我觉得很奇怪。但是也不知道哪里有日志可以看问题在哪个环节。

作者: mike79 时间: 2012-01-06 14:43

wdbj 发表于 2012-01-06 11:29
其实我还是强烈建议LZ用 dd的512k的stripe unit建卷来试一下vxvm，用time或timex来衡量时间，应能明确看到 ...

512K的stripe size用意何在？以LVM为例，因为LTG Size可以到1MB，如果stripe size为1M或者更大的话，那一个1MB的写操作只会落到一块盘上；但是如果stripe size为512KB的话，那1MB的写操作会落到两块盘上。多占用一倍的IO，可能只换来些微的性能提升，我不是很赞成这种做法。

作者: wdbj 时间: 2012-01-06 14:52

mike79 发表于 2012-01-06 14:43
512K的stripe size用意何在？以LVM为例，因为LTG Size可以到1MB，如果stripe size为1M或者更大的话，那一 ...

你不信就算了，但是我建议你还是试试。1MB的I/O落到两个盘上才真正能充分利用stripe的优势，你4个盘做stripe，以一个1MB的IO为例，如果stripe unit 是1MB，那么，需要一个IO搞定，但只有一个盘来处理这个IO，大小是1M；但如果stripe unit是256k，会产生4个IO来完成这一笔，但这4个IO可是4个盘同时做的，而非第一个盘做完才第2个盘做，每一个盘只处理256K的IO，4个盘一起干活，当然要快，这就是stripe为什么快的原理

作者: mike79 时间: 2012-01-06 15:12

wdbj 发表于 2012-01-06 14:52
你不信就算了，但是我建议你还是试试。1MB的I/O落到两个盘上才真正能充分利用stripe的优势，你4个盘做s ...

这个原理我知道。但是这个方法的弊端就是单个磁盘的IO性能没有充分发挥。其实对于单个磁盘而言，只要单个写操作数据量不超过LTG，也就是能在一个IO内完成，那么是写入256KB、512KB或者1MB，时间相差不是很大。但是消耗的IO却相差很远。

作者: wdbj 时间: 2012-01-06 15:16

mike79 发表于 2012-01-06 15:12
这个原理我知道。但是这个方法的弊端就是单个磁盘的IO性能没有充分发挥。其实对于单个磁盘而言，只要单个 ...

唉，你不测就算了，说实话这种测试我做过无数遍了，我能非常确定你的IO慢的问题在哪，既然你不肯测，我也不说了

作者: mike79 时间: 2012-01-06 15:30

wdbj 发表于 2012-01-06 15:16
唉，你不测就算了，说实话这种测试我做过无数遍了，我能非常确定你的IO慢的问题在哪，既然你不肯测，我 ...

你说的这种方法提升写性能我能够理解，但这不是我要的那种。测试过程中只有我一个人在用，可以占用全部IO，数据会很好看。但是实际环境中IO并发一旦上去的话，stripe size太小的弊端就出现了。我以前也做过类似测试，最后得到一个经验就是stripe size是LTG的1~4倍比较合适。

另外刚刚在一台测试机上试了下，LTG Size是1MB。因为是单盘，没法做条带化，但是可以间接的说明些问题：
root@blade1[/tmp]#time dd if=/dev/zero of=/dev/rlvtest bs=1m count=5000
5000+0 records in.
5000+0 records out.

real 1m13.61s
user 0m0.01s
sys    0m1.78s
root@blade1[/tmp]#time dd if=/dev/zero of=/dev/rlvtest bs=512K count=5000
5000+0 records in.
5000+0 records out.

real 0m51.40s
user 0m0.01s
sys    0m0.92s
root@blade1[/tmp]#time dd if=/dev/zero of=/dev/rlvtest bs=512K count=10000
10000+0 records in.
10000+0 records out.

real 1m43.05s
user 0m0.03s
sys    0m1.85s

作者: mike79 时间: 2012-01-06 15:32

wdbj 发表于 2012-01-06 15:16
唉，你不测就算了，说实话这种测试我做过无数遍了，我能非常确定你的IO慢的问题在哪，既然你不肯测，我 ...

作者: wdbj 时间: 2012-01-06 15:44

mike79 发表于 2012-01-06 15:32
你说的这种方法提升写性能我能够理解，但这不是我要的那种。测试过程中只有我一个人在用，可以占用全部IO ...

不多说，随手找了个机器做了个测试

SLESa0428@~>vxassist -g wldg make vol1 1g layout=striped ncol=4 alloc=wldgdisk05,wldgdisk06,wldgdisk11,wldgdisk12 stripeunit=2m
SLESa0428@~>time dd if=/dev/zero of=/dev/vx/rdsk/wldg/vol1 bs=2048k count=100
100+0 records in
100+0 records out

real 0m11.285s
user 0m0.000s
sys 0m0.036s

SLESa0428@~>vxassist -g wldg remove volume vol1
SLESa0428@~>vxassist -g wldg make vol1 1g layout=striped ncol=4 alloc=wldgdisk05,wldgdisk06,wldgdisk11,wldgdisk12 stripeunit=256k
SLESa0428@~>time dd if=/dev/zero of=/dev/vx/rdsk/wldg/vol1 bs=2048k count=100
100+0 records in
100+0 records out

real 0m6.127s
user 0m0.000s
sys 0m0.034s
SLESa0428@~>

作者: wdbj 时间: 2012-01-06 15:47
本帖最后由 wdbj 于 2012-01-06 15:49 编辑

你能看到256k的stripe unit和2m的stripe unit在做一个单线程连续写的IO时的速度差别有多大

作者: 无牙 时间: 2012-01-06 15:51

mike79 发表于 2012-01-06 14:37
加载ALS应该是在DMP层面解决的吧？这个问题我也考虑过，但是现在用DMP作为多路径软件，然后建立LVM VG，再 ...

你有没有对比过用LVM和用VxVM时dmp的i/o策略是一样的吗？都是minimumq吗？

作者: mike79 时间: 2012-01-06 16:22

无牙发表于 2012-01-06 15:51
你有没有对比过用LVM和用VxVM时dmp的i/o策略是一样的吗？都是minimumq吗？

我没调整过，应该都是缺省值

作者: mike79 时间: 2012-01-06 16:26
本帖最后由 mike79 于 2012-01-06 16:46 编辑

wdbj 发表于 2012-01-06 15:47
你能看到256k的stripe unit和2m的stripe unit在做一个单线程连续写的IO时的速度差别有多大

我不是要单独追求MBPS，还要考虑IOPS。你这个方法以数倍的IOPS为代价，但是并没有获得相同倍数的MBPS，这不是我所想要的方法。
PS 我节后再做个测试看看。我怀疑其实stripe size设置成256KB也未必有效。因为读操作是正常的，不论是VxVM还是LVM都可以到100MBPS以上。

作者: wdbj 时间: 2012-01-06 16:45

mike79 发表于 2012-01-06 16:26
我不是要单独追求MBPS，还要考虑IOPS。你这个方法以数倍的IOPS为代价，但是并没有获得相同倍数的MBPS，这 ...

IO数没变啊兄弟，单盘的IO数是一样的，卷的IO数4x是因为使用了4个盘工作，既然你给这个卷分了4个盘，那让另外三个闲着不干活那不是浪费资源吗。
另外你如果非要保持2m的stripe Unit，把vol_maxio设成8m也能使速度提高，原理一样，但不推荐

作者: wolfheader 时间: 2012-01-09 11:56
根据老大们的建议
使用powerpath的时候可以到vxdiskadm把这几个盘的dmp排除掉

dd功能太弱了，试试iozone的-I测试directIO能更精确一点

作者: spook 时间: 2012-01-12 09:06
http://bbs.chinaunix.net/thread-1538453-1-1.html

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)