JP2002351852A - System operation management method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To make it possible to forecast system load change in detail and take measures. SOLUTION: This method is constituted with a transaction function DB, a transaction ID function acquisition part to acquire a transaction ID attached to a new transaction, load history, a forecast DB, a function search part to search a load value for each of the functions, a load calculation part to calculate the load value for each of the new transactions and a judgement making part to judge whether or not to execute the new transaction, and, before the new transaction is executed, the load value for each of the functions is acquired from the transaction function DB, the system load change is forecasted and whether or not to execute the new transaction is judged.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to system operation management and transaction processing.

[0002]

2. Description of the Related Art FIG.
BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a system configuration diagram of a conventional "transaction distribution method and system and recording medium for transaction distribution processing" disclosed in Japanese Unexamined Patent Application Publication No. 60-260. As shown in the drawing, the server devices 1 and 2 and the proxy server device 3 and the client device 4 are roughly composed of network devices.

Next, the operation will be described. When making a transaction request, the client device 4 determines the maximum response time of the server devices 1 and 2 from the statistics of the response times of past transaction requests, and executes a transaction process according to the maximum response time. Is determined. If the maximum response time is exceeded contrary to the determination, the transaction processing can be switched to another server.

[0004]

Since the conventional transaction distribution method is configured as described above, whether or not a transaction can be executed is determined only by the response time. If there are heavy processes that are present and overlap at the same time, the response waiting time may be longer than expected. In this case, there is a problem that the delay of the response time cannot be predicted even though the load is predicted.

The present invention has been made to solve the above problems, and has as its object to predict a change in system load in detail and take measures.

[0006]

A system operation management system according to the present invention comprises a transaction function DB for storing a load value for each transaction function, and a transaction ID assigned to a new transaction.
, A transaction ID acquisition unit for acquiring a system load history and a load history for recording a future load estimate, and a forecast D
B, a function retrieval unit that retrieves a load value for each function from the transaction function DB using the transaction ID as a key, a load calculation unit that computes a load value for each transaction function for a new transaction, and executes a new transaction. A transaction execution availability determination unit for determining whether or not a new transaction can be executed by acquiring a load value for each function from the transaction function DB before executing a new transaction, predicting a change in system load, and determining whether the new transaction can be executed. It is.

A load value for each function of a transaction input to the transaction function DB can be determined at design time based on a primitive processing unit obtained by subdividing the function.

A function design document describing the detailed processing contents of the function, a function decomposing unit that decodes the contents of the function design document and extracts a primitive process, and accumulates a system load and a processing time of the primitive process. The primitive processing DB and the system load and processing time of the primitive processing extracted by the function decomposition unit are retrieved from the primitive processing DB and calculated as the load value for each function, and the load value for each function is input to the transaction function DB. A calculation unit to
It is provided with.

In addition, the calculation unit adopts one maximum value of the primitive processing for each function unit, and the processing time sums up each primitive processing for each function unit. Is to be entered.

After the start of operation, the difference between the actual system load and the expected load is periodically investigated, and if there is a difference, the load value is reviewed.

Also, a system load measuring unit for measuring a system load, a difference detecting unit for calculating a difference between a load history and a predicted load value stored in a prediction DB and an actual system load, and a difference detecting unit for the difference A function-based load value recalculation unit for recalculating the load value input to the transaction function DB based on the difference information output from the transaction function DB, and a transaction function DB based on the result of the function-based load value recalculation unit.
And a load value reflection unit that reflects the load history and the prediction DB.

Further, a plurality of transaction function DBs are provided, and a more detailed determination of transaction execution is made by combining some system loads.

Further, as a result of predicting a change in system load,
When the overload is determined, the transaction scheduling is changed to avoid the overload.

Further, as a result of predicting a change in system load,
When an overload is determined, the scheduling is changed so as to lower the priority of the transaction at a time when the system is overloaded, thereby avoiding the overload.

Further, as a result of predicting a change in system load,
When the overload is determined, the degree of delay of the transaction is predicted and notified to the executor of the transaction.

Further, as a result of predicting a change in system load,
If the execution of another transaction after this transaction is expected to be overloaded, a warning is issued before the execution of the transaction.

Further, as a result of predicting a change in system load,
When the overload is determined, a delay warning is issued before the execution of the transaction, and the determination as to whether or not the transaction can be performed is left to the user.

Further, as a result of predicting a change in system load,
When overload is determined, only a privileged user can execute a transaction.

[0019]

Embodiments of the present invention will be described below with reference to the drawings. Embodiment 1 FIG. 1 to 6 show the first embodiment, FIG. 1 is an overall configuration diagram of the system, FIG.
Showing the expected and actual system load and the actual execution time and actual results for each function, FIG. 3 shows the ID and the load value for each function stored in the transaction function DB, and FIG. FIG. 5 is a system load estimation diagram showing the result of load estimation calculated by the load calculation unit, and FIG. 6 is a message notified to an execution user before executing a new transaction. FIG.

In FIG. 1, reference numeral 11 denotes a transaction ID acquisition unit for extracting a transaction ID from a transaction to be executed, and reference numeral 12 denotes a load for each function in the transaction from a transaction function DB 15 based on the transaction ID from the transaction ID acquisition unit 11. A function retrieval unit 13 for retrieving a value includes a load value for each function from the function retrieval unit 12, a load history, and an expected D.
A load calculation unit that calculates a system load value when this transaction is input based on the data in B16, and a transaction execution determination unit 14 that determines whether the transaction can be executed based on the expected system load data from the load calculation unit 13. And 15, a transaction function DB for storing a list of functions for each transaction, load values of the functions, and required time, and 16 a load history and prediction for recording a predicted transaction execution of the system, a predicted load of the system, and an actual system load. DB.

In FIG. 2, reference numeral 21 denotes a table for storing a predicted system load and a result, and reference numerals 22 and 23 denote tables for storing a predicted execution time and a result for each transaction function.

In FIG. 3, reference numerals 31 and 32 denote execution order tables indicating the execution order of transaction functions, reference numeral 34 denotes a function-specific table for storing load values and execution times for respective functions, and reference numeral 33 denotes
Is the function of the execution order tables 31 and 32 and the function-specific table 3
4 is a relation line for associating the four functions.

In FIG. 5, reference numeral 51 denotes a transaction A
And a system load estimate (A + B) obtained by adding the load changes of the transaction B and 52, a system load estimate (A + B + C) obtained by adding the load changes when the new transaction C is executed, 53 a load value of the transaction A,
54 is the load value of transaction B, and 55 is the load value of transaction C.

Next, the operation will be described. The transaction is a unit in which a series of functions such as document ID numbering, registration information arrangement, and DB registration for document creation are put together. Such a transaction is provided with an ID for identifying the type of the transaction. Here, this is called a transaction ID.

First, before executing a transaction, the transaction ID obtaining unit 11 extracts a transaction ID from the transaction. Transaction I
The function search unit 12 that has received the D searches the transaction function DB 15 and extracts the functions executed when the transaction is executed and the system load information of each function.

As shown in FIG. 3, the inside of the transaction function DB 15 uses the transaction ID as a key,
Load information can be extracted for each function. For each value of the load information, the load applied to the system by the function is determined in advance and input. The extracted system load information is stored in the load calculation unit 13 in the form of load history, expected D
The calculation is performed together with the expected system load information stored in B16. The calculated result is shown in FIG.

Now, the transaction A and the transaction B are being executed, and the sum of the respective load values 53 and 54 is represented by the solid line portion 51 of the system load prediction as the load prediction. Here, when the transaction C is newly executed from the time point T1, the system load estimate changes as indicated by a dotted line 52 which is the load estimate value obtained by adding the load value 55 of the transaction C.

The transaction execution availability determination unit 14 searches for a point at which the system load becomes maximum based on the expected system load, and determines whether or not the system becomes a load thereat, so that countermeasures against transaction execution can be taken. For example, as shown in FIG. 6, the execution of the transaction is determined according to the expected load.

As described above, the load is predicted before executing the transaction, and whether the transaction can be executed or not is determined. Therefore, it is possible to prevent the transaction execution from being delayed more than expected.

Further, since the load value for each function is determined and input in advance, a detailed load estimation can be performed from the start of system operation.

Also, since the load is predicted for each function of the transaction, it is possible to know in advance in detail whether the system will be in a high load state, and it is possible to make a judgment at a detailed level whether or not the transaction can be executed. .

Further, since the function search unit retrieves load information before executing a transaction, it is possible to grasp the load state of the transaction in detail.

Further, the load calculation unit performs the calculation together with the load history calculated in advance and the load prediction stored in the prediction DB, so that the load prediction of the system can be grasped in detail.

Embodiment 2 In the above embodiment, the load value for each function in the transaction function DB is in a set state. Next, an embodiment for determining the load value for each function will be described. 7 and 8 are diagrams showing the second embodiment, FIG. 7 is a configuration diagram showing a method of determining a load value, and FIG. 8 shows load values and execution times of primitive processing input to a primitive DB. FIG.

In FIG. 7, reference numeral 71 denotes a function design document that describes detailed processing contents of functions, 72 denotes a function decomposition unit that decodes the contents of the function design document 71 and extracts primitive processing, 7
Reference numeral 3 denotes a calculation unit for retrieving the system load and processing time of the primitive processing and calculating as a load value; 74, a system load of the primitive processing; a primitive processing DB for accumulating the processing time; 75, a load value for each function; Transaction function DB.

Next, the operation will be described. A transaction obtained by decomposing a transaction is referred to as a function. The function is further subdivided based on the function design document 71 and, for example, a primitive process such as a process of writing to a disk or a process of reading from a DB is decomposed. Then, as the processing approaches the primitive processing, it becomes easier to estimate the system load and the required time from the processing contents.

Therefore, as shown in FIG. 8, the system load and the required time for each primitive process are set in the primitive process DB 74, and the function disassembly section 72 analyzes the contents of the function design document 71 to determine the function. The calculation unit 73 employs one of the maximum values of the primitive processing as the system load for each functional unit, and the processing time is the sum of the primitive processing. The result is input to the transaction function DB 75 as a function load value.

As described above, the functions are decomposed into primitive processes so that the load values can be easily determined, and the load values are determined based on the system load of the primitive processes. can do.

Embodiment 3 In the above embodiment, the load value for each function is set in advance, but next, the expected load value is compared with the actual machine load, and the load value for each function is adjusted based on the result. An embodiment will be described. 9 to 12 are diagrams showing a third embodiment, FIG. 9 is a configuration diagram showing a method of adjusting a load value for each function, and FIG. 10 is an actual system load and load history, and a load stored in a prediction DB. FIG. 11 is a diagram in which predictions are superimposed, FIG. 11 is a diagram showing a load value for each function of a single transaction, and FIG. 12 is a diagram showing that a load value of a single transaction input to the transaction function DB is corrected. It is.

In FIG. 9, 11 to 16 are the transaction ID acquisition unit, 12 is the function search unit, 13 is the system load calculation unit, and 14 is the transaction as described in FIG. 1 of the first embodiment. An executable / non-executable determination unit, 15 is a transaction function DB, and 16 is a load history and a prediction DB.

Reference numeral 91 denotes a system load measuring unit for measuring a system load; 92, a load history; a difference detecting unit for calculating a difference between a load predicted value stored in the prediction DB 16 and an actual system load; Based on the difference information output from the difference detection unit 92, the transaction function DB1
5, a function-specific load value recalculation unit 94 for recalculating the load value input to the unit 5; a transaction function DB 15 and a load history;
This is a load value reflection unit that reflects the value on B16.

FIG. 10 is a graph obtained by superimposing the actual system load, the load history, and the load estimate stored in the estimation DB. 101 is the actual system load, 102 is the load estimate, and 103 is the system load and the load. This is a difference from the expectation.

FIG. 11 shows the load value for each function of a single transaction (transaction C). 111 is a graph before load value correction, 112 is a graph after load value correction, and 113 is a difference. is there.

FIG. 12 shows a transaction function DB.
FIG. 9 is a diagram showing that the load value of a single transaction (transaction C) input to the “.” Is modified.

Next, the operation will be described. The system load detector 91 periodically measures the current system load and sends the system load value to the difference detector 92. Difference detection unit 92
Extracts the current system load forecast value from the load history and forecast DB 16 and calculates the difference. Load value recalculation unit 93
Adjusts the load value of the function started or ended immediately before.

If the function has not started or ended immediately before, the load value of each function is adjusted uniformly. The adjusted load value is transferred to the transaction function DB by the load value reflection unit 94.
15 is reflected. For example, assuming that the system load 101 at time T1 in FIG. 10 is “50” and the load forecast 102 is “48”, the difference 103 is “2”. Since this load change has changed immediately after the function b of the transaction C is executed as shown in FIG. 11, the load value of the function b is changed from "10%" to "12%" as shown in FIG. change.

The required time can be modified as follows. The start and end of each function are detected by a time stamp, and the required time of each function is calculated from the time stamp by the required time detecting unit. As a result of the calculation, if there is a difference from the required time set in the transaction function DB, and if there is no overload while executing the function in the system load history DB, it is reflected in the transaction function DB 15.

As described above, since the load value for each function is always adjusted to the optimum value during the operation of the system, the load can be predicted accurately.

Embodiment 4 In the above embodiment, load estimation is performed based on a single system load. Next, a plurality of transaction function DBs are provided, and more detailed load estimation is performed based on a plurality of load values. An embodiment for performing the above will be described.

FIG. 13 shows the fourth embodiment and shows a plurality of system loads in a single transaction. The system load includes, for example, a CPU load, an N / W load, and a disk load. When one transaction is executed, the load changes as shown in FIG. 13, for example. Thus, for example, even when the load on the CPU is high, the load on other systems may be low. Therefore,
If you try to execute a new transaction, CP
The CPU predicts a load for three of the U load, the N / W load, and the Disk load according to the method of the first embodiment, and avoids an overload of the Disk when the Disk load is large.
If the load of is large, avoid overloading the CPU load,
For each system load, control the transaction execution so that it is not overloaded.

As described above, the system can be used efficiently by estimating the load in detail while estimating a change in a plurality of system loads.

Embodiment 5 FIG. In the above embodiment, the execution is suppressed when it is determined that the load is overload as a result of the load estimation. However, in such a case, the overload is avoided by shifting the transaction execution start time. An embodiment will be described. FIG. 14 shows the fifth embodiment, and is a load prediction diagram showing that overload is avoided by shifting the transaction execution start time. In the figure, 141 is the load value of a new transaction, 1
42 is a system load forecast, 143 is a system load forecast when a new transaction is executed, 144 is a new transaction position when an overload is avoided, 145 is a system load forecast when an overload is avoided, 146 is a load threshold.

Next, the operation will be described. Embodiment 1
When there is a transaction that is determined to be overloaded as a result of the load prediction by the method described above, the overload detection unit calculates the time when the overload reaches the maximum value, and sets the time as T1. Then, it is calculated how much the load forecast at that time exceeds the load threshold 146, and the calculated value is set to d1.

Next, when the system load estimate is later than T1, T1
A point where the load is reduced by d1 or more from the load forecast at the time is searched for and set as T2. Next, the execution start position of the new transaction is changed by the difference between T1 and T2, and the load estimate is calculated again here.

If the result is that overloading occurs again, the same method is repeated once. If you can avoid overload,
This point is the execution start position of the new transaction.

As described above, as a result of the load estimation, the transaction start position is changed by paying attention to the point of overload, so that even if it is determined that the overload occurs, the overload can be quickly avoided. it can.

Embodiment 6 FIG. In the above embodiment, when it is determined that the load is overloaded as a result of the load prediction, the execution start is delayed or the execution itself is suppressed.
Next, by scheduling the transaction to be prioritized at a time when the system is overloaded,
An embodiment for avoiding overload will be described.

FIG. 15 is a diagram showing the sixth embodiment, and is a load forecast diagram showing that a schedule for lowering the priority of the transaction is set during a time when the system is overloaded. In the figure, 151 is a load value of a new transaction, 152 is a load forecast of the system, 153 is a load forecast of the system when a new transaction is executed, 1
Numeral 54 denotes the position of a new transaction when the overload is avoided, 155 denotes a system load prediction when the overload is avoided, and 156 denotes a load threshold.

Next, the operation will be described. Embodiment 1
If there is a transaction that is determined to be overloaded as a result of the load prediction by the method described above, the overload detection unit calculates the time exceeding the load threshold 156 and the time exceeding the load threshold 156, and calculates the time Are T1 and T2, respectively. Then, it calculates how much the load estimate at that point exceeds the load threshold 156, and sets the maximum value to d1. Then, in the time period T2 exceeding the load threshold 156, the schedule is changed so as to lower the priority of the transaction to be newly executed, thereby avoiding an overload.

As described above, the overload is detected before the transaction is executed, and in that section, the priority of the newly executed transaction is lowered to prevent unexpected delay of the already executed transaction. Overload can be prevented.

Embodiment 7 FIG. In the above embodiment, when the system is overloaded, the user confirms whether or not to execute the transaction even if it is delayed. An embodiment for estimating time will be described.

The operation will be described. Load prediction is performed when a new transaction is executed, and the required time T1 of the transaction at this time is set as a reference time. As a result of the load prediction, it is determined that the load is overloaded, and the schedule of the transaction is changed by the method of the sixth or seventh embodiment. As a result, in the example of FIG. Suppose. At this time, the time difference T3 between T1 and T2 is set as the transaction delay time, and the execution user of the new transaction is notified and the execution feasibility determination is left to the user.

As described above, before executing a new transaction, if it is determined that the transaction is delayed, the transaction execution user is notified of the scheduled delay time, so that the execution user can easily grasp the state of the transaction. become.

In addition, in the case of a transaction delay, by entrusting the user with the determination of whether or not the transaction can be executed, it is possible to prevent a transaction delay unexpected for the user.

Embodiment 8 FIG. In the above-described embodiment, whether the transaction can be executed is determined when the system is overloaded. Next, when the system load is at a somewhat high level and the new transaction is continuously executed, the system is overloaded. An embodiment will be described in which a warning is issued and the user is alerted when the load becomes a load.

FIGS. 16 and 17 show the eighth embodiment.
FIG. 16 is a configuration diagram of a method for issuing a warning and alerting the user before the system is overloaded, and FIG. 17 is a diagram illustrating an example of notifying the user of the execution delay of a new transaction. In FIG. 16, reference numerals 11 to 16 represent the first embodiment.
As already described with reference to FIG. 1, 11 is a transaction ID acquisition unit, 12 is a function search unit, 13 is a system load calculation unit, 14 is a transaction execution availability determination unit, 15
Is transaction function DB, 16 is load history, expected D
B. Reference numeral 161 denotes an overload detecting unit that detects an overload threshold based on the load history and the history data of the system load in the prediction DB 16.

FIG. 17 is a diagram showing a method of detecting the degree of load change, wherein 171 is a load history, a system load history stored in the prediction DB 16, 172 is a load forecast of the transaction A, and 173 is a load of the transaction B. The prediction 174 is the load prediction of the transaction C, and 175 is the point where the system load was the highest within the time T1.

Next, the operation will be described. The overload detection unit 161 detects the degree of load change when the largest load change occurs due to transaction execution from the load history and the load history stored in the prediction DB 16. The degree of load change is compared with the maximum load value of the new transaction, and the larger value is added to the load prediction performed before executing the new transaction. As a result, when it is determined that the transaction is overloaded, a warning is issued to the executing user to notify that the execution of the new transaction from the next time onward may be suppressed.

A method of detecting the degree of load change will be described with reference to FIG. Assuming that the new transaction is transaction C, the expected load of transaction C 17
4, while the function b with the highest load is being executed (time T
1) The point 215 (time T2) having the highest system load history is detected. The function being performed at this point is
Since the transaction A is the function j, the transaction B is the function f, and the transaction C is the function b, a value obtained by proportionally distributing the system load history to the expected load of each function is defined as the load change degree. For example, the system load history at the time T2 is 33%, the function j is 5%, the function f is 7%, and the function b is
Is assumed to be 10%, the function b is 33 / (5 + 7 + 10) × 10 = 15 when the load prediction is proportionally distributed. This 15
% Is the load change degree of transaction C.

As described above, before executing a new transaction, it is possible to predict a future increase in the load and to issue a warning of the transaction execution, so that the user can execute the transaction execution in advance.

Embodiment 9 FIG. In the above embodiment, when it is determined that the load is overloaded as a result of performing load prediction before executing a new transaction, the scheduling of the transaction is changed to grasp the degree of delay.
Next, an embodiment will be described in which, when a transaction delay is found, a user is notified of the degree of delay before executing a new transaction. FIG. 18 shows a ninth embodiment.
FIG. 7 is a diagram illustrating an example in which a user is notified of a delay in execution of a new transaction.

Next, the operation will be described. As a result of performing load estimation before executing a new transaction, it is determined that it is overloaded and the transaction scheduling is changed.
The method of detecting the degree of delay is as described in the eighth embodiment. At this time, the generated degree of delay is notified to the transaction execution user in a sentence, for example, as shown in FIG. 18, and the user is urged to judge whether or not execution is possible.

As described above, before executing a new transaction, the user is notified of the degree of delay in executing the transaction, and the user can determine whether or not the transaction can be executed. Therefore, the user can change the schedule of the transaction in advance. .

Embodiment 10 FIG. In the above embodiment,
When the system is overloaded, it is determined whether or not to execute a transaction. In such a situation, an embodiment in which a transaction of a privileged user is preferentially executed will be described. 19 and 20 show the tenth embodiment. FIG. 19 is a configuration diagram of a method for preferentially executing a transaction of a privileged user. FIG. 20 is a diagram showing user information stored in a user authority DB and the presence or absence of a privilege. FIG.

As shown in FIG. 1 of the first embodiment, reference numerals 11 to 16 denote a transaction ID acquisition unit, reference numeral 12 denotes a function search unit, reference numeral 13 denotes a system load calculation unit, and reference numeral 14 denotes a transaction execution. Availability judgment unit,
Reference numeral 15 denotes a transaction function DB, and reference numeral 16 denotes a load history and a prediction DB. An execution user detection unit 191 detects an execution user of a transaction to be executed,
192 is a user authority D that accumulates the execution authority of the execution user
B and 193 are user authority determination units that determine whether the user of this transaction has a privilege based on the data in the user authority DB.

Next, the operation will be described. Embodiment 1
As a result, when the system load is estimated before the execution of the new transaction and the overload is determined, the executing user detecting unit 191 detects the executing user of the new transaction. Then, the user authority determination unit 193 checks the authority of the user executing the new transaction based on the data in the user authority DB 192. If this user is a privileged user, execution of the transaction is started. If not, a message is output and the execution of the transaction is suppressed.

For example, when the user "igarashi" attempts to execute a new transaction and estimates that the system load is over, the user "igarashi" is judged to be overloaded, and from the table in FIG. 20, it is determined that the user "igarashi" is not a privileged user. "Igarashi" is notified of the non-execution, and the execution of the transaction is suppressed.

As described above, when it is determined that the system is overloaded, it is determined whether the transaction can be executed based on the authority of the transaction execution user. Therefore, important transactions can be executed with priority, and the system can be operated efficiently. it can.

[0079]

According to the present invention, the load is predicted before executing the transaction, and whether the transaction can be executed or not is determined. Therefore, it is possible to prevent the transaction execution from being delayed more than expected. .

[Brief description of the drawings]

FIG. 1 is a diagram illustrating a first embodiment, and is an overall configuration diagram of a system.

FIG. 2 is a diagram showing the first embodiment, and shows a load history and an expected D;
FIG. 9 is a diagram showing a system load estimate and result stored in B, and an execution time estimate and result for each function.

FIG. 3 is a diagram illustrating the first embodiment and is a diagram illustrating an ID stored in a transaction function DB and a load value for each function;

FIG. 4 is a diagram showing the first embodiment, and is a load prediction diagram of a single transaction retrieved by a transaction ID from a transaction function DB;

FIG. 5 is a diagram illustrating the first embodiment, and is a load prediction diagram of the system showing a result of calculating a load prediction by a load calculation unit.

FIG. 6 is a diagram illustrating the first embodiment and is a diagram illustrating a message notified to an executing user before executing a new transaction.

FIG. 7 shows the second embodiment and is a configuration diagram showing a method for determining a load value.

FIG. 8 is a diagram showing the second embodiment, in which a primitive DB is used.
FIG. 5 is a diagram illustrating load values and execution times of primitive processes input to the LM.

FIG. 9 is a diagram illustrating a third embodiment, and is a configuration diagram illustrating a method of adjusting a load value for each function.

FIG. 10 shows the third embodiment, and is a diagram in which an actual system load, a load history, and a load prediction stored in a prediction DB are superimposed.

FIG. 11 is a diagram illustrating the third embodiment, and is a diagram illustrating a load value for each function of a single transaction.

FIG. 12 shows the third embodiment and is a diagram showing that the load value of a single transaction input to the transaction function DB has been corrected.

FIG. 13 is a diagram illustrating a fourth embodiment, and illustrates a plurality of system loads in a single transaction.

FIG. 14 is a diagram showing the fifth embodiment, and is a load prediction diagram showing that overload is avoided by shifting the execution start time of a transaction.

FIG. 15 is a diagram showing the sixth embodiment, and is a load prediction diagram showing that a schedule for lowering the priority of the transaction is set during a time when the system is overloaded.

FIG. 16 is a diagram illustrating an eighth embodiment, and is a configuration diagram of a method for issuing a warning and calling a user's attention before the system is overloaded.

FIG. 17 is a diagram illustrating an eighth embodiment, and is a diagram illustrating an example of notifying a user of an execution delay of a new transaction.

FIG. 18 illustrates the ninth embodiment, and illustrates an example of notifying a user of an execution delay of a new transaction;

FIG. 19 shows the tenth embodiment, and is a configuration diagram of a method for preferentially executing a transaction of a privileged user.

FIG. 20 shows the tenth embodiment, in which a user authority D
FIG. 6 is a diagram showing user information stored in B and the presence or absence of a privilege.

FIG. 21 is a system configuration diagram of a conventional transaction distribution method.

[Explanation of symbols]

11 transaction ID acquisition section, 12 function search section, 13 load calculation section, 14 transaction execution availability determination section, 15 transaction function DB, 16 load history, forecast DB, 21 table for storing system load forecast and results, 22, 23 transactions Table storing execution time forecasts and results for each function, 31, 32 execution order table, 34 function table, 33 related line, 51 system load forecast (A +
B), 52 System load forecast (A + B + C), 53
Load value of transaction A, 54 Load value of transaction B, 55 Load value of transaction C, 71
Function design document, 72 Function decomposition unit, 73 Calculation unit, 74
Primitive processing DB, 75 transaction function DB, 91 system load measuring unit, 92 difference detecting unit,
93 load value recalculation unit, 94 load value reflection unit, 101 system load, 102 load forecast, 103 difference between system load and load forecast, 111 graph before load value correction,
112 graph after load value correction, 113 difference, 141
Load value of new transaction, 142 System load forecast, 143 System load forecast when a new transaction is executed, 144 New transaction position when overload is avoided, 145 System load when overload is avoided Expected, 146 load threshold, 151 new transaction load, 15
2 System load forecast, 153 System load forecast when a new transaction is executed, 154 New transaction position when overload is avoided, 155 System load forecast when overload is avoided, 156 Load threshold , 161 overload detector, 17
1 System load history, 172 Transaction A load forecast, 173 Transaction B load forecast, 17
4 Load prediction of transaction C, 175 The point where the system load was the highest in T1 time, 191 execution user detection unit, 192 user authority DB, 193 user authority determination unit.

Claims (13)

[Claims] 1. A transaction function DB (DataBase) for storing a load value for each transaction function.
A transaction ID acquisition unit for acquiring a transaction ID (IDentification) assigned to a new transaction; a load history for recording a system load history and a future load estimate; a forecast DB; and a transaction function D using the transaction ID as a key.
A function search unit for searching for a load value for each function from B; a load calculation unit for calculating a load value for each transaction function for a new transaction; and a transaction execution availability determination unit for determining whether to execute a new transaction. A system operation management method for acquiring a load value for each function from a transaction function DB before executing a new transaction, predicting a change in system load, and determining whether a new transaction can be executed. 2. The system according to claim 1, wherein the load value for each function of the transaction input to the transaction function DB can be determined based on a primitive processing unit obtained by subdividing the function at the time of design. Operation management method. 3. A function design document describing detailed processing contents of a function, a function decomposing unit that decodes the contents of the function design document and extracts a primitive process, and accumulates a system load and a processing time of the primitive process. A primitive processing DB, and a system load and a processing time of the primitive processing extracted by the functional decomposition unit are retrieved from the primitive processing DB and calculated as a load value for each function. 3. The system operation management system according to claim 2, further comprising a calculation unit for inputting the data to a DB. 4. The system unit employs one maximum value of primitive processing for each function unit in the calculation unit, and adds a processing time of each primitive processing for a processing time. 4. The system operation management system according to claim 3, wherein the system operation management system inputs the information to a function DB. 5. The system operation management system according to claim 1, wherein after starting operation, a difference between an actual system load and a load estimate is periodically checked, and if there is a difference, the load value is reviewed. 6. A system load measuring unit for measuring a system load, a difference detecting unit for calculating a difference between the load history and a load predicted value stored in a prediction DB and an actual system load, A load value recalculating unit for each function that recalculates the load value input to the transaction function DB based on the difference information output from the unit; and a transaction based on the result of the load value recalculating unit for each function. 6. The system operation management system according to claim 5, further comprising: a function DB, a load history, and a load value reflection unit that reflects the load history and the prediction DB. 7. The system operation management system according to claim 1, further comprising a plurality of transaction function DBs, and performing more detailed transaction execution determination by combining some system loads. 8. The system operation management method according to claim 1, wherein, when a change in the system load is predicted, when an overload is determined, the overload is avoided by changing the transaction scheduling. 9. The system according to claim 1, wherein when a change in the system load is predicted, if an overload is determined, the scheduling is changed so as to lower the priority of the transaction at a time when the system is overloaded, thereby avoiding the overload. 2. The system operation management system according to claim 1, wherein: 10. The system operation management method according to claim 1, wherein when an overload is determined as a result of estimating a change in system load, a degree of delay of the transaction is estimated and notified to an executor of the transaction. . 11. A system according to claim 1, wherein as a result of estimating a change in the system load, if it is expected that another transaction is executed after this transaction, an overload is expected, a warning is issued before the execution of the transaction. 1. The system operation management system according to 1. 12. The system according to claim 1, wherein when an overload is determined as a result of estimating a change in the system load, a delay warning is issued before executing the transaction, and the determination as to whether or not execution is possible is left to the user. Operation management method. 13. The system operation management system according to claim 1, wherein only a privileged user can execute a transaction when the system load is estimated and an overload is determined.