|
|
继续引用CU上面nntp的帖子，对我启发非常大，让我更清楚地意识到目前的应用可能需要什么方案：
Q:
用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
但是在实际的应用中，比较说用户去读取一个文件，是不是都是有一个默认的块大小？这个块的大小实际使用中是如何修改？或者说我如何调优性能！
非常谢谢！有没有高手帮忙
A:
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, |
评分
-
查看全部评分
|
楼主: ubuntuhk
发表于 27-6-2009 20:01:36
楼主
)
