Tags:
create new tag
view all tags

September

9.2~9.7 (数据和测试作业出错)

  • 8月31日~9月1日 SE出现各命令timeout, 服务正常。重启后,症状缓和,但是过一会又出现堵塞。原因:作业对SE的连接数操作系统承受值。加大数据库连接数,问题解决。
  • 9月2日 dcap命令失败,在cmspn03.ihep.ac.cn的dcap log中 /var/log/dcap-cmspn03Domain.log 出现错误:open too many files。原因:系统允许打开的最大文件数不够。加大系统最大文件数后,问题解决。
  • 周作业总结:
(1)Test作业:   31, 1, 2日,测试作业成功率~50%。
(2)作业总数:17104, 成功率68%,application 26%, grid 6%。
(3)production: 6100/21000   Analysis:2100/4439
(4)错误原因和解决方法:如前面所述
* 周传输总结:
第一个SE错误影响了传输,31,1日传输出错。
状态:传入6.8TB,传出5TB

9.8~9.22 (测试作业和传输正常->分析作业少->FileOpen错误多)

  • 9月13日 jobRobot 96%,发现jobRobot测试数据集少了一个文件,补上这个文件,就恢复到100% * 9月20日 CMS用户发现某些文件读取不了,经检查,这些文件集中在某个pool上,加大这个pool的mover数,问题就解决了。
  • 周作业总结:
(1)Test作业:   测试作业成功率~100%,除了13日,96%。
(2)作业总数:38621, 成功率88%,application 9%, grid 3%。
(3)production: 450/22670   Analysis:3600/5802
(4)错误原因和解决方法:主要的appliation错误在13日,FileOpen Error,由于CMS用户申请删除了一些数据。
  • 周传输总结:
正常
状态:传入18.45TB,传出9TB

9.23~10.8 (作业和传输出问题->主要原因作业多->使得SE和CE出现过载)

  • 9.24 creamce critical -> "too many files" 重启后问题解决
  • 9.25 se服务掉了,admin的服务死了因为java.lang.OutOfMemoryError: Java heap space 加大dcacheSetup java memory, 重启后问题解决 主要原因:queue作业超过3000,运行大约1000 * 9.26 cce错误,一个计算节点出问题
        "100 CREAM_EX CREAM Register raised std::exception Connection to service 
        [https://cce.ihep.ac.cn:8443/ce-cream/services/CREAM2] failed: FaultString=[connection error] - FaultCode=[SOAP-ENV:Client] - FaultSubCode=[SOAP-ENV:Client] - FaultDetail=[Connection refused]
        Done
        90 UNKNOWN pbs_reason=-1"
        

October

10.9~10.17 (作业和传输出错->文件打开太多导致SE过载)

  • 10.12 SE出错,pool disabled, I/O tests failed.重启后恢复. 主要原因仍然是需要打开文件数太多,服务出现过载

November

11.1~11.8 (测试作业和传输正常->主要为分析作业->downtime和"memory"问题)

  • 11月3日 downtime
  • 11月4日 cms 用户作业占用大量memory, 导致结点死机
  • 周作业总结:
(1)Test作业:   测试作业成功率~100%,除了downtime。
(2)作业总数:37376, 成功率40%,application 6%, grid 54%。
(3)主要是分析作业(失败/总数): 22650/30530 
(4)错误原因和解决方法:大部分失败作业发生在downtime,部分因为4日memory问题,建议在本地调度系统对作业的内存使用和磁盘使用进行限制,CMS上层调度还没有有效的工具来控制。
  • 周传输总结:
正常
状态:传入7.8TB,传出5TB

11.9~11.16 (测试作业和传输正常->主要为分析作业->grid的"LB communicate error")

  • 周作业总结:
(1)Test作业:   测试作业成功率~100%。
(2)作业总数:23077, 成功率66%,application 10%, grid 24%。
(3)主要是分析作业(失败/总数): 7400/14477 
(4)错误原因和解决方法:大部分失败作业发生在10日,11日,大部分原因是LB communicate error, 部分原因是cce critical。
  • 周传输总结:
正常
状态:传入15TB,传出5TB

11.17~11.24 (测试作业和传输正常->主要为分析作业->用户配置错误)

  • 周作业总结:
(1)Test作业:   测试作业成功率~100%。
(2)作业总数:19453, 成功率66%,application 8%, grid 28%。
(3)(失败/总数): 分析作业:7700/11188,  Production作业:1/781
(4)错误原因和解决方法:大部分原因是用户配置错误。
  • 周传输总结:
正常
状态:传入6TB,传出5TB

11.25~12.2 (测试作业和传输错误->数据文件不能正常读出)

  • 周作业总结:
(1)Test作业:   测试作业成功率~92%。部分测试数据不能正常读出。
(2)作业总数:15324, 成功率66%,application 6%, grid 25%, 原因是数据文件不能打开。
(3)(失败/总数): 分析作业:820/9703,  Production作业:0/84
(4)错误原因和解决方法:部分数据文件出现不能正常读出,显示数据存在,但是使用dccp和srmcp都不能将数据拷出,
   上次dcache硬盘坏了造成数据损坏。现已经将部分测试作业数据和传输测试数据补上,
  • 周传输总结:
错误:向Beijing传输的链路正常,Beijing向外传输的测试大部分出现错误。

December

12.3~12.10 (测试作业和传输基本正常->发现pilot作业使用大量磁盘空间)

  • 周作业总结:
(1)Test作业:   测试作业成功率100%, 除了4日,5日SAM tests为84%,92%。
(2)作业总数:12606, 成功率91%,application 4%, grid 5%。
(3)(失败/总数): 分析作业:570/3855,  Production作业:0/2235
(4)错误原因和解决方法:本周发现部分CMS pilot作业在多个站点使用大量磁盘空间,包括北京站点。
原因包括用户错误配置crab等.唯一的解决办法是站点自我保护,找到用户DN,杀掉该用户,或者将其暂时列入站点黑名单
另:CMS对作业使用磁盘空间的限制规定: < 10GB/job
  • 周传输总结:
正常
状态:传入11.6TB,传出5.32TB
Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2011-12-21 - ZhangXiaomei
 
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