Method for monitoring and debugging multi-threaded network devices

Abstract

The present invention relates to a method for monitoring and debugging multi-threaded network equipment, comprising the following steps: monitoring the CPU usage rate of each network protocol thread / process of the system, obtaining the baseline rate, upper limit rate, lower limit rate, and current usage rate through an artificial intelligence algorithm; issuing an alarm if the current usage rate is higher than the upper limit rate or lower than the lower limit rate; performing performance diagnosis, notifying each protocol thread / process to perform performance detection and report the results, analyzing the results, and combining the artificial intelligence algorithm to obtain a stable baseline performance, upper limit performance, and current execution performance. When the execution performance of a certain protocol thread / process is lower than the lower limit, the current resource usage status of the protocol thread / process is analyzed and repaired, and then an alarm is issued. As a result, when a network device has problems in network operation, the problem can be quickly located and the pain point solved. It can be realized to diagnose the execution performance of each network protocol thread / process.

Description

Technical Field

[0001] The invention relates to a multi-threaded network program, and in particular to a multi-threaded network equipment monitoring and debugging method. Background Art

[0002] For conventional network equipment, when problems occur in actual network operation, it is impossible to quickly locate the problematic node and provide effective self-repair. Especially for switches, wireless access points or routers, when problems occur in the network, some ineffective monitoring and debugging are difficult to change, which often results in data transmission loss, affecting the smooth operation of other devices connected to the network and easily causing irreversible losses.

[0003] In view of the above-mentioned defects, the designers have actively carried out research and innovation in order to create a method for monitoring and debugging multi-threaded network equipment to make it more valuable for industrial use. Summary of the invention

[0004] To solve the above technical problems, the purpose of the present invention is to provide a method for monitoring and debugging multi-threaded network devices.

[0005] The present invention provides a method for monitoring and debugging multi-threaded network equipment, which comprises the following steps:

[0006] Step 1: Monitor the CPU usage of each network protocol thread / process in the system and use artificial intelligence algorithms to derive the baseline rate (CU basel ), upper limit rate (CU upl ), lower limit rate (CU downl ), current usage (CU cul );

[0007] Step 2: If the current usage rate is higher than the upper limit or lower than the lower limit, an alarm is issued;

[0008] Step 3: Perform performance diagnosis, notify each protocol thread / process to perform performance detection and report the results, analyze the results, and combine artificial intelligence algorithms to obtain a stable baseline performance (PV base ), upper limit performance (PV up ), current execution performance (PV cur );

[0009] Step 4: Repair processing: when the execution efficiency of a protocol thread / process is lower than the lower limit, the current resource usage status of the protocol thread / process is analyzed and repaired, and then an alarm is issued.

[0010] Furthermore, in the above-mentioned method for monitoring and debugging multi-threaded network devices, the baseline rate (CU basel) is obtained by:

[0011] set up

[0012] Among them, CU basel Indicates the baseline rate, i indicates the count of each sampling when the network is historically stable, n indicates the maximum number of samplings, which is 10,000 by default, and data is collected once a minute, and Cui indicates the CPU usage of the current sampling.

[0013] Furthermore, in the above-mentioned method for monitoring and debugging multi-threaded network devices, the upper limit line rate (CU upl ) is obtained by setting CU upl =CU basel +2σ,CU upl , expressed as, upper limit rate = baseline rate plus 2 standard deviations;

[0014] The lower limit rate (CU downl ) is obtained by setting CU downl =CU basel -2σ,CU downl , expressed as, lower limit rate = baseline rate minus 2 standard deviations;

[0015] The upper limit efficacy (PV up ) is expressed as, PV up =PV base +2σ, that is, the upper limit performance value = the benchmark performance value plus 2 standard deviations,

[0016] is the average value.

[0017] Furthermore, in the above-mentioned method for monitoring and debugging multi-threaded network devices, in the step 2, the upper limit line rate (CU) is collected per minute. upl ) data to determine whether it exceeds the upper limit rate (CU upl ) or below the lower limit rate (CU downl ).

[0018] Furthermore, in the above-mentioned method for monitoring and debugging multi-threaded network devices, the benchmark performance (PV base ) is expressed as, Where i represents the count of each sampling when the network is stable in history, n represents the maximum number of sampling, which is 10,000 times, and data is collected once a minute. PVi is the execution performance of the current sampling.

[0019] Furthermore, in the above-mentioned method for monitoring and debugging multi-threaded network devices, the repair process is as follows: if the protocol thread exceeds the upper limit performance value, the current protocol thread resource data is obtained, and the resource usage of the protocol process / thread is checked to see if there is a memory leak and memory resources are occupied, and the memory and resources are released accordingly. If the problem cannot be solved, the protocol process / thread is restarted;

[0020] Alternatively, if the protocol thread does not respond, check whether there is a deadlock. If a deadlock occurs, unlock it after analysis, restart or close the process / thread that caused the deadlock, and if it cannot be resolved, restart the protocol process / thread.

[0021] Furthermore, in the above-mentioned method for monitoring and debugging multi-threaded network devices, if the data is always at the baseline rate (CU basel ) or above the baseline rate (CU basel ) or less, calibration is performed to obtain the updated new base line rate, upper limit line rate and lower limit line rate.

[0022] Furthermore, in the above-mentioned method for monitoring and debugging multi-threaded network devices, for a stable network, calibration is set to be performed once every six months; or, calibration is triggered by a command.

[0023] Furthermore, in the above-mentioned method for monitoring and debugging multi-threaded network devices, in step four, resources are expressed using tables, event message queues and semaphores, and if the protocol thread / process does not respond to the execution request, repair processing is performed immediately.

[0024] By means of the above scheme, the present invention has at least the following advantages:

[0025] 1. When network equipment has problems in network operation, the problem can be quickly located and the pain point solved.

[0026] 2. It is possible to diagnose the execution performance of each network protocol thread / process.

[0027] 3. It can issue an alarm for abnormalities and automatically start the repair mechanism after the alarm.

[0028] 4. The repair efficiency is high and can meet the use of conventional equipment that supports a variety of network communication protocols, and is suitable for conventional switches, wireless access points or routers.

[0029] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention and implement it according to the contents of the specification, the following is a detailed description of the preferred embodiments of the present invention in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 This is the CPU usage distribution status diagram of protocol thread A in the historical stable network.

[0031] Figure 2 It is a normal distribution graph of CPU usage of historical stable network data.

[0032] Figure 3 It is the CPU usage status of protocol thread A.

[0033] Figure 4 It is the execution performance distribution state diagram of protocol thread A.

[0034] Figure 5 It is a normal distribution graph of historical stable network execution performance data.

[0035] Figure 6 It is the execution efficiency graph of protocol thread A.

[0036] Figure 7 This is a repair process diagram. DETAILED DESCRIPTION

[0037] The specific implementation of the present invention is further described in detail below in conjunction with the accompanying drawings and examples. The following examples are used to illustrate the present invention, but are not intended to limit the scope of the present invention.

[0038] like Figures 1 to 7 The method for monitoring and debugging a multi-threaded network device is distinctive in that it includes the following steps:

[0039] First, monitor the CPU usage of each network protocol thread / process in the system. The baseline rate (CU basel ), upper limit rate (CU upl ), lower limit rate (CU downl ), current usage (CU cul ).

[0040] During the implementation period, if the current utilization rate is higher than the upper limit rate (CU cul >CU upl ) or below the lower limit rate (CU cul <CU down l ), an alarm is issued. The upper limit rate (CU upl ) data to determine whether it exceeds the upper limit rate (CU upl ) or below the lower limit rate (CU downl ).

[0041] Next, we perform performance diagnosis, notify each protocol thread / process to perform performance detection and report the results, and analyze the results. This notification mechanism can be an interface call, signal or message queue. At the same time, we combine artificial intelligence algorithms to obtain a stable benchmark performance (PV base ), upper limit performance (PV up ), current execution performance (PV cur ).

[0042] After that, repair processing is performed. When the execution performance of a protocol thread / process is lower than the lower limit, the current resource usage status of the protocol thread / process is analyzed and repaired, and then an alarm is issued. The resources involved include the tables in use, event message queues and semaphores. If the protocol thread / process does not respond to the execution request, repair processing is performed immediately.

[0043] In conjunction with a preferred embodiment of the present invention, by Figure 1 The CPU usage distribution graph shown can be used to calculate the baseline rate (CU basel ) is obtained by setting Among them, CU basel represents the baseline rate, i represents the count of each sampling in the historical stable network, n represents the maximum number of sampling, the default is 10,000 times, and data is collected once a minute, the total time is 6.94 days, Cui represents the CPU usage of the current sampling.

[0044] At the same time, the upper limit rate (CU upl ) is obtained by setting CU upl =CU basel +2σ,CU upl , expressed as, upper limit rate = baseline rate plus 2 standard deviations.

[0045] Lower limit rate (CU downl ) is obtained by setting CU downl =CU basel -2σ,CU downl , expressed as, lower limit rate = baseline rate minus 2 standard deviations.

[0046] For the upper limit performance (PV up ) is expressed as, PV up =PV base +2σ, that is, the upper limit performance value = the benchmark performance value plus 2 standard deviations.

[0047] During the implementation period,

[0048] is the average value.

[0049] At the same time, based on historical stable network data, we took protocol process A as an example to test, collecting data once a minute, spending 6.94 days, collecting data 10,000 times, and through analysis, we found that all data were between 4% and 20%, as shown below Figure 2 The normal distribution curve shown in Figure 2 shows that the data distribution will fall within 2 standard deviations, and CU upl 21.2%, CU down l It is 2.9%.

[0050] Therefore, after obtaining the upper and lower limits of the baseline rate, the following is obtained based on the actual execution status of the protocol process in the system: Figure 3 In the protocol thread A-CPU usage graph shown, if the current usage is higher than the upper limit or lower than the lower limit, performance diagnosis is performed.

[0051] Further, the benchmark performance (PV base ) is expressed as, Where i represents the count of each sampling when the network is stable in history, and n represents the maximum number of sampling, which can be preset to 10,000 times. Data can be collected once a minute, and the total time is 6.94 days. PVi is the execution performance of the current sampling. For protocol thread A, its execution performance distribution state diagram can be shown as follows: Figure 4 shown.

[0052] In combination with actual implementation, we can use historical stable network data to send messages to the protocol thread / process through interface calls to perform performance diagnosis and process the execution performance response results. Taking protocol process A as an example, we collect data once a minute, spend 6.94 days, and collect 10,000 data. Through analysis, we find that all data are between 80 milliseconds and 400 milliseconds, as shown below: Figure 5 The normal distribution curve shown in the figure shows that the data distribution will fall within 2 standard deviations, and the upper limit performance value PV is obtained. up 426 milliseconds and the lower performance value PV down It is 56 milliseconds (and the lower limit performance value is only for reference and not as a basis for alarm judgment).

[0053] After obtaining the baseline performance value, the upper performance value and the lower performance value, the following is obtained based on the actual execution status of the protocol process in the system: Figure 6 As shown in the protocol thread A-execution performance diagram, if the current execution performance is higher than the upper limit performance value, an alarm is issued and a repair mechanism is started.

[0054] Looking further, the repair process adopted by the present invention is as follows Figure 7As shown, if the protocol thread exceeds the upper limit performance value, the current protocol thread resource data (table, event message queue, semaphore) is obtained, and the resource usage of the protocol process / thread is checked to see if there is any memory leak or memory resource occupation. After that, the memory and resources are released accordingly, and the protocol process / thread is finally restarted. Alternatively, if the protocol thread does not respond, check whether there is a deadlock. If a deadlock occurs, unlock it after analysis, restart or close the process / thread that caused the deadlock, and finally restart the protocol process / thread. It should be noted that the premise of restarting the protocol process / thread is the means of handling when conventional repair methods cannot handle it.

[0055] During the implementation period, if the data remains at the baseline rate (CU basel ) is the baseline rate (CU basel ) or less, it means that the network topology may have changed and it is necessary to collect data again 10,000 times. Therefore, calibration is performed to obtain the updated basic rate, upper rate, and lower rate. At the same time, for a stable network, calibration can be set once every six months. Of course, calibration can also be triggered by commands.

[0056] It can be seen from the above textual description and the accompanying drawings that the present invention has the following advantages:

[0057] 1. When network equipment has problems in network operation, the problem can be quickly located and the pain point solved.

[0058] 2. It is possible to diagnose the execution performance of each network protocol thread / process.

[0059] 3. It can issue an alarm for abnormalities and automatically start the repair mechanism after the alarm.

[0060] 4. The repair efficiency is high and can meet the use of conventional equipment that supports a variety of network communication protocols, and is suitable for conventional switches, wireless access points or routers.

[0061] In addition, the indicated orientations or positional relationships described in the present invention are all based on the orientations or positional relationships shown in the accompanying drawings and are only for the convenience of describing the present invention and simplifying the description. They do not indicate or imply that the device or structure referred to must have a specific orientation or be operated with a specific orientation structure. Therefore, they cannot be understood as limitations on the present invention.

[0062] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. It should be pointed out that a person skilled in the art can make several improvements and modifications without departing from the technical principles of the present invention, and these improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. A method for monitoring and debugging multi-threaded network devices, characterized in that The following steps are involved: Step 1: Monitor the CPU usage of each network protocol thread / process in the system and use artificial intelligence algorithms to derive the baseline rate CU basel , upper limit rate CU upl , lower limit rate CU downl , Current usage CU cul ; Step 2: If the current usage rate is higher than the upper limit or lower than the lower limit, an alarm is issued; Step 3: Perform performance diagnosis, notify each protocol thread / process to perform performance detection and report the results, analyze the results, and combine artificial intelligence algorithms to obtain a stable baseline performance PV base , upper limit performance PV up 、Current execution performance PV cur ; Step 4: Repair processing: when the execution efficiency of a certain protocol thread / process is lower than the lower limit, the current resource usage status of the protocol thread / process is analyzed and repaired, and then an alarm is issued; The baseline rate CU basel The way to obtain is, set up Among them, CU basel represents the baseline rate, i represents the count of each sampling when the network is stable historically, n represents the maximum number of samplings, the default is 10,000 times, and data is collected once a minute, and Cui represents the CPU usage of the current sampling; The upper limit line rate CU upl The method of obtaining is, let CU upl =CU basel +2σ, CU upl , expressed as, upper limit rate = baseline rate plus 2 standard deviations; The lower limit rate CU downl The method of obtaining is, let CU downl =CU basel -2σ, CU downl , expressed as, lower limit rate = baseline rate minus 2 standard deviations; The upper limit efficacy PV up Expressed as, PV up =PV base +2σ, upper limit performance value = benchmark performance value plus 2 standard deviations, is the average value, where σ represents the standard deviation, xi represents the data collected each time, and N represents the maximum number of sampling times, 10,000 times; In the step 2, the upper limit line rate CU is collected per minute. upl Data to determine whether it exceeds the upper limit line rate CU upl Or below the lower limit rate CU downl ; The benchmark performance PV base Expressed as, Where i represents the count of each sampling when the network is stable in history, n represents the maximum number of sampling times, 10,000 times, data is collected once a minute, and PVi is the execution performance of the current sampling; The repair process is as follows: if the protocol thread exceeds the upper limit performance value, the current protocol thread resource data is obtained, the resource usage of the protocol process / thread is checked to see if there is a memory leak and the memory resources are occupied, and the memory and resources are released accordingly, and finally the protocol process / thread is restarted; or, if the protocol thread does not respond, check whether there is a deadlock, if a deadlock occurs, unlock it after analysis, restart or close the process / thread that caused the deadlock, and finally restart the protocol process / thread; If the data remains at the baseline rate CU basel Above or baseline rate CU basel Next, calibration is performed to obtain the updated new basic rate, upper rate, and lower rate. For a stable network, calibration is performed once every six months; or, calibration is triggered by a command; In step 4, if the protocol thread / process does not respond to the execution request, a repair process is immediately performed.

Images