高通量计算框架HTCondor(六)——拾遗

简介: 高通量计算框架HTCondor(六)——拾遗

高通量计算框架HTCondor(六)——拾遗

目录

1. 正文

1.1. 一些问题

如果真正要将HTCondor高通量计算产品化还需要很多工作要做,HTCondor并没有GUI界面,更多更全面的功能在Linux系统下的命令窗口下更方便。

拆分任务也是使用者值得考虑的问题,很多的密集运算其实不太方便拆分,拆分后大概率要进行合并操作,这种合并操作可能也相当耗时,且只能单机运算不能进行分布式计算。拆分任务还需要一定的经验,即如何保证负载均衡,让所有的任务同时完成。

文件访问也是个值得研究的问题。Windows下回默认使用文件传输机制,也就是将数据随着任务程序发送到任务机上区运行,这种方式往往会造成巨大的IO阻塞;再运行完成后,传送的数据又会被清空删除,也造成了IO性能浪费。所以,如果条件允许的情况下,最好还是使用分布式文件管理系统,当然这又是另外一个问题。

Windows下使用的vanilla模式部分功能还是受限的:

  1. 是发送到任务机的任务程序无法访问任务机的网络地址资源,这是由于安全策略决定的;
  2. 发送的任务程序被进一步封装了,默认参数有改变;
  3. 在任务机计算资源存在问题时,不能自动迁移以及断点续作。这个功能对于HTC来说是比较重要的,HTC处理的就是稳定的进行规模运算的问题。这个问题也需要进一步深究。

HTCondor本身的计算资源是按照CPU的核心数划分的;这一点也很值得商榷。如果给一个8核的机器提交任务,这台机器就会同时运行8个任务,如果恰好这个任务是与IO密集相关的,就会造成IO性能的浪费。毕竟硬盘总是只有一个磁头,单个磁头在磁盘中反复移动,会造成磁盘的损耗。而且CPU可以按照核心数划分,那么GPU资源呢?对于基于GPU计算的任务程序该如何划分呢?很多实际的情况下可能是把一台机器作为一个节点更合理一些。

为了达到更好的性能,我曾经简单的采用文件共享机制的办法。也就是HTCondor的任务程序虽然无法访问网络资源,但是可以在计算之前把文件共享做好,把需要的数据提前传送到任务机器上去,保证任务程序访问本地资源即可。这样发送的数据可以反复使用,有助于后续任务的执行效率。这种办法怎么说呢,除非你对网络文件共享那一套非常熟悉,否则建议不要这么做。

1.2. 使用建议

  1. condor_q显示任务为H也就是挂起,说明发送的任务程序可能无法正常运行,一般是任务机器缺少必要的运行环境如一些dll。
  2. 网络环境需要保持稳定。一些安全软件、防火墙、网络工具可能会造成网络环境的变动,造成任务无法执行。上一篇的实例是基于本地局域网的。
  3. HTC更强调稳定性而不仅是高性能,所有的改动都要基于这个原则。
  4. HTCondor有设置任务队列优先级运行的功能condor_prio,可以查看文档内相关的说明。
  5. 在HTCondor帮助文档的7.2.4节"Executing Jobs as the Submitting User"提到了访问任务程序网络资源的问题:

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 = True

这一段的意思是更后台condor_credd进程有关,需要配置相关的环境。但是我根据7.2.5节"The condor_credd Daemon"进行配置并没有成功,有兴趣的童靴可以自己试一试。

2. 相关

上一篇

目录

分类: 分布式计算

标签: 分布式计算 , 集群计算 , HTCondor


相关文章
|
5月前
|
分布式计算 负载均衡 数据处理
高通量计算框架HTCondor(四)——案例准备
高通量计算框架HTCondor(四)——案例准备
56 0
|
5月前
|
分布式计算 数据安全/隐私保护
高通量计算框架HTCondor(三)——使用命令
高通量计算框架HTCondor(三)——使用命令
68 0
|
5月前
|
分布式计算 Windows
高通量计算框架HTCondor(五)——分布计算
高通量计算框架HTCondor(五)——分布计算
69 0
|
5月前
|
算法 C++
惊爆!KPM算法背后的秘密武器:一行代码揭秘字符串最小周期的终极奥义,让你秒变编程界周期大师!
【8月更文挑战第4天】字符串最小周期问题旨在找出字符串中最短重复子串的长度。KPM(实为KMP,Knuth-Morris-Pratt)算法,虽主要用于字符串匹配,但其生成的前缀函数(next数组)也可用于求解最小周期。核心思想是构建LPS数组,记录模式串中每个位置的最长相等前后缀长度。对于长度为n的字符串S,其最小周期T可通过公式ans = n - LPS[n-1]求得。通过分析周期字符串的特性,可证明该方法的有效性。提供的C++示例代码展示了如何计算给定字符串的最小周期,体现了KPM算法在解决此类问题上的高效性。
100 0
|
8月前
|
机器学习/深度学习 人工智能 数据可视化
号称能打败MLP的KAN到底行不行?数学核心原理全面解析
Kolmogorov-Arnold Networks (KANs) 是一种新型神经网络架构,挑战了多层感知器(mlp)的基础,通过在权重而非节点上使用可学习的激活函数(如b样条),提高了准确性和可解释性。KANs利用Kolmogorov-Arnold表示定理,将复杂函数分解为简单函数的组合,简化了神经网络的近似过程。与mlp相比,KAN在参数量较少的情况下能达到类似或更好的性能,并能直观地可视化,增强了模型的可解释性。尽管仍需更多研究验证其优势,KAN为深度学习领域带来了新的思路。
2942 5
|
Web App开发 调度 Windows
开源代码分享(8)—大规模电动汽车时空耦合双层优化调度(附matlab代码)
本文研究了发电机、电动汽车和风能的协同优化调度问题。提出了一种新颖的双层优化方法,用于解决在风能存在的情况下,电动汽车充放电负荷在时间和空间领域的调度问题。在输电系统中,上层优化协调了电动汽车、热发电机和基本负荷,考虑了风能因素,优化了电动汽车在时间域内的负荷时段。在配电系统中,下层优化则对电动汽车负荷的位置进行空间调度。通过对一个拥有10台发电机的输电网和一个IEEE 33节点的配电网的电力系统基准进行评估,评估了提出的双层优化策略的性能。分析了电价曲线、电动汽车普及率以及电动汽车负荷位置等因素的影响。
|
PyTorch 算法框架/工具
pytorch诞生逻辑和演化过程
pytorch诞生逻辑和演化过程
96 0
|
机器学习/深度学习 算法 数据挖掘
浙大发布「数据混合增强」框架AutoMix,还顺手开源了众多mixup算法(1)
浙大发布「数据混合增强」框架AutoMix,还顺手开源了众多mixup算法
205 0
|
编解码 算法 数据挖掘
浙大发布「数据混合增强」框架AutoMix,还顺手开源了众多mixup算法(2)
浙大发布「数据混合增强」框架AutoMix,还顺手开源了众多mixup算法
324 0
|
算法 C++
<<算法很美>>——(五)——回溯算法核心框架(上)
<<算法很美>>——(五)——回溯算法核心框架(上)
<<算法很美>>——(五)——回溯算法核心框架(上)