JP2014235579A - Cpu usage rate control device, cpu usage rate control method, and cpu usage rate control program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To control CPU usage rate for each software module.SOLUTION: A CPU usage control device 1 includes mapping means 12 which generates a second thread of an OS layer for mapping to a first thread one-on-one each time the first thread is generated for executing a software module in an execution environment layer, group managing means 14 for managing a group in which the second thread is summarized for each software module, receiving means 16 for receiving a set value of CPU usage rate and a group of control object in the group, calculating means 15 for calculating CPU usage time of the second thread belonging to the group of control object on the basis of the set value of the CPU usage rate, and controlling means 11 for controlling CPU usage rate of the group of control object by using the CPU usage time.

Description

  The present invention relates to a CPU usage rate control device, a CPU usage rate control method, and a CPU usage rate control program for controlling a CPU usage rate for a software module in a software execution environment.

  A Java (registered trademark) VM exists as one of the software execution environments, and an OSGi bundle is a software module that operates on the Java VM.

  JavaVM (Java Virtual Machine) operates as a single process as viewed from the OS, and a software module that operates on the JavaVM can generate a plurality of Java threads, and a plurality of processes can be executed in parallel by the JavaVM. Can do. Depending on the application, it may be desired to preferentially process some Java threads. In the Java API specification, a method for changing the priority order of Java threads is defined (Non-Patent Document 1).

  In addition, OSGi (Open Services Gateway initiative) is a technique for configuring a piece of software with a plurality of Java software modules (Non-patent Document 2). 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 install / uninstall and start / stop during the OSGiFW operation.

“Class Thread, java.lang.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)> “OSGi Specifications”, OSGi Alliance, <URL: http://www.osgi.org/Specifications/HomePage>

  An end user or an operator of a software execution environment may want to ensure that certain critical bundles operate. For example, there is a case where it is desired to guarantee the operation of a certain bundle regardless of the operation load status of other bundles, for example, when it is desired to complete the calculation of the earthquake early warning within one second even during a game operation with high CPU load. Therefore, there is a need to control the CPU usage rate in bundle units, but there are the following problems.

  (1) The Java thread priority change in Non-Patent Document 1 does not specify the actual operation.

  (2) Since the bundle thread itself changes the Java thread priority in Non-Patent Document 1, the speculation of the end user who is the creator of the bundle may be different from the speculation of the operator of the software execution environment. In other words, the priority change cannot be controlled from the outside, and each bundle needs to be modified for external control.

  (3) The Java thread priority change of Non-Patent Document 1 is a comprehensive overview of the whole, and a mechanism for limiting priority setting is not defined. For this reason, for example, when the highest priority is set for all Java threads, there is a case where there is substantially no meaning.

  (4) A Java thread in the software 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 setting of priority in units of Java threads does not set in units of bundles.

  The present invention has been made in view of the above circumstances, and an object of the present invention is to provide a CPU usage rate control device, a CPU usage rate control method, and a CPU usage rate control program for controlling the CPU usage rate for each software module. There is to do.

  In order to solve the above-mentioned problem, a first aspect of the present invention is a CPU usage rate control device for controlling the CPU usage rate of a software module that operates in an execution environment of a single process. Each time a first thread for executing is generated, a second thread of the OS layer is generated and associated with the first thread in one-to-one correspondence with the second thread for each software module. A group management means for managing a group; a receiving means for receiving a control target group and a CPU usage rate setting value of the control target group from the group; and the control target group based on the CPU usage rate setting value And calculating means for calculating the CPU usage time of the second thread belonging to And a control means for controlling the CPU usage rate of the control target group.

  In the CPU usage rate control apparatus, the group management unit manages a process other than the execution environment and a non-control target group in a predetermined group.

  In the CPU usage rate control apparatus, the calculation means is configured such that a ratio between the CPU usage time of the control target group and the CPU usage time set for the predetermined group is a set value of the CPU usage rate of the control target group. The CPU usage time of the second thread belonging to the control target group is calculated so as to be the same as the ratio of the CPU usage rate that can be used by the predetermined group.

  In the CPU usage rate control apparatus, the execution environment is Java Virtual Machine, and the software module is an OSGi bundle.

  According to a second aspect of the present invention, there is provided a CPU usage rate control method for controlling a CPU usage rate of a software module operating in a single process execution environment performed by a computer, wherein the software module is executed in the execution environment layer. Each time the first thread is generated, a second thread of the OS layer is generated and associated with the first thread in one-to-one correspondence, and a group in which the second threads are grouped for each software module is managed. A group management step; a receiving step for receiving a control target group and a CPU usage rate setting value of the control target group from the group; and a second belonging to the control target group based on the CPU usage rate setting value A calculation step of calculating the CPU usage time of the thread, and when the CPU is used Using, it performs a control step for controlling the CPU usage rate of the control target group.

  In the CPU usage rate control method, the group management step manages a process other than the execution environment and a non-control target group in a predetermined group.

  In the CPU usage rate control method, the calculation step includes a ratio between the CPU usage time of the control target group and the CPU usage time set for the predetermined group, and a set value of the CPU usage rate of the control target group. The CPU usage time of the second thread belonging to the control target group is calculated so as to be the same as the ratio of the CPU usage rate that can be used by the predetermined group.

  The third aspect of the present invention is a CPU usage rate control program for causing a computer to function as the CPU usage rate control device.

  According to the present invention, it is possible to provide a CPU usage rate control device, a CPU usage rate control method, and a CPU usage rate control program for controlling the CPU usage rate for each software module.

It is a block diagram of the CPU usage rate control apparatus in one embodiment of this invention. It is a figure which shows an example of group information. It is a sequence diagram which shows control of CPU usage rate. It is a figure which shows an example of a setting screen. It is a figure which shows the holding information (initial state) of a bundle group management part. It is a figure which shows the holding information (OSGi starting state) of a bundle group management part. It is a figure which shows the holding information (CPU resource control start state) of a bundle group management part. It is a figure which shows the holding information (CPU resource control completion state) of a bundle group management part. It is explanatory drawing for demonstrating this embodiment.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  In the present embodiment, a software execution environment that operates in one process on a certain OS and a plurality of software modules (software programs) that operate in the software execution environment will be described. As a specific example, in the present embodiment, JavaVM will be described below as an example of a software execution environment, and an OSGi bundle will be described as an example of a software module. However, the present invention is not limited to this, and other software execution environments having a similar mechanism. It is also applicable to software modules.

  Further, as a premise of the present embodiment, the CPU is scheduled by the OS, and a unit of the scheduling includes a process, LWP (Light Weight Process) and the like. LWP is a thread in the OS layer.

  As a mechanism for causing software module processes to operate in parallel in time, a process and an LWP (thread) exist in the OS layer. 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 a Java thread corresponding to itself, but the Java thread and the LWP are independent from each other because the operating layers are different.

  FIG. 1 is a block diagram showing a functional configuration of a CPU usage rate control device 1 according to an embodiment of the present invention. The CPU usage rate control device 1 shown in FIG. 1 includes an LWP unit CPU control unit 11, a Java thread / LWP correspondence unit 12, a bundle threading unit 13, a bundle group management unit 14, an LWP group management unit 15, and a bundle CPU. A usage rate setting unit 16.

[LWP unit CPU control unit 11]
The LWP unit CPU control unit 11 (control unit) operates in the OS layer, and controls the CPU usage rate in LWP units or LWP group units. Specifically, the CPU usage rate is controlled by holding the CPU usage time value (CPU scheduling ratio) for each LWP or each group of LWP and scheduling the CPU according to the ratio.

When controlling the CPU, for example, Linux (registered trademark) cgroups can be used. cgroups is a Linux kernel function that controls the CPU usage rate in units of processes, LWP units, or LWP groups. cgroups is described in, for example, http://en.wikipedia.org/wiki/Cgroups [Java Thread / LWP Corresponding Unit 12]
The Java thread / LWP correspondence unit 12 (association means) operates in the Java VM layer, and each time one Java thread is generated, one LWP for executing the Java thread is generated, and the Java thread on the Java VM is set as the OS. The above LWP is made to correspond 1: 1.

[Bundle threading unit 13]
The bundle threading 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 for executing the bundle is generated. Then, the bundle is activated as a Java thread. The process for calling the bundle process includes, for example, eventing from OSGiFW to the bundle such as starting and stopping the bundle.

  In addition, since the Java thread generated by the Java thread / LWP correspondence unit 12 is associated with the LWP, the bundle threading unit 13 generates a new Java thread and at the same time, assigns the ID of the corresponding LWP from the OS. Can be acquired.

  Further, since the OSGiFW can acquire the ID of the bundle that the Java thread intends to call, the bundle threading unit 13 acquires the ID of the bundle that is to be called, and the Java thread / LWP corresponding unit 12 The ID is associated with the LWP ID generated by, and delivered to the bundle group management unit 14.

  Further, the bundle threading unit 13 notifies the bundle group management unit 14 when a bundle is newly installed or uninstalled. The notification information includes installation or uninstallation, the bundle ID, and the like.

[Bundle group management unit 14]
The bundle group management unit 14 (group management means) operates on the OSGiFW and manages the LWP belonging to the bundle for each bundle. The bundle ID notified from the bundle threading unit 13 and the LWP ID are stored in a storage unit (not shown). In addition, the LWP group management unit 15 is instructed to generate / delete a group. Specifically, the setting information from the bundle CPU usage rate setting unit 16 is received, an instruction to generate a group is issued for each bundle set by the user as a CPU usage rate control target, and other groups are deleted. Instructs the LWP group management unit 15. At that time, the information instructed by the bundle group management unit 14 includes the generation / deletion instruction, the bundle ID (group ID), the CPU usage rate set by the user, and the ID of the LWP belonging to the bundle. And are included.

[LWP group management unit 15]
The LWP group management unit 15 (calculation unit) operates in the OS layer, and bundles and handles the Java thread group associated with the LWP by the bundle threading unit 13 and calls the LWP unit CPU control unit 11. The LWP group management unit 15 may be mounted and operated in a layer other than the OS layer.

  Specifically, the LWP group management unit 15 generates a “group” for each bundle ID instructed by the bundle group management unit 14, and sends the LWP ID and the bundle ID from the bundle group management unit 14. Each time, the ID of the LWP belongs to the group of the corresponding bundle ID, and is stored in a storage unit (not shown) as group information.

  FIG. 2 shows an example of group information. In the group information shown in the figure, the ID of the corresponding bundle, the ID of the LWP included in the group, the set value, and the control value are stored in association with each group (for each bundle). The set value is a value input to the bundle CPU usage rate setting unit 16 by the user, and the CPU usage rate is used in the present embodiment. The set value is a value for ensuring the operation for the group.

  The control value is a value set for the group in order to be input to the LWP unit CPU control unit 11. The control value is calculated based on the set value as will be described later. When the above-described cgroups is used in the LWP unit CPU control unit 11, the value of cpu.shares is set as a control value. Note that cpu.shares is an integer value (CPU scheduling ratio) of CPU usage time allocated to the corresponding group in cgroups.

  Further, the LWP group management unit 15 also manages processes other than JavaVM by “group” at the same time.

  Here, the LWP group management unit 15 will explain to which group a certain LWP and process belong. In the present embodiment, the belonging group is determined based on the following rules.

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

  (2) The LWP ID delivered from the bundle group management unit 14 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) LWPs other than (1) to (3) above belong to a root group.

  (5) If the process and LWP are stopped or disappear, they are deleted from the group to which they belong.

  The group and group information are generated or deleted based on the following rules.

  (A) Only one route group is generated when the LWP group management unit 15 is activated.

  (B) A group of each bundle is generated when an instruction is given from the bundle group management unit 14. It is not generated when the bundle ID is the same as the group already held.

  (C) When there is an instruction to delete a group from the bundle group management unit 14, it is deleted. In that case, the LWP belonging to the group instructed to be deleted belongs to the root group.

[Bundle CPU usage rate setting unit 16]
The bundle CPU usage rate setting unit 16 operates in the OSGi layer, and includes a setting GUI (Graphical User Interface) for a user (operator or end user), a Web UI, and the like. Note that the bundle CPU usage rate setting unit 16 may be mounted and operated in a layer other than the OSGi layer.

  The bundle CPU usage rate setting unit 16 acquires from the OSGiFW a list of bundles already installed at the time of GUI generation and their operating states (operating / not operating), and displays them on the user terminal 2.

  The user designates and sets the CPU resource to be allocated to a certain bundle (regardless of the operation state) by the CPU usage rate (%). The bundle CPU usage rate setting unit 16 receives the setting contents of the user and outputs them to the bundle group management unit 14. Further, the bundle CPU usage rate setting unit 16 issues a warning to the user when the total CPU usage rate exceeds a predetermined threshold. For example, when the total CPU usage rate set by the user exceeds 99%, a warning message is transmitted to the user terminal 2.

  The CPU usage rate control device 1 of the present embodiment described above can use a general-purpose computer system including a CPU, a memory, an external storage device such as an HDD, and the like. In this computer system, each function of the CPU usage rate control device 1 is realized by the CPU executing a program for the CPU usage rate control device 1 loaded on the memory. Further, the program of the CPU usage rate control device 1 can be stored in a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, a DVD-ROM, or can be distributed via a network.

  Next, the operation of this embodiment will be described.

  FIG. 3 is a sequence diagram showing the operation of the CPU usage rate control device 1 in the present embodiment.

  In FIG. 3, the flow of CPU resource control of each bundle when the user changes the CPU resource control setting of each bundle is shown below.

  Step S10: The bundle group management unit 14 always monitors the life cycle (installation and uninstallation) of each bundle, and holds the bundle ID and LWP ID notified from the bundle threading unit 13. .

  Step S11: First, the user terminal 2 transmits the bundle selected by the user's instruction and the CPU usage rate assigned to the bundle to the bundle CPU usage rate setting unit 16.

  FIG. 4 is an example of a setting screen displayed on the user terminal 2 by the bundle CPU usage rate setting unit 16. The user uses the setting screen displayed on the user terminal 2 to set the bundle to be controlled and the CPU usage rate assigned to the bundle.

  The column “bundle symbolic name” 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 existing 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. This also indicates that the CPU usage rate of this set value is given to the corresponding bundle at a minimum even when the load on the computer increases. On the other hand, when the load on the computer is small, the CPU may be used beyond this setting value. Conversely, when the set bundle is not processing, the other bundles use this setting value. The CPU may be used.

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

  Step S12: The bundle CPU usage rate setting unit 16 receives the user setting information transmitted in step S11 and sends it to the bundle group management unit 14. Here, the information sent to the bundle group management unit 14 includes the ID of each bundle that is set as a control target by the user and “minimum quality assurance” that is set as the control target. CPU utilization ". Note that a bundle whose “control start” is ON is output to the bundle group management unit 14 regardless of whether the bundle is in operation (ACTIVE) or not.

  Step S13: The bundle group management unit 14 receives information from the bundle CPU usage rate setting unit 16, instructs the LWP group management unit 15 to generate a group for each bundle set as a control target by the user, Instructs other groups to be deleted.

  The information instructed to the LWP group management unit 15 includes, for each bundle set as a control target, a generation instruction, a bundle ID (group ID), and a CPU usage rate set by the user (minimum quality assurance CPU usage rate). ) And the ID of the LWP belonging to the bundle. On the other hand, for each non-control target bundle that is not set as a control target, there are a deletion instruction, a bundle ID (group ID), an LWP ID belonging to the bundle, and the like.

  Step S14: The LWP group management unit 15 receives the instruction information from the bundle group management unit 14, generates (or updates) a corresponding group for the control target bundle for which generation is instructed, and performs non-control for which deletion is instructed For the target bundle, the corresponding group is deleted and the group information (FIG. 2) is updated.

  In addition, when the group of the ID of the bundle to be controlled that has been instructed already exists in the group information, the group information is updated using the instruction information transmitted in step S13 without newly generating the group. To do. If the group of the ID of the bundle to be controlled that is instructed to be deleted exists in the group information, the record of the group is deleted, and the LWP belonging to the group belongs to the root group.

  For each group of bundles instructed to generate, specifically, the LWP group management unit 15 uses the instruction information transmitted in step S13 to set the bundle ID, the LWP ID to which the user belongs, and the user setting. The CPU usage rate (setting value) is registered (or updated) in the group information. Then, the LWP group management unit 15 calculates a control value to the LWP unit CPU control unit 11 corresponding to the CPU usage rate, as will be described later.

  For example, when using the above cgroups as the LWP unit CPU control unit 11, cpu. The value of shares is calculated. In addition, when using the Linux nice, it is calculated using a CPU scheduling function on the OS that is uniquely implemented.

  Step S15: The LWP group management unit 15 inputs the calculated control value of each group (for example, the value of cpu.shares) to the LWP unit CPU control unit 11. Note that the processing in step S14 and step S15 is performed regardless of whether or not the bundle state is in operation.

  Step S16: The LWP unit CPU control unit 11 controls the CPU usage rate of the LWP belonging to each group (bundle) based on the control value input from the LWP group management unit 15. Specifically, the CPU scheduling is performed so that the ratio of the CPU usage time used by the LWPs belonging to each group is equal to the ratio of the CPU usage rate setting values set for each group. As a result, the CPU usage time is controlled so that the CPU usage rate set by the user in S11 is obtained. For example, in cgroups, cpu. Control is performed to relatively distribute the CPU usage time in accordance with the integer ratio given as shares.

  However, if there is no LWP belonging to a group, CPU scheduling is not performed for that group. Alternatively, although scheduling is performed, since no LWP exists, it may be skipped to the next scheduling.

  With the above processing, the CPU usage time of each bundle is controlled to be the CPU usage rate input in step S11.

  Next, the LWP group management unit 15 will be described in detail.

  Here, the details of the LWP group management unit 15 will be described by taking as an example the case of using Linux as the OS, JavaVM and OSGi as the software execution environment, OSGi bundle as the software module, and cgroups as the LWP unit CPU control unit 11. 5 to 8 show transition of information held by the LWP group management unit 15.

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

  Here, cgroups cpu. The shares (control value) is a fixed value N. The fixed value N may be set to an arbitrary value because it is in the initial state, but here it is set to 1024 in consideration of the balance with the CPU usage rate set for other bundles. In the following example, calculation is performed based on this value.

  Next, FIG. 6 illustrates a state after JavaVM and OSGi are activated, setting information from the user is input to the bundle CPU usage rate setting unit 16, and a group generation instruction is issued from the bundle group management unit 14.

  The LWP group management unit 15 generates a group (“ProcessGroup” in the figure) for each bundle set as a control target by the user. That is, the instruction information sent from the bundle group management unit 14 notifies the ID of the bundle to be controlled that is instructed to generate, the ID of the LWP, and the CPU usage rate set by the user. Group information is generated.

Then, the LWP group management unit 15 uses the CPU usage rate set by the user for each group of the bundles to be controlled, using cpu. Shares is calculated by the following equation.

  The left side of the above formula indicates the cpu. Of the bundle (group) to be controlled. This is the value (control value) of shares. The right-hand side denominator means the CPU usage rate that can be used by all non-control target processes and LWPs. The “user setting CPU usage rate” in the numerator on the right side is the CPU usage rate (setting value) set by the user. Also, “1024” in the numerator on the right side is a fixed value N set in the root group, and all the processes to be controlled and the cpu. The total value of shares.

  The above formula shows that the ratio of “the value of cpu.shares of the control target bundle” and “the total of the values of cpu.shares set in all non-control target processes and LWPs” is “the user in the control target bundle “Cpu.shares value of control target bundle” is calculated so as to be equal to the ratio of “CPU usage rate set” and “CPU usage rate that can be used by all non-control target processes and LWPs”. is there. Note that the calculation is performed for all bundles to be controlled regardless of the bundle state (whether or not it is operating).

  Next, FIG. 7 shows a case where a bundle (bundle C in the figure) as a control target is in accordance with a user instruction (a state in which control is started). FIG. 8 shows a case where a certain bundle (bundle C in the figure) is removed from the control target (a state where the control is terminated). In both cases of FIG. 7 and FIG. 8, cpu. Recalculate the value of shares.

  In the present embodiment described above, each time a Java thread for executing a bundle is generated, an OS layer LWP is generated, associated with the Java thread on a one-to-one basis, and the LWP is collected for each bundle. When a group is managed and a control target group and a CPU usage rate setting value of the control target group are received from the group, the CPU usage time of the LWP belonging to the control target group is determined based on the CPU usage rate setting value. Calculate and control the CPU usage rate of the control target group. Thereby, in this embodiment, it is possible to control the CPU usage rate in units of bundles and guarantee the CPU usage rate set in units of bundles.

  Specifically, as shown in FIG. 9, the “lumps (= bundles)” in the software execution environment (Java VM) operating in a single process are usually not visible from the OS layer. That is, it is not a target of the CPU scheduling function. Therefore, in the present embodiment, the bundle is first divided into units called Java threads, associated with the OS layer LWP, and then the Java thread (LWP) is handled in units of “lumps” called bundles. The layer can recognize the “bundle” of the bundle.

  Further, in this embodiment, the bundles and processes to be controlled that are not set by the user are grouped into one route group so that the CPU usage rate is evenly allocated. And there is an advantage that no imbalance occurs in the process.

  That is, in the present embodiment, the bundle group management unit 14 that manages which Java thread (LWP) corresponds to which bundle, and “how much CPU usage is given to which bundle” set by the user In order to satisfy the above, the LWP group management unit 15 that calculates the CPU usage time (scheduling ratio) for the bundle is provided separately, and a group is created only for the bundle to be controlled set by the user, CPU usage time is calculated. As a result, since the LWP of the non-control target bundle belongs to the root group, the CPU scheduling receives the same treatment as the process, and no imbalance occurs in the non-control target bundle and the process.

  In addition, this invention is not limited to the said embodiment, A various change and application are possible within a claim.

1: CPU usage rate control device 11: LWP unit CPU control unit 12: Java thread / LWP support unit 13: Bundle threading unit 14: Bundle group management unit 15: LWP group management unit 16: Bundle CPU usage rate setting unit 2: User terminal

Claims (8)

A CPU usage rate control device for controlling the CPU usage rate of a software module operating in an execution environment of a single process,
In the execution environment layer, each time a first thread for executing a software module is generated, an association unit that generates a second thread of the OS layer and associates the first thread with the first thread one-to-one;
Group management means for managing a group in which the second threads are grouped for each software module;
A receiving unit that receives a set value of a control target group and a CPU usage rate of the control target group from the group;
Calculation means for calculating a CPU usage time of a second thread belonging to the control target group based on a set value of the CPU usage rate;
And a control unit that controls the CPU usage rate of the control target group using the CPU usage time. The CPU usage rate control device according to claim 1,
The group management means manages a process other than the execution environment and a non-control target group in a predetermined group. The CPU usage rate control device according to claim 2,
The calculation means can use a ratio between the CPU usage time of the control target group and the CPU usage time set for the predetermined group, the set value of the CPU usage rate of the control target group, and the predetermined group. The CPU usage rate control device calculates the CPU usage time of the second thread belonging to the control target group so that the CPU usage rate ratio is the same. A CPU usage rate control device according to any one of claims 1 to 3,
The execution environment is Java Virtual Machine,
The CPU usage rate control device, wherein the software module is an OSGi bundle. A CPU usage rate control method for controlling the CPU usage rate of a software module operating in a single process execution environment performed by a computer,
In the execution environment layer, each time a first thread for executing a software module is generated, an association step of generating a second thread of the OS layer and associating the first thread with the first thread one-to-one;
A group management step for managing a group in which the second threads are grouped for each software module;
Receiving a control target group and a set value of the CPU usage rate of the control target group from the group;
A calculation step of calculating a CPU usage time of a second thread belonging to the control target group based on a set value of the CPU usage rate;
And a control step of controlling the CPU usage rate of the group to be controlled using the CPU usage time. The CPU usage rate control method according to claim 5,
In the group management step, a process other than the execution environment and a non-control target group are managed by a predetermined group. The CPU usage rate control method according to claim 6,
In the calculation step, a ratio between the CPU usage time of the control target group and the CPU usage time set for the predetermined group is the set value of the CPU usage rate of the control target group and the predetermined group is available. A CPU usage rate control method, comprising: calculating a CPU usage time of a second thread belonging to the control target group so that the CPU usage rate ratio is the same.   A CPU usage rate control program for causing a computer to function as the CPU usage rate control device according to any one of claims 1 to 4.

Images