A method for dynamic monitoring of memory usage based on services and processes

Abstract

This invention provides a method for dynamic monitoring of memory usage based on services and processes. The method includes monitoring the physical memory residency and virtual memory usage of services and processes. Service monitoring involves obtaining processes associated with the service by parsing `systemctl status`, monitoring and aggregating the VmRSS and VmSize of each process associated with the same service, or collecting the VmRSS and VmSize of each process associated with the same service twice before and after a sampling time interval, calculating the difference between the two values, and aggregating them. Process monitoring involves activating process monitoring mode, monitoring the VmRSS and VmSize of active processes, or collecting the VmRSS and VmSize of active processes twice before and after a sampling time interval, and calculating the difference between the two values. This invention enables dynamic tracking of the overall memory usage of services and rapid diagnosis and identification of the growth trend of processes with the highest memory consumption.

Description

Technical Field

[0001] This invention relates to a method for dynamic monitoring of memory usage, and more particularly to a method for dynamic monitoring of memory usage based on services and processes, belonging to the field of computer memory monitoring technology. Background Technology

[0002] In modern Linux operating systems, the memory usage behavior of services and processes directly affects system stability and performance. Especially for long-running services and processes, memory leaks or abnormal growth can lead to system resource exhaustion, response delays, and even service crashes. Therefore, dynamically monitoring the physical memory residency set (VmRss) and virtual memory usage (VmSize) of critical services and long-running processes is a crucial step and necessary measure for system fault diagnosis.

[0003] To visualize and analyze memory usage, various technologies have been developed in the industry. Common traditional memory reporting tools such as `free` and `top` can provide a rough overview of memory usage. Command-line tools like `smem` can also be used to collect statistics on process and user memory usage based on the ` / proc` filesystem. While traditional commands like `free` and `top` can obtain the current running status of system processes, further filtering of the command output can reveal the memory status information of specific processes. The `smem` command-line tool can collect statistics on process and user memory usage based on the ` / proc` filesystem. However, `smem` only outputs a snapshot of memory usage at a specific moment, and cannot automatically perform comparative analysis over time. Furthermore, `smem` is a static snapshot tool, which has significant limitations in dynamic monitoring and anomaly warning.

[0004] In summary, the shortcomings of existing technologies are as follows:

[0005] Current mainstream process memory monitoring technologies have many limitations in real-world production environments: Traditional command-line tools such as the `free` command only provide an overview of the overall system memory usage, including total memory, used memory, and free memory, but cannot provide detailed information at the specific process or service level. Moreover, they only display the current status each time they are executed, and do not support dynamic monitoring; while the `top` command can view the memory usage of a single process (such as VmRSS, VmSize), it does not associate this data with specific services by default.

[0006] As a static snapshot tool, smem has significant shortcomings in dynamic detection and anomaly warning. smem only outputs a snapshot of memory usage at a specific moment, failing to automatically perform comparative analysis over time; it only provides static snapshots and lacks dynamic monitoring capabilities. smem only displays the current memory value and lacks the ability to identify the core characteristic of memory leaks—"continuous memory growth"—meaning it lacks incremental analysis and leak warning mechanisms. smem's output is a terminal table, which, although redirected to a file, lacks structured fields such as timestamps, service names, sampling periods, and incremental values, resulting in unstructured log output that hinders automated analysis. Summary of the Invention

[0007] To address the aforementioned issues, this invention provides a method for dynamic monitoring of memory usage based on services and processes, enabling dynamic tracking of the overall memory usage of critical systemd services, and rapid diagnosis and identification of the growth trend of processes with the highest memory consumption.

[0008] To achieve the above objectives, the technical solution of the present invention is: a method for dynamic monitoring of memory usage based on services and processes, comprising two aspects: monitoring the physical memory residency and virtual memory usage of services, and monitoring the physical memory residency and virtual memory usage of processes; wherein,

[0009] Monitoring the physical memory residency and virtual memory usage of a service includes the following steps: obtaining all processes associated with the service by parsing systemctl status, directly monitoring and aggregating the VmRSS and VmSize of each process associated with the same service, or collecting the VmRSS and VmSize of each process associated with the same service twice before and after the sampling time interval, calculating the difference between the two values ​​and aggregating them, so as to achieve statistics on the overall memory usage of a single service.

[0010] Monitoring the physical memory residency and virtual memory usage of processes includes the following steps: starting the process monitoring mode, directly monitoring the VmRSS and VmSize of effective processes, or collecting the VmRSS and VmSize of effective processes twice before and after the sampling time interval and calculating the difference between the two values ​​to achieve statistics on the memory usage of each process;

[0011] Wherein, VmRSS is the physical memory residency, which represents the total size of all pages in the page tables of each process that have been mapped to physical memory, including the code segment, data segment, heap, stack, and the portion of shared libraries that have been loaded into physical memory, but excluding pages that have been swapped out to Swap, mmap regions that have not yet been loaded into memory, and virtual memory that has only been allocated but not used.

[0012] VmSize refers to the virtual memory footprint, representing the size of the entire virtual address space of each process, including the code segment, data segment, heap, stack, memory-mapped regions, shared libraries, and memory allocated by malloc() but not yet used.

[0013] Furthermore, monitoring the physical memory residency and virtual memory usage of the service includes the following steps:

[0014] Step S1: Receive user command-line arguments;

[0015] Step S2: Initialize the predefined list of critical services;

[0016] Step S3: Select services in an active state from the predefined list of critical services to form a set of monitoring services;

[0017] Step S4: Determine the sampling time interval. Check if the user has set the -t parameter via command line parameters. If so, the time interval is the parameter set by the user; if not, the time interval is the system default parameter.

[0018] Step S5: Traverse each service in the monitoring service set and obtain the associated processes;

[0019] Step S6: Collect the initial memory data of each associated process. The initial memory data includes VmRSS(t0) and VmSize(t0).

[0020] Step S7: Wait for the sampling time interval;

[0021] Step S8: Recollect the memory data (t1) of each associated process, including VmRSS(t1) and VmSize(t1);

[0022] Step S9: Calculate the memory growth. For each process, calculate: ΔVmRSS = VmRSS(t1) - VmRSS(t0); ΔVmSize = VmSize(t1) - VmSize(t0); Aggregate the memory growth of each process associated with the same service to obtain the memory growth of the service.

[0023] Step S10: Generate and output monitoring logs;

[0024] Where VmRSS(t0) and VmSize(t0) are the initial physical memory resident value and virtual memory usage value, respectively, and VmRSS(t1) and VmSize(t1) are the physical memory resident value and virtual memory usage value after the sampling time interval t, respectively.

[0025] Furthermore, the command-line parameters obtained in step S1 include those obtained by the user via -a<service_name> Added custom services.

[0026] Furthermore, after step S3, the following steps are also included: processing user-added services and determining whether -a was used.<service_name> parameter:

[0027] If used, services that are active will be filtered from custom services and added to the monitoring service set.

[0028] Furthermore, the command-line parameters obtained in step S1 also include the service's memory increment threshold, which is used to determine whether an alarm needs to be triggered during subsequent memory monitoring.

[0029] Furthermore, monitoring the physical memory residency and virtual memory usage of processes includes the following steps:

[0030] Step Sa: Start process monitoring mode. Process monitoring is enabled by default in the system, or it can be triggered explicitly by the user.

[0031] Step Sb: Traverse the / proc directory to identify all processes and determine whether they are valid processes;

[0032] Step Sc: Filter invalid processes, kernel processes, and user-specified processes to ignore;

[0033] Step Sd: For the filtered processes, sort them by memory usage and select the processes with the highest memory usage as the processes to be detected;

[0034] Step Se: Collect memory information for each process to be detected;

[0035] Step Sf: Determine whether to perform trend analysis by checking if check_interval > 0 is set.

[0036] If not, only the current memory information of the process to be detected will be output, and the process will proceed to step Si; if yes, the process will proceed to the growth detection process, and the process will proceed to step Sg.

[0037] Step Sg: Wait for the sampling time interval and re-acquire the memory information of each process to be detected;

[0038] Step Sh: Calculate the memory growth based on the results collected in steps Se and Sg;

[0039] Step Si: Generate monitoring results output and end process monitoring.

[0040] Furthermore, in step Sc, processes that the user specifies to be ignored are filtered using the skip_services parameter set by the user.

[0041] Furthermore, step Sa also includes setting the maximum number of outputs in the output memory increment.

[0042] Furthermore, step Se collects memory information for each process under test, including reading / proc / <pid>The ` / status` file is used to obtain VmSize and VmRSS, and ` / proc / ` is read. <pid> / comm or / proc / <pid>The Name field in / status retrieves the process name; where VmRSS is the physical memory residency and VmSize is the virtual memory usage.

[0043] Furthermore, step S adjusts the output format based on whether check_interval > 0 is set. If check_interval > 0 is not set, the memory usage of the current Top process is printed directly; if there is a time interval, the result is formatted and written to the log file.

[0044] The beneficial effects of the service- and process-based dynamic memory usage monitoring method of the present invention are as follows:

[0045] This invention enables dynamic tracking of overall memory usage for critical systemd services and rapid diagnosis and trend identification of processes with the highest memory consumption. It overcomes the limitations of existing general-purpose memory analysis tools (such as smem, ps, and top) in system-level service monitoring and critical process behavior analysis. It provides a lightweight, efficient, configurable, and trend-analysis-supporting dual-mode memory monitoring method and system, meeting the practical needs of refined and automated observation of service and process resource behavior in operating system maintenance, performance tuning, and troubleshooting.

[0046] This invention calls `systemctl status` for each systemd service. <service>Obtain the list of PIDs of its main process and subprocesses, and iterate through / proc / <pid>The ` / status` function extracts and sums the VmRSS (Virtual Memory Resident Size) and VmSize (Virtual Memory Usage) of each process to obtain the overall memory usage of the service. It establishes a mapping and aggregation mechanism between "services" and "processes," thereby improving the rationality and practicality of monitoring granularity. It can reflect the overall memory consumption level of a service (which may contain multiple processes), avoiding misjudgments of service resource overhead caused by focusing only on a single process. Traditional tools (such as `smem`) output memory data on a process-by-process basis, failing to reflect the resource aggregation relationship of the logical unit of "service."

[0047] This invention incorporates a default set of critical services (such as dbus, docker, polkit, and systemd), and uses `systemctl list-units --type=service --state=active` to retrieve currently running services, monitoring only the intersection of these two sets. By combining the "preset list" with "runtime status query," it leverages systemd's service management capabilities to automatically identify currently active critical services. This combination of "static configuration + dynamic awareness" makes monitoring targets more targeted, reduces invalid data collection, improves monitoring efficiency and accuracy, and enables critical service inspections to be initiated without manual intervention.

[0048] Users of this invention can access it via -a<service_name> When a custom service is added, the system checks if the service is active; if so, it is included in the monitoring. By introducing a dual mechanism of "user scalability" and "status verification," the system's adaptability is enhanced. On one hand, the `-a` parameter provides a configuration interface; on the other hand, querying the `systemctlis-active` or status list ensures that only actually running services are monitored. This "scalable + conditional filtering" design allows the monitoring system to meet general needs while adapting to personalized scenarios, avoiding waste of monitoring resources. This invention supports flexible monitoring of non-standard services (such as self-developed daemons) and avoids initiating invalid monitoring requests for services that are not running.

[0049] This invention supports two modes simultaneously: service mode and process mode. Service mode monitors memory changes for a specified service; process mode identifies the Top N processes with high memory usage and analyzes their growth trends. It can run independently or sequentially. This solves the problem that single-granularity monitoring is insufficient for handling complex issues. For example, after detecting memory growth in the Docker service, it's still necessary to determine whether it's caused by containerd or dockerd. This invention combines service-level aggregation with process-level sorting to construct a progressive diagnostic chain; service monitoring is used to discover problems, and process monitoring is used to locate the root cause. The two work together to improve overall troubleshooting efficiency, forming a problem localization path "from macro (service) to micro (process)," meeting diagnostic needs at different levels.

[0050] This invention reads / proc / before and after the time interval. <pid>The difference between VmRSS and VmSize in / status is used to calculate the amount of memory growth. Since memory leaks often manifest as slow growth over a long period, instantaneous values ​​are difficult to detect. This invention transforms static observation into dynamic analysis by introducing state comparisons over a time dimension. Through the process of "initial sampling → waiting → resampling → difference calculation," the system can capture memory behaviors that "appear normal but are continuously increasing," thus providing a basis for preventative maintenance; identifying slow memory growth or potential leaks, and providing trend information with greater diagnostic value than instantaneous snapshots.

[0051] This invention allows users to specify parameters such as `--skip-services="journald,kworker"` to exclude known non-critical processes, retaining only those requiring attention. System processes often include those like `kworker` and `journald`, which experience memory fluctuations due to kernel activity or log writing, easily masking the truly problematic processes. This invention introduces a configurable filtering mechanism, allowing users to filter out interfering items based on environmental characteristics. This "whitelist + blacklist" filtering logic enhances the relevance and diagnostic efficiency of monitoring results; reduces interfering information, improves readability, and focuses on the processes that truly need analysis.

[0052] This invention writes monitoring results to a log file in a fixed format, including fields such as timestamp, service name, PID, VmRSS, and ΔVmRSS. Because console output is easily lost and difficult to audit, this invention persists monitoring data as structured text, making it traceable. Each line of log represents an observation point, and multiple observation points can form a trend curve. This "output is data" design allows the tool to be used not only for real-time diagnosis but also as a data source for automated operations and maintenance platforms. Attached Figure Description

[0053] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0054] Figure 1 This is a schematic diagram illustrating the monitoring of physical memory residency and virtual memory usage in this invention.

[0055] Figure 2 This is a schematic diagram illustrating the monitoring of physical memory residency and virtual memory usage during the process of this invention. Detailed Implementation

[0056] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0057] This invention discloses a dynamic monitoring method for memory usage based on services and processes, specifically a dynamic monitoring method based on the systemd service model and the dynamic monitoring of process-resident memory and virtual memory usage. The method includes two aspects: monitoring service physical memory residency and virtual memory usage, and monitoring process physical memory residency and virtual memory usage.

[0058] This invention implements service-level memory monitoring. By parsing `systemctl status`, it obtains all processes associated with a service and aggregates their VmRSS (physical memory residency) and VmSize (virtual memory usage), achieving accurate statistics on the overall memory usage of a single service. This invention provides a predefined automatic detection mechanism for critical services: a built-in default list of critical services (such as dbus, docker, polkit, systemd) automatically filters currently running services, enabling core component monitoring without manual intervention. This invention supports memory usage growth trend analysis: after a set time interval, resampling is performed, and the difference between VmRSS and VmSize (ΔVmRSS and ΔVmSize) is calculated to identify potential memory leaks or abnormal growth behavior. This invention allows users to dynamically expand the monitoring scope by using the `-a service_name` parameter to include user-specified services in the monitoring set. If the service is running, it is automatically added to the detection process, improving flexibility and applicability. This invention sets a default monitoring duration, lowering the barrier to entry: if the `-t` parameter is not specified, it defaults to 5 minutes. This invention features a minute-by-minute monitoring cycle to prevent users from missing parameters and causing functional failures, thus improving usability and robustness. It outputs structured logs for easy subsequent analysis: monitoring results are written to a specified log file, including timestamps, service names, PIDs, memory values, and increments, supporting long-term archiving and automated analysis. The following examples provide a detailed introduction to monitoring service physical memory residency and virtual memory usage, as well as process physical memory residency and virtual memory usage.

[0059] Example 1

[0060] This Example 1 details a method for monitoring service physical memory residency and virtual memory usage. This method operates on a "service" basis, making it suitable for system-level operation and maintenance monitoring. It emphasizes configurability, supporting default services plus dynamic extensions. It relies on the systemd management mechanism and is applicable to modern Linux distributions. Specifically, it includes the following:

[0061] Combination Figure 1 As shown, it receives user command-line arguments and determines whether to perform a service-level memory check by parsing the command-line arguments. Figure 1 The `-c` option specifies service-level memory checks, while the `-C` option specifies process-level memory checks. Users can define a predefined list of critical services or add custom services. For example, dbus, docker, polkit, and systemd can be preset as critical services using the `-a` option.<service_name> (Hereinafter referred to as "-a parameter") Add custom services (i.e. additional services).

[0062] The system retrieves the list of services specified in the `-a` parameter. Simultaneously, it checks if any additional services are in the critical service list. If so, it initializes the critical service list and filters out services in the active (running) state to form the final monitoring service set. If any additional services are not in the critical service list, they are added to the list, and services in the active (running) state are merged into the final monitoring service set. Services not in a running state can be logged as a notification.

[0063] Set the sampling time interval. Check if a sampling time interval has been set. If not, the default sampling interval is 300s or other default duration. If a sampling time interval has been set, subsequent data collection will be performed according to the specified time interval.

[0064] Set a memory increment threshold for the service, which will be used to determine whether an alarm should be triggered during subsequent memory monitoring.

[0065] Iterate through the monitoring service collection, execute the monitoring process for each service, and call systemctl status. <service>Retrieve the list of PIDs corresponding to the service (including the PIDs of the main process and child processes), and for each process PID, execute the read operation on / proc / <pid>The ` / status` file extracts the VmRSS and VmSize of each process and sums them to obtain the overall memory usage of the service. The initial state (t0) is recorded, including a timestamp, PID, service name, and initial VmRSS and VmSize. VmRSS represents the physical memory residency, indicating the total size of all pages mapped to physical memory in each process's page tables. This includes code segments, data segments, heap, stack, and portions of shared libraries loaded into physical memory, but excludes pages swapped out, mmap regions not yet loaded into memory, and allocated but unused virtual memory. VmSize represents the virtual memory usage, indicating the size of the entire virtual address space for each process, including code segments, data segments, heap, stack, memory-mapped regions, shared libraries, and memory allocated via `malloc()` but not yet used.

[0066] Wait for the set sampling interval, then read / proc / again. <pid>The ` / status` command reads VmRSS and VmSize again and records them as status t1. It calculates the increments ΔVmRSS and ΔVmSize; checks if they exceed the thresholds; if the increments exceed the preset thresholds, an alarm is triggered. The growth of VmRSS and VmSize is saved in the corresponding log files.

[0067] Example 2

[0068] This Example 2 details a method for monitoring process physical memory residency and virtual memory usage. This method operates on a process-by-process basis, providing a closer look at underlying resource usage; it supports lightweight and rapid diagnosis, making it suitable for investigating memory leaks or abnormal memory growth; it does not rely on systemd, has strong compatibility, and is applicable to various Linux environments. Combined with... Figure 2 As shown, this method monitors the processes with the highest memory usage in the system in real time (Top 10 by default), supporting two modes: one is an instant snapshot, displaying the current memory usage of each process; the other is growth detection, which calculates the memory growth rate after a specified time interval to identify potential memory leaks. The specific operation is as follows: First, initialize the memory monitoring class, such as... Figure 2 As shown, the defined class `classMemoryMonitor` is like a template. The class implements various functions for memory monitoring. To use the functionality of this class, an instance of the class needs to be created, which is the initialization process.

[0069] The command-line arguments, specifically the `skip_services` parameter, are parsed and split into sets for quick lookup. This involves using `.split(',')` to split the string into lists by commas: for example, "dbus,systemd,docker" → ['dbus', 'systemd', 'docker']. Then, a generator expression is used to remove leading and trailing spaces from each name. In other words, when the program starts, it receives a string argument like "dbus,systemd", indicating which services do not need to be monitored. We need to split this string by commas to get individual service names and store them in a set. This allows for very quick determination of whether each process belongs to the "services to skip" category later.

[0070] Set the `check_interval` and `top_count` parameters, with default values ​​of 0 and 10 respectively. This sets the maximum number of outputs per memory increment, i.e., the preset threshold.

[0071] Get all valid process directories: Traverse all entries under the / proc directory and keep only the PIDs of valid directories in numeric form.

[0072] Perform checks and information extraction on the directory of each valid PID: read / proc / <pid>The / status file contains VmSize and VmRSS.

[0073] Read / proc / <pid> / comm or / proc / <pid>The Name field in / status gets the process name. If the process name is in skip_services, the process is ignored.

[0074] Collect all valid process snapshots: call the corresponding method for all valid PIDs corresponding to the process, if successful collection, record the valid process snapshot, if failed, skip the process, and finally generate a ProcessSnapshot object list.

[0075] Sort the process of the ProcessSnapshot object list in descending order according to VmRSS, and take the top_count (default 10) processes as monitoring objects.

[0076] Growth rate calculation: determine whether check_interval is set, if set, check_interval is greater than 0, record the initial memory snapshot, wait for check_interval seconds, then reacquire the memory information of the same process, calculate the memory usage increment ΔVmRSS and ΔVmSize between the two sampling, and evaluate the memory growth trend; if check_interval is not set, directly output the current state.

[0077] Format output each line of data: adjust the output format according to whether there is check_interval, specifically, if there is no time interval, directly print the memory usage of the current Top process; if there is a time interval, format the results and write them to a log file, including the increment information.

[0078] Finally output the result to the log file or print: write the final result to the process_log file.

[0079] Application Example 1

[0080] The method described in Example 1 is used to dynamically monitor the memory used by services, which includes the following steps:

[0081] Step S1: receive user command line parameters.

[0082] Step S2: initialize the predefined key service list, the system has a predefined key system service list, which contains common and resource sensitive core daemon processes in the operating system.

[0083] Step S3: get the current running service set, parse the output, extract all service names currently in active (running) state, and form a running service set.

[0084] Step S4: Screening the base service set Base_Service_Set, specifically by calculating the intersection of the predefined service list and the running service set.

[0085] Step S5: Processing the user-added service (-a parameter), determining whether the -a <service_name> parameter is used: if not, the final monitoring set Final_Service_Set = Base_Service_Set;

[0086] If the parameter is used, check whether the service exists in Running_Services: if yes, add it to Final_Service_Set; if not, ignore the service and record a log prompt.

[0087] Step S6: Determining the sampling time interval, determining whether the -t parameter is set: if yes, check_interval = t; if not, check_interval = 300s;

[0088] Step S7: Traversing each service and obtaining the associated processes.

[0089] Step S8: Collecting initial memory data (t0).

[0090] Step S9: Waiting for the sampling interval.

[0091] Step S10: Re-collecting memory data (t1).

[0092] Step S11: Calculating the memory growth, calculating for each process: ΔVmRSS = VmRSS(t1) - VmRSS(t0); ΔVmSize = VmSize(t1) - VmSize(t0); aggregating the memory growth of the processes associated with the same service to obtain the memory growth of the service.

[0093] Step S12: Generating and outputting the monitoring log.

[0094] Application Example 2

[0095] The method described in Example 2 is used to dynamically monitor the memory used by the processes, specifically including the following steps:

[0096] Step Sa: Starting the process monitoring mode, which is enabled by default by the system or triggered explicitly by the user.

[0097] Step Sb: Traversing the / proc directory to identify all processes, determining whether they are valid process directories.

[0098] Step Sc: filter out invalid or kernel processes.

[0099] Step Sd: collect memory information of each process.

[0100] Step Se: filter out processes specified by user to ignore.

[0101] Step Sf: sort by memory usage and take top N.

[0102] Step Sg: determine whether to perform trend analysis, check whether check_interval > 0 is set:

[0103] If not, only output the current snapshot, and enter step Sj; if yes, enter the growth detection process, and enter step Sh.

[0104] Step Sh: wait for a sampling interval and re-collect.

[0105] Step Si: calculate memory growth.

[0106] Step Sj: generate monitoring result output.

[0107] Step Sk: end process monitoring.

[0108] In summary, the present application overcomes the limitations of existing general memory analysis tools (such as smem, ps, top) in system-level service monitoring and key process behavior analysis, and provides a lightweight, efficient, configurable, and trend analysis supporting dual-mode memory monitoring method and system. The system of the present application can not only realize dynamic tracking of the overall memory usage of key systemd services, but also can quickly diagnose and identify the growth trend of the processes with the highest memory usage, thereby meeting the actual needs of fine and automated observation of resource behavior at the service and process levels in operating system operation and maintenance, performance tuning and fault troubleshooting.

[0109] The present application provides a dual-mode memory monitoring scheme integrating "service-level dynamic monitoring" and "process-level trend diagnosis", which overcomes the deficiencies of existing tools (such as smem) in monitoring granularity, trend analysis, configurability, automation and ease of use. The present application realizes memory aggregation and dynamic tracking at the systemd service level; provides memory growth rate analysis capability of top processes; supports user-defined monitoring range (-a) and filtering of irrelevant processes (skip_services), improving flexibility; in addition, default behaviors (such as 5-minute sampling and top 10 output) are set to reduce the use threshold; and structured logs are output to support automated operation and maintenance and long-term trend analysis.

[0110] Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.< / pid> < / pid> < / pid> < / pid> < / pid> < / service> < / pid> < / pid> < / service> < / pid> < / pid> < / pid>

Claims

1. A method for dynamically monitoring memory usage based on services and processes, characterized in that, It includes monitoring physical memory residence and virtual memory usage of services and monitoring physical memory residence and virtual memory usage of processes, wherein, The monitoring physical memory residence and virtual memory usage of services includes the following steps: obtaining all processes associated with a service by parsing systemctl status, directly monitoring VmRSS and VmSize of processes associated with the same service and aggregating, or collecting VmRSS and VmSize of processes associated with the same service at twice before and after a sampling time interval and calculating the difference between the two values and aggregating, to realize the statistics of the overall memory usage of a single service; The monitoring physical memory residence and virtual memory usage of processes includes the following steps: starting process monitoring mode, directly monitoring VmRSS and VmSize of effective processes, or collecting VmRSS and VmSize of effective processes at twice before and after a sampling time interval and calculating the difference between the two values, to realize the statistics of the memory usage of each process; The VmRSS is the physical memory residence, which represents the total size of pages of a process table that have been mapped to the physical memory, including the code segment, data segment, heap, stack, and the part of the shared library that has been loaded into the physical memory, and excluding the pages that have been swapped out to the swap, the mmap region that has not been loaded into the memory, and the virtual memory that has been allocated but not used; The VmSize is the virtual memory occupation, which represents the size of the entire virtual address space of each process, including the code segment, data segment, heap, stack, memory mapping region, shared library, and memory allocated by malloc() but not used; The monitoring physical memory residence and virtual memory usage of services includes the following steps: Step S1: receiving user command line parameters; Step S2: initializing a predefined key service list; Step S3: screening services in an active state from the predefined key service list as a monitoring service set; Step S4: determining a sampling time interval, judging whether the user sets the -t parameter through the command line parameter, if yes, the time interval is the parameter set by the user, if not, the time interval is the system default parameter; Step S5: traversing each service in the monitoring service set and obtaining associated processes; Step S6: collecting initial memory data of each associated process, the initial memory data including VmRSS(t0) and VmSize(t0); Step S7: waiting for the sampling time interval; Step S8: re-collecting memory data (t1) of each associated process, including VmRSS(t1) and VmSize(t1); Step S9: calculating memory growth, calculating ΔVmRSS = VmRSS(t1) - VmRSS(t0) and ΔVmSize = VmSize(t1) - VmSize(t0) for each process, and aggregating the memory growth of processes associated with the same service to obtain the memory growth of the service; Step S10: generating and outputting a monitoring log; Wherein, VmRSS(t0) and VmSize(t0) are initial physical memory resident quantity value and virtual memory occupation quantity value respectively, VmRSS(t1) and VmSize(t1) are physical memory resident quantity value and virtual memory occupation quantity value after interval sampling time interval t respectively.

2. The method of claim 1, wherein, The command line parameters obtained in step S1 include a custom service added by the user through -a <service_name>.

3. The method of claim 2, wherein, After step S3, the following step is included: processing the user-added service, and judging whether the -a <service_name> parameter is used: If yes, the services in the active state are filtered from the custom service, and are added to the monitoring service set.

4. The method of claim 3, wherein, The command line parameters obtained in step S1 also include the memory increment threshold of the service, which is used to judge whether the memory increment needs to trigger an alarm in the subsequent memory monitoring process.

5. The method of claim 1, wherein the method further comprises: The monitoring of the physical memory resident and virtual memory usage of the process includes the following steps: Step Sa: starting the process monitoring mode, the system enables the process monitoring by default, or is triggered by the user explicitly; Step Sb: traversing the / proc directory to identify all processes, and judging whether it is a valid process; Step Sc: filtering invalid processes, kernel processes and user-specified ignored processes; Step Sd: for the filtered processes, sorting by memory occupation and taking the processes with the top pre-determined memory occupation as the to-be-detected processes; Step Se: collecting the memory information of each to-be-detected process; Step Sf: judging whether to perform trend analysis by checking whether check_interval > 0 is set: If no, only output the current memory information of the to-be-detected process, and enter step Si; if yes, enter the growth detection flow, and enter step Sg; Step Sg: waiting for the sampling time interval and re-collecting the memory information of each to-be-detected process; Step Sh: calculating the memory growth based on the collection results of step Se and step Sg; Step Si: generating the monitoring result output, and ending the process monitoring.

6. The method of claim 5, wherein the method further comprises: In step Sc, the skip_services parameter set by the user is used to filter the user-specified ignored processes.

7. The method of claim 5, wherein the method further comprises: Step Sa also includes setting the output memory increment highest output number.

8. The method of claim 5, wherein the method further comprises: Step Se collects memory information of each process to be detected, including reading / proc / <pid> / status file to get VmSize and VmRSS, read / proc / <pid> / comm or / proc <pid>The Name field in / status obtains the process name; wherein VmRSS is the physical memory resident quantity, and VmSize is the virtual memory occupation quantity.< / pid> < / pid> < / pid> 9. The method of claim 5, wherein the method further comprises: Step Si adjusts the output format according to whether check_interval > 0 is set: if check_interval > 0 is not set, directly print the current Top process memory usage; if there is a time interval, format the result and write it into a log file.

Images