若是真正要將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