一种在线任务的实时监控和自动处理方法

技术领域

本发明涉及半导体技术领域，特别是涉及一种在线任务的实时监控和自动处理方法。

背景技术

目前的流片(Tape out)工作中发现，某些任务在运行的过程中会发生异常完成的现象，这些异常任务的状态被称之为完成异常(Done-abnormally)。从队列里看这些任务已经运行完，但是从运行记录Log中可以发现没有输出需要的数据，这些任务的运行时间Runtime一般小于20sec。那就会导致相关联的任务会被待命在线上，导致工程师次日没法看到需要的结果。

通过查看异常任务的Log可以推测出问题大概率和LSF有关，需要联系厂商来解决。但是由于公司目前没有继续采购LSF，导致没有厂商提供维护服务。且异常完成的现象会不定期的发生在不同的产品中，只能由工程师手动重新运行。如果是晚上或者Tape out任务重期间频繁发生这种情况，会严重影响产品Tape out周期。本着在不给公司增加额外开支且不增加工程师工作量的情况下，希望可以通过程序化语言来代替工程师及时的发现并解决问题，利用最少的资源将问题造成的影响降到最小。

发明内容

鉴于以上所述现有技术的缺点，本发明的目的在于提供一种在线任务的实时监控和自动处理方法，用于解决现有技术中从队列里看这些任务已经运行完，但是从运行记录Log中发现没有输出需要的数据，导致工程师无法看到需要的结果的问题。

为实现上述目的及其他相关目的，本发明提供一种在线任务的实时监控和自动处理方法，至少包括：

步骤一、搜索过去运行时长在一小时内文件夹下生成的所有Log；

步骤二、将搜索到的所有Log逐个打开并逐行搜索关键词“Successfullycompleted”；

步骤三、将搜索到所述关键词的Log再次打开并逐行扫描读取运行时长Runtime数据；并将运行时长Runtime小于20sec的Log的任务信息抓取出来；

步骤四、处理busb指令中所需要使用到的数值；

步骤五、判断测试程式Recipe的类型；若异常完成的任务的测试程式Recipe的类型是OPC.DRC，则只需要重新提交任务，不需要执行bkill指令；若异常完成的任务的测试程式Recipe的类型是TDOPC.DRC或OPCRP.DRC，需要先清除线上对应的OPC.DRC或OPCV.DRC，再重新提交两支任务；

步骤六、若提交了两支任务，需从队列中抓取两支任务的ID，使用bmod指令建立两支任务的依赖关系，以确定该两支任务的运行顺序。

优选地，步骤四中busb指令中所需要使用到的数值包括：Calibre Version、Turbo、Path。

优选地，步骤四中busb指令中所需要使用到的数值从运行时长Runtime小于20sec的Log中抓取，这些值经过排序处理，被编辑为提交任务所需要用到的busb指令。

优选地，在执行步骤一前，使用Linux的Crontab命令将程序设定为1小时执行一次，程序运行时，执行步骤一。

优选地，步骤三中搜索到所述关键词“Successfully completed”的Log表示对应的任务已在线上完成。

优选地，步骤三中运行时长Runtime小于20sec的Log为异常完成。

如上所述，本发明的在线任务的实时监控和自动处理方法，具有以下有益效果：本发明代替工程师实时监控处理任务运行情况，避免任务异常完成后得不到及时处理和长时间待命。提高流片效率，确保在预估时间内有效运行完任务。在此程序试用期间，异常完成的任务已经可以被重新提交至线上并顺利完成，避免了需要通过采购额外服务来解决根本问题从而造成的资源浪费。可以通过增加测试程式类型来适配更多任务。

附图说明

图1显示为本发明的在线任务的实时监控和自动处理方法流程图。

具体实施方式

以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。

请参阅图1。需要说明的是，本实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

本发明提供一种在线任务的实时监控和自动处理方法，至少包括：

在线Job实时监控和自动处理技术主要原理是定时监控Job的完成情况，当发现有异常完成的Job，系统会自动将线上已经Pend的相关联Job杀掉，并将Job重新丢到线上。本发明进一步地，本实施例在执行步骤一前，使用Linux的Crontab命令将程序设定为1小时执行一次，程序运行时，执行步骤一。

步骤一、搜索过去运行时长在一小时内文件夹下生成的所有Log(每条任务的运行记录)；

步骤二、将搜索到的所有Log逐个打开并逐行搜索关键词“Successfullycompleted”；

使用Linux的Crontab命令将程序设定为1小时执行一次。当程序运行时，首先会搜索过去一小时内在文件夹下生成的所有Log。将这些Log逐个打开并逐行搜索关键词“Successfully completed”，搜索到关键词表明此Log对应的任务(Job)已在线上完成。将符合条件的Log检索出来并提取文件名便是在过去一小时内完成的所有Job。

步骤三、将搜索到所述关键词的Log再次打开并逐行扫描读取运行时长Runtime数据；并将运行时长Runtime小于20sec的Log的任务信息抓取出来；

本发明进一步地，本实施例的步骤三中搜索到所述关键词“Successfullycompleted”的Log表示对应的任务已在线上完成。本发明进一步地，本实施例的步骤三中运行时长Runtime小于20sec的Log为异常完成。

需要判断这些Job中是否有异常完成的。通过查看以往异常完成的Job的Log内容可以发现，通常这些Job的Runtime＜20sec。所以程序执行时会再次打开Log逐行扫描读取Runtime数据，并将小于20sec的Job信息抓取出来进行下一步处理。

步骤四、处理busb指令中所需要使用到的数值；

本发明进一步地，本实施例的步骤四中busb指令中所需要使用到的数值包括：Calibre Version、Turbo、Path。

本发明进一步地，本实施例的步骤四中busb指令中所需要使用到的数值从运行时长Runtime小于20sec的Log中抓取，这些值经过排序处理，被编辑为提交任务所需要用到的busb指令。

处理busb指令中所需要使用到的数值，包括Calibre Version、Turbo、Path、CpuNumber、Recipe Step等。这些值都可以从Log中抓取到。这些值经过排序和处理，就可以被编辑为最后提交Job所需要用到的busb指令。

步骤五、判断测试程式Recipe的类型；若异常完成的任务的测试程式Recipe的类型是OPC.DRC，则只需要重新提交任务，不需要执行bkill指令；若异常完成的任务的测试程式Recipe的类型是TDOPC.DRC或OPCRP.DRC，需要先清除线上对应的OPC.DRC或OPCV.DRC，再重新提交两支任务；

步骤六、若提交了两支任务，需从队列中抓取两支任务的ID，使用bmod指令建立两支任务的依赖关系，以确定该两支任务的运行顺序。

若提交了两支Job，需要从队列中抓取两支Job的ID，使用bmod指令建立两支Job的Dependence关系，确保Job运行的先后顺序。

综上所述，本发明代替工程师实时监控处理任务运行情况，避免任务异常完成后得不到及时处理和长时间待命。提高流片效率，确保在预估时间内有效运行完任务。在此程序试用期间，异常完成的任务已经可以被重新提交至线上并顺利完成，避免了需要通过采购额外服务来解决根本问题从而造成的资源浪费。可以通过增加测试程式类型来适配更多任务。所以，本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。

上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。