pvfs提高性能的方法

请教 PVFS2 性能提升的问题，请高手帮忙！！！！！！

请教 PVFS2 性能提升的问题，请高手帮忙！！！！！！用PVFS2 搭建了一个 1 IO client，3 IO server的架构， IO server使用本地的 IDE硬盘。

使用 IOzone测试，在测试过程中，发现 读写的块越大，性能越好， 如下，第一列是文件大小，第一行为块大小,单位为kB：

64 128 256 512 1024 2048 4096 8192

32768 22417 31767 47938 65769 75807 83918 88573 88973

65536 20900 32689 42910 66529 77538 84766 87415 88472

131072 19465 34990 45330 65079 76348 82455 87738 87950

262144 20148 31539 45970 39854 77824 83332 88841 87776

524288 21090 33517 48185 64404 77262 84647 88657 87929

1048576 20079 24960 38063 45894 75932 61022 53082 50351

2097152 18595 30156 47571 49094 57575 83622 88007 88119



但是在实际的应用中，比较说用户去读取一个文件，是不是都是有一个默认的块大小？这个块的大小实际使用中是如何修改？或者说我如何调优性能！

非常谢谢！有没有高手帮忙

Hello,



目前分布式文件系统比如 PVFS, lustre, 对于大量小文件的操作性能都一塌糊涂,原因很清楚, 在分布式文件系统中,通过多个服务器组成的IO cluster 建立一个跨越物理节点的虚拟的文件系统,当用户请求IO的时候,如果请求操作的文件块,被条带化在多个物理节点上, 多个物理IO节点和metadata node协同工作,可以并发的操作你的数据, 比如一个500MB的文件被条带化在10个节点上,如果存储策略是等分的,每个IO node并发的存取1/10的这个文件, node数越多, 存取速度越快.

再来考虑小文件,比如16KB以下的文件, 当IO request过来的时候,metadata server发现这个data实际上并没有跨越在多个IO node上,而是位于一个server上,所以整个处理过程等同于IO client -> metadata server -> IO node, 当如果你有大量的小文件(<16KB)分布在若干个IO node上的时候, 存取的性能除了需要考虑单台IO node的IO延迟之外,还要加上整个分布式文件系统在同一读写的时候的元数据操作开销. 所以当你的数据文件尺寸越小, 整个文件系统的性能就越差.



回头说你的例子, 你每个IO node都是IDE 硬盘,IDE硬盘速度再快,但是并发性很差, 特别是大量数据(小文件)读写的时候,IDE硬盘的性能一败涂地, 更加不要说你的IDE channel和system bus之间的延迟了.

还有就是你选择IDE 硬盘的服务器+PVFS2正好是错误的选择,因为PVFS2和PVFS1还有lustre不一样,他的代码都是重新写的,而且用了分布式的 metadata ,PVFS2里面再也没有独立的一个metadata server存在了,也就是说,所有的IO node之间在每次IO操作,文件定位等等,都要比single metadata 的方案开销更大,有更多的延迟累加, 分布式的metadata设计+本来并发和IO都不太好的IDE硬盘的服务器, 你说性能会好么?PVFS2的重新设计,完全是定位在高端用户的,Argonne 国家实验室和Clemson大学的重新开发PVFS2的初衷就是使得这个分布式文件系统完全摆脱PVFS1的socket network的结构,这样新的高端集群互联设备比如Infiniband, Myrinet,Quadrics就可以派上用处了.



优化的方法不多,下面列几条你可以试试看:



1)如果你现在只是测试的话,你可以这样做, 你把配置文件当中<StorageHints>这个章节的"TroveSyncMeta"和"TroveSyncData" 从yes改为no, 这样性能应该会有看得到的提高,每次IO node之间同步metadata的时候,就直接从cache里面读,而不是去读metafile了,当然如果服务器挂掉,数据也就废了.



2)我建议你把节点的硬件配置提高, IDE硬盘的设备不适合作这种应用,尤其是和PVFS2这种连metadata都分布的系统一起工作. 节点之间的交换速度要尽可能得快,把交换机的自动协商关掉,mii-tool把linux的网卡的自动协商也关掉,速度定死在1000MB上.



3)如果你用的是RHEL4U2的话,它里面带的ext3和PVFS2一起工作会有问题,你得用U3或者mount你的IO node上的 ext3的时候,用noreservation的开关.否则会对PVFS2的性能造成影响.



4) 你如果一定要用PVFS2的话,就要明白PVFS2是读写文件块的时候,是不用cache机制的,只有metafile的属性控制彼此同步的时候会用 cache,所以不管你用bonnie++还是IOzone他们都是用来对本地文件系统作测试的,测试用的都是很小的文件区块,这种测试方法本身就是不正 确的,不管最后测试出来的结果如何,都不能正确的告诉你,你面前的这套PVFS2集群到底性能有多大.

测试并行分布式文件系统的工具有很多, PVFS2建议你用IOR (<a href="http://www.llnl.gov/asci/purple/benchmarks/limited/ior/)" _fcksavedurl=""http://www.llnl.gov/asci/purple/benchmarks/limited/ior/)"" target="_blank">http://www.llnl.gov/asci/purple/benchmarks/limited/ior/)</a>, 你可以去测试一下,不要太在意IOzone的测试结果,那个在并行文件系统上测得不准.



5)如果你没有Infiniband,Myrinet的高速互联和快速的scsi 服务器,并且你以后跑的应用不会用到PVFS2的MPI-IO, 我建议你可以考虑Lustre而不是PVFS2.



6). PVFS2的性能还和IO server上的local filesystem的类型有关系, jfs 性能最好,其次是ext2, 然后是xfs, 然后是ext3(用writeback日志策略),然后是reiserfs,然后是ext3(默认的日志策略是ordered).所以从兼容性和管理 等方面权衡,你可以用 ext3( mount -o data=writeback, writeback日志策略).



7) 检查你的IO server的 buffer 设置 /proc/sys/net/core/rmem_default 和 /proc/sys/net/core/wmem_default



性能诊断和优化是非常复杂的工作,特别是在分布式的文件系统上,你要对各种并行文件系统本身和linux系统还有你的应用环境有非常深刻地认识, 调优的过程通常就像一个跷跷板,做得不好的话,一头高了,一头就低下去了, 你需要在精通上面这些技术的基础上,设计出针对你最终应用的几种方案,以便于从offline的tuning转向online tuning的工作.



good luck,
我的一个朋友，在自己的一个HPC集群上，在每个节点上都划分出了一个分区，然后安装了lustre，每个节点既做为lustre的server和 client，同时也要做计算节点。发现一个有趣的现象，就是lustre装好了以后，在节点上跑计算程序，CPU的负载最高也就是50％，将 lustre卸掉之后就OK了，好像lustre预留了50％的CPU资源一样。按理说lustre是不提倡用户一个节点又做client又做 server的，所以我想也有可能是这方面的问题。

?顶楼并没有把client和server混合亚?



lustre不但不应该把client和server混，而且不应该和hpc cluster混在一起.

我说的人不是楼主，是我的一个朋友，HOHO



没错，lustre是不应该把client和server混装，但是软件本身并没有作这样的限制。我觉得如果要专门搞一个集群来作存储的话，不如买专业的存储设备了。更何况现在的PVFS、Lustre这些在性能、稳定性、冗余方面都实现的不是非常好。



欧洲的CERN据说用的是AFS，将很多国家的HPC集群都互联了起来。最近正在看GFS、AFS、GPFS。

用PVFS2 搭建了一个 1 IO client，3 IO server的架构， IO server使用本地的 IDE硬盘。
使用 IOzone测试，在测试过程中，发现 读写的块越大，性能越好， 如下，第一列是文件大小，第一行为块大小,单位为kB：
64 128 256 512 1024 2048 4096 8192
32768 22417 31767 47938 65769 75807 83918 88573 88973
65536 20900 32689 42910 66529 77538 84766 87415 88472
131072 19465 34990 45330 65079 76348 82455 87738 87950
262144 20148 31539 45970 39854 77824 83332 88841 87776
524288 21090 33517 48185 64404 77262 84647 88657 87929
1048576 20079 24960 38063 45894 75932 61022 53082 50351
2097152 18595 30156 47571 49094 57575 83622 88007 88119

但是在实际的应用中，比较说用户去读取一个文件，是不是都是有一个默认的块大小？这个块的大小实际使用中是如何修改？或者说我如何调优性能！
非常谢谢！有没有高手帮忙

---

作者: nntp 时间: 2006-6-23 18:43

Hello,

目前分布式文件系统比如 PVFS, lustre, 对于大量小文件的操作性能都一塌糊涂,原因很清楚, 在分布式文件系统中,通过多个服务器组成的IO cluster 建立一个跨越物理节点的虚拟的文件系统,当用户请求IO的时候,如果请求操作的文件块,被条带化在多个物理节点上, 多个物理IO节点和metadata node协同工作,可以并发的操作你的数据, 比如一个500MB的文件被条带化在10个节点上,如果存储策略是等分的,每个IO node并发的存取1/10的这个文件, node数越多, 存取速度越快.
再来考虑小文件,比如16KB以下的文件, 当IO request过来的时候,metadata server发现这个data实际上并没有跨越在多个IO node上,而是位于一个server上,所以整个处理过程等同于IO client -> metadata server -> IO node, 当如果你有大量的小文件(<16KB)分布在若干个IO node上的时候, 存取的性能除了需要考虑单台IO node的IO延迟之外,还要加上整个分布式文件系统在同一读写的时候的元数据操作开销. 所以当你的数据文件尺寸越小, 整个文件系统的性能就越差.

回头说你的例子, 你每个IO node都是IDE 硬盘,IDE硬盘速度再快,但是并发性很差, 特别是大量数据(小文件)读写的时候,IDE硬盘的性能一败涂地, 更加不要说你的IDE channel和system bus之间的延迟了.
还有就是你选择IDE 硬盘的服务器+PVFS2正好是错误的选择,因为PVFS2和PVFS1还有lustre不一样,他的代码都是重新写的,而且用了分布式的 metadata ,PVFS2里面再也没有独立的一个metadata server存在了,也就是说,所有的IO node之间在每次IO操作,文件定位等等,都要比single metadata 的方案开销更大,有更多的延迟累加, 分布式的metadata设计+本来并发和IO都不太好的IDE硬盘的服务器, 你说性能会好么?PVFS2的重新设计,完全是定位在高端用户的,Argonne 国家实验室和Clemson大学的重新开发PVFS2的初衷就是使得这个分布式文件系统完全摆脱PVFS1的socket network的结构,这样新的高端集群互联设备比如Infiniband, Myrinet,Quadrics就可以派上用处了.

优化的方法不多,下面列几条你可以试试看:

1)如果你现在只是测试的话,你可以这样做, 你把配置文件当中<StorageHints>这个章节的"TroveSyncMeta"和"TroveSyncData" 从yes改为no, 这样性能应该会有看得到的提高,每次IO node之间同步metadata的时候,就直接从cache里面读,而不是去读metafile了,当然如果服务器挂掉,数据也就废了.

2)我建议你把节点的硬件配置提高, IDE硬盘的设备不适合作这种应用,尤其是和PVFS2这种连metadata都分布的系统一起工作. 节点之间的交换速度要尽可能得快,把交换机的自动协商关掉,mii-tool把linux的网卡的自动协商也关掉,速度定死在1000MB上.

3)如果你用的是RHEL4U2的话,它里面带的ext3和PVFS2一起工作会有问题,你得用U3或者mount你的IO node上的 ext3的时候,用noreservation的开关.否则会对PVFS2的性能造成影响.

4) 你如果一定要用PVFS2的话,就要明白PVFS2是读写文件块的时候,是不用cache机制的,只有metafile的属性控制彼此同步的时候会用 cache,所以不管你用bonnie++还是IOzone他们都是用来对本地文件系统作测试的,测试用的都是很小的文件区块,这种测试方法本身就是不正 确的,不管最后测试出来的结果如何,都不能正确的告诉你,你面前的这套PVFS2集群到底性能有多大.
测试并行分布式文件系统的工具有很多, PVFS2建议你用IOR (http://www.llnl.gov/asci/purple/benchmarks/limited/ior/), 你可以去测试一下,不要太在意IOzone的测试结果,那个在并行文件系统上测得不准.

5)如果你没有Infiniband,Myrinet的高速互联和快速的scsi 服务器,并且你以后跑的应用不会用到PVFS2的MPI-IO, 我建议你可以考虑Lustre而不是PVFS2.

6). PVFS2的性能还和IO server上的local filesystem的类型有关系, jfs 性能最好,其次是ext2, 然后是xfs, 然后是ext3(用writeback日志策略),然后是reiserfs,然后是ext3(默认的日志策略是ordered).所以从兼容性和管理 等方面权衡,你可以用 ext3( mount -o data=writeback, writeback日志策略).

7) 检查你的IO server的 buffer 设置 /proc/sys/net/core/rmem_default 和 /proc/sys/net/core/wmem_default

性能诊断和优化是非常复杂的工作,特别是在分布式的文件系统上,你要对各种并行文件系统本身和linux系统还有你的应用环境有非常深刻地认识, 调优的过程通常就像一个跷跷板,做得不好的话,一头高了,一头就低下去了, 你需要在精通上面这些技术的基础上,设计出针对你最终应用的几种方案,以便于从offline的tuning转向online tuning的工作.

good luck,

---

作者: kartwall 时间: 2006-6-23 23:20

我的一个朋友，在自己的一个 HPC集群上，在每个节点上都划分出了一个分区，然后安装了lustre，每个节点既做为lustre的server和client，同时也要做计算节 点。发现一个有趣的现象，就是lustre装好了以后，在节点上跑计算程序，CPU的负载最高也就是50％，将lustre卸掉之后就OK了，好像 lustre预留了50％的CPU资源一样。按理说lustre是不提倡用户一个节点又做client又做server的，所以我想也有可能是这方面的问 题。

---

作者: nntp 时间: 2006-6-24 10:11

?顶楼并没有把client和server混合亚?

lustre不但不应该把client和server混，而且不应该和hpc cluster混在一起.

---

作者: kartwall 时间: 2006-6-24 10:43

我说的人不是楼主，是我的一个朋友，HOHO

没错，lustre是不应该把client和server混装，但是软件本身并没有作这样的限制。我觉得如果要专门搞一个集群来作存储的话，不如买专业的存储设备了。更何况现在的PVFS、Lustre这些在性能、稳定性、冗余方面都实现的不是非常好。

欧洲的CERN据说用的是AFS，将很多国家的HPC集群都互联了起来。最近正在看GFS、AFS、GPFS。

---

作者: nntp 时间: 2006-6-24 12:56

QUOTE:

原帖由 kartwall 于 2006-6-24 10:43 发表
我说的人不是楼主，是我的一个朋友，HOHO

没错，lustre是不应该把client和server混装，但是软件本身并没有作这样的限制。我觉得如果要专门搞一个集群来作存储的话，不如买专业的存储设备了。更何况现在的PVFS、 ...

lustre 本来就是提供一个存储的集群，软件没有限制，但是有设计和性能上的考量。而且专业的存储(如果你说专业存储就是普通的DAS/NAS/SAN的话) 和lustre 不是互为独立而是整合在一起的.HP有一个高端的SFS存储方案，基于lustre production version, 每个OST通过两个独立的阵列卡，连接到8台DAS 阵列. 一套SFS一共4个OST, 2个互为HA的MDS. 这是低端的配置，高端的配置是EVA3000/4000光纤阵列连接OST server. 从1T-1024T，IO带宽从35G/s -115G/s.

欧洲的CERN的确是采用AFS,不过你说的"将很多国家的HPC集群都互联了起来" 其实和parallel filesystem没有关系，应该是CERN主持的Euro-Grid.
CERN当初选择parallel filesystem的时候，是根据自己的应用特点和特定要求，作了针对自己业务的选择的。CERN IT运营部门的Rainer Többicke 当时针对外界对他们选择 AFS的问题在不同的会议上作了解释. 你搜 "Rainer Többicke - AFS at CERN" 应该就可以看到03年的时候 Rainer的一个介绍.当时IBM吃掉了AFS, lustre还不够成熟，CERN选择AFS是有特定的原因的(推动CERN购买AFS的原因还有IBM在CERN超级计算机的大单).

偷偷澄清一下,GFS(sistina/RedHat的么?)和AFS不是一种东西，前者是集群文件系统，后者是分布式文件系统.
我个人比较关注Lustre, lustre现在表现出越来越多的技术优势。我看你几次提到AFS, GPFS，是不是你们单位买了很多IBM的东西？或者和IBM技术部门关系比较密切? :") 开个玩笑.
我记的中国气象局那个21.76TFlops的集群用的也是GPFS.

欢迎你和你的朋友多来这里参加讨论.

[ 本帖最后由 nntp 于 2006-6-24 12:59 编辑 ]

---

作者: kartwall 时间: 2006-6-24 13:28

非常感谢NNTP给出的专业建议，我对你帖子中展现出来的宽阔的知识面相当的敬佩，我想NNTP在这个领域是不是已经耕耘了很多年了？：）

事实上，我不是高性能计算的用户，而是在一个从事高性能计算相关的技术公司工作，所以，接触到了HPC相关的一些东西。有NNTP的专业建议在，我想我一定会常来这里，向你讨教问题。

---

作者: jiangyi_hust 时间: 2006-6-24 14:20

NNTP的确十分的专业，我很多朋友都知道你（当然是在网络上）。
回Kartwall，nntp：你们可以拿到 GPFS的安装包么？这个似乎很难得到

多谢回复
正在改用 外置scsi磁盘阵列，ext2文件系统。再使用IOR测试。。。

---

作者: nntp 时间: 2006-6-24 17:12

QUOTE:

原帖由 kartwall 于 2006-6-24 13:28 发表
非常感谢NNTP给出的专业建议，我对你帖子中展现出来的宽阔的知识面相当的敬佩，我想NNTP在这个领域是不是已经耕耘了很多年了？：）

事实上，我不是高性能计算的用户，而是在一个从事高性能计算相关的技术公司工 ...

讨教真的不敢当，多交流吧.

---

作者: nntp 时间: 2006-6-24 17:19

QUOTE:

原帖由 jiangyi_hust 于 2006-6-24 14:20 发表
NNTP的确十分的专业，我很多朋友都知道你（当然是在网络上）。
回Kartwall，nntp：你们可以拿到 GPFS的安装包么？这个似乎很难得到

多谢回复
正在改用 外置scsi磁盘阵列，ext2文件系统。再使用IOR测试。。。

Hi, 一点tips:

1)scsi盘阵一定得选好了，小文件的在分布式文件系统上的问题对于你的底层硬件敏感度很高, 我们以前测试过好多种磁盘柜.
最完美的就是低延迟的scsi JBOD设备,配备有非常高速的磁盘控制器和磁盘，比如SAS或SATAII,如果可以调整NCQ就最好了. 因为我以往的经验都来自于有时间限制的项目，
虽然用的设备都很高端，但是无法测试更多的第三方产品，有条件的话你们可以测一些，效果差异还是很大的。阵列的配置也有讲究.
2)ext3 writeback 基本上等于ext2, 在PVFS2环境性能差别很小，但是如果机器挂掉，可以省fsck时间，推荐之。还有反正是测试，你们可以用用jfs,我估计可能会有惊喜。

---

作者: myprotein 时间: 2006-9-26 12:50

这个帖子我反复看了n遍，每次看完其他文档之后，再回顾一下这个帖子，发现都能有新的收获
谢谢nntp