动态I/O转发节点分配系统(Dynamic forwarding resource allocation)
-
动态I/O转发节点分配系统(Dynamic forwarding resource allocation)的使用介绍和问题讨论。
欢迎这个板块讨论。 或者发我的邮箱sov.matrixac@gmail.com 微信号Sov_Matrix
-
简介
DFRA（Dynamic forwarding resource allication）是神威太湖之光上动态调整I/O代理转发层配置（参考前面的文档）的工具，通过学习作业的历史信息，解决I/O代理转发资源不足，I/O干扰的问题。对于高I/O需求的作业，I/O性能最高可能提升20倍。我们建议所有的高I/O需求的课题使用这一工具。
使用方法：
在作业提交系统bsub加入相应的参数来触发DFRA：
-fs_proj onlineX其中X是1或者2.表示你使用的是online1文件系统或者online2文件系统。
一个具体一点的例子,在online1上提交某个作业：bsub -fs_proj online1 -I -q your_queue_name -n your_process_num your_job常见问题：
如果出现下列提示：
fs_adjust for project <onlineX> failed, ret = -1. Job XXXXX has been finished. exit_code is 121可能是因为DFRA服务器的暂时不可用导致的或者有的节点的文件系统出现问题导致暂时不可用，连续出现可以暂时去掉整个-fs_proj 保证任务正常提交
-
萌萌哒 不符合 @jixu 的气质
-
详细唠唠神威DFRA原理呗
-
@qazserfv 您要是有兴趣的话，我们可以给您看一下我们的文章。这里先简单跟您说一下我们的原理：
首先在我们神威太湖之光的存储系统上，计算节点的I/O并不是直接连接到后端的存储节点上去的，而是通过中间的一层：我们叫做I/O转发层。这种架构可以帮助构建一个轻量级的操作系统内核，同时减少网络拓扑的复杂性。
但是不幸的是，测试发现，应用程序的I/O性能经常会卡在这一层上：在神威上，计算节点到I/O转发节点的映射是静态的，计算节点到I/O转发节点的比例是512-1. 而进一步研究发现，一个I/O密集程序，到达最好的性能的时候的这个比例是32-1。 但是如果全部计算节点的配置都是32-1的话，I/O转发节点就不足了（经费原因，我们没有买那么多I/O转发节点）。所以我们就使用了这么一套动态转发的机制，我们会查看应用程序的历史，评估应用程序是否是I/O密集的（读写很大量的文件）。然后再作业真正运行之前，修改好计算节点到I/O转发节点的映射，也就是为作业提供更多的I/O转发节点。这种最好可以带来差不多20倍的性能提升(读带宽从1GB/s提升到了20GB/s)。
另外的一个问题是I/O冲突的问题：共享I/O代理转发节点会造成很严重的I/O性能下降，最严重的情况可能性能只是正常性能的1%。我们的监控系统Beacon会帮助我们找到相互冲突的I/O程序。如果您应用在运行之前，已经发现了一些很重I/O的应用程序跟您一起共享某些I/O转发节点，我们会调整您的I/O转发，将他们重新映射到新的转发节点上，避免I/O的性能下降。
-
@jixu 你们的文章可以在哪里下载到？？我好好学习一下
或者你直接发个链接
-
@qazserfv 我加一下您的微信吧？？
-
@jixu 其实你可以直接在论坛里私聊的。。。
-
@jixu 论坛作者还是很用心的做事情的
-
@popo 是的, 赵老师是个好全栈...
