Difference: Condor_log_2017 (1 vs. 5)

Revision 52017-05-24 - JiangXiaowei

Line: 1 to 1
 
META TOPICPARENT name="Condor_log"

Title

Line: 100 to 100
 service condor start

-- jiang xiaowei - 2017-04-05

Added:
>
>
5月22日:

juno用户使用condor原生命令提交作业,并使用transfer方式,同时生成大量日志输出,导致计算节点本地盘占满。

解决:

删除该用户作业;

删除该用户在计算节点/var/lib/condor/execute目录下对应进程的目录;

通知该用户检查作业程序的日志输出,并建议使用hepjob提交作业。

-- jiang xiaowei - 2017-05-24

 
<--/commentPlugin-->

Revision 42017-04-05 - JiangXiaowei

Line: 1 to 1
 
META TOPICPARENT name="Condor_log"

Title

Line: 56 to 56
  3. 调整我们提供用户的作业管理工具命令程序,减少schedd服务器上shadow由于写日志对公共盘的访问。原有的hep_job 有-l选项,用于显示作业运行的condor进度,现将此选项屏蔽去除。
Added:
>
>
4月4日:

1、更改配置: SCHEDD_MAX_FILE_DESCRIPTORS = 30000 SHARED_PORT_MAX_FILE_DESCRIPTORS = 30000

2、重启condor以使以上配置生效:

condor_hold -all

service condor stop

service condor start

condor_release -all

3、由于操作等待时间较少,部分shadow未正常与计算节点释放,导致collector与schedd信息不同步。 第2步过程更正为:

condor_hold -all

等待shadow全部结束

service condor stop

service condor start

condor_release -all

 

Comments

Deleted:
<
<

<--/commentPlugin-->
 \ No newline at end of file
Added:
>
>
4月4日: 1、更改配置: SCHEDD_MAX_FILE_DESCRIPTORS = 30000 SHARED_PORT_MAX_FILE_DESCRIPTORS = 30000 2、重启condor以使以上配置生效: condor_hold -all service condor stop service condor start 3、由于操作等待时间较少,部分shadow未正常与计算节点释放,导致collector与schedd信息不同步。 第2步过程更正为: condor_hold -all 等待shadow全部结束 service condor stop service condor start

-- jiang xiaowei - 2017-04-05

<--/commentPlugin-->

Revision 32017-03-21 - ZouJiaheng

Line: 1 to 1
 
META TOPICPARENT name="Condor_log"

Title

Line: 40 to 40
  3月15日:
Changed:
<
<
job hung的问题原因找到并解决:
>
>
job hung的问题原因:
 
Changed:
<
<
1. 在计算平台上整体IO变大时,使得从htcondor服务器与计算节点的通信socket的时间变长,进而出现一个进程在连接的socket数量会越积越多。
>
>
1.每个作业都会定期(20分钟)与schedd通讯,发送keep alive消息;在作业向schedd的并发连接请求过多,超过open file默认的1024上限时,会导致keep alive发送失败;若某个作业在time out期限内都未能成功发送keep alive消息,schedd就会认为该作业已死,使得job hung并重新排队调度。
 
Changed:
<
<
2. 当达到htcondor服务器设置了open file的上限1024个时,socket也是被作为文件处理的。因此无法再生成新的socket,使调度器与计算节点不能正常联系,从而会认为节点上作业失败,而将该作业重新排队运行。经检查发现schedd的进程不止与shadow通信,还要与节点的startd通信,当socket连接由于读写io大时,延迟变大,则逐渐累积,超过1024个的上限时,就不无生成新的socket,猜测schedd与startd会有类似keep live的通信联系,慢慢增加。。无法再生成新socket时,会认为节点有问题,作业要重新排队。
>
>
2.原来boss.cordor的作业提交脚本延用了pbs的方式,即提交作业后将作业脚本删除,所以重新排队的作业因为找不到作业脚本而失败。
 
Changed:
<
<
3. 原来boss.cordor的作业提交脚本延用了pbs的方式,即提交作业后将作业脚本删除,所以重新排队的作业因为找不到作业脚本而失败。
>
>
3.另有磁盘卡顿时schedd owner会变为普通用户的情况,也会导致作业与schedd通讯失败;该情况与用户的condor日志模式关联性极大,并且condor开发人员也建议减少schedd服务器上shadow对公共盘的访问。(该问题未能在实验环境中重现,不能确认具体原因,但应该与shadow访问公共盘时的卡顿有关)
  现在做的调整包括:

1. 增加了htconodr服务器对每个进程可以open 文件(Socket)的上限。

Changed:
<
<
2. 调整我们提供用户的作业管理工具命令程序,减少作业由于写日志对磁盘的访问。原有的hep_job 有-l选项,用于显示作业运行的condor进度,现将此选项屏蔽去除。
>
>
2. 修改boss.condor, 提交作业后不再删除该作业的脚本。
 
Changed:
<
<
3. 修改boss.condor, 提交作业后不再删除该作业的脚本。
>
>
3. 调整我们提供用户的作业管理工具命令程序,减少schedd服务器上shadow由于写日志对公共盘的访问。原有的hep_job 有-l选项,用于显示作业运行的condor进度,现将此选项屏蔽去除。
 

Comments

Revision 22017-03-16 - ShiJingyan

Line: 1 to 1
 
META TOPICPARENT name="Condor_log"

Title

Line: 22 to 22
  出现多次作业hung后,掉作业情况。现象为condor_sched的属主变成了普通用户,当hung掉部分作业后,属主变回condor。当前scratchfs的访问一直比较慢,不确定是否有影响。
Added:
>
>
3月8日:

发现用户冯锋有恶意多占资源的情况。具体做法如下:

1. 用condor_status查看哪些用户或用户组可以使用更多资源。

2. 用condor_submit命令宣称自己的作业是以其它用户组别提交(发现宣称盗用了offline, lint, jiangxw等用户)

3. 作业的内容为在2170的端口启动sshd,然后sleep

4. 在登录结点上发启mpirun的大型并行作业,在所有占用的作业槽上运行

5. 在每个节点上的运行的mpi计算还将节点的所有cpu占用,并非只是调度器分配的一个cpu核,而是检测当前机器的所有cpu核数,运行同等进程。

发现后,删除该用户账号,联系用户要求其说明做法。用户狡辩几次后承认使用了不该用的资源。

3月15日:

job hung的问题原因找到并解决:

1. 在计算平台上整体IO变大时,使得从htcondor服务器与计算节点的通信socket的时间变长,进而出现一个进程在连接的socket数量会越积越多。

2. 当达到htcondor服务器设置了open file的上限1024个时,socket也是被作为文件处理的。因此无法再生成新的socket,使调度器与计算节点不能正常联系,从而会认为节点上作业失败,而将该作业重新排队运行。经检查发现schedd的进程不止与shadow通信,还要与节点的startd通信,当socket连接由于读写io大时,延迟变大,则逐渐累积,超过1024个的上限时,就不无生成新的socket,猜测schedd与startd会有类似keep live的通信联系,慢慢增加。。无法再生成新socket时,会认为节点有问题,作业要重新排队。

3. 原来boss.cordor的作业提交脚本延用了pbs的方式,即提交作业后将作业脚本删除,所以重新排队的作业因为找不到作业脚本而失败。

现在做的调整包括:

1. 增加了htconodr服务器对每个进程可以open 文件(Socket)的上限。

2. 调整我们提供用户的作业管理工具命令程序,减少作业由于写日志对磁盘的访问。原有的hep_job 有-l选项,用于显示作业运行的condor进度,现将此选项屏蔽去除。

3. 修改boss.condor, 提交作业后不再删除该作业的脚本。

 

Comments


<--/commentPlugin-->
\ No newline at end of file

Revision 12017-02-21 - ShiJingyan

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="Condor_log"

Title

Article text.

-- Shi Jingyan - 2017-02-21

1月29日

发现计算节点的配置文件有问题。配置文件是能程序生成的,在有些情况下的配置文件内容多了个引号,修改程序后,重新发布。节点正常,作业也调度正常。

2月1日-2月4日,

由于新上线的besfs3出现硬件故障,计算结点上进程不正常,使得startd进程死了。besfs3恢复后,此问题解决。

2月17日:

用户一批作业有快,有慢。。作业内容相同。经检查是用户的模拟作业要大量访问数据库,且每个数据库是长链接。BES3数据库由多台数据库组成,通过dns的轮询的方式进行负载均衡。所以连接有问题的数据库的作业都变得很慢。将此数据库从dns定义中去掉后,不再有慢作业出现。

2月20日:

出现多次作业hung后,掉作业情况。现象为condor_sched的属主变成了普通用户,当hung掉部分作业后,属主变回condor。当前scratchfs的访问一直比较慢,不确定是否有影响。

Comments


<--/commentPlugin-->
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback