CN113778892B - Method for locating performance bottleneck of operating system, computing device and storage medium - Google Patents

Method for locating performance bottleneck of operating system, computing device and storage medium Download PDF

Info

Publication number
CN113778892B
CN113778892B CN202111092768.2A CN202111092768A CN113778892B CN 113778892 B CN113778892 B CN 113778892B CN 202111092768 A CN202111092768 A CN 202111092768A CN 113778892 B CN113778892 B CN 113778892B
Authority
CN
China
Prior art keywords
operating system
performance
function library
library
performance test
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202111092768.2A
Other languages
Chinese (zh)
Other versions
CN113778892A (en
Inventor
焦芬芳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Uniontech Software Technology Co Ltd
Original Assignee
Uniontech Software Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Uniontech Software Technology Co Ltd filed Critical Uniontech Software Technology Co Ltd
Priority to CN202111092768.2A priority Critical patent/CN113778892B/en
Publication of CN113778892A publication Critical patent/CN113778892A/en
Application granted granted Critical
Publication of CN113778892B publication Critical patent/CN113778892B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test management for test execution, e.g. scheduling of test suites

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The invention discloses a method for locating performance bottlenecks of an operating system, a computing device and a storage medium, wherein the method for locating the performance bottlenecks of the operating system is executed in the computing device and comprises the following steps: performing performance test on the first operating system and the second operating system based on the first performance test program respectively to obtain a first test value of the first operating system and a second test value of the second operating system; if the first test value is smaller than the second test value, linking the target function library residing in the first operating system with the first performance test program in a preset state by using a linker to generate a second performance test program; performing performance test on the second operating system based on the second performance test program to obtain a third test value; and if the third test value is smaller than the second test value, the objective function library is a performance bottleneck of the first operating system.

Description

Method for locating performance bottleneck of operating system, computing device and storage medium
The application is a divisional application of an application patent application filed on 7 months 13 days 2021, and the application number of the original application is: 2021107874196, name of application: a method, computing device, and storage medium for locating operating system performance bottlenecks.
Technical Field
The present invention relates to the field of internet, and in particular, to a method for locating performance bottlenecks of an operating system, a computing device, and a storage medium.
Background
In the face of a huge and complex Linux operating system, positioning performance problems require extensive experience and methods, first knowing where to start analysis, what data to collect, and how to analyze the data.
There are many tools currently used to collect Linux operating system data (e.g., perf, blktrace, sar, etc. tools) that can be used directly to gain insight into performance bottlenecks, but this is time consuming.
Disclosure of Invention
The present invention has been made in view of the above problems, and provides a method, computing device, and storage medium for locating operating system performance bottlenecks that overcome or at least partially solve the above problems.
According to one aspect of the present invention, there is provided a method of locating operating system performance bottlenecks, performed in a computing device, the method comprising: performing performance test on the first operating system and the second operating system based on the first performance test program respectively to obtain a first test value of the first operating system and a second test value of the second operating system; if the first test value is smaller than the second test value, linking the target function library residing in the first operating system with the first performance test program in a preset state by using a linker to generate a second performance test program; performing performance test on the second operating system based on the second performance test program to obtain a third test value; if the third test value is smaller than the second test value, the objective function library is positioned as the performance bottleneck of the first operating system.
Optionally, in the method for locating an operating system performance bottleneck according to the present invention, the first operating system and the second operating system at least include: the system layer at least comprises a system kernel function library and a driving function library; the non-system layer at least comprises a calling interface function library, an element function library and an application function library; the target function library is one of a calling interface function library, an element function library and an application function library.
Optionally, in the method for locating operating system performance bottlenecks according to the present invention, the method further includes the steps of: traversing all objective function libraries in a non-system layer; if all the objective functions are not the performance bottleneck of the first operating system, the system layer is the performance bottleneck of the first operating system.
Optionally, in the method for locating an operating system performance bottleneck according to the present invention, the hardware configurations carried by the first operating system and the second operating system are the same.
Optionally, in the method for locating a performance bottleneck of an operating system according to the present invention, if the first test value is smaller than the second test value, the step of linking the target function library residing in the first operating system with the first performance test program by using the linker to perform a preset state, and generating the second performance test program includes: determining a link mode of a preset state link based on the type of the objective function library; compiling the first performance test program based on the link parameters corresponding to the determined link mode to obtain a compiled first performance test program; and linking the compiled first performance test program with the objective function library by using a linker to generate a second performance test program.
Optionally, in the method for locating an operating system performance bottleneck according to the present invention, before the step of performing a performance test on the second operating system based on the second performance test program to obtain the third test value, the method further includes: the second performance test program is binary copied to the second operating system.
Optionally, in the method for locating operating system performance bottlenecks according to the present invention, the objective function library is one of a static library or a dynamic library.
Optionally, in the method for locating a performance bottleneck of an operating system according to the present invention, the link mode of the preset state link includes a static link and a dynamic link, and the step of determining the preset state link mode based on the type of the objective function library includes: if the objective function library is a static library, carrying out static link on the objective function library and the first performance test program; and if the objective function library is a dynamic library, dynamically linking the objective function library with the first performance test program.
According to yet another aspect of the present invention, there is provided a computing device comprising: at least one processor; and a memory storing program instructions, wherein the program instructions are configured to be adapted to be executed by the at least one processor, the program instructions comprising instructions for performing the above-described method.
According to yet another aspect of the present invention, there is provided a readable storage medium storing program instructions that, when read and executed by a computing device, cause the computing device to perform the above-described method.
According to the scheme of the invention, the objective function library in the system with poor performance and the performance test program are compiled and linked in a static link or dynamic link mode, and then the performance test program is implanted into the system with good performance for execution, so that the objective function library is not relied on when the system with good performance is tested, but is relied on, and therefore, whether the objective function library is a performance bottleneck of the system with poor performance is judged.
According to the method for locating the performance bottleneck of the operating system, the locating range of the performance problem of the complex system can be reduced, the function library to which the problem belongs can be quickly located, and limited efforts are focused on the solution of the performance bottleneck of the system.
The foregoing description is only an overview of the present invention, and is intended to be implemented in accordance with the teachings of the present invention in order that the same may be more clearly understood and to make the same and other objects, features and advantages of the present invention more readily apparent.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to designate like parts throughout the figures. In the drawings:
FIG. 1 shows a schematic diagram of a computing device 100 according to one embodiment of the invention;
FIG. 2 illustrates a flow of a method 200 of locating operating system performance bottlenecks, according to one embodiment of the invention;
FIG. 3 illustrates a system architecture 300 according to one embodiment of the invention;
FIG. 4 illustrates a flow chart of a method 400 of locating performance bottlenecks at a level in a system architecture, according to one embodiment of the invention.
Detailed Description
Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
Linux operating systems have many performance analysis tools, such as tools "perf, blktrace, sar", which can be used directly to gain insight into performance bottlenecks, but are time consuming to do so.
In general, when comparing the performance of two Linux operating systems, if a certain performance of a system is poor, the reason of the difference needs to be found, the operating system is huge, and the system consists of an application, a base library, a kernel, a driver and the like, so that the problem that the certain performance of the operating system is poor is a complex problem, and a simple method is not available, but a complex problem can be decomposed, the core range of a performance bottleneck can be found, and the problem locating efficiency is improved.
The proposal of the invention is provided for solving the problems in the prior art. One embodiment of the present invention provides a method of locating operating system performance bottlenecks that may be performed in a computing device.
FIG. 1 illustrates a block diagram of a computing device 100 according to one embodiment of the invention. As shown in FIG. 1, in a basic configuration 102, a computing device 100 typically includes a system memory 106 and one or more processors 104. The memory bus 108 may be used for communication between the processor 104 and the system memory 106.
Depending on the desired configuration, the processor 104 may be any type of processing including, but not limited to: a microprocessor (μp), a microcontroller (μc), a digital information processor (DSP), or any combination thereof. The processor 104 may include one or more levels of caches, such as a first level cache 110 and a second level cache 112, a processor core 114, and registers 116. The example processor core 114 may include an Arithmetic Logic Unit (ALU), a Floating Point Unit (FPU), a digital signal processing core (DSP core), or any combination thereof. The example memory controller 118 may be used with the processor 104, or in some implementations, the memory controller 118 may be an internal part of the processor 104.
Depending on the desired configuration, system memory 106 may be any type of memory including, but not limited to: volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.), or any combination thereof. Physical memory in a computing device is often referred to as volatile memory, RAM, and data in disk needs to be loaded into physical memory in order to be read by processor 104. The system memory 106 may include an operating system 120, one or more applications 122, and program data 124. The application 122 is actually a plurality of program instructions for instructing the processor 104 to perform a corresponding operation. In some implementations, the application 122 may be arranged to execute instructions on an operating system by the one or more processors 104 using the program data 124 in some implementations. Operating system 120 may be, for example, linux, windows or the like, which includes program instructions for handling basic system services and performing hardware-dependent tasks. The application 122 includes program instructions for implementing various functions desired by the user, and the application 122 may be, for example, a browser, instant messaging software, a software development tool (e.g., integrated development environment IDE, compiler, etc.), or the like, but is not limited thereto. When an application 122 is installed into computing device 100, a driver module may be added to operating system 120.
When the computing device 100 starts up running, the processor 104 reads and executes program instructions of the operating system 120 from the system memory 106. Applications 122 run on top of operating system 120, utilizing interfaces provided by operating system 120 and underlying hardware to implement various user-desired functions. When a user launches the application 122, the application 122 is loaded into the system memory 106, and the processor 104 reads and executes the program instructions of the application 122 from the system memory 106.
Computing device 100 also includes storage device 132, storage device 132 including removable storage 136 and non-removable storage 138, both removable storage 136 and non-removable storage 138 being connected to storage interface bus 134.
Computing device 100 may also include an interface bus 140 that facilitates communication from various interface devices (e.g., output devices 142, peripheral interfaces 144, and communication devices 146) to basic configuration 102 via bus/interface controller 130. The example output device 142 includes a graphics processing unit 148 and an audio processing unit 150. They may be configured to facilitate communication with various external devices such as a display or speakers via one or more a/V ports 152. Example peripheral interfaces 144 may include a serial interface controller 154 and a parallel interface controller 156, which may be configured to facilitate communication with external devices such as input devices (e.g., keyboard, mouse, pen, voice input device, touch input device) or other peripherals (e.g., printer, scanner, etc.) via one or more I/O ports 158. An example communication device 146 may include a network controller 160, which may be arranged to facilitate communication with one or more other computing devices 162 via one or more communication ports 164 over a network communication link.
The network communication link may be one example of a communication medium. Communication media may typically be embodied by computer readable instructions, data structures, program modules, and may include any information delivery media in a modulated data signal, such as a carrier wave or other transport mechanism. A "modulated data signal" may be a signal that has one or more of its data set or changed in such a manner as to encode information in the signal. By way of non-limiting example, communication media may include wired media such as a wired network or special purpose network, and wireless media such as acoustic, radio Frequency (RF), microwave, infrared (IR) or other wireless media. The term computer readable media as used herein may include both storage media and communication media.
Computing device 100 also includes a storage interface bus 134 that is coupled to bus/interface controller 130. The storage interface bus 134 is coupled to the storage device 132, and the storage device 132 is adapted to store data. An example storage device 132 may include removable storage 136 (e.g., CD, DVD, U disk, removable hard disk, etc.) and non-removable storage 138 (e.g., hard disk drive HDD, etc.).
In computing device 100 according to the present invention, application 122 includes a plurality of program instructions to perform method 200.
FIG. 2 illustrates a flowchart of a method 200 of locating operating system performance bottlenecks, according to one embodiment of the invention. The method 200 is suitable for execution in a computing device, such as the computing device 100 described previously.
As shown in fig. 2, the method 200 is to provide a method for quickly locating performance bottlenecks of an operating system, and starts in step S202.
In step S202, performance tests are performed on the first operating system and the second operating system based on the first performance test program, so as to obtain a first test value of the first operating system and a second test value of the second operating system.
It should be noted that, the method for locating the performance bottleneck of the operating system provided in this embodiment is applicable to Unix-like (such as Unix, BSD, linux) operating systems, for example, the first operating system and the second operating system are Linux operating systems disposed on a computing device, and loads and hardware configurations of the first operating system and the second operating system are the same, so that factors such as hardware and the like are prevented from interfering with locating the performance bottleneck of the system.
In this embodiment, the first performance testing procedure may be a conventional system performance testing tool, such as Unixbench, kylinTOP, loadRunner, which is not limited in this embodiment.
Preferably, unixBench is selected as the first performance test program in the present embodiment, unixBench is a performance test tool under Unix (BSD, linux) system, an open source tool, which is widely used for testing the performance of the Linux system host. The main test items of Unixbench are: system reference performance such as system call, read-write, process, graphical test, 2D, 3D, pipeline, operation, C library and the like provides test data.
In a specific example, under the condition that loads and configurations of two operating systems (a first operating system and a second operating system) are the same, a first performance testing tool (Unixbench) is used for respectively performing performance testing on the first operating system and the second operating system to obtain a corresponding first test value and a corresponding second test value. The first test value and the second test value may be digital values, for example, the first test value is 1400 minutes, and the second test value is 1600 minutes. In other words, the performance score of the first operating system is 1400 points and the performance score of the second operating system is 1600 points.
In step S204, the magnitudes of the first test value and the second test value are determined, and if the first test value is smaller than the second test value, the target function library residing in the first operating system is linked with the first performance test program in a preset state by using the linker, so as to generate a second performance test program.
As can be seen from step S202, if the first test value is smaller than the second test value, it is indicated that the performance of the first operating system is worse than that of the second operating system, so in this embodiment, it is necessary to locate the performance bottleneck of the first operating system, i.e. to find the cause of the poor performance of the first operating system, and locate the problem of the first operating system.
It is readily understood that an Operating System (OS) is a computer program that manages computer hardware and software resources, consisting of libraries of functions that perform different functions. For example, the system may include an Operating SYSTEM KERNEL (system kernel) function library, a driver function library, a glibc (system program) function library, a SYSTERN CALL INTERFACE (system call interface, SCI for short) function library, a library of library elements, an Application function library, and the like. When the performance bottleneck of the system is located, the performance bottleneck of the system can be located only by finding out the problem function library.
In this embodiment, a new performance test program (second test program) is formed by linking the objective function library of the first operating system with the performance test program (first test program) by means of static linking and/or dynamic linking. At this time, the second performance test program already carries the objective function library of the first operating system, and the second performance test program carrying the objective function library is utilized to test the first operating system, so as to determine whether the objective function library is a performance bottleneck of the first operating system.
Static linking is a method commonly used by compilers, and is performed in the compiling stage, for example, an application program xx.c calls a function of a static library tirpc.a, and then when xx.c is compiled, the static linking method is used to link target files of tirpc.a and xx.c together to generate an executable program, and the generated executable program contains tirpc.a. The executable program generated by xx.c and tirpc.a can be moved to any system which does not contain tirpc.a, which is a benefit of static linking, but has the disadvantage that the generated executable program occupies large space and is redundant, if another application yy.c also uses tirpc.a, yy.c is compiled to statically link tirpc.a, so that the static link tirpc.a. is in both xx.c and yy.c, and binary redundancy of tirpc.a is caused, so dynamic linking is generated, xx.c and yy.c record use tirpc.a in the compiling stage, and when executing, searching of tirpc.a is completed by a linker ld, and the dynamic linking reduces redundancy.
Of course, while dynamic links are somewhat superior to static links, not all function libraries are amenable to dynamic links, depending on whether the function library itself belongs to a static library or a dynamic library. For example, glibc function Libraries are static Libraries, while library is a dynamic library. Thus, in some embodiments, the library of objective functions is one of a static library or a dynamic library.
It should be noted that the dynamic link is developed from a static link, and the function libraries linked by the dynamic link may also be statically linked, in other words, all the function libraries in the system may be statically linked.
In addition, for easy understanding and description, step S204 further includes the following sub-steps:
s224, determining a link mode of a preset state link based on the type of the objective function library.
As described above, compared with the static link, the dynamic link can avoid redundancy and reduce resource waste, so in this embodiment, before the objective function library and the first performance test program are linked in a preset state, it is necessary to determine whether the objective function library belongs to the static library or the dynamic library. If the objective function library is a static library, carrying out static link on the objective function library and the first performance test program; and if the objective function library is a dynamic library, dynamically linking the objective function library with the first performance test program.
S244, compiling the first performance test program based on the link parameters corresponding to the determined link mode to obtain a compiled first performance test program.
Specifically, the parameter compilation performance test tools may be linked using gcc-static, gcc-WL-Bstatic-Lxxx, or gcc-WL-Bstatic-Lxxx. Under the default condition, the GCC/G++ links the dynamic library preferentially, and if the dynamic library does not exist, the corresponding static library is linked. Static is to have gcc statically compiled, i.e. to integrate all needed libraries into a compiled program, which can be run independent of external libraries. -Wl, -Bstatic and-Wl, -Bdynamic for the user to specify linking to a dynamic library or a static library, respectively. Xxx in lxxx indicates the name of the target function library called by the performance test tool, e.g., -l Libraries, the performance test program may call the Libraries, in particular may be obtained by ldd commands, the detailed use of which is not described in this embodiment.
S264, linking the compiled first performance test program with the objective function library by using a linker to generate a second performance test program.
It should be noted that, the forming process of the second performance test program is completed on the first operating system (with poor performance), and the formed second performance test program needs to be copied into the second operating system (with good performance), specifically, the second performance test program is copied into the second operating system in binary.
In step S206, performance testing is performed on the second operating system based on the second performance testing program, so as to obtain a third test value.
Because the second performance test program carries the objective function library in the first operating system, when the second performance test program is used for retesting the second operating system, the second performance test program does not test the function library corresponding to the objective function library in the second operating system, but tests the carried objective function library.
Taking the objective function as the glibc function library as an example, the second performance test program binds the glibc function library of the first operating system (i.e. the glibc function library carrying the first operating system), so when the second performance test program is used for testing the second operating system, the glibc function library of the second operating system is not tested any more, and still the glibc function library of the first operating system is tested.
In step S208, if the third test value is smaller than the second test value, the objective function library is located as a performance bottleneck of the first operating system.
Continuing with the previous example, if the third test value is 1400, the second test value is 1600. Given that the system score of the second operating system is reduced from 1600 to 1400 in the two test results, it is indicated that the objective function library of the first operating system carried by the second performance test program has a problem, and it can be determined that the performance bottleneck of the first operating system is the objective function.
Of course, if the third test value is better than or equal to the second test value, indicating that the objective function is not a performance bottleneck of the first operating system, switching other objective functions to locate the performance bottleneck.
In some embodiments, the first operating system and the second operating system comprise at least: the system layer at least comprises a system kernel function library and a driving function library; the non-system layer at least comprises a calling interface function library, an element function library and an application function library; the target function library is one of a calling interface function library, an element function library and an application function library.
The above is a simple layering of the architecture of the operating system, but the layering of the architecture of the system may be divided according to the actual situation, and is not limited to and divided into a system layer and a non-system layer. Other layering methods are also possible, for example, as shown in fig. 3, according to the calling and called conditions of the objective function library, the non-system layer may be subdivided into an application function library layer, an element function library layer, a system program library layer, and the like.
Referring to fig. 3, in the framework of the Operating system, the upper function library may call the next function library, but the lower function library may not call the upper function library, for example, the upper Application may call the lower function library such as Libraries, glibc or Operating SYSTEM KERNEL, or the library may call glibc or Operating SYSTEM KERNEL, glibc may call Operating SYSTEM KERNEL, but the lower Operating SYSTEM KERNEL may not call the upper glibc. If the objective function library carried by the second performance test program is a function library of a system layer, for example, the second performance test program carries a function library of a first Operating system SYSTEM KERNEL, since the carried Operating SYSTEM KERNEL function library can only be called, but cannot call a library of an upper layer such as library or glibc, there is a problem of inaccurate positioning (since the first Operating system and the second Operating system set the same system load and hardware environment, HARDWARE LAYER (hardware layer) is not considered here).
When the method for locating the performance bottleneck of the operating system judges that a certain objective function is not the performance bottleneck of the first operating system, the replaceable objective function library judges again, and finally the performance bottleneck of the first operating system is found out. Specifically, all objective function libraries in the non-system layer are traversed. If all the objective function libraries are not the performance bottleneck of the first operating system, the system layer is the performance bottleneck of the first operating system. Of course, it may be HARDWARE LAYER (hardware layer) that a problem arises if it is ultimately determined that the respective objective function library in the system layer is not a performance bottleneck for the first operating system.
In addition, in order to save positioning time further, the method can be used for directly positioning the system performance bottleneck on which layer of the system architecture. In a specific example, taking the system architecture 300 as shown in fig. 3 as a layered example, the method of this embodiment is described below, and fig. 4 is a flowchart illustrating a method 400 for locating a performance bottleneck at a layer in the system architecture 300, where a gcc-static link parameter is used to compile a first performance test program on a system with poor performance (a first operating system) to form a second performance test program; and (3) binary copying the compiled second performance test program to a System (second Operating System) with good performance, if the test score of the second Operating System is better than the performance score of the second Operating System tested in advance or the flatness is tested in advance, the problem of the System (first Operating System) with poor performance is in the layer of Operating System (OS) kernel, drivers, etc, otherwise, the problem is in the upper layer of Operating System (OS) kernel, drivers, etc.
If the problem is located at the upper layer of the Operating System (OS) kernel, drivers, etc, the gcc-Wl-Bstatic-lxxx static link is used to compile the first performance test program on the System with poor performance, forming a second performance test program. Xxx in lxxx denotes that the performance test procedure calls the library of the library layer, and the library of the library layer is obtained. And (3) re-copying the re-compiled second performance test program to a system with good performance (a first operating system), wherein if the test score of the second operating system is better than the performance score of the second operating system tested by the prior test or the uniformity is tested, the system problem with poor performance is in a glibc/SYSTEM CALL INTERFACE (SCI) layer, otherwise, the problem is in a Libraries layer.
In another example, taking the objective function as a glibc function library as an example, the execution process of the above method is described as follows:
Taking syscale of the performance test program Unixbench as an example, makefile of the Unixbench tool compiles dynamic links for use by the performance test tool. Syscall 1 is to test the system call performance of the Linux operating system, which only calls the glibc library, and under the condition that the loads and the configurations of the two Linux operating systems are the same, the first Linux system scores 1400 and the second Linux system scores 1600, and for a novice, there may be no performance bottleneck for locating the first Linux system. For an experienced performance tuning engineer, the test item relates to the problem of glibc and Operating System (OS) kernel, particularly which layer, and requires deep analysis and tracking, and glibc and Operating System (OS) kernel are complex, not simple hundreds of thousands of lines of codes or logic structures, and preferentially analyze which layer, if guessed by experience, saves much time, otherwise, if guessed by mistake, valuable time is wasted. By using the static linking method described above, on the first Operating System, the glibc and the syscall 1 target program are statically linked to generate an executable program syscall 2, then the compiled executable program syscall 2 is put on the second Linux System to be executed, when the syscall 2 is executed on the second Linux System, the method only depends on an Operating System (OS) kernel of the second Linux System, and does not depend on the glibc of the second Linux System, and the test result 1400 points, which is the problem of the glibc. A novice or experienced engineer may analyze performance problems with low syscale scores on the first Linux system starting from the trace analysis glibc.
The various techniques described herein may be implemented in connection with hardware or software or, alternatively, with a combination of both. Thus, the methods and apparatus of the present invention, or certain aspects or portions of the methods and apparatus of the present invention, may take the form of program code (i.e., instructions) embodied in tangible media, such as removable hard drives, U-drives, floppy diskettes, CD-ROMs, or any other machine-readable storage medium, wherein, when the program is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention.
In the case of program code execution on programmable computers, the computing device will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. Wherein the memory is configured to store program code; the processor is configured to perform the method of the invention in accordance with instructions in said program code stored in the memory.
By way of example, and not limitation, readable media comprise readable storage media and communication media. The readable storage medium stores information such as computer readable instructions, data structures, program modules, or other data. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. Combinations of any of the above are also included within the scope of readable media.
In the description provided herein, algorithms and displays are not inherently related to any particular computer, virtual system, or other apparatus. Various general-purpose systems may also be used with examples of the invention. The required structure for a construction of such a system is apparent from the description above. In addition, the present invention is not directed to any particular programming language. It should be appreciated that the teachings of the present invention as described herein may be implemented in a variety of programming languages and that the foregoing description of specific languages is provided for disclosure of preferred embodiments of the present invention.
In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.
Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. However, the disclosed method should not be construed as reflecting the intention that: i.e., the claimed invention requires more features than are expressly recited in each claim.
Those skilled in the art will appreciate that the modules or units or components of the devices in the examples disclosed herein may be arranged in a device as described in this embodiment, or alternatively may be located in one or more devices different from the devices in this example. The modules in the foregoing examples may be combined into one module or may be further divided into a plurality of sub-modules.
Those skilled in the art will appreciate that the modules in the apparatus of the embodiments may be adaptively changed and disposed in one or more apparatuses different from the embodiments. The modules or units or components of the embodiments may be combined into one module or unit or component and, furthermore, they may be divided into a plurality of sub-modules or sub-units or sub-components. Any combination of all features disclosed in this specification (including any accompanying claims, abstract and drawings), and all of the processes or units of any method or apparatus so disclosed, may be used in combination, except insofar as at least some of such features and/or processes or units are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings), may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.
Furthermore, those skilled in the art will appreciate that while some embodiments described herein include some features but not others included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention and form different embodiments.
Furthermore, some of the embodiments are described herein as methods or combinations of method elements that may be implemented by a processor of a computer system or by other means of performing the functions. Thus, a processor with the necessary instructions for implementing the described method or method element forms a means for implementing the method or method element. Furthermore, the elements of the apparatus embodiments described herein are examples of the following apparatus: the apparatus is for carrying out the functions performed by the elements for carrying out the objects of the invention.
As used herein, unless otherwise specified the use of the ordinal terms "first," "second," "third," etc., to describe a general object merely denote different instances of like objects, and are not intended to imply that the objects so described must have a given order, either temporally, spatially, in ranking, or in any other manner.
While the invention has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of the above description, will appreciate that other embodiments are contemplated within the scope of the invention as described herein. Furthermore, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the appended claims. The disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is defined by the appended claims.

Claims (10)

1. A method of locating operating system performance bottlenecks, executing on a computing device, the method comprising:
Performing performance test on a first operating system and a second operating system based on a first performance test program to obtain a first test value of the first operating system and a second test value of the second operating system, wherein the types of the first operating system and the second operating system are the same, and loads and hardware configurations of the first operating system and the second operating system are the same;
If the first test value is smaller than the second test value, a linker is used for carrying out preset state linking on an objective function library residing in the first operating system and the first performance test program to generate a second performance test program, and the linking mode of the preset state linking comprises a static link and a dynamic link;
Performing performance test on the second operating system based on the second performance test program to obtain a third test value;
and if the third test value is smaller than the second test value, locating the objective function library as the performance bottleneck of the first operating system.
2. The method of claim 1, wherein the first operating system and the second operating system comprise at least:
The system layer at least comprises a system kernel function library and a driving function library;
the non-system layer at least comprises a calling interface function library, an element function library and an application function library;
the target function library is one of the call interface function library, the element function library and the application function library.
3. The method of claim 2, further comprising the step of:
Traversing all objective function libraries in the non-system layer;
And if all the objective function libraries are not the performance bottlenecks of the first operating system, the system layer is the performance bottleneck of the first operating system.
4. The method of claim 1, wherein hardware configurations on which the first operating system and the second operating system are loaded are the same.
5. The method of claim 1, wherein if the first test value is less than the second test value, the step of linking the target function library residing in the first operating system with the first performance test program by using a linker to perform a preset state, and generating a second performance test program comprises:
determining a link mode of a preset state link based on the type of the objective function library;
Compiling the first performance test program based on the link parameters corresponding to the determined link mode to obtain a compiled first performance test program;
And linking the compiled first performance test program with the target function library by using the linker to generate a second performance test program.
6. The method of claim 1, wherein prior to the step of performing a performance test on the second operating system based on the second performance test program to obtain a third test value, further comprising:
And binary copying the second performance test program to the second operating system.
7. The method of claim 1, wherein the library of objective functions is one of a static library or a dynamic library.
8. The method of claim 5, wherein determining the link mode of the preset state link based on the type of the objective function library comprises:
If the objective function library is a static library, carrying out static link on the objective function library and the first performance test program;
And if the objective function library is a dynamic library, dynamically linking the objective function library with the first performance test program.
9. A computing device, comprising:
at least one processor; and
A memory storing program instructions, wherein the program instructions are configured to be adapted to be executed by the at least one processor, the program instructions comprising instructions for performing the method of any of claims 1-8.
10. A readable storage medium storing program instructions which, when read and executed by a computing device, cause the computing device to perform the method of any of claims 1-8.
CN202111092768.2A 2021-07-13 2021-07-13 Method for locating performance bottleneck of operating system, computing device and storage medium Active CN113778892B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111092768.2A CN113778892B (en) 2021-07-13 2021-07-13 Method for locating performance bottleneck of operating system, computing device and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111092768.2A CN113778892B (en) 2021-07-13 2021-07-13 Method for locating performance bottleneck of operating system, computing device and storage medium
CN202110787419.6A CN113238973B (en) 2021-07-13 2021-07-13 Method, computing device and storage medium for locating performance bottleneck of operating system

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN202110787419.6A Division CN113238973B (en) 2021-07-13 2021-07-13 Method, computing device and storage medium for locating performance bottleneck of operating system

Publications (2)

Publication Number Publication Date
CN113778892A CN113778892A (en) 2021-12-10
CN113778892B true CN113778892B (en) 2024-05-07

Family

ID=77135373

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202110787419.6A Active CN113238973B (en) 2021-07-13 2021-07-13 Method, computing device and storage medium for locating performance bottleneck of operating system
CN202111092768.2A Active CN113778892B (en) 2021-07-13 2021-07-13 Method for locating performance bottleneck of operating system, computing device and storage medium

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN202110787419.6A Active CN113238973B (en) 2021-07-13 2021-07-13 Method, computing device and storage medium for locating performance bottleneck of operating system

Country Status (1)

Country Link
CN (2) CN113238973B (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108521353A (en) * 2018-04-02 2018-09-11 深圳前海微众银行股份有限公司 Processing method, equipment and the readable storage medium storing program for executing of positioning performance bottleneck
CN110580226A (en) * 2019-09-23 2019-12-17 上海创景信息科技有限公司 object code coverage rate testing method, system and medium for operating system level program
CN111143179A (en) * 2019-12-24 2020-05-12 中信银行股份有限公司 Method, device, storage medium and electronic equipment for positioning performance bottleneck
CN112988544A (en) * 2021-04-20 2021-06-18 北京国科环宇科技股份有限公司 Method, system, device and storage medium for analyzing performance bottleneck of operating system

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102541739B (en) * 2011-12-31 2016-01-13 曙光信息产业股份有限公司 The method of testing of (SuSE) Linux OS and device
US20130179144A1 (en) * 2012-01-06 2013-07-11 Frank Lu Performance bottleneck detection in scalability testing
CN103049245B (en) * 2012-10-25 2015-12-02 浪潮电子信息产业股份有限公司 A kind of software performance optimization method based on central processor CPU multi-core platform
US20150082107A1 (en) * 2013-09-19 2015-03-19 Jicksen JOY State machine based functional stress tests
CN112711521A (en) * 2021-03-25 2021-04-27 浙江华创视讯科技有限公司 Automatic performance testing method and system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108521353A (en) * 2018-04-02 2018-09-11 深圳前海微众银行股份有限公司 Processing method, equipment and the readable storage medium storing program for executing of positioning performance bottleneck
CN110580226A (en) * 2019-09-23 2019-12-17 上海创景信息科技有限公司 object code coverage rate testing method, system and medium for operating system level program
CN111143179A (en) * 2019-12-24 2020-05-12 中信银行股份有限公司 Method, device, storage medium and electronic equipment for positioning performance bottleneck
CN112988544A (en) * 2021-04-20 2021-06-18 北京国科环宇科技股份有限公司 Method, system, device and storage medium for analyzing performance bottleneck of operating system

Also Published As

Publication number Publication date
CN113778892A (en) 2021-12-10
CN113238973B (en) 2021-10-15
CN113238973A (en) 2021-08-10

Similar Documents

Publication Publication Date Title
US7086046B2 (en) Method and apparatus for displaying compiler-optimizated code
US7437706B2 (en) Automating the life cycle of a distributed computing application
US10394694B2 (en) Unexplored branch search in hybrid fuzz testing of software binaries
US20050278318A1 (en) Iterative development with prioritized build
Kim et al. Performance testing of mobile applications at the unit test level
JPH02217926A (en) Compiler
US20110145799A1 (en) Path-sensitive dataflow analysis including path refinement
CN112016099B (en) Method and system for analyzing static taint among binary program processes
CN116991381B (en) Application cross compiling method and device, computing equipment and storage medium
CN112882718A (en) Compiling processing method, device, equipment and storage medium
CN111049889A (en) Static resource uploading method and device, integrated server and system
CN114780173B (en) Method for loading plug-in application, computing device and storage medium
WO2022222378A1 (en) Kernel clipping method and computing device
CN114647416A (en) Method and device for realizing service flow based on annotation, storage medium and electronic equipment
CN111880803B (en) Software construction method and device applied to multiple platforms
CN113778892B (en) Method for locating performance bottleneck of operating system, computing device and storage medium
US7996824B2 (en) Benchmark synthesis using workload statistics
KR100640243B1 (en) Apparatus for improvement of applications performance in mobile communication terminal and method
US11847433B2 (en) Source code editing combining edit and continue with hot reload
CN113342698B (en) Test environment scheduling method, computing device and storage medium
CN112528273B (en) Medical data detection method, device, medium and electronic equipment
JP5067705B2 (en) Abnormal test support device, abnormal test support method, and program
US20080235653A1 (en) System and method for defining and dynamically invoking polymorphic call flows
US20230359547A1 (en) Targeted Testing for Modular Software Applications
KR101225577B1 (en) Apparatus and method for analyzing assembly language code

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant