CN116991505A - 插件加载方法、装置、电子设备和存储介质 - Google Patents
插件加载方法、装置、电子设备和存储介质 Download PDFInfo
- Publication number
- CN116991505A CN116991505A CN202311255671.8A CN202311255671A CN116991505A CN 116991505 A CN116991505 A CN 116991505A CN 202311255671 A CN202311255671 A CN 202311255671A CN 116991505 A CN116991505 A CN 116991505A
- Authority
- CN
- China
- Prior art keywords
- plug
- ins
- crash
- loading
- load
- 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.)
- Pending
Links
- 238000011068 loading method Methods 0.000 title claims abstract description 95
- 238000000034 method Methods 0.000 claims abstract description 373
- 230000001960 triggered effect Effects 0.000 claims description 3
- 230000002159 abnormal effect Effects 0.000 abstract description 77
- FFBHFFJDDLITSX-UHFFFAOYSA-N benzyl N-[2-hydroxy-4-(3-oxomorpholin-4-yl)phenyl]carbamate Chemical compound OC1=C(NC(=O)OCC2=CC=CC=C2)C=CC(=C1)N1CCOCC1=O FFBHFFJDDLITSX-UHFFFAOYSA-N 0.000 description 14
- 238000010586 diagram Methods 0.000 description 6
- 238000004590 computer program Methods 0.000 description 5
- 230000000694 effects Effects 0.000 description 4
- 230000002411 adverse Effects 0.000 description 3
- 230000015556 catabolic process Effects 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 239000002699 waste material Substances 0.000 description 3
- 230000005856 abnormality Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012804 iterative process Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
- G06F9/44526—Plug-ins; Add-ons
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0715—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a system implementing multitasking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5017—Task decomposition
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Stored Programmes (AREA)
Abstract
本公开关于插件加载方法、装置、电子设备和存储介质，该方法包括：启动单个进程，并在单个进程中加载多个插件；在检测到单个进程崩溃的情况下，执行至少一次分组加载操作直到所有崩溃进程均仅加载单个插件；其中，分组加载操作包括：对当前崩溃进程所包含的插件进行分组，并针对每个组分别启用一个新进程以加载对应组的插件。这样，由于每次均是对当前崩溃进程所包含的插件进行分组，因此，经过有限次分组之后，异常插件就可以被分配至一个单独的进程，使得既能够快速定位异常插件，又可以使异常插件不影响正常插件，保障正常插件的正常运行。
Description
技术领域
本公开涉及计算机技术领域，更具体地说，涉及插件加载方法、装置、电子设备和存储介质。
背景技术
相关技术中，常用的插件加载方式为单进程方式或多进程方式。其中，单进程方式是指将所有的插件在同一个进程空间中进行加载，例如，所有的插件可以共享宿主进程的代码段。但是，一旦部分插件出现异常，会殃及其他插件，即会影响其他插件的正常加载，插件加载的稳定性较差。多进程方式是指每个插件都运行在一个单独的进程中，但是，此种方式启动的进程数量较多，部分进程资源无法共享，会导致系统资源的额外消耗。
发明内容
本公开提供插件加载方法、装置、电子设备和存储介质，以至少解决上述相关技术中，单进程加载插件方式的稳定性较差、多进程加载插件方式会导致系统资源的额外消耗的问题。
根据本公开实施例的第一方面，提供一种插件加载方法，包括：启动单个进程，并在所述单个进程中加载多个插件；在检测到所述单个进程崩溃的情况下，执行至少一次分组加载操作直到所有崩溃进程均仅加载单个插件；其中，所述分组加载操作包括：对当前崩溃进程所包含的插件进行分组，并针对每个组分别启用一个新进程以加载对应组的插件。
可选地，所述执行至少一次分组加载操作直到所有崩溃进程均仅加载单个插件，包括：通过迭代的方式执行所述至少一次分组加载操作直到当前迭代启用的新进程中出现崩溃进程、且所述崩溃进程中仅包含一个插件；其中，针对每一次迭代，对当前崩溃进程所包含的插件进行分组并针对每个组分别启用一个新进程以加载对应组的插件；其中，在本次迭代启用的新进程中再次检测到崩溃进程的情况下，进入下一次迭代。
可选地，所述分组的步骤包括：将插件均匀划分为预设数量个组。
可选地，所述预设数量为2。
可选地，所述插件加载方法还包括：重复启用预设次数的单独的进程加载所述崩溃进程所包含的所述单个插件，其中，所述单独的进程崩溃的情况下触发下一次启用。
可选地，所述对当前崩溃进程所包含的插件进行分组的步骤包括：基于所述当前崩溃进程所包含的各个插件所需耗费的资源，对当前崩溃进程所包含的插件进行分组，使得每个组中的插件所需耗费的资源总和均衡。
可选地，所述对当前崩溃进程所包含的插件进行分组的步骤还包括：基于所述当前崩溃进程所包含的各个插件所需耗费的资源，确定分组数量，使得每个组中的插件所需耗费的资源总和不超过预定资源上限。
根据本公开实施例的第二方面，提供一种插件加载装置，包括：加载模块，被配置为启动单个进程，并在所述单个进程中加载多个插件；分组模块，被配置为在检测到所述单个进程崩溃的情况下，执行至少一次分组加载操作直到所有崩溃进程均仅加载单个插件；其中，所述分组加载操作包括：对当前崩溃进程所包含的插件进行分组，并针对每个组分别启用一个新进程以加载对应组的插件。
可选地，所述分组模块被配置为：通过迭代的方式执行所述至少一次分组加载操作直到当前迭代启用的新进程中出现崩溃进程、且所述崩溃进程中仅包含一个插件；其中，针对每一次迭代，对当前崩溃进程所包含的插件进行分组并针对每个组分别启用一个新进程以加载对应组的插件；其中，在本次迭代启用的新进程中再次检测到崩溃进程的情况下，进入下一次迭代。
可选地，所述分组模块被配置为：将插件均匀划分为预设数量个组。
可选地，所述预设数量为2。
可选地，所述插件加载装置还包括：重复启用模块，被配置为重复启用预设次数的单独的进程加载所述崩溃进程所包含的所述单个插件，其中，所述单独的进程崩溃的情况下触发下一次启用。
可选地，所述分组模块被配置为：基于所述当前崩溃进程所包含的各个插件所需耗费的资源，对当前崩溃进程所包含的插件进行分组，使得每个组中的插件所需耗费的资源总和均衡。
可选地，所述分组模块被配置为：基于所述当前崩溃进程所包含的各个插件所需耗费的资源，确定分组数量，使得每个组中的插件所需耗费的资源总和不超过预定资源上限。
根据本公开实施例的第三方面，提供一种电子设备，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令，以实现根据本公开的插件加载方法。
根据本公开实施例的第四方面，提供一种计算机可读存储介质，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行根据本公开的插件加载方法。
本公开的实施例提供的技术方案至少带来以下有益效果：
在本公开中，由于每次均是对当前崩溃进程所包含的插件进行分组，因此，经过有限次分组之后，异常插件就可以被分配至一个单独的进程。这样，当检测到某个进程崩溃并且该崩溃进程仅包含一个插件时，则可以直接确定该插件是导致进程崩溃的原因，即可以快速锁定该插件为异常插件。进一步的，通过对当前崩溃进程所包含的插件进行分组的方式，可以使每个新进程仅加载崩溃进程中的部分插件，此时，异常插件仅仅会对其所在进程中的部分插件造成影响，而不会对其他新进程中的非异常插件造成任何干扰，可以保证大部分非异常插件的正常运行，提高了插件加载的稳定性。并且，当所有插件都无异常时，则为单进程运行状态，相比于直接使用多进程进行加载的方式，可以大大减少进程资源的消耗，避免所启动的进程数量过多而导致系统资源的过多占用。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。
图1是示出根据本公开的示例性实施例的插件加载方法的流程图；
图2是示出根据本公开的示例性实施例的插件加载过程的示意图；
图3是示出根据本公开的示例性实施例的插件加载装置的框图；
图4是示出根据本公开的示例性实施例的电子设备的框图。
具体实施方式
为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。
需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
在此需要说明的是，在本公开中出现的“若干项之中的至少一项”均表示包含“该若干项中的任意一项”、“该若干项中的任意多项的组合”、“该若干项的全体”这三类并列的情况。例如“包括A和B之中的至少一个”即包括如下三种并列的情况：（1）包括A；（2）包括B；（3）包括A和B。又例如“执行步骤一和步骤二之中的至少一个”，即表示如下三种并列的情况：（1）执行步骤一；（2）执行步骤二；（3）执行步骤一和步骤二。
在一个复杂的大型计算机系统中，其模块可能有上百个之多，如果将这些模块分属到不同的进程中运行，会导致所占用的系统资源过多，需要进一步压缩这部分进程运行后所占用的内存空间。如果把所有模块都集合到一个单独的进程来处理，很可能出现某个模块发生异常导致其他模块无法正常使用的情况。因此，目前迫切需要一种既能照顾系统内存空间占用大小，又能保障关键模块正常被加载的技术。
上述“进程”可以包含，但不限于系统守护进程（systemd）。系统守护进程是一个软件套件，它为Linux 操作系统提供一系列系统组件，其主要目标是统一Linux 发行版中的服务配置和行为。其开发目标是提供更优秀的框架以表示系统服务间的依赖关系，并依此实现系统初始化时服务的并行启动，同时达到降低Shell的系统开销的效果。系统守护进程的主要组件是“系统和服务管理器”，一个用于引导用户空间和管理用户进程的初始化系统。系统守护进程还提供各种守护程序和实用程序的替代品，包括设备管理、登录管理、网络连接管理和事件日志记录。
相关技术中，常用的插件加载方式为单进程方式以及多进程方式。其中，单进程方式是指将所有的插件都部署在同一个进程空间中运行，例如，这些插件可以共享宿主进程的代码段。但是，如果其中一个插件发生异常，就会导致进程崩溃，即会导致其他插件无法正常运行，插件加载的稳定性较差。多进程方式是指将每个插件都单独部署在一个单独的进程中运行，但是，这会启用数量较多的进程，而且部分进程资源无法共享，导致系统资源的额外消耗。
为了解决相关技术中存在的上述问题，本公开提供的插件加载方法、装置、电子设备和存储介质，由于每次均是对当前崩溃进程所包含的插件进行分组，因此，经过有限次分组之后，异常插件就可以被分配至一个单独的进程。这样，当检测到某个进程崩溃并且该崩溃进程仅包含一个插件时，则可以直接确定该插件是导致进程崩溃的原因，即可以快速锁定该插件为异常插件。进一步的，通过对当前崩溃进程所包含的插件进行分组的方式，可以使每个新进程仅加载崩溃进程中的部分插件，此时，异常插件仅仅会对其所在进程中的部分插件造成影响，而不会对其他新进程中的非异常插件造成任何干扰，可以保证大部分非异常插件的正常运行，提高了插件加载的稳定性。并且，当所有插件都无异常时，则为单进程运行状态，相比于直接使用多进程进行加载的方式，可以大大减少进程资源的消耗，避免所启动的进程数量过多而导致系统资源的过多占用。
图1是示出根据本公开的示例性实施例的插件加载方法的流程图。
参照图1，在步骤101中，可以启动单个进程，并可以在单个进程中加载多个插件。示例性的，上述单个进程可以为但不限于宿主进程，即可以先仅仅启动一个宿主进程，并利用该宿主进程加载所有的插件。其中，“宿主进程”能提高调试性能，支持部分信任调试并支持设计时表达式计算。
在步骤102中，在检测到上述单个进程崩溃的情况下，可以执行至少一次分组加载操作直到所有崩溃进程均仅加载单个插件。即在检测到上述单个进程崩溃的情况下，可以通过执行至少一次分组加载操作的方式，检测导致进程崩溃的异常插件，并可以在单独的进程中加载异常插件。其中，“分组加载操作”可以包括：对当前崩溃进程所包含的插件进行分组，并针对每个组分别启用一个新进程以加载对应组的插件。
这样，由于每次均是对当前崩溃进程所包含的插件进行分组，因此，经过有限次分组之后，异常插件就可以被分配至一个单独的进程。这样，当检测到某个进程崩溃并且该崩溃进程仅包含一个插件时，则可以直接确定该插件是导致进程崩溃的原因，即可以快速锁定该插件为异常插件。进一步的，通过对当前崩溃进程所包含的插件进行分组的方式，可以使每个新进程仅加载崩溃进程中的部分插件，此时，异常插件仅仅会对其所在进程中的部分插件造成影响，而不会对其他新进程中的非异常插件造成任何干扰，可以保证大部分非异常插件的正常运行，提高了插件加载的稳定性。并且，当所有插件都无异常时，则为单进程运行状态，相比于直接使用多进程进行加载的方式，可以大大减少进程资源的消耗，避免所启动的进程数量过多而导致系统资源的过多占用。
图2是示出根据本公开的示例性实施例的插件加载过程的示意图。参照图2，启动的单个进程可以为Process1，并且一共可以存在4个插件，分别为插件1（plug1）、插件2（plug2）、插件3（plug3）和插件4（plug4）。可以先将上述4个插件均部署在同一个进程空间Process1中运行。
当图2中的4个插件中的部分插件内部发生错误时，就会导致进程空间Process1崩溃，假设内部发生错误的插件为插件4。此时，可以对崩溃进程Process1所包含的4个插件进行分组，并可以分别启用不同的新进程以加载不同组的插件。
根据本公开的示例性实施例，可以通过迭代的方式执行至少一次分组加载操作直到当前迭代启用的新进程中出现崩溃进程、且崩溃进程中仅包含一个插件。即可以通过迭代的方式检测异常插件直至迭代终止，并且，可以确定迭代终止时的崩溃进程所包含的插件为异常插件，也即可以确定迭代终止时的崩溃进程所包含的插件为上述内部发生错误的插件。需要说明的是，迭代次数与所需加载插件的总数有关。插件总数越多，则需要的迭代次数就越多；插件总数越少，则需要的迭代次数就越少。但是，无论插件总数为多少，经过可预见的有限次迭代之后，即可以确定导致进程崩溃的异常插件。
其中，针对每一次迭代，可以对当前崩溃进程所包含的插件进行分组并可以针对每个组分别启用一个新进程以加载对应组的插件。并且，在本次迭代启用的新进程中再次检测到崩溃进程的情况下，可以进入下一次迭代。
示例性的，如前所述，最开始时，可以先仅仅启动一个进程Process1，并利用该进程Process1加载全部的4个插件。如果4个插件中的插件4内部发生错误，就会导致进程Process1崩溃。此时，可以进入首次迭代。针对该首次迭代，当前崩溃进程即为Process1。因此，可以对该当前崩溃进程Process1所包含的4个插件进行分组并可以利用不同的新进程分别加载不同组的插件。
示例性的，可以将当前崩溃进程Process1所包含的4个插件划分为两组，每个组内可以包含两个插件，并可以利用两个新进程分别加载这两组的插件。参照图2，启用的两个新进程分别为Process2-1和Process2-2。并且，新进程Process2-1用于加载当前崩溃进程Process1所包含的4个插件中的插件1和插件2，新进程Process2-2用于加载当前崩溃进程Process1所包含的4个插件中的插件3和插件4。
接下来，如果插件4仍然异常，会继续导致其所在的进程Process2-2的崩溃。此时，由于首次迭代启用的两个新进程Process2-1和Process2-2中再次检测到崩溃进程Process2-2，则可以进入下一次迭代，即可以进入第2次迭代。此时，针对该第2次迭代，“当前崩溃进程”即为Process2-2，可以对该当前崩溃进程Process2-2所包含的两个插件进行分组，并可以利用不同的新进程分别加载不同组的插件。
示例性的，参照图2，在第2次迭代过程中，仍然可以启用两个新进程，分别为Process3-1和Process3-2，并且，新进程Process3-1用于加载当前崩溃进程Process2-2所包含的两个插件中的插件3，新进程Process3-2用于加载当前崩溃进程Process2-2所包含的两个插件中的插件4。此时，插件4即处于一个单独的进程Process3-2中，就算插件4出现错误，也仅仅会导致其所在的进程Process3-2的崩溃，而不会对其他的两个进程Process2-1和Process3-1造成任何干扰，即不会影响其他的3个插件：插件1、插件2和插件3的正常运行。
接下来，如果插件4仍然异常，会继续导致其所在的进程Process3-2的崩溃。此时，由于第2次迭代启用的两个新进程Process3-1和Process3-2中再次检测到崩溃进程Process3-2，则可以进入下一次迭代，即可以进入第3次迭代。此时，针对该第3次迭代，“当前崩溃进程”即为Process3-2，由于该当前崩溃进程Process3-2仅仅包含一个插件，即插件4，因此，可以直接确定插件4即为导致进程Process3-2崩溃的原因，即插件4为异常插件。同时，迭代过程也随即终止。
这样，针对每一次迭代，均可以对插件进行分组并利用不同的新进程分别加载不同组的插件，即此时每个新进程仅仅加载当前崩溃进程所包含的全部插件中的部分插件，就算某个插件出现异常，也仅仅会对其所在的进程内的一小部分插件造成影响，而不会对其他进程中的插件运行造成任何干扰，可以保证其他大部分非异常插件的正常运行，大大提高了插件加载的稳定性。
根据本公开的示例性实施例，在对多个插件进行分组时，可以将插件均匀划分为预设数量个组，该预设数量可以根据实际需要灵活设置。示例性的，可以将该预设数量设置为2、3、5等等，本公开对预设数量的大小不做具体限制。这样，由于可以根据实际需要设置预设数量，因此，可以使对插件的分组更加灵活，可以满足在不同场景下的实际需求。
根据本公开的示例性实施例，上述预设数量可以为2，即可以采用均分的方式对崩溃进程所包含的插件进行分组。其中，这里的“均分”是指保持两个新进程所分配到的插件的数量大致均衡，并不一定要求两个新进程所分配到的插件的数量必须相同。
例如，在崩溃进程所包含的插件的数量为偶数的情况下，则两个新进程被分配到的插件的数量是相同的；在崩溃进程所包含的插件的数量为奇数的情况下，则两个新进程被分配到的插件的数量是不同的。此时，只需要保证大致满足均分的程度就可以，即只需要保证两个新进程被分配到的插件的数量的差距较小即可。示例性的，假设崩溃进程所包含的插件的数量为7个，则可以为启用的两个新进程中的一个新进程分配3个插件，并且为另一个新进程分配4个插件。
根据本公开的示例性实施例，在对当前崩溃进程所包含的插件进行分组时，可以获取当前崩溃进程所包含的各个插件所需耗费的资源。其中，不同插件在加载时所需耗费的资源可能是不同的，即某些插件所需耗费的资源可能比较小，而某些插件所需耗费的资源可能比较大。并且，这里的“资源”可以为但不限于内存资源、计算资源等等。可以基于当前崩溃进程所包含的各个插件所需耗费的资源，对当前崩溃进程所包含的插件进行分组，使得每个组中的插件所需耗费的资源总和均衡。其中，“资源总和均衡”的含义可以是指资源总和大致平均，即彼此之间相差不多，并不要求彼此之间完全相等。
这样，在划分分组时，通过控制各个组的插件所需耗费的资源总和大致相同，可以保证各个新进程的负载大致均衡，降低某些新进程因负载过重而发生崩溃的风险，以及减少某些新进程因负载过轻而导致的进程资源的过度浪费。
根据本公开的示例性实施例，在对当前崩溃进程所包含的插件进行分组时，还可以基于当前崩溃进程所包含的各个插件所需耗费的资源，确定分组数量，使得每个组中的插件所需耗费的资源总和不超过预定资源上限。
示例性的，可以先计算当前崩溃进程所包含的全部插件所需耗费的资源总和。然后，可以计算该资源总和与预定资源上限的比值。接下来，可以基于该比值对当前崩溃进程所包含的插件进行分组。示例性的，可以针对该比值进行向上取整，获得基准整数。然后，可以直接将该基准整数确定为实际的分组数量，或者，还可以将高于该基准整数的整数确定为实际的分组数量等等。
这样，通过控制每个组中的插件所需耗费的资源总和不超过预定资源上限，不但可以保证每个新进程的负载均衡，还可以降低每个新进程因实际负载超过其负载上限而导致该新进程崩溃的风险。
需要说明的是，在对插件进行分组时，除了按照上述负载均衡原则、避免进程因负载过重而崩溃的原则进行分组之外，还可以使用其他分组方式，示例性的，可以使用随机分组方式等等，本公开对插件分组的方式不作具体限定。其中，“随机分组方式”是指将插件随机分配至不同的分组，即每个组内的至少一个插件都是随机组合获得的。
根据本公开的示例性实施例，上述迭代终止的条件可以为：本次迭代启用的新进程中出现崩溃进程、且该崩溃进程中仅包含一个插件。这样，由于进程中仅包含一个插件，一旦进程出现崩溃，可以直接确定该插件为导致进程崩溃的原因，可以实现快速锁定异常插件。
根据本公开的示例性实施例，可以重复启用预设次数的单独的进程加载崩溃进程所包含的单个插件，其中，单独的进程崩溃的情况下触发下一次启用。示例性的，返回参照图2，经过2次迭代之后，问题插件，即插件4被单独分配至一个进程Process3-2中运行。此时，如果插件4仍然异常，仅仅会导致进程Process3-2的崩溃，并不会对其他的2个进程Process2-1和Process3-1造成任何干扰。并且，此时可以连续多次启用新进程来加载插件4，其中，当前进程崩溃时即触发下一个新进程的启用。示例性的，可以先启用一个单独的新进程Process4-1来加载插件4，如果插件4仍然异常导致进程Process4-1崩溃，则可以继续启动一个单独的新进程来加载插件4，以此类推，直至启用新进程的次数达到次数上限为止。
这样，通过重复启用预设次数的单独的进程来加载异常插件的方式，即通过重复多次尝试加载异常插件的方式，可以提高异常插件被加载成功的几率。并且，由于每次均是启用一个单独的新进程来加载异常插件，该异常插件不会对其他进程中的插件运行造成任何不利影响，可以保证其他大部分非异常插件的稳定运行，提高了插件运行的稳定性。
需要说明的是，在Linux操作系统下，可以使用系统守护进程的unit服务来完成上述插件加载的过程。针对其他平台，则可以借助相关服务或自行创建服务来执行上述插件加载过程。
进一步的，返回参照图2，图2中以插件4为异常插件为例解释了本公开的插件加载过程。而在实际场景中，出现错误的插件可能不仅只有一个，可能存在多个。例如，图2中的进程Process1中可能出现两个问题插件，分别为插件2和插件4。或者，某些插件虽然在最开始时并未出现异常，但是在后续的迭代过程中可能出现异常，即在迭代过程中可能出现新的异常插件。例如，返回参照图2，在最开始利用进程Process1加载全部插件时，仅仅是插件4出现了异常，其他的3个插件并未出现异常。但是，经过第1次迭代之后，进程Process2-1在加载插件1和插件2的过程中，插件1或者插件2可能突然出现异常等等。但是，无论是前述哪种情况，均可以使用本公开的插件加载方法进行插件加载。
图3是示出根据本公开的示例性实施例的插件加载装置的框图。
参照图3，该插件加载装置300可包括加载模块301和分组模块302。
加载模块301可以启动单个进程，并可以在单个进程中加载多个插件。示例性的，上述单个进程可以为但不限于宿主进程，即可以先仅仅启动一个宿主进程，并利用该宿主进程加载所有的插件。其中，“宿主进程”能提高调试性能，支持部分信任调试并支持设计时表达式计算。
分组模块302在检测到单个进程崩溃的情况下，可以执行至少一次分组加载操作直到所有崩溃进程均仅加载单个插件。即在检测到上述单个进程崩溃的情况下，可以通过执行至少一次分组加载操作的方式，检测导致进程崩溃的异常插件，并可以在单独的进程中加载异常插件。其中，“分组加载操作”可以包括：对当前崩溃进程所包含的插件进行分组，并针对每个组分别启用一个新进程以加载对应组的插件。
这样，由于每次均是对当前崩溃进程所包含的插件进行分组，因此，经过有限次分组之后，异常插件就可以被分配至一个单独的进程。这样，当检测到某个进程崩溃并且该崩溃进程仅包含一个插件时，则可以直接确定该插件是导致进程崩溃的原因，即可以快速锁定该插件为异常插件。进一步的，通过对当前崩溃进程所包含的插件进行分组的方式，可以使每个新进程仅加载崩溃进程中的部分插件，此时，异常插件仅仅会对其所在进程中的部分插件造成影响，而不会对其他新进程中的非异常插件造成任何干扰，可以保证大部分非异常插件的正常运行，提高了插件加载的稳定性。并且，当所有插件都无异常时，则为单进程运行状态，相比于直接使用多进程进行加载的方式，可以大大减少进程资源的消耗，避免所启动的进程数量过多而导致系统资源的过多占用。
根据本公开的示例性实施例，分组模块302可以通过迭代的方式执行至少一次分组加载操作直到当前迭代启用的新进程中出现崩溃进程、且崩溃进程中仅包含一个插件。即分组模块302可以通过迭代的方式检测异常插件直至迭代终止，并且，可以确定迭代终止时的崩溃进程所包含的插件为异常插件，即可以确定迭代终止时的崩溃进程所包含的插件为上述内部发生错误的插件。需要说明的是，迭代次数与所需加载插件的总数有关。插件总数越多，则需要的迭代次数就越多；插件总数越少，则需要的迭代次数就越少。但是，无论插件总数为多少，经过可预见的有限次迭代之后，即可以确定导致进程崩溃的异常插件。
其中，针对每一次迭代，可以对当前崩溃进程所包含的插件进行分组并可以针对每个组分别启用一个新进程以加载对应组的插件。并且，在本次迭代启用的新进程中再次检测到崩溃进程的情况下，可以进入下一次迭代。
这样，针对每一次迭代，均可以对插件进行分组并利用不同的新进程分别加载不同组的插件，即此时每个新进程仅仅加载当前崩溃进程所包含的全部插件中的部分插件，就算某个插件出现异常，也仅仅会对其所在的进程内的一小部分插件造成影响，而不会对其他进程中的插件运行造成任何干扰，可以保证其他大部分非异常插件的正常运行，大大提高了插件加载的稳定性。
根据本公开的示例性实施例，分组模块302在对多个插件进行分组时，可以将插件均匀划分为预设数量个组，该预设数量可以根据实际需要灵活设置。示例性的，可以将该预设数量设置为2、3、5等等，本公开对预设数量的大小不做具体限制。这样，由于可以根据实际需要设置预设数量，因此，可以使对插件的分组更加灵活，可以满足在不同场景下的实际需求。
根据本公开的示例性实施例，上述预设数量可以为2，即可以采用均分的方式对崩溃进程所包含的插件进行分组。其中，这里的“均分”是指保持两个新进程所分配到的插件的数量大致均衡，并不一定要求两个新进程所分配到的插件的数量必须相同。
例如，在崩溃进程所包含的插件的数量为偶数的情况下，则两个新进程被分配到的插件的数量是相同的；在崩溃进程所包含的插件的数量为奇数的情况下，则两个新进程被分配到的插件的数量是不同的。此时，只需要保证大致满足均分的程度就可以，即只需要保证两个新进程被分配到的插件的数量的差距较小即可。示例性的，假设崩溃进程所包含的插件的数量为7个，则可以为启用的两个新进程中的一个新进程分配3个插件，并且为另一个新进程分配4个插件。
根据本公开的示例性实施例，分组模块302在对当前崩溃进程所包含的插件进行分组时，可以获取当前崩溃进程所包含的各个插件所需耗费的资源。其中，不同插件在加载时所需耗费的资源可能是不同的，即某些插件所需耗费的资源可能比较小，而某些插件所需耗费的资源可能比较大。并且，这里的“资源”可以为但不限于内存资源、计算资源等等。可以基于当前崩溃进程所包含的各个插件所需耗费的资源，对当前崩溃进程所包含的插件进行分组，使得每个组中的插件所需耗费的资源总和均衡。其中，“资源总和均衡”的含义可以是指资源总和大致平均，即彼此之间相差不多，并不要求彼此之间完全相等。
这样，在划分分组时，通过控制各个组的插件所需耗费的资源总和大致相同，可以保证各个新进程的负载大致均衡，降低某些新进程因负载过重而发生崩溃的风险，以及减少某些新进程因负载过轻而导致的进程资源的过度浪费。
根据本公开的示例性实施例，分组模块302在对当前崩溃进程所包含的插件进行分组时，还可以基于当前崩溃进程所包含的各个插件所需耗费的资源，确定分组数量，使得每个组中的插件所需耗费的资源总和不超过预定资源上限。
示例性的，可以先计算当前崩溃进程所包含的全部插件所需耗费的资源总和。然后，可以计算该资源总和与预定资源上限的比值。接下来，可以基于该比值对当前崩溃进程所包含的插件进行分组。示例性的，可以针对该比值进行向上取整，获得基准整数。然后，可以直接将该基准整数确定为实际的分组数量，或者，还可以将高于该基准整数的整数确定为实际的分组数量等等。
这样，通过控制每个组中的插件所需耗费的资源总和不超过预定资源上限，不但可以保证每个新进程的负载均衡，还可以降低每个新进程因实际负载超过其负载上限而导致该新进程崩溃的风险。
需要说明的是，在对插件进行分组时，除了按照上述负载均衡原则、避免进程因负载过重而崩溃的原则进行分组之外，还可以使用其他分组方式，示例性的，可以使用随机分组方式等等，本公开对插件分组的方式不作具体限定。其中，“随机分组方式”是指将插件随机分配至不同的分组，即每个组内的至少一个插件都是随机组合获得的。
根据本公开的示例性实施例，上述迭代终止的条件可以为：本次迭代启用的新进程中出现崩溃进程、且该崩溃进程中仅包含一个插件。这样，由于进程中仅包含一个插件，一旦进程出现崩溃，可以直接确定该插件为导致进程崩溃的原因，可以实现快速锁定异常插件。
根据本公开的示例性实施例，插件加载装置300还可以包含重复启用模块，该重复启用模块可以重复启用预设次数的单独的进程加载崩溃进程所包含的单个插件。其中，单独的进程崩溃的情况下触发下一次启用，直至启用新进程的次数达到次数上限为止。
这样，通过重复启用预设次数的单独的进程来加载异常插件的方式，即通过重复多次尝试加载异常插件的方式，可以提高异常插件被加载成功的几率。并且，由于每次均是启用一个单独的新进程来加载异常插件，该异常插件不会对其他进程中的插件运行造成任何不利影响，可以保证其他大部分非异常插件的稳定运行，提高了插件运行的稳定性。
需要说明的是，在Linux操作系统下，可以使用系统守护进程的unit服务来完成上述插件加载的过程。针对其他平台，则可以借助相关服务或自行创建服务来执行上述插件加载过程。
图4是示出根据本公开的示例性实施例的电子设备400的框图。
参照图4，电子设备400包括至少一个存储器401、至少一个处理器402、操作系统403和应用程序404。其中，至少一个存储器401中存储有指令，当指令被至少一个处理器402执行时，执行根据本公开的示例性实施例的插件加载方法。并且，本公开中的插件均为在应用程序404中运行的插件。
作为示例，电子设备400可以是PC计算机、平板装置、个人数字助理、智能手机、或其他能够执行上述指令的装置。这里，电子设备400并非必须是单个的电子设备，还可以是任何能够单独或联合执行上述指令（或指令集）的装置或电路的集合体。电子设备400还可以是集成控制系统或系统管理器的一部分，或者可被配置为与本地或远程（例如，经由无线传输）以接口互联的便携式电子设备。
在电子设备400中，处理器402可包括中央处理器（CPU）、图形处理器（GPU）、可编程逻辑装置、专用处理器系统、微控制器或微处理器。作为示例而非限制，处理器还可包括模拟处理器、数字处理器、微处理器、多核处理器、处理器阵列、网络处理器等。
处理器402可运行存储在存储器401中的指令或代码，其中，存储器401还可以存储数据。指令和数据还可经由网络接口装置而通过网络被发送和接收，其中，网络接口装置可采用任何已知的传输协议。
存储器401可与处理器402集成为一体，例如，将RAM或闪存布置在集成电路微处理器等之内。此外，存储器401可包括独立的装置，诸如，外部盘驱动、存储阵列或任何数据库系统可使用的其他存储装置。存储器401和处理器402可在操作上进行耦合，或者可例如通过I/O端口、网络连接等互相通信，使得处理器402能够读取存储在存储器中的文件。
此外，电子设备400还可包括视频显示器（诸如，液晶显示器）和用户交互接口（诸如，键盘、鼠标、触摸输入装置等）。电子设备400的所有组件可经由总线和/或网络而彼此连接。
根据本公开的示例性实施例，还可提供一种计算机可读存储介质，当计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述插件加载方法。这里的计算机可读存储介质的示例包括：只读存储器（ROM）、随机存取可编程只读存储器（PROM）、电可擦除可编程只读存储器（EEPROM）、随机存取存储器（RAM）、动态随机存取存储器（DRAM）、静态随机存取存储器（SRAM）、闪存、非易失性存储器、CD-ROM、CD-R、CD+R、CD-RW、CD+RW、DVD-ROM、DVD-R、DVD+R、DVD-RW、DVD+RW、DVD-RAM、BD-ROM、BD-R、BD-R LTH、BD-RE、蓝光或光盘存储器、硬盘驱动器（HDD）、固态硬盘（SSD）、卡式存储器（诸如，多媒体卡、安全数字（SD）卡或极速数字（XD）卡）、磁带、软盘、磁光数据存储装置、光学数据存储装置、硬盘、固态盘以及任何其他装置，所述任何其他装置被配置为以非暂时性方式存储计算机程序以及任何相关联的数据、数据文件和数据结构并将所述计算机程序以及任何相关联的数据、数据文件和数据结构提供给处理器或计算机使得处理器或计算机能执行所述计算机程序。上述计算机可读存储介质中的计算机程序可在诸如客户端、主机、代理装置、服务器等计算机设备中部署的环境中运行，此外，在一个示例中，计算机程序以及任何相关联的数据、数据文件和数据结构分布在联网的计算机系统上，使得计算机程序以及任何相关联的数据、数据文件和数据结构通过一个或多个处理器或计算机以分布式方式存储、访问和执行。
根据本公开的插件加载方法、装置、电子设备和存储介质，由于每次均是对当前崩溃进程所包含的插件进行分组，因此，经过有限次分组之后，异常插件就可以被分配至一个单独的进程。这样，当检测到某个进程崩溃并且该崩溃进程仅包含一个插件时，则可以直接确定该插件是导致进程崩溃的原因，即可以快速锁定该插件为异常插件。进一步的，通过对当前崩溃进程所包含的插件进行分组的方式，可以使每个新进程仅加载崩溃进程中的部分插件，此时，异常插件仅仅会对其所在进程中的部分插件造成影响，而不会对其他新进程中的非异常插件造成任何干扰，可以保证大部分非异常插件的正常运行，提高了插件加载的稳定性。并且，当所有插件都无异常时，则为单进程运行状态，相比于直接使用多进程进行加载的方式，可以大大减少进程资源的消耗，避免所启动的进程数量过多而导致系统资源的过多占用。
进一步的，针对每一次迭代，均可以对插件进行分组并利用不同的新进程分别加载不同组的插件，即此时每个新进程仅仅加载当前崩溃进程所包含的全部插件中的部分插件，就算某个插件出现异常，也仅仅会对其所在的进程内的一小部分插件造成影响，而不会对其他进程中的插件运行造成任何干扰，可以保证其他大部分非异常插件的正常运行，大大提高了插件加载的稳定性。
进一步的，由于可以根据实际需要设置预设数量，因此，可以使对插件的分组更加灵活，可以满足在不同场景下的实际需求。
进一步的，由于进程中仅包含一个插件，一旦进程出现崩溃，可以直接确定该插件为导致进程崩溃的原因，可以实现快速锁定异常插件。
进一步的，通过重复启用预设次数的单独的进程来加载异常插件的方式，即通过重复多次尝试加载异常插件的方式，可以提高异常插件被加载成功的几率。并且，由于每次均是启用一个单独的新进程来加载异常插件，该异常插件不会对其他进程中的插件运行造成任何不利影响，可以保证其他大部分非异常插件的稳定运行，提高了插件运行的稳定性。
进一步的，在划分分组时，通过控制各个组的插件所需耗费的资源总和大致相同，可以保证各个新进程的负载大致均衡，降低某些新进程因负载过重而发生崩溃的风险，以及减少某些新进程因负载过轻而导致的进程资源的过度浪费。
进一步的，通过控制每个组中的插件所需耗费的资源总和不超过预定资源上限，不但可以保证每个新进程的负载均衡，还可以降低每个新进程因实际负载超过其负载上限而导致该新进程崩溃的风险。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。
应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。
Claims (10)
1.一种插件加载方法，其特征在于，包括：
启动单个进程，并在所述单个进程中加载多个插件；
在检测到所述单个进程崩溃的情况下，执行至少一次分组加载操作直到所有崩溃进程均仅加载单个插件；
其中，所述分组加载操作包括：对当前崩溃进程所包含的插件进行分组，并针对每个组分别启用一个新进程以加载对应组的插件。
2.如权利要求1所述的插件加载方法，其特征在于，所述执行至少一次分组加载操作直到所有崩溃进程均仅加载单个插件，包括：
通过迭代的方式执行所述至少一次分组加载操作直到当前迭代启用的新进程中出现崩溃进程、且所述崩溃进程中仅包含一个插件；
其中，针对每一次迭代，对当前崩溃进程所包含的插件进行分组并针对每个组分别启用一个新进程以加载对应组的插件；
其中，在本次迭代启用的新进程中再次检测到崩溃进程的情况下，进入下一次迭代。
3.如权利要求1或2所述的插件加载方法，其特征在于，所述分组的步骤包括：
将插件均匀划分为预设数量个组。
4.如权利要求3所述的插件加载方法，其特征在于，所述预设数量为2。
5.如权利要求1所述的插件加载方法，其特征在于，所述插件加载方法还包括：
重复启用预设次数的单独的进程加载所述崩溃进程所包含的所述单个插件，其中，所述单独的进程崩溃的情况下触发下一次启用。
6.如权利要求1所述的插件加载方法，其特征在于，所述对当前崩溃进程所包含的插件进行分组的步骤包括：
基于所述当前崩溃进程所包含的各个插件所需耗费的资源，对当前崩溃进程所包含的插件进行分组，使得每个组中的插件所需耗费的资源总和均衡。
7.如权利要求1或6所述的插件加载方法，其特征在于，所述对当前崩溃进程所包含的插件进行分组的步骤还包括：
基于所述当前崩溃进程所包含的各个插件所需耗费的资源，确定分组数量，使得每个组中的插件所需耗费的资源总和不超过预定资源上限。
8.一种插件加载装置，其特征在于，包括：
加载模块，被配置为启动单个进程，并在所述单个进程中加载多个插件；
分组模块，被配置为在检测到所述单个进程崩溃的情况下，执行至少一次分组加载操作直到所有崩溃进程均仅加载单个插件；
其中，所述分组加载操作包括：对当前崩溃进程所包含的插件进行分组，并针对每个组分别启用一个新进程以加载对应组的插件。
9.一种电子设备，其特征在于，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如权利要求1至7中任一项所述的插件加载方法。
10.一种计算机可读存储介质，其特征在于，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如权利要求1至7中任一项所述的插件加载方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311255671.8A CN116991505A (zh) | 2023-09-26 | 2023-09-26 | 插件加载方法、装置、电子设备和存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311255671.8A CN116991505A (zh) | 2023-09-26 | 2023-09-26 | 插件加载方法、装置、电子设备和存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116991505A true CN116991505A (zh) | 2023-11-03 |
Family
ID=88523592
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311255671.8A Pending CN116991505A (zh) | 2023-09-26 | 2023-09-26 | 插件加载方法、装置、电子设备和存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116991505A (zh) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102982169A (zh) * | 2012-12-12 | 2013-03-20 | 北京奇虎科技有限公司 | 用于隔离网页插件的浏览器和方法 |
| US20130191526A1 (en) * | 2011-03-14 | 2013-07-25 | Tencent Technology Shenzhen Company Limited | Open plug-in management platform and plug-in management method implemented on browser |
| CN111538585A (zh) * | 2019-12-31 | 2020-08-14 | 浙江明度智控科技有限公司 | 一种基于node.js的服务器进程调度方法、系统和装置 |
| CN112306833A (zh) * | 2020-10-28 | 2021-02-02 | 广州虎牙科技有限公司 | 应用程序的崩溃统计方法、装置、计算机设备及存储介质 |
| CN113342600A (zh) * | 2021-05-31 | 2021-09-03 | 中国工商银行股份有限公司 | 一种程序依赖插件的监测方法及装置 |
| CN114546511A (zh) * | 2020-11-11 | 2022-05-27 | 华为技术有限公司 | 插件管理方法、系统及装置 |
| CN115437882A (zh) * | 2022-08-31 | 2022-12-06 | 重庆长安汽车股份有限公司 | 一种车载Android系统的应用崩溃监控方法、装置及存储介质 |
-
2023
- 2023-09-26 CN CN202311255671.8A patent/CN116991505A/zh active Pending
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20130191526A1 (en) * | 2011-03-14 | 2013-07-25 | Tencent Technology Shenzhen Company Limited | Open plug-in management platform and plug-in management method implemented on browser |
| CN102982169A (zh) * | 2012-12-12 | 2013-03-20 | 北京奇虎科技有限公司 | 用于隔离网页插件的浏览器和方法 |
| CN111538585A (zh) * | 2019-12-31 | 2020-08-14 | 浙江明度智控科技有限公司 | 一种基于node.js的服务器进程调度方法、系统和装置 |
| CN112306833A (zh) * | 2020-10-28 | 2021-02-02 | 广州虎牙科技有限公司 | 应用程序的崩溃统计方法、装置、计算机设备及存储介质 |
| CN114546511A (zh) * | 2020-11-11 | 2022-05-27 | 华为技术有限公司 | 插件管理方法、系统及装置 |
| CN113342600A (zh) * | 2021-05-31 | 2021-09-03 | 中国工商银行股份有限公司 | 一种程序依赖插件的监测方法及装置 |
| CN115437882A (zh) * | 2022-08-31 | 2022-12-06 | 重庆长安汽车股份有限公司 | 一种车载Android系统的应用崩溃监控方法、装置及存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5828348B2 (ja) | 試験サーバ、情報処理システム、試験プログラムおよび試験方法 | |
| RU2571726C2 (ru) | Система и способ проверки целесообразности установки обновлений | |
| US10956143B2 (en) | Server updates | |
| US10114952B2 (en) | System, apparatus and method for performing secure memory training and management in a trusted environment | |
| US20140122931A1 (en) | Performing diagnostic tests in a data center | |
| US8812915B2 (en) | Determining whether a right to use memory modules in a reliability mode has been acquired | |
| CN109189627B (zh) | 一种硬盘故障监控检测方法、装置、终端及存储介质 | |
| Vargas et al. | High availability fundamentals | |
| US12117927B2 (en) | Method and system for scalable performance testing in cloud computing environments | |
| CN112306784A (zh) | 一种测试方法、装置、电子设备和测试系统 | |
| CN111181780A (zh) | 基于ha集群的主机池切换方法、系统、终端及存储介质 | |
| US9135002B1 (en) | Systems and methods for recovering an application on a computing device | |
| US11163630B2 (en) | Using real-time analytics to manage application features | |
| US7610429B2 (en) | Method and system for determining device criticality in a computer configuration | |
| CN110399168B (zh) | 多数据盘存储服务器的系统启动方法、装置及设备 | |
| US11921604B2 (en) | Evaluating system recovery using emulated production systems | |
| US6996648B2 (en) | Generating notification that a new memory module has been added to a second memory slot in response to replacement of a memory module in a first memory slot | |
| US11126486B2 (en) | Prediction of power shutdown and outage incidents | |
| CN116991505A (zh) | 插件加载方法、装置、电子设备和存储介质 | |
| US20180081729A1 (en) | Methods and modules relating to allocation of host machines | |
| US9471433B2 (en) | Optimizing computer hardware usage in a computing system that includes a plurality of populated central processing unit (‘CPU’) sockets | |
| US11144487B1 (en) | Method to overload hardware pin for improved system management | |
| US11048523B2 (en) | Enabling software sensor power operation requests via baseboard management controller (BMC) | |
| US12079072B2 (en) | Orchestration of automated virtual machine failure replacement in a node cluster | |
| CN116483641B (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 |