CN112306781B - 一种线程故障处理方法、装置、介质及设备 - Google Patents

一种线程故障处理方法、装置、介质及设备 Download PDF

Info

Publication number
CN112306781B
CN112306781B CN202011314998.4A CN202011314998A CN112306781B CN 112306781 B CN112306781 B CN 112306781B CN 202011314998 A CN202011314998 A CN 202011314998A CN 112306781 B CN112306781 B CN 112306781B
Authority
CN
China
Prior art keywords
thread
osd
state
fault
overtime
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202011314998.4A
Other languages
English (en)
Other versions
CN112306781A (zh
Inventor
杨文文
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
New H3C Big Data Technologies Co Ltd
Original Assignee
New H3C Big Data Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by New H3C Big Data Technologies Co Ltd filed Critical New H3C Big Data Technologies Co Ltd
Priority to CN202011314998.4A priority Critical patent/CN112306781B/zh
Publication of CN112306781A publication Critical patent/CN112306781A/zh
Application granted granted Critical
Publication of CN112306781B publication Critical patent/CN112306781B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2205Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested
    • G06F11/221Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested to test buses, lines or interfaces, e.g. stuck-at or open line faults
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2273Test methods
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems

Abstract

本公开涉及计算机存储技术领域,本公开提供了一种线程故障处理方法、装置、介质及设备,应用于对象存储设备OSD进程,所述OSD进程包括第一OSD线程、第二OSD线程以及监控线程,所述方法包括:在第一OSD线程运行过程中执行打点操作并设置超时时间,其中,所述打点为获取并记录当前的时间点;由所述监控线程对所述第一OSD线程进行超时判断,若所述第一OSD线程存在线程超时,则确定所述第一OSD线程存在线程超时故障,并标记所述第一OSD线程的状态为线程故障状态;停止向所述第二OSD线程回复心跳信息。本公开解决现有线程超时报down机制中,CPU持续飙高导致的线程超时故障长时间未消除情况下OSD反复震荡的问题,使得存储集群osd状态更加稳定。

Description

一种线程故障处理方法、装置、介质及设备
技术领域
本公开涉及计算机存储技术领域,更为具体来说,本公开涉及一种线程故障处理方法、装置、介质及设备。
背景技术
分布式存储集群是由多台廉价服务器组成的存储集群,它将集群中每台服务器直连的存储设备通过网络连接在一起以标准协议(例如iSCSI、CIFS协议)的方式对外提供存储资源。用户数据都是通过储存到存储集群的OSD当中,所以,一旦存储集群中的OSD出现异常,那么存储集群就有可能出现数据丢失等异常。因此,保障存储集群各个主机的OSD处于稳定、正常的状态显得尤为重要。
当CPU繁忙导致集群OSD进程内部线程超时,现有技术手段是在30s超时之后,OSD不再回复peers心跳,后续OSD会被peers报down;之后被报down的OSD会向MON申诉,请求重新up,MON便会将OSD标记为up。此种场景下,假如CPU飙高的故障尚未解除,那么OSD就会再次线程超时,会再次被报down,这样一来,OSD便会不断震荡。
当前,现有代码会在OSD再次恢复至up之前进行一次线程超时的判断,但是判断时刻,OSD仍然处于down的状态,此时的OSD上没有IO下发,所以即使此刻的线程超时检测通过之后,后续拉起该OSD后,待OSD上重新有IO时,仍旧会因为线程超时被再次报down。所以此时的检测依然不能避免后续的OSD震荡。
发明内容
为解决现有技术线程超时报down机制中,CPU持续飙高导致的线程超时故障长时间未消除情况下OSD反复震荡的技术问题。
为实现上述技术目的,本公开提供了一种线程故障处理方法,应用于对象存储设备OSD进程,所述OSD进程包括第一OSD线程、第二OSD线程以及监控线程,所述方法包括:
在第一OSD线程运行过程中执行打点操作并设置超时时间,其中,所述打点为获取并记录当前的时间点;
由所述监控线程对所述第一OSD线程进行超时判断,若所述第一OSD线程存在线程超时,则确定所述第一OSD线程存在线程超时故障,并标记所述第一OSD线程的状态为线程故障状态;
停止向所述第二OSD线程回复心跳信息。
进一步,还包括:
所述第二OSD线程确认所述第一OSD线程是否存在心跳超时故障;
若存在,则向监控器MON发送用于表征所述第一OSD线程存在心跳超时故障的故障消息,以使所述MON接收到所述故障消息后,若确认接收到的故障消息的次数超过预设的第一阈值,则将所述第一OSD线程的状态标记为down状态。
进一步,若确认所述第一OSD线程的状态被标记为down状态,获取第一OSD线程的属性信息,判断所述属性信息是否满足状态切换条件;
若满足则向监控器MON发起状态切换请求,以使所述MON将所述第一OSD线程的状态标记为up状态。
进一步,所述属性信息包括IO平均时延和IO返回数;
所述状态切换条件为:
所述IO平均时延不超过第二阈值;
所述IO返回数超过不第三阈值;
所述第一OSD线程不存在线程超时。
进一步,所述IO平均时延的确定方法具体包括:
计算每个时间间隔内的IO时延大小,其中每个时间间隔为相邻两个打点时间点的时间差;
基于计算出的各个IO时延确定超过预设时间阈值的IO时延的数量
将所述数量与所述时间间隔的总数量之间的比值确定为所述IO平均时延。
进一步,所述IO返回数的确定方法具体包括:
若确定本次IO下发和IO返回之间的时间间隔超过预先设定的超时时间阈值,则将计数结果加1,将加1后的计数结果确定为所述IO返回数。
进一步,所述第一OSD线程不存在线程超时的确定方法为:
若确定所述第一OSD线程停止向第二OSD线程回复心跳消息的持续时间超过第四阈值,则确认所述第一OSD线程超时。
为实现上述技术目的,本公开还能够提供一种线程超时故障检测装置,包括:
处理模块,用于在第一OSD线程运行过程中执行打点操作并设置超时时间,其中,所述打点为获取并记录当前的时间点;
第一判断模块,用于由所述监控线程对所述第一OSD线程进行超时判断,若所述第一OSD线程存在线程超时,则确定所述第一OSD线程存在线程超时故障,并标记所述第一OSD线程的状态为线程故障状态;
停止模块,用于停止向所述第二OSD线程回复心跳信息。
为实现上述技术目的,本公开还能够提供一种计算机存储介质,其上存储有计算机程序,计算机程序被处理器执行时用于实现上述的线程故障处理方法的步骤。
为实现上述技术目的,本公开还提供了一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,处理器执行计算机程序时实现上述的线程故障处理方法的步骤。
本公开的有益效果为:
跟原有机制相比,本公开通过在OSD进程中新增监控线程,由监控线程监控第一OSD线程是否故障,当监控到第一OSD线程存在超时故障时,停止向第二OSD线程回复心跳信息,从而在一定程度上能够有效检测出因线程超时故障的OSD线程,一定程度上避免了OSD的震荡。
本公开解决现有线程超时报down机制中,CPU持续飙高导致的线程超时故障长时间未消除情况下OSD反复震荡的问题,使得存储集群osd状态更加稳定。
此外,正常的OSD线程超时报down机制不会对故障OSD向MON申诉时进行有效检测,无法知晓申诉的OSD是否仍然存在线程超时故障。本公开提出一种线程超时故障检测机制,并将该检测机制用于OSD向MON申诉up之时。即在OSD再次up之前增加了有效的线程超时检测机制,在OSD层增加压力测试,统计OSD层检测下发IO的平均时延以及IO返回数,将IO平均时延和IO返回数跟设定阈值进行比较,满足阈值要求,且该OSD没有其他线程超时故障,则允许OSD接入集群,否则,则OSD继续在故障隔离态等待,直到满足接入条件。
附图说明
图1示出了本公开的实施例1的流程示意图;
图2示出了本公开的实施例1的改进方案的流程示意图;
图3示出了本公开的实施例1的改进方案的流程示意图;
图4示出了本公开的实施例3的结构示意图;
图5示出了本公开的实施例4的结构示意图。
具体实施方式
以下,将参照附图来描述本公开的实施例。但是应该理解,这些描述只是示例性的,而并非要限制本公开的范围。此外,在以下说明中,省略了对公知结构和技术的描述,以避免不必要地混淆本公开的概念。
在附图中示出了根据本公开实施例的各种结构示意图。这些图并非是按比例绘制的,其中为了清楚表达的目的,放大了某些细节,并且可能省略了某些细节。图中所示出的各种区域、层的形状以及它们之间的相对大小、位置关系仅是示例性的,实际中可能由于制造公差或技术限制而有所偏差,并且本领域技术人员根据实际所需可以另外设计具有不同形状、大小、相对位置的区域/层。
本公开涉及的术语解释:
OSD:Object Storage Device,主要功能包括存储数据,处理数据的复制、恢复、回补、平衡数据分布,并将一些相关数据提供给Ceph Monitor。
Ceph Monitor:Ceph的监控器,主要功能是维护整个集群的健康状态,提供一致性的决策,包含了Monitor map、OSD map、PG(Placement Group)map和crush map。
Ceph Monitor下文中简称为MON。
Ceph:分布式文件系统。
Ceph是一个统一的分布式存储系统,设计初衷是提供较好的性能、可靠性和可扩展性。
Ceph项目最早起源于Sage就读博士期间的工作(最早的成果于2004年发表),并随后贡献给开源社区。在经过了数年的发展之后,目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。
Ceph特点
高性能
a.摒弃了传统的集中式存储元数据寻址的方案,采用CRUSH算法,数据分布均衡,并行度高。
b.考虑了容灾域的隔离,能够实现各类负载的副本放置规则,例如跨机房、机架感知等。
c.能够支持上千个存储节点的规模,支持TB到PB级的数据。
高可用性
a.副本数可以灵活控制。
b.支持故障域分隔,数据强一致性。
c.多种故障场景自动进行修复自愈。
d.没有单点故障,自动管理。
高可扩展性
a.去中心化。
b.扩展灵活。
c.随着节点增加而线性增长。
特性丰富
a.支持三种存储接口:块存储、文件存储、对象存储。
b.支持自定义接口,支持多种语言驱动。
Up/down:OSD的一种运行状态,有up状态和down状态两种,当OSD运行状态正常时标记为up,异常时标记为down。
报down:也称为标记OSD状态为down,时集群Monitor对集群OSD运行状态的一种标记。
实施例一:
如图1所示:
本公开提供了一种线程故障处理方法,应用于对象存储设备OSD进程,所述OSD进程包括第一OSD线程、第二OSD线程以及监控线程,所述方法包括:
S1:在第一OSD线程运行过程中执行打点操作并设置超时时间,其中,所述打点为获取并记录当前的时间点;
S2:由所述监控线程对所述第一OSD线程进行超时判断,若所述第一OSD线程存在线程超时,则确定所述第一OSD线程存在线程超时故障,并标记所述第一OSD线程的状态为线程故障状态;
S3:停止向所述第二OSD线程回复心跳信息。
需要说明的是:
第一OSD线程是进程中的任一个线程,第二OSD线程是泛指概念,第二OSD线程为除第一OSD线程之外的至少一个OSD线程,如第二OSD线程可以为除第一OSD线程之外的一个线程、多个线程或所有线程等等。
进一步地,如图2所示:
本公开的实施例1的技术方案还可以做如下改进:
所述的线程故障处理方法还包括:
S4:所述第二OSD线程确认所述第一OSD线程是否存在心跳超时故障;
S5:若存在,则向监控器MON发送用于表征所述第一OSD线程存在心跳超时故障的故障消息,以使所述MON接收到所述故障消息后,若确认接收到的故障消息的次数超过预设的第一阈值,则将所述第一OSD线程的状态标记为down状态。
进一步地,如图3所示:
本公开的实施例1的技术方案还可以做如下改进:
所述方法还包括:
S6:若确认所述第一OSD线程的状态被标记为down状态,获取第一OSD线程的属性信息,判断所述属性信息是否满足状态切换条件;
S7:若满足则向监控器MON发起状态切换请求,以使所述MON将所述第一OSD线程的状态标记为up状态。
具体地,所述S5中的所述属性信息包括IO平均时延和IO返回数;
所述状态切换条件为:
所述IO平均时延不超过第二阈值;
具体地,所述IO平均时延的确定方法具体包括:
计算每个时间间隔内的IO时延大小,其中每个时间间隔为相邻两个打点时间点的时间差;
基于计算出的各个IO时延确定超过预设时间阈值的IO时延的数量
将所述数量与所述时间间隔的总数量之间的比值确定为所述IO平均时延。
所述IO返回数不超过第三阈值;
具体地,所述IO返回数的确定方法具体包括:
若确定本次IO下发和IO返回之间的时间间隔超过预先设定的超时时间阈值,则将计数结果加1,将加1后的计数结果确定为所述IO返回数。
所述第一OSD线程不存在线程超时。
具体地,所述第一OSD线程不存在线程超时的确定方法为:
若确定所述第一OSD线程停止向第二OSD线程回复心跳消息的持续时间超过第四阈值,则确认所述第一OSD线程超时。
下面结合一个具体的实例,详解本公开的线程故障处理方法:
线程故障处理机制流程如下,需要说明的是,以第一OSD线程为OSD.A、第二OSD线程为OSD.B为例进行说明:
在OSD.A运行过程中进行打点,设置超时时间T(用来限制线程在接下来一个阶段的执行时间,阶段末尾就是下一次打点);
监控线程周期性对所监控的线程OSD.A进行超时判断,如果线程OSD.A存在线程超时,即线程运行时间t>T,则标记线程OSD.A(即第一OSD线程,下同)处于线程不健康,即线程OSD.A存在线程超时故障;
线程OSD.A检测到自身线程存在处理超时,将会停止回复OSD.B(即第二OSD线程,下同)心跳消息;
线程OSD.B未及时接收到线程OSD.A的心跳响应,则会向监控器MON报告线程OSD.A存在心跳超时故障;
当MON收到足够多的线程OSD.A心跳超时故障消息后,会将线程OSD.A标记为down状态。
当线程OSD.A发现自己被MON标down状态之后,在线程OSD.A有三个状态切换条件,当线程OSD.A同时满足三个状态切换条件,会再次向MON发起状态切换请求;若不满足上述状态切换条件,则会继续执行判断条件,直至满足状态切换条件为止。
监控器MON接收到状态切换请求后,才会再次将线程OSD.A标记为UP状态。
三个状态切换条件具体为:
状态切换条件1:
判断第一OSD线程上IO平均时延是否超阈值
1)在线程运行过程中进行打点,并设置打点时间t1、t2,、t3…tn,其中每一个打点间隔设定为一个时间间隔Ti,其中:
Ti=ti+1-ti,i=1,2,……n,其中,n为正整数;
2)分别记录时间间隔Ti的IO时延大小delay1、delay2、delay3、……delayn,同时设定超时时间阈值为d,假如一个时间间隔内,有:
delayi>d
则判定这个IO为延时IO。
3)当时间间隔内延时IO比例超过设定比例阈值K时,即:
(延时IO数/IO总数)>K
则认为该第一OSD线程IO时延较高,不执行状态切换。
状态切换条件2:
预先设定超时时间阈值Time,若确定本次IO下发和IO返回之间的时间间隔超过预先设定的超时时间阈值Time,则将计数结果加1,将加1后的计数结果确定为所述IO返回数;
判断所述IO返回数的数值是否超过第三阈值,若超过则认为该第一OSD线程存在IO返回慢,不执行状态切换。
状态切换条件3:
判断第一OSD线程不存在线程超时:
所述第一OSD线程不存在线程超时的确定方法为:
若确定所述第一OSD线程停止向第二OSD线程回复心跳消息的持续时间超过第四阈值,则确认所述第一OSD线程超时,不执行状态切换。
正常的OSD线程超时报down机制不会对故障OSD向MON申诉时进行有效检测,无法知晓申诉的OSD是否仍然存在线程超时故障。本公开提出一种线程超时故障检测机制,并将该检测机制用于OSD向MON申诉up之时。即在OSD再次up之前增加了有效的线程超时检测机制,在OSD层增加压力测试,统计OSD层检测下发IO的平均时延以及IO返回数,将IO平均时延和IO返回数跟设定阈值进行比较,满足阈值要求,且该OSD没有其他线程超时故障,则允许OSD接入集群,否则,则OSD继续在故障隔离态等待,直到满足接入条件。
跟原有机制相比,本公开在一定程度上能够有效检测出因线程超时故障的OSD,一定程度上避免了OSD的震荡。
本公开优化了原有线程超时OSD报down机制,增加OSD向mon申诉UP时的检测机制。增加了三种有效的线程超时检测机制,避免故障尚未解除的OSD再次加入集群,从而大大降低了OSD震荡的频率。
本公开创新性地提出了三种检测判断条件,三种检测条件分别包含:1.给申诉up的OSD下发检测IO时,IO平均时延小于设定阈值;2.周期内IO返回数大于设定阈值;3.该OSD上没有线程超时故障。
实施例二:
如图4所示:
本公开还提供了一种线程超时故障检测装置,应用于对象存储设备OSD进程,所述OSD进程包括第一OSD线程、第二OSD线程以及监控线程,所述装置包括:
处理模块401,用于在第一OSD线程运行过程中执行打点操作并设置超时时间,其中,所述打点为获取并记录当前的时间点;
第一判断模块402,用于由所述监控线程对所述第一OSD线程进行超时判断,若所述第一OSD线程存在线程超时,则确定所述第一OSD线程存在线程超时故障,并标记所述第一OSD线程的状态为线程故障状态;
停止模块403,用于停止向所述第二OSD线程回复心跳信息。
其中,所述处理模块401、所述判断模块402和所述停止模块403依次连接。
可选地,本实施例提供的线程超时故障检测装置,还包括:
第二判断模块(图中未示出),用于确认所述第一OSD线程是否存在心跳超时故障;
第一发送模块(图中未示出),用于若所述第二判断模块确认所述第一OSD线程存在心跳超时故障,则向监控器MON发送用于表征所述第一OSD线程存在心跳超时故障的故障消息,以使所述MON接收到所述故障消息后,若确认接收到的故障消息的次数超过预设的第一阈值,则将所述第一OSD线程的状态标记为down状态。
可选地,本实施例提供的线程超时故障检测装置,还包括:
获取模块(图中未示出),用于若确认所述第一OSD线程的状态被标记为down状态,获取第一OSD线程的属性信息;
第三判断模块(图中未示出),用于判断所述属性信息是否满足状态切换条件;
第二发送模块(图中未示出),用于若所述第三判断模块的判断结果为满足,则向监控器MON发起状态切换请求,以使所述MON将所述第一OSD线程的状态标记为up状态。
可选地,本实施例中的属性信息包括IO平均时延和IO返回数;
所述状态切换条件为:
所述IO平均时延不超过第二阈值;
所述IO返回数不超过第三阈值;
所述第一OSD线程不存在线程超时。
可选地,本实施例提供的线程超时故障检测装置,还包括:
第一确定模块(图中未示出),用于计算每个时间间隔内的IO时延大小,其中每个时间间隔为相邻两个打点时间点的时间差;基于计算出的各个IO时延确定超过预设时间阈值的IO时延的数量将所述数量与所述时间间隔的总数量之间的比值确定为所述IO平均时延。
可选地,本实施例提供的线程超时故障检测装置,还包括:
第二确定模块(图中未示出),用于若确定本次IO下发和IO返回之间的时间间隔超过预先设定的超时时间阈值,则将计数结果加1,将加1后的计数结果确定为所述IO返回数。
可选地,本实施例提供的线程超时故障检测装置,还包括:
第三确定模块(图中未示出),若确定所述第一OSD线程停止向第二OSD线程回复心跳消息的持续时间超过第四阈值,则确认所述第一OSD线程超时。
实施例三:
本公开还能够提供一种计算机存储介质,其上存储有计算机程序,计算机程序被处理器执行时用于实现上述的线程故障处理方法的步骤。
本公开的计算机存储介质可以采用半导体存储器、磁芯存储器、磁鼓存储器或磁盘存储器实现。
半导体存储器,主要用于计算机的半导体存储元件主要有Mos和双极型两种。Mos元件集成度高、工艺简单但速度较慢。双极型元件工艺复杂、功耗大、集成度低但速度快。NMos和CMos问世后,使Mos存储器在半导体存储器中开始占主要地位。NMos速度快,如英特尔公司的1K位静态随机存储器的存取时间为45ns。而CMos耗电省,4K位的CMos静态存储器存取时间为300ns。上述半导体存储器都是随机存取存储器(RAM),即在工作过程中可随机进行读出和写入新内容。而半导体只读存储器(ROM)在工作过程中可随机读出但不能写入,它用来存放已固化好的程序和数据。ROM又分为不可改写的熔断丝式只读存储器──PROM和可改写的只读存储器EPROM两种。
磁芯存储器,具有成本低,可靠性高的特点,且有20多年的实际使用经验。70年代中期以前广泛使用磁芯存储器作为主存储器。其存储容量可达10位以上,存取时间最快为300ns。国际上典型的磁芯存储器容量为4MS~8MB,存取周期为1.0~1.5μs。在半导体存储快速发展取代磁芯存储器作为主存储器的位置之后,磁芯存储器仍然可以作为大容量扩充存储器而得到应用。
磁鼓存储器,一种磁记录的外存储器。由于其信息存取速度快,工作稳定可靠,虽然其容量较小,正逐渐被磁盘存储器所取代,但仍被用作实时过程控制计算机和中、大型计算机的外存储器。为了适应小型和微型计算机的需要,出现了超小型磁鼓,其体积小、重量轻、可靠性高、使用方便。
磁盘存储器,一种磁记录的外存储器。它兼有磁鼓和磁带存储器的优点,即其存储容量较磁鼓容量大,而存取速度则较磁带存储器快,又可脱机贮存,因此在各种计算机系统中磁盘被广泛用作大容量的外存储器。磁盘一般分为硬磁盘和软磁盘存储器两大类。
硬磁盘存储器的品种很多。从结构上,分可换式和固定式两种。可换式磁盘盘片可调换,固定式磁盘盘片是固定的。可换式和固定式磁盘都有多片组合和单片结构两种,又都可分为固定磁头型和活动磁头型。固定磁头型磁盘的容量较小,记录密度低存取速度高,但造价高。活动磁头型磁盘记录密度高(可达1000~6250位/英寸),因而容量大,但存取速度相对固定磁头磁盘低。磁盘产品的存储容量可达几百兆字节,位密度为每英寸6 250位,道密度为每英寸475道。其中多片可换磁盘存储器由于盘组可以更换,具有很大的脱体容量,而且容量大,速度高,可存储大容量情报资料,在联机情报检索系统、数据库管理系统中得到广泛应用。
实施例四:
本公开还提供了一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,处理器执行计算机程序时实现上述的线程故障处理方法的步骤。
图5为一个实施例中电子设备的内部结构示意图。如图4所示,该电子设备包括通过系统总线连接的处理器、存储介质、存储器和网络接口。其中,该计算机设备的存储介质存储有操作系统、数据库和计算机可读指令,数据库中可存储有控件信息序列,该计算机可读指令被处理器执行时,可使得处理器实现一种线程故障处理方法。该电设备的处理器用于提供计算和控制能力,支撑整个计算机设备的运行。该计算机设备的存储器中可存储有计算机可读指令,该计算机可读指令被处理器执行时,可使得处理器执行一种线程超时故障检测方法。该计算机设备的网络接口用于与终端连接通信。本领域技术人员可以理解,图4中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的计算机设备的限定,具体的计算机设备可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。
该电子设备包括但不限于智能电话、计算机、平板电脑、可穿戴智能设备、人工智能设备、移动电源等。
所述处理器在一些实施例中可以由集成电路组成,例如可以由单个封装的集成电路所组成,也可以是由多个相同功能或不同功能封装的集成电路所组成,包括一个或者多个中央处理器(Central Processing unit,CPU)、微处理器、数字处理芯片、图形处理器及各种控制芯片的组合等。所述处理器是所述电子设备的控制核心(Control Unit),利用各种接口和线路连接整个电子设备的各个部件,通过运行或执行存储在所述存储器内的程序或者模块(例如执行远端数据读写程序等),以及调用存储在所述存储器内的数据,以执行电子设备的各种功能和处理数据。
所述总线可以是外设部件互连标准(peripheral component interconnect,简称PCI)总线或扩展工业标准结构(extended industry standard architecture,简称EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。所述总线被设置为实现所述存储器以及至少一个处理器等之间的连接通信。
图5仅示出了具有部件的电子设备,本领域技术人员可以理解的是,图5示出的结构并不构成对所述电子设备的限定,可以包括比图示更少或者更多的部件,或者组合某些部件,或者不同的部件布置。
例如,尽管未示出,所述电子设备还可以包括给各个部件供电的电源(比如电池),优选地,电源可以通过电源管理装置与所述至少一个处理器逻辑相连,从而通过电源管理装置实现充电管理、放电管理、以及功耗管理等功能。电源还可以包括一个或一个以上的直流或交流电源、再充电装置、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。所述电子设备还可以包括多种传感器、蓝牙模块、Wi-Fi模块等,在此不再赘述。
进一步地,所述电子设备还可以包括网络接口,可选地,所述网络接口可以包括有线接口和/或无线接口(如WI-FI接口、蓝牙接口等),通常用于在该电子设备与其他电子设备之间建立通信连接。
可选地,该电子设备还可以包括用户接口,用户接口可以是显示器(Display)、输入单元(比如键盘(Keyboard)),可选地,用户接口还可以是标准的有线接口、无线接口。可选地,在一些实施例中,显示器可以是LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode,有机发光二极管)触摸器等。其中,显示器也可以适当的称为显示屏或显示单元,用于显示在电子设备中处理的信息以及用于显示可视化的用户界面。
进一步地,所述计算机可用存储介质可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序等;存储数据区可存储根据区块链节点的使用所创建的数据等。
在本发明所提供的几个实施例中,应该理解到,所揭露的设备,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述模块的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能模块可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能模块的形式实现。
以上对本公开的实施例进行了描述。但是,这些实施例仅仅是为了说明的目的,而并非为了限制本公开的范围。本公开的范围由所附权利要求及其等价物限定。不脱离本公开的范围,本领域技术人员可以做出多种替代和修改,这些替代和修改都应落在本公开的范围之内。

Claims (7)

1.一种线程故障处理方法,其特征在于,应用于对象存储设备OSD进程,所述OSD进程包括第一OSD线程、第二OSD线程以及监控线程,所述方法包括:
在第一OSD线程运行过程中执行打点操作并设置超时时间,其中,所述打点为获取并记录当前的时间点;
由所述监控线程对所述第一OSD线程进行超时判断,若所述第一OSD线程存在线程超时,则确定所述第一OSD线程存在线程超时故障,并标记所述第一OSD线程的状态为线程故障状态;
停止向所述第二OSD线程回复心跳信息;
所述第二OSD线程确认所述第一OSD线程是否存在心跳超时故障;
若存在,则向监控器MON发送用于表征所述第一OSD线程存在心跳超时故障的故障消息,以使所述MON接收到所述故障消息后,若确认接收到的故障消息的次数超过预设的第一阈值,则将所述第一OSD线程的状态标记为down状态;
若确认所述第一OSD线程的状态被标记为down状态,获取第一OSD线程的属性信息,判断所述属性信息是否满足状态切换条件,所述属性信息包括IO平均时延和IO返回数;所述状态切换条件为:所述IO平均时延不超过第二阈值;所述IO返回数不超过第三阈值;所述第一OSD线程不存在线程超时;
若满足则向监控器MON发起状态切换请求,以使所述MON将所述第一OSD线程的状态标记为up状态。
2.根据权利要求1所述的方法,其特征在于,所述IO平均时延的确定方法具体包括:
计算每个时间间隔内的IO时延大小,其中每个时间间隔为相邻两个打点时间点的时间差;
基于计算出的各个IO时延确定超过预设时间阈值的IO时延的数量
将所述数量与所述时间间隔的总数量之间的比值确定为所述IO平均时延。
3.根据权利要求1所述的方法,其特征在于,所述IO返回数的确定方法具体包括:
若确定本次IO下发和IO返回之间的时间间隔超过预先设定的超时时间阈值,则将计数结果加1,将加1后的计数结果确定为所述IO返回数。
4.根据权利要求1所述的方法,其特征在于,所述第一OSD线程不存在线程超时的确定方法为:
若确定所述第一OSD线程停止向第二OSD线程回复心跳消息的持续时间超过第四阈值,则确认所述第一OSD线程超时。
5.一种线程故障处理装置,其特征在于,应用于对象存储设备OSD进程,所述OSD进程包括第一OSD线程、第二OSD线程以及监控线程,所述装置包括:
处理模块,用于在第一OSD线程运行过程中执行打点操作并设置超时时间,其中,所述打点为获取并记录当前的时间点;
第一判断模块,用于由所述监控线程对所述第一OSD线程进行超时判断,若所述第一OSD线程存在线程超时,则确定所述第一OSD线程存在线程超时故障,并标记所述第一OSD线程的状态为线程故障状态;
停止模块,用于停止向所述第二OSD线程回复心跳信息;
所述装置,还包括:
第二判断模块,用于确认所述第一OSD线程是否存在心跳超时故障;
第一发送模块,用于若所述第二判断模块确认所述第一OSD线程存在心跳超时故障,则向监控器MON发送用于表征所述第一OSD线程存在心跳超时故障的故障消息,以使所述MON接收到所述故障消息后,若确认接收到的故障消息的次数超过预设的第一阈值,则将所述第一OSD线程的状态标记为down状态;
获取模块,用于若确认所述第一OSD线程的状态被标记为down状态,获取第一OSD线程的属性信息;
第三判断模块,用于判断所述属性信息是否满足状态切换条件,所述属性信息包括IO平均时延和IO返回数;所述状态切换条件为:所述IO平均时延不超过第二阈值;所述IO返回数不超过第三阈值;所述第一OSD线程不存在线程超时;
第二发送模块,用于若所述第三判断模块的判断结果为满足,则向监控器MON发起状态切换请求,以使所述MON将所述第一OSD线程的状态标记为up状态。
6.一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述计算机程序时实现权利要求1~4任一项中所述的线程故障处理方法的步骤。
7.一种计算机存储介质,其上存储有计算机程序指令,其特征在于,所述程序指令被处理器执行时用于实现权利要求1~4任一项中所述的线程故障处理方法对应的步骤。
CN202011314998.4A 2020-11-20 2020-11-20 一种线程故障处理方法、装置、介质及设备 Active CN112306781B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011314998.4A CN112306781B (zh) 2020-11-20 2020-11-20 一种线程故障处理方法、装置、介质及设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011314998.4A CN112306781B (zh) 2020-11-20 2020-11-20 一种线程故障处理方法、装置、介质及设备

Publications (2)

Publication Number Publication Date
CN112306781A CN112306781A (zh) 2021-02-02
CN112306781B true CN112306781B (zh) 2022-08-19

Family

ID=74334365

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011314998.4A Active CN112306781B (zh) 2020-11-20 2020-11-20 一种线程故障处理方法、装置、介质及设备

Country Status (1)

Country Link
CN (1) CN112306781B (zh)

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6032271A (en) * 1996-06-05 2000-02-29 Compaq Computer Corporation Method and apparatus for identifying faulty devices in a computer system
CN108255429A (zh) * 2018-01-10 2018-07-06 郑州云海信息技术有限公司 一种写操作控制方法、系统、装置及计算机可读存储介质
CN109144789A (zh) * 2018-09-10 2019-01-04 网宿科技股份有限公司 一种重启osd的方法、装置及系统
CN109213617A (zh) * 2018-09-25 2019-01-15 郑州云海信息技术有限公司 一种osd故障原因的确定方法、系统及相关组件
CN109274544A (zh) * 2018-12-11 2019-01-25 浪潮(北京)电子信息产业有限公司 一种分布式存储系统的故障检测方法及装置
CN109656895A (zh) * 2018-11-28 2019-04-19 平安科技(深圳)有限公司 分布式存储系统、数据写入方法、装置和存储介质
WO2019148841A1 (zh) * 2018-01-31 2019-08-08 华为技术有限公司 一种分布式存储系统、数据处理方法和存储节点
CN110727556A (zh) * 2019-09-21 2020-01-24 苏州浪潮智能科技有限公司 一种bmc健康状态监控方法、系统、终端及存储介质
CN111628893A (zh) * 2020-05-27 2020-09-04 星辰天合(北京)数据科技有限公司 分布式存储系统的故障处理方法及装置、电子设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108235751B (zh) * 2017-12-18 2020-04-14 华为技术有限公司 识别对象存储设备亚健康的方法、装置和数据存储系统

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6032271A (en) * 1996-06-05 2000-02-29 Compaq Computer Corporation Method and apparatus for identifying faulty devices in a computer system
CN108255429A (zh) * 2018-01-10 2018-07-06 郑州云海信息技术有限公司 一种写操作控制方法、系统、装置及计算机可读存储介质
WO2019148841A1 (zh) * 2018-01-31 2019-08-08 华为技术有限公司 一种分布式存储系统、数据处理方法和存储节点
CN109144789A (zh) * 2018-09-10 2019-01-04 网宿科技股份有限公司 一种重启osd的方法、装置及系统
CN109213617A (zh) * 2018-09-25 2019-01-15 郑州云海信息技术有限公司 一种osd故障原因的确定方法、系统及相关组件
CN109656895A (zh) * 2018-11-28 2019-04-19 平安科技(深圳)有限公司 分布式存储系统、数据写入方法、装置和存储介质
CN109274544A (zh) * 2018-12-11 2019-01-25 浪潮(北京)电子信息产业有限公司 一种分布式存储系统的故障检测方法及装置
CN110727556A (zh) * 2019-09-21 2020-01-24 苏州浪潮智能科技有限公司 一种bmc健康状态监控方法、系统、终端及存储介质
CN111628893A (zh) * 2020-05-27 2020-09-04 星辰天合(北京)数据科技有限公司 分布式存储系统的故障处理方法及装置、电子设备

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
《IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries》;IEEE;《https://ieeexplore.ieee.org/servlet/opac?punumber=2267》;19910118;全文 *
支持多线程监控的外置Watchdog监控组件的设计;郑培余等;《计算机工程》;20051205(第24期);全文 *

Also Published As

Publication number Publication date
CN112306781A (zh) 2021-02-02

Similar Documents

Publication Publication Date Title
CN107015872B (zh) 监控数据的处理方法及装置
CN103458036B (zh) 一种集群文件系统的访问装置和方法
CN102402395B (zh) 基于仲裁磁盘的高可用系统不间断运行方法
CN102308559B (zh) 一种用于集群计算机系统的投票仲裁方法及装置
US20080201603A1 (en) Correlating hardware devices between local operating system and global management entity
CN104965850A (zh) 一种基于开源技术的数据库高可用实现方法
CN111858240B (zh) 一种分布式存储系统的监控方法、系统、设备以及介质
CN104298583B (zh) 基于基板管理控制器的主板管理系统及方法
CN108206768A (zh) 集群监测和切换方法及装置
CN107463468A (zh) 缓存管理方法及其设备
CN108255620A (zh) 一种业务逻辑处理方法、装置、业务服务器及系统
CN104298574A (zh) 一种数据高速存储处理系统
WO2023222109A1 (zh) 网络唤醒的管理方法、装置、电子设备及存储介质
CN104573428B (zh) 一种提高服务器集群资源有效性的方法及系统
CN109558299A (zh) 业务监控与预警的方法、装置、设备及存储介质
CN114553747A (zh) redis集群的异常检测方法、装置、终端及存储介质
CN114154035A (zh) 一种动环监控的数据处理系统
US20220247641A1 (en) Unobservable node identification
CN112348213A (zh) 运维故障排查实现方法、装置、介质及设备
CN112306781B (zh) 一种线程故障处理方法、装置、介质及设备
CN104460938A (zh) 利用存储器高速缓存在系统范围内节省电力的方法和系统
CN114675976B (zh) 基于kubernetes的GPU共享方法、装置、设备及介质
CN113407374A (zh) 故障处理方法、装置、故障处理设备及存储介质
CN112306815B (zh) Ceph中OSD侧主从间IO信息监控方法、装置、设备及介质
CN107562580A (zh) 一种计算机集成系统及故障自动切换方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant