本文探讨了在使用PVFS2分布式文件系统时遇到的性能问题，尤其是IDE硬盘对性能的影响。文章指出，读写块大小增加会提升性能，并提供了优化建议，包括修改配置以提高性能、升级硬件、调整文件系统类型和缓冲设置等。此外，建议使用专业的存储设备或考虑使用Lustre替代PVFS2。
请教 PVFS2 性能提升的问题，请高手帮忙！！！！！！
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里面读,而不
请教 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
但是在实际的应用中，比较说用户去读取一个文件，是不是都是有一个默认的块大小？这个块的大小实际使用中是如何修改？或者说我如何调优性能！
非常谢谢！有没有高手帮忙
使用 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里面读,而不
最低0.47元/天 解锁文章
扫一扫
7619
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
