CN110879773B - CGroup-based memory monitoring method and device - Google Patents

Abstract

The present invention provides a CGroup-based memory monitoring method, comprising the following steps: periodically traversing all sub-CGroup trees, checking the memory.failcnt file of each CGroup, and recording the number of times the memory usage recorded in the file reaches the limit value ; In response to the number of times that the recorded memory usage of one of the CGroups reaches the limit value and the number of times recorded last time has increased, then check the cgroup.proc file of the CGroup to cyclically print all the running programs in the CGroup. process; select the directory files of multiple processes with the highest OOM scores in order of OOM scores from large to small, and match the selected process ID with the process ID in the printed CGroup, to Determining a process with a larger OOM score in the CGroup; and notifying the matched process ID in the CGroup as alarm information. The invention can record the usage of the Linux memory in detail, and can easily locate and solve memory-related errors that occur in the running process of the target program.

Description

A CGroup-based memory monitoring method and device

technical field

The present invention relates to the computer field, and more specifically, to a CGroup-based memory monitoring method and device.

Background technique

For the Linux operating system, memory management has always been very important. Although with the development of hardware, the computer memory capacity is also increasing, but it is still impossible to put all the processes and data in the memory, so memory allocation and monitoring are still very important. If the memory is used improperly or allocated unreasonably, it is easy to cause memory overflow, memory overwriting and other problems.

When a memory error occurs in the program, such as a memory overflow, the kernel will print some memory error information to the kernel log to help locate and solve the problem. However, the printing information of the kernel is generally relatively simple, and the memory error problem is affected by many conditions, and it is often difficult to locate in a more complicated situation. Linux kernel 2.6.24 introduces CGroup (Control Group). CGroup is a mechanism for managing processes in groups under Linux. Each CGroup has its own independently allocated memory capacity and managed processes. If the system memory is sufficient, insufficient CGroup memory will also cause OOM. The introduction of CGroup makes memory management more complicated, and memory problems are more difficult to find.

Contents of the invention

In view of this, the purpose of the embodiment of the present invention is to propose a memory monitoring method and device based on CGroup, so as to check the operation status of the current memory through the memory query interface of the Linux system, and print it out to a log file.

Based on the above purpose, an aspect of the embodiments of the present invention provides a CGroup-based memory monitoring method, including the following steps:

Periodically traverse all child CGroup trees, check the memory.failcnt file of each CGroup, and record the number of times the memory usage recorded in the file reaches the limit value;

In response to the number of times that the recorded memory usage of one of the CGroups reaches the limit value compared with the last recorded number of times, check the cgroup.proc file of the CGroup to print all the running programs in the CGroup in a loop process;

Select the directory files of a plurality of processes with the highest OOM scores in order of OOM scores from large to small, and match the selected process IDs with the process IDs in the printed CGroup;

Notify the matched process ID in the CGroup as alarm information.

In some embodiments, the periodic traversal of all sub-CGroup trees, checking the memory.failcnt file of each CGroup, and recording the number of times the memory usage recorded in the file reaches the limit value includes:

Check the memory.usage_in_bytes file and the memory.limit_in_bytes file to view and record the memory used by the CGroup and the memory quota limited by the CGroup respectively.

In some implementations, in response to the number of times that the recorded memory usage of one of the CGroups reaches the limit value has increased compared with the last recorded number of times, then check the cgroup.proc file of the CGroup to print in a loop All running processes within the CGroup include:

Use the ps command to cyclically print the user to which each process in the CGroup belongs, the process ID, the parent process ID, and the instructions executed by the process.

In some implementation manners, the catalog files of selecting a plurality of processes with the highest OOM scores according to the descending order of the OOM scores include:

Use a regular expression to match the directory files of the 10 processes with the largest OOM score values.

In some implementation manners, the notifying the matched process ID in the CGroup as alarm information includes:

The matched process ID in the CGroup and other relevant printed information are notified as alarm information through the simple network management protocol.

In some implementation manners, the notifying the matched process ID in the CGroup as alarm information further includes:

The memory quota limited by the matched CGroup and the memory information used by the CGroup are notified as alarm information.

Another aspect of the embodiments of the present invention provides a CGroup-based memory monitoring device, including:

at least one processor; and

A memory, the memory stores program code executable by the processor, and the program code implements the following steps when executed by the processor:

Periodically traverse all child CGroup trees, check the memory.failcnt file of each CGroup, and record the number of times the memory usage recorded in the file reaches the limit value;

In response to the number of times that the recorded memory usage of one of the CGroups reaches the limit value compared with the last recorded number of times, check the cgroup.proc file of the CGroup to print all the running programs in the CGroup in a loop process;

Select the directory files of the processes with the highest OOM scores in descending order of the OOM scores, and match the selected process IDs with the process IDs in the printed CGroup to determine the A process with a large OOM score in a CGroup;

Notify the matched process ID in the CGroup as alarm information.

In some embodiments, the periodic traversal of all sub-CGroup trees, checking the memory.failcnt file of each CGroup, and recording the number of times the memory usage recorded in the file reaches the limit value also includes:

Check the memory.usage_in_bytes file and the memory.limit_in_bytes file to view and record the memory used by the CGroup and the memory quota limited by the CGroup respectively.

In some implementations, in response to the number of times that the recorded memory usage of one of the CGroups reaches the limit value has increased compared with the last recorded number of times, then check the cgroup.proc file of the CGroup to print in a loop All running processes within the CGroup include:

Use the ps command to cyclically print the user to which each process in the CGroup belongs, the process ID, the parent process ID, and the instructions executed by the process.

In some implementation manners, the catalog files of selecting a plurality of processes with the highest OOM scores according to the descending order of the OOM scores include:

Use a regular expression to match the directory files of the 10 processes with the largest OOM score values.

The present invention has the following beneficial technical effects: a CGroup-based memory monitoring method and device provided by the embodiment of the present invention can record the usage of Linux memory in detail, and can be easily located and solved for memory-related errors that occur during the running of the target program, such as CGroup memory overflow problem is beneficial to debug programs, monitor system status, and help locate and solve memory-related problems that occur during program development.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only These are some embodiments of the present invention, and those skilled in the art can obtain other embodiments according to these drawings without any creative effort.

Fig. 1 is the flow chart of a kind of memory monitoring method based on CGroup according to the present invention;

Fig. 2 is a schematic diagram of sending an alarm notification through an SNMP service according to the present invention;

FIG. 3 is a schematic diagram of a hardware structure of a CGroup-based memory monitoring device according to the present invention.

detailed description

Embodiments of the present invention are described below. It is to be understood, however, that the disclosed embodiments are merely examples and that other embodiments may take various alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention. As will be understood by persons of ordinary skill in the art, various features shown and described with reference to any one figure can be combined with features shown in one or more other figures to create embodiments not explicitly shown or described . Combinations of features shown provide representative embodiments for typical applications. However, various combinations and modifications of the features consistent with the teachings of the present invention may be desired for certain particular applications or implementations.

In order to make the object, technical solution and advantages of the present invention clearer, the embodiments of the present invention will be further described in detail below in conjunction with specific embodiments and with reference to the accompanying drawings.

Based on the above purpose, an embodiment of the present invention proposes a CGroup-based memory monitoring method, as shown in FIG. 1 , including the following steps:

Step S101: Periodically traverse all sub-CGroup trees, check the memory.failcnt file of each CGroup (this file shows the number of times the memory usage reaches the limit value), and record the number of times the memory usage recorded in the file reaches the limit value ;

Step S102: In response to the number of times that the recorded memory usage of one of the CGroups reaches the limit value compared with the number of times recorded last time, check the cgroup.proc file of the CGroup (this file records the number of times in the current CGroup) ID information of all processes), to cyclically print all running processes in the CGroup;

Step S103: Select the directory files of a plurality of processes with the highest OOM scores in descending order according to the OOM (Out Of Memory) scores, and combine the selected process ID with the printed CGroup Match the process IDs in the CGroup to determine the process with a larger OOM score in the CGroup;

Step S104: Notify the matched process ID in the CGroup as alarm information.

In some embodiments, the date and overall memory status can be printed first, for example, use the date command to format and output the system time, and use the free command to display the overall usage of the system memory.

In some embodiments, the periodic traversal of all child CGroup trees, checking the memory.failcnt file of each CGroup, and recording the number of times the memory usage recorded in the file reaches the limit value includes: checking the memory.usage_in_bytes file and memory.limit_in_bytes file to view and record the memory used by the CGroup and the memory quota limited by the CGroup.

In some embodiments, in a Linux system, the /sys/fs/cgroup/memory/ directory is a CGroup tree, and all subdirectories under the directory form nodes on the CGroup tree. Through the recursive function, traverse all sub-CGroup trees, that is, traverse all sub-directories. Under each CGroup, check the contents of the following files: memory.usage_in_bytes, which shows the memory used by the current CGroup; memory.limit_in_bytes, which shows the memory quota limited by the current CGroup; memory.failcnt, which shows the memory usage The number of times the limit value was reached.

Comparing the memory used by the current CGroup and the memory quota, the closer the used memory is to the memory quota, the greater the risk of OOM in the CGroup. When the process in the CGroup applies for memory, if the memory in the CGroup is exhausted, the value of memory.failcnt will be increased by 1. Therefore, when the value of memory.failcnt increases, it indicates that the CGroup memory allocation is insufficient, and it is necessary to consider increasing the CGroup memory. The monitoring script will execute a traversal operation at regular intervals (set by the user, 5 seconds by default), which is called a cycle. Every time you check the value of memory.failcnt, compare it with the value of the previous cycle. If the value increases, it means that the memory allocation of the CGroup is insufficient, and the CGroup has the risk of memory overflow, and the information of the CGroup will be recorded.

In some embodiments, in response to the number of times that the recorded memory usage of one of the CGroups reaches the limit value is greater than the number of previous records, then check the cgroup.proc file of the CGroup to print in a loop All running processes in the CGroup include: using the ps command to cyclically print the user, process ID, parent process ID and instructions executed by each process in the CGroup.

The cgroup.proc file in each CGroup records the pids of all the processes in the current CGroup. In each CGroup with a risk of memory overflow, all running processes in the CGroup are printed cyclically through the cgroup.proc file. Use the ps command to cyclically print the user (user), pid (process id), ppid (parent process id), and cmd (commands executed by the process) of each process. These printed information help developers understand the relationship between processes and memory. When CGroup memory overflow triggers OOM (Out Of Memory, insufficient memory), they can quickly find processes that occupy too much memory.

When OOM occurs in CGroup due to insufficient memory, oom killer (the kernel handler after OOM occurs) will score each process, and then choose the process with the highest score to kill. The oom_score of the process is the main reference value when scoring. The higher the oom_score score, the more it will be killed by the kernel first.

In some embodiments, the selection of the directory files of the processes with the highest OOM scores according to the descending order of the OOM score (oom_score) includes: using a regular expression to match the 10 processes with the largest OOM score value catalog file.

In some embodiments, under the /proc directory, a regular expression is used to match a directory file in the form of /proc/[0-9]+ (the name of the directory file is the process ID). Each catalog file records the details of a process. In each directory, print the contents of the file named oom_score, which outputs the score of the process oom_score. Select 10 processes according to the order of oom_score from large to small. If the above memory.failcnt value has increased CGroup, a process belongs to these 10 processes (matched by process ID), then print the oom_score of the process come out.

In some embodiments, the notifying the matched process ID in the CGroup as alarm information includes: using the simple network management protocol to notify the matched process ID in the CGroup and other related information printed as alarm information Notice.

In some embodiments, the notifying the matched process ID in the CGroup as alarm information further includes: notifying the memory quota limited by the matched CGroup and the memory information used by the CGroup as alarm information Notice.

The Simple Network Management Protocol (SNMP) is an application layer protocol of the TCP/IP protocol suite, which is mainly used for the management of network devices. In the above steps, as shown in Figure 2, if there is a risk of memory overflow, the memory monitoring program will print the detailed information of CGroup and the detailed information of the process (if there is no risk of memory overflow, the warning message will not be generated, this step will not be executed), that is, the ID of the process with a larger OOM score in the determined CGroup and other related information. The detailed information related to these memory and processes will be input to the local log file and saved on the one hand, and will be used as the data part of the snmp message on the other hand. The memory monitoring program composes the snmp trap message together with the data part of the snmp message according to the snmp configuration items such as the snmp message sending address and community word set in advance by the developer. Subsequently, the monitoring program sends the snmp trap message to the destination address, which is generally the developer's own network device. In this way, when there is a risk of system memory overflow, the developer will receive a warning message.

When technically feasible, the technical features listed above for different embodiments can be combined with each other, or changed, added, omitted, etc., so as to form other embodiments within the scope of the present invention.

As can be seen from the above embodiments, the CGroup-based memory monitoring method provided by the embodiment of the present invention can record the usage of Linux memory in detail, and is easy to locate and solve memory-related errors that occur during the running of the target program, such as CGroup memory The overflow problem is conducive to debugging programs, monitoring system status, and helping to locate and solve memory-related problems that occur during program development.

Based on the above purpose, another aspect of the embodiments of the present invention proposes a CGroup-based memory monitoring device including:

at least one processor; and

A memory, the memory stores program code executable by the processor, and the program code implements the following steps when executed by the processor:

Periodically traverse all child CGroup trees, check the memory.failcnt file of each CGroup, and record the number of times the memory usage recorded in the file reaches the limit value;

In response to the number of times that the recorded memory usage of one of the CGroups reaches the limit value compared with the last recorded number of times, check the cgroup.proc file of the CGroup to print all the running programs in the CGroup in a loop process;

Select the directory files of the processes with the highest OOM scores in descending order of the OOM scores, and match the selected process IDs with the process IDs in the printed CGroup to determine the A process with a large OOM score in a CGroup;

Notify the matched process ID in the CGroup as alarm information.

In some embodiments, the periodic traversal of all sub-CGroup trees, checking the memory.failcnt file of each CGroup, and recording the number of times the memory usage recorded in the file reaches the limit value also includes: checking the memory.usage_in_bytes file And the memory.limit_in_bytes file to view and record the memory used by the CGroup and the memory quota limited by the CGroup.

In some embodiments, in response to the number of times that the recorded memory usage of one of the CGroups reaches the limit value is greater than the number of previous records, then check the cgroup.proc file of the CGroup to print in a loop All running processes in the CGroup include: using the ps command to cyclically print the user, process ID, parent process ID and instructions executed by each process in the CGroup.

In some embodiments, the selecting the directory files of the processes with the highest OOM scores in descending order of the OOM scores includes: using a regular expression to match the directory files of the 10 processes with the largest OOM scores.

As shown in FIG. 3 , it is a schematic diagram of the hardware structure of an embodiment of the CGroup-based memory monitoring device provided by the present invention.

Taking the computer equipment shown in FIG. 3 as an example, the computer equipment includes a processor 301 and a memory 302 , and may further include: an input device 303 and an output device 304 .

The processor 301, the memory 302, the input device 303, and the output device 304 may be connected via a bus or in other ways. In FIG. 3, connection via a bus is taken as an example.

The memory 302, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs and modules, such as the CGroup-based memory monitoring in the embodiment of the present application The program instruction/module to which the method corresponds. The processor 301 executes various functional applications and data processing of the server by running non-volatile software programs, instructions and modules stored in the memory 302, that is, implements the CGroup-based memory monitoring method in the above method embodiment.

The memory 302 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application program required by at least one function; the data storage area may store data created according to the CGroup-based memory monitoring method, and the like. In addition, the memory 302 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid-state storage devices. In some embodiments, the memory 302 may optionally include memory that is remotely located relative to the processor 301, and these remote memories may be connected to the local module through a network. Examples of the aforementioned networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The input device 303 can receive input numbers or character information, and generate key signal input related to user setting and function control of the computer equipment based on the CGroup memory monitoring method. The output device 304 may include a display device such as a display screen.

The program instructions/modules corresponding to the one or more CGroup-based memory monitoring methods are stored in the memory 302, and when executed by the processor 301, the CGroup-based memory monitoring method in any of the above method embodiments is executed .

Any one of the embodiments of the computer device that executes the CGroup-based memory monitoring method can achieve the same or similar effects as any of the foregoing method embodiments corresponding thereto.

Finally, it should be noted that those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer programs, and the programs can be stored in computer-readable storage media. , when the program is executed, it may include the procedures of the embodiments of the above-mentioned methods. Wherein, the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM) and the like.

In addition, typically, the devices and devices disclosed in the embodiments of the present invention can be various electronic terminal devices, such as mobile phones, personal digital assistants (PDAs), tablet computers (PADs), smart TVs, etc., and can also be large-scale terminals equipment, such as servers, etc., therefore, the scope of protection disclosed in the embodiments of the present invention should not be limited to a specific type of device or equipment. The client disclosed in the embodiments of the present invention may be applied to any of the above-mentioned electronic terminal devices in the form of electronic hardware, computer software, or a combination of the two.

In addition, the method disclosed according to the embodiment of the present invention can also be implemented as a computer program executed by a CPU, and the computer program can be stored in a computer-readable storage medium. When the computer program is executed by the CPU, the above functions defined in the methods disclosed in the embodiments of the present invention are executed.

In addition, the above-mentioned method steps and system units can also be realized by using a controller and a computer-readable storage medium for storing a computer program for enabling the controller to realize the functions of the above-mentioned steps or units.

In addition, it should be appreciated that the computer-readable storage media (eg, memories) described herein can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. By way of example and not limitation, nonvolatile memory can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory memory. Volatile memory can include random access memory (RAM), which can act as external cache memory. By way of example and not limitation, RAM is available in various forms such as Synchronous RAM (DRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). Storage devices of the disclosed aspects are intended to include, but are not limited to, these and other suitable types of memory.

Those of skill would also appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described generally in terms of their functionality. Whether such functionality is implemented as software or as hardware depends upon the particular application and design constraints imposed on the overall system. Those skilled in the art can implement the described functions in various ways for each specific application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosed embodiments of the present invention.

The various exemplary logical blocks, modules, and circuits described in connection with the disclosure herein can be implemented or performed using the following components designed to perform the functions described herein: general-purpose processors, digital signal processors (DSPs), special-purpose Integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination of these. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, eg, a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP, and/or any other such configuration.

The steps of a method or algorithm described in connection with the disclosure herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of both. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In an alternative, the storage medium may be integrated with the processor. The processor and storage medium can reside in an ASIC. The ASIC may reside in a user terminal. In an alternative, the processor and storage medium may reside as discrete components in the user terminal.

In one or more exemplary designs, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. Storage media may be any available media that can be accessed by a general purpose or special purpose computer. By way of example and not limitation, the computer readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage device, magnetic disk storage device or other magnetic storage device, or may be used to carry or store instructions in Any other medium that can be accessed by a general purpose or special purpose computer or a general purpose or special purpose processor, and the required program code or data structure. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable Cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers . Combinations of the above should also be included within the scope of computer-readable media.

It should be understood that as used herein, the singular form "a" and "an" are intended to include the plural forms as well, unless the context clearly supports an exception. It should also be understood that "and/or" as used herein is meant to include any and all possible combinations of one or more of the associated listed items.

The serial numbers of the embodiments disclosed in the above-mentioned embodiments of the present invention are only for description, and do not represent the advantages and disadvantages of the embodiments.

Those of ordinary skill in the art can understand that all or part of the steps for implementing the above embodiments can be completed by hardware, and can also be completed by instructing related hardware through a program. The program can be stored in a computer-readable storage medium. The above-mentioned The storage medium mentioned may be a read-only memory, a magnetic disk or an optical disk, and the like.

The above-described embodiments are possible examples of implementations, and were merely set forth for a clear understanding of the principles of the invention. Those of ordinary skill in the art should understand that: the discussion of any of the above embodiments is exemplary only, and is not intended to imply that the scope (including claims) disclosed by the embodiments of the present invention is limited to these examples; under the idea of the embodiments of the present invention , technical features in the above embodiments or in different embodiments can also be combined, and there are many other changes in different aspects of the embodiments of the present invention as described above, which are not provided in details for the sake of brevity. Therefore, within the spirit and principle of the embodiments of the present invention, any omissions, modifications, equivalent replacements, improvements, etc., shall be included in the protection scope of the embodiments of the present invention.

Claims (10)

1. A memory monitoring method based on CGroup, is characterized in that, comprises the following steps: Periodically traverse all child CGroup trees, check the memory.failcnt file of each CGroup, and record the number of times the memory usage recorded in the file reaches the limit value; In response to the number of times that the recorded memory usage of one of the CGroups reaches the limit value compared with the last recorded number of times, check the cgroup.proc file of the CGroup to print all the running programs in the CGroup in a loop process; Select the directory files of a plurality of processes with the highest OOM scores in order of OOM scores from large to small, and match the selected process IDs with the process IDs in the printed CGroup; Notify the matched process ID in the CGroup as alarm information. 2. The method according to claim 1, characterized in that, the periodic traversal of all sub-CGroup trees, checking the memory.failcnt file of each CGroup, and recording the time when the memory usage recorded in the file reaches the limit value Times include: Check the memory.usage_in_bytes file and the memory.limit_in_bytes file to view and record the memory used by the CGroup and the memory quota limited by the CGroup respectively. 3. The method according to claim 1, characterized in that, the number of times that the memory usage of the record in response to one of the CGroups reaches the limit value is increased compared with the number of times recorded last time, then check the CGroup The cgroup.proc file to loop through all running processes within the CGroup includes: Use the ps command to cyclically print the user to which each process in the CGroup belongs, the process ID, the parent process ID, and the instructions executed by the process. 4. The method according to claim 1, characterized in that, selecting the directory files of a plurality of processes with the highest OOM scores in descending order according to the OOM scores comprises: Use regular expressions to match the directory files of the 10 processes with the largest OOM scores. 5. The method according to claim 3, wherein the notifying the matched process ID in the CGroup as alarm information comprises: The matched process ID in the CGroup and other printed related information are notified as alarm information through the simple network management protocol. 6. The method according to claim 2, wherein the notifying the matched process ID in the CGroup as alarm information further comprises: The memory quota limited by the matched CGroup and the memory used by the CGroup are notified as alarm information. 7. A memory monitoring device based on CGroup, characterized in that, comprising: at least one processor; and A memory, the memory stores program code executable by the processor, and the program code implements the following steps when executed by the processor: Periodically traverse all child CGroup trees, check the memory.failcnt file of each CGroup, and record the number of times the memory usage recorded in the file reaches the limit value; In response to the number of times that the recorded memory usage of one of the CGroups reaches the limit value compared with the last recorded number of times, check the cgroup.proc file of the CGroup to print all the running programs in the CGroup in a loop process; Select the directory files of a plurality of processes with the highest OOM scores in order of OOM scores from large to small, and match the selected process IDs with the process IDs in the printed CGroup; Notify the matched process ID in the CGroup as alarm information. 8. The device according to claim 7, wherein the periodic traversal of all sub-CGroup trees, checking the memory.failcnt file of each CGroup, and recording the time when the memory usage recorded in the file reaches the limit value Times also include: Check the memory.usage_in_bytes file and the memory.limit_in_bytes file to view and record the memory used by the CGroup and the memory quota limited by the CGroup respectively. 9. The device according to claim 7, wherein the response to the number of times that the recorded memory usage of one of the CGroups reaches the limit value is increased compared with the number of times recorded last time, then check the CGroup The cgroup.proc file to loop through all running processes within the CGroup includes: Use the ps command to cyclically print the user to which each process in the CGroup belongs, the process ID, the parent process ID, and the instructions executed by the process. 10. The device according to claim 7, wherein the catalog files of selecting a plurality of processes with the highest OOM scores according to the descending order of the OOM scores include: Use regular expressions to match the directory files of the 10 processes with the largest OOM scores.

Images