目录
如果真正要将HTCondor高通量计算产品化还需要很多工作要做,HTCondor并没有GUI界面,更多更全面的功能在Linux系统下的命令窗口下更方便。
拆分任务也是使用者值得考虑的问题,很多的密集运算其实不太方便拆分,拆分后大概率要进行合并操作,这种合并操作可能也相当耗时,且只能单机运算不能进行分布式计算。拆分任务还需要一定的经验,即如何保证负载均衡,让所有的任务同时完成。
文件访问也是个值得研究的问题。Windows下回默认使用文件传输机制,也就是将数据随着任务程序发送到任务机上区运行,这种方式往往会造成巨大的IO阻塞;再运行完成后,传送的数据又会被清空删除,也造成了IO性能浪费。所以,如果条件允许的情况下,最好还是使用分布式文件管理系统,当然这又是另外一个问题。
Windows下使用的vanilla模式部分功能还是受限的:
HTCondor本身的计算资源是按照CPU的核心数划分的;这一点也很值得商榷。如果给一个8核的机器提交任务,这台机器就会同时运行8个任务,如果恰好这个任务是与IO密集相关的,就会造成IO性能的浪费。毕竟硬盘总是只有一个磁头,单个磁头在磁盘中反复移动,会造成磁盘的损耗。而且CPU可以按照核心数划分,那么GPU资源呢?对于基于GPU计算的任务程序该如何划分呢?很多实际的情况下可能是把一台机器作为一个节点更合理一些。
为了达到更好的性能,我曾经简单的采用文件共享机制的办法。也就是HTCondor的任务程序虽然无法访问网络资源,但是可以在计算之前把文件共享做好,把需要的数据提前传送到任务机器上去,保证任务程序访问本地资源即可。这样发送的数据可以反复使用,有助于后续任务的执行效率。这种办法怎么说呢,除非你对网络文件共享那一套非常熟悉,否则建议不要这么做。
这一段的意思是更后台condor_credd进程有关,需要配置相关的环境。但是我根据7.2.5节"The condor_credd Daemon"进行配置并没有成功,有兴趣的童靴可以自己试一试。