JP2011242890A - Request processing method, request processing program and request processing apparatus - Google Patents

Abstract

PROBLEM TO BE SOLVED: To prevent shortage of computer resources in the future by executing requests within the range of computer resources that can be provided.SOLUTION: A memory usage control part 108 of a computer 30 calculates an increase in memory quantity used for a request currently being executed as a third memory quantity, references a maximum size management table 118 to acquire the maximum memory quantity for a newly accepted request as a fourth memory quantity, and acquires the current available capacity of a user memory area 111 from JavaVM. If the current available capacity is greater than the sum of the third and fourth memory quantities, it allows the execution of the new request.

Description

  The present invention relates to a request processing method, a request processing program, and a request processing apparatus.

  In a system connected from a client device via a network, when a request requested from the client device cannot be executed within the framework of the amount of memory supplied by the system, the requested request is rejected by rejecting the request. A technique for controlling the flow rate flowing into the air is disclosed in Patent Document 1 and the like. With this request flow rate control system, a memory shortage of a computer that processes the received request is prevented.

Japanese Patent Laid-Open No. 10-301883

  When a Java (registered trademark) application server is operated as a computer for processing a request, a plurality of processes are executed in parallel on the same process mainly for reasons of performance improvement. Therefore, when there is a request that is already being executed, execution of a new request may be requested. When a request that is already being executed and a newly requested request share the memory space of the same memory resource, the memory space used by all the requests needs to be within the maximum capacity of the memory resource.

  Here, the amount of memory used by the request may change (increase) over time. For example, even if the amount of free memory at a predetermined time is larger than the amount of memory required to execute a new request, the amount of memory used by a request that has already been executed increases after the predetermined time. The amount of memory required for execution will be insufficient afterwards.

  However, in a conventional request flow rate control system such as Patent Document 1, whether or not to execute a new request refers only to the current memory amount (at a predetermined time), and takes into account the increase in usage thereafter. Therefore, it is not possible to prevent the above-mentioned subsequent memory shortage.

  Therefore, the main object of the present invention is to prevent the shortage of computer resources in the future by executing requests within the range of computer resources that can solve and provide the above-mentioned problems.

In order to solve the above-described problem, the present invention provides a request processing device that executes a received request,
The request processing device is a Java application server that operates a Java (registered trademark) VM (Virtual Machine),
The request processing device stores the user memory area and the JavaVM management area in the storage means, and has a memory usage control unit,
The user memory area stores an object embodying a program for executing a request,
In the JavaVM management area, the object ID of the object stored in the user memory area, the amount of memory used by the object, and the request ID of the request that created the object are associated with each other for object management. Is stored as data, and the maximum memory amount used to execute the request for each request ID is stored in association with the maximum size management data,
When the memory usage control unit determines whether to execute a newly received request,
With reference to the maximum size management data, the maximum memory amount of the currently executing request is acquired as the first memory amount,
By referring to the object management data, the memory amount currently used by the object corresponding to the request ID of the currently executing request is acquired as the second memory amount, and the first memory amount is obtained from the second memory amount. Calculate the subtracted value as the third memory amount,
With reference to the maximum size management data, the maximum memory amount of the newly accepted request is acquired as the fourth memory amount,
The current free space in the user memory area is acquired from the JavaVM, and when the acquired current free space is larger than the sum of the third memory amount and the fourth memory amount, the newly accepted request It is characterized by permitting execution of.
Other means will be described later.

  According to the present invention, a shortage of computer resources can be prevented in the future by executing a request within the range of computer resources that can be provided.

It is explanatory drawing which shows the outline | summary of the apparatus structure of the request processing system regarding one Embodiment of this invention. It is explanatory drawing which shows an example of the executing request management table regarding one Embodiment of this invention. It is explanatory drawing which shows an example of the object management table regarding one Embodiment of this invention. It is explanatory drawing which shows an example of the maximum size management table regarding one Embodiment of this invention. It is explanatory drawing which shows an example of the maximum size information file regarding one Embodiment of this invention. It is explanatory drawing which shows the discriminant for the feasibility determination of the new request regarding one Embodiment of this invention. It is explanatory drawing which shows the flow of the message between the components in the manual setting mode regarding one Embodiment of this invention. It is explanatory drawing which shows the flow of the message between the components in the test mode regarding one Embodiment of this invention. It is a flowchart which shows the outline | summary of the request process in the manual setting mode regarding one Embodiment of this invention. It is a flowchart which shows the detail of the memory usage-amount control process regarding one Embodiment of this invention. It is a flowchart which shows the detail of the process which calculates the memory usage of all the requests in execution regarding one Embodiment of this invention. It is a flowchart which shows the detail of the process which calculates the memory usage of the request regarding one Embodiment of this invention. It is a flowchart which shows the detail of the execution process of the request regarding one Embodiment of this invention. It is a flowchart which shows the outline | summary of the request process in the test mode regarding one Embodiment of this invention. It is a flowchart which shows the GC process which the GC (Garbage Collection) process part regarding one Embodiment of this invention performs. It is a flowchart which shows the detail of the update process of pre-GC maximum usage amount regarding one Embodiment of this invention. It is a flowchart which shows the detail of the update process of the maximum usage amount after GC regarding one Embodiment of this invention.

  Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

FIG. 1 is an explanatory diagram showing an outline of the device configuration of the request processing system. In the request processing system, the terminal 10 and the computer 30 are connected via the network 20.
The terminal 10 is a client device that transmits a request for requesting execution of a business process designated by the computer 30.

The computer 30 (Java application server) includes a communication device 40, a CPU 50, an input device 60, an output device 70, an auxiliary storage device 80, and a main storage device 95, and is connected to each other via a bus 90.
The communication device 40 is connected to the network 20 connected to the terminal 10.
The CPU 50 executes various processes by executing various programs stored in the main storage device 95.
The input device 60 is used for inputting information and instructions necessary for the computer 30.
The output device 70 displays information output from the computer 30.
The auxiliary storage device 80 is configured as a storage unit that stores a program and data necessary for executing the program in a storage unit. The maximum size information file 122 (maximum size management data) is included in the auxiliary storage device 80. Note that the maximum size information file 122 is, for example, copied from a CSV file 122b that has already been manually created.

The main storage device 95 includes a container management area 101, a user memory area 111, and a Java VM (Virtual Machine) management area 113.
The container management area 101 stores a request reception unit 102, a request ID numbering unit 103, a request control unit 104, a program processing unit 105, a memory usage control unit 108, a command reception unit 109, and a command execution unit 110.
The user memory area 111 stores an object 112 created by a program constituting the program processing unit 105.
The Java VM management area 113 includes an object management table 114 (object management data), an object management unit 115, an executing request management table 116, a maximum memory usage calculation unit 117, a maximum size management table 118, an object ID numbering unit 119, A Java API (Application Program Interface) 120 and a GC processing unit 121 are included.

  The request reception unit 102 receives a request from the terminal 10, assigns a unique request ID to the request ID numbering unit 103, and notifies the request control unit 104 of the request URL and the request ID.

  The request control unit 104 receives the request URL and the request ID notified from the request reception unit 102, notifies the memory usage amount control unit 108 of the request URL, and requests a determination as to whether or not the request can be executed.

In accordance with the request execution determination request notified from the request control unit 104, the memory usage control unit 108 determines whether the received request can be executed in the following order (1) to (3).
(1) In accordance with a discriminant described later in FIG. 7 (first determination), it is determined whether the accepted request can be executed. Here, when it is determined that the request can be executed, a message to that effect is returned to the request control unit 104.
(2) Request the Java API 120 to perform GC and increase the free memory. After the GC, it is determined whether or not the accepted request can be executed according to a discriminant (second determination) described later in FIG. Here, when it is determined that the request can be executed, a message to that effect is returned to the request control unit 104.
(3) If the received request cannot be executed due to a lack of free memory, the request control unit 104 is replied.
The request control unit 104 that receives the response in (1) or (2) activates the container processing unit 106 and executes the received request. On the other hand, the request control unit 104 that has received the response in (3) notifies the request reception unit 102 that the execution of the request has not been permitted.

The program processing unit 105 includes a container processing unit 106 and a user processing unit 107.
The container processing unit 106 performs request control, transaction control, and the like. When the container processing unit 106 receives a processing request from the request control unit, the container processing unit 106 stores the request information in the executing request management table 116. Further, the container processing unit 106 executes the user processing unit 107. After the processing of the user processing unit 107 ends, the container processing unit 106 deletes the request information from the executing request management table 116. The user processing unit 107 executes a process created by the user to execute the business process. Part. Further, when using an object, the user processing unit 107 requests the object management unit 115 to generate an object, and uses the object 112 generated in the user memory area.

The object management unit 115 is a processing unit that manages the object 112 in the user memory area 111.
The object management unit 115 receives a request from the user processing unit 107, assigns a unique object ID in the object ID numbering unit 119, creates the requested object 112, and stores the object information in the object management table 114. Store.
Further, the object management unit 115 receives the request ID from the memory usage control unit 108 and the maximum memory usage calculation unit 117, and returns a list of the sizes of the objects created by the request.
Further, the object management unit 115 receives a request from the GC processing unit 121, deletes information on the object 112 from the object management table 114, and releases the object 112 from the user memory area 111.

  The Java API 120 is an existing interface provided by Java. The Java API 120 receives a request for acquiring the current free memory usage and a GC issuance request from the memory usage control unit 108.

  When the free memory area of the user memory area 111 is reduced or when a GC issuance request is received from the Java API 120, the GC processing unit 121 is an object that can be discarded among the objects 112 stored in the user memory area 111. And requests the object management unit 115 to release the object. This GC process is implemented in Java.

The maximum size information file 122 stores the maximum size of memory used by each URL. Specifically, the user stores the total memory usage used in requests to each URL and the memory usage at the moment of using the most memory before starting the processing. The maximum size information file 122 may be read every time the memory usage control unit 108 receives a request, or may be read and stored in the main storage device 95 when the Java application server is activated.
The creation processing of the maximum size information file 122 is realized by any one of the following two modes (1) and (2).

(1) The manual setting mode is a mode in which the data content of the maximum size information file 122 is explicitly specified by manual setting by an administrator or the like (see FIG. 7 for details).
For this reason, when receiving a “creation request specifying the data content of the maximum size information file 122” as a command from the administrator, the command receiving unit 109 transfers control of processing to the command executing unit 110.
Alternatively, when the command receiving unit 109 receives the CSV file 122b of FIG. 1 that has been manually created as a command from the administrator, the command receiving unit 109 transfers the processing control to the command execution unit 110.
The command execution unit 110 receives the request from the command reception unit 109 and outputs the data content specified by the command or the data content of the CSV file 122b as the maximum size information file 122 as it is.

(2) The test mode is a mode in which the data content of the maximum size information file 122 is acquired by measuring an actual measurement value as a result of actually operating a request (refer to FIG. 8 for details).
Therefore, in the test mode, in addition to the configuration required in the manual setting mode, the maximum memory usage calculation unit 117 and the maximum size management table 118 are used.
The maximum memory usage calculation unit 117 totals (totals) the memory usage of the object 112 for each request ID, and stores the result in the maximum size management table 118.
Then, the command receiving unit 109 receives a command request from the administrator, and transfers control of processing to the command execution unit 110. The command execution unit 110 receives a request from the command reception unit 109, refers to the information stored in the maximum size management table 118, and formats the referenced information (from a table format to a CSV (Comma-Separated Values) format). Export processing), and outputs the result to the maximum size information file 122.

Note that the longer the operation period of the test mode, the better. By operating the test mode for a long period of time, the update frequency of the maximum value of the memory usage increases, so the accuracy of the maximum memory usage stored in the maximum size management table 118 is also improved.
Furthermore, the information in the maximum size information file 122 created using the test mode is used not only for determining whether or not a new request can be executed, but also for other purposes such as memory tuning and specifying requests that consume a large amount of memory. May be.

FIG. 2 is an explanatory diagram illustrating an example of the in-execution request management table 116.
The request management table 116 includes a request ID field 201 and a URL field 202. Records in the in-execution request management table 116 are stored by the container processing unit 106 when a request is received, and are deleted by the container processing unit 106 when the request ends. For this reason, it is possible to acquire a list of executing requests by referring to the executing request management table 116.
The request ID field 201 stores a request ID that uniquely identifies a request received from the terminal 10. The request ID is generated in the request ID numbering unit 103 when a request is received.
The URL field 202 stores the URL included in the request received from the terminal 10.

FIG. 3 is an explanatory diagram illustrating an example of the object management table 114. The object management table 114 includes an object ID field 301, a request ID field 302, and an object size field 303.
Records in the object management table 114 are stored by the object management unit 115 when the object 112 is created, and are deleted by the object management unit 115 when the object 112 is released. The object management table 114 is referred to by the object management unit 115 in order to calculate the memory usage for each request.

The object ID field 301 stores an object ID for uniquely identifying the object by the object management unit 115. The object ID number generation unit 119 generates the object ID in response to a request from the object management unit 115.
The request ID field 302 is the same as the request ID field 201 of the executing request management table 116. The request ID field 302 stores the request ID of the request that created the object. The object size field 303 is the amount of memory used by the object 112. The object management table 114 stores the memory amount secured when the object 112 is created in the object size field 303.

FIG. 4 is an explanatory diagram showing an example of the maximum size management table 118. The maximum size management table 118 includes a URL field 401, a pre-GC maximum use amount field 402, and a post-GC maximum use amount field 403.
The URL field 401 is the same as the URL field 202 of the executing request management table 116.
The pre-GC maximum usage field 402 and the post-GC maximum usage field 403 each store the maximum value of the memory usage used by the request in the lifetime of the request (from the start time to the end time).
The pre-GC maximum usage field 402 stores the maximum value of the memory usage before the GC processing by the GC processing unit 121 is performed.
The post-GC maximum use amount field 403 stores the maximum value of the memory use amount after the GC processing by the GC processing unit 121 is performed.

  The maximum memory usage calculation unit 117 monitors the memory usage of the request during the lifetime of the request, and the current memory usage is larger than the maximum value of the memory usage already stored in the maximum size management table 118. Exceeds the current memory usage, the pre-GC maximum usage field 402 (before GC processing) or the post-GC maximum usage field 403 (GC processing). Store (update value).

FIG. 5 is an explanatory diagram showing an example of the maximum size information file 122. The maximum size information file 122 includes a URL field 501, a pre-GC maximum use amount field 502, and a post-GC maximum use amount field 503. The maximum size information file 122 is a data format of the maximum size management table 118 in CSV format.
The URL field 501 has the same contents as the URL field 401.
The pre-GC maximum usage field 502 has the same contents as the pre-GC maximum usage field 402.
The post-GC maximum use amount field 503 has the same contents as the post-GC maximum use amount field 403.

  FIG. 6 is an explanatory diagram showing a discriminant for determining whether a new request can be executed. 6 (a) and 6 (b) are diagrams for explaining problems in discriminants in comparative examples such as Patent Document 1, and FIG. 6 (c) is a diagram for comparing discriminants in this embodiment. It is a figure explaining that the problem of an example is solved.

FIG. 6A shows the memory usage status in the user memory area 111 when the new request R3 arrives.
In the user memory area 111, existing requests (R1, R2) are being executed, and each uses the current amount of memory. However, the current free memory amount in the user memory area 111 has a sufficient free space enough to accommodate the current memory usage (necessary at the start of execution) of the new request R3.
Therefore, the new request R3 is determined to be executable by satisfying the following discriminant of the comparative example.
When (current free memory amount) = (memory capacity of the user memory area 111) − (current usage amount of R1) − (current usage amount of R2), the discriminant “(current usage amount of R3) <(current The amount of free memory) is satisfied.

FIG. 6B shows a memory usage state in the user memory area 111 when a further time elapses from the time of FIG.
The existing requests (R1, R2) use the memory corresponding to the maximum usage amount as a result of additionally using the additional amount of memory from the current usage amount in FIG. 6A. Therefore, at the time shown in FIG. 6B, the current free memory amount is reduced by an increase in the memory usage compared to the time shown in FIG. As a result, the amount of memory that can be used for the new request R3 is reduced, and the memory becomes short afterwards even though it can be executed in FIG.

FIG. 6C shows the processing content of the discriminant of the present embodiment at the time of FIG. In FIG. 6A, the current usage of the existing request (R1, R2) was referred to. In FIG. 6C, in addition to the current usage, the maximum of the existing request (R1, R2) The usage amount is read from the storage means as a value registered in advance. Then, it is determined whether or not the following discriminant is satisfied.
(Maximum usage of R3) <(Available free memory in the future)
This discriminant is equivalent to the following discriminant because (the amount of free memory that can be used in the future) = (current amount of free memory) − (increase in R1) − (increase in R2).
(Increase amount of R1) + (Increase amount of R2) + (Maximum usage amount of R3) <(Current free memory amount)
In this example, since (the increase in R1) + (the increase in R2) is large, (the amount of free memory that can be used in the future) is small, so it is determined that this discriminant is not satisfied. That is, the discriminant of FIG. 6C differs from the discriminant of FIG. 6A in that not only the current memory amount (current use amount, free memory amount) but also the future (maximum) memory use amount. By referring to the above, it is possible to suppress a memory shortage afterwards.

  As described above, the discriminant shown in FIG. 6 can be generalized as shown below.

The discriminant of FIG. 6A is as follows.
(DRC) + (DNC) <(RS)
Here, DRC (Demand Running Current) indicates the total of the current (Current) memory usage (Demand) of the running requests R1 and R2.
DNC (Demand New Current) indicates the current (Current) memory usage (Demand) of the new (New) request R3.
RS (Resource Supply) indicates the supply amount (Supply) of the memory resource (Resource) provided by the user memory area 111.

The situation in FIG. 6B is expressed by the following equation.
(DRM) + (DNM)> (RS)
Here, DRM (Demand Running Maximum) indicates the sum of the maximum (Maximum) memory usage (Demand) of the running requests (R1, R2).
DNM (Demand New Maximum) indicates the maximum memory usage (Demand) of the new (New) request R3.

The discriminant of FIG. 6C is as follows.
(DRM) + (DNM) <(RS)
Here, DRI (Demand Running Increase) indicates the total amount of memory usage (Demand) of the increments (Increase) of the requests R1 and R2 being executed (Running). By (DRM) = (DRC + DRI), the discriminant of FIG. 6C can be transformed as follows. Since the expressions in these expression modifications are equivalent in content, any of the expressions in the expression modification may be used as a discriminant.
(DRM) + (DNM) <(RS)
(DRC + DRI) + (DNM) <(RS)
(DRI) + (DNM) <(RS)-(DRC)
(DRI) + (DNM) <(RSC)
Here, RSC (Resource Supply Current) is the current (Current) free memory amount (Resource Supply) and is equivalent to “(RS) − (DRC)”.

Furthermore, as shown below, each parameter used in the discriminant can be acquired.
The DRC (first memory amount) acquires the request ID of the request being executed from the request ID field 201, searches for the request ID from the request ID field 302, and sets the object size field 303 of the retrieved record for each request ID. Can be calculated by summing to
The DRM (second memory amount) acquires the URL of the request being executed from the URL field 202, searches the URL field 401 (= URL field 501) for the URL, and the maximum used amount field before GC of the searched record. It can be acquired as values of 402 (= maximum usage amount before GC field 502) and a maximum usage amount after GC field 403 (= maximum usage amount after GC field 503).
The DRI (third memory amount) can be calculated by “DRM-DRC”.

The DNM (fourth memory amount) searches the URL field 401 (= URL field 501) for the URL of the newly arrived request, and the pre-GC maximum usage field 402 (= pre-GC maximum usage field) of the retrieved record. 502) and the post-GC maximum use amount field 403 (= the post-GC maximum use amount field 503).
The RS is a maximum value of the memory capacity that can be used as the user memory area 111, and is acquired through, for example, the Java API 120. The upper limit of the memory capacity of the user memory area 111 can be set by Java. For example, 0.5 GB of 4 GB memory available on the OS (Operating System) is set as the upper limit. At that time, the object 112 can be arranged in the user memory area 111 within a range in which the total data amount of the object 112 is within 0.5 GB. On the other hand, when the available memory capacity on the OS and the available memory capacity of the user memory area 111 are the same, the available memory capacity on the OS acquired through the OS system call is used as the user memory area 111. The available memory capacity may be used.
The RSC is the current free memory of the RS, and is acquired via the Java API 120.

  FIG. 7 is an explanatory diagram showing the flow of messages between components in the manual setting mode.

In m1, the request reception unit 102 receives a new request from the terminal 10.
In m2, the request reception unit 102 requests the request ID numbering unit 103 to generate a request ID that uniquely identifies the new request received in m1. The request ID numbering unit 103 generates an ID for uniquely identifying and returns the generated value to the request receiving unit 102.
At m3, the request receiving unit 102 notifies the request control unit 104 of the request ID and the request URL for the new request received at m1.

At m4, the request control unit 104 notifies the memory usage control unit 108 of the URL of the request received at m3.
In m5, the memory usage control unit 108 refers to the executing request management table 116 and acquires a list of currently executed requests as a list of request IDs. For example, in FIG. 2, request IDs “1”, “2”, “3”, and “4” and respective URLs are acquired.
In m6, the memory usage control unit 108 notifies the object management unit 115 of the request ID acquired in m5.

  In m7, the object management unit 115 refers to the object management table 114 and acquires a list of objects created by the request ID for each request ID received in m6. Then, the object management unit 115 calculates the total memory usage of all objects acquired for each request ID, and returns the total to the memory usage control unit 108. The memory usage control unit 108 calculates the DRC by summing up the memory usages of all requests currently being executed (memory usages returned from the object management unit 115).

  For example, when the object management unit 115 receives the request ID “1”, the object management unit 115 acquires the record 311 and the record 312 in which the value of the request ID field 302 of the object management table 114 is “1”, and records each record. The sum of the object sizes 303 (9034 + 883 = 9917 (bytes)) is returned to the memory usage control unit 108 as the DRC component of the request ID “1”. Similarly, the object management unit 115 obtains the DRC component “129 (bytes)” of the request ID “2” and the DRC component “2009 (bytes)” of the request ID “4”, and sends it to the memory usage control unit 108. return. The memory usage control unit 108 calculates the sum of these DRC components (9917 + 129 + 2009 = 12055 (bytes)) as DRC.

  At m8, the memory usage control unit 108 refers to the pre-GC maximum usage field 502 or the post-GC maximum usage field 503 of the maximum size information file 122 for the currently executed request acquired at m5. Thus, the referred maximum usage amount is acquired as a DRM. Thereby, DRI = DRM-DRC can be calculated.

For example, a record 511 in the URL field 501 that matches the URL field 202 “/example/index.jsp” of the currently executed request “1” is obtained, and the maximum pre-GC usage 502 “20034 (byte)” of the record 511 is obtained. And the maximum post-GC usage 503 “10028 (byte)” are acquired as the DRM component of the request “1”.
Similarly, by searching the URL field 501 from the URL field 202 for the other requests “2, 3, 4”, the corresponding maximum pre-GC usage 502 and post-GC maximum usage 503 are obtained for each request. Acquired as a DRM component.

Furthermore, the DRM is calculated by the sum of the DRM components of each request.
The DRM before GC is: DRM component (20034) of request “1” + DRM component (8099012) of request “2” + DRM component (20034) of request “3” + DRM component (4098) of request “4” = 8143178 (bytes).
The DRM after GC is: DRM component (10028) of request “1” + DRM component (51582) of request “2” + DRM component (10028) of request “3” + DRM component (3100) of request “4” = It is 74738 (byte).

  Further, the memory usage control unit 108 refers to the pre-GC maximum usage field 502 or the post-GC maximum usage field 503 of the maximum size information file 122 based on the URL of the new request notified in m4. As a result, the referred maximum usage is acquired as a DNM.

In m9, the memory usage control unit 108 uses the Java API 120 to acquire the current free memory amount as RSC. Then, the memory usage control unit 108 determines whether a new request can be executed based on the discriminant “(DRI) + (DNM) <(RSC)” shown in the description of FIG. In the first determination process of this discriminant, the pre-GC maximum usage field 502 is used as the DNM of the discriminant.
When determining that the request can be executed, the memory usage control unit 108 notifies the request control unit 104 to execute the request.

On the other hand, if the memory usage control unit 108 determines that the request can be executed, the memory usage control unit 108 performs the second determination process of the discriminant by increasing the RSC by the GC process.
In m10a, the memory usage control unit 108 requests the Java API 120 to issue a GC in order to increase the free memory.
In m10b, the memory usage control unit 108 acquires the DRC updated after the GC issuance from the object management table 114 via the object management unit 115. Thereby, DRI = DRM-DRC is updated.
In m10c, the memory usage control unit 108 uses the Java API 120 to acquire the RSC updated after the GC issuance.
Then, the memory usage control unit 108 determines whether a new request can be executed based on the discriminant “(DRI) + (DNM) <(RSC)”. In the second determination process of this discriminant, the post-GC maximum use amount field 503 is used as the discriminant DNM, and the DRI updated in m10a and the RSC updated in m10c are used.
When determining that the request can be executed, the memory usage control unit 108 notifies the request control unit 104 to execute the request. When the second determination process is not satisfied, the request control unit 104 returns a notification that the request cannot be executed from the memory usage control unit 108, and notifies the terminal 10 of an error due to lack of resources via the request reception unit 102. To do.

When either the first determination process or the second determination process is satisfied at m11, the request control unit 104 notifies the request ID and request URL of the new request to the program processing unit 105, and transfers control to the container processing unit 106. .
In m12, the container processing unit 106 stores the request ID and request URL received in m11 in the executing request management table 116. For example, in m1, if the request URL received by the request receiving unit 102 is “/example/index.jsp” and the request ID generated in m2 is “1”, the request is stored as a record 211 in FIG. Then, the container processing unit 106 transfers control to the user processing unit 107.

In m13, when generating the object, the user processing unit 107 notifies the object management unit 115 of the request ID of the new request and the creation request of the object used by the request.
In m14, the object management unit 115 assigns a unique object ID in the object ID numbering unit 119 for the object of the creation request received in m13.
In m15, the object management unit 115 creates the object 112 in the user memory area 111.
At m16, the object management unit 115 associates the memory usage of the object ID of m15 with the request ID of m13 and stores them in the object management table 114. For example, the object management unit 115 associates the request ID “1” of m13, the object ID “2” of m15, and the memory usage “883 (bytes)” of the object ID “2” as a record 312. Store.
In m17, the object management unit 115 returns a reference to the created object 112 to the user processing unit 107, and the user processing unit 107 uses the object 112.

  In m18, when the processing of the request by the user processing unit 107 is completed, the container processing unit 106 deletes information on the completed request from the executing request management table 116. For example, the record 211 of FIG. 2 whose request ID registered at m12 is “1” is deleted. Then, the container processing unit 106 returns a response to the terminal 10 via the request receiving unit 102.

Furthermore, by the process shown below, the object used by the completed request is released by the GC process, thereby making it easy to accept a new request.
In m19, the object management unit 115 receives an object release request from the GC processing unit 121.
At m20, the object management unit 115 releases (deletes) the object 112 from the user memory area 111.
In m21, the object management unit 115 deletes the information of the object 112 of m20 from the object management table 114.

  FIG. 8 is an explanatory diagram showing a message flow between components in the test mode.

In n1, the request reception unit 102 receives a request from the terminal 10.
At n2, the request receiving unit 102 causes the request ID numbering unit 103 to generate a request ID that uniquely identifies the request received at n1.
In n3, the request reception unit 102 calls the container processing unit 106 using the request ID and URL of the request received in n1 as arguments. Here, since the request received at n1 is a request for actual measurement (benchmark) in the test mode, it is surely executed. That is, the request execution determination based on the discriminant as executed by the memory usage control unit 108 in FIG. 7 is omitted.

In n4, the container processing unit 106 stores the request ID and URL received in n3 in the executing request management table 116, and calls the user processing unit 107.
Hereinafter, each process of n5-n10 of FIG. 8 is the same as each process of m13-m18 of FIG. For example, the process of n5 is the same as the process of m13.

Hereinafter, the update process of the maximum size management table 118 (the pre-GC maximum usage field 402) in the test mode will be described.
In n11, the GC processing unit 121 requests the maximum memory usage calculation unit 117 to acquire the current memory usage.
In n12, the maximum memory usage calculation unit 117 refers to the in-execution request management table 116 and acquires a list of requests being executed (for example, record 211, record 212, record 213, and record 214).
In n13, the maximum memory usage calculation unit 117 notifies the object management unit 115 of the request ID for all acquired requests, and acquires the memory usage used by each request.
In n14, the maximum memory usage calculation unit 117 refers to the maximum size management table 118, acquires the information in the maximum pre-GC usage field 402, and the acquired value (20034bytes in the request ID “1”) is the current value. If the memory usage of the request is smaller than 9034 + 883 = 9917 bytes for the request ID “1”, the value in the pre-GC maximum usage field 402 is updated with the memory usage of the current request (request ID “1”). "Does not update.)

Hereinafter, the update process of the maximum size management table 118 (the maximum use amount field after GC field 403) after the GC process in the test mode will be described.
In n15, the GC processing unit 121 requests the object management unit 115 to delete the unnecessary object 112 as in the existing GC processing.
In n16, the object management unit 115 deletes the object 112 requested in n15 from the user memory area 111. For example, when deleting an object whose object ID is “2”, the record 312 in FIG. 3 is deleted.
In n17, the information of the object 112 deleted in n16 is deleted from the object management table 114, and the control is returned to the GC processing unit 121. And since the GC process part 121 released the unnecessary object by GC process (n15-n17), the acquisition process (n11-n13) of maximum memory usage is performed again.
Then, the maximum memory usage calculation unit 117 refers to the maximum size management table 118, acquires the information in the post-GC maximum usage field 403, and stores the memory usage (request ID “1”) in the post-GC maximum usage field 403. In this case, if 10028 bytes) is smaller than the memory usage (9034 + 883 = 9917 bytes for request ID “1”) acquired by the acquisition processing (n11 to n13) of the maximum memory usage, the post-GC maximum usage field 403 Is updated with the memory usage acquired by the maximum memory usage acquisition processing (n11 to n13) (the request ID “1” is not updated).

A process for exporting the updated maximum size management table 118 as the maximum size information file 122 is described below.
In n18, when the command reception unit 109 receives a file output command from the administrator, the command reception unit 109 requests the command execution unit 110 to perform file output processing.
In n19, the command execution unit 110 refers to the maximum size management table 118, and acquires information on URLs, pre-GC maximum usage, and post-GC maximum usage of all requests.
In n20, the command execution unit 110 outputs the result of the format conversion (CSV conversion) of the data content acquired in n19 as the maximum size information file 122.

  FIG. 9 is a flowchart showing an outline of request processing in the manual setting mode.

In step S <b> 1001, the request reception unit 102 receives a request from the terminal 10.
In S1002, the request ID numbering unit 103 assigns a unique request ID for each request, and notifies the request control unit 104 of the request URL and the request ID.
In step S <b> 1003, the request control unit 104 receives the request ID and the request URL from the request reception unit 102 and notifies the memory usage control unit 108 of the request URL to determine whether the request can be executed. Transfer.
In S1004, the memory usage control unit 108 performs a new request execution feasibility determination process (details are shown in FIG. 10) as the memory usage control process.
In S1005, the request control unit 104 receives the determination result of S1004 from the memory usage control unit 108. If the determination result is executable (S1005, Yes), the process proceeds to S1006, and if the request is not executable (No in S1005). ) Go to S1009.

In step S <b> 1006, the container processing unit 106 receives the request ID and the character string of the request URL from the request control unit 104 and stores the information in the in-execution request management table 116.
In step S1007, the container processing unit 106 instructs the user processing unit 107 to execute the request received in step S1001 (details are shown in FIG. 13).
In step S <b> 1008, the container processing unit 106 deletes the information on the request executed in step S <b> 1007 from the in-execution request management table 116 after completing the processing in step S <b> 1007. As a result, only the information of the currently executing request is stored in the executing request management table 116.
In step S <b> 1009, the request reception unit 102 returns a response (response) to the request in step S <b> 1001 to the terminal 10. This response is a notification of normal execution of the request received from the container processing unit 106 when branched to Yes in S1005, and an error when branched to No in S1005.

  FIG. 10 is a flowchart that shows details of the memory usage control process that is called from S1004. In the following description, the main operation of each process in FIG. 10 is the memory usage control unit 108.

In step S <b> 1101, the URL information of the request to be executed is received from the request control unit 104.
In step S1102, the in-execution request management table 116 is referred to, and a list of in-execution request IDs is acquired.
In S1103, in order to calculate the current memory usage (DRC) of all the requests being executed, the process of FIG. 11 is called with the list of request IDs being executed as an argument.
In S1104, the maximum size information file 122 is referred to, and the pre-GC maximum usage and post-GC maximum usage corresponding to the URL information of the request being executed calculated in S1103 are acquired as DRM, and the URL of the request received in S1101 The maximum usage amount before GC and the maximum usage amount after GC corresponding to the information are acquired as DNM.
As S1105, the Java API 120 is executed to acquire the current free memory amount (RSC).

  In S1106, it is determined whether or not the first discriminant “(DRI) + (DNM) <(RSC)” is satisfied. The DRI on the left side of the discriminant is the result of subtracting the DRC acquired in S1103 from the maximum pre-GC usage as the DRM acquired in S1104. Further, as the DNM on the left side of the discriminant, the pre-GC maximum use amount as the DNM acquired in S1104 is used. When this discriminant is satisfied, the process proceeds to S1111. When the discriminant is not satisfied, the process proceeds to S1107.

In S1107, in order to increase the free memory, the Java API 120 is requested to execute Full GC.
As S1108, after the Full GC is executed, the processing of S1103 is executed again.
As S1109, the process of S1105 is executed again.
In S1110, it is determined whether or not the second discriminant “(DRI) + (DNM) <(RSC)” is satisfied. The DRI on the left side of the discriminant is a result of subtracting the DRC acquired in S1108 from the maximum usage amount after GC as the DRM acquired in S1104. Further, as the DNM on the left side of the discriminant, the post-GC maximum use amount as the DNM acquired in S1104 is used. When this discriminant is satisfied, the process proceeds to S1111. When the discriminant is not satisfied, the process proceeds to S1112.

In S1111, it is determined that the request received in S1101 can be executed, and the determination result is notified to the request control unit 104.
In S1112, it is determined that the request received in S1101 cannot be executed due to a lack of memory, and the determination result is notified to the request control unit 104.

FIG. 11 is a flowchart showing the details of the processing that is called from S1103 and S1108 with the request IDs of all requests being executed as arguments, and that calculates the memory usage of all requests being executed. In the following description, the main operation of each process in FIG. 11 is the memory usage control unit 108.
In step S1201, the memory usage control unit 108 starts a loop for sequentially selecting the request IDs currently being received received as arguments.
In S1202, the process shown in FIG. 12 is called with the selected request ID as an argument, and the memory usage of the request ID is calculated.
As S1203, the loop of S1201 is terminated.
In S1204, the memory usage calculated in S1202 is totaled, and the total value is returned to the caller as the memory usage of all requests being executed.

FIG. 12 is a flowchart showing details of a process that is called from S1202 with the request ID of the request being executed as an argument, and that calculates the memory usage of the request. In the following description, the subject of the operation of each process in FIG. 12 is the object management unit 115.
In step S <b> 1301, an argument request ID is received from the memory usage control unit 108.
In step S1302, the object management table 114 is referred to, and a list of objects corresponding to the request ID in step S1301 is acquired.
In S1303, for all the objects acquired in S1302, the total memory usage of the objects is calculated, and the calculation result is returned to the request source.

FIG. 13 is a flowchart showing details of the request execution process, which is a process called from S1007 with the request ID as an argument. In the following description, the subject of the operation of each process in FIG. 13 is the user processing unit 107 except for S1404.
In S1401, a loop for sequentially executing the processing of the Java program created by the user is started in accordance with the argument request.
In S1402, the program selected in the loop is executed.
In S1403, it is determined whether or not the processing in S1402 is processing for generating an object. If Yes in S1403, the process proceeds to S1404, and if No in S1403, the process proceeds to S1405.
In step S <b> 1404, the user processing unit 107 notifies the object management unit 115 of the request ID and requests creation of the object 112. In response to the request, the object management unit 115 assigns a unique object ID to the object ID numbering unit 119 and generates an object 112 indicated by the object ID. Further, the object management unit 115 associates the numbered object ID, the notified request ID, and the memory usage of the generated object 112 and stores them in the object management table 114.
As S1405, the loop of S1401 is terminated.

  FIG. 14 is a flowchart showing an overview of request processing in the test mode. Compared with the process in the manual setting mode of FIG. 9, the process (S1003 to S1005) related to the memory usage control unit 108 becomes unnecessary.

FIG. 15 is a flowchart showing the GC processing executed by the GC processing unit 121. The trigger for executing this GC process is, for example, when Java detects a memory shortage state.
In S2001, an object that is no longer needed is determined as an object to be released.
In S2002, the update process (FIG. 16) of the maximum pre-GC usage in the maximum size management table 118 is called.
In S2003, as the GC process, the release process of the object 112 that is the release target in S2001 is performed. Along with this release processing, the information of the released object 112 is deleted from the object management table 114.
In S2004, an update process (FIG. 17) of the maximum use amount after GC in the maximum size management table 118 is called.

FIG. 16 is a flowchart showing details of the pre-GC maximum use amount update process called from S2002. In the following description, the subject of the operation of each process in FIG. 16 is the maximum memory usage calculation unit 117.
In S2101, the in-execution request management table 116 is referred to, and a list of requests in execution is acquired.
In S2102, a loop for selecting the executing requests acquired in S2101 one by one is started.
In S1202, the current memory usage acquisition process described in FIG. 12 is called.
In S2103, it is determined whether the URL of the request being executed selected in S2102 has already been registered in the maximum size management table 118. If YES in step S2103, the process advances to step S2104. If NO in step S2103, the process advances to step S2105.
In S2104, the value of the pre-GC maximum usage field 402 is acquired from the maximum size management table 118, and it is determined whether or not the acquired value is smaller than the memory usage calculated in S1202. If Yes in S2104, the process proceeds to S2105, and if No in S2104, the process proceeds to S2106.
In S2105, the memory usage calculated in S1202 is registered (overwritten update) in the pre-GC maximum usage field 402 of the maximum size management table 118.
As S2106, the loop from S2102 is terminated.

FIG. 17 is a flowchart showing details of the update processing for the maximum usage amount after GC called from S2004. In the following description, the subject of the operation of each process in FIG. 17 is the maximum memory usage calculation unit 117. The process in FIG. 17 is similar to the process in FIG. 16, but the processes in S2103 to S2105 in FIG. 16 are replaced with the processes in S2201 to S2202 in FIG.
In S2201, it is determined whether or not the value in the post-GC maximum usage field 403 stored in the maximum size management table 118 is smaller than the memory usage calculated in S1202. If Yes in S2201, the process proceeds to S2202, and if No in S2201, the process proceeds to S2106.
In S2202, the memory usage calculated in S1202 is registered (overwritten update) in the post-GC maximum usage field 403 of the maximum size management table 118.

In the present embodiment described above, the memory usage control unit 108 executes a new request using the increased memory usage (DRI) of the currently executing request in the discriminant shown in FIG. By determining the availability, a subsequent memory shortage as shown in FIG. 6B can be prevented.
Furthermore, by measuring DRI as an actual measurement value in the test mode, the determination accuracy in the discriminant can be improved as compared with the manual setting mode.

10 terminal 20 network 30 computer 40 communication device 50 CPU
Reference Signs List 60 input device 70 output device 80 auxiliary storage device 90 bus 95 main storage device 101 container management area 102 request reception unit 103 request ID numbering unit 104 request control unit 105 program processing unit 106 container processing unit 107 user processing unit 108 memory usage Control unit 109 Command reception unit 110 Command execution unit 111 User memory area 112 Object 113 Java VM management area 114 Object management table 115 Object management unit 116 In-execution request management table 117 Maximum memory usage calculation unit 118 Maximum size management table 119 Object ID collection Part 120 Java API
121 GC processing unit 122 Maximum size information file

Claims (6)

A request processing method by a request processing device that executes a received request,
The request processing device is a Java application server that operates a Java (registered trademark) VM (Virtual Machine).
The request processing apparatus includes a storage unit that stores a user memory area and a JavaVM management area in a storage unit, and a memory usage control unit.
The user memory area stores an object embodying a program for executing a request,
In the JavaVM management area, the object ID of the object stored in the user memory area, the amount of memory used by the object, and the request ID of the request that created the object are associated with each other for object management. Is stored as data, and the maximum memory amount used to execute the request for each request ID is stored in association with the maximum size management data,
When the memory usage control unit determines whether to execute a newly received request,
With reference to the maximum size management data, the maximum memory amount of the currently executing request is acquired as the first memory amount,
By referring to the object management data, the memory amount currently used by the object corresponding to the request ID of the currently executing request is acquired as the second memory amount, and the first memory amount is obtained from the second memory amount. Calculate the subtracted value as the third memory amount,
With reference to the maximum size management data, the maximum memory amount of the newly accepted request is acquired as the fourth memory amount,
The current free space in the user memory area is acquired from the JavaVM, and when the acquired current free space is larger than the sum of the third memory amount and the fourth memory amount, the newly accepted request A request processing method characterized in that execution of the request is permitted and execution of the request is instructed. When it is determined that execution of the newly accepted request is not permitted, the memory usage control unit causes the Java VM to execute GC (Garbage Collection) to increase the current free space, and then again. It is determined whether or not the current free space is larger than the sum of the third memory amount and the fourth memory amount. If it is determined that the current free space is larger, the execution of the newly accepted request is permitted. The request processing method according to claim 1, wherein execution of the request is instructed. The request processing device refers to the object management data, acquires the second memory amount corresponding to the request ID, totals the maximum value of the second memory amount for each request ID, and calculates the total result. The request processing method according to claim 1 or 2, wherein the first memory amount is stored in the maximum size management data. The request processing device stores a list of currently executing requests in the storage unit, adds the request to the list when the newly accepted request is allowed to be executed, and completes the execution of the request, The request processing method according to any one of claims 1 to 3, wherein the request is deleted from the list.   A request processing program for causing the request processing apparatus, which is a computer, to execute the request processing method according to any one of claims 1 to 4. A request processing device that executes a received request,
The request processing device is a Java application server that operates a Java (registered trademark) VM (Virtual Machine).
The request processing apparatus includes a storage unit that stores a user memory area and a JavaVM management area in a storage unit, and a memory usage control unit.
The user memory area stores an object embodying a program for executing a request,
In the JavaVM management area, the object ID of the object stored in the user memory area, the amount of memory used by the object, and the request ID of the request that created the object are associated with each other for object management. Is stored as data, and the maximum memory amount used to execute the request for each request ID is stored in association with the maximum size management data,
When the memory usage control unit determines whether to execute a newly received request,
With reference to the maximum size management data, the maximum memory amount of the currently executing request is acquired as the first memory amount,
By referring to the object management data, the memory amount currently used by the object corresponding to the request ID of the currently executing request is acquired as the second memory amount, and the first memory amount is obtained from the second memory amount. Calculate the subtracted value as the third memory amount,
With reference to the maximum size management data, the maximum memory amount of the newly accepted request is acquired as the fourth memory amount,
The current free space in the user memory area is acquired from the JavaVM, and when the acquired current free space is larger than the sum of the third memory amount and the fourth memory amount, the newly accepted request A request processing device characterized in that execution of the request is permitted and execution of the request is instructed.

Images