JP6497234B2 - Control program, control method, and information processing apparatus - Google Patents

Description

  The present invention relates to a control program, a control method, and an information processing apparatus.

  In the operation verification of the software (program), in addition to the verification of the software function, the performance of the software is verified. The verifier measures the performance value of the software, and verifies the performance based on the determination as to whether or not the measured performance value satisfies a predetermined standard. For example, the verifier measures the performance value a plurality of times in order to obtain a highly accurate performance value.

  The verifier measures the performance value assuming an environment similar to the actual operating environment of the software. In the operation environment, an operation system and various software processes (processes not to be verified) operate in addition to processes to be verified (operation monitoring targets).

  The resource usage in the information processing apparatus that measures the performance value changes according to the operation state of the process that is not to be verified. As the resource usage changes, for example, the number of child processes that can be generated may vary, resulting in variations in performance values.

  The verifier extracts a significant performance value from the plurality of measured performance values, and verifies the performance based on an average value of the significant performance values.

  The techniques relating to the measurement of the performance value are described in Patent Documents 1 to 4.

International Publication No. 2008/072674 JP-A-7-129653 Japanese Patent Publication No. 7-74984 JP 2005-25372 A

  However, when performance value variation occurs, it is not easy to specify whether the performance value variation is caused by resource usage, software failure, verification environment setting error, or the like.

  Therefore, there is a method to identify the cause of performance value variation by obtaining the trace of the system call of the process at the time of measurement and grasping the operation status of the child process corresponding to the process to be verified (operation monitoring target). is there. However, acquiring the system call trace increases the load on the information processing apparatus, and the operation of the software differs from that during actual operation.

  As described above, it is not easy to grasp the operation status of the child process corresponding to the verification target process without changing the operation during actual operation.

  In one aspect, an object of the present invention is to provide a control program, a control method, and an information processing apparatus that support grasping of an operation state of a child process corresponding to a process to be monitored.

  According to the first aspect, the generation of the child process of the target process is detected in response to reading of the execution file instructing the computer to execute the generation of the child process of the target process by the target process of operation monitoring. In response to occurrence of access to the storage unit or the network by the target process after the generation of the child process is detected, it is determined whether or not the child process is in operation. When the determination is made, the end of the child process is detected, and the information related to the access by the target process corresponding to the timing at which the generation of the child process and the end of the child process are detected is used as identification information for identifying the child process. It associates and memorize | stores in a memory | storage part.

  In one aspect, it assists in grasping the operation status of a child process corresponding to a process subject to operation monitoring.

It is a figure which shows the structure of the verification system in this Embodiment. It is a figure explaining the process which operate | moves with the information processing apparatus 100 shown in FIG. It is a figure which shows an example of the operation state of each process shown in FIG. 2 from the measurement start of a performance value to completion | finish. FIG. 10 is a diagram for explaining an example in which a process px to be verified generates five child processes pxc-1 to pxc-5 and executes five processes in parallel. It is a figure explaining the process px to be verified produces | generates the four child processes pxc-1 to pxc-4, and performs four processes in parallel. It is a figure explaining the example from which the process of the process px to be verified differs according to predetermined conditions. It is a figure which illustrates typically the process which acquires CPU execution time of each process regularly. It is a figure which illustrates the outline | summary of the process in this Embodiment typically. It is a figure which shows an example of the log information 50 which the driver program 10 of this Embodiment produces | generates. It is a hardware block diagram of the information processing apparatus 100 (FIG. 1, FIG. 2) in this Embodiment. It is a block diagram of the software block of the driver program 10 shown in FIG. FIG. 12 is a diagram illustrating an example of a verification target process table 60a and a process generation address table 60b illustrated in FIG. 11. It is a figure which shows an example of the child process management table 60c shown in FIG. It is a figure explaining the log information 50-1x of another form of the 1st log information 50-1. It is a 1st figure explaining the example from which a performance value fluctuates according to execution of the process py which is not verification object. It is a 2nd figure explaining the example from which a performance value fluctuates according to execution of the process py which is not verification object. It is a figure which shows an example of the 2nd log information 50-2. An arrow Y11 in FIG. 17 indicates the CPU execution time. It is a figure which shows an example of the candidate process table 60d shown in FIG. FIG. 12 is a flowchart illustrating a processing flow of the driver program 10 illustrated in FIG. 11. It is a figure which shows the measurement parameter 70-1 of a 1st execution process, and the re-measurement parameter 70-2. It is a flowchart figure explaining the flow of a process of a 1st execution process (S11 of FIG. 19). It is a figure which shows an example of the process management table 80 at the time of a measurement. It is a 1st flowchart figure explaining the flow of the determination process of remeasurement shown to process S26 of FIG. It is a 2nd flowchart figure explaining the flow of the determination process of the remeasurement shown to process S26 of FIG. It is a flowchart figure explaining the flow of a process of a 2nd execution process (S12 of FIG. 19). FIG. 25 is a first flowchart illustrating the process of the log information generation module 114 in step S65 of FIG. 24. It is a 2nd flowchart figure explaining the process of the log information generation module 114 of process S65 of FIG. It is a figure which shows an example of the measurement result information.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. However, the technical scope of the present invention is not limited to these embodiments, but extends to the matters described in the claims and equivalents thereof.

[Verification system]
FIG. 1 is a diagram illustrating a configuration of a verification system according to the present embodiment. The verification system illustrated in FIG. 1 includes an information processing apparatus 100, a client apparatus 40, and a storage apparatus SD. The information processing apparatus 100 is connected to the client apparatus 40 and the storage apparatus SD.

  The verification system shown in FIG. 1 verifies the performance by measuring the performance of the verification target software 20 operating on the information processing apparatus 100 and determining whether the measured performance satisfies a predetermined standard. In the information processing apparatus 100, an operation system (not shown in FIG. 1) operates, and the verification target software 20 operates on the operation system. Further, the verification target software 20 calls, for example, the driver program 10 that performs access (ay) to the storage apparatus SD as a subroutine (ax).

  Next, a series of flow of performance value measurement of the verification target software 20 will be described. The client device 40 instructs the verification target software 20 to start a predetermined process as a performance value measurement target (st). In response to the instruction from the client device 40, the verification target software 20 performs a predetermined process using the test data stored in the storage device SD. The verification target software 20 repeats, for example, reading test data, processing the read data, writing data to the storage device SD, and the like as predetermined processing.

  When the predetermined process ends, the verification target software 20 notifies the client apparatus 40 of the end of the process (ed). The client device 40 acquires the response time (also referred to as processing time) from the start instruction to the end notification as a performance value.

  In order to perform verification based on a highly accurate performance value, for example, the verification system measures the performance value multiple times. For example, the verifier determines a significant performance value from a plurality of performance values, and determines whether or not the performance value satisfies a predetermined criterion based on an average value of the significant performance values.

  In this embodiment, the verification target software 20 is, for example, software of a database management system (DBMS). The DBMS software performs access to a database in response to an access request. Note that the verification target software 20 is not limited to the DBMS software example, and may be file system software, software that performs arithmetic processing based on data, or the like.

  Also, the verification system constructs an environment assuming the operating environment and measures the performance value in order to measure the performance value according to the operating environment in which the software 20 to be verified is actually used. Therefore, in the information processing apparatus 100, in addition to the verification target software 20 and the operation system, the software (not shown in FIG. 1) that operates on the operation system and that is not the performance verification target operates.

  FIG. 2 is a diagram illustrating a process that operates in the information processing apparatus 100 illustrated in FIG. 2 that are the same as those shown in FIG. 1 are denoted by the same symbols. FIG. 2 shows the information processing apparatus 100 described in FIG. 1, the test program 30 operating on the client apparatus 40, and the storage apparatus SD.

  As described above, in the information processing apparatus 100, in addition to the verification target software 20, an operation system and non-verification target software operate. Therefore, as shown in FIG. 2, in the information processing apparatus 100, in addition to the verification target software processes px1 to px3 and pxc, the operation system process pz and the non-verification target software processes py1 and py2 operate. .

  The rectangles px1 to px3 and pxc indicated by horizontal lines in FIG. 2 indicate processes of the software 20 to be verified. A process pxc indicates a process generated by the process px3. The processes px1 to px3 and pxc include a resident process and a non-resident process. In the example of FIG. 2, processes px1 to px3 indicate resident processes, and process pxc indicates a nonresident process.

  The resident processes px1 to px3 indicate processes that are generated when the software 20 to be verified is started and are ended when the software 20 ends, for example. On the other hand, the non-resident process pxc is a process that is generated at any timing from the start of the verification target software 20 to the end thereof, or indicates a process that ends.

  Hereinafter, the processes px1 to px3 are referred to as a process px to be verified, and the process pxc is referred to as a child process. Also, the operation system process pz and the non-verification software processes py1 and py2 illustrated in FIG. 2 are referred to as non-verification process py.

  In the example of FIG. 2, the process px1 receives an instruction to start a predetermined process by the test program 30 (st), and notifies the test program 30 of the end when the predetermined process ends (ed). The processes px1 to px3 perform interprocess communication with each other, and transmit and receive data, instructions, and the like.

  In the example of FIG. 2, the process px3 (also referred to as a parent process) generates a child process pxc in the middle of a predetermined process, and instructs the child process pxc according to inter-process communication. In the example of FIG. 2, the process px3 and its child process pxc call the driver program 10 as a subroutine to access the storage device SD (ax).

[Operation status of each process from measurement start to end]
Next, the operation state of each process shown in FIG. 2 from the start to the end of the performance value measurement will be described with reference to FIG.

  FIG. 3 is a diagram illustrating an example of an operation state of each process illustrated in FIG. 2 from the start to the end of the performance value measurement. In FIG. 3, the same components as those shown in FIGS. 1 and 2 are denoted by the same symbols. An arrow tt shown in FIG. 3 indicates the passage of time.

  3 indicate periods tpx1 to tpx3 in which a CPU (Central Processing Unit: CPU) is used by the processes to be verified px1 to px3 illustrated in FIG. On the other hand, the blank rectangles indicate periods tpy1 to tpy2 in which the CPU is used by the processes py1 and py2 that are not verification targets illustrated in FIG. Also, the hatched rectangle indicates a period io of an I / O (Input / Output) waiting state by the processes px1 to px3 to be verified. An arrow tx indicates a period during which no process is using the CPU.

  An operation system that operates on the information processing apparatus 100 executes processing of each process by sequentially assigning CPU time to each process. For example, the operation system switches the CPU assignment to another process when the time for which each process uses the CPU exceeds the assigned time or when the process waits for I / O or the like. .

  According to the example of FIG. 3, the operation system assigns CPUs in the order of process px1, process px2, and process px3 (tpx1 to px3). When the CPU detects that the process px3 waits for I / O while the CPU is allocated to the process px3, the operation system switches the CPU allocation to the process py1. Until the I / O waiting period tio ends, a period tx in which no process uses the CPU occurs.

  When detecting the end of the I / O waiting period tio, the operation system reassigns the CPU to the process px3. When re-detecting the occurrence of I / O waiting by the process px3, the operation system switches the CPU allocation to the process py2. When detecting the end of the I / O waiting period tio, the operation system reassigns the CPU to the process px3 in accordance with the end of the assignment of the CPU to the process py2. Similarly, the operation system sequentially assigns a CPU to each process.

  As described with reference to FIGS. 2 and 3, in the information processing apparatus 100, in addition to the process px to be verified, a process py that is not a verification target operates, and each process shares resources such as a CPU resource with each other. . Accordingly, the usage status of resources such as the CPU and the memory changes according to the operating status of the process py that is not verified.

  The amount of resources that can be used by the process px to be verified changes due to changes in the resource usage status. Therefore, the measured value of the performance value may vary depending on the operation status of the process py that is not subject to verification at the time of measurement. Thereby, for example, when the performance value is measured a plurality of times, a variation may occur between the plurality of performance values.

  The verification target software 20 may have a specification for performing a specific process when a predetermined condition is met. Thereby, depending on whether or not a predetermined condition is met, the processing of the process px to be verified may change and the performance value may change. As a result, in the same manner as when the resource usage status changes, there may be variations among the plurality of performance values.

[Variation of performance values]
Next, an example in which performance value variation occurs will be described with reference to FIGS. 4 and 5 illustrate a case where the process px to be verified generates a plurality of child processes pxc (fk), and the processes are executed in parallel according to the child processes pxc. FIG. 6 illustrates a case where a child process pxc is generated and a specific process is performed by the child process pxc when the verification process px matches a predetermined condition.

(When processing is executed in parallel)
The example of FIGS. 4 and 5 exemplifies a case where the process px to be verified executes a predetermined process 10 times after starting the service and measures the processing time until the service is ended as a performance value. According to the examples of FIGS. 4 and 5, the process px to be verified generates a plurality of child processes pxc after the service is started in order to execute predetermined processing in parallel.

  FIG. 4 is a diagram illustrating an example in which the process px to be verified generates five child processes pxc-1 to pxc-5 and executes the five processes in parallel. 4, the same components as those shown in FIGS. 1 and 2 are denoted by the same symbols. An arrow tm1 shown in FIG. 4 indicates a processing time (response time) from the start of the service to the end, that is, a performance value.

  In response to the service start instruction from the test program 30, the verification target process px generates a plurality of child processes pxc-1 to pxc-5. At this time, the process px to be verified generates five child processes pxc-1 to pxc-5 according to the resource usage status of the information processing apparatus 100 (fk).

  After generation of the child processes pxc-1 to pxc-5, the process px to be verified instructs each of the child processes pxc-1 to pxc-5 to execute predetermined processing. Thereby, the child processes pxc-1 to pxc-5 execute predetermined processes in parallel, and perform five processes. The process px to be verified waits until the child processes pxc-1 to pxc-5 finish the predetermined process (tp), and waits for instructions for executing the remaining five processes.

  When the child processes pxc-1 to pxc-5 end the predetermined process, the verification process px further instructs the child processes pxc-1 to pxc-5 to execute the predetermined process. Therefore, the child processes pxc-1 to pxc-5 again execute predetermined processing in parallel. When the process ends, the process px to be verified ends the child processes pxc-1 to pxc-5 and ends the service.

  In the example of FIG. 4, the process px to be verified generates five child processes pxc-1 to pxc-5. Therefore, the verification target software 20 can execute five predetermined processes in parallel.

  FIG. 5 is a diagram illustrating an example in which the process px to be verified generates four child processes pxc-1 to pxc-4 and executes the four processes in parallel. 5 that are the same as those shown in FIG. 4 are indicated by the same symbols.

  In the example of FIG. 5, the process px to be verified can generate only four child processes pxc-1 to pxc-4 as compared to the example of FIG. 4 (fk). Therefore, the verification target software 20 executes four predetermined processes in parallel. When the child processes pxc-1 to pxc-4 finish the predetermined process, the verification process px further instructs the child processes pxc-1 to pxc-4 to execute the predetermined process. As a result, the verification target software 20 executes eight processes.

  Since the process for two times remains, in response to the end of the process, the verification process px further instructs the child processes pxc-1 and pxc-2 to execute a predetermined process, and the child process pxc- 1, pxc-2 executes two processes in parallel. When the process ends, the process px to be verified ends the child processes pxc-1 to pxc-4 and ends the service.

  According to the example of FIG. 5, since the process px to be verified can generate only four child processes pxc-1 to pxc-4, the degree of parallelism of processing is lower than that of the example of FIG. Therefore, the processing time tm2 of the example of FIG. 5 is longer than the processing time tm1 of the example of FIG.

  As described above, when a sufficient number of child processes pxc can be generated (FIG. 4), the degree of parallelism of processing becomes high and the processing time can be shortened. On the other hand, when a sufficient number of child processes pxc cannot be generated (FIG. 5), the degree of parallelism of processing decreases, and the processing time is longer than when a sufficient number of child processes pxc can be generated.

  Although not shown in FIGS. 4 and 5, when a sufficient number of child processes pxc cannot be generated, additional child processes pxc may be additionally generated according to the resource vacancy generated during the processing. In this case, the processing time is a time between the processing times tm1 and tm2 in FIGS.

  In this way, depending on how many processes the child process pxc generates when the process px to be verified is performing depending on the resource usage status of the information processing apparatus 100, the processing time (performance value) ) Will change. Therefore, when the performance value is measured a plurality of times, variation may occur between the plurality of performance values.

(Difference in processing according to predetermined conditions)
FIG. 6 is a diagram illustrating an example in which the process px to be verified is different depending on a predetermined condition. In FIG. 6, the same components as those shown in FIGS. 1 and 2 are denoted by the same symbols.

  In the example of FIG. 6, the processing time tm11 from the start of the service (st) to the end (ed) is measured as a performance value in the same manner as the examples of FIGS. According to the example of FIG. 6, the process px to be verified is generated during execution of the service, and when the data lg accumulated in the internal memory (not shown) exceeds a predetermined amount, the data lg is stored in the storage device SD. Write.

  Specifically, the process px to be verified responds to a service start instruction from the test program 30 (st), performs predetermined processing, generates data lg, and stores it in the internal memory. The process px to be verified generates data lg for each predetermined process and stores it in the internal memory. The process px to be verified generates a child process pxc when the accumulated data lg exceeds a predetermined amount (fk), and writes the data lg from the internal memory to the storage device SD via the child process pxc ( ax, ay).

  According to the example of FIG. 6, the process px to be verified generates 32 data lg in one measurement. The process px to be verified generates a child process pxc when the data lg in the internal memory reaches 200, and causes the child process pxc to store 200 data lg in the storage device SD. Therefore, there are a measurement time when writing to the storage device SD occurs and a time when the writing does not occur.

  According to the example of FIG. 6, in the measurement times such as the seventh time, the 13th time, and the 19th time, the data lg in the internal memory reaches 200 pieces, and the data lg is written to the storage device SD. Therefore, there is a difference in the presence or absence of writing to the storage device SD between the first to sixth measurement times and the seventh measurement time, and the processing time tm11 is different. Similarly, the 13th measurement time and the 19th measurement time are different from each other in the processing time tm11.

  The processing time tm11 of the measurement times when writing to the storage device SD occurs is longer than the processing time tm11 of the measurement times when writing does not occur. If the writing occurs during the I / O waiting time by the process px to be verified, the processing time tm11 approximates that the writing does not occur.

  As described above, the processing time (performance value) varies depending on which process the verification target process px is performing, depending on whether the child process pxc is generated. As a result, when the performance value is measured a plurality of times, variations may occur between the plurality of performance values.

  As shown in FIGS. 4 to 6, the performance value may vary. Therefore, the verification system varies during the measurement in order to identify whether the performance value variation is caused by the failure of the software 20 to be verified or the example shown in FIGS. Collect information that can identify the cause of the problem.

[Collect information]
Next, an example of collecting information at the time of measurement will be described. First, an example of acquiring a system call trace and second, an example of acquiring a CPU execution time will be described.

(System call trace)
First, the verification system uses a function of the operation system to trace a system call issued by each process when the performance value is measured. Specifically, the verification system activates the process px to be verified by performing a setting for acquiring a trace of the system call together with a time stamp (time).

  The verifier can grasp the processing flow of each process based on the trace of the system call corresponding to the time of each process. Further, the verifier can grasp the processing correspondence between the processes by matching the traces of the system calls of the respective processes based on the time. Thereby, the verifier can grasp which process the verification target process px is executing, and whether the child process pxc is generated or terminated.

  Therefore, in the examples of FIGS. 4 and 5, the verifier can grasp how many child processes pxc are generated when the process px to be verified is performing. Similarly, in the example of FIG. 6, the verifier can grasp which process the verification target process px is performing and generate the child process pxc. As a result, in the example of FIGS. 4 to 6, it is possible to specify which factor caused the variation in the performance value.

  However, collecting the trace increases the load on the operation system and increases the processing time of each process. Due to the increase in load and processing time, the operation changes during normal operation. As an example, when the verification target software 20 includes a specification for detecting a timeout when a certain period of time has elapsed, timeout may occur frequently as the processing time increases, and the processing may end abnormally. Alternatively, when specific processing is performed at regular intervals, the specific processing operates more than during normal operation due to an increase in processing time.

  In addition, the trace area of the operation system may overflow due to the huge amount of trace data. When the trace data is written to a disk or the like before the overflow occurs, the processing time is further increased.

  Thus, by collecting the trace of the system call, it becomes possible to identify the cause of the variation in the performance value, while the processing of the verification target software 20 at the time of measurement changes from the processing at the time of actual operation. Performance values measured in an environment where processing differs from actual operation are not appropriate.

  Further, for example, there is a method of tracing only system calls related to generation and termination of the child process pxc among the system calls. Thereby, it becomes possible to suppress the load concerning acquisition of a trace. Alternatively, there is a method of incorporating in the operation system a function for notifying a predetermined program that the child process pxc has been generated at the timing when the process px to be verified has generated the child process pxc.

  By extracting and collecting information related to generation and termination of the child process pxc, it is possible to grasp the time required for generation and termination of the child process pxc. However, it is difficult to grasp whether the child process pxc is generated or terminated when the process px to be verified is executing.

(Collecting CPU execution time)
Second, the verification system periodically acquires the CPU execution time of each process when measuring the performance value. The CPU execution time indicates the operating time of the CPU of the information processing apparatus 100, and indicates the time (total number) that each process occupies the CPU for execution of processing.

  FIG. 7 is a diagram schematically illustrating processing for periodically acquiring the CPU execution time of each process. 7, the same components as those shown in FIG. 6 are denoted by the same symbols. As illustrated in FIG. 7, the verification system acquires the CPU execution time of each process at regular intervals (tt1 to tt5).

  The verifier grasps in which time zone the child process pxc was operated based on the CPU execution time of each process at regular intervals (tt1 to tt5). For example, when the CPU execution time of the new child process pxc is detected at the timing tt4, it can be grasped that the child process pxc is generated in the time zone from the timing tt3 to tt4. Thereby, the verifier can grasp | ascertain the time slot | zone when the child process pxc was produced | generated.

  However, based on the CPU execution time at regular intervals, the CPU execution time of the verification target process px can be acquired in the time zone when the child process pxc was generated, but the processing of the verification target process px is grasped. It is difficult. Therefore, in the examples of FIGS. 4 to 6, it is possible to grasp which process the verification target process px is performing and how many child processes pxc are generated when the child process pxc is generated. It is difficult.

  As described above, it is not easy to collect information indicating the operation status of the child process corresponding to the process px to be verified without changing the process during actual operation.

[Outline of this embodiment]
Therefore, the information processing apparatus 100 according to the present embodiment detects the generation of the child process pxc in response to the reading of the execution file for executing the generation of the child process pxc by the operation monitoring target process px. Then, the information processing apparatus 100 determines whether or not the child process pxc is operating according to the access to the storage unit or the network by the target process px after the generation of the child process pxc is detected. To do. If it is determined that the information processing apparatus 100 is not operating, the information processing apparatus 100 detects the end of the child process pxc.

  Then, the information processing apparatus 100 stores, in the storage unit, information related to access by the target process px corresponding to timings at which generation and termination of the child process pxc are detected in association with identification information for identifying the child process pxc. The storage unit is, for example, the main memory or the storage device SD of the information processing apparatus 100.

  FIG. 8 is a diagram schematically illustrating an outline of processing in the present embodiment. In FIG. 8, the same components as those shown in FIGS. 1 and 2 are denoted by the same symbols. In FIG. 8, an execution file ex stored in the storage device SD indicates a program that instructs generation of a child process pxc of the verification target process px. The execution file ex may be stored in a memory or the like of the information processing apparatus.

  FIG. 8 illustrates a case where the process px to be verified generates a child process pxc in the middle of processing (fk). In the example of FIG. 8, among the accesses ax1 to ax8 to the storage apparatus SD by the process px to be verified, the access ax4 indicates reading from the execution file ex instructing generation of the child process pxc. Accesses ax11 and ax12 indicate access to the storage device SD by the child process pxc, and a period ch indicates a generation period of the child process pxc.

  The generation of the child process pxc is realized by, for example, reading the execution file ex describing the generation instruction of the child process pxc (ax4) and giving the execution authority by the operation system pz. Therefore, the driver program 10 according to the present embodiment detects the generation of the child process pxc when reading the execution file ex that instructs generation of the child process pxc.

  Then, after generating the child process pxc, the driver program 10 determines whether or not the generated child process pxc is operating every time ax5 to ax7 are accessed with respect to the storage device SD. According to the example of FIG. 8, the driver program 10 detects that the generated child process pxc has ended at the timing of access ax7.

  Then, the driver program 10 stores, as log information 50, information related to access by the process px to be verified at timings ax4 and ax7 at which generation of the child process pxc and the end of the operation are detected, in association with identification information of the child process pxc. Store in the department. Hereinafter, information related to access is referred to as access information.

  The access information in the present embodiment is, for example, one or both of an access sequence number (order information) and an access target address. However, the access information is not limited to this example. The access information may be, for example, the size of data to be accessed and the content of the data.

(Log information)
FIG. 9 is a diagram illustrating an example of log information generated by the driver program 10 according to the present embodiment. The log information shown in FIG. 9 is referred to as first log information 50-1.

  Information le1 illustrated in FIG. 9 indicates access information of the verification target process px corresponding to the timing at which generation of the child process pxc is detected. The information le2 indicates the access information of the process px to be verified corresponding to the timing when the end of the child process pxc is detected. The information le2 includes identification information “iD001” of the execution file ex and process ID “6789” of the child process pxc as identification information of the child process pxc.

  Based on the identification information “iD001” of the execution file ex, it is possible to specify which processing program has been executed. In the example of FIG. 9, the access information is an address to be accessed.

  Based on the access information, the verifier who detects the content of the process can grasp the process of the process px to be verified when the access occurs. In other words, the verifier can grasp which process is being performed when the access information is accessed by the process px to be verified.

  Therefore, by recording the access information of the generation timing and termination timing of the child process pxc in correspondence with the information of the child process, the generation of the child process pxc is performed when any process is being performed by the process px to be verified. And it becomes possible to grasp whether the termination has occurred. Alternatively, based on the identification information of the child process, it is possible to grasp how many child processes pxc are generated when the verification process px performs any processing.

  Accordingly, in the example of FIGS. 4 and 5, the verifier can grasp how many child processes pxc are generated when the process px to be verified is executing. Further, in the example of FIG. 6, the verifier can grasp which process the verification target process px is executing has generated the child process pxc that stores the data lg in the storage device SD. .

  In addition, since the driver program 10 according to the present embodiment stores only access information, it is possible to suppress an increase in load due to collection of information and an increase in processing time. In this way, the driver program 10 collects information indicating the operation status of the child process corresponding to the process px to be verified without changing the actual operation and processing by storing the minimum information. Can do. As a result, it is possible to efficiently identify the cause of the variation in the performance value.

  In the examples of FIGS. 8 and 9, the case where the access by the process px to be verified is the access to the storage device SD is illustrated. However, it is not limited to this example. Access by the process px to be verified may be access to another storage unit or a network. The access to the network is, for example, transmission / reception of information to / from another process or another apparatus by the process px to be verified.

  For example, in addition to access to the storage unit, the driver program 10 detects transmission / reception of information by the process px to be verified, and stores the access information. The access information indicates, for example, information on information transmission / reception destinations and data to be transmitted / received. As described above, by recording the access information of the network access, it becomes possible to grasp the processing at the time of the access occurrence by the process px to be verified in the same manner.

  Next, a hardware configuration of the information processing apparatus 100 according to the present embodiment will be described with reference to FIG. 10, and a software block diagram of the information processing apparatus 100 according to the present embodiment will be described with reference to FIG.

[Hardware Configuration of Information Processing Apparatus 100]
FIG. 10 is a hardware configuration diagram of the information processing apparatus 100 (FIGS. 1 and 2) according to the present embodiment. The information processing apparatus 100 includes, for example, a CPU (Central Processing Unit: CPU) 101, a memory 102 including a main memory 201, an auxiliary storage device 202, and the like, a communication interface unit 103, and an external interface unit 104. Each unit is connected to each other via a bus 106.

  The CPU 101 is connected to the memory 102 and the like via the bus 106 and controls the information processing apparatus 100 as a whole. The communication interface unit 103 is connected to another device (not shown) via the Internet or the like, and accesses the network. A main memory 201 indicating a RAM (Random Access Memory: RAM) or the like stores data or the like that is processed by the CPU 101. The external interface unit 104 is connected to the storage device SD and the like.

  The auxiliary storage device 202 includes an area (not shown) for storing an operating system program executed by the CPU 101. The auxiliary storage device 202 includes a software program storage area 20, a driver program storage area 10, and a test program storage area 30. The auxiliary storage device 202 has a log information storage area 50 and a parameter file group storage area 60. The auxiliary storage device 202 represents a hard disk drive (HDD), a nonvolatile semiconductor memory, or the like.

  A software program in the software program storage area 20 (hereinafter referred to as software program 20) realizes processing of the software program (software to be verified) 20 by execution of the CPU 101. As described above, the software program 20 is, for example, DBMS software.

  The test program 30 in the test program storage area 30 (hereinafter referred to as the test program 30) realizes the processing of the test program 30 by the execution of the CPU 101. The test program 30 instructs the software program 20 to start and end the test.

  A driver program in the driver program storage area 10 (hereinafter referred to as the driver program 10) realizes access processing to a storage unit such as the storage device SD and the main memory 201, a network, and the like by execution of the CPU 101.

  In response to the access command from the software program 20, the driver program 10 performs processing corresponding to the command and outputs the processing result to the software program 20. Details of the driver program 10 will be described later according to the software block diagram of FIG. For example, the verifier replaces the driver program included in the operation system (not shown) with the driver program 10 in the present embodiment when measuring the performance value.

  The log information (hereinafter referred to as log information 50) in the log information storage area 50 is information generated by the driver program 10, and indicates the first log information 50-1 as shown in FIG. The log information 50 may be stored in the storage device SD.

  The parameter file group (hereinafter referred to as parameter file group 60) in the parameter file group storage area 60 is information referred to by the driver program 10. Details of each parameter file included in the parameter file group 60 will be described later with reference to FIG.

[Software Block of Information Processing Device 100]
FIG. 11 is a configuration diagram of software blocks of the driver program 10 shown in FIG. The driver program 10 includes, for example, a control module 111, an access module 112, an execution management module 113, and a log information generation module 114.

  The control module 111 controls the modules 111 to 114. The access module 112 detects access to the storage unit, the network, and the like by the process of the software 20 to be verified, and executes processing corresponding to the access.

  The execution management module 113 refers to the parameter file group 60 and determines whether or not to re-measure the performance value for collecting the log information 50 when measuring the performance value of the process px to be verified. When performing remeasurement of the performance value, the execution management module 113 instructs the log information generation module 114 to generate the log information 50.

  The log information generation module 114 refers to the parameter file group 60 and detects the generation and termination of the child process pxc. Then, the log information generation module 114 stores, as log information 50, access information of access by the process px to be verified and identification information of the child process pxc at the timing when the generation and termination of the child process pxc are detected.

  The parameter file group includes a verification target process table 60a, a process generation address table 60b, a child process management table 60c, and a candidate process table 60d. The verification target process table 60a and the process generation address table 60b will be described with reference to FIG. The child process management table 60c will be described later according to FIG. 13, and the candidate process table 60d will be described later according to FIG.

  FIG. 12 is a diagram illustrating an example of the verification target process table 60a and the process generation address table 60b illustrated in FIG.

[Verification target process table 60a]
FIG. 12A illustrates an example of the verification target process table 60a illustrated in FIG. The verification target process table 60a includes identification information (for example, process name) of the verification target process px. Specifically, the verification target process table 60a illustrated in FIG. 12A includes process names “mwproc” and “mwprv” of the verification target process px.

[Process generation address table 60b]
FIG. 12B is a diagram illustrating an example of the process generation address table 60b illustrated in FIG. The process generation address table 60b has an address of an execution file ex instructing generation of a child process pxc of the verification target process px shown in the verification target process table 60a of FIG.

  The process generation address table 60b shown in FIG. 12B has addresses “0x101abdd0” and “0x10205a00”. Therefore, the driver program 10 detects the generation of the child process pxc when the process px to be verified accesses the addresses “0x101abdd0” and “0x10205a00”.

[Child Process Management Table 60c]
FIG. 13 is a diagram showing an example of the child process management table 60c shown in FIG. The log information generation module 114 generates a child process management table 60c. The child process management table 60c includes information Y1 of the process ID (identifier: ID) of the process px to be verified, the number Y2 of the child processes pxc, and information Y3 of the process ID of the child process pxc.

  According to the example of FIG. 13, the child process management table 60c includes the information Y1 of the process ID “011” of the process px to be verified and the number “3” of the generated child processes pxc for the software 20 with the sequence number “1”. Y2. The child process management table 60c includes information Y3 of process IDs “175, 176, 179” of the three child processes pxc.

[Another form of the first log information 50-1]
Note that the driver program 10 may further store access information at a timing different from the timing at which generation and termination of the child process pxc is detected, according to the occurrence of access by the verification target process px. Next, according to FIG. 14, another form of the first log information 50-1 shown in FIG. 9 is illustrated.

  FIG. 14 is a diagram illustrating another form of log information 50-1x of the first log information 50-1. The first log information 50-1x illustrated in FIG. 14 includes the information le1 and le2 of the first log information 50-1 illustrated in FIG. Specifically, the information le12 illustrated in FIG. 14 corresponds to the information le1 (FIG. 9), and the information le14 illustrated in FIG. 14 corresponds to the information le2 (FIG. 9).

  Information le11 illustrated in FIG. 14 indicates access information by the process px to be verified at a timing different from the timing at which generation and termination of the child process pxc is detected. In this way, by further based on the access information le11 at a timing different from the timing at which the generation and termination of the child process pxc is detected, the processing contents of the process px to be verified can be grasped in more detail.

  Therefore, it is possible to grasp with high accuracy whether the generation and termination of the child process pxc occurred during execution of the process px to be verified, and it is possible to specify the cause of the dispersion of the performance value with higher accuracy. Become.

  Further, the driver program 10 may further store information related to the access of the child process pxc in response to the occurrence of the access of the child process pxc. Information le13 illustrated in FIG. 14 indicates access information by the child process pxc. Based on the access information le13 of the child process pxc, the contents of the process of the child process pxc can be grasped.

  Therefore, in addition to the generation and termination of the child process pxc, it is possible to grasp which process of the verification target process px is executed while the child process pxc is executing which process. As a result, it is possible to specify the cause of the variation in the performance value with higher accuracy.

  Although not shown, the driver program 10 further associates information on access corresponding to the timing at which the end of the child process pxc is detected with the execution time (CPU execution time) used by the CPU to execute the child process pxc. May be stored. That is, the driver program 10 may further record the CPU execution time of the child process pxc in the information le14. Thereby, the verifier can grasp the processing load of the child process pxc, and can grasp the processing of the child process pxc more accurately.

[Another example of performance value variation]
Here, before explaining the details of the processing of the driver program 10, another example in which the performance value varies will be described according to FIGS. In order to specify the cause of the variation in the performance values in the examples of FIGS. 15 and 16, the driver program 10 may further collect other information.

  15 and 16 illustrate a case where a process py that is not a verification target of the performance value operates during measurement of the performance value of the verification process px. In the examples of FIGS. 15 and 16, the verification system measures the time from the start of the service to the end thereof as a performance value in the same manner as in the examples of FIGS.

  FIG. 15 is a first diagram illustrating an example in which the performance value varies according to the execution of the process py that is not the verification target. 15 that are the same as those shown in FIGS. 4 to 6 are indicated by the same symbols.

  As described above, the non-verification process py indicates a process of the operation system or non-verification software. An example of the non-verified process py is a process that performs a monitoring process, and a process that performs a predetermined process with a predetermined change as a trigger. In the present embodiment, the case where the process py that is not subject to verification is a non-resident process that performs patrol such as memory and I / O is illustrated.

  When the test program 30 instructs the verification target software 20 to start a service, the verification target process px performs a series of processes in accordance with an instruction from the test program 30. When the series of processing ends, the verification process px notifies the test program 30 of the end of the series of processing.

  According to the example of FIG. 15, the process pr1 by the process px to be verified and the process pr2 of the patrol process (process py that is not verified) are executed in the same time zone. As described above with reference to FIG. 3, the operation system alternately assigns a CPU to each process. Accordingly, the process pr2 of the process pr that performs patrol is executed in the same time zone as the process pr1 of the process px to be verified, whereby the process of the process px to be verified temporarily enters a standby state. As a result, the processing time tm21 from the start to the end of the service becomes longer.

  FIG. 16 is a second diagram illustrating an example in which the performance value varies according to the execution of the process py that is not the verification target. In FIG. 16, the same components as those shown in FIG. 15 are denoted by the same symbols.

  In the example of FIG. 16, the process pr2 of the process py that performs patrol is executed in a time zone in which the process px to be verified is waiting for I / O (the part without an arrow). Therefore, the processing time tm22 in the example of FIG. 16 is shorter than the processing time tm21 in the example of FIG.

  Although not shown, when the process py for performing patrol does not operate during the time period from the start to the end of the service, the processing time is further shortened compared to the examples of FIGS. As described above, the processing time becomes longer depending on the degree of overlap of the time zones in which the process pr1 of the process px to be verified and the process pr2 of the process py that is not the verification target are executed.

  As illustrated in FIGS. 15 and 16, when the process px to be verified is performing which process, the performance value may change depending on whether the process py not verified has performed the process pr <b> 2. . Therefore, when the performance value is measured a plurality of times, variation occurs between the plurality of performance values.

  According to the examples of FIGS. 15 and 16, in order to identify the cause of the variation in the performance value, it is determined which process py performing the patrol is performed when the process px to be verified is performing. It is required to collect the information shown.

  Therefore, the driver program 10 determines the execution time (CPU execution time) used by the CPU to execute the non-verified process py according to the occurrence of access at a timing different from the timing when the generation and termination of the child process pxc is detected. ) May be further stored. The driver program 10 may generate second log information 50-2 shown in FIG. 17 in addition to the log first log information 50-1 and 50-1x shown in FIGS.

[Second log information 50-2]
FIG. 17 is a diagram illustrating an example of the second log information 50-2. An arrow Y11 in FIG. 17 indicates the CPU execution time. The second log information 50-2 shown in FIG. 17 includes information related to the access (hereinafter also referred to as access information) corresponding to the timing at which occurrence of access by the process px to be verified is detected, and information that is not verified. The process py has a CPU execution time Y1. In the example of FIG. 17, the access information indicates an access sequence number (1 to 6) and an access target address.

  According to the information le21 shown in FIG. 17, the CPU execution time of the process ID “1001” of the sequence number “4” is the value “1.100122”. On the other hand, according to the information le22, the CPU execution time of the process ID “1001” with the sequence number “5” is the value “1.102375”. That is, the CPU execution time of the process ID “1001” increases from the value “1.100122” to the value “1.102375” from the access of the sequence number “4” to the access of the sequence number “5”.

  This indicates that the non-verified process py indicated by the process ID “1001” used the CPU in the time period from the access of the sequence number “4” to the access of the sequence number “5”. That is, it indicates that the process py that is not subject to verification performed processing during the time period from the access of sequence number “4” to the access of sequence number “5”. Further, as described above, the verifier can grasp which process is being performed by the process px to be verified, based on the access information.

  Therefore, by recording the access information of the verification target process px in correspondence with the CPU execution time of the non-verification process py, when the verification target process px is performing any processing, the verification target process px is excluded from the verification target. It is possible to grasp whether or not the process py has been performed.

  Accordingly, in the example of FIGS. 15 and 16, the verifier can grasp which process pr1 of the patrol process is executed when the process px1 is executed by the process px to be verified. Therefore, when the performance value variation occurs, whether the performance value variation has occurred due to the failure of the software 20 based on the second log information 50-2 shown in FIG. It becomes possible to specify whether it occurred based on such an example.

  In addition, since the driver program 10 according to the present embodiment stores only access information, it is possible to suppress an increase in load due to collection of information and an increase in processing time. As described above, the driver program 10 stores the minimum amount of information so that the operation status of the non-verified process py corresponding to the verification target process px can be further changed without changing the actual operation and processing. The information shown can be collected. As a result, it is possible to efficiently identify the cause of the variation in the performance value.

  Next, an example of the candidate process table 60d described in FIG. 11 will be described according to FIG.

[Candidate process table 60d]
18 is a diagram illustrating an example of the candidate process table 60d illustrated in FIG. The candidate process table 60d includes information on the process py that is the target of obtaining the CPU execution time and is not to be verified, as described with reference to FIGS.

  The candidate process table 60d illustrated in FIG. 18 includes identification information of two processes py “iopatol” and “devdaemon” that are not to be verified. Therefore, the driver program 10 acquires the CPU execution times of the processes “iopatol” and “devdaemon” at the time of measurement.

[Details of processing of driver program 10]
Next, details of the processing of the driver program 10 shown in FIG. 11 will be described with reference to FIGS. In the example of FIGS. 19 to 27, the driver program 10 generates the first log information 50-1x shown in FIG. 14 and the second log information 50-2 shown in FIG. Note that the first log information 50-1x illustrated in FIG. 14 includes the information of the first log information 50-1 illustrated in FIG. Therefore, the driver program 10 can generate the first log information 50-1 shown in FIG. 9 according to the examples of FIGS.

  FIG. 19 is a flowchart for explaining the processing flow of the driver program 10 shown in FIG.

  S11: The execution management module 113 of the driver program 10 measures the performance value of the verification target software 20 a plurality of times based on the measurement parameter 70-1 as a first execution step. Then, the execution management module 113 determines whether or not the performance value is remeasured for the verification target software 20, and stores the remeasurement parameter 70-2. Details of the measurement parameter 70-1 and the remeasurement parameter 70-2 will be described later with reference to FIG. Details of the process of step S11 will be described later according to the flowchart of FIG.

  S12: As a second execution step, the execution management module 113 remeasures the performance value of the verification target software 20 in which the remeasurement parameter 70-2 is instructed to be remeasured. At the time of remeasurement, the log information generation module 114 stores log information 50 (first log information 50-1x, second log information 50-2). Details of the process of step S12 will be described later according to the flowchart of FIG.

[First Execution Step (S11 in FIG. 19)]
Before describing the details of the process of the first execution step, the measurement parameter 70-1 and the remeasurement parameter 70-2 of the first execution step will be described according to FIG. Although not illustrated in FIG. 10, the measurement parameter 70-1 and the remeasurement parameter 70-2 are stored in the auxiliary storage device 202 of the information processing apparatus 100, for example.

(Re-measurement parameter 70-2)
FIG. 20 is a diagram illustrating the measurement parameter 70-1 and the remeasurement parameter 70-2 in the first execution process. 20A shows the measurement parameter 70-1, and FIG. 20B shows the remeasurement parameter 70-2.

  A measurement parameter 70-1 illustrated in FIG. 20A includes a sequence number Y21 of the software 20 to be verified, a performance value measurement count Y22, and a file path Y23 of the execution file ex of the software 20 to be verified. .

  Specifically, according to FIG. 20A, the file path Y23 of the software 20 indicated by the sequence number “1” Y21 is the path “/ usr / kensa / test / testpro1”, and the measurement count Y22 is 100. Times. Similarly, the file path Y23 of the software 20 indicated by the sequence number “2” Y21 is the path “/ usr / kensa / test / testpro2”, and the measurement count Y22 is 50 times.

  A remeasurement parameter 70-2 shown in FIG. 20B includes, in addition to the measurement parameter 70-1 shown in FIG. 20A, a remeasurement flag Y31 and process ID information Y32 of the process py that is not subject to verification. Have The remeasurement flag Y21 indicates whether to remeasure the performance value of the software 20 with the target sequence number. Further, the process ID information Y32 indicates a process py that is not subject to verification and has been processed at the time of measurement.

  Specifically, according to (B) of FIG. 20, the remeasurement flag Y31 of the verification target software 20 with the sequence number “1” Y21 has the value “ON”, and in the second execution step (S12), The re-measurement of the performance value of the software 20 is performed. Further, it indicates that the process py that is not subject to verification of the process ID “125” Y32 has been operated when the performance value of the software 20 is measured in the first execution step (S11).

  Further, according to FIG. 20B, since the remeasurement flag Y31 of the software 20 with the sequence number “2” Y21 is the value “OFF”, the performance value of the software 20 in the second execution step (S12). Indicates that no re-measurement is performed.

(Processing flow of the first execution process)
FIG. 21 is a flowchart for explaining the flow of processing in the first execution step (S11 in FIG. 19). The execution management module 113 receives the measurement parameter 70-1 shown in FIG. 20A as an input, executes the process shown in the flowchart of FIG. 21, and performs the remeasurement parameter 70-2 shown in FIG. Is output.

  S21: The execution management module 113 sets the value “1” to the variable “i” indicating the sequence number of the measurement parameter 70-1 ((A) in FIG. 20).

  S22: The execution management module 113 sets the value “1” to the variable “j” indicating the number of measurements of the measurement parameter 70-1.

  S23: Based on the file path of the measurement parameter 70-1, the execution management module 113 instructs the execution of the verification target software 20 with the sequence number “i” and measures the performance value of the verification target software 20. .

  At this time, the execution management module 113 acquires the CPU execution time of the non-verification process py defined in the candidate process table 60d (FIG. 18) when measuring the performance value of the verification target software 20, and the measurement process Record in the management table 80. Details of the measurement process management table 80 will be described later with reference to FIG.

  Specifically, the execution management module 113 acquires the CPU execution time of the process py that is not subject to verification at the start and end of the measurement. Then, the execution management module 113 records the difference in CPU execution time between the start and end of the measurement of the verification target process px in the measurement time process management table 80 as the CPU execution time of the non-verification target process py. .

  S24: The execution management module 113 increments the value of the measurement count “j”.

  S25: The execution management module 113 determines whether or not the number of measurements “j” exceeds a predetermined number.

  S26: When the predetermined number of times is exceeded (Yes in S25), the execution management module 113 determines whether remeasurement is necessary based on the measurement result. As a result of the determination, when it is determined that remeasurement is necessary, the remeasurement flag of the target sequence number “i” in the remeasurement parameter 70-2 ((B) in FIG. 19) is set to the value “ON”. Details of the process of step S26 will be described later according to the flowchart of FIG.

  On the other hand, when the predetermined number of times is not exceeded (No in S25), the execution management module 113 transitions to Step S23 and instructs execution of the software 20 to be verified with the sequence number “i”.

  S27: After the remeasurement determination (S26), the execution management module 113 increments the value of the sequence number “i”.

  S28: The execution management module 113 determines whether or not the value of the sequence number “i” exceeds the total number of pieces of verification target software 20 specified in the measurement parameter 70-1. When the value of the variable “i” exceeds the total number (Yes in S28), the execution management module 113 ends the process to indicate that the performance value has been measured for all software.

  On the other hand, when the total number has not been exceeded (No in S28), the execution management module 113 transitions to step S22 and measures the performance value for the next software.

(Measurement process management table 80)
FIG. 22 is a diagram illustrating an example of the measurement process management table 80. The measurement-time process management table 80 shown in FIG. 22 has the CPU execution time of each process defined in the candidate process table 60d for each measurement time Y42 of the software 20 corresponding to the sequence number Y41.

  According to the information le81, the CPU execution time of the process “iopatol” of the measurement time “1” Y42 of the execution sequence “1” Y41 is the value “0.100122”. Further, according to the information le82, the CPU execution time of the process “devdaemon” of the measurement time “1” Y42 of the execution sequence “1” Y41 is the value “0.000000”.

(Determining the presence or absence of remeasurement (S26 in FIG. 20))
FIG. 23 is a first flowchart illustrating the flow of the remeasurement determination process shown in step S26 of FIG.

  S31: The execution management module 113 refers to the candidate process table 60d (FIG. 18), and sets the total number of processes defined in the candidate process table 60d to the variable “N”. According to the candidate process table 60d shown in FIG. 18, the variable “N” has a value “2”.

  S32: The execution management module 113 sets the value “1” to the variable “k” indicating the counter of the process defined in the candidate process table 60d.

  S33: The execution management module 113 sets the value “1” to the variable “m” indicating the counter and the value “1” to the variable “j” indicating the measurement time.

  S34: The execution management module 113 refers to the measurement process management table 80 shown in FIG. 22, and the CPU execution time of the non-verified process py of sequence number “i” and measurement time “j” is “k”. Is set to the value “work (k)”.

  S35: The execution management module 113 determines whether or not the value “work (k)” is greater than the value “0”. That is, the execution management module 113 determines whether or not the “k” -th non-verification process py of the sequence number “i” and the measurement time “j” has been executed at the time of measurement. In this way, the execution management module 113 extracts the non-verification process py that was executed at the time of measurement from the processes defined in the candidate process table 60d based on the measurement time process management table 80.

  S36: When the value “work (k)” is the value “0” (No in S35), it indicates that the “k” th non-verification process py has not been executed. Therefore, the execution management module 113 increments the value of the measurement time “j”.

  S37: The execution management module 113 determines whether or not the value of the measurement time “j” exceeds the measurement frequency. That is, the execution management module 113 determines whether or not the processes of steps S34 to S36 have been performed for all measurement times. When the number of measurements is not exceeded (No in S37), the execution management module 113 transitions to the process in step S34, and performs the processes in steps S34 and S35 for another measurement time.

  S38: When the number of measurements is exceeded (Yes in S37), the execution management module 113 increments the value of the process counter “k”.

  S39: On the other hand, if the value “work (k)” is greater than the value “0” (Yes in S35), it indicates that the “k” th process py that is not subject to verification has been executed. Therefore, the execution management module 113 sets the work flag to the value “ON” and stores the “k” -th process name (process ID) in the work list (m). Further, the execution management module 113 increments the value of the counter “m”.

  According to the measurement-time process management table 80 of FIG. 21, the CPU execution time of the process “iopatol” with “k = 1” is the value “0” at the first and second measurements of the verification target software 20 with the sequence number “1”. Larger than Accordingly, the execution management module 113 sets the work flag of the verification target software 20 with the sequence number “1” to the value “ON” and stores the process name “iopatol” in the work (m).

  S40: The execution management module 113 determines whether or not the value of the process counter “k” exceeds the value of the total number of processes “N” included in the candidate process table 60d. If not exceeding (No in S40), the execution management module 113 transitions to the process of step S33. That is, the execution management module 113 performs the processes of steps S33 to S39 for another process py that is not subject to verification.

  On the other hand, when the value of the process counter “k” exceeds the value of the total number of processes “N” in the candidate process table 60d (Yes in S40), the execution management module 113 performs the processing in the flowchart of FIG. Transition (A1).

  FIG. 24 is a second flowchart illustrating the flow of the remeasurement determination process shown in step S26 of FIG. FIG. 24 is a flowchart showing processing subsequent to FIG. 23 (A1).

  S51: The execution management module 113 determines whether or not the work flag is the value “ON”. That is, the execution management module 113 determines whether or not the work flag of the software 20 with the sequence number “i” has been updated to the value “ON” in step S39 of FIG.

  S52: When the work flag is not the value “ON” (No in S51), the execution management module 113 performs the performance value (processing time) corresponding to the number of measurement times of the sequence number “i” measured according to step S23 in FIG. Calculate the variance of.

  S53: The execution management module 113 determines whether the calculated variance exceeds a predetermined value. The predetermined value is determined in advance according to, for example, verification.

  S54: When the variance does not exceed the predetermined value (No in S53), it indicates that no variation has occurred among the plurality of performance values. Therefore, the execution management module 113 writes information indicating that the remeasurement flag of the software 20 with the sequence number “i” is the value “OFF” in the remeasurement parameter 70-2.

  S55: On the other hand, if the variance exceeds a predetermined value (Yes in S53), a variation occurs between a plurality of performance values, and there is a need to collect information at the time of measurement in order to identify the cause of the variation. Show. Therefore, the execution management module 113 writes information indicating that the remeasurement flag of the software 20 with the sequence number “i” is the value “ON” in the remeasurement parameter 70-2.

  As described above, the execution management module 113 executes the predetermined process by the verification target process px a plurality of times as the first execution step (S11), and acquires the measurement values (execution result information) of the predetermined process a plurality of times. To do. And the driver program 10 produces | generates and memorize | stores the 1st log information 50-1, 50-1x, when the dispersion | distribution of a measurement value (execution result information) of multiple times exceeds a predetermined value.

  That is, the execution management module 113 determines that the performance value of the target software 20 is to be remeasured when the performance value variation is detected. Thereby, the execution management module 113 can collect information that can identify the cause of variation for the software 20.

  S56: When the work flag is the value “ON” (Yes in S51), it indicates that the work flag is updated to the value “ON” in step S39 of FIG. Means that was being executed.

  Therefore, the execution management module 113 writes information indicating that the remeasurement flag of the software 20 with the sequence number “i” is the value “ON” in the remeasurement parameter 70-2. In addition, the execution management module 113 stores, in the remeasurement parameter 70-2, information on the process ID held in the work (m) indicating the process being executed when the software 20 with the sequence number “i” is measured. to add.

  As described above, the execution management module 113 executes predetermined processing by the verification target process px a plurality of times, and the execution time (CPU execution time) used by the CPU of the non-verification target process py during execution exceeds a predetermined value. In this case, the second log information 50-2 is generated and stored. The predetermined value is, for example, the value “0”. However, the present invention is not limited to this example, and the predetermined value may be set according to verification or the like.

  As described above, the execution management module 113 performs remeasurement of the performance value even when the software 20 does not detect the variation in the performance value when the process py that is not the verification target is executed at the time of measurement. Judgment is made. For example, when the process py that is not subject to verification is executed through all measurement times, the performance value may not vary, but the performance value may not be an appropriate value.

  Therefore, the execution management module 113 can collect information that can identify the presence or absence of a failure in the software 20 based on the CPU execution time of the process py that is not the verification target.

[Second Execution Step (S12 in FIG. 19)]
FIG. 25 is a flowchart for explaining the flow of processing in the second execution step (S12 in FIG. 19).

  S61: The execution management module 113 sets the value “1” to the variable “i” indicating the sequence number of the remeasurement parameter 70-2 ((B) in FIG. 20).

  S62: The execution management module 113 determines whether or not the remeasurement flag of the software 20 to be verified with the sequence number “i” is the value “ON” in the remeasurement parameter 70-2.

  S63: When the remeasurement flag is “ON” (Yes in S62), the execution management module 113 performs setting for collecting information at the time of measurement. Specifically, the execution management module 113 sets the non-target process flag value “ON” to the sequence number “i” of the re-measurement parameter 70-2 when the non-verification process ID operated at the time of measurement is assigned. Set to. Processing to refer to the non-target process flag will be described later according to FIG.

  S64: The execution management module 113 sets a value “1” to a variable “j” indicating the number of measurements of the remeasurement parameter 70-2.

  S65: Based on the remeasurement parameter 70-2, the execution management module 113 instructs the execution of the verification target software 20 with the sequence number “i” and measures the performance value of the verification target software 20. The log information generation module 114 generates log information 50 at the time of measurement.

  When the process ID of the process py that is not the verification target is not described in the remeasurement parameter 70-2, the log information generation module 114 generates the first log information 50-1 and 50-1x. Further, when the remeasurement flag in the remeasurement parameter 70-2 is the value “ON” and the process ID of the process py that is not the verification target is described, the log information generation module 114 outputs the second log information 50. -2 is generated. Details of the processing of the log information generation module 114 will be described later with reference to FIG.

  S66: The execution management module 113 increments the value of the measurement count “j”.

  S67: The execution management module 113 determines whether or not the measurement count “j” exceeds a predetermined count.

  S68: When the predetermined number of times is exceeded (Yes in S67), the execution management module 113 outputs the collected log information 50 when measuring the performance value by executing the verification target software 20 in step S65. On the other hand, when the predetermined number of times is not exceeded (No in S67), the execution management module 113 transitions to step S65.

  S69: If the remeasurement flag is not “ON” (No in S62), or after step S68, the execution management module 113 increments the value of the sequence number “i”.

  S70: The execution management module 113 determines whether or not the value of the sequence number “i” exceeds the total number of pieces of software 20 to be verified. When the value of the variable “i” exceeds the number of software 20 (Yes in S70), the execution management module 113 ends the process.

  On the other hand, when the total number of the software 20 to be verified does not exceed (No in S70), the execution management module 113 transitions to step S64 and performs the processes of steps S64 to S69 for the next software.

(Process of log information generation module 114 (S65 in FIG. 24))
FIG. 26 is a first flowchart illustrating the process of the log information generation module 114 in step S65 of FIG.

  S81: When the occurrence of access is detected, the log information generation module 114 refers to the verification target process table 60a shown in FIG. Then, the log information generation module 114 determines whether the detected caller process of access or the parent process of the caller process corresponds to a process defined in the verification target process table 60a. If not applicable (No in S81), the log information generation module 114 transitions to the processing of the flowchart in FIG. 27 (A3).

  S82: On the other hand, if applicable (Yes in S81), the log information generation module 114 records the access information in the log information (first log information 50-1x, second log information 50-2). When the first log information 50-1 shown in FIG. 9 is generated, the log information generation module 114 records access information only when generation and termination of a child process pxc described later are detected.

  S83: The log information generation module 114 determines whether or not the non-target process flag set in step S63 of FIG. 25 is the value “ON”.

  S84: When the non-target process flag is the value “ON” (Yes in S83), the log information generation module 114 acquires the CPU execution time of the process ID specified in the remeasurement parameter 70-2 from the operation system. . The operation has a CPU execution time for each process ID. Then, as illustrated in FIG. 17, the log information generation module 114 adds the acquired CPU execution time to the second log information 50-2.

  Note that when the non-target process flag is not the value “ON” (No in S83), the log information generation module 114 does not perform the process of Step S84.

  S85: The log information generation module 114 determines whether or not the detected access is read.

  S86: In the case of reading (Yes in S85), the log information generation module 114 determines whether or not the address to be read is an address defined in the process generation address table 60b.

  S87: If defined (Yes in S86), it indicates a read access for the purpose of generating a child process pxc. Accordingly, the log information generation module 114 stores information indicating that the child process pxc has been generated in addition to the first log information 50-1x, as indicated by the information le12 in FIG.

  S88: The log information generation module 114 sets a child process generation flag value “ON” indicating that the child process pxc has been generated (A2).

  If the access is not a read access (No in S85), or if the read address is not defined in the process generation address table 60b (No in S86), the log information generation module 114 performs the processes of Steps S87 and S88. No (A2).

  FIG. 27 is a second flowchart illustrating the process of the log information generation module 114 in step S65 of FIG. FIG. 27 is a flowchart of the continuation (A2) of FIG.

  S91: The log information generation module 114 determines whether or not the child process generation flag is the value “ON”.

  When the child process generation flag is not the value “NO” (No in S91), and when the determination in step S81 in the flowchart of FIG. 26 is NO (No in S81: A3), the log information generation module 114 The process proceeds to process S100 described later.

  S92: If the child process generation flag is “ON” (Yes in S91), it indicates that the child process has been generated. Therefore, the log information generation module 114 determines whether or not the generated child process pxc is operating based on information included in the operation system.

  S93: If the child process pxc is operating (Yes in S92), the log information generation module 114 determines whether or not the child process pxc has been added to the child process management table 60c. The log information generation module 114 adds information of the detected child process pxc to the child process management table 60c when it has not been added.

  S94: On the other hand, when the child process pxc is not operating (No in S92), the log information generation module 114 detects the end of the child process pxc. Accordingly, the log information generation module 114 records information indicating that the child process pxc has ended in addition to the first log information 50-1x, as indicated by information le14 in FIG.

  S95: Following step S94, the log information generation module 114 sets the child process generation flag to the value “OFF”.

  S96: The log information generation module 114 determines whether or not the process ID of the access call source process is not defined in the verification target process table 60a.

  S97: If not defined (Yes in S96), it indicates that the access is by the generated child process pxc. Accordingly, the log information generation module 114 additionally describes information indicating that the access is made by the child process pxc in addition to the first log information 50-1x, as indicated by information le13 in FIG.

  As described above, the log information generation module 114 further records the access information of the child process, thereby making it possible to grasp the processing contents of the child process pxc in addition to the generation and termination timings of the child process pxc.

  S98: The log information generation module 114 determines whether or not the process ID of the calling child process pxc is registered in the child process management table 60c.

  S99: A case where a plurality of child processes pxc are generated based on the address of the same execution file ex when not registered (Yes of S98). In this case, since the data of the execution file ex is stored in the cache memory, the access module 112 may not be able to detect that the address has been accessed, and may not detect the generation of the child process pxc. Accordingly, the log information generation module 114 adds the process ID of the calling child process pxc to the child process management table 60c in response to the occurrence of access by the child process pxc.

  On the other hand, when it has been registered (No in S98), the log information generation module 114 does not perform the process of step S99.

  If the process ID of the access call source process is defined in the verification target process table 60a (No in S96), it indicates that the detected access is an access by the verification target process px. Therefore, the log information generation module 114 does not perform the processes of steps S97 to S99.

  S100: When step S96 is No, when step S81 is No, and in any case after step S99, the access module 112 performs processing according to the detected access. Specifically, the access module 112 performs reading or writing with respect to the storage unit according to access. When detecting access to the network, the access module 112 transmits and receives data.

[Measurement result information]
Although not shown in the flowcharts of FIGS. 25 and 26, the driver program 10 may further generate measurement result information 90 shown in FIG.

  FIG. 28 is a diagram illustrating an example of the measurement result information 90. The measurement result information 90 includes information such as the presence / absence of re-measurement Y51, the presence / absence of variation in performance value Y52, and the presence / absence of operation of a process py that is not subject to verification for each sequence number. The measurement result information 90 includes link information (detailed information 1) to the first log information 50-1x when there is variation. In addition, the measurement result information 90 includes link information (detailed information 2) to the second log information 50-2 in the case of the operation of the process py that is not verified.

  For example, the information le91 indicates that there is a variation in the performance value of the verification target software 20 with the sequence number “1”, and includes link information to the first log information 50-1x. The information le91 indicates that a process py that is not subject to verification has been operated during the measurement of the software 20, and includes link information to the second log information 50-2. On the other hand, the information le92 has only link information to the first log information 50-1x because the process py that is not the verification target is not operating.

[Other embodiments]
The driver program 10 may store the access information in association with the execution time (CPU execution time) used by the CPU for executing the process px to be verified. Thereby, the verifier can grasp the processing load of the process px to be verified for each access timing, and can more accurately grasp the processing contents of the process px to be verified.

  The above embodiment is summarized as follows.

(Appendix 1)
On the computer,
In response to reading of an execution file instructing execution of generation of a child process of the target process by the target process of operation monitoring, detection of generation of a child process of the target process is detected.
After the generation of the child process is detected, it is determined whether or not the child process is operating according to the access to the storage unit or the network by the target process, and it is determined that the child process is not operating Detects the end of the child process,
Information related to the access by the target process corresponding to the timing at which the generation and termination of the child process are detected, in association with identification information for identifying the child process, and stored in a storage unit;
A control program characterized by causing

(Appendix 2)
In Appendix 1,
The storage further stores information on the access according to the occurrence of the access at a timing different from the timing at which the generation and termination of the child process is detected.
Control program.

(Appendix 3)
In Appendix 2,
The storage further stores information related to access of the child process in response to occurrence of access of the child process.
Control program.

(Appendix 4)
In any one of supplementary notes 1 to 3,
The information related to access includes either or both of access order information and access target address,
Control program.

(Appendix 5)
In any one of supplementary notes 1 to 4,
The storage stores information related to the access corresponding to the timing at which the end of the child process is detected, in further association with an execution time used by the processor to execute the child process.
Control program.

(Appendix 6)
In any one of supplementary notes 1 to 5,
Executing a predetermined process by the target process a plurality of times, obtaining execution result information of the plurality of the predetermined processes;
When the distribution of the execution result information of the plurality of times exceeds a predetermined value, the generation and the end detection are performed, and the storage is performed.
Control program.

(Appendix 7)
In any one of supplementary notes 1 to 6,
The storage further stores an execution time used by a processor to execute a process that is not subject to operation monitoring according to the occurrence of the access at a timing different from the timing at which generation and termination of the child process are detected.
Control program.

(Appendix 8)
In Appendix 7,
Performing the predetermined process by the target process a plurality of times, and performing the storage when the execution time used by the processor of the non-target process exceeds a predetermined value during the execution;
Control program.

(Appendix 9)
The processing unit detects generation of a child process of the target process in response to reading of an execution file instructing execution of generation of the child process of the target process by the target process of operation monitoring,
The processing unit determines whether or not the child process is operating in response to occurrence of access to the storage unit or the network by the target process after the generation of the child process is detected. When it is determined that it is not, the end of the child process is detected,
The processing unit stores, in the storage unit, information related to the access by the target process corresponding to the timing at which the generation and termination of the child process are detected in association with identification information for identifying the child process.
Control method.

(Appendix 10)
In Appendix 9,
The storage further stores information on the access according to the occurrence of the access at a timing different from the timing at which the generation and termination of the child process is detected.
Control method.

(Appendix 11)
In Appendix 10,
The storage further stores information related to access of the child process in response to occurrence of access of the child process.
Control method.

(Appendix 12)
In any one of appendices 9 to 11,
The information related to access includes either or both of access order information and access target address,
Control method.

(Appendix 13)
In any one of appendices 9 to 12,
Executing a predetermined process by the target process a plurality of times, obtaining execution result information of the plurality of the predetermined processes;
When the distribution of the execution result information of the plurality of times exceeds a predetermined value, the generation and the end detection are performed, and the storage is performed.
Control method.

(Appendix 14)
In any one of appendices 9 to 13,
The storage further stores an execution time used by a processor to execute a process that is not subject to operation monitoring according to the occurrence of the access at a timing different from the timing at which generation and termination of the child process are detected.
Control method.

(Appendix 15)
A storage unit that stores an execution file that instructs execution of generation of a child process of a target process of operation monitoring;
The generation of the child process of the target process is detected in response to the reading of the child executable file by the target process, and the access to the storage unit or the network by the target process after the generation of the child process is detected In response to the occurrence of the above, it is determined whether or not the child process is operating, and when it is determined that the child process is not operating, the end of the child process is detected, and the generation and the end of the child process are detected. A processing unit that stores information related to the access by the target process corresponding to each of the timings, in the storage unit in association with identification information that identifies the child process;
An information processing apparatus.

(Appendix 16)
In Appendix 15,
The processing unit further stores information on the access according to the occurrence of the access at a timing different from the timing at which the generation and termination of the child process is detected.
Information processing device.

(Appendix 17)
In Appendix 16,
The processing unit further stores information related to access of the child process in response to occurrence of access of the child process.
Information processing device.

(Appendix 18)
In any one of Supplementary Notes 15 to 17,
The information related to access includes either or both of access order information and access target address,
Information processing device.

(Appendix 19)
In any one of Supplementary Notes 15 to 18,
The processing unit executes a predetermined process by the target process a plurality of times, acquires execution result information of the predetermined process a plurality of times,
When the distribution of the execution result information of the plurality of times exceeds a predetermined value, the generation and the end detection are performed, and the storage is performed.
Information processing device.

(Appendix 20)
In any one of Supplementary Notes 15 to 19,
The processing unit further stores an execution time used by the processor for execution of a process not subject to operation monitoring in accordance with the occurrence of the access at a timing different from the timing at which the generation and termination of the child process is detected. ,
Information processing device.

100: Information processing device, 40: Client device, SD: Storage device SD, 20: Software to be verified, 10: Driver program, 30: Test program, px: Process to be verified, py: Process not to be verified

Claims (7)

On the computer,
In response to reading of an execution file instructing execution of generation of a child process of the target process by the target process of operation monitoring, detection of generation of a child process of the target process is detected.
After the generation of the child process is detected, it is determined whether or not the child process is operating according to the access to the storage unit or the network by the target process, and it is determined that the child process is not operating Detects the end of the child process,
Information related to the access by the target process corresponding to the timing at which the generation and termination of the child process are detected, in association with identification information for identifying the child process, and stored in a storage unit;
A control program characterized by causing In claim 1,
The storage further stores information on the access according to the occurrence of the access at a timing different from the timing at which the generation and termination of the child process is detected.
Control program. In claim 2,
The storage further stores information related to access of the child process in response to occurrence of access of the child process.
Control program. In any one of Claims 1 thru | or 3,
Executing a predetermined process by the target process a plurality of times, obtaining execution result information of the plurality of the predetermined processes;
When the distribution of the execution result information of the plurality of times exceeds a predetermined value, the generation and the end detection are performed, and the storage is performed.
Control program. In any one of Claims 1 thru | or 4,
The storage further stores an execution time used by a processor to execute a process that is not subject to operation monitoring according to the occurrence of the access at a timing different from the timing at which generation and termination of the child process are detected.
Control program. The processing unit detects generation of a child process of the target process in response to reading of an execution file instructing execution of generation of the child process of the target process by the target process of operation monitoring,
The processing unit determines whether or not the child process is operating in response to occurrence of access to the storage unit or the network by the target process after the generation of the child process is detected. When it is determined that it is not, the end of the child process is detected,
The processing unit stores, in the storage unit, information related to the access by the target process corresponding to the timing at which the generation and termination of the child process are detected in association with identification information for identifying the child process.
Control method. A storage unit that stores an execution file that instructs execution of generation of a child process of a target process of operation monitoring;
By the target process, in response to a read before you line file, detects the generated child process of the target process, after the formation of the child process is detected, by the subject process, the storage unit or the network In response to the occurrence of the access, it is determined whether or not the child process is in operation. When it is determined that the child process is not in operation, the end of the child process is detected, and the generation and the end of the child process are detected. A processing unit that stores information on the access by the target process corresponding to each detected timing in the storage unit in association with identification information for identifying the child process;
An information processing apparatus.

Images