KR20090081749A - The device and method of resource monitoring for application - Google Patents

Abstract

A resource monitoring method of application and an apparatus there are provided to grasp performance and the used amount of resources by S/W(Software) component and help to seek out an S/W component to focus for performance optimization. A plurality of execution component identification values of application is designated(41). A thread including the execution component identification values is produced(42). The execution information of the thread including the identification values is stored in a PCB(Process Control Block) data structure(43). In the PCB data structure, execution component resource information corresponding to the identification values is monitored(44).

Description

Application monitoring method and device thereof {THE DEVICE AND METHOD OF RESOURCE MONITORING FOR APPLICATION}

The present invention relates to a method and apparatus for resource monitoring for a single process based application consisting of a plurality of threads in an operating system.

CE (Customer Edge) companies, which have developed products using real-time operating systems (RTOS) such as VxWorks and pSOS, are gradually using virtual memory based systems such as Linux and WinCE to meet the demands of high performance and high performance. The trend is to develop products using high-performance operating systems.

In this process, the S / W platform and applications developed on the existing RTOS are often ported to an operating system such as Linux for commercial use. At this time, many execution components (hereinafter, referred to as 'S / W components') developed in the form of tasks on the RTOS, in order to minimize issues due to characteristics and porting such as address space sharing between tasks, In most cases, it is ported to a thread rather than a process.

A thread is a piece of a process that is divided into pieces. From a program's point of view, it is the information needed to service one individual user or a specific service request.

Every application has one thread for the main application. Threads can run with other threads, and each thread has an address for the process that manages it.

When multiple users are writing the program, or when requests are made simultaneously from other programs, a thread is created and maintained for each user or program. In other words, one process can create several threads to perform several tasks at the same time.

The thread tells the program which user is currently receiving the service, allowing the user to choose whether to reenter for other users. In other words, a thread refers to a series of instructions that are executed inside a process. A multi-threaded programming is a program in which several threads can be executed at the same time.

Today's computers can only execute one program instruction at a time. But because they run so fast, they only seem to run many programs at the same time and serve many users. In other words, if several threads are running at once, the threads run alternately for a given amount of time in the execution order.

A process control block (PCB) data structure (structure) for process / thread management is represented as an example of a general Linux operating system as shown in FIG. 1.

Each process or thread is managed by one task_struct, the Linux PCB structure, and each task_struct has a main field and a pid field to store its process name (ID) or thread name (ID). It has a tgid field to indicate the main process.

The values of pid and tgid of the main process are the same. Hereinafter, all threads created in the main process have different pid values, but tgid has the same value.

2 is a diagram illustrating an example of a Linux operating system including a related process / thread.

Referring to FIG. 2, as shown in the left figure (a), the application program 20 includes a variety of software programs such as a system library 21, an S / W platform 22, a third party library 23, an application 24, and the like. W components can be linked into a single executable and executed in a single process.

This application 20 is executed by being composed of a plurality of threads in one process, as in the PCB data structure for process / thread management in the Linux operating system shown in FIG. In this case, when the name of the application program 20 is "hello", the execution name (comm) of the main process and all the threads is the same as "hello".

In this case, each thread may identify the threads using the process ID or the value of pid, which is a field for storing the thread ID, described above in FIG. 1, but it is not possible to know which S / W component each thread belongs to. .

For example, as shown in FIG. 3, a single process application with multiple threads is shown.

Referring to FIG. 3, even in an application having a single process form, a large application composed of a plurality of threads may be configured and executed by many S / W components.

For example, even in the case of a digital TV (application), the H / W control library, window system library, DTV platform, various 3rd party libraries, and various applications provided by the DTV chipset vendor are included. Each thread can be created and operated.

In addition, each of these S / W components can be developed through outsourcing (outsourcing), the development subjects can all be different.

If the CPU usage of the digital TV application is very high or the memory usage is very high, you may want to analyze which S / W component is mainly CPU intensive or memory intensive.

As described above with reference to FIG. 2, in the current OS structure, only the pid field value is different for each thread, and since there is no information on which S / W component the thread belongs to, it is difficult to identify a problem location and find an improvement method.

In other words, there is no delimiter such as process name except the method of classifying by thread ID, so it is difficult to analyze performance and resource information for each thread group.

The present invention gives a thread group name to each thread, and provides a method for collecting and grouping and analyzing thread performance and resource information according to the name.

SUMMARY OF THE INVENTION An object of the present invention is a configuration for analyzing execution information for each S / W component constituting an application by grouping the threads on a specific basis in a single process application program consisting of a plurality of threads. To provide that method.

Another object of the present invention is to provide a method for more efficient operation by analyzing execution information for each S / W component constituting the application in a single process application program composed of a plurality of threads.

Another object of the present invention is to develop a plurality of threads for the application of a single process consisting of a plurality of threads can collect information on the CPU usage, memory usage, etc. for each S / W component (component) constituting the application To provide a way.

In order to solve the above problems, according to the first aspect of the present invention, the present invention is a resource monitoring method for a single process-based application consisting of a plurality of threads, for each of the plurality of execution components of the application Assigning an identification value, generating a thread including the identification value for each of the execution components, storing execution information of the thread including the identification value in a process control block (PCB) data structure, and the PCB The problem can be solved by using a resource monitoring method of an application program, the method comprising monitoring resource information for each execution component corresponding to the identification value in a data structure.

In order to solve the above problems, according to the second aspect of the present invention, in the resource monitoring method for a single process-based application program consisting of a plurality of threads, a plurality of executions allocated to the actual memory address area and executing The process that is returned after the system call is completed and the return address returned to the position of the return address of the designated program counter value before the application consisting of the component calls the system call. And determining the execution component of the memory address where the system call is actually called by checking the memory address to which the system call belongs, and automatically setting an identification value for each execution component. The problem can be solved by using a monitoring method.

Through the thread group based application profiling and resource monitoring technique of the present invention, developers can use the CPU usage and memory usage by software components for a single process application composed of multiple threads. It is possible to collect information about the back.

In the process of developing S / W components developed by many out-sourcing companies in a single process model, performance problems and resource overuse problems often cause problems in any S / W component. It was difficult to analyze.

However, it is possible to grasp the performance and resource usage of each S / W component for an application of a thread through the present invention, and may help to find the S / W component to be focused for performance optimization.

Hereinafter, the operating principle of the present invention will be described in detail with reference to the accompanying drawings. In the following description of the present invention, detailed descriptions of well-known functions or configurations will be omitted if it is determined that the detailed description of the present invention may unnecessarily obscure the subject matter of the present invention. Terms to be described later are terms defined in consideration of functions in the present invention, and may be changed according to intentions or customs of users or operators. Therefore, the definition should be made based on the contents throughout the specification.

4 is a flowchart illustrating a resource monitoring process of an application program according to the present invention.

The application program is composed of various execution components (hereinafter, referred to as 'S / W component'), and the S / W components may be linked to a single executable file and executed in a single process. This application program consists of a number of threads in one process.

Referring to FIG. 4, the application program designates an identification value that an operating system module managing the process under a single process can identify for each S / W component of the application in step 41.

In particular, according to an embodiment of the present invention, a method of specifying the identification value for each S / W component will be dealt with in FIGS. 5 and 6. In FIG. 5, a new system call having a function of specifying an identification value for each execution component is used, whereas in FIG. 6, a program counter (PC) of an application program calling the system call will be used. According to the implementation, the identification value for each S / W component may be set to a default value or may be changed according to application execution.

In step 42, the operating system module creates a thread for each S / W component having the identification value.

In step 43, the operating system module stores execution information of a thread including the identification value in a process control block (PCB) data structure. The operating system module manages both the process and the thread by the PCB data structure.

In this case, the PCB data structure is a data structure in which a field capable of storing the identification value is expanded.

In operation 44, the operating system module may group and analyze the S / W component based on the identification value among the execution information of the thread stored in the PCB data structure. Therefore, resource information for each S / W component can be monitored.

In addition, the operating system module may store execution information of the stored thread so that it can be used again later.

The grouping / analysis and monitoring process for each S / W component using the thread may be performed in the OS module, but may be performed in the application program or an external software program. A detailed description thereof will follow in FIG. 7 to be described later.

5 is a process control block (PCB) data structure (structure) using a new system call (clone2 ()) to which a thread group name (tgname) designation function is added in a Linux operating system according to an embodiment of the present invention. The figure which shows.

Software responsible for scheduling the operating system (here 'kernel' in Linux) manages both the process and the thread by means of the PCB data structure.

The application calls a system call (clone2 ()) that creates a thread to which a thread identification value (here, thread group name (tgname)) is added. At this time, the kernel provides a system call having the function.

The system call allows an application program in user mode to use kernel functions. When the system call is called, the system call is changed from user mode to kernel mode. When the system call is processed by the kernel, the system call is changed back to user mode. Change to continue working.

The application program creates a thread by specifying a thread group name (tgname) of a thread corresponding to each S / W component through the clone2 () system call. That is, an information field for identifying each S / W component is added and an appropriate name is set each time the thread is created.

The kernel stores information of a thread including the newly added information field tgname designated by the application program in a PCB structure task_struck.

For example, in the task_struct shown, if the thread whose pid is "1001", the field for remembering the ID of the process or thread, is the thread where the S / W component is created in subsystem "A", subsystem "A" is When creating a thread, add "A" to tgname, an added field to remember the group name of the S / W component.

Likewise, when "C" on the S / W platform creates a thread, "C" is specified for tgname to create a thread with pid "1002".

After creating the threads in this way, by collecting the execution information of each thread, grouping the threads having the same tgname (group), and based on this outputs the resource (resource) information such as CPU usage, Memory usage by thread group In addition, execution information for each S / W component can be analyzed. This will be described with reference to FIG. 7 to be described later.

FIG. 6 is a thread automatically using a program counter (PC; Program Counter) of an application calling a system call (eg, clone (), mmap (), etc.) in the Linux operating system according to another embodiment of the present invention. Is a diagram illustrating a method of specifying an identification value (thread group name (tgname)) of a node.

6 (b) shows a virtual address allocated to real memory by execution of the application program including each S / W component of (a). As shown, it can be seen that each S / W component is assigned to a specific virtual address in the corresponding address area.

In other words, the executable application program stored in the disk is loaded into the memory and under the control of the operating system.

(C) of FIG. 6 shows a group name (tgname) of a thread automatically using a program counter (PC; Program Counter) of an application program that calls a system call (eg, clone (), mmap (), etc.). A diagram illustrating the method.

As shown, the application allocated and running in the memory space (stack) calls a system call (e.g., clone (), mmap (), etc.) to the kernel as needed (step 61).

Since the system call allows the application program in the user mode to use the kernel function, when the system call is called, the system call is changed from the user mode to the kernel mode. When the system call is processed by the kernel, the system call is returned from the kernel mode to the user mode. Change to continue working.

That is, just before the system call is called, if the application program is executed, it is allocated to the stack of memory as described above (Application Run-time Stack) (step 62a).

Moreover, when the system call is called, the user mode of the application is suspended for a while and changed from the user mode to the kernel mode. In this case, the kernel allocates a stack to a memory stack including a program counter value that includes a return address corresponding to an address to be returned for execution of an application after the system call is completed. (Step 62b).

The stack is used when writing a variable (e.g. program execution) or calling a function (e.g. system call). Declaring the variable allocates space to a memory space called the stack. Moreover, when calling the function, the program counter value is put on the stack and called before calling the function. When the called function is executed, terminated and returned, the program counter value that was put on the stack is received as the current program counter value. Will return to the position of.

In this case, when using the program counter, which is a register having an address in the main memory where the next instruction to be stored is stored, the address of the instruction (system call) to be executed soon after each instruction (system call) is executed. The value pointed to is automatically incremented.

That is, when calling the system call, the program counter value is put on the stack and called before calling the system call. When the called system call is executed, terminated and returned, the program counter value stored on the stack is received as the current program counter value and returned to the original position (step 63).

Preferably, according to the present invention, the application program returned to the address value designated by the program counter after the system call is completed, the address value corresponds to a certain S / W component to the virtual address presented in (b) of FIG. If yes, determine (step 64).

That is, it will mean that the system call is actually called from the corresponding S / W component.

Accordingly, by checking the memory address to which the returned return address belongs, the system call may determine an execution component of the memory address actually called, and automatically set an identification value for each execution component (step 65). .

In addition, when the application creates a thread as needed, a thread including an identification value set for each execution component may be created.

Thereafter, execution information of the thread including the identification value may be stored in a PCB data structure, and resource information for each execution component corresponding to the identification value may be monitored in the PCB data structure.

In this case, as described above with reference to FIG. 5, the kernel of the corresponding operating system makes the application program into a data structure (PCB) suitable for control, reads it into memory, registers it in a process table of the kernel, and registers a memory, a file, an input / output device, Allocates resources, from which the application is executed as a process of the kernel.

The PCB data structure containing the information of the thread in which the identification value (for example, tgname (thread group name)) corresponding to each S / W component is set by the method described above in FIG. 6 is consequently the same as the embodiment shown in FIG. We will create a data structure containing the identifier information.

Therefore, the application program generates each thread for which an identification value (for example, tgname) is set for each S / W component, and the kernel collects execution information of each thread to group threads having the same tgname. have.

Based on this, by outputting resource (resource) information such as CPU usage and memory usage by thread group, execution information for each S / W component can be analyzed. This will be described with reference to FIG. 7 to be described later.

7 is a diagram illustrating a process of collecting execution information for each system component and thread-group.

Referring to FIG. 7, each S / W component of an application uses a group call of a thread through a system call such as a new clone2 () to which a group naming function of the thread described in FIG. 5 is added. tgname) to create a thread (Step 1). In this case, the system call interface of the illustrated kernel provides a system call to which the tgname designation function is added, such as clone2 ().

Alternatively, through the system call provided by the kernel such as clone (), mmap (), etc. described in FIG. 6, the thread group name for each corresponding S / W component using the program counter of the application program calling the system call. You can create a thread by setting (thname) automatically.

The kernel then calls a new thread and stores the tgname specified by the application in the PCB structure (step ②). The PCB (Process Control Block) structure here is a data structure in which the field is extended to store the tgname.

At this time, the illustrated Performance / Resource Info. Collector constantly asks the kernel to collect process / thread execution information (process ③).

The kernel collects execution information for each requested process / thread and displays Performance / Resource Info. Transfer to Monitoring Interface (step ④). Performance / Resource Info. Monitoring Inrerface is an interface for providing process / thread execution information from the kernel to an application program.

Thereafter, Performance / Resource Info. Monitoring Interface displays process / thread execution information in Performance / Resource Info. Deliver to Collector (step ⑤). Performance / Resource Info. Collector is the Performance / Resource Info. Through monitoring interface, process / thread information is continuously collected, stored in execution information repository, and provided to analysis tool.

In addition, the Performance / Resource Info. Collector saves the collected information in the execution information store so that it can be used again later (⑥ process).

Since, Performance / Resource Info. Analysis & Presentation analyzes collected and stored thread execution information, groups them based on thread group name delimiter (tgname), and analyzes the execution information for each thread group and provides them to users (⑦ process ).

Components such as an application program, a kernel, and the like shown in FIG. 7 may be included in the corresponding operating system module, and the operating system module supports resource monitoring for a single process based application program composed of a plurality of threads. In particular, the plurality of threads generated by the application program according to the present invention includes a thread group name that can be grouped by S / W components of the application program.

Preferably, the operating system module may provide the analyzed resource information to the user by dividing the thread including the thread group name for each S / W component.

Therefore, if the operating system module is applied to various devices such as a digital TV, it will help to improve the performance while solving the conventional problems described above in the present specification.

1 is a diagram illustrating a process control block (PCB) data structure (structure) for process / thread management in a general Linux operating system;

2 is a diagram illustrating a Linux operating system including a related process of a conventional process / thread;

3 illustrates a single process application with multiple threads;

4 is a flowchart illustrating a resource monitoring process of an application program according to the present invention;

FIG. 5 is a diagram illustrating a process control block data structure (structure) using a new system call (eg, clone2 ()) to which a thread group name (eg, tgname) designation function is added in a Linux operating system according to an embodiment of the present invention. drawing;

FIG. 6 is a thread automatically using a program counter (PC; Program Counter) of an application calling a system call (eg, clone (), mmap (), etc.) in the Linux operating system according to another embodiment of the present invention. A diagram illustrating a method of naming a group; And

7 is a diagram illustrating a process of collecting execution information for each system component and thread-group.

Claims (34)

In the resource monitoring method for a single process-based application consisting of a plurality of threads, Designating an identification value for each of a plurality of execution components of an application program; Creating a thread including the plurality of identification values for each of the execution components; Storing execution information of a thread including the identification value in a process control block (PCB) data structure; And monitoring resource information for each execution component corresponding to the identification value in the process control block data structure. The method of claim 1, The process of generating the thread uses a system call having a function of specifying an identification value for each of the execution components. The method of claim 2, Providing a system call having a function of specifying an identification value for each execution component is managed by a kernel of an operating system. The method of claim 3, wherein The process control block data structure is a resource monitoring method of an application program, characterized in that the field for storing the identification value is an extended data structure. The method of claim 1, The resource monitoring method of the application program resource monitoring method further comprises the step of storing the collected execution information in the storage for future use again. The method of claim 1, The resource information is a resource monitoring method of an application, characterized in that the CPU usage (CPU usage) or memory usage (Memory usage) for each execution component. The method of claim 1, The monitoring method of the resource of the application, characterized in that provided by the application or an external software program. The method of claim 1, The resource monitoring method of the application program is a resource monitoring method of an application program, characterized in that applied to a virtual memory-based operating system, such as WinCE, Linux. In the resource monitoring method for a single process-based application consisting of a plurality of threads, The system call to the position of the return address of the specified program counter value before the application program consisting of a plurality of execution components allocated and executed in the real memory address area calls the system call. Returned after this is completed; Checking the memory address to which the returned return address belongs, and determining an execution component of the memory address from which the system call is actually called, and automatically setting an identification value for each execution component. How an application monitors resources. The method of claim 9, Resource monitoring method for the application, When the application creates a thread as needed, generating a thread including an identification value set for each execution component; Storing execution information of a thread including the identification value in a process control block (PCB); And monitoring the resource information for each of the execution components corresponding to the identification value in the process control block data structure. The method of claim 10, The process control block data structure is a resource monitoring method of an application program, characterized in that the field for storing the identification value is an extended data structure. The method of claim 10, The resource monitoring method of the application program resource monitoring method further comprises the step of storing the collected execution information in the storage for future use again. The method of claim 10, The resource information is a resource monitoring method of an application, characterized in that the CPU usage (CPU usage) or memory usage (Memory usage) for each execution component. The method of claim 10, The monitoring method of the resource of the application, characterized in that provided by the application or an external software program. The method of claim 10, The identifier setting is a resource monitoring method of an application program, characterized in that managed by the kernel of the operating system (Kernel). The method of claim 10, The monitoring method of the resource of the application, characterized in that provided by the application or an external software program. The method of claim 10, The resource monitoring method of the application program is a resource monitoring method of an application program, characterized in that applied to a virtual memory-based operating system, such as WinCE, Linux. In a device that supports resource monitoring for a single process-based application composed of multiple threads, After designating an identification value for each execution component of an application program, a thread including the identification value for each of the execution components is generated, and execution information of a thread including the identification value is stored in a process control block (PCB). And an operating system module capable of monitoring resource information for each execution component corresponding to the identification value in the process control block data structure after storing the data in the data structure. The method of claim 18, The generation of the thread is characterized in that for using the system call (system call) having a function for specifying the identification value for each of the execution component. The method of claim 19, Providing a system call having a function of specifying an identification value for each execution component is managed by a kernel of an operating system. The method of claim 20, And said process control block data structure is an extended data structure in which a field capable of storing said identification value is extended. The method of claim 18, The electronic device stores the execution information in a storage for later use. The method of claim 18, The resource information is characterized in that the CPU usage (CPU usage) or memory usage (Memory usage) for each execution component. The method of claim 18, Wherein the monitoring is provided by the application program or an external software program. The method of claim 18, The device is characterized in that using a virtual memory based operating system, such as WinCE, Linux. In a device that supports resource monitoring for a single process-based application composed of multiple threads, The system consists of a number of execution components allocated and executed in a real memory address area before the system call calls a system call. Operating system that returns after the call is completed, checks the memory address to which the returned return address belongs, determines the execution component of the memory address where the system call is actually called, and automatically sets the identification value for each execution component. Device comprising a module. The method of claim 26, When the application program creates a thread as needed, the operating system module generates a thread including an identification value set for each execution component, and executes a process control block (PCB) of execution information of the thread including the identification value. And storing resource information of each of the execution components corresponding to the identification value in the process control block data structure. The method of claim 27, And said process control block data structure is an extended data structure in which a field capable of storing said identification value is extended. The method of claim 27, The electronic device stores the collected execution information in a storage for later use. The method of claim 27, The resource information is characterized in that the CPU usage (CPU usage) or memory usage (Memory usage) for each execution component. The method of claim 27, Wherein the monitoring is provided by the application program or an external software program. The method of claim 27, The identifier setting device, characterized in that managed in the kernel (Kernel) of the operating system. The method of claim 27, Wherein the monitoring is provided by the application program or an external software program. The method of claim 27, The device is characterized in that using a virtual memory based operating system, such as WinCE, Linux.

Images