CN112948214B - Software overload warning method and device - Google Patents
Software overload warning method and device Download PDFInfo
- Publication number
- CN112948214B CN112948214B CN202110232008.0A CN202110232008A CN112948214B CN 112948214 B CN112948214 B CN 112948214B CN 202110232008 A CN202110232008 A CN 202110232008A CN 112948214 B CN112948214 B CN 112948214B
- Authority
- CN
- China
- Prior art keywords
- time
- software
- monitoring function
- ending
- sampling
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 165
- 238000012544 monitoring process Methods 0.000 claims abstract description 177
- 238000005070 sampling Methods 0.000 claims abstract description 177
- 238000004891 communication Methods 0.000 claims description 77
- 238000012545 processing Methods 0.000 claims description 41
- 230000002618 waking effect Effects 0.000 claims description 5
- 230000006870 function Effects 0.000 description 227
- 238000010586 diagram Methods 0.000 description 19
- 238000013515 script Methods 0.000 description 11
- 238000004590 computer program Methods 0.000 description 10
- 230000000694 effects Effects 0.000 description 8
- 238000007639 printing Methods 0.000 description 5
- 238000003860 storage Methods 0.000 description 5
- 230000001960 triggered effect Effects 0.000 description 5
- 238000012360 testing method Methods 0.000 description 4
- 238000001514 detection method Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 230000035945 sensitivity Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000004904 shortening Methods 0.000 description 1
- 230000004622 sleep time Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
- G06F11/324—Display of status information
- G06F11/327—Alarm or error message display
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application relates to the technical field of computers, in particular to a software overload warning method and device, which are used for calling a monitoring function at least once in a preset sampling time period, acquiring each starting time for starting to call the monitoring function in the sampling time period and each ending time for ending to call the monitoring function, determining the running time of software in the sampling time period according to each starting time and each ending time, determining the load value of the software in the sampling time period according to the running time, and determining whether to carry out overload warning on the software according to the load value.
Description
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a method and an apparatus for alarming overload of software.
Background
At present, for software installed on a high-performance server, a load value of the software in a working state needs to be acquired, so that operators can timely expand the software when the software is overloaded, and normal service of the high-performance server is ensured.
In the related art, the load value of the software can be detected by calling the acquisition script or the external component, and overload warning is performed according to the detected load value. For example, the acquisition script is called every 30 seconds, and the load value of the software at the current time is obtained through detection of the acquisition script. However, in the related art, the timing acquisition mode can only acquire the load value of the software when the acquisition script is called at the current moment, so that erroneous judgment can occur in the acquisition process, and the accuracy of the software overload alarm is reduced. In addition, since the related art needs to detect the load value of the software by calling the acquisition script or using the external component, frequent calling of the acquisition script or using the external component may occupy a large amount of system resources, and thus, system resource consumption in the process of overload alarm of the software may be increased.
Disclosure of Invention
The embodiment of the application provides a method and a device for alarming software overload, which are used for improving the accuracy of alarming the software overload and reducing the system resource consumption of alarming the software overload.
The specific technical scheme provided by the embodiment of the application is as follows:
a software overload warning method, comprising:
calling a monitoring function at least once in a preset sampling time period, and acquiring each starting time for starting to call the monitoring function and each ending time for ending to call the monitoring function in the sampling time period, wherein the ending time is the time acquired by ending to call the monitoring function when a communication event is monitored, and the monitoring function is used for continuously monitoring whether the communication event occurs in the process of software;
Determining the running time of the software in the sampling time period according to the starting time and the ending time;
and determining a load value of the software in the sampling time period according to the running time, and determining whether to carry out overload warning on the software according to the load value.
Optionally, at least one monitoring function is called in a preset sampling period, and each starting time for starting to call the monitoring function and each ending time for ending to call the monitoring function in the sampling period are obtained, which specifically includes:
the following operation steps are executed at least once in a preset sampling time period, and each starting time for starting to call a monitoring function and each ending time for ending to call the monitoring function in the sampling time period are obtained: and calling a monitoring function in a process of software, acquiring the starting time for starting to call the monitoring function, ending calling the monitoring function if the communication event is monitored in the process, acquiring the ending time for ending calling the monitoring function, and processing the monitored communication event.
Optionally, after processing the monitored communication event, further comprising:
Judging whether the time difference between the ending time and the starting time of calling the monitoring function for the first time is larger than a preset sampling time period or not;
if the time difference value is determined to be larger than the sampling time period, terminating calling the monitoring function to obtain each starting time and each ending time;
and if the time difference value is not larger than the sampling time period, re-executing the step of calling the monitoring function in the process of the software.
Optionally, processing the monitored communication event specifically includes:
waking up the process based on the monitored communication event;
the communication event is processed in the process.
Optionally, determining the running time of the software in the sampling time period according to the starting time and the ending time specifically includes:
calculating a first time difference value between any one end time and the starting time of starting to call the monitoring function next time according to each end time;
and adding the calculated first time differences to obtain the running time of the software in the sampling time period.
Optionally, determining the running time of the software in the sampling time period according to the starting time and the ending time specifically includes:
Calculating a second time difference value between any one starting time and the corresponding ending time according to the starting time respectively;
adding the calculated second time difference values to obtain the idle time of the software in the sampling time period;
and obtaining the running time of the software in the sampling time period by calculating the time difference between the sampling time period and the idle time.
Optionally, determining the load value of the software in the sampling time period according to the running time specifically includes:
calculating a ratio between the run time and the sampling period;
and taking the calculated ratio as a load value of the software in the sampling time period.
Optionally, determining whether to carry out overload warning on the software according to the load value specifically includes:
judging whether the load value is larger than a preset load threshold value, if the load value is larger than or equal to the load threshold value, adding 1 to an overload count stored in a preset overload counter, and if the load value is smaller than the load threshold value, resetting the overload count;
determining a corresponding alarm mode according to the overload count in the overload counter;
And carrying out load alarm on the software based on the determined alarm mode.
A software overload warning apparatus, comprising:
the processing module is used for calling a monitoring function at least once in a preset sampling time period, and acquiring each starting time for starting to call the monitoring function in the sampling time period and each ending time for ending to call the monitoring function, wherein the ending time is the time acquired by ending to call the monitoring function when a communication event is monitored, and the monitoring function is used for continuously monitoring whether the communication event occurs in the process of software;
the determining module is used for determining the running time of the software in the sampling time period according to the starting time and the ending time;
and the alarm module is used for determining the load value of the software in the sampling time period according to the running time and determining whether to carry out overload alarm on the software according to the load value.
Optionally, the processing module is specifically configured to:
the following operation steps are executed at least once in a preset sampling time period, and each starting time for starting to call a monitoring function and each ending time for ending to call the monitoring function in the sampling time period are obtained: and calling a monitoring function in a process of software, acquiring the starting time for starting to call the monitoring function, ending calling the monitoring function if the communication event is monitored in the process, acquiring the ending time for ending calling the monitoring function, and processing the monitored communication event.
Optionally, after processing the monitored communication event, the processing module is further configured to:
judging whether the time difference between the ending time and the starting time of calling the monitoring function for the first time is larger than a preset sampling time period or not;
if the time difference value is determined to be larger than the sampling time period, terminating calling the monitoring function to obtain each starting time and each ending time;
and if the time difference value is not larger than the sampling time period, re-executing the step of calling the monitoring function in the process of the software.
Optionally, when processing the monitored communication event, the processing module is specifically configured to:
waking up the process based on the monitored communication event;
the communication event is processed in the process.
Optionally, the determining module is specifically configured to:
calculating a first time difference value between any one end time and the starting time of starting to call the monitoring function next time according to each end time;
and adding the calculated first time differences to obtain the running time of the software in the sampling time period.
Optionally, the determining module is specifically configured to:
calculating a second time difference value between any one starting time and the corresponding ending time according to the starting time respectively;
Adding the calculated second time difference values to obtain the idle time of the software in the sampling time period;
and obtaining the running time of the software in the sampling time period by calculating the time difference between the sampling time period and the idle time.
Optionally, when determining the load value of the software in the sampling time period according to the running time, the alarm module is specifically configured to:
calculating a ratio between the run time and the sampling period;
and taking the calculated ratio as a load value of the software in the sampling time period.
Optionally, when determining whether to carry out overload alarm on the software according to the load value, the alarm module is specifically configured to:
judging whether the load value is larger than a preset load threshold value, if the load value is larger than or equal to the load threshold value, adding 1 to an overload count stored in a preset overload counter, and if the load value is smaller than the load threshold value, resetting the overload count;
determining a corresponding alarm mode according to the overload count in the overload counter;
and carrying out load alarm on the software based on the determined alarm mode.
An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the software overload warning method described above when the program is executed by the processor.
A computer readable storage medium having stored thereon a computer program which when executed by a processor implements the steps of the software overload warning method described above.
In the embodiment of the application, at least one monitoring function is called in a preset sampling time period, each starting time for starting to call the monitoring function in the sampling time period and each ending time for ending to call the monitoring function are obtained, the running time of the software in the sampling time period is determined according to each starting time and each ending time, the load value of the software in the sampling time period is determined according to the running time, and whether overload warning is carried out on the software is determined according to the load value. Therefore, the method does not need to rely on an external component or call an acquisition script, and only needs to determine each starting time and each ending time by calling the monitoring function for a plurality of times in a preset sampling time period, and obtains the load value of the software in the sampling time period according to each starting time and each ending time, so that the consumption of system resources can be reduced. In addition, the method can obtain the load value of the software in the sampling time period, and compared with the prior art that only the load value of the software at a certain moment is acquired, the method can avoid misjudgment or omission, thereby improving the accuracy of the software overload alarm.
Drawings
FIG. 1 is a flowchart of a software overload warning method in an embodiment of the present application;
FIG. 2 is a schematic diagram of sampling data according to an embodiment of the present application;
fig. 3 is an effect schematic diagram of scene 1 in the embodiment of the present application;
fig. 4 is an effect schematic diagram of scene 2 in the embodiment of the present application;
fig. 5 is an effect schematic diagram of scene 3 in the embodiment of the present application;
fig. 6 is an effect schematic diagram of scene 4 in the embodiment of the present application;
FIG. 7 is another flowchart of a software overload warning method according to an embodiment of the present application;
FIG. 8 is a schematic structural diagram of a software overload warning device according to an embodiment of the present application;
fig. 9 is a schematic structural diagram of an electronic device in an embodiment of the present application.
Detailed Description
The following description of the technical solutions in the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.
Aiming at software for providing real-time service for users online, particularly the software installed on a high-performance server, the load condition of the software in a working state needs to be acquired, so that operators can timely expand the capacity of the software when the software is overloaded, and the high-performance server can always maintain normal service.
In general, the service indexes of the whole machine include: the occupation rate of the CPU, the read-write frequency of IO and the like, and the service index of the whole machine can reflect the load value of software. In the related art, the load value of the software can be detected by collecting scripts or external components, so that the aim of early warning is fulfilled. For example, the load value of the software may be determined by a timed task or other component of the Linux system that invokes the collect script every 30 seconds. However, since this mode in the related art is implemented by setting the timing task, only the load value of the software at the moment when the timing task is started, that is, only the load value at a certain moment can be obtained by this implementation in the related art, and thus, erroneous judgment may occur during the acquisition process, thereby reducing the accuracy of the software overload alarm. For example, a CPU spike generated at the moment of acquisition may be misinterpreted as an excessive load, and for example, just recovered to a normal state near the acquisition point and ignored. Also, since the related art needs to detect a load value of software by calling an acquisition script or using an external component, system resource consumption may be increased.
In order to solve the above problems, in this embodiment of the present application, a software overload alarm method is provided, at least one time of a listening function is called in a preset sampling period, and each start time and each end time of calling the listening function in the sampling period are acquired, an operation time of software in the sampling period is determined according to each start time and each end time, a load value of the software in the sampling period is determined according to the operation time, whether the software is overloaded and alerted is determined according to the load value, the operation time of the software in the sampling period is determined according to each start time and each end time, the load value of the software in the sampling period is determined according to the operation time, and whether the software is overloaded and alerted is determined according to the load value. And the load value of the software in the sampling time period is calculated according to the starting time of starting to call the monitoring function and the ending time of ending to call the monitoring function in the sampling time period, so that the misjudgment condition in the acquisition process can be avoided, and the instantaneity and the accuracy of the software overload alarm are improved.
Based on the foregoing embodiments, referring to fig. 1, a flowchart of a software overload alarm method in an embodiment of the present application specifically includes:
step 100: and calling the monitoring function at least once in a preset sampling time period, and acquiring each starting time for starting to call the monitoring function and each ending time for ending to call the monitoring function in the sampling time period.
The ending time is the time acquired by ending calling the monitoring function when the communication event is monitored, and the monitoring function is used for continuously monitoring whether the communication event occurs in the process of the software.
In this embodiment, when executing step 100, the method specifically includes:
the following operation steps are executed at least once in a preset sampling time period, and each starting time for starting to call the monitoring function and each ending time for ending to call the monitoring function in the sampling time period are obtained: and calling the monitoring function in the process of the software, acquiring the starting time for starting to call the monitoring function, ending calling the monitoring function if the communication event is monitored in the process, acquiring the ending time for ending calling the monitoring function, and processing the monitored communication event.
Wherein, the monitoring function is used for continuously monitoring whether a communication event occurs in the process.
In the embodiment of the application, a plurality of different types of software are installed in the high-performance server, and each software comprises a process. In order to determine the load value of the software in the sampling time period, the following operation steps can be executed at least once in the preset sampling time period, each starting time for starting to call the monitoring function in the sampling time period and each ending time for ending to call the monitoring function are obtained, and then the load value of the software in the sampling time period can be determined according to the obtained starting times and ending times:
a1: and calling the monitoring function in the process of the software, and acquiring the starting time for starting to call the monitoring function.
In the embodiment of the application, the software needing overload warning is determined, an event driving framework is built in the determined process of the software, and after the event driving framework is built, a monitoring function is called in the determined process of the software, that is, the monitoring function is called from a function database into the process of the software, and the starting time for starting to call the monitoring function is acquired.
The starting time characterizes the instant time when the process of the software starts to call the monitoring function, for example, assuming that the time when the process of the software starts to call the monitoring function is 16:00:26 and the time when the process ends to call the monitoring function is 16:00:53, the acquired starting time when the process starts to call the monitoring function is 16:00:26.
The event driven framework in the embodiment of the present application may be implemented in different manners, for example, may be a multiplexing mechanism such as select, poll, epoll, which is not limited in the embodiment of the present application.
It should be noted that, if it is determined that the process of the software has called the listening function, the process of the software is blocked, and at this time, the process is in a dormant state, and the process in the dormant state continuously waits for whether a communication event occurs.
Taking the event driven framework as an epoll as an example, when the event driven framework is the epoll, the monitoring function is the epoll_wait function, and when the epoll_wait function is called, the starting time t0 for starting to call the epoll_wait function is obtained. If the communication event is not monitored in the process at this time, the process of the software is blocked, the process of the software is converted from the working state to the dormant state, and the process does not work when in the dormant state.
A2: if the communication event is monitored in the process, the call of the monitoring function is ended, and the ending time for ending the call of the monitoring function is obtained.
In the embodiment of the application, after a process of software calls a monitor function, the process is in a dormant state at this time, but the process runs the called monitor function and continuously monitors whether a communication event of a preset type occurs in the process of software based on the monitor function, if it is determined that the communication event of the preset type does not occur in the process of software, the process of software continues to monitor whether the communication event of the preset type occurs, at this time, the process of software is still in the dormant state, if it is determined that the communication event of the preset type occurs in the process of software, the process in the dormant state is awakened, the call of the monitor function is ended, the monitor function is returned to a function database, and the end time for ending the call of the monitor function is acquired.
The process of the software represented by the ending time finishes the moment of calling the monitoring function, for example, assuming that the time when the process of the software starts to call the monitoring function is 16:00:26 and the time when the process of the software finishes calling the monitoring function is 16:00:53, the process of the software continuously calls the monitoring function in the 16:00:26-16:00:53. Then the end time of the finally obtained end call listening function is 16:00:53.
Taking an event driven framework as an epoll as an example, the steps of acquiring the ending time in the embodiment of the present application will be described in detail. When the event-driven framework is epoll, the monitoring function is an epoll_wait function, if it is determined that a preset communication event is monitored in a process of software, the process is awakened, the epoll_wait function is triggered to return, at the moment, the epoll_wait function is finished to be called, and the time t1 when the epoll_wait function is finished to be called is acquired. And, because the preset communication event occurs in the process at this time, the process of the software is awakened, and the process of the software can be converted from the dormant state to the working state, and the process works in the working state.
A3: processing the monitored communication event.
In the embodiment of the application, after the communication event is monitored, the monitored communication event is processed.
It should be noted that, the steps A1 to A3 may be regarded as one cycle, and the steps A1 to A3 are executed at least once within a preset sampling period until the preset sampling period expires, and then the execution of the steps is stopped. Thus, at least one cycle is included in the predetermined sampling period, i.e. the listening function is called at least once in the sampling period.
Moreover, it should be noted that, the embodiments of the present application are directed to only software of a single process, and, since the main thread is configured to process communication events in a loop, the embodiments of the present application are directed to only collecting the main thread in the single process.
Further, in each cycle of calling the listening function, after the monitored communication event is processed, whether the preset sampling period is up or not is determined according to the end time obtained from the current cycle, so as to determine whether the calling of the listening function is required to be terminated, which specifically includes:
a1: and judging whether the time difference between the ending time and the starting time of the first call of the monitoring function is larger than a preset sampling time period or not.
A2: if the time difference value is larger than the sampling time period, the calling of the monitoring function is terminated, and each starting time and each ending time are obtained.
A3: if the time difference is not greater than the sampling time period, returning to the step of calling the monitoring function in the process of the software.
In this embodiment of the present application, after the process of software completes the monitored communication event, the starting time of calling the listening function for the first time is obtained, and whether the time difference between the ending time and the starting time of calling the listening function for the first time is greater than a preset sampling time period is determined, which may be specifically divided into the following two cases:
first case: the time difference between the end time and the start time of the first call of the listening function is greater than a preset sampling period.
The method specifically comprises the following steps: if the time difference between the ending time and the starting time of the first call of the monitoring function is larger than the preset sampling time period, the call of the monitoring function is terminated, and all the starting time and all the termination time are obtained.
In the embodiment of the application, the starting time of calling the monitoring function for the first time is taken as the starting time of calling the monitoring function for the first time. If it is determined that the time difference between the acquired ending time in a certain cycle and the starting time of calling the monitoring function for the first time is larger than a preset sampling time period when the cycle is ended, the calling of the monitoring function is stopped, and all the starting time and all the ending time acquired in the sampling time period are obtained.
For example, assuming that the preset sampling period is 10s, the starting time of the first call monitoring function is 16:00:06, and if the acquired ending time is 16:00:17 in the third cycle, the starting time of the first call monitoring function, the ending time of the first return monitoring function, the starting time of the second call monitoring function, the ending time of the second return monitoring function, the starting time of the third call monitoring function and the ending time of the third return monitoring function are taken as the starting times and the ending times acquired in the sampling period 10 s.
Second case: the time difference between the end time and the start time of the first call of the listening function is not greater than a preset sampling period.
The method specifically comprises the following steps: and if the time difference between the ending time and the starting time of the first calling of the monitoring function is not larger than the sampling time period, returning to the step of calling the monitoring function in the process of the software.
In the embodiment of the application, if it is determined that the time difference between the end time and the start time of the first call of the monitoring function is not greater than the sampling time period, it is determined that the start time and the end time of the call of the monitoring function still need to be collected continuously in the sampling time period, so that the step of calling the monitoring function in the process of the software is returned, and the monitoring function is called again.
For example, assuming that the preset sampling period is 10s, the starting time of the first call of the listening function is 16:00:06, if the acquired ending time is 16:00:13 in the third cycle, it is determined that the starting time and the ending time of the call of the listening function need to be continuously acquired before the acquisition is completed, and the step of calling the listening function in the process of the software is returned.
Further, in this embodiment of the present application, a timer may be further set, in a timing period set by the timer, a call of a listening function in a process of software is continuously executed, and a start time for starting to call the listening function is obtained, if it is determined that a communication event is monitored in the process, the call of the listening function is ended, and an end time for ending to call the listening function is obtained, and a cycle step for processing the monitored communication event is obtained, until the timer expires, the collection is ended, and each start time and end time in the timing period of the timer are obtained.
For example, assuming that the timing period set in the timer is 10s, the above-described loop step is continuously performed for 10s until 10s expires, and the loop step is stopped. And obtains the start times and end times for calling the listening function within the 10 s.
Further, after the process of the software finishes calling the listening function, the process in the sleep state may be awakened, and the monitored communication event is processed in the process, and the steps for processing the communication event in the embodiment of the present application are described in detail below, which specifically includes:
a1: based on the monitored communication event, the process is awakened.
In the embodiment of the present application, if it is determined that a communication event is monitored in a process of software, the process in the software in the sleep state at this time is awakened based on the monitored communication event.
The communication event may be one event or multiple events, which is not limited in this embodiment of the present application.
The communication event may be a preset different type of communication event, for example, a read-write event, which is not limited in the embodiment of the present application.
It should be noted that, if a plurality of communication events are monitored in the process of the software, when the first communication event is monitored, the process is awakened, and the call of the monitoring function is ended.
A2: the communication event is handled in the process.
In the embodiment of the application, the monitored communication event is processed in the process, if the monitored communication event is determined to be processed, the working state of the process in the software is determined to be ended, the monitoring function is called into the process again, and the working state of the process at the moment is converted into the dormant state.
Step 110: and determining the running time of the software in the sampling time period according to each starting time and each ending time.
In this embodiment of the present application, when determining the running time of the software in the sampling period, the following two ways may be implemented, and in this embodiment of the present application, two ways of determining the running time of the software in the sampling period are described in detail below.
The first processing mode specifically comprises:
s1: for each end time, a first time difference between any one end time and the start time of the next start of calling the listening function is calculated.
In this embodiment of the present invention, since the starting time of starting to call the listening function is the time when the software stops working, and the ending time of ending to call the listening function is the time when the software starts working, each ending time and the starting time of starting to call the listening function next corresponding to each ending time may be divided into a group, each time combination in the sampling period is obtained, and each time combination is respectively calculated, and a first time difference value between the ending time of ending to call the listening function and the starting time of starting to call the listening function, that is, the first time difference value is a difference value between the ending time when the listening function is currently ended and the starting time of starting to call the listening function next again is calculated. In this first time difference, the process is in an active state and the process is always processing the monitored communication event, and therefore, the software can be considered to be in an active state during this period.
For example, referring to fig. 2, in the embodiment of the present application, it is assumed that in fig. 2, the starting time of the first-time start call monitor function is t0, the ending time of the first-time end call monitor function is t1, the starting time of the second-time start call monitor function is t2, the ending time of the second-time end call monitor function is t3, the starting time of the third-time start call monitor function is t4, the ending time of the third-time end call monitor function is t5, the starting time of the fourth-time start call monitor function is t6, the ending time of the fourth-time end call monitor function is t7, the starting time of the fifth-time start call monitor function is t8, the starting time t2 of the second-time start call monitor function and the ending time t1 of the first-time end call monitor function are grouped, the starting time t4 of the third-time start call monitor function and the ending time t3 of the second-time end call monitor function are grouped, the starting time t6 of the fourth-time start call monitor function and the ending time of the third-time end call monitor function are grouped, and the fourth-time end call monitor function is grouped together with the starting time t8 of the fourth-time start call monitor function is grouped. Then, calculating the time difference between the starting time t2 of the second call monitoring function and the ending time t1 of the first return monitoring function as t2-t1, calculating the time difference t4-t3 between the starting time t4 of the third call monitoring function and the ending time t3 of the second return monitoring function, calculating the time difference t6-t5 between the starting time t6 of the fourth call monitoring function and the ending time t5 of the third return monitoring function, and calculating the time difference t8-t7 between the starting time t8 of the fifth call monitoring function and the ending time t7 of the fourth return monitoring function.
It should be noted that, taking the snoop function as the epoll_wait function as an example, the period from when the epoll_wait function starts to be called to when the epoll_wait function returns may be considered as an idle period, and the period from when the epoll_wait function returns to when the epoll_wait function is called next time may be considered as an operating period.
Wherein, the operating time at least includes one of the following: CPU processing time, sleep time, input port read-write time, output port read-write event, mutual exclusion lock contention waiting time, which is not limited in the embodiment of the present application.
S2: and adding the calculated first time differences to obtain the running time of the software in the sampling time period.
In this embodiment of the present application, since each first time difference value represents the working time of the software, after the working time corresponding to each time combination is obtained, the working times of the software are added, that is, the calculated first time difference values are added, so that the running time of the software in the sampling time period can be obtained.
For example, as shown in fig. 2, the calculated first time differences are t2-t1, t4-t3, t6-t5 and t8-t7, respectively, and the running time of the software in the sampling time is t= (t 2-t 1) + (t 4-t 3) + (t 6-t 5) + (t 8-t 7).
The second processing mode specifically comprises:
s1: and calculating a second time difference value between any one starting time and the corresponding ending time according to each starting time.
In this embodiment of the present invention, since the start time of starting to call the listening function is the time when the software stops working, and the end time of ending to call the listening function is the time when the software starts working, the start time of starting to call the listening function and the corresponding end time of ending to call the listening function collected in each cycle may be divided into a group, each time combination in the sampling period is obtained, and a second time difference between the start time of starting to call the listening function and the end time of ending to call the listening function, that is, the second time difference is the difference between the start time of currently starting to call the listening function and the end time of currently ending to call the listening function, which is included in any time combination. In this second time difference value, the process is in an idle state.
For example, as shown in fig. 2, the sampling period is t8-t0, assuming that the initial start call monitoring function is t0, the initial end call monitoring function is t1, the second start call monitoring function is t2, the second end call monitoring function is t3, the third start call monitoring function is t4, the third end call monitoring function is t5, the fourth start call monitoring function is t6, the fourth end call monitoring function is t7, the fifth start call monitoring function is t8, the initial start time t1 of the initial end call monitoring function and the initial start call monitoring function are grouped together, the end time t3 of the second end call monitoring function and the initial start time t2 of the second start call monitoring function are grouped together, the end time t5 of the third end call monitoring function and the initial start time t4 of the third start call monitoring function are grouped together, and the end time t7 of the fourth start call monitoring function and the start time t6 of the fourth start call monitoring function are grouped together, and the end time t6 of the fourth start call monitoring function is grouped together. Then, the time difference between the starting time t1 of the first-time call completion monitoring function and the starting time t0 of the first-time call completion monitoring function is calculated as t1-t0, the time difference t3-t2 between the ending time t3 of the second-time call completion monitoring function and the starting time t2 of the second-time call completion monitoring function is calculated, the time difference t5-t4 between the ending time t5 of the third-time call completion monitoring function and the starting time t4 of the third-time call completion monitoring function is calculated, and the time difference t7-t6 between the ending time t7 of the fourth-time call completion monitoring function and the starting time t6 of the fourth-time call completion monitoring function is calculated.
S2: and adding the calculated second time difference values to obtain the idle time of the software in the sampling time period.
In this embodiment of the present invention, since each second time difference value represents the idle time of the software, after the idle time corresponding to each time combination is obtained, the idle time of the software in the sampling period can be obtained by adding the idle times of the software, that is, adding the calculated second time difference values.
For example, as shown in fig. 2, the calculated second time differences are t1-t0, t3-t2, t5-t4 and t7-t6, respectively, and the idle time of the software in the sampling period is t= (t 1-t 0) + (t 3-t 2) + (t 5-t 4) + (t 7-t 6).
S3: and obtaining the running time of the software in the sampling time period by calculating the time difference between the sampling time period and the idle time.
For example, as shown in fig. 2, when the sampling period is t0 to t8, the running time of the software in the sampling period is the sampling period minus the idle time, which is t= (t 8-t 0) - ((t 1-t 0) + (t 3-t 2) + (t 5-t 4) + (t 7-t 6)).
In this embodiment of the present application, since in the sampling period, the software is only in two states, one is in a sleep state and the other is in a working state, if it is required to obtain the running time of the software in the sampling period, the time difference between the sampling period and the idle time is calculated, and the calculated time difference is the working time of the software in the sampling period.
Step 120: and determining a load value of the software in the sampling time period according to the running time, and determining whether to carry out overload warning on the software according to the load value.
In this embodiment of the present application, when determining a load value of software in a sampling period according to running time, the method specifically includes:
s1: the ratio between the run time and the sampling period is calculated.
In this embodiment of the present application, the process may be in only two states in the sampling period, where one state is a working state and the other state is an operating state. Then, the duty ratio of the working state of the computing process in the sampling period can be obtained, so that the load value of the software in the sampling period can be obtained. Thus, the ratio between the run time and the sampling period is calculated.
S2: the calculated ratio is taken as the load value of the software in the sampling time period.
In the embodiment of the application, the duty ratio of the time when the process is in the working state in the sampling time period can be used as the load value of the software in the sampling time period.
For example, assuming that the sampling period is t and the running time is t1, the load value may be expressed as:
t0＝t1*100％/t
it should be noted that, the load value in the embodiment of the present application characterizes the duty ratio of the time when the process is in the working state in the sampling period.
Of course, the load value may also be a numerical value, and the ratio between the running time and the sampling period is calculated, and the calculated ratio is multiplied by 100, so as to obtain the load value, for example, assuming that the sampling period is t and the running time is t1, the load value may be expressed as:
t0＝t1*100/t
further, in the embodiment of the present application, when the load value of the software in the sampling period is obtained, the duty ratio of the time when the process is in the idle state in the sampling period may also be calculated, and the duty ratio of the time when the process is in the idle state in the sampling period may be subtracted by 1, so as to obtain the duty ratio of the time when the process is in the working state in the sampling period.
For example, assuming that the idle duty ratio is idle_ratio, the sampling period is totallime, and the time of each in the idle state is deltaWait, the idle duty ratio may be expressed as:
idle_ratio＝deltaWait/Totaltime*100
＝(t1-t0+t3-t2+t5-t4+t7-t6)/(t8-t0)*100
thus, the duty cycle of the software can be calculated as:
work_ratio＝100-idle_ratio
in addition, it should be noted that, in the method in the embodiment of the present application, only the main thread in a single process, that is, the main thread processes the event cycle for collection, so the load usage of log printing does not exceed 100. The% CPU obtained by the top command would exceed 100 because the top statistics is the CPU usage of all threads, and therefore this approach focuses on the load of the main thread when processing events, regardless of the other threads.
The top command is used for displaying the resource occupation condition of each process in the Linux system. In the embodiment of the application, whether the load value determined based on the starting time and the ending time of calling the monitoring function is correct or not can be determined through the resource occupation condition displayed by the top command. For example, a related tester inputs a top command into a Linux system, so that a CPU occupancy percentage% of a process contained in the Linux system in a sampling period can be displayed through the top command, then, in a test process, a load value user of the CPU in the sampling period can be obtained through the method of the embodiment of the application, and the CPU occupancy percentage% and the user are compared. Thus, whether the load value of the software calculated by the method in the embodiment of the application is reliable or not can be determined.
After obtaining the load value of the software in the sampling period, determining whether the overload warning needs to be performed on the software according to the load value, and describing in detail the step of determining whether the overload warning needs to be performed on the software according to the load value in the embodiment of the present application specifically includes:
s1: judging whether the load value is larger than a preset load threshold, if the load value is larger than or equal to the load threshold, adding 1 to the overload count stored in the preset overload counter, and if the load value is smaller than the load threshold, resetting the overload count.
In this embodiment of the present application, whether the load value is greater than a preset load threshold is determined, which may be specifically classified into the following two cases.
First case: the load value is greater than or equal to the load threshold.
The method specifically comprises the following steps: and reading the overload count stored in the overload counter, judging whether the calculated load value is larger than a preset load threshold, and if the load value is larger than or equal to the load threshold, adding 1 to the overload count stored in the preset overload counter.
Second case: the load value is less than the load threshold.
The method specifically comprises the following steps: and reading the overload count stored in the overload counter, judging whether the calculated load value is larger than a preset load threshold, and resetting the overload count if the calculated load value is smaller than the load threshold.
S2: and determining a corresponding alarm mode according to the overload count in the overload counter.
In this embodiment, if it is determined that the overload count in the overload counter is greater than the preset count threshold, it is determined that an overload alarm is triggered, if it is determined that the overload count in the overload counter is equal to the preset count threshold, it is determined that an overload alarm is to be triggered, and if it is determined that the overload count in the overload counter is less than the preset count threshold, it is not triggered.
S3: and carrying out load alarm on the software based on the determined alarm mode.
Taking 4 scenarios as an example, the process of determining the software load value in the embodiment of the present application is tested:
scene 1: referring to fig. 3, an effect schematic diagram of scenario 1 in the embodiment of the present application is shown, in scenario 1, the software includes 2 working processes, and the concurrence number is 2, and then the load ratio of the CPU displayed by the top command is 36.0% and 31.6% respectively, and the load usages of log printing are 31, 30, 33, 29, 31 and 31 respectively.
Scene 2: referring to fig. 4, an effect schematic diagram of scenario 2 in the implementation of the present application is shown, in scenario 2, the software includes 2 working processes, and the concurrency number is 8, and then the load ratios of the CPU displayed by the top command are 79.9% and 72.6% respectively, and the load usages of log printing are 76, 84, 78, 84, and 77 respectively.
Scene 3: referring to fig. 5, an effect schematic diagram of scenario 3 in the embodiment of the present application is shown, in scenario 3, the software includes 2 working processes, and the concurrency number is 16, and then the load ratio of the CPU displayed by the top command is 101.2% and 88.6% respectively, and the load usages of log printing are 88, 95, 91, 94, 87 and 87 respectively.
Scene 4: referring to fig. 6, an effect schematic diagram of a scenario 4 in the embodiment of the present application is shown, in the scenario 4, the software includes 2 working processes, and the concurrence number is 30, and then the load ratio of the CPU displayed by the top command is 108.9% and 92.2% respectively, and the load usages of log printing are 99, 97, 98, 93 and 93 respectively.
It should be noted that, the test data of the above 4 scenarios are obtained by testing based on the nginx event driven framework, and based on the above 4 sets of test data, it is known that the load usage calculated by the method in the embodiment of the present application and the% CPU value displayed by the top command are generally close, and the load value calculated by the method in the embodiment of the present application can be considered to be reliable.
In the related art, when detecting the load of the software, a great deal of system resources are occupied by the need of frequently executing the acquisition task outside, but in the embodiment of the application, the load value of the software is detected by acquiring the starting time and the ending time of calling the monitoring function, and the method does not depend on external components or scripts, and almost does not consume the system resources. In addition, in the related art, the sensitivity can only be improved by shortening the acquisition time during external detection, because the sensitivity is lower due to the excessively long detection interval. In addition, erroneous judgment or omission may occur by external means, for example, cpu spurs generated at the moment of acquisition may be misjudged as too high load, and may be ignored in the vicinity of the acquisition point because the state just returns to normal. By the method in the embodiment of the application, when the load is calculated, the load is calculated according to the data in the last statistical period, so that the real-time performance of load judgment is remarkably improved, and meanwhile, the accuracy is also improved.
Based on the foregoing embodiments, referring to fig. 7, another flowchart of a software overload alarm method in the embodiment of the present application specifically includes:
step 700: starting.
Step 701: the time at which the sampling period starts, the idle time of the software, the overload count in the overload counter, is initialized.
Step 702: recording the ending time of ending calling the monitoring function.
Step 703: judging whether the time difference between the ending time and the starting time of the first starting call of the monitoring function is greater than or equal to a preset sampling time period, if so, executing step 704, and if not, executing step 710.
Step 704: it is determined whether the ratio obtained by (100-100 x idle time)/sampling period is greater than the overload threshold, if so, step 705 is executed, and if not, step 706 is executed.
Step 705: the overload count in the overload counter is incremented by 1.
Step 706: the overload count in the overload counter is cleared to 0.
Step 707: whether the overload count in the overload counter is greater than or equal to the preset count threshold is determined, if yes, step 708 is executed, and if not, step 713 is executed.
Step 708: an alarm is triggered.
Step 709: clear the idle time by 0 and record the current time as the start time of the new sampling period.
Step 710: a snoop function is started to be invoked.
Step 711: the idle time is accumulated.
Step 712: the monitored communication event is processed and step 702 is re-executed.
Step 713: and (5) ending.
In the embodiment of the application, aiming at a main thread in a single process, the starting time and the ending time of calling the epoll_wait function are collected, the duty ratio of idle waiting time in a statistical period is calculated by utilizing the starting time and the ending time, and then the duty ratio of working time, namely the actual load condition of the process is obtained, so that the calculated load value can truly reflect the load condition of the process of software installed in a high-performance server, system resources are hardly consumed in the collection process, and meanwhile, the accuracy and the instantaneity of load judgment are greatly improved. The method can provide reliable judgment basis for load balancing or upper layer scheduling, thereby improving the instantaneity and accuracy of software overload warning.
Based on the same inventive concept, a software overload alarm apparatus is provided in the embodiments of the present application, and the software overload alarm apparatus may be a hardware structure, a software module, or a hardware structure plus a software module. Based on the above embodiments, referring to fig. 8, a schematic structural diagram of a software overload alarm apparatus in an embodiment of the present application is shown, which specifically includes:
The processing module 800 is configured to call a listening function at least once in a preset sampling period, and obtain each start time for starting to call the listening function in the sampling period and each end time for ending to call the listening function, where the end time is a time acquired by ending to call the listening function when a communication event is detected, and the listening function is configured to continuously monitor whether a communication event occurs in a process of software;
a determining module 810, configured to determine a running time of the software in the sampling period according to the start times and the end times;
and the alarm module 820 is used for determining the load value of the software in the sampling time period according to the running time and determining whether to carry out overload alarm on the software according to the load value.
Optionally, the processing module 800 is specifically configured to:
the following operation steps are executed at least once in a preset sampling time period, and each starting time for starting to call a monitoring function and each ending time for ending to call the monitoring function in the sampling time period are obtained: and calling a monitoring function in a process of software, acquiring the starting time for starting to call the monitoring function, ending calling the monitoring function if the communication event is monitored in the process, acquiring the ending time for ending calling the monitoring function, and processing the monitored communication event.
Optionally, after processing the monitored communication event, the processing module 800 is further configured to:
judging whether the time difference between the ending time and the starting time of calling the monitoring function for the first time is larger than a preset sampling time period or not;
if the time difference value is determined to be larger than the sampling time period, terminating calling the monitoring function to obtain each starting time and each ending time;
and if the time difference value is not larger than the sampling time period, re-executing the step of calling the monitoring function in the process of the software.
Optionally, when processing the monitored communication event, the processing module 800 is specifically configured to:
waking up the process based on the monitored communication event;
the communication event is processed in the process.
Optionally, the determining module 810 is specifically configured to:
calculating a first time difference value between any one end time and the starting time of starting to call the monitoring function next time according to each end time;
and adding the calculated first time differences to obtain the running time of the software in the sampling time period.
Optionally, the determining module 810 is specifically configured to:
calculating a second time difference value between any one starting time and the corresponding ending time according to the starting time respectively;
Adding the calculated second time difference values to obtain the idle time of the software in the sampling time period;
and obtaining the running time of the software in the sampling time period by calculating the time difference between the sampling time period and the idle time.
Optionally, when determining the load value of the software in the sampling period according to the running time, the alarm module 820 is specifically configured to:
calculating a ratio between the run time and the sampling period;
and taking the calculated ratio as a load value of the software in the sampling time period.
Optionally, when determining whether to overload alarm the software according to the load value, the alarm module 820 is specifically configured to:
judging whether the load value is larger than a preset load threshold value, if the load value is larger than or equal to the load threshold value, adding 1 to an overload count stored in a preset overload counter, and if the load value is smaller than the load threshold value, resetting the overload count;
determining a corresponding alarm mode according to the overload count in the overload counter;
and carrying out load alarm on the software based on the determined alarm mode.
Based on the above embodiments, referring to fig. 9, a schematic structural diagram of an electronic device in an embodiment of the present application is shown.
Embodiments of the present application provide an electronic device that may include a processor 910 (Center Processing Unit, CPU), a memory 920, an input device 930, an output device 940, and the like, where the input device 930 may include a keyboard, a mouse, a touch screen, and the like, and the output device 940 may include a display device, such as a liquid crystal display (Liquid Crystal Display, LCD), a Cathode Ray Tube (CRT), and the like.
Memory 920 may include Read Only Memory (ROM) and Random Access Memory (RAM) and provides processor 910 with program instructions and data stored in memory 920. In the embodiment of the present application, the memory 920 may be used to store a program of any of the software overload warning methods in the embodiment of the present application.
The processor 910 is configured to execute any of the software overload warning methods according to the embodiments of the present application according to the obtained program instructions by calling the program instructions stored in the memory 920.
Based on the above embodiments, in the embodiments of the present application, there is provided a computer readable storage medium having stored thereon a computer program, which when executed by a processor, implements the software overload warning method in any of the above method embodiments.
It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
It will be apparent to those skilled in the art that various modifications and variations can be made in the present application without departing from the spirit or scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims and the equivalents thereof, the present application is intended to cover such modifications and variations.
Claims (10)
1. A method for alerting software overload, comprising:
calling a monitoring function at least once in a preset sampling time period, and acquiring each starting time for starting to call the monitoring function and each ending time for ending to call the monitoring function in the sampling time period, wherein the method specifically comprises the following steps of: the following steps are performed at least once within a preset sampling period: calling a monitoring function in a process of software, acquiring starting time for starting to call the monitoring function, ending calling the monitoring function if the communication event is monitored in the process, acquiring ending time for ending calling the monitoring function, and processing the monitored communication event; the ending time is the time acquired by ending calling the monitoring function when the communication event is monitored, and the monitoring function is used for continuously monitoring whether the communication event occurs in the process of the software;
determining the running time of the software in the sampling time period according to the starting time and the ending time, wherein the running time comprises the following steps: calculating a first time difference value between any one end time and the starting time of starting to call the monitoring function next time according to the end times respectively; adding the calculated first time differences to obtain the running time of the software in the sampling time period; or, respectively calculating a second time difference value between any one starting time and the corresponding ending time according to the starting times; adding the calculated second time difference values to obtain the idle time of the software in the sampling time period; obtaining the running time of the software in the sampling time period by calculating the time difference between the sampling time period and the idle time;
And determining a load value of the software in the sampling time period according to the running time, and determining whether to carry out overload warning on the software according to the load value.
2. The method of claim 1, wherein after processing the monitored communication event, further comprising:
judging whether the time difference between the ending time and the starting time of calling the monitoring function for the first time is larger than a preset sampling time period or not;
if the time difference value is determined to be larger than the sampling time period, terminating calling the monitoring function to obtain each starting time and each ending time;
and if the time difference value is not larger than the sampling time period, re-executing the step of calling the monitoring function in the process of the software.
3. The method of claim 1, wherein processing the monitored communication event comprises:
waking up the process based on the monitored communication event;
the communication event is processed in the process.
4. The method according to claim 1, wherein determining the load value of the software during the sampling period from the runtime comprises:
calculating a ratio between the run time and the sampling period;
And taking the calculated ratio as a load value of the software in the sampling time period.
5. The method of claim 1, wherein determining whether to overload the software based on the load value comprises:
judging whether the load value is larger than a preset load threshold value, if the load value is larger than or equal to the load threshold value, adding 1 to an overload count stored in a preset overload counter, and if the load value is smaller than the load threshold value, resetting the overload count;
determining a corresponding alarm mode according to the overload count in the overload counter;
and carrying out load alarm on the software based on the determined alarm mode.
6. A software overload warning apparatus, comprising:
the processing module is used for calling a monitoring function at least once in a preset sampling time period, and acquiring each starting time for starting to call the monitoring function in the sampling time period and each ending time for ending to call the monitoring function, wherein the ending time is the time acquired by ending to call the monitoring function when a communication event is monitored, and the monitoring function is used for continuously monitoring whether the communication event occurs in the process of software;
The processing module is specifically configured to perform the following operation steps at least once within a preset sampling period: calling a monitoring function in a process of software, acquiring starting time for starting to call the monitoring function, ending calling the monitoring function if the communication event is monitored in the process, acquiring ending time for ending calling the monitoring function, and processing the monitored communication event;
the determining module is used for determining the running time of the software in the sampling time period according to the starting time and the ending time; wherein:
the determining module is used for calculating a first time difference value between any one ending time and the starting time of next starting to call the monitoring function according to the ending time respectively; adding the calculated first time differences to obtain the running time of the software in the sampling time period; or,
the determining module is used for calculating a second time difference value between any one starting time and the corresponding ending time according to the starting time respectively; adding the calculated second time difference values to obtain the idle time of the software in the sampling time period; obtaining the running time of the software in the sampling time period by calculating the time difference between the sampling time period and the idle time; and
And the alarm module is used for determining the load value of the software in the sampling time period according to the running time and determining whether to carry out overload alarm on the software according to the load value.
7. The apparatus of claim 6, wherein after processing the monitored communication event, the processing module is further to:
judging whether the time difference between the ending time and the starting time of calling the monitoring function for the first time is larger than a preset sampling time period or not;
if the time difference value is determined to be larger than the sampling time period, terminating calling the monitoring function to obtain each starting time and each ending time;
and if the time difference value is not larger than the sampling time period, re-executing the step of calling the monitoring function in the process of the software.
8. The apparatus of claim 6, wherein the processing module is configured to, when processing the monitored communication event:
waking up the process based on the monitored communication event;
the communication event is processed in the process.
9. The apparatus of claim 6, wherein when determining a load value of the software during the sampling period based on the runtime, the alert module is specifically configured to:
Calculating a ratio between the run time and the sampling period;
and taking the calculated ratio as a load value of the software in the sampling time period.
10. The apparatus of claim 6, wherein the alarm module is configured to, when determining whether to overload the software based on the load value:
judging whether the load value is larger than a preset load threshold value, if the load value is larger than or equal to the load threshold value, adding 1 to an overload count stored in a preset overload counter, and if the load value is smaller than the load threshold value, resetting the overload count;
determining a corresponding alarm mode according to the overload count in the overload counter;
and carrying out load alarm on the software based on the determined alarm mode.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110232008.0A CN112948214B (en) | 2021-03-02 | 2021-03-02 | Software overload warning method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110232008.0A CN112948214B (en) | 2021-03-02 | 2021-03-02 | Software overload warning method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112948214A CN112948214A (en) | 2021-06-11 |
| CN112948214B true CN112948214B (en) | 2024-02-02 |
Family
ID=76247237
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110232008.0A Active CN112948214B (en) | 2021-03-02 | 2021-03-02 | Software overload warning method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112948214B (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107480029A (en) * | 2017-08-02 | 2017-12-15 | 北京深思数盾科技股份有限公司 | A kind of monitoring method and device of function call time |
| CN109495542A (en) * | 2018-10-16 | 2019-03-19 | 深圳壹账通智能科技有限公司 | Load allocation method and terminal device based on performance monitoring |
| CN111124829A (en) * | 2019-12-22 | 2020-05-08 | 北京浪潮数据技术有限公司 | Method for monitoring states of kubernetes computing nodes |
| CN112104513A (en) * | 2020-11-02 | 2020-12-18 | 武汉中科通达高新技术股份有限公司 | Visual software load method, device, equipment and storage medium |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8356194B2 (en) * | 2010-01-28 | 2013-01-15 | Cavium, Inc. | Method and apparatus for estimating overshoot power after estimating power of executing events |
-
2021
- 2021-03-02 CN CN202110232008.0A patent/CN112948214B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107480029A (en) * | 2017-08-02 | 2017-12-15 | 北京深思数盾科技股份有限公司 | A kind of monitoring method and device of function call time |
| CN109495542A (en) * | 2018-10-16 | 2019-03-19 | 深圳壹账通智能科技有限公司 | Load allocation method and terminal device based on performance monitoring |
| CN111124829A (en) * | 2019-12-22 | 2020-05-08 | 北京浪潮数据技术有限公司 | Method for monitoring states of kubernetes computing nodes |
| CN112104513A (en) * | 2020-11-02 | 2020-12-18 | 武汉中科通达高新技术股份有限公司 | Visual software load method, device, equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112948214A (en) | 2021-06-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2911060B1 (en) | Method and device for determining resource leakage and for predicting resource usage state | |
| US8402463B2 (en) | Hardware threads processor core utilization | |
| US8132170B2 (en) | Call stack sampling in a data processing system | |
| CN112749013B (en) | Thread load detection method and device, electronic equipment and storage medium | |
| CN102521098B (en) | Processing method and processing device for monitoring dead halt of CPU (Central Processing Unit) | |
| CN107038107A (en) | A kind of method and device for obtaining application interim card information | |
| CN108508874B (en) | Method and device for monitoring equipment fault | |
| CN109271290B (en) | Method and device for monitoring thread utilization rate and storage device | |
| US20130145220A1 (en) | Detection on Resource Leakage | |
| CN106528318B (en) | Thread dead loop detection method and device | |
| US20120180057A1 (en) | Activity Recording System for a Concurrent Software Environment | |
| US11455024B2 (en) | Idle state estimation by scheduler | |
| CN113806183A (en) | Application morton processing method, device, equipment, storage medium and program product | |
| CN112948214B (en) | Software overload warning method and device | |
| CN110990243A (en) | Caton analysis method and device, storage medium and computing equipment | |
| CN112764959B (en) | Method, device, equipment and storage medium for monitoring application program locking problem | |
| CN112035322B (en) | JVM monitoring method and device | |
| US8046760B2 (en) | Lock contention pinpointing | |
| CN115309507B (en) | CPU resource occupancy rate calculation method, device, equipment and medium | |
| CN100557576C (en) | The method and apparatus that operating system failure detects | |
| US8612988B2 (en) | Method for monitoring system resources and associated electronic device | |
| US20100274531A1 (en) | Automatic Identification of Execution Phases in Load Tests | |
| CN113742169A (en) | Service monitoring and alarming method, device, equipment and storage medium | |
| CN114238009A (en) | Performance self-adaptive adjusting method, system and medium for terminal system | |
| CN114003498A (en) | Software anomaly detection method and device and electronic equipment |
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 |