若是真正要将HTCondor高通量计算产品化还须要不少工做要作,HTCondor并无GUI界面,更多更全面的功能在Linux系统下的命令窗口下更方便。安全
拆分任务也是使用者值得考虑的问题,不少的密集运算其实不太方便拆分,拆分后大几率要进行合并操做,这种合并操做可能也至关耗时,且只能单机运算不能进行分布式计算。拆分任务还须要必定的经验,即如何保证负载均衡,让全部的任务同时完成。网络
文件访问也是个值得研究的问题。Windows下回默认使用文件传输机制,也就是将数据随着任务程序发送到任务机上区运行,这种方式每每会形成巨大的IO阻塞;再运行完成后,传送的数据又会被清空删除,也形成了IO性能浪费。因此,若是条件容许的状况下,最好仍是使用分布式文件管理系统,固然这又是另一个问题。负载均衡
Windows下使用的vanilla模式部分功能仍是受限的:分布式
HTCondor自己的计算资源是按照CPU的核心数划分的;这一点也很值得商榷。若是给一个8核的机器提交任务,这台机器就会同时运行8个任务,若是刚好这个任务是与IO密集相关的,就会形成IO性能的浪费。毕竟硬盘老是只有一个磁头,单个磁头在磁盘中反复移动,会形成磁盘的损耗。并且CPU能够按照核心数划分,那么GPU资源呢?对于基于GPU计算的任务程序该如何划分呢?不少实际的状况下多是把一台机器做为一个节点更合理一些。工具
为了达到更好的性能,我曾经简单的采用文件共享机制的办法。也就是HTCondor的任务程序虽然没法访问网络资源,可是能够在计算以前把文件共享作好,把须要的数据提早传送到任务机器上去,保证任务程序访问本地资源便可。这样发送的数据能够反复使用,有助于后续任务的执行效率。这种办法怎么说呢,除非你对网络文件共享那一套很是熟悉,不然建议不要这么作。性能
在HTCondor帮助文档的7.2.4节"Executing Jobs as the Submitting User"提到了访问任务程序网络资源的问题:ui
By default, HTCondor executes jobs on Windows using dedicated run accounts that have minimal access rights and privileges, and which are recreated for each new job. As an alternative, HTCondor can be configured to allow users to run jobs using their Windows login accounts. This may be useful if jobs need access to files on a network share, or to other resources that are not available to the low-privilege run account.
This feature requires use of a condor_credd daemon for secure password storage and retrieval. With the condor_credd daemon running, the user’s password must be stored, using the condor_store_cred tool. Then, a user that wants a job to run using their own account places into the job’s submit description file
run_as_owner = Truehtm
这一段的意思是更后台condor_credd进程有关,须要配置相关的环境。可是我根据7.2.5节"The condor_credd Daemon"进行配置并无成功,有兴趣的童靴能够本身试一试。blog