Web interface-based Linux tuning profile inheritance chain analysis and parameter management method

Abstract

The application relates to a Linux tuning profile inheritance chain analysis and parameter management method based on a Web interface, and belongs to the technical field of Linux performance tuning. The method comprises the following steps: in response to a tuning configuration file query request, an inheritance chain of a target tuning configuration file is parsed and parameters are combined to generate a flattened parameter set; in response to a parameter comparison request, parameters from a first tuning configuration source and parameters from a second tuning configuration source are structurally compared, difference parameters are identified, and difference data is generated; and in response to a real-time monitoring data request, system operation indexes are collected by directly reading a kernel virtual file system and are stored in a ring buffer. The Linux performance tuning is realized.

Description

Technical Field

[0001] This invention relates to the field of Linux performance tuning technology, and in particular to a method for parsing and managing Linux tuning profile inheritance chains and parameters based on a web interface. Background Technology

[0002] In Linux server operations and maintenance, system tuning is a crucial operation to ensure performance meets standards under different business loads. Red Hat's tuned framework uses a Profile mechanism to centrally manage low-level configurations such as kernel parameters, CPU scheduling, and disk I / O, and supports dynamic switching. Since RHEL / CentOS 6.3, tuned has been widely integrated and has become a mainstream system tuning tool in the Linux ecosystem.

[0003] Currently, tuned primarily interacts with administrators through the local command-line tool tuned-adm and the local graphical interface tuned-gui. tuned-adm outputs human-readable plain text with no structured data interface; tuned-gui relies on the X11 / Wayland desktop environment and cannot be used on servers without a graphical interface. Profiles support multi-level inheritance, but tuned does not provide calculation of final effective parameters or inheritance chain lookup. Parameter differences between different profiles require manual comparison of each item in the configuration file; there is no built-in verification method for switching profiles, and administrators can only monitor the changes manually using external commands; switching operations do not record the previous state and cannot be automatically rolled back; and the core files lack integrity checks.

[0004] In summary, the existing tuned framework suffers from several drawbacks. First, its closed interaction mechanism prevents remote, visual invocation. Second, its unstructured output leads to fragile automated program parsing and high maintenance costs. Third, multi-level inheritance necessitates manual, layer-by-layer parameter tracing, which is inefficient and error-prone. Fourth, the lack of automatic profile difference detection makes manual cross-comparison time-consuming and difficult to pinpoint discrepancies. Fifth, the absence of optimization effect verification functionality means external monitoring commands incur additional performance overhead, and misaligned timestamps prevent the creation of a unified system status view. Sixth, the lack of stateful persistence and atomic rollback mechanisms for switching operations results in high configuration drift risks and difficulty in ensuring consistency in concurrent scenarios. Seventh, the lack of integrity protection for tool files poses a security risk of execution after tampering. These shortcomings limit the effective application of tuned in automated operations and maintenance, large-scale cluster management, and high-reliability production environments. Summary of the Invention

[0005] Based on the above analysis, the present invention aims to provide a web-based method for parsing the inheritance chain and managing parameters of Linux tuning profiles, in order to solve the problems of existing tuned framework tuning and maintenance being highly dependent on inefficient manual operations, unable to support remote automation and large-scale cluster management, and having configuration drift and security risks.

[0006] This invention provides a web-based method for resolving Linux tuning profile inheritance chains and managing parameters, comprising the following steps: Receive structured data requests from browser clients via built-in web services; In response to a tuning configuration file query request, the inheritance chain of the target tuning configuration file is parsed and the parameters are merged to generate a flattened parameter set and an inheritance chain order list; the flattened parameter set includes the final effective value of each parameter and its source configuration file information; In response to a parameter comparison request, the parameters from the first optimization configuration source and the parameters from the second optimization configuration source are compared in a structured manner to identify the differences and generate difference data; the difference data includes the location information of the differences in the original output text. In response to real-time monitoring data requests, system operation metrics are collected by directly reading the kernel virtual file system and the metric data is stored in a circular buffer; The response result is returned to the browser client, and the browser client performs visualization rendering based on the response result.

[0007] Furthermore, the flattened parameter set and inheritance chain order list are encapsulated into structured response data and returned to the browser client as the response result; When the browser client receives a structured, flattened set of parameters, the browser client categorizes and displays the parameters according to their types, and displays the parameter name, the final effective value of the parameter, and the identification information of the source configuration file for each parameter; When the browser client receives the inheritance chain order list, it graphically displays the inheritance relationship between the various tuning configuration files based on the inheritance chain order list.

[0008] Furthermore, when the parameter comparison request is a comparison between two tuning configuration files, the first tuning configuration source is the first tuning configuration file, and the second tuning configuration source is the second tuning configuration file; when the parameter comparison request is a comparison between the current system parameters and the target tuning configuration file, the first tuning configuration source is the parameters actually running in the current system, and the second tuning configuration source is the target tuning configuration file.

[0009] Furthermore, the difference data is generated in the following way: Based on the parameter comparison request, obtain the first parameter dictionary and the second parameter dictionary; A structured comparison is performed item by item between the first parameter dictionary and the second parameter dictionary to identify and classify the differing parameters; For each difference parameter, the position of the difference parameter is matched in the corresponding original output text to generate positioning information including line number and character offset; All difference parameters, their difference types, current values, target values, and location information are structured and encapsulated to obtain difference data.

[0010] Furthermore, if the parameter comparison request is for a first tuning configuration file and a second tuning configuration file, then the first parameter dictionary includes the flattened parameter set of the first tuning configuration file; the second parameter dictionary includes the flattened parameter set of the second tuning configuration file. If the parameter comparison request is between the current system parameters and the target tuning configuration file, the first parameter dictionary obtains the parameter key-value pairs actually running in the current system by directly reading the kernel virtual file system; the second parameter dictionary includes the flattened parameter set of the target tuning configuration file.

[0011] Furthermore, the difference parameters include a parameter name, a current value in a first parameter dictionary, a target value in a second parameter dictionary, and a difference type identifier; the difference parameters are identified and classified in the following ways: Get the union of all keys in the first parameter dictionary and all keys in the second parameter dictionary. Iterate through each parameter name in the union and execute: If the parameter name exists in the second parameter dictionary but not in the first parameter dictionary, it is marked as a new parameter; If the parameter name exists in the first parameter dictionary but not in the second parameter dictionary, it is marked as a deleted parameter; If the parameter name exists in both the first and second parameter dictionaries, but the parameter values ​​are different, it is marked as a changed parameter. If the parameter name exists in both the first and second parameter dictionaries and the parameter value is the same, it is marked as an indifferent parameter and is not included in the difference results.

[0012] Furthermore, after receiving the structured difference data, the browser client highlights the parameter values ​​of the difference parameters in the display area of ​​the browser client with different colors, based on the line number and character offset start and end positions in the positioning information.

[0013] Furthermore, the method also includes: In response to a tuning configuration file switching request, the system tuning configuration is switched to the specified target tuning configuration file, and the persistent state record is updated after the switch is completed. The persistent state record includes the state before the switch and the state after the switch.

[0014] Furthermore, the method also includes: In response to the rollback request, the system tuning configuration is restored to the state before the tuning configuration file switching operation was performed, and the rollback result is returned after the rollback operation is completed.

[0015] Furthermore, the persistent state record also includes a rollback state identifier; when a rollback request is received, the validity of the persistent state record is verified, and after confirming that the current system state is consistent with the state after the switch in the persistent state record, the operation of restoring the system parameters to the state before the switch is performed, and the rollback state identifier is updated.

[0016] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects: This invention provides a web-based method for parsing the inheritance chain and managing parameters of Linux tuning profiles. By building a web service, it provides remote tuning management capabilities with a graphical and structured data interface, allowing maintenance personnel to perform tuning operations through a browser without relying on command-line text parsing. This completely solves the vulnerability of automated parsing caused by the unstructured output of tuned-adm. By parsing the multi-level inheritance relationship of the profile through the inheritance chain and outputting a flat parameter set with source annotations, the original process of manually tracing each layer is transformed into an automated process, allowing administrators to know the final value of each parameter without opening the configuration file. Effective values ​​and their source profiles; through structured parameter comparison and character-level positioning technology, the difference detection process, which originally required manual line-by-line cross-comparison of configuration files, is transformed into automatic system completion and precise highlighting of difference locations, significantly reducing the time consumption of manual comparison and avoiding omissions; through visual monitoring of system status information, system operation indicators are presented in the form of dynamic chart rendering, allowing administrators to view the performance changes after optimization without repeatedly logging into the server, intuitively demonstrating the impact of optimization operations on the system; at the same time, by directly reading monitoring data collected from the kernel virtual file system and storing it in a circular buffer, the system overhead of child process creation in traditional external command monitoring methods is eliminated.

[0017] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0018] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0019] Figure 1 This is a flowchart illustrating the Linux tuning profile inheritance chain parsing and parameter management method based on a web interface provided in this embodiment of the invention. Detailed Implementation

[0020] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0021] A specific embodiment of the present invention discloses a method for resolving Linux tuning profile inheritance chain and managing parameters based on a web interface, such as... Figure 1 As shown, it includes: S1. Receive structured data requests from browser clients via built-in web services; S21. In response to the tuning configuration file query request, parse the inheritance chain of the target tuning configuration file and merge the parameters to generate a flattened parameter set and an inheritance chain order list; the flattened parameter set includes the final effective value of each parameter and its source configuration file information; S22. In response to the parameter comparison request, perform a structured comparison between the parameters from the first optimization configuration source and the parameters from the second optimization configuration source, identify the differences in parameters, and generate difference data; the difference data includes the location information of the differences in parameters in the original output text; S23. In response to a real-time monitoring data request, collect system operation metrics by directly reading the kernel virtual file system and store the metric data in a circular buffer; S3. The response result is returned to the browser client, and the browser client performs visualization rendering based on the response result.

[0022] Those skilled in the art will understand that steps S21, S22, and S23 are specific operations in response to a structured request, and there is no necessary sequential relationship between the steps; they are merely step identifiers.

[0023] It should be noted that the method in this embodiment adopts a layered architecture, which separates system interaction, business logic and underlying command calls. The browser client communicates with the server through a structured data interface, the server business logic is responsible for parameter parsing, difference comparison and rollback management, and the underlying interaction encapsulates the calls to the tuning framework and kernel interface.

[0024] Specifically, the browser client is implemented using HTML5, CSS3, and JavaScript. The required chart components, styles, and script static resources are all packaged and distributed locally with the system, without relying on external content delivery networks or internet resources, and can run directly in an offline server environment.

[0025] Specifically, the built-in web service is built on the standard library of the programming language. By default, the service is only bound to the local loopback address (127.0.0.1 for IPv4 and ::1 for IPv6), and rejects connection requests from any external network interface. The operating system network stack will discard all TCP SYN packets sent from the external network to this port, ensuring that the tuning and management interface can only be accessed by the browser on the server itself. The server listens on port 8000 by default, and the port number can be flexibly modified through command-line parameters.

[0026] Understandably, by default, only the local loopback address is bound, which can provide the highest level of security protection during initial deployment and prevent the optimization management interface from being exposed to the external network if it is not configured properly. When the administrator has remote access needs, external access capability can be enabled by modifying the listening address parameter.

[0027] More specifically, the HTTP server is directly instantiated as a built-in web service using the Python standard library http.server.ThreadingHTTPServer, without relying on any third-party web framework, thus avoiding the introduction of additional dependencies and potential security vulnerabilities.

[0028] Specifically, the built-in web service employs a multi-threaded concurrent processing model. Each received HTTP request is processed by a separate worker thread, enabling concurrent service for multiple requests. In a local listening scenario, the number of threads depends on the number of simultaneous requests. The TCP connection queue's backlog parameter limits the upper limit of concurrent connections; connections exceeding the backlog are rejected by the system kernel, and no threads are created if there are no connections. Threads automatically terminate after HTTP connection timeouts, thus eliminating the risk of unlimited thread growth.

[0029] Specifically, the built-in web services include a request route dispatcher, a user authentication middleware, and a session management module. When a user visits for the first time, they need to submit an administrator password on the front-end login page. The back-end calls the system's authentication capabilities to verify the user's identity. After successful authentication, a session credential (Session Cookie) based on an HMAC-SHA256 signature is issued. All subsequent API requests must carry this credential, and the authentication middleware verifies its validity and signature integrity.

[0030] More specifically, the request route dispatcher is implemented by a custom request handling class that inherits from BaseHTTPRequestHandler. In the do_GET and do_POST methods, it parses the request path self.path and dispatches the request to the corresponding business processing function based on the path prefix.

[0031] More specifically, the authentication middleware is called before each API processing function that requires authentication is executed. Its verification logic is as follows: extract the session_token field from the request cookie, read the session payload and recalculate the HMAC-SHA256 signature, and compare it with the signature stored on the server. If the verification is successful, check whether the session is within the validity period. If it is within the active period, it will be automatically renewed, that is, the expiration time will be extended, and the cookie will be updated in the response. If the verification fails, an HTTP 401 Unauthorized status code will be returned, and the frontend will automatically redirect to the login page upon receiving the status code.

[0032] Furthermore, to prevent brute-force attacks, the authentication middleware implements a frequency limit on login attempts, maintaining a failed attempt counter based on the client's IP address. When the same IP fails more than 5 times consecutively within 5 minutes, subsequent login requests are directly rejected and a 403 Forbidden response is returned until the lockout window expires. Administrators can adjust the maximum number of attempts and the lockout duration through configuration files.

[0033] Specifically, the built-in web service automatically adds security headers to each HTTP response, including: Content-Security-Policy is used to restrict the source of page resources and prevent cross-site scripting (XSS) attacks. X-Content-Type-Options: nosniff is used to disable browser MIME type sniffing; X-Frame-Options: DENY is used to prevent pages from being embedded in iframes, thus preventing clickjacking attacks.

[0034] More specifically, the built-in web service performs strict validation on all user input. File path parameters are validated to ensure they do not contain ".." to prevent path traversal attacks. For command parameters that need to be concatenated, shlex.split() is used for secure splitting and shell=False is forced to prevent command injection attacks. All input parameters are subject to length limits and character set whitelist filtering to reject unexpected input.

[0035] Specifically, all data interactions between the browser client and the built-in web services use the RESTful HTTP protocol, with both request and response bodies encapsulated in JSON format. The browser client proactively initiates structured requests via the Fetch API or XMLHttpRequest object; structured request types include: optimization configuration file query requests, parameter comparison requests, real-time monitoring data requests, state switching requests, and optimization rollback requests.

[0036] More specifically, the configuration file query request includes requests for a list of configuration files, parameter details of a specified configuration file, and inheritance chain information; the parameter comparison request includes requests for comparisons between two configuration files, or between the current system parameters and the target configuration file parameters; the real-time monitoring data request includes requests for the current values ​​and historical trend data of system operating metrics such as CPU, memory, network, and disk; the configuration file switching request includes requests to switch the system configuration to a specified target configuration file; and the configuration rollback request includes requests to revert the system configuration to its state before the switch, carrying the verification information required for the rollback operation. It should be noted that the browser client polls for real-time monitoring data every 2 seconds by default.

[0037] During implementation, in step S21, in response to the tuning configuration file query request, the inheritance chain of the target tuning configuration file is parsed and the parameters are merged, including: S211. Starting from the target tuning configuration file, trace upwards layer by layer to the parent configuration files it references, until the root tuning configuration file, to generate a complete inheritance chain order list.

[0038] In practice, a complete inheritance chain order list is generated in the following way: a1. Based on the name of the current tuning configuration file, search for the corresponding tuning configuration file in the order of priority of the preset configuration file directory list, and determine the current valid configuration file. The configuration file directory list includes at least two configuration directories with different priorities (e.g., the user-level configuration directory has higher priority than the system-level configuration directory) to support user-defined configurations overriding the system default configuration. The first existing and unprocessed configuration file found is determined as the current valid configuration file. If a configuration file with the same name has been processed in a higher priority directory, and then a configuration file with the same name appears again in a lower priority directory, then the configuration file with the same name is not directly judged as a circular reference, and loading configuration files with the same name in different directories is allowed. a2. Extract all parent configuration file references from the currently valid configuration file. Expand the variables and built-in functions of the parent configuration file references and divide them according to the preset delimiter to obtain the parent configuration file name sequence. If the current configuration file contains multiple parent references, all of them are included in the tracing scope, forming a multi-parent inheritance. According to the declaration order in the parent configuration file name sequence, recursively execute steps a1 to a2 for each referenced parent configuration file, tracing upwards layer by layer until a root tuning configuration file that meets the preset root condition is encountered. When a parent configuration file has a conditional loading flag and there is no corresponding valid configuration file, skip the parent without stopping the parsing. When a normal parent configuration file does not have a corresponding valid configuration file, terminate the parsing and return an exception message. a3. Arrange all the tuning configuration files accessed during the tracing process in the order from the root tuning configuration file to the target tuning configuration file, generating a complete inheritance chain order list. When there are multiple parent configuration file branches, merge and deduplicate the tracing results of each branch, then arrange them uniformly in the order from root to target. For multiple parent configuration files belonging to the same level, arrange them according to the order in which they appear in the parent references of the target configuration file.

[0039] Specifically, the default separator can be set to a comma or a semicolon.

[0040] Specifically, the preset root conditions include: there are no parent configuration file references in the tuning configuration file; the tuning configuration file already exists in the current trace path.

[0041] Specifically, a maximum recursion depth limit is set during the tracing process. When the tracing depth exceeds this limit, the inheritance relationship of the configuration file is determined to be abnormal, parsing is terminated, and an error message is returned to prevent infinite recursion or stack overflow caused by user configuration errors. More specifically, the maximum recursion depth limit is set according to the actual use case; for example, the maximum recursion depth limit is set to 10 levels, which can cover all reasonable configurations while reserving fault tolerance space for abnormal configurations.

[0042] Specifically, a hash set is used to record the names of the accessed tuning profiles; whenever a new tuning profile is traced, it is checked whether the name of the tuning profile already exists in the hash set; if it does, it is determined that there is a circular reference in the inheritance chain, the resolution is terminated immediately and an error message containing circular path information is returned.

[0043] Furthermore, before locating and reading the tuning configuration file, it verifies whether the name of the current tuning configuration file is within the preset list of legal configuration files, and refuses to read any configuration files located outside the system configuration directory and user configuration directory, in order to prevent path traversal or unauthorized reading of unexpected configuration files.

[0044] S212. According to the inheritance chain order list, merge parameters layer by layer from the root tuning configuration file to the target tuning configuration file, wherein the parameter with the same name in the later tuning configuration file overrides the parameter value in the previous tuning configuration file.

[0045] In practice, parameters are merged layer by layer in the following manner: Based on the inheritance chain order list, starting from the root tuning configuration file, the parameter key-value pairs of each tuning configuration file are read layer by layer towards the target tuning configuration file, and a merged parameter dictionary is maintained. For each pair of parameter key-value pairs, perform the following merge rule: If the current parameter name does not exist in the merged parameter dictionary, then the parameter name and its value are directly stored in the merged parameter dictionary; If the current parameter name already exists in the merge parameter dictionary, then the current parameter value will overwrite the existing value in the merge parameter dictionary.

[0046] Specifically, a source configuration file field is maintained for each parameter in the merge parameter dictionary; when a parameter is overridden by the current layer, the source configuration file field of that parameter is synchronously updated to the name of the configuration file of the current layer.

[0047] Preferably, for tuning configuration files containing plug-in unit configurations, the configuration section name is used as the unit identifier for merging: When a new plug-in unit is set to a global replacement flag (e.g., replace=1), the existing unit with the same name will be replaced entirely by the new plug-in unit. When no overall replacement flag is set, update the type, enable status and device expression of the unit with the same name, and update the corresponding old values ​​with the non-empty priority, device matching regular expression, processor information regular expression, kernel version regular expression, pre-script and post-script in the new unit; For script-based configuration units, new scripts are appended to the existing script sequence in the order they are loaded. For regular options, the new value overwrites the old value with the same name, and old options that do not conflict are retained; before updating regular options, delete the existing options specified in the option deletion list.

[0048] After the merge is complete, a merged tuning configuration file is generated that is consistent with the target version of the TuneD loader.

[0049] S213. The merged parameter values ​​are used as the final effective values ​​of the parameters, and the identifier of the source configuration file is marked for each final effective value of the parameters to obtain a flattened parameter set.

[0050] Specifically, the flattened parameter set is a structured data format, with each parameter including a parameter name, the final effective value of the parameter, and the name of the source configuration file.

[0051] Optionally, the flattened parameter set also includes the original definition line number of each parameter in the tuning configuration file.

[0052] During implementation, the flattened parameter set and inheritance chain order list are encapsulated as structured JSON response data and returned to the browser client as the response result. In essence, the generated complete inheritance chain order list is appended to the response data, allowing the browser client to view the full picture of the inheritance relationship and enabling administrators to intuitively understand the hierarchical origin path of the parameters.

[0053] During implementation, when the browser client receives the structured, flattened parameter set, the browser client categorizes and displays the parameters according to their types, and displays the parameter name, the final effective value of the parameter, and the identification information of the source configuration file for each parameter; When the browser client receives the inheritance chain order list, it graphically displays the inheritance relationship between the various tuning configuration files based on the inheritance chain order list.

[0054] Specifically, the browser client displays the inheritance relationship between various tuning configuration files in a tree structure diagram according to the inheritance chain order list. The root tuning configuration file is located at the top level, and the child tuning configuration files are located at the lower level of the parent tuning configuration files they reference. Each configuration file node displays the name of the configuration file and the number of parameters contributed by the configuration file. In response to the user's click operation on any configuration file node, the detailed parameter list of the configuration file and the final effective value of each parameter are displayed.

[0055] During implementation, step S21 also includes: after completing parameter merging, establishing a variable evaluation context according to the variable order in the merged variable unit, and expanding the device expression, processor information regular expression and kernel version regular expression of each plug-in unit; marking the options that still need to be evaluated by specific plug-ins at runtime as runtime pending, and obtaining the merged expected configuration; For each configuration addition, overwrite, overall replacement, explicit deletion, and script append operation, a bypass source record is generated. The bypass source record includes the Profile logical name, actual configuration file path, loading sequence number, plugin unit name, option name, original value, processed value, processing type, and previous source. The bypass source record does not participate in the Profile file selection, loading sorting, and configuration merging decisions.

[0056] Specifically, in step S22, when the parameter comparison request is a comparison between two tuning configuration files, the first tuning configuration source is the first tuning configuration file, and the second tuning configuration source is the second tuning configuration file; when the parameter comparison request is a comparison between the current system parameters and the target tuning configuration file, the first tuning configuration source is the parameters actually running in the current system, and the second tuning configuration source is the target tuning configuration file.

[0057] During implementation, in step S22, in response to the parameter comparison request, difference data is generated in the following manner: S221. Based on the parameter comparison request, obtain the first parameter dictionary and the second parameter dictionary; In practice, if the parameter comparison request is for the first tuning configuration file and the second tuning configuration file, then The first parameter dictionary includes a flattened parameter set of the first tuning configuration file; it is obtained by performing the inheritance chain resolution step as in step S21 on the first tuning configuration file. The second parameter dictionary includes a flattened parameter set of the second tuning configuration file; it is obtained by performing the inheritance chain resolution step as in step S21 on the second tuning configuration file.

[0058] In practice, if the parameter comparison request is for the current system parameters and the target tuning configuration file, then... The first parameter dictionary obtains the key-value pairs of parameters that are actually running in the current system by directly reading the kernel virtual file system; system running parameters include reading various kernel parameter files under the / proc / sys / directory, as well as CPU scheduling policies, transparent big pages, platform power saving configuration system status parameters under the / sys / directory through system calls or reading. The second parameter dictionary includes a flattened parameter set of the target tuning configuration file; it is obtained by performing the inheritance chain resolution step as in step S21 on the target tuning configuration file.

[0059] Preferably, both the first parameter dictionary and the second parameter dictionary are key-value pair structures with parameter names as keys and parameter values ​​as values.

[0060] Specifically, during the acquisition of the parameter dictionary, the analyzer automatically expands to flexibly parse different data source formats. Specifically, when the system starts, it automatically scans all analyzer modules in the specified directory, identifies and registers the analyzers that implement the preset interface specifications. After collecting system data, it automatically matches and schedules the corresponding analyzer for data processing based on the data source type using a dual strategy of exact matching and prefix matching, converting the original acquisition results into a unified parameter dictionary format.

[0061] S222. Perform a structured comparison of each item in the first parameter dictionary and the second parameter dictionary, identify the differences in parameters, and classify them.

[0062] Specifically, the difference parameters include the parameter name, the current value in the first parameter dictionary, the target value in the second parameter dictionary, and the difference type identifier.

[0063] Specifically, the differential parameters are identified and classified in the following ways: Get the union of all keys in the first parameter dictionary and all keys in the second parameter dictionary. Iterate through each parameter name in the union and execute: If the parameter name exists in the second parameter dictionary but not in the first parameter dictionary, it is marked as a new parameter; If the parameter name exists in the first parameter dictionary but not in the second parameter dictionary, it is marked as a deleted parameter; If the parameter name exists in both the first and second parameter dictionaries, but the parameter values ​​are different, it is marked as a changed parameter. If the parameter name exists in both the first and second parameter dictionaries and the parameter value is the same, it is marked as an indifferent parameter and is not included in the difference results.

[0064] S223. For each difference parameter, match the position of the difference parameter in the corresponding original output text to generate positioning information containing line number and character offset.

[0065] Specifically, the raw output text includes one or more of the following: multi-line text returned by executing a system parameter query command (such as sysctl -a), the original configuration file content of the target tuning configuration file, and the content read from the corresponding parameter file in the system kernel virtual file system (such as / proc / sys / ).

[0066] More specifically, matching the location of the difference parameter in the corresponding original output text, including: Get the original output text content where the difference parameter is located, and construct a regular expression that starts with the name of the difference parameter. Match the original output text line by line to locate the specific line number where the difference parameter is located. The line number starts counting from 0 or 1. Calculate the start and end positions of the character offset of the difference parameter within the line, and use the line number and the start and end positions of the character offset as the positioning information of the difference parameter.

[0067] For example, for a line vm.swappiness = 10 in the output of the sysctl -a command, if vm.swappiness is marked as a difference parameter, after matching the line, the line number (e.g., line 42) is recorded, and the start and end offsets of the character 10 within that line are calculated (e.g., start=16, end=18).

[0068] S224. All difference parameters, their difference types, current values, target values, and positioning information are structured and encapsulated to obtain difference data.

[0069] Specifically, structured difference data is used as the response result; the difference data is in JSON format, including the name of the difference parameter, the current value of the parameter in the first parameter dictionary, the target value of the parameter in the second parameter dictionary, the difference type identifier, the line number of the difference parameter in the original output text, the starting character offset of the difference parameter value within the line, and the ending character offset of the difference parameter value within the line.

[0070] Preferably, the difference data also includes difference summary information, which includes the total number of difference parameters, the number of newly added parameters, the number of deleted parameters, the number of changed parameters, and the difference distribution by parameter category; wherein, the parameter categories include CPU, memory, network, disk, and kernel general.

[0071] During implementation, after receiving the structured difference data, the browser client highlights the parameter values ​​of the difference parameters in the display area using differentiated colors based on the line numbers and the start and end positions of the character offsets.

[0072] More specifically, the browser client supports three highlighting modes based on the response results of the difference data: Inline character positioning: By using line numbers and the start and end positions of character offsets, the browser client can achieve precise character-level highlighting of difference parameter values. Field name location: Use the difference parameter name as the field key name to match the corresponding field in the structured output to achieve highlight location; Line-level highlighting: When the difference cannot be pinpointed to a specific character position, the entire line is highlighted using the line number.

[0073] More specifically, the first color is used to identify changed parameters; the second color is used to identify newly added parameters; and the third color is used to identify deleted parameters.

[0074] Preferably, when the same parameter appears in multiple original output texts, the browser client automatically selects the location information corresponding to the displayed content for highlighting based on the current display context.

[0075] Furthermore, during the parameter acquisition and display process, report enhancement processing is also performed, including: When system parameters cannot be read due to insufficient permissions, a visual entry containing an unreadable status indicator and highlight style information is generated. The visual entry is presented in a visual style that is different from that of normal parameters. When parameter value collection fails or is empty, the blank cell is replaced with a predefined placeholder and an uncollected status label is added to clearly distinguish between the two semantic states: empty parameter value and parameter value not collected.

[0076] Furthermore, in step S22, in response to a parameter comparison request, cache optimization is also included: The structured difference data generated in this comparison is cached in the server memory, and a unique comparison session identifier is generated. The unique comparison session identifier is returned to the browser client; When the browser client executes a request to switch the tuning configuration file, it carries a unique comparison session identifier. The server can then directly read the cached difference data based on this identifier, without having to re-execute the comparison and parsing.

[0077] Preferably, the cache is set with an expiration period. Cache data that has exceeded the expiration period is automatically invalidated and cleaned up to free up server memory resources.

[0078] Preferably, the identifiers of the two tuning configuration files in the comparison request are persistently recorded in the browser client's local storage, enabling the administrator to quickly initiate another comparison between the same two configuration files during subsequent accesses.

[0079] During implementation, in step S23, the real-time monitoring data request is initiated periodically by the browser client through a timer. Each time a request arrives, all data points in the circular buffer are serialized into a structured data format as a response result and returned to the browser client.

[0080] Preferably, the timer period is 2 seconds.

[0081] Specifically, system performance metrics include CPU utilization, memory utilization, network transmission and reception rate, and disk read / write rate.

[0082] In specific implementation, step S23, in response to a real-time monitoring data request, includes: Within the same acquisition cycle, multiple read tasks are executed concurrently through a thread pool to read the processor time statistics file, memory statistics file, network interface statistics file, and disk block device statistics file exposed by the kernel in parallel, and to calculate CPU utilization, memory utilization, network transmit / receive rate, and disk read / write rate respectively. System operation index data collected at the same time are treated as a single data point and stored in a circular buffer in chronological order, so that each index data has a unified timestamp reference.

[0083] Understandably, system performance metrics data are read simultaneously and share the same timestamp within the same collection period, ensuring that the curves of each metric are strictly aligned on the timeline when displayed later, thus avoiding data inconsistencies caused by different collection times of each metric.

[0084] In practice, CPU utilization is calculated by reading the cumulative CPU status data provided by the kernel and calculating the CPU utilization based on the difference between two samples, avoiding the execution of external monitoring commands; memory utilization is calculated by reading the memory statistics provided by the kernel to calculate total memory, available memory, and memory utilization, without the need to execute external memory viewing commands; network transmit / receive rate is calculated by reading the cumulative transmit / receive data of the network interface and calculating the network receive rate and transmit rate based on the sampling difference; disk read / write rate is calculated by reading the cumulative disk read / write statistics and calculating the disk read / write rate based on the sampling difference.

[0085] Specifically, CPU utilization is obtained by reading the cumulative jiffies value of the CPU in each state from the / proc / stat file. The total jiffies value is obtained by summing the jiffies values ​​of each state collected in this collection. The non-idle jiffies value is the total jiffies value minus the idle jiffies value. The CPU utilization is obtained by calculating the ratio of the difference between the non-idle jiffies value and the previous collection to the difference in the total jiffies value, thereby avoiding the execution of external monitoring commands.

[0086] Specifically, memory utilization is calculated by reading the / proc / meminfo file to extract the total memory and available memory fields. Memory utilization = (total memory) / (available memory) Available memory / Total memory × 100%, no need to execute external memory viewing commands.

[0087] Specifically, the network transmit and receive rates are obtained by reading the / proc / net / dev file to extract the cumulative number of bytes received and the cumulative number of bytes sent for the specified network interface, calculating the difference in the number of bytes received and the difference in the number of bytes sent between the current and previous data collection, and dividing by the data collection interval to obtain the network receive rate and the network transmit rate.

[0088] Specifically, the disk read and write speeds are obtained by reading the cumulative number of read sectors and the cumulative number of write sectors of the specified disk from the / proc / diskstats file, multiplying the number of read sectors and the number of write sectors by the sector size (e.g., 512 bytes) to convert them into bytes; calculating the difference in the number of read bytes and the difference in the number of write bytes between the current and previous collections, and dividing by the collection interval to obtain the disk read speed and disk write speed.

[0089] Specifically, the circular buffer is a fixed-capacity queue structure that adopts a first-in, first-out (FIFO) strategy; when the buffer is full, the newest data point overwrites the oldest data point.

[0090] Preferably, the ring buffer has a capacity of 900 data points, calculated at a 2-second acquisition interval, corresponding to the storage of trend data for the most recent 30 minutes. The capacity of the ring buffer can be adjusted via a configuration file according to actual monitoring needs.

[0091] More specifically, the data points in the circular buffer are JSON objects or structured tuples, including: collection timestamps, CPU utilization, memory utilization, network receive rate, network send rate, disk read rate, and disk write rate.

[0092] It's important to note that the circular buffer begins writing data continuously upon system startup, regardless of whether the browser client initiates a real-time monitoring data request. Real-time monitoring data collection and browser client polling requests are decoupled in time. The collection thread runs independently at fixed intervals, continuously writing data to the circular buffer. When the HTTP service thread responds to a browser client request, it directly reads the current content of the buffer and returns it. The collection cycle is unaffected by the frequency of browser client requests, ensuring the continuity and stability of data collection. When the browser client initiates its first real-time monitoring data request, it returns the historical data already stored in the buffer. This allows the browser client to display complete historical trends upon launching the monitoring page, avoiding incomplete chart rendering due to an empty buffer when the front-end page first starts.

[0093] Furthermore, for environments with multiple network interfaces or multiple disk devices, the network transmit / receive rate collection and disk read / write rate collection also support device selection: by default, the network interface that is active in the system (such as having an IP address and not being a loopback) is automatically selected for collection; by default, the disk device that is not virtual (such as not loop, not RAM, not DM-prefix) is automatically selected for collection; the administrator can manually specify the network interface name or disk device name to be monitored through the configuration file.

[0094] In implementation, the browser client uses a locally packaged charting library to draw line charts on HTML5 Canvas elements. Each time new data is received, only the newly added data points are appended to the existing chart, rather than redrawing all data points, achieving incremental updates. Specifically, the browser client uses the HTML5 Canvas element on the monitoring page to draw the system monitoring chart's internal processing logic in real time. Every 2 seconds, a GET request to ` / api / monitor` is initiated. The handler calls `MonitorCollector.collect()`, which in turn calls `_read_cpu_stat()` (reading ` / proc / stat`), `_read_mem_info()` (reading ` / proc / meminfo`), `_read_net_dev()` (reading ` / proc / net / dev`), and `_read_diskstats()` (reading ` / proc / diskstats`) in parallel to calculate the current value of each indicator and write it to a circular buffer (`history:deque maxlen=900`). Finally, the buffer data is serialized into JSON and returned to the browser client. The browser client then incrementally updates the Canvas line chart based on the returned data using the locally packaged `Chart.js` static file.

[0095] Specifically, the real-time monitoring data request also includes a specified time range parameter. The browser client carries the start and end times in the real-time monitoring data request. The built-in web service filters and returns data points within the corresponding time period from the circular buffer based on the time range, which is used to support historical trend review.

[0096] Understandably, in traditional monitoring solutions, data is collected by periodically executing external commands such as top, free, and iostat. Each execution requires fork+exec to create a child process, with a single overhead of about 5-10ms and CPU usage of about 2.5% at a 2-second sampling interval. However, this implementation completely eliminates the above-mentioned child process creation overhead by directly reading the kernel virtual file system.

[0097] Preferably, the method further includes a mechanism for handling abnormal monitoring data: When the value of a certain indicator remains unchanged in multiple consecutive data collection cycles, a zero value is reported normally. When the raw data for a certain indicator fails to be read (e.g., the file does not exist or permissions are insufficient), the system marks the current value of the indicator as invalid (e.g., -1 or null) and carries the invalid status identifier of the indicator in the returned data. The browser client displays the invalid status in the chart as a breakpoint or special marker based on the identifier, instead of using zero value to mislead the administrator.

[0098] In implementation, the method also includes: S24. In response to the tuning configuration file switching request, switch the system tuning configuration to the specified target tuning configuration file, and update the persistent state record after the switch is completed. The persistent state record includes the state before the switch and the state after the switch.

[0099] In practice, upon receiving a configuration file switching request, the built-in web service performs a validity check on the configuration file switching request before making the switch, including: The check verifies whether the target tuning configuration file name is empty or contains illegal characters. If so, the check fails and a message indicating that the configuration file is non-compliant is returned; otherwise, the check passes. Verify that the target tuning configuration file exists in the system's list of installed tuning configuration files. If not, the verification fails and a message indicating that the configuration file is non-compliant is returned; otherwise, the verification passes. Verify whether the current system's active tuning configuration file is the same as the target tuning configuration file; if so, the verification fails and a prompt indicating that no switching is needed is returned to avoid invalid operations; otherwise, the verification passes. The check verifies whether the path of the target tuning configuration file is within the preset range of the valid configuration file storage directory. If the target configuration file path contains ".." or is outside the range of the valid configuration file storage directory, the check fails to prevent path traversal or unauthorized reading of unexpected configuration files; otherwise, the check passes. If all checks pass, the configuration file switching request is deemed valid.

[0100] In practice, after receiving a request to switch the optimization configuration file, the built-in web service, before switching, also includes: generating difference data based on the parameters of the current system's actual operation and the target optimization configuration file, returning the difference data to the browser client, so that the administrator can preview the specific parameter changes that will occur before the switching operation is executed, and submit a confirmation switching request after confirming that there are no errors.

[0101] Specifically, using the same method as in step S22, difference data is generated based on the parameters of the current system operation and the target tuning configuration file.

[0102] Understandably, by previewing the differences before the switch, administrators can fully understand the impact of the switch before it is implemented, thus avoiding blind switching that could lead to unexpected changes in the production environment.

[0103] During implementation, after the user confirms the switch, the browser client initiates a confirmation request. The built-in web service responds to this confirmation request by invoking the switching command of the underlying tuning framework (such as tuned-adm profile<target configuration file name>) to switch the system tuning configuration to the specified target tuning configuration file.

[0104] During implementation, an idempotency check is performed before saving the state before the switch. If the name of the configuration file before the switch is the same as the name of the target configuration file, the existing persistent state records are automatically cleared and no new state records are saved to avoid the accumulation of invalid rollback states.

[0105] Specifically, the persistent state record includes the pre-switch state as the name of the configuration file before the switch, a snapshot of the key kernel parameters before the switch, the operation timestamp, the operator, and the operation source; the post-switch state includes the name of the configuration file after the switch; the persistent state record also includes a rollback state identifier.

[0106] Understandably, saving the state before the switch must be done after the switch operation is successfully executed, to ensure that rollback is only allowed after the switch has actually taken effect, and to avoid generating an invalid rollback state in the event of a switch failure.

[0107] In practice, after the switchover operation is completed, an audit log is recorded. The audit log includes: operation timestamp, operation user, operation type (switchover operation), the names of the tuning configuration files before and after the switchover, and a snapshot comparison of key kernel parameters before and after the switchover.

[0108] Specifically, persistent state records are stored using atomic write methods: The status data is first written to a temporary file. After the writing is completed and synchronized to the physical storage medium, the temporary file is renamed to the target status file. The target status file can only be accessed by privileged system users.

[0109] Understandably, atomic writing ensures that even if the system crashes abnormally during the writing process, no partially written corrupted state files will remain, thus guaranteeing the integrity and reliability of persistent state records.

[0110] During implementation, the switching result and the name of the currently effective tuning configuration file are encapsulated as structured response data and returned to the browser client. Upon receiving a successful response, the browser client renders the application based on the response.

[0111] Preferably, after the switching operation is successful, the browser client will also persistently store the name of the currently effective tuning configuration file locally, so that the administrator can quickly identify the tuning configuration currently used by the system when accessing it in the future.

[0112] In practice, after the switchover operation is completed, an audit log is recorded. The audit log is stored in a separate JSON format in an audit log file and is not mixed with the system syslog. The audit log file permissions are set to allow only privileged system users to read and write. Each audit log record includes: operation timestamp, operation user, client source IP address, operation type (switchover operation), optimization configuration file names before and after the switchover, and snapshot values ​​of key kernel parameters before and after the switchover. Among them, the key kernel parameters are a preset fixed parameter list. A snapshot of the parameters before the switchover is automatically collected before the switchover is executed, and a snapshot of the parameters after the switchover is automatically collected after the switchover is executed. Both of these, along with the operation record, are written to the audit log to provide quantitative evidence for subsequent analysis of optimization effects.

[0113] In implementation, the method also includes: S25. In response to the rollback request, restore the system tuning configuration to the state before the tuning configuration file switching operation was performed, and return the rollback result after the rollback operation is completed; including: When a rollback request is received, the validity of the persistent state record is verified. After confirming that the current system state is consistent with the state after the switch in the persistent state record, the system parameters are restored to the state before the switch, and the rollback state identifier is updated.

[0114] During implementation, the rollback status identifier is managed using a three-state machine, including: The first state, which indicates that the configuration file switching operation has been successfully executed, means that the system is currently in the new configuration state and the state information before the switch has been saved, allowing for rollback. The second state indicates that the rollback is in progress, meaning that the rollback operation is being executed. This is used to prevent concurrent rollback requests from causing state chaos. The third state, indicating rollback, signifies that the rollback operation has been successfully completed and the system has been restored to its pre-switch configuration state; among which... The state transition rules are as follows: rollback can only be performed when the state is the first state. When it is performed, the state will be transitioned to the second state. If the rollback is successful or fails, the state will be transitioned to the third state or restored to the first state, respectively.

[0115] More specifically, when responding to a rollback request, the following validations are performed: Read the rollback status flag in the local status file to confirm whether the current status is effective. If not, refuse the rollback. Obtain the name of the tuning configuration file that is currently in effect in the system, and confirm whether it is consistent with the name of the tuning configuration file after the switch in the persistent state record. If not, refuse to roll back. Determine whether the name of the tuning configuration file before the switch in the persistent state record still exists in the system's list of installed tuning configuration files. If not, refuse to roll back. If all of the above conditions are met, the rollback is confirmed, and a state transition is performed, updating the rollback status flag from "in effect" to "rollback in progress" to prevent state chaos caused by multiple rollback requests being executed simultaneously in concurrent scenarios.

[0116] During implementation, if rollback is confirmed, the underlying tuning framework's switching command is invoked to switch the system tuning configuration to the pre-switch tuning configuration file in the status log, restoring the pre-switch state. If the rollback operation is successful, the rollback status flag is updated to "rollback successful," and the successful rollback result is returned to the browser client as a response. If the rollback operation fails, the rollback status flag is automatically restored to "effective," allowing the administrator to retry the rollback, and the failure result and reason for failure are returned to the browser client.

[0117] Specifically, if the name of the tuning configuration file is empty or indicates that there is no tuning configuration file before the switch, the underlying tuning framework is invoked to close the current tuning configuration and restore the system to the default untuned state.

[0118] In practice, after the rollback operation is completed, an audit log is recorded. The audit log records include: operation timestamp, operation user, operation type (rollback operation), optimization configuration file names before and after the rollback, and the rollback operation execution result (success or failure).

[0119] Preferably, the audit log also includes a summary of the changes in key system kernel parameters between the current configuration file switching operation and the rollback operation, allowing administrators to assess the differences in system state before and after the rollback.

[0120] Furthermore, this method also includes a health linkage protection mechanism for audit logs, including: Before performing the audit log write operation, check the system disk space and I / O status; When the disk space is detected to be lower than the preset threshold or the I / O response is abnormal, the subsequent audit log writing operation is automatically suspended, and the audit events to be written are temporarily stored in the memory cache. Continuously monitor the system's health status. Once the system returns to normal, resume writing the audit logs and write the cached audit events sequentially.

[0121] Understandably, this mechanism prioritizes the successful execution of the tuning operation itself when disk space is insufficient or I / O is abnormal, avoiding the failure of the tuning operation to be completed due to audit log writing failure or I / O blocking.

[0122] Furthermore, the method in this embodiment also includes a browser user reverse lookup, including: When the built-in web service receives an HTTP request from a browser client, it extracts the client's IP address and source port number from the request; Traverse the network socket information (such as / proc / net / tcp and / proc / net / tcp6) under the system kernel process file system, find the network connection in the ESTABLISHED state that matches the client IP address and source port number, and obtain the process identifier (PID) of the process to which the connection belongs. Based on the process identifier, look up the operating system username to which the process belongs in the system process information file (such as / proc / [PID] / status); The operating system username is recorded as the actual operator of the HTTP request in the audit log.

[0123] Understandably, the above mechanism can establish a mapping relationship between web requests and operating system users, accurately trace the actual source of each web operation, prevent identity impersonation, and enhance the credibility of audit logs.

[0124] Furthermore, the persistent state record is shared for reading and writing by both the Web operation entry point and the command line operation entry point. When recording the persistent state, the system also records the operation source identifier of this switching operation. The operation source identifier is used to distinguish whether the switching is triggered by the Web interface or by the command line. When a rollback operation is performed from any entry point, the same persistent state record is read to ensure that the rollback behavior is consistent under different operation entry points.

[0125] Furthermore, rollback management also supports rollback history tracing. The system generates an independent operation history record for each switch and rollback operation, including operation type, time, operator, name of the optimization configuration file involved, and snapshot of key parameters. After multiple switch and rollback operations are executed alternately, the administrator can view the complete operation history chain through the browser client to understand the complete change trajectory of the system optimization configuration, which facilitates fault tracing and auditing.

[0126] In implementation, the method also includes a startup integrity verification mechanism, including: At the initial stage of system service startup and before log system initialization, read the integrity verification list stored externally in encrypted form and verify the digital signature or message authentication code of the verification list to confirm that it has not been tampered with. Based on the file hash values ​​in the verification list, verify the integrity of core program files and key configuration files one by one; If any file verification fails, the system startup process is terminated and an alarm message is output through a channel independent of the log system.

[0127] Understandably, the persistent rollback mechanism using a three-state machine and atomic write ensures persistent state recording and atomic rollback for profile switching operations. Administrators can easily revert to the stable state before the switch if parameters are incompatible, avoiding configuration drift and concurrent operation chaos. Through multiple layers of security protection, including browser user reverse lookup mechanism, login frequency limit, secure command execution, and startup integrity verification, a complete identity traceability and anti-tampering defense is established for the Web tuning channel. This effectively prevents security risks such as unauthorized operations and execution after core files have been tampered with, enabling Linux system tuning to have enterprise-level automated operation and maintenance capabilities with remote visualization, full-link traceability, and secure rollback.

[0128] It should be noted that after receiving a request from a browser client, the web server executes the corresponding response operation based on the request path and parameters. All operations involving underlying system command calls are handled uniformly through the secure command execution module. This module enforces shell=False to disable the shell interpreter, uses parameter lists to pass command parameters to prevent injection attacks, and sets timeout thresholds for each child process to prevent process hangs.

[0129] In implementation, the method of this embodiment can be implemented using a five-layer layered architecture, specifically structured as follows: The front-end presentation layer is implemented using native HTML5 and JavaScript. All required static resources are packaged and distributed locally with the system, without relying on external CDNs or internet resources. The system can run self-contained in an isolated intranet environment. The front-end communicates with the back-end via a RESTful JSON API, supporting features such as profile list display, parameter detail viewing, parameter difference comparison highlighting, real-time monitoring chart rendering, optimization rollback interaction, and user login authentication.

[0130] The web service layer implements multi-threaded HTTP services based on the Python standard library, without relying on third-party web frameworks. This layer is responsible for request routing, user authentication, session management, and audit logging, providing structured data interfaces for the front-end pages.

[0131] The core business layer adopts a modular architecture design, including a main control module, a data acquisition module, a parameter analysis module, a rollback management module, an integrity verification module, a report export module, and a real-time monitoring module, which respectively complete data acquisition, parameter parsing, difference analysis, status rollback, security verification, and report generation.

[0132] The Tuned interaction layer encapsulates the interaction operations with the tuned system, including profile list query, current profile identification, profile switching, inheritance chain resolution, system parameter reading, and secure command execution, and provides capabilities to the core business layer through a unified interface.

[0133] The system's underlying layers include the tuned daemon, kernel parameter interface, profile configuration file, rollback status file, and system performance metrics data source.

[0134] Understandably, the front-end layer is only responsible for interface display and user interaction, with simple logic and no external dependencies; the web service layer is implemented based on the Python standard library, making deployment easy; the core business layer achieves functional scalability through a modular plug-in architecture; the Tuned interaction layer ensures stable interaction with the tuned system through carefully designed encapsulation; and the system's underlying layer directly reads kernel parameter interfaces to ensure data accuracy and real-time performance.

[0135] Compared with existing technologies, this embodiment provides a Linux tuning profile inheritance chain parsing and parameter management method based on a web interface. By building a web service, it provides remote tuning management capabilities with a graphical and structured data interface, enabling maintenance personnel to perform tuning operations through a browser without relying on command-line text parsing. This completely solves the defect of fragile automated parsing caused by the unstructured output of tuned-adm. By parsing the multi-level inheritance relationship of the profile through inheritance chain and outputting a flat parameter set with source annotations, the original source tracing process that required manual layer-by-layer tracking is transformed into an automatic process completed by the system. This allows administrators to know each parameter without opening the configuration file. The final effective value of the data and its source profile; through structured parameter comparison and character-level positioning technology, the difference detection process that originally required manual line-by-line cross-comparison of configuration files is transformed into automatic system completion and precise highlighting of difference locations, which greatly reduces the time consumption of manual comparison and avoids omissions; through visual monitoring of system status information, system operation indicators are presented in the form of dynamic chart rendering, so that administrators can view the performance changes after optimization without repeatedly logging into the server, intuitively reflecting the impact of optimization operations on the system; at the same time, by directly reading the kernel virtual file system to collect monitoring data and storing it in a circular buffer, the system overhead of child process creation in the traditional external command monitoring method is eliminated.

[0136] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0137] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for resolving Linux tuning profile inheritance chain and managing parameters based on a web interface, characterized in that, Includes the following steps: Receive structured data requests from browser clients via built-in web services; In response to a tuning configuration file query request, the inheritance chain of the target tuning configuration file is parsed and the parameters are merged to generate a flattened parameter set and an inheritance chain order list. The flattened parameter set includes the final effective value of each parameter and its source configuration file information; In response to a parameter comparison request, the parameters from the first optimization configuration source and the parameters from the second optimization configuration source are compared in a structured manner to identify the differences and generate difference data; the difference data includes the location information of the differences in the original output text. In response to real-time monitoring data requests, system operation metrics are collected by directly reading the kernel virtual file system and the metric data is stored in a circular buffer; The response result is returned to the browser client, and the browser client performs visualization rendering based on the response result.

2. The Linux tuning profile inheritance chain parsing and parameter management method based on a web interface according to claim 1, characterized in that, The flattened parameter set and inheritance chain order list are encapsulated into structured response data and returned to the browser client as the response result; When the browser client receives a structured, flattened set of parameters, the browser client categorizes and displays the parameters according to their types, and displays the parameter name, the final effective value of the parameter, and the identification information of the source configuration file for each parameter; When the browser client receives the inheritance chain order list, it graphically displays the inheritance relationship between the various tuning configuration files based on the inheritance chain order list.

3. The Linux tuning profile inheritance chain parsing and parameter management method based on a web interface according to claim 1, characterized in that, When the parameter comparison request is a comparison between two tuning configuration files, the first tuning configuration source is the first tuning configuration file, and the second tuning configuration source is the second tuning configuration file; When the parameter comparison request is a comparison between the current system parameters and the target tuning configuration file, the first tuning configuration source is the parameters actually running in the current system, and the second tuning configuration source is the target tuning configuration file.

4. The Linux tuning profile inheritance chain parsing and parameter management method based on a web interface according to claim 3, characterized in that, The difference data is generated in the following ways: Based on the parameter comparison request, obtain the first parameter dictionary and the second parameter dictionary; A structured comparison is performed item by item between the first parameter dictionary and the second parameter dictionary to identify and classify the differing parameters; For each difference parameter, the position of the difference parameter is matched in the corresponding original output text to generate positioning information including line number and character offset; All difference parameters, their difference types, current values, target values, and location information are structured and encapsulated to obtain difference data.

5. The Linux tuning profile inheritance chain parsing and parameter management method based on a web interface according to claim 4, characterized in that, If the parameter comparison request is for a first tuning configuration file and a second tuning configuration file, then the first parameter dictionary includes the flattened parameter set of the first tuning configuration file; the second parameter dictionary includes the flattened parameter set of the second tuning configuration file. If the parameter comparison request is between the current system parameters and the target tuning configuration file, the first parameter dictionary obtains the parameter key-value pairs actually running in the current system by directly reading the kernel virtual file system; the second parameter dictionary includes the flattened parameter set of the target tuning configuration file.

6. The Linux tuning profile inheritance chain parsing and parameter management method based on a web interface according to claim 5, characterized in that, The difference parameters include parameter name, current value in the first parameter dictionary, target value in the second parameter dictionary, and difference type identifier; The differential parameters are identified and classified in the following ways: Get the union of all keys in the first parameter dictionary and all keys in the second parameter dictionary. Iterate through each parameter name in the union and execute: If the parameter name exists in the second parameter dictionary but not in the first parameter dictionary, it is marked as a new parameter; If the parameter name exists in the first parameter dictionary but not in the second parameter dictionary, it is marked as a deleted parameter; If the parameter name exists in both the first and second parameter dictionaries, but the parameter values ​​are different, it is marked as a changed parameter. If the parameter name exists in both the first and second parameter dictionaries and the parameter value is the same, it is marked as an indifferent parameter and is not included in the difference results.

7. The Linux tuning profile inheritance chain parsing and parameter management method based on a web interface according to claim 4, characterized in that, After receiving the structured difference data, the browser client highlights the parameter values ​​of the difference parameters in the display area of ​​the browser client with different colors, based on the line numbers and character offset start and end positions in the positioning information.

8. The Linux tuning profile inheritance chain parsing and parameter management method based on a web interface according to claim 1, characterized in that, The method further includes: In response to a tuning configuration file switching request, the system tuning configuration is switched to the specified target tuning configuration file, and the persistent state record is updated after the switch is completed. The persistent state record includes the state before the switch and the state after the switch.

9. The Linux tuning profile inheritance chain parsing and parameter management method based on a web interface according to claim 8, characterized in that, The method further includes: In response to the rollback request, the system tuning configuration is restored to the state before the tuning configuration file switching operation was performed, and the rollback result is returned after the rollback operation is completed.

10. The Linux tuning profile inheritance chain parsing and parameter management method based on a web interface according to claim 9, characterized in that, The persistent state record also includes a rollback state identifier; when a rollback request is received, the validity of the persistent state record is verified, and after confirming that the current system state is consistent with the state after the switch in the persistent state record, the operation of restoring the system parameters to the state before the switch is performed, and the rollback state identifier is updated.

Images