JP5847746B2 - CPU usage rate control device, CPU usage rate control method, and CPU usage rate control program - Google Patents

Description

  The present invention relates to a technique for controlling a CPU usage rate.

  The computer can include a software program execution environment that operates as a single process on the OS, and a plurality of software programs that operate on the execution environment. For example, there is a Java (registered trademark) VM as such an execution environment, and an OSGi bundle as a software program.

  A Java VM (Java Virtual Machine) operates as a single process as viewed from the OS, and a software program operating on the Java VM can generate a plurality of Java threads, and a Java VM performs a plurality of processes in a time-parallel manner. Can be executed.

  OSGi (Open Service Gateway initiative) is a technique for configuring a software program with a plurality of Java software modules (Non-patent Document 1). An OSGiFW (OSGi Framework) can be operated on one JavaVM, and a plurality of OSGi bundles (hereinafter referred to as bundles) can be operated on the OSGiFW. This bundle can dynamically execute installation / uninstallation and start / stop during the operation of OSGiFW.

  Here, the end user or the operator of the software program execution environment may want to operate a specific bundle with certainty. For example, it is desirable to guarantee the operation of an important bundle regardless of the operation load status of other bundles. Specifically, if you want to complete the earthquake early warning calculation within 1 second even when an application for a game with a high CPU load is operating, or when the CPU load increases due to an infinite loop caused by a poorly created application, the management Web screen is displayed. This is when you want to display within 2 seconds.

  For this reason, it is conceivable that the CPU usage rate should be guaranteed at the minimum for each bundle. In that case, it is conceivable to use a Java thread priority changing method defined in the specification of the Java application program interface (Non-patent Document 2).

“OSGi Specifications”, OSGi Alliance, <URL: http://www.osgi.org/Download/File?url=/download/r5/osgi.core-5.0.0.pdf> “Class Thread, java.land.Thread.setPriority (int)”, Java 2 Platform Std. Ed v1.4.0, <URL: http://docs.oracle.com/javase/jp/1.4/api/java/lang /Thread.html#setPriority (int)>

  However, even if such an existing method is used, it is difficult to reliably guarantee the operation of a specific bundle for the following reasons.

(1) In the existing priority changing method, the actual operation is not defined.

(2) Since the existing priority change is performed by the bundle itself, the speculation of the end user who is the creator of the bundle may differ from the speculation of the operator of the software program execution environment. In other words, the priority change cannot be controlled from the outside, and it is necessary to modify each bundle for external control.

(3) The existing priority changing method does not define a mechanism for comprehensively overlooking the whole and restricting priority setting. For this reason, for example, the highest priority may be set for all Java threads, which may not have any meaning.

(4) A Java thread in the software program execution environment may operate a bundle, or a single bundle may operate a plurality of Java threads. That is, one Java thread does not necessarily exist for one bundle, and priority setting in Java thread units cannot be set in bundle units.

  The present invention has been made in view of the above circumstances, and an object thereof is to guarantee a CPU usage rate in software program units.

The CPU usage rate control device according to claim 1, wherein the CPU usage rate control device controls the CPU usage rate of a software program operating on an execution environment of a single process, and the execution environment layer is used to execute the software program. Generating a first thread and starting means for starting the software program as the first thread, and each time the first thread is generated, a second thread of the OS layer is generated and 1 is assigned to the first thread. Corresponding means for associating with each other, grouping means for grouping the second threads into groups for each software program and storing them in the storage means as group information, and input means for receiving input of a specified value of the CPU usage rate for each group If, reads the group information from the storage unit, for each group The serial CPU usage the CPU usage rate of the second thread belonging to each group based on the specified value of the calculated and summarized in that and a control means for controlling the CPU usage rate to the second thread .

  The CPU usage rate control device according to claim 2 is the CPU usage rate control device according to claim 1, wherein the execution environment is Java Virtual Machine, and the grouping means is a software program other than a software program operating on the Java Virtual Machine. The gist is to manage the second thread related to the software program in a specific group.

CPU usage control apparatus according to claim 3, wherein, in the CPU utilization rate control apparatus according to claim 1 or 2, wherein switching the belonging group of the second thread corresponding to the first thread that calls itself to other groups The gist is to further include a switching means.

5. The CPU usage rate control method according to claim 4, wherein the CPU usage rate control method controls the CPU usage rate of a software program that operates in an execution environment of a single process, in order to execute the software program by a computer. A first step of generating a first thread of an execution environment layer and starting the software program as the first thread, and a second thread of the OS layer are generated each time the first thread is generated. A step of associating the threads one-to-one, a grouping step of storing the second threads in groups for each software program and storing them in the storage means as group information, and inputting a specified value of the CPU usage rate for each group an input step of accepting, a group from the storage means Reads broadcast, a control step of the CPU usage rate of the second thread belonging to each group based on a specified value of the CPU utilization was calculated for each group, to control the CPU usage rate to the second thread The gist is to have.

The gist of the CPU usage rate control program according to claim 5 is to cause a computer to function as the CPU usage rate control device according to any one of claims 1 to 3 .

  As described above, according to the present invention, the first thread of the execution environment layer is generated and started to execute the software program, and the second thread of the OS layer is generated every time the first thread is generated. Thus, the second threads are grouped for each software program in a one-to-one correspondence with the first thread, and the CPU usage rate of the second thread belonging to each group is determined based on the specified CPU usage rate for each group. In order to calculate and control the CPU usage rate for the second thread, the OS layer that controls the CPU can indirectly control the software program that is started as the first thread through the second thread of the OS layer. Thus, the CPU usage rate can be guaranteed in software program units.

  According to the present invention, it is possible to guarantee the CPU usage rate in units of software programs.

It is a figure which shows the functional block structure of a CPU usage rate control apparatus. It is a figure which shows the example of group information. It is a figure which shows the control flow of CPU usage rate. It is a figure which shows the example of a setting screen. It is a figure which shows the group switching flow of a Java thread. It is a figure which shows the holding information (initial state) of a thread group grouping function part. It is a figure which shows the holding information (OSGi starting state) of a thread group grouping function part. It is a figure which shows the holding information (CPU resource control start state) of a thread group grouping function part. It is a figure which shows the holding | maintenance information (CPU resource control completion state) of a thread group grouping function part. It is a reference figure at the time of effect description.

  Hereinafter, an embodiment for carrying out the present invention will be described with reference to the drawings. However, the present invention can be implemented in many different modes and should not be construed as being limited to the description of the present embodiment.

[Existing technology]
The present invention is based on the existing technology as described above. In the following, supplementary explanation will be given for the existing technology.

  The CPU is scheduled by the OS, and the unit of the scheduling is a process or a LWP (Light Weight Process) that is a thread in the OS layer.

  Processes and LWPs exist in the OS as a mechanism for operating software programs in parallel in time, and JavaVM operates as one process when viewed from the OS. JavaVM, on the other hand, prepares a Java thread as a mechanism for operating processes in parallel in JavaVM. The LWP executes the Java thread corresponding to itself, but the Java thread and the LWP are independent from each other because the operating layers are different.

[Configuration of CPU usage rate control device]
FIG. 1 is a diagram showing a functional block configuration of a CPU usage rate control device 1 according to the present embodiment. The CPU usage rate control device 1 includes an LWP unit CPU control function unit 11, a Java thread / LWP support function unit 12, a bundle threading function unit 13, a thread group grouping function unit 14, and a thread group switching function unit. 15 and a bundle CPU usage rate setting unit 16. This will be described in detail below.

  The LWP unit CPU control function unit 11 operates in the OS layer and has a function of controlling the CPU usage rate in units of LWP or LWP groups. Specifically, the CPU usage rate is controlled by scheduling the CPU using the value of the ratio of the CPU usage time for each LWP or each group of LWP.

  When the CPU is directly controlled by the OS, for example, Linux (registered trademark) cgroups can be used. The cgroups is a Linux kernel function that controls the CPU usage rate in units of processes, LWPs, and LWPs.

  The Java thread / LWP support function unit 12 operates in the JavaVM layer, generates one LWP for executing it every time one Java thread is generated, and sets one Java thread on the JavaVM to the LWP on the OS. It has the function of making it correspond one-on-one.

  The bundle threading function unit 13 operates on OSGiFW, and when a Java thread generated by OSGiFW calls a bundle process (starts a bundle or the like), a new Java thread is generated to execute the bundle. The bundle is activated as a Java thread.

  Note that the processing for calling the bundle processing is, for example, eventing from a framework such as start or stop of a certain bundle to another bundle. Specifically, as a callback interface from the OSGiFW to the bundle, it is possible to start a thread for BundleActivator, ServiceFactory, Bundle-, Service-, FrameworkListener, Framework hook services, and the like. These include, for example, BundleActivator. There is start ().

  In addition, since the Java thread is associated with the LWP by the Java thread / LWP correspondence function unit 12, the bundle threading function unit 13 may generate a new Java thread and simultaneously obtain the corresponding LWP ID from the OS. it can.

  Also, since OSGiFW can acquire the ID of the bundle that the Java thread intends to call, the bundle threading function unit 13 acquires the ID of the bundle that is to be called, and the Java thread / LWP support function unit 12 It also has a function of associating with the generated LWP ID and handing it over to the thread group grouping function unit 14.

  Further, the bundle threading function unit 13 has a function of notifying the thread group grouping function unit 14 when a bundle is newly installed or uninstalled. The notification information here is information indicating that installation or uninstallation has been performed and the bundle ID.

  The thread group grouping function unit 14 operates in the OS layer (other layers may be used) and handles the Java thread group associated with the LWP by the bundle threading function unit 13 as a group for each bundle. It has a function of calling the CPU control function unit 11.

  Specifically, when the installation information of the new bundle is notified from the bundle threading function unit 13, a group is generated for each newly installed bundle ID, and the LWP ID is generated from the bundle threading function unit 13. Each time a bundle ID is sent, that is, each time a new Java thread is generated, the LWP ID belongs to the corresponding bundle ID group and is stored as group information.

  Here, an example of the group information is shown in FIG. The group information includes an ID of a bundle corresponding to one group, an ID of an LWP included in the group (= bundle), and an operation guarantee setting value for the group (= bundle) designated and set by the user (= bundle). For example, a CPU usage rate) and a setting value for CPU usage rate control set for a group (= bundle) are stored in association with each other.

  The set value for CPU usage rate control is calculated based on the set value for operation guarantee, as will be described later. When using the above cgroups, the calculated value is cpu. Set as the value of shares. In addition, cpu. “shares” is an integer value of CPU usage time allocated to a corresponding group in cgroups.

  As described in the problem, the OS that schedules the CPU cannot normally grasp the operation of the bundle in the Java VM operating in a single process. On the other hand, in the present embodiment, the CPU usage time is controlled in units of LWPs or LWP groups using the group information. Since LWP is associated with Java threads, it can be handled in units of Java threads, that is, in units of bundles called bundles, through LWP, and as a result, the operation of a specific bundle can be guaranteed.

  2 illustrates a Java VM process that operates as a single process as viewed from the OS. However, the thread group grouping function unit 14 uses a process other than the Java VM (as shown on the right side of FIG. Processes that operate directly on the OS without going through JavaVM are also managed simultaneously in a specific group within the same group information.

  Here, a group to which a process (including LWP) operating in the OS layer belongs will be described. In the present embodiment, the affiliation group is determined based on the following rules (1) to (6).

(1) Processes other than JavaVM belong to a certain group (hereinafter referred to as a root group). This is done each time a new process occurs.

(2) The LWP ID delivered from the bundle threading function unit 13 belongs to the bundle ID group delivered at the same time.

(3) An LWP generated by an LWP belonging to one of the groups is made to belong to the same group as the source LWP. This corresponds to the case where a certain Java thread generates another Java thread.

(4) When the LWP having the thread group switching function unit 15 is designated to belong to a group with another bundle ID, the thread group switching function unit 15 belongs to the group designated there.

(5) LWPs other than the above (1) to (4) belong to the root group.

(6) When a process or LWP stops or disappears, it is deleted from the group to which it belongs.

  Moreover, a group and group information are produced | generated or eliminated based on the following rules (A)-(D).

(A) Only one root group is generated when the thread group grouping function unit 14 is activated.

(B) Each bundle ID group is generated when installation information is notified from the bundle threading function unit 13. It is not generated when the bundle ID is the same as the group already held.

(C) The group and group information are kept regardless of the operation status of each bundle and the OSGiFW operation status. The IDs of LWPs belonging to the bundle ID group are deleted when the bundle or OSGi is stopped, but other information is retained.

(D) Group deletion is executed at any of the following timings.

(D-1) When the CPU usage rate control device 1 is initialized.

(D-2) Immediately after receiving notification of uninstallation information from the bundle threading function unit 13.

(D-3) After a certain period of time after receiving the uninstall information notification from the bundle threading function unit 13. For example, after one month.

(D-4) When the OSGiFW operation stops, all groups other than the root group are deleted.

  The thread group switching function unit 15 operates in the OSGi layer, and has a function of switching a bundle ID group to which a Java thread that calls itself belongs to another group using an LWP ID. This function is provided as an interface to the bundle.

  Specifically, when called by a bundle with the bundle ID of the switching destination as an argument, the thread group switching function unit 15 obtains the bundle ID of the calling source bundle and the ID of the LWP corresponding to the calling Java thread. The acquired groups are combined and handed over to the thread group grouping function unit 14 to switch the belonging group.

  The bundle CPU usage rate setting unit 16 operates in the OSGi layer (other layers may be used) and has a function having a setting Web user interface for operators and end users. For example, a list of bundles already installed at the time of GUI generation and the operating state (operating / not operating) of the bundle are acquired from the OSGiFW and displayed on the user terminal.

  Specifically, when the CPU resource to be allocated to a certain bundle (regardless of the operation state) is specified and set by the CPU usage rate (%), the setting content is input to the thread group grouping function unit 14. . In addition, when the total CPU usage rate exceeds a predetermined threshold, a function for issuing a warning to the user is also provided. For example, a warning message is displayed when the total CPU usage rate exceeds 99%.

[Operation of CPU usage rate control device]
Next, the operation of the CPU usage rate control device 1 will be described. First, a CPU resource control method for each bundle will be described with reference to FIG.

  First, the bundle CPU usage rate setting unit 16 receives input of the bundle selected by the user and the CPU usage rate to be assigned to the bundle that has been set and input (step S101).

  An example of the setting screen is shown in FIG. The “bundle symbolic name” column represents a list of bundles. The “bundle state” column represents the operation state of each bundle, but this column may be omitted. The bundle state includes operating (ACTIVE), stopping (RESOLVED), installed but not operating (INSTALLED), and the like. The user can set the bundle for any state in the list.

  The column of “minimum quality assurance CPU usage rate” is a text box for inputting a minimum value of CPU usage rate (%) set for a bundle for which operation guarantee is to be performed. Even when the load on the computer increases, the CPU usage rate of this set value is given to the corresponding bundle at a minimum. On the other hand, when the load on the computer is small, the CPU may be used exceeding this setting value. Conversely, when the set bundle is not processing, another bundle uses the CPU. There is also a case.

  The column “CPU resource control application flag” indicates whether or not the CPU resource control function is valid. The columns “control start” and “control end” are displayed so as to be selectable by radio buttons, and the CPU resource control function can be turned on or off. The “total” line at the bottom represents the total value of the CPU usage rate set by the “minimum quality assurance CPU usage rate” of the bundle whose “CPU resource control application flag” is ON.

  Next, the bundle CPU usage rate setting unit 16 inputs the user setting information received in step S101 into the thread group grouping function unit 14 (step S102).

  The input information here is an ID of a bundle that is selected by the user and whose “control start” is ON, and a corresponding “minimum quality assurance CPU usage rate”. The bundle is inserted regardless of whether the bundle state is ACTIVE or not.

  Next, the thread group grouping function unit 14 is an LWP unit CPU control function unit corresponding to the CPU usage rate (the setting value for operation guarantee shown in FIG. 2) input to each group of each bundle ID. 11 is calculated (set value for CPU usage rate control shown in FIG. 2) and is input to the LWP unit CPU control function unit 11 (step S103).

  Specifically, as described later, a setting value for the LWP unit CPU control function unit 11 is calculated based on the CPU usage rate designated by the user. That is, the CPU usage rate of the LWP belonging to each group is calculated.

  For example, when the LWP unit CPU control function unit 11 uses the above-mentioned cgroups, cpu. The value of shares will be calculated. Further, when using the Linux nice, the calculation is performed by using the CPU scheduling function on the OS that is uniquely implemented. Note that the calculation and input here are performed for LWPs belonging to all groups regardless of whether the bundle state is ACTIVE.

  Next, the LWP unit CPU control function unit 11 controls the CPU usage rate of the LWP belonging to the group (= bundle) using the set value input from the thread group grouping function unit 14 (step S104).

  Specifically, using the cgroups kernel function, the CPU usage time ratio of the LWP belonging to each group (= bundle) is “minimum quality assurance CPU usage rate” input to each group (= bundle). The CPU in the computer is scheduled so as to be equal to the ratio. In cgroups, the cpu. It has a function of performing control to relatively distribute CPU usage time according to an integer ratio given as shares.

  However, if there is no LWP belonging to a group, CPU scheduling is not performed for that group. At this time, scheduling is performed, but since there is no corresponding LWP, it may be skipped to the next scheduling.

  Through the above processing, the CPU usage time of each bundle is controlled to be the CPU usage rate input in step S101. Thereby, the operation of a specific bundle can be guaranteed.

  Next, a Java thread group switching method will be described with reference to FIG. However, it is assumed that some bundles are already operating and “minimum quality assurance CPU usage rate” is set in some bundles.

  First, the operating bundle 1 calls the thread group switching function unit 15 using the bundle ID of the switching destination as an argument (step S201). At this time, the bundle 1 is input with designation information as to which other bundle in which the running Java thread belongs.

  Next, the thread group switching function unit 15 acquires the bundle ID of the call source (switch source) bundle and the ID of the LWP corresponding to the Java thread of the call source bundle, together with the bundle ID of the switch destination bundle. The switching information is input to the thread group grouping function unit 14 (step S202).

  Next, the thread group grouping function unit 14 moves the ID of the LWP belonging to the group of the bundle ID of the switching source to the group of the bundle ID of the switching destination (step S203).

  Next, the thread group grouping function unit 14 notifies the LWP unit CPU control function unit 11 of the information related to all groups and the IDs of LWPs belonging to the group updated in step S203 (step S204).

  Finally, the LWP unit CPU control function unit 11 controls the CPU usage rate of the LWP belonging to the group based on the notified updated information (step S205).

[About thread group grouping function]
Next, the thread group grouping function unit 14 will be described in detail. 6 to 9 show transitions of retained information retained by the thread group grouping function unit 14.

  FIG. 6 shows a state before JavaVM and OSGi are activated. In this initial state, all processes (including LWP) on the OS belong to the route group.

  Here, cpu. Set in the route group. The value of shares is a fixed value N. Since it is in the initial state, the fixed value N may be set as an arbitrary value, but here it is set to 1024 in consideration of the balance with the CPU usage rate set to other bundles. In the following example, calculation is performed based on this value.

  In FIG. 6, there is no group other than the root group, but OSGiFW has been activated in the past, and the thread group grouping function unit 14 has already generated a group, and OSGi is terminated. However, in the case of an implementation that holds groups, groups other than the root group may exist.

  Next, FIG. 7 shows a state after JavaVM and OSGi are activated. A group (indicated as ProcessGroup in the figure) is created for each installed bundle. That is, the bundle threading function unit 13 notifies the ID of the installed bundle and the ID of the LWP, and therefore generates group information that associates them.

  If the bundle CPU usage rate setting unit 16 has set the group information in the past and the thread group grouping function unit 14 has already held the group information, the group of bundles that are not targeted for control of the CPU resource is referred to. For cpu. A fixed value N of 1024, which is the same as the route group, is set as the value of shares.

On the other hand, for a group of CPU resource control target bundles, “the minimum quality assurance CPU usage rate of the CPU resource control target bundle” and “all processes (including LWP) that are not subject to CPU resource control can be used. The ratio of “CPU utilization” is “the value of cpu.shares of the CPU resource control target bundle” and “the sum of the values of cpu.shares set for all processes (including LWP) that are not subject to CPU resource control”. For example, the “value of cpu.shares of the CPU resource control target bundle” is calculated using the following equation (1) so as to be equal to the ratio of:

Incidentally, _{C S} is the "value of cpu.shares of CPU resource control object bundles _{', G cpu} is" minimum quality assurance CPU use rate of the CPU resource control object bundles', n represents CPU resource control non-target bundle K is the number of CPU resource control target bundles, and i is the identifier of the CPU resource control target bundle.

  The “CPU usage rate that can be used by all processes (including LWP) that are not subject to CPU resource control” corresponds to the denominator on the right side. Further, “the sum of the values of cpu.shares set for all processes (including LWP) that are not subject to CPU resource control” corresponds to the parenthesis part of the numerator on the right side. Since a fixed value N of 1024 is set for each of the CPU resource control non-target bundles, and the same fixed value N is also fixedly set for the route group, the formula shown in the parentheses is used. This calculation is performed regardless of the operating state of the bundle.

  Finally, FIG. 8 shows a state where the control of the CPU resource is started, and FIG. 9 shows a state where the control of the CPU resource is finished. In either case, cpu. Recalculate the value of shares. Also, when the number of bundle groups increases or decreases, recalculation is performed for all groups.

  As described above, according to the present embodiment, a Java thread is generated and started in order to execute a bundle, and each time the Java thread is generated, an OS layer LWP is generated and a pair of the Java thread is generated. 1, the LWPs are grouped for each bundle, the CPU usage rates of the LWPs belonging to each group are calculated based on the specified CPU usage rates for each group, and the CPU usage rates are controlled for the LWPs. Therefore, as shown in FIG. 10, since the OS layer that controls the CPU can indirectly control the bundle that is activated as a Java thread through the LWP of the OS layer, the CPU usage rate is guaranteed in units of bundles. be able to.

  Finally, in this embodiment, JavaVM is used as the software program execution environment and bundled as the software program. However, the software program execution environment that operates as a single process on the OS and the execution environment operate. Any computer provided with a software program can be applied in the same manner, and the same effect can be obtained.

  The CPU usage rate control device 1 described in the present embodiment can be realized by a computer having a memory and a CPU. The process can be executed by a program.

DESCRIPTION OF SYMBOLS 1 ... CPU usage rate control apparatus 11 ... LWP unit CPU control function part 12 ... Java thread and LWP corresponding | compatible function part 13 ... Bundle threading function part 14 ... Thread group grouping function part 15 ... Thread group switching function part 16 ... Bundle CPU Usage rate setting unit S101 to S104, S201 to S205 ... step

Claims (5)

In a CPU usage rate control device that controls the CPU usage rate of a software program that operates on the execution environment of a single process,
Starting means for generating a first thread of the execution environment layer to execute the software program, and starting the software program as the first thread;
An association unit that generates a second thread of the OS layer and associates the first thread with the first thread each time the first thread is generated;
Grouping means for grouping the second threads into groups for each software program and storing them in the storage means as group information;
An input means for receiving an input of a specified value of the CPU usage rate for each group;
Reads the group information from the storage means, a CPU usage rate of the second thread belonging to each group based on a specified value of the CPU utilization was calculated for each group, the CPU utilization rate with respect to the second thread Control means for controlling;
A CPU usage rate control device comprising: The execution environment is Java Virtual Machine,
The grouping means includes
The CPU usage rate control apparatus according to claim 1, wherein the second thread related to a software program other than a software program operating on the Java Virtual Machine is managed in a specific group. 3. The CPU usage rate control apparatus according to claim 1, further comprising switching means for switching a group to which the second thread corresponding to the first thread that has called itself belongs to another group. In a CPU usage rate control method for controlling the CPU usage rate of a software program operating on an execution environment of a single process,
By computer
Generating a first thread of the execution environment layer to execute the software program, and starting the software program as the first thread;
An association step of generating a second thread of the OS layer and associating with the first thread on a one-to-one basis each time the first thread is generated;
A grouping step in which the second threads are grouped into groups for each software program and stored in the storage means as group information;
An input step for receiving an input of a specified value of the CPU usage rate for each group;
The group information is read from the storage means, the CPU usage rate of the second thread belonging to each group is calculated based on the specified value of the CPU usage rate for each group, and the CPU usage rate is calculated for the second thread. Control steps to control;
A CPU usage rate control method comprising: A CPU usage rate control program for causing a computer to function as the CPU usage rate control device according to claim 1.

Images