WO2019030889A1 - 計算機運用管理システムおよび方法 - Google Patents

計算機運用管理システムおよび方法 Download PDF

Info

Publication number
WO2019030889A1
WO2019030889A1 PCT/JP2017/029058 JP2017029058W WO2019030889A1 WO 2019030889 A1 WO2019030889 A1 WO 2019030889A1 JP 2017029058 W JP2017029058 W JP 2017029058W WO 2019030889 A1 WO2019030889 A1 WO 2019030889A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
computer
time
feature point
unit
Prior art date
Application number
PCT/JP2017/029058
Other languages
English (en)
French (fr)
Inventor
寿昭 小田
健一 井手上
隆司 西岡
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to JP2018567962A priority Critical patent/JP6681484B2/ja
Priority to PCT/JP2017/029058 priority patent/WO2019030889A1/ja
Publication of WO2019030889A1 publication Critical patent/WO2019030889A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]

Definitions

  • the present invention relates to a technology for operating application software such as a business system.
  • the business application actually developed overseas or the business application realized by combining commercial software and open source software has a configuration that the operator does not know what characteristics it has. There is (black boxed).
  • Java virtual machine Java virtual machine
  • the operation schedule on when to execute the application in the entire business system may be inappropriate. Improper scheduling may increase the delay of process completion. Also, an application may not run due to an inappropriate schedule. As a result, the operation cost of the business system may increase or the reliability of the business system may decrease.
  • the time and effort to determine the time to execute the application may increase in the formulation of the operation schedule.
  • An object of the present invention is to provide a technology that enables improvement of a business system in which the characteristics of the application are not known.
  • a computer operation management apparatus executes on a computer according to a first resource allocation defining resources used for executing an application and a first schedule defining a time zone utilizing the resources for executing the application.
  • An operation information editing unit which is provided with operation information recording the history of the executed application and generates feature point information representing a predetermined quantitative property of the application based on the operation information, and based on the feature point information
  • An application characteristic determination unit that determines an application characteristic representing a predetermined qualitative characteristic of the application, an operation requirement specifying a performance required in relation to the application, and a resource constraint usable by the computer Show the resource constraints shown and guidelines for the operation of the computer
  • An operation policy is given, and based on the feature point information of the application and the application characteristic, the operation requirement and the resource constraint are satisfied, and the computer is used so as to follow the guidelines indicated in the operation policy.
  • an optimization execution unit that calculates a second resource allocation and a second schedule.
  • FIG. 1 is a block diagram of an operation management system according to the present embodiment.
  • the operation management system 100 according to the present embodiment is a system for operating a business system realized by a plurality of applications 370 operating on the application operating environment 200.
  • the application in the present embodiment is configured in units of jobs of the business system, and can specify and execute a plurality of applications.
  • the operation management system 100 receives, as input, the operation requirements 310, the operation policy 320, and the schedule 330 given in advance, and the operation information 380 accumulated by execution of the application 370 in the application operation environment 200, and performs sizing and scheduling. , And the process of operation improvement candidate search, and outputs sizing information 340, a schedule 350, and an operation improvement candidate 360.
  • the operation requirement 310 is the level of service to be provided to the user by executing the application by the business system including the performance required in connection with the application.
  • the operation requirement 310 is, for example, an SLA (Service Level Agreement) agreed between an operator and a user of the business system.
  • SLA Service Level Agreement
  • the operation policy 320 is a guideline for operation of the business system.
  • the operation policy 320 includes information as to which parameter such as performance or cost is to be prioritized in operation of the business system.
  • the schedule 330 is information indicating which resource is allocated to which application in which time zone.
  • the schedule 330 is a schedule applied before the operation management process of the business system by the operation management system 100, and is appropriately improved by the operation management process.
  • the operation management process is a process for improving the operation of the business system, and the process result includes information appropriately applied to the business system and information proposed to the operator as a candidate for operation improvement measures (operation improvement candidate). And are included.
  • the resources include hardware and software resources such as a central processing unit (CPU) and memory.
  • the application operating environment 200 is the configuration and state of hardware and software of a computer (not shown) that operates a business system realized by a plurality of applications.
  • the resources available for executing the application are determined by the application operating environment 200.
  • the application 370 is a software program used by the user of the business system.
  • the business system is realized by a plurality of applications.
  • the operation information 380 is information relating to the operation of a resource acquired at a predetermined timing such as the start or completion timing of a request generated with the execution of an application.
  • the sizing information 340 is information indicating how many resources are used to execute which application.
  • the sizing information 340 is a processing result of the operation management process by the operation management system 100, and is appropriately applied to the business system.
  • the schedule 350 is information indicating which resource is allocated to which application in which time zone.
  • the schedule 350 is a schedule obtained by the operation management process, and is information appropriately applied to the business system. By applying the schedule 350 to the business system, it is considered that resource management of the business system is improved.
  • the operation improvement candidate 360 is a processing result of operation management processing, and is a candidate for improvement measures for improving the operation of the business system. However, unlike the sizing information 340 and the schedule 350, the operation improvement candidate 360 is presented to the operator before being applied to the business system.
  • the operation improvement candidate 360 is an improvement measure that can not be applied automatically, for example, a change in hardware configuration.
  • the presentation to the operator is, for example, display on a display screen. The operator can determine whether to apply the presented operation improvement candidate 360 to the business system.
  • the operation management system 100 includes the operation information acquisition unit 110, the operation information editing unit 120, the feature point analysis unit 130, the input unit 140, the optimization execution unit 150, and the operation improvement candidate presentation.
  • a section 160 and an output section 170 are provided.
  • the operation information editing unit 120 includes a feature point extracting unit 121, an operation result extracting unit 122, and a schedule result extracting unit 123.
  • the feature point analysis unit 130 includes an application characteristic determination unit 131.
  • the input unit 140 includes an operation requirement input unit 141, an operation policy input unit 142, and a schedule input unit 143.
  • the optimization execution unit 150 includes a sizing planning unit 151, a schedule determination unit 152, and a rescheduling unit 153.
  • the operation improvement candidate presentation unit 160 includes an operation improvement candidate search unit 161.
  • the output unit 170 includes a sizing output unit 171, a schedule output unit 172, and an operation improvement candidate output unit 173.
  • an operation information acquisition unit 210 which is paired with the operation information acquisition unit 110 of the operation management system is disposed.
  • the operation information acquisition unit 110 of the operation management system 100 is a server, and the operation information acquisition unit 210 of the application operation environment 200 is an agent, and the acquisition of operation information 380 by the operation management system 100 is realized.
  • the input unit 140 inputs the operation requirements 310, the operation policy 320, and the schedule 330 into the operation management system 100.
  • the operation requirement input unit 141 inputs the operation requirement 310.
  • the operation policy input unit 142 inputs the operation policy 320.
  • the schedule input unit 143 inputs the schedule 330.
  • the operation information editing unit 120 extracts the feature point information of the application 370, the operation result of the business system, and the schedule result from the operation information 380 acquired by the operation information acquisition units 110 and 210.
  • Feature point information is information that represents the quantitative nature of the application 370.
  • the operation result of the business system indicates whether or not the business system is properly operated. For example, as the operation result of the business system, information indicating whether the given operation requirement 310 is satisfied can be obtained.
  • the schedule result is information indicating whether the business system is operating properly according to the given schedule 330.
  • the feature point extraction unit 121 extracts feature point information from the operation information 380.
  • the operation result extraction unit 122 extracts the information of the operation result from the operation information 380.
  • the schedule result extraction unit 123 extracts the information of the schedule result from the operation information 380.
  • the feature point analysis unit 130 analyzes the feature point information of the application of the business system extracted by the feature point extraction unit 121, and the application characteristic determination unit 131 determines the application characteristic.
  • the application characteristic is information on an item of a predetermined qualitative nature of the application.
  • the optimization execution unit 150 performs sizing expression implementation processing, and executes sizing (configuration management) processing and scheduling processing or rescheduling processing using the sizing expression.
  • the sizing expression embodying process is a process for embodying the sizing equation based on the feature point information of the application and the application characteristics and the operation requirements based on the original formula of the sizing equation used for the sizing process. Note that, for example, when the operation result extraction unit 122 obtains the operation result of the business system that the business system is not properly operated, the sizing and scheduling process may be started. The sizing and scheduling process may be started when the schedule result extraction unit 123 obtains a schedule result indicating that the business system is not properly operating according to the given schedule 330. In addition, the sizing and rescheduling process may be started when the execution of the rescheduling is instructed by the operator's operation.
  • the optimization execution unit 150 receives the operation requirement 310 given from the operation requirement input unit 141, the operation policy 320 given from the operation policy input unit 142, and the feature point extraction unit 121. Based on feature point information, application characteristics given by the application characteristic determination unit 131, and resource constraints determined by resources of the application operating environment 200, the operation requirements 310 and resource constraints are satisfied, and the guidelines shown in the operation policy 320
  • the resource allocation (sizing information 340) used by the computer and the schedule 350 are calculated according to the following.
  • the optimization execution unit 150 adds the operation requirements 310, the operation policy 320, the feature point information, the application characteristics, the resource constraints, and the schedule given from the schedule input unit 143.
  • the sizing process is a process of determining resources to be used to execute an application.
  • Resources include CPU and memory.
  • the scheduling process is a process of determining a time zone in which a resource is used to execute an application.
  • the resource determined to be used for execution of the application in the sizing process is determined for which time zone to use for execution of each application of the business system.
  • the results of the sizing process and the scheduling process are notified to the application operating environment 200 of the business system and applied as appropriate.
  • the rescheduling process is a process of obtaining information from a given schedule, such as an existing schedule, and performing sizing and scheduling within the range of the information.
  • the information obtained from the given schedule includes information on resources used for executing the application, and information on time from the start of execution of the application to the completion of the execution.
  • a schedule is calculated that runs the application using limited resources and completes the process in a limited amount of time.
  • the sizing planning unit 151 executes a sizing process.
  • the schedule determination unit 152 executes a scheduling process.
  • the rescheduling unit 153 executes a rescheduling process.
  • the operation improvement candidate presentation unit 160 causes the operation improvement candidate search unit 161 to execute operation improvement candidate search processing.
  • the operation improvement candidate search process is a process of searching for an operation improvement measure that involves a change in internal processing of an application or a change in the hardware configuration of a computer that implements the application operating environment 200.
  • the resource constraint includes the number of CPUs and the memory capacity limited by the hardware configuration of the computer.
  • the operation improvement candidate search unit 161 proposes an operation improvement measure for adding or deleting the CPU or memory of the computer restricted by the resource constraint.
  • the operation improvement measures that are the result of the operation improvement candidate search process can not be applied immediately because they differ from the results of the sizing process and the scheduling process and involve changes in the hardware configuration of the application or the computer.
  • the operation improvement measure is presented to the operator as the operation improvement candidate 360, and it is determined whether or not the application can be applied.
  • the output unit 17 outputs sizing information 340 that is the result of the sizing process, a schedule 350 that is the result of the scheduling process, and an operation improvement candidate 360 that is the result of the operation improvement candidate search process.
  • the sizing output unit 171 outputs the sizing information 340.
  • the schedule output unit 172 outputs the schedule 350 which is the result of the scheduling process or the rescheduling process.
  • the operation improvement candidate output unit 173 outputs the operation improvement candidate 360.
  • the operation management system 100 includes the operation information editing unit 120, the application characteristic determination unit 131, and the optimization execution unit 150.
  • the operation information editing unit 120 uses the resources executed by the computer according to the first resource allocation that defines the resources used for the execution of the application and the first schedule that defines the time zone for using the resources for the execution of the application. Is provided, and based on the operation information, feature point information representing a predetermined quantitative property of the application is generated.
  • the application characteristic determination unit 131 determines an application characteristic representing a predetermined qualitative property of the application based on the feature point information.
  • the optimization execution unit 150 gives an operation requirement specifying the performance required in relation to the application, a resource constraint indicating a constraint of resources available on the computer, and an operation policy indicating a guideline for operation of the computer.
  • feature point information that is the quantitative property of the application is generated from the operation information
  • an application characteristic that is the qualitative property is determined from the feature point information
  • appropriate resources are used using the feature point information and the application characteristic.
  • the schedule can be calculated, it is possible to improve the operation of the computer even if the application characteristics are unknown.
  • the operation improvement candidate search unit 161 proposes an operation improvement measure involving a change of the application or the computer based on the application characteristic.
  • the application characteristic is estimated based on the operation information, and the operation improvement measure is calculated based on the application characteristic. Therefore, even if the application characteristic is unknown, the improvement system makes it possible to improve the computer system.
  • the output unit 170 applies the second resource allocation and the second schedule to the computer, and presents an operation improvement measure to the operator (operator) who operates the computer.
  • the applicable resource allocation and schedule are applied to the computer and operation improvement measures involving changes in the application and computer configuration are presented to the operator, so that the current good computer operation can be achieved. It will be realized and future improvement will be possible.
  • FIG. 2 is a flowchart of the operation management process executed by the operation management system according to the present embodiment.
  • the operation information acquisition unit 110 acquires the operation information 380 of the application 370 in cooperation with the operation information acquisition unit 210 of the application operation environment 200 in step S101.
  • the feature point extracting unit 121 extracts feature point information of the application 370 from the operation information 380 in step S102.
  • the application characteristic determination unit 131 determines the application characteristic of the application 370 based on the feature point information.
  • the operation requirement input unit 141 inputs the operation requirement 310 to the optimization execution unit 150.
  • the operation policy input unit 142 inputs the operation policy 320 to the optimization execution unit 150.
  • step S106 the sizing planning unit 151 executes a sizing formula realization process. Furthermore, in the optimization execution unit 150, in step S107, the sizing planning unit 151 performs sizing processing (configuration management processing), and the schedule determination unit 152 executes scheduling processing. Sizing information 340 (second resource allocation) is generated as a result of the sizing process. As a result of the scheduling process, a schedule 350 (second schedule) is generated. The sizing process and the scheduling process are performed by the optimization engine. For example, the optimization execution unit 150 calculates, as the second resource allocation, the CPU, the memory area, and the number of concurrent executions of processes allocated to the application. The optimization execution unit 150 also calculates, as the second schedule, the start time and end time of the application executed on the computer and the resources to be used.
  • step S108 the operation improvement candidate search unit 161 executes the operation candidate improvement process.
  • An operation improvement candidate 360 is generated as a result of the operation improvement candidate search process.
  • the output unit 170 outputs the sizing information 340 by the sizing output unit 171
  • the schedule 350 is output by the schedule output unit 172
  • the operation improvement candidate 360 is output by the operation improvement candidate output unit 173. .
  • a portion surrounded by a dashed square is a process for one or more applications. The detailed process will be described later. That is, the detailed processing of steps S101 to S102, steps S103, S106, S107, and S108 will be described later.
  • FIG. 3 is a diagram for describing feature point extraction processing in the present embodiment.
  • the feature point extraction unit 121 extracts the value of each item of feature point information that is predetermined as shown in FIG. 3 from the operation information 380.
  • FIG. 3 shows a table describing, for each item of feature point information, the type of operation log from which the information of the item is extracted and the unit in which the log is output.
  • the operation log is history information acquired as the operation information 380 in the application operating environment 200.
  • items to be extracted as feature point information include execution time, CPU time, total memory allocation amount, maximum memory reference size, maximum memory reference life, post-execution reference memory size, DB (database) access time, File IO (file I / O processing) time, NWIO (network I / O processing) time, exclusive waiting time, throughput, other waiting time, GC (garbage collection) occupancy rate, Java heap securing size, GC required time, post-GC Java heap There is remaining size.
  • the execution time is shown to be extracted from a log called request trace. Also, it is shown that the output unit of the request trace is by application or by process.
  • the execution time is the time required to execute a predetermined execution unit, specifically, the response time in one transaction, or a plurality (several thousands to several thousands) of processing included in one execution unit. It is the time it takes to do.
  • the execution unit referred to here is a group of processing units executed using the CPU in the application, and is, for example, a program, a transaction, a process, a thread, or the like.
  • An example of processing included in one execution unit is access to a database.
  • Execution time is the sum of CPU time, IO time and latency, and may be referred to as ETIME.
  • the feature point extraction unit 121 can extract the execution time of the application from the request trace output for each application.
  • CPU time is shown to be extracted from a log called request trace. Also, it is shown that the output unit of the request trace is by application or by process. The CPU time is the time that the CPU operates to execute a predetermined execution unit. The feature point extraction unit 121 can extract the CPU time of the application from the request trace output for each application.
  • the total memory allocation amount is extracted from a log called a memory profile. Also, it is shown that the output unit of the memory profile is application or process.
  • the total memory allocation amount is the total capacity of a memory area allocated to execute a predetermined execution unit of an application.
  • the feature point extraction unit 121 can extract the total amount of memory allocation from the memory profile output for each application.
  • a computer that executes a business system to be managed has a memory and a CPU as resources.
  • the feature point extraction unit 121 extracts a value from the operation information 380 in the operation information editing unit 120, so that the feature point information is at least the total amount of memory area allocated for each predetermined execution unit of the application.
  • a certain total memory allocation amount, CPU time which is a time when the CPU is operated to execute a predetermined execution unit, and execution time which is a time required to execute a predetermined execution unit are generated. Given the total amount of memory allocation, CPU time, and execution time, key application characteristics can be determined in diagnosing resource allocation and scheduling.
  • the main feature of the program can be grasped by the minimum configuration feature point information (total memory allocation amount, CPU time, and execution time), and appropriate resource allocation and schedule can be calculated.
  • the application characteristic determination unit 131 determines in step S201 whether the execution time is shorter than 60 seconds.
  • the execution time may be described as R below. If the execution time is shorter than 60 seconds, the application characteristic determination unit 131 determines the item of the application type of the application characteristic as the online processing “online” in step S203.
  • the application characteristic determination unit 131 determines in step S202 whether the execution time is shorter than 3600 seconds. If the execution time is shorter than 3600 seconds, the application characteristic determination unit 131 determines the application type item as the on-batch processing “on-batch” in step S204.
  • the application characteristic determination unit 131 determines the application type item as the off-batch processing “off-batch” in step S205.
  • the threshold used in steps S201 and S202 may be set in advance to a value appropriate for identifying the application type. For example, information that associates a large number of applications with their execution times may be collected, and an appropriate threshold may be determined from the information.
  • the application characteristic determination unit 131 determines in step S206 whether the CPU time / execution time is greater than 80%. If the CPU time / execution time is greater than 80%, the application characteristic determination unit 131 determines an item indicating whether or not CPU bound in step S 210 as “1” indicating CPU bound. .
  • the application characteristic determination unit 131 determines in step S207 whether the DB access time / execution time is greater than 80%. If the DB access time / execution time is greater than 80%, the application characteristic determination unit 131 indicates that the item indicating whether or not DB access is bound is DB access bound at step S211. Decide.
  • the application characteristic determination unit 131 determines in step S208 whether the file IO time / execution time is greater than 80%. If the file IO time / execution time is greater than 80%, the application characteristic determination unit 131 indicates that the item indicating whether or not the file IO is bound is “file IO bound” in step S 212. Decide.
  • the application characteristic determination unit 131 determines whether the NWIO time / execution time is greater than 80% in step S209. If the NWIO time / execution time is greater than 80%, the application characteristic determination unit 131 determines the item indicating whether or not the NWIO is bound in step S213 as “1” indicating that the NWIO is bound. .
  • threshold values used in steps S206, S207, S208, and S209 may be set to values appropriate for determining the feature of the application.
  • a value of 80% which is generally used in determining the feature of the application is used.
  • the application characteristic determination unit 131 determines in step S214 whether the application type is online. If the application type is online, the application characteristic determination unit 131 determines whether the CPU time is larger than 100 msec in step S215. If the CPU time is greater than 100 msec, the application characteristic determination unit 131 determines an item indicating whether the CPU cost is large as “1” indicating that the CPU cost is large in step S217.
  • the application characteristic determination unit 131 determines in step S216 whether the total memory allocation amount is larger than 100 MB. If the total memory allocation amount is larger than 100 MB, the application characteristic determination unit 131 determines an item indicating whether the memory cost is large as “1” indicating that the memory cost is large.
  • the threshold used in steps S215 and S216 may be set in advance to a value suitable for determining the cost. For example, information may be collected for a large number of applications and an appropriate threshold may be determined from the information.
  • step S301 determines whether the exclusive waiting time / execution time is greater than 5%. . If the exclusion waiting time / execution time is greater than 5%, the application characteristic determination unit 131 determines that the proportion of the item indicating whether the proportion of the exclusion waiting time is large in the execution time is large in step S302. Determine "1" to indicate.
  • step S302 determines whether the GC required time is larger than 10 seconds. If the GC required time is longer than 10 seconds, the application characteristic determination unit 131 determines the item indicating whether the GC required time is large or not as “1” indicating that the GC required time is large in step S305. .
  • the application characteristic determination unit 131 determines in step S304 whether the GC occupancy rate is larger than 2%. If the GC occupancy rate is larger than 2%, the application characteristic determination unit 131 determines an item indicating whether the GC occupancy rate is large as “1” indicating that the GC occupancy rate is large.
  • step S307 the application characteristic determination unit 131 determines, in step S307, the information of each item of the application characteristic obtained by the determination so far to the application characteristic table.
  • the threshold values used in steps S301, S303, and S304 may be set in advance to values appropriate for determining each feature of the application. For example, information may be collected for a large number of applications and an appropriate threshold may be determined from the information.
  • the application characteristic determination unit 131 determines each item of the application characteristic based on the feature point information.
  • the application characteristic determination unit 131 determines, as an application characteristic, the application type including whether or not it is online processing based on the execution time, and when the application type is online, determines the memory cost based on the total memory allocation amount.
  • CPU cost is determined based on CPU time.
  • FIG. 6 is a flowchart of the sizing formula realization process in the present embodiment.
  • step S401 the sizing planning unit 151 determines whether the application type is online processing. This determination is made by referring to the application characteristic table. If the application type is the online process, the sizing planning unit 151 sets each value of feature point information and operation requirement for the settable part of the original formula of the sizing formula of the online process in step S403, Generate a specific sizing formula.
  • step S401 the sizing planning unit 151 determines whether the application type is on-batch processing in step S402. If the application type is the on-batch process, the sizing planning unit 151 proceeds to step S403 and generates a specific sizing formula using the formula of the sizing formula of the online process.
  • step S402 the sizing planning unit 151 sets each value of feature point information and operation requirement for the settable portion of the batch processing sizing formula original formula, and the specifics Generate a sizing formula.
  • step S405 the sizing planning unit 151 passes the sizing formula generated at step S403 or S404 to the schedule processing.
  • FIG. 7 is a diagram for explaining the cost priority scheduling process in the present embodiment.
  • the sizing formula of each application is embodied by applying feature point information, application characteristics, and operation requirements to the sizing formula prototype. Apply the sizing formula and operation policy of each application to the optimization engine that performs configuration management (sizing) and scheduling.
  • a cost-first operation policy is used.
  • the operation cost is set to 2,000,000 yen or less as an optimization target. Further, as the constraint conditions, a leading condition, a start time, and an end time are set.
  • the configuration definition obtained as a result of the sizing indicates that the application # 1 and the application # 2 operating on the basis of the Java VM are allocated with CPU # 1, CPU # 2, and 10 GB of memory, respectively.
  • application 1 (0001) operates on CPU # 1 and CPU # 2 in the time zone from 6:00 to 18:00, and CPU # 1 after 18:00. And the application 2 (0002) is shown to operate on the CPU # 2.
  • FIG. 8 is a diagram for describing the performance priority scheduling process in the present embodiment.
  • the operation policy of performance priority is used here.
  • the content that the completion time must be before 18:00 is set as the optimization target.
  • the constraint conditions a leading condition, a start time, and an end time are set.
  • application 1 (0001) operates on CPU # 1 and CPU # 2 in the time zone from 6:00 to 18:00, and application 2 (CPU 2) 0002) has been shown to work.
  • the sizing planning unit 151 and the schedule determination unit 152 calculate the configuration definition and the schedule so as to satisfy the constraint condition in addition to the operation requirements and the operation policy.
  • the constraint condition is an application in which a flag “1” meaning large is set in the item of whether or not the GC required time in the application characteristic is large.
  • the constraint condition in this example is a constraint condition that scheduling is performed so that applications in which the flag indicating file IO bound is “1” or the flag indicating NWIO bound is “1” are not simultaneously executed.
  • File IO bound and NWIO bound may be collectively called IO bound. This constraint condition is applied to an application in which one of the IO bound flags is “1”.
  • 9 and 10 are flowcharts of operation improvement candidate search processing in the present embodiment.
  • step S501 the operation improvement candidate search unit 161 determines whether the application type is online processing. If it is an online process, the operation improvement candidate search unit 161 determines in step S502 whether the CPU cost is large. If the CPU cost is high, the application is an online process and the CPU time is heavy, so the operation improvement candidate search unit 161 proposes a review of the dynamic step in step S503.
  • step S504 the operation improvement candidate search unit 161 determines whether the memory cost is large. If the memory cost is large, the application is online processing and the amount of memory used is large, so the operation improvement candidate search unit 161 proposes a review of how to use the memory in step S505.
  • step S506 the operation improvement candidate search unit 161 determines whether the ratio of the exclusion wait time to the execution time is large. If the ratio of the exclusion waiting time to the execution time is large, the exclusion waiting time is relatively large. Therefore, in step S507, the operation improvement candidate searching unit 161 proposes a review of the exclusion process.
  • step S508 the operation improvement candidate search unit 161 determines whether the application is DB access bound. If the application is DB access bound, the operation improvement candidate search unit 161 proposes SQL or DB server tuning in step S509 because DB access is heavy.
  • step S510 the operation improvement candidate search unit 161 determines whether the application is file IO bound. If the application is file IO bound, the file I / O is heavy, so the operation improvement candidate search unit 161 proposes IO processing or disk tuning in step S511.
  • step S512 the operation improvement candidate search unit 161 determines whether the application is NWIO bound. If the application is NWIO bound, since the NWIO is heavy, the operation improvement candidate search unit 161 proposes NW processing or NW tuning in step S513.
  • the operation improvement candidate search unit 161 determines in step S601 whether or not the ratio of the exclusion wait time to the execution time is large. . If the ratio of the exclusion wait time to the execution time is large, the operation improvement candidate search unit 161 proposes a review of the exclusion process in step S602.
  • step S603 the operation improvement candidate search unit 161 determines whether the application is DB access bound. If the application is DB access bound, the operation improvement candidate search unit 161 proposes tuning of the SQL or DB server in step S604 because DB access is heavy.
  • step S605 the operation improvement candidate search unit 161 determines whether the application is file IO bound. If the application is file IO bound, the operation improvement candidate search unit 161 proposes tuning of the IO processing or the disk in step S606 because the file IO is heavy.
  • step S607 the operation improvement candidate search unit 161 determines whether the application is NWIO bound. If the application is NWIO bound, the operation improvement candidate search unit 161 proposes NW processing or tuning of NW in step S608 because the NWIO is heavy.
  • FIG. 11 is a flowchart of rescheduling processing performed by the operation management system in the present embodiment.
  • the rescheduling process is a process for improving the existing schedule. Therefore, schedule optimization is performed within the range of information obtained from existing schedules.
  • the operator can regenerate the schedule again using the operation management system according to the present embodiment.
  • the operation policy input unit 142 acquires the operation policy 320 in step S701. Subsequently, in step S702, the rescheduling unit 153 acquires the existing schedule 330 input by the schedule input unit 143.
  • the existing schedule 330 may be, for example, the schedule 330 currently applied to the application operating environment 200.
  • step S703 the sizing planning unit 151 performs sizing using feature point information, application characteristics, and operation requirements obtained in advance and the operation policy 320 acquired in step S701. Furthermore, in step S704, the rescheduling unit 153 generates a schedule for improving the existing schedule 330 acquired in step S702. At this time, the rescheduling unit 153 instructs the schedule determining unit 152 to execute the scheduling process.
  • the schedule improved from the existing schedule 330 is, for example, a schedule conforming to the operation policy 320.
  • step S705 the operation improvement candidate search unit 161 searches for an operation improvement candidate.
  • the operation improvement candidate search unit 161 executes the operation improvement candidate search process shown in FIGS. 9 and 10.
  • step S706 the sizing output unit 171 outputs the sizing result in step S703, the schedule output unit 172 outputs the scheduling result in step S704, and the operation improvement candidate output unit 173 improves the operation in step S705. Output the result of candidate search.
  • FIG. 12 is a flowchart of the operation requirement review process executed by the operation management system in the present embodiment.
  • the operation requirement review process is a process of evaluating the fulfillment of the operation requirements based on the actual operation of the application.
  • Application feature point information and application characteristics are acquired again based on operation information, and satisfaction of operation requirements is evaluated based on the new information.
  • step S 801 the operation information acquisition unit 110 cooperates with the operation information acquisition unit 210 of the application operation environment 200 to acquire operation information 380.
  • step S802 the operation result extraction unit 122 extracts the operation result from the operation information.
  • step S803 the feature point extraction unit 121 extracts feature points of the application and generates feature point information. Subsequently, in step S804, the application characteristic determination unit 131 determines an application characteristic based on the feature point information. Furthermore, in step S805, the operation policy input unit 142 inputs the operation policy 320.
  • step S806 the sizing planning unit 151 performs the feature point information acquired in step S803, the application characteristic acquired in step S804, the operation requirements included in the operation result extracted from the operation information in step S802, and the step Sizing is performed using the operation policy 320 acquired in S805. Furthermore, the schedule determination unit 152 executes scheduling processing in step S807.
  • the operation improvement candidate search unit 161 searches for operation improvement candidates in step S808.
  • the operation improvement candidate search unit 161 executes the operation improvement candidate search process shown in FIGS. 9 and 10.
  • step S809 the sizing output unit 171 outputs the sizing result in step S806, the schedule output unit 172 outputs the scheduling result in step S807, and the operation improvement candidate output unit 173 improves the operation in step S808.
  • the operator evaluates whether the operation requirements are appropriate by looking at the results of sizing, scheduling, and operation improvement candidate search performed based on feature point information and application characteristics re-acquired based on actual operation information be able to. If sizing and scheduling are performed properly, it can be estimated that the operation requirements are appropriate. Also, by looking at the results of the operation improvement candidate search, it is possible to know how to correct the operation requirements.
  • the sizing planning unit 151 of the optimization execution unit 150 calculates resource allocation using a sizing formula according to the application type. Since the way of sizing differs depending on whether or not the application requires real time property, it is possible to easily make appropriate sizing by separating those calculation formulas.
  • Example of Sizing Formula for Online Processing The basic configuration of a sizing formula for online processing will be described. Here, it is assumed that the target to be calculated by the sizing formula is the Java heap size, the number of CPUs, and the number of simultaneous executions, which are allocated to the execution of the application. Java heap size corresponds to memory size.
  • the scheduled time is a scheduled execution time and depends on the schedule. When the throughput is designated in the operation requirement, the value of the designated throughput is used as T.
  • MT is the total memory allocate amount.
  • cd is a copy GC generation interval, and a normal value such as 10 seconds can be used, for example.
  • R is the execution time.
  • MR is the maximum memory reference size.
  • MA is a reference memory size after execution.
  • fd is a full GC occurrence interval. The fd specified in the operation requirement may be used. If fd is not specified as the operation requirement, a normal value such as 3600 seconds may be used. Also, if there is no garbage collection, fd will be the same as the application's scheduled time.
  • ML is the maximum memory reference life.
  • ⁇ is the size of a management memory area that the application uses for other than business, and for example, about 100 MB may be expected.
  • C is CPU time.
  • Other waiting time which is feature point information, refers to the waiting time in the pending queue in Java VM.
  • Example of Sizing Formula for Batch Processing The basic configuration of a sizing formula for batch processing will be described.
  • the target to be calculated by the sizing formula is the Java heap size, the number of CPUs, and the number of simultaneous executions, which are allocated to the execution of the application.
  • ⁇ is the size of a management memory area that the application uses for other than business, and for example, about 500 MB may be expected.
  • MT is the total amount of memory allocation as in ⁇ 1>.
  • fd is a full GC occurrence interval as in ⁇ 1>.
  • R is an execution time as in ⁇ 1>.
  • MR like ⁇ 1>, is the maximum memory reference size.
  • ⁇ is the size of a management memory area used by applications other than business, and for example, about 100 MB may be expected.
  • C is CPU time as in ⁇ 1>.
  • the other waiting time which is feature point information, also refers to the waiting time in the pending queue in Java VM.
  • the feature point information includes the number of CPUs indicating the number of CPUs to be allocated to the application, and the optimization execution unit 150 processes the application in any of ⁇ 1> and ⁇ 2> as well.
  • the number of CPUs is determined according to the CPU time which is the time to use the CPU. If the time taken for the process of the application is long, the number of CPUs can be increased to realize the throughput required by the operation requirements.
  • the feature point information includes the number of simultaneous executions, which is the number that can execute the process of the application in parallel, and the optimization execution unit 150 similarly determines whether the process of the application is executed in any of ⁇ 1> and ⁇ 2>.
  • the number of concurrent executions is determined according to the time obtained by subtracting the waiting time in the execution queue from the execution time at which the process was executed. If the time required for the process of the application is long, the number of concurrent executions can be increased to realize the throughput required by the operation requirements.
  • FIG. 13 is a diagram showing an example of the feature point information table in the present embodiment.
  • application ID application ID
  • execution time R
  • CPU time C
  • total memory allocation amount MT
  • maximum memory reference size MR
  • maximum memory reference life Reference memory size after execution (MA)
  • DB access time file IO time, NWIO time, exclusion waiting time, throughput, other waiting time, GC occupancy rate, Java heap securing size, GC required time, GC post heap size The remaining amount is recorded.
  • the execution time is the internal hold time, which is the response time seen by the client minus the communication time by the network.
  • the other waiting time refers to the waiting time in the execution waiting queue in Java VM, and is the time excluding CPU time, DB access time, file IO time, NWIO time, and exclusion waiting time from execution time.
  • Memory allocation is cumulatively performed during the execution time of the application.
  • the total amount of memory allocated during execution time is the total memory allocate amount.
  • the memory size of the portion (active memory) of the memory allocated to the application being executed excluding the portion that is not referred to (the dust) is called the maximum memory reference size.
  • the memory size of the memory left as a part to be referred to when execution of the application is finished is referred to as post-execution reference memory size.
  • a maximum memory reference life a period in which a memory of reference memory size continues to remain after execution.
  • FIG. 14 is a diagram showing an example of the application characteristic table in the present embodiment.
  • FIG. 15 is a diagram showing an example of the operation requirement table in the present embodiment.
  • the precedent condition is set to an application that needs to be completed before executing the application.
  • An application ID of an application that needs to be completed in advance is recorded in the Preconditions column.
  • the numbers shown in parentheses in the execution time column represent the worst values. The worst value is a time taking into account the time required for full GC (full GC time (FD)) when full GC occurs, in addition to the normal execution time shown without parentheses.
  • the operation policy is set for each application based on the operation requirements and other conditions. Other conditions are, for example, the operation cost.
  • contents such as which item is to be prioritized among operation requirements in which a plurality of items are designated are set.
  • FIG. 16 is a diagram for explaining an example of the operation policy. In the example of FIG. 16, four items of operation requirements are set.
  • Requirement (1) is a requirement that the peak throughput be 10,000.
  • Requirement (2) is a requirement that the execution time is within 2 seconds.
  • Requirement (3) is the requirement that the number of data search targets is 100,000.
  • the requirement (4) is that the average number of displayed items is 30 per request.
  • the first operation policy is an operation policy that is assumed to be applied during the busy period of the end of the month.
  • the objective function it is set that the requirement (2) is an absolute condition.
  • conditions that the requirement (1), the requirement (3), the requirement (4), and the absence of a GC are imposed as constraints.
  • the objective function has higher priority than the constraint in the optimization process.
  • the second operation policy is an operation policy that is assumed to be applied at normal times.
  • the objective function it is set to minimize the operation cost.
  • the execution time of the requirement (2) is within 2.6 seconds, and further, the condition that the requirement (1), the requirement (3), the requirement (4), and the GC are permitted is set. .
  • priority weighting can be performed on a plurality of designated items including designated items related to cost and designated items related to performance.
  • designated items related to cost For example, operation cost minimization is a designated item related to cost.
  • the operation requirements such as the execution time of requirement (2) include designated items related to performance.
  • the business system can be appropriately operated by prioritizing designated items such as cost priority or performance priority.
  • a plurality of different operation policies can be set from the same operation requirement, and a plurality of operation policies can be switched and applied at certain times.
  • the schedule that is the result of the scheduling process is recorded in the scheduling result table. If the operation policy applied to the scheduling process is different, the same operation requirements, resource constraints, and the schedule that can be obtained for the application are also different.
  • FIG. 17 is a diagram showing an example of a scheduling result table in the present embodiment.
  • the scheduling result table in the case where the operation policy is cost first and the case where the operation policy is performance first are shown in a contrastable manner.
  • the scheduling result table includes the application ID of the application, the number of CPUs and memory size available to the application, the number of processes and the number of concurrent executions permitted for the application, the execution period for executing the application, start time and end time It is shown.
  • the result of scheduling is represented by the start time and end time of each application. As can be seen by comparing the tables, the time when the entire operation by a plurality of applications is finished is 1:00 on the next day in the case of cost priority, but 22:00 in the case of performance priority. It is early.
  • FIG. 18 is a diagram for describing a first example of a scheduling result according to the present embodiment. As a first example, a time chart of cost priority scheduling results is shown. This corresponds to the scheduling result table shown in the upper part of FIG.
  • FIG. 19 is a diagram for describing a second example of the scheduling result according to the present embodiment. As a second example, a time chart of performance-oriented scheduling results is shown. This corresponds to the scheduling result table shown at the bottom of FIG.
  • FIG. 18 and FIG. 19 are compared, it can be seen that although the schedule of FIG. 19 uses more CPU and memory than the schedule of FIG. 18, the end time of the overall task is earlier.
  • the operation management system 100 may visually display the scheduling result on the screen as shown in FIG. 18 and FIG. As a result, the operator can easily understand and grasp the scheduling result visually.
  • FIG. 20 is a diagram showing an example of the operation improvement candidate in the present embodiment.
  • the operation required improvement candidate obtained by the operation improvement candidate search unit 161 is output from the operation improvement candidate output unit 173.
  • the operation improvement candidate output unit 173 outputs the operation improvement candidate extracted by the operation improvement candidate search unit 161 executing the improvement candidate search process shown in FIGS. 9 and 10. Referring to FIG. 20, the application ID of the application targeted for operation improvement and the content of the operation improvement candidate to be presented are shown in association with each other. At that time, the operation improvement candidate output unit 173 may display, for example, a list of operation improvement candidates on the screen, or may output list information of operation improvement candidates to a file.
  • FIG. 21 is a diagram for describing the state of the sizing process and the scheduling process in the present embodiment.
  • FIG. 21 shows a feature point information table and a scheduling result table. The information of the part surrounded by the bold square in the feature point information table is used for generating the information of the part surrounded by an ellipse in the scheduling result table, which is connected to the square and the arrow.
  • the optimization execution unit 150 determines the size of memory to be allocated to an application based on the GC occupancy of garbage collection.
  • the GC occupancy rate indicates the ratio of the GC processing time (the same as the time when the execution of the application is stopped) occupies per unit time.
  • performance such as application throughput and response is degraded due to overhead due to GC.
  • the GC occupancy rate is calculated as an index of overhead by GC, and the size of the memory allocated to the application is determined based on the value. Sizing and scheduling can be performed to meet the requirements.
  • the information on the GC required time and the post-GC Java heap size remaining amount in the feature point information table is the memory size of the scheduling result table, the number of processes, and the number of simultaneous executions. It can be seen that it is used to determine Specifically, it can be seen that the application is divided into processes and the number of processes is increased from 1 to 3 because the GC time required is long.
  • the optimization execution unit 150 determines the number of processes of the application according to the required time for garbage collection.
  • the required time of GC is calculated as an index of overhead by GC, and the number of processes of the application is determined based on that value. Sizing and scheduling can be performed.
  • the application operating environment 200 has a memory as a resource
  • the optimization execution unit 150 determines the area of the memory based on the application characteristic for the memory allocation. Determine the size of each area based on the feature point information. Since the area configuration of the memory is determined based on the quantitative nature of the application and the size of each area is determined based on the quantitative nature, memory having a suitable area configuration and area size can be provided to the application.
  • 100 ... operation management system, 110 ... operation information acquisition unit, 120 ... operation information editing unit, 121 ... feature point extraction unit, 122 ... operation result extraction unit, 123 ... schedule result extraction unit, 130 ... feature point analysis unit, 131 ... Application characteristic determination unit, 140 ... input unit, 141 ... operation requirements input unit, 142 ... operation policy input unit, 143 ... schedule input unit, 150 ... optimization execution unit, 151 ... sizing planning unit, 152 ... schedule determination unit, 153 ...
  • Re-scheduling unit 160 Operation improvement candidate presenting unit 161: Operation improvement candidate searching unit 170: Output unit 171: Sizing output unit 172: Schedule output unit 173: Operation improvement candidate output unit 200: Application operation Environment 210 operation information acquisition unit 310 operation requirements 320 operation policy 330 Jules, 340 ... sizing information, 350 ... schedule, 360 ... operational improvement candidates, 370 ... application, 380 ... operation information

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

アプリケーション特性が分からない業務システムの改善を可能にする。稼働情報編集部は、第１リソース割り当ておよび第１スケジュールに従って計算機にて実行されたアプリケーションの履歴を記録した稼働情報を与えられ、稼働情報に基づいて、アプリケーションの定量的性質を表す特徴点情報を生成する。アプリケーション特性判定部は、特徴点情報に基づいて、アプリケーションの定性的性質を表すアプリケーション特性を判定する。最適化実行部は、アプリケーションに関連して要求される性能を指定した運用要件と、計算機にて利用可能なリソースの制約を示すリソース制約と、計算機の運用の指針を示す運用ポリシとを与えられ、特徴点情報およびアプリケーション特性に基づいて、運用要件およびリソース制約を満たし、運用ポリシに示された指針に従うように、第２リソース割り当ておよび第２スケジュールを算出する。

Description

計算機運用管理システムおよび方法
　本発明は業務システムなどのアプリケーションソフトウェアを運用する技術に関する。
　近年では業務システムに搭載するアプリケーションを海外で開発することが増えている。また、アプリケーションサーバレイヤにおいて、商用ソフトウェアとオープンソースソフトウェア（ＯＳＳ）を組み合わせて効率よく業務システムのトータルサービスを実現することが求められている。
　実際に海外で開発された業務アプリケーションや商用ソフトウェアとオープンソースソフトウェアを組み合わせて実現された業務アプリケーションは、どのような構成になっており、どのような特性を持っているのか運用者でも分からないことがある（ブラックボックス化）。
　また、Ｊａｖａ仮想マシン（ＪａｖａＶＭ）など自動でメモリ管理を行うマネジメント環境が普及してきている。それによってもアプリケーションの特性が分かりにくくなっている。なお、Ｊａｖａは登録商標である。
特開２０１６－５０７６１８号公報 特許５１４２５８号公報
　アプリケーションの特性が分からないとシステム設計において処理装置および記憶装置の適切なリソース量を見積もることができない。そのため、処理装置および記憶装置のリソース量が不足あるいは過剰となる、サイジングの問題が起こる可能性がある。処理装置や記憶装置のリソースが不足すると、それによりシステム障害が引き起こされることがある。過剰なリソースは業務システムの運用コストを増大させることがある。
　また、アプリケーションの特性が分からないと、業務システムの全体の中でアプリケーションをいつ実行するかという運用スケジュールが不適切になる可能性がある。不適切なスケジューリングにより処理完了の遅延が増えることがある。また、不適切なスケジュールによりアプリケーションが実行されないことがある。そして、その結果、業務システムの運用コストが増大したり、業務システムの信頼性が低下したりすることがある。また、アプリケーションの特性が分からないと、運用スケジュールの策定において、アプリケーションを実行する時期を決める手間が増大することがある。
　また、アプリケーションの特性が分からないと、上述したサイジングあるいはスケジューリングの問題があった場合に、計算機に、どの程度の処理装置および記憶装置のリソース量を変更し、アプリケーションの運用をどのように改善したらよいか判断することが困難である。
　そのため、業務システムにおける計算機への各リソースの割り当ておよび運用スケジュールを改善するために、未知のアプリケーションの特性を診断し、診断結果に基づいて、業務システムの処理装置および記憶装置のリソース量の改善策や業務システムの運用改善策を提案するアプリケーション診断サービスが重要となっている。
　本発明の目的は、アプリケーションの特性が分からない業務システムの改善を可能にする技術を提供することである。
　本発明の一つの実施態様に従う計算機運用管理装置は、アプリケーションの実行に利用するリソースを定めた第１リソース割り当ておよびリソースをアプリケーションの実行に利用する時間帯を定めた第１スケジュールに従って計算機にて実行されたアプリケーションの履歴を記録した稼働情報を与えられ、前記稼働情報に基づいて、前記アプリケーションの所定の定量的性質を表す特徴点情報を生成する稼働情報編集部と、前記特徴点情報に基づいて、前記アプリケーションの所定の定性的性質を表すアプリケーション特性を判定するアプリケーション特性判定部と、前記アプリケーションに関連して要求される性能を指定した運用要件と、前記計算機にて利用可能なリソースの制約を示すリソース制約と、前記計算機の運用の指針を示す運用ポリシとを与えられ、前記アプリケーションの前記特徴点情報および前記アプリケーション特性に基づいて、前記運用要件および前記リソース制約を満たし、前記運用ポリシに示された指針に従うように、前記計算機にて利用する第２リソース割り当ておよび第２スケジュールを算出する最適化実行部と、を有している。
　稼働情報からアプリケーションの定量的性質である特徴点情報を生成し、その特徴点情報から定性的性質であるアプリケーション特性を判定し、特徴点情報とアプリケーション特性を利用して適切なリソースおよびスケジュールを算出することができるので、アプリケーション特性が未知であっても計算機の運用の改善が可能となる。
本実施形態による運用管理システムのブロック図である。 本実施形態による運用管理システムが実行する運用管理処理のフローチャートである。 本実施形態における特徴点抽出処理について説明するための図である。 本実施形態におけるアプリケーション特性判定処理のフローチャートである。 本実施形態におけるアプリケーション特性判定処理のフローチャートである。 本実施形態におけるサイジング式具体化処理のフローチャートである。 本実施形態におけるコスト優先のスケジューリング処理について説明するための図である。 本実施形態における性能優先のスケジューリング処理について説明するための図である。 本実施形態における運用改善候補探索処理のフローチャートである。 本実施形態における運用改善候補探索処理のフローチャートである。 本実施形態における運用管理システムが実行する再スケジューリング処理のフローチャートである。 本実施形態における運用管理システムが実行する運用要件見直し処理のフローチャートである。 本実施形態における特徴点情報テーブルの一例を示す図である。 本実施形態におけるアプリケーション特性テーブルの例を示す図である。 本実施形態における運用要件テーブルの例を示す図である。 運用ポリシの例について説明するための図である。 本実施形態におけるスケジューリング結果テーブルの例を示す図である。 本実施形態によるスケジューリング結果の第１例について説明するための図である。 本実施形態によるスケジューリング結果の第２例について説明するための図である。 本実施形態における運用改善候補の例を示す図である。 本実施形態におけるサイジング処理およびスケジューリング処理の様子を説明するための図である。
　以下、本発明の実施形態について図面を参照して説明する。
　図１は、本実施形態による運用管理システムのブロック図である。本実施形態による運用管理システム１００は、アプリケーション稼働環境２００上で動作する複数のアプリケーション３７０により実現された業務システムを運用するためのシステムである。本実施形態におけるアプリケーションは業務システムのジョブの単位に構成され、複数のアプリケーションを指定して実行することができる。
　運用管理システム１００は、予め与えられる運用要件３１０、運用ポリシ３２０、およびスケジュール３３０と、アプリケーション稼働環境２００にてアプリケーション３７０が実行されたことで蓄積される稼働情報３８０とを入力とし、サイジング、スケジューリング、および運用改善候補探索の処理を実行し、サイジング情報３４０、スケジュール３５０、および運用改善候補３６０を出力する。
　運用要件３１０は、アプリケーションに関連して要求される性能を含む業務システムがアプリケーションを実行することによりユーザに提供すべきサービスのレベルである。運用要件３１０は、例えば、業務システムのオペレータとユーザとの間で合意したＳＬＡ（Ｓｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ａｇｒｅｅｍｅｎｔ）である。
　運用ポリシ３２０は、業務システムの運用の指針である。運用ポリシ３２０には業務システムの運用にて、性能またはコスト等どのパラメータを優先させるかという情報が含まれる。
　スケジュール３３０は、どの時間帯にどのアプリケーションにどのリソースを割り当てるかを示す情報である。スケジュール３３０は、運用管理システム１００による業務システムの運用管理処理前から適用されているスケジュールであり、運用管理処理により適宜改善される。運用管理処理は、業務システムの運用を改善するための処理であり、その処理結果には業務システムに適宜適用される情報と、運用改善策の候補（運用改善候補）としてオペレータに提案される情報とが含まれる。リソースには、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）、メモリなどハードウェアおよびソフトウェアのリソースが含まれる。
　アプリケーション稼働環境２００は、複数のアプリケーションにより実現される業務システムを稼働させる計算機（不図示）のハードウェアおよびソフトウェアの構成および状態である。アプリケーションの実行に利用可能なリソースはアプリケーション稼働環境２００により決まる。
　アプリケーション３７０は、業務システムのユーザが利用するソフトウェアプログラムである。業務システムは複数のアプリケーションにより実現される。
　稼働情報３８０は、アプリケーションの実行に伴い発生するリクエストの開始あるいは完了のタイミングなど所定のタイミングで取得されるリソースの稼働に関する情報である。
　サイジング情報３４０は、どのアプリケーションの実行にどれだけのリソースを利用するかを示す情報である。サイジング情報３４０は、運用管理システム１００による運用管理処理の処理結果であり、業務システムに適宜適用される。
　スケジュール３５０は、スケジュール３３０と同様、どの時間帯にどのアプリケーションにどのリソースを割り当てるかを示す情報である。ただし、スケジュール３５０は、運用管理処理により得られたスケジュールであり、業務システムに適宜適用される情報である。業務システムにスケジュール３５０を適用することにより、業務システムのリソースの運用が改善されると考えられる。
　運用改善候補３６０は、運用管理処理の処理結果であり、業務システムの運用を改善する改善策の候補である。ただし、運用改善候補３６０は、サイジング情報３４０およびスケジュール３５０とは異なり、業務システムに適用する前にオペレータに提示される。運用改善候補３６０は、例えばハードウェア構成の変更など自動的に適用することができない改善策である。オペレータへの提示は例えばディスプレイ画面への表示である。オペレータは提示された運用改善候補３６０を業務システムに適用するか否か判断することができる。
　図１を再び参照すると、運用管理システム１００は、稼働情報取得部１１０と、稼働情報編集部１２０と、特徴点解析部１３０と、入力部１４０と、最適化実行部１５０と、運用改善候補提示部１６０と、出力部１７０とを有している。
　稼働情報編集部１２０は、特徴点抽出部１２１と、運用結果抽出部１２２と、スケジュール結果抽出部１２３とを有している。特徴点解析部１３０は、アプリケーション特性判定部１３１を有している。入力部１４０は、運用要件入力部１４１と、運用ポリシ入力部１４２と、スケジュール入力部１４３とを有している。
　最適化実行部１５０は、サイジング計画部１５１と、スケジュール決定部１５２と、再スケジュール部１５３とを有している。運用改善候補提示部１６０は、運用改善候補探索部１６１を有している。出力部１７０は、サイジング出力部１７１と、スケジュール出力部１７２と、運用改善候補出力部１７３とを有している。
　一方、アプリケーション稼働環境２００には運用管理システムの稼働情報取得部１１０と対をなす稼働情報取得部２１０が配置されている。運用管理システム１００の稼働情報取得部１１０がサーバとなり、アプリケーション稼働環境２００の稼働情報取得部２１０がエージェントとなり、運用管理システム１００による稼働情報３８０の取得を実現する。
　入力部１４０は、運用要件３１０、運用ポリシ３２０、およびスケジュール３３０を運用管理システム１００に入力する。入力部１４０において、運用要件入力部１４１は、運用要件３１０を入力する。運用ポリシ入力部１４２は、運用ポリシ３２０を入力する。スケジュール入力部１４３は、スケジュール３３０を入力する。
　稼働情報編集部１２０は、稼働情報取得部１１０、２１０により取得された稼働情報３８０から、アプリケーション３７０の特徴点情報と、業務システムの運用結果と、スケジュール結果とを抽出する。特徴点情報は、アプリケーション３７０の定量的性質を表す情報である。業務システムの運用結果は、業務システムが適切に運用されているか否かを示す。例えば、業務システムの運用結果として、与えられた運用要件３１０が満たされているかを示す情報が得られる。スケジュール結果は、業務システムが与えられたスケジュール３３０通りに適切に動作しているか否かを示す情報である。
　稼働情報編集部１２０において、特徴点抽出部１２１は、稼働情報３８０から特徴点情報を抽出する。運用結果抽出部１２２は、稼働情報３８０から運用結果の情報を抽出する。スケジュール結果抽出部１２３は、稼働情報３８０からスケジュール結果の情報を抽出する。
　特徴点解析部１３０は、特徴点抽出部１２１で抽出された、業務システムのアプリケーションの特徴点情報を解析し、アプリケーション特性判定部１３１にて、アプリケーション特性を判定する。アプリケーション特性は、アプリケーションの予め定められた定性的性質の項目に関する情報である。
　最適化実行部１５０は、サイジング式具体化処理を行い、サイジング式を用いたサイジング（構成管理）処理およびスケジューリング処理または再スケジューリング処理を実行する。サイジング式具体化処理は、サイジング処理に用いるサイジング式の原型の式を基に、アプリケーションの特徴点情報およびアプリケーション特性と運用要件とに基づいて、サイジング式を具体化する処理である。なお、例えば、運用結果抽出部１２２にて、業務システムが適切に運用されていないという業務システムの運用結果が得られたときに、サイジングおよびスケジューリングの処理を開始することにしてもよい。また、スケジュール結果抽出部１２３にて、業務システムが与えられたスケジュール３３０通りに適切に動作していないというスケジュール結果が得られたときにサイジングおよびスケジューリングの処理を開始することにしてもよい。また、オペレータ操作により再スケジューリングの実行が指示されたときに、サイジングおよび再スケジューリングの処理を開始することにしてもよい。
　サイジング処理およびスケジューリング処理を行う場合、最適化実行部１５０は、運用要件入力部１４１から与えられる運用要件３１０と、運用ポリシ入力部１４２から与えられる運用ポリシ３２０と、特徴点抽出部１２１から与えられる特徴点情報と、アプリケーション特性判定部１３１から与えられるアプリケーション特性と、アプリケーション稼働環境２００の有するリソースにより定まるリソース制約とを入力とし、運用要件３１０およびリソース制約を満たし、運用ポリシ３２０に示された指針に従うように、計算機にて利用するリソース割り当て（サイジング情報３４０）およびスケジュール３５０を算出する。
　サイジング処理および再スケジューリング処理を行う場合、最適化実行部１５０は、運用要件３１０と、運用ポリシ３２０と、特徴点情報と、アプリケーション特性と、リソース制約とに加え、スケジュール入力部１４３から与えられるスケジュール３３０と、を入力とし、スケジュール３３０から得られる情報の範囲内で運用要件３１０およびリソース制約を満たし、運用ポリシ３２０に示された指針に従うように、計算機にて利用するリソース割り当て（サイジング情報３４０）およびスケジュール３５０を算出する。
　サイジング処理は、アプリケーションの実行に利用するリソースを決定する処理である。リソースにはＣＰＵおよびメモリが含まれる。スケジューリング処理は、リソースをアプリケーションの実行に利用する時間帯を決定する処理である。サイジング処理にてアプリケーションの実行に利用すると決定されたリソースを、業務システムの各アプリケーションの実行にどの時間帯に利用するかが決定される。サイジング処理およびスケジューリング処理の結果は業務システムのアプリケーション稼働環境２００に通知され、適宜適用される。
　再スケジューリング処理は、例えば既存のスケジュールのような与えられたスケジュールから情報を得て、その情報の範囲内でサイジングおよびスケジューリングを行う処理である。与えられたスケジュールから得る情報には、アプリケーションの実行に利用されるリソースの情報、アプリケーションの実行開始から実行完了までの時間の情報と、が含まれる。限られたリソースを用いてアプリケーションを実行し、限られた時間内に処理を完了させるスケジュールが算出される。
　最適化実行部１５０において、サイジング計画部１５１は、サイジング処理を実行する。スケジュール決定部１５２は、スケジューリング処理を実行する。再スケジュール部１５３は、再スケジューリング処理を実行する。
　運用改善候補提示部１６０は、運用改善候補探索部１６１により運用改善候補探索処理を実行する。運用改善候補探索処理は、アプリケーションの内部処理の変更またはアプリケーション稼働環境２００を実現する計算機のハードウェア構成の変更を伴う運用改善策を探索する処理である。例えば、リソース制約には計算機のハードウェア構成によるＣＰＵ数およびメモリ容量の制限が含まれているとする。運用改善候補探索部１６１は、リソース制約で制限された計算機のＣＰＵまたはメモリを追加または削除する運用改善策を提案する。運用改善候補探索処理の結果である運用改善策は、サイジング処理およびスケジューリング処理の結果と異なり、アプリケーションあるは計算機のハードウェア構成の変更を伴うので、すぐに適用することができない。運用改善策は、運用改善候補３６０としてオペレータに提示され、適用の可否が判断される。
　出力部１７は、サイジング処理の結果であるサイジング情報３４０と、スケジューリング処理の結果であるスケジュール３５０と、運用改善候補探索処理の結果である運用改善候補３６０を出力する。出力部１７０において、サイジング出力部１７１はサイジング情報３４０を出力する。スケジュール出力部１７２は、スケジューリング処理あるいは再スケジューリング処理の結果であるスケジュール３５０を出力する。運用改善候補出力部１７３は運用改善候補３６０を出力する。
　以上説明したように、本実施形態による運用管理システム１００は、稼働情報編集部１２０と、アプリケーション特性判定部１３１と、最適化実行部１５０と、を有している。稼働情報編集部１２０は、アプリケーションの実行に利用するリソースを定めた第１リソース割り当ておよびリソースをアプリケーションの実行に利用する時間帯を定めた第１スケジュールに従って計算機にて実行されたアプリケーションによるリソースの利用を記録した稼働情報を与えられ、その稼働情報に基づいて、アプリケーションの所定の定量的性質を表す特徴点情報を生成する。アプリケーション特性判定部１３１は、その特徴点情報に基づいて、アプリケーションの所定の定性的性質を表すアプリケーション特性を判定する。最適化実行部１５０は、アプリケーションに関連して要求される性能を指定した運用要件と、計算機にて利用可能なリソースの制約を示すリソース制約と、計算機の運用の指針を示す運用ポリシとを与えられ、前記アプリケーションの前記特徴点情報および前記アプリケーション特性に基づいて、前記運用要件および前記リソース制約を満たし、前記運用ポリシに示された指針に従うように、前記計算機にて利用する第２リソース割り当ておよび第２スケジュールを算出する。このように、稼働情報からアプリケーションの定量的性質である特徴点情報を生成し、その特徴点情報から定性的性質であるアプリケーション特性を判定し、特徴点情報とアプリケーション特性を利用して適切なリソースおよびスケジュールを算出することができるので、アプリケーション特性が未知であっても計算機の運用の改善が可能である。
　また、本実施形態では、運用改善候補探索部１６１は、アプリケーション特性に基づき、アプリケーションまたは計算機の変更を伴う運用改善策を提案する。このように、稼働情報に基づいてアプリケーション特性を推定し、そのアプリケーション特性に基づいて運用改善策を算出するので、アプリケーション特性が未知であっても改善策により計算機システムの改善が可能となる。
　また、本実施形態では、出力部１７０は、第２リソース割り当ておよび第２スケジュールを計算機に適用し、運用改善策を、計算機を運用するオペレータ（運用者）に提示する。現在のアプリケーションおよび計算機の構成により適用可能なリソース割り当ておよびスケジュールを計算機に適用するとともに、アプリケーションおよび計算機の構成の変更を伴う運用改善策をオペレータに提示するので、現状での良好な計算機の運用を実現するとともに将来の更なる改善も可能となる。
　次に本実施形態による運用管理システムが実行する処理について説明する。
　図２は、本実施形態による運用管理システムが実行する運用管理処理のフローチャートである。
　図２を参照すると、運用管理処理において、稼働情報取得部１１０は、ステップＳ１０１において、アプリケーション稼働環境２００の稼働情報取得部２１０と連携して、アプリケーション３７０の稼働情報３８０を取得する。次に、特徴点抽出部１２１は、ステップＳ１０２にて、稼働情報３８０から、アプリケーション３７０の特徴点情報を抽出する。続いて、アプリケーション特性判定部１３１は、ステップＳ１０３にて、特徴点情報に基づき、アプリケーション３７０のアプリケーション特性を判定する。次に、運用要件入力部１４１は、ステップＳ１０４にて、最適化実行部１５０に運用要件３１０を入力する。次に、運用ポリシ入力部１４２は、ステップＳ１０５にて、最適化実行部１５０に運用ポリシ３２０を入力する。
　次に、サイジング計画部１５１は、ステップＳ１０６にて、サイジング式具体化処理を実行する。更に、最適化実行部１５０では、ステップＳ１０７にて、サイジング計画部１５１がサイジング処理（構成管理処理）を行い、スケジュール決定部１５２がスケジューリング処理を実行する。サイジング処理の結果としてサイジング情報３４０（第２リソース割り当て）が生成される。スケジューリング処理の結果として、スケジュール３５０（第２スケジュール）が生成される。サイジング処理およびスケジューリング処理は最適化エンジンにより行われる。例えば、最適化実行部１５０は、第２リソース割り当てとして、アプリケーションに割り当てるＣＰＵ、メモリ領域、およびプロセスの同時実行数を算出する。また、最適化実行部１５０は、第２スケジュールとして、計算機上で実行されるアプリケーションの開始時刻および終了時刻と利用するリソースとを算出する。
　次に、運用改善候補探索部１６１は、ステップＳ１０８にて、運用候補改善処理を実行する。運用改善候補探索処理の結果として、運用改善候補３６０が生成される。更に、出力部１７０は、ステップＳ１０９にて、サイジング出力部１７１によりサイジング情報３４０を出力し、スケジュール出力部１７２によりスケジュール３５０が出力され、運用改善候補出力部１７３により運用改善候補３６０が出力される。
　なお、図２にて、破線の四角形で囲われた部分は、１つ以上のアプリケーションに対する処理である。その詳細処理は後述する。つまり、ステップＳ１０１~Ｓ１０２、ステップＳ１０３、ステップＳ１０６、ステップＳ１０７、ステップＳ１０８の詳細な処理は後述する。
　以下、図２に示した各処理の詳細について説明する。
　図３は、本実施形態における特徴点抽出処理について説明するための図である。特徴点抽出部１２１は、図３に示すように予め定められた特徴点情報の各項目の値を稼働情報３８０から抽出する。
　図３には、特徴点情報の各項目について、その項目の情報が抽出される稼働ログの種類と、そのログが出力される単位とを記載したテーブルが示されている。稼働ログは稼働情報３８０としてアプリケーション稼働環境２００にて取得された履歴情報である。図３の例では、特徴点情報として抽出される項目として、実行時間、ＣＰＵ時間、総メモリアロケート量、最大メモリ参照サイズ、最大メモリ参照寿命、実行後参照メモリサイズ、ＤＢ（データベース）アクセス時間、ファイルＩＯ（ファイル入出力処理）時間、ＮＷＩＯ（ネットワーク入出力処理）時間、排他待ち時間、スループット、その他待ち時間、ＧＣ（ガベージコレクション）占有率、Ｊａｖａヒープ確保サイズ、ＧＣ所要時間、ＧＣ後Ｊａｖａヒープサイズ残量がある。
　その中で例えば、実行時間は、リクエストトレースというログから抽出されることが示されている。また、リクエストトレースの出力単位がアプリケーション別あるいはプロセス別であることが示されている。実行時間とは、所定の実行単位を実行するのに要する時間であり、具体的には、１トランザクションでの応答時間、あるいは１つの実行単位に含まれる複数（数千から数万）の処理を行うのに要する時間である。ここでいう実行単位は、アプリケーションにおいてＣＰＵを利用して実行するひとまとまりの処理単位であり、例えば、プログラム、トランザクション、プロセス、スレッドなどである。１つの実行単位に含まれる処理の例としてデータベースへのアクセスがある。実行時間は、ＣＰＵ時間、ＩＯ時間及び待ち時間の合計であり、ＥＴＩＭＥと呼ばれることもある。特徴点抽出部１２１は、アプリケーション毎に出力されたリクエストトレースからアプリケーションの実行時間を抽出することができる。
　また、例えば、ＣＰＵ時間は、リクエストトレースというログから抽出されることが示されている。また、リクエストトレースの出力単位がアプリケーション別あるいはプロセス別であることが示されている。ＣＰＵ時間は、所定の実行単位を実行するのにＣＰＵが稼働する時間である。特徴点抽出部１２１は、アプリケーション毎に出力されたリクエストトレースからアプリケーションのＣＰＵ時間を抽出することができる。
　また、例えば、総メモリアロケート量は、メモリプロファイルというログから抽出されることが示されている。また、メモリプロファイルの出力単位がアプリケーション別あるいはプロセス別であることが示されている。総メモリアロケート量は、アプリケーションの所定の実行単位を実行するために割り当てられたメモリ領域の総容量である。特徴点抽出部１２１は、アプリケーション毎に出力されたメモリプロファイルから総メモリアロケート量を抽出することができる。
　本実施形態による運用管理システム１００では、管理対象の業務システムを実行する計算機がリソースとしてメモリおよびＣＰＵを有している。本実施形態では、稼働情報編集部１２０において、特徴点抽出部１２１は、稼働情報３８０から値を抽出することにより、特徴点情報として少なくとも、アプリケーションの所定の実行単位ごとに割り当てるメモリ領域の総量である総メモリアロケート量と、所定の実行単位を実行するのにＣＰＵが稼働した時間であるＣＰＵ時間と、所定の実行単位を実行するのに要した時間である実行時間と、を生成する。総メモリアロケート量、ＣＰＵ時間、および実行時間があると、リソース割り当ておよびスケジュールが適切かどうか診断するうえで主要なアプリケーション特性を判定することができる。最小構成の特徴点情報（総メモリアロケート量、ＣＰＵ時間、および実行時間）によりプログラムの主要な特徴を把握し、適切なリソース割り当ておよびスケジュールを算出することができる。
　以下、アプリケーション特性判定処理を更に詳細に説明する。
　図４、図５は、本実施形態におけるアプリケーション特性判定処理のフローチャートである。
　図４を参照すると、アプリケーション特性判定部１３１は、ステップＳ２０１にて、実行時間が６０秒よりも短いか否か判定する。実行時間を以下Ｒと記す場合がある。実行時間が６０秒よりも短ければ、アプリケーション特性判定部１３１は、ステップＳ２０３にて、アプリケーション特性のアプリケーション種別の項目をオンライン処理「オンライン」と決定する。
　実行時間が６０秒よりも短くなければ、アプリケーション特性判定部１３１は、ステップＳ２０２にて、実行時間が３６００秒よりも短いか否か判定する。実行時間が３６００秒よりも短ければ、アプリケーション特性判定部１３１は、ステップＳ２０４にて、アプリケーション種別の項目をオンバッチ処理「オンバッチ」と決定する。
　実行時間が３６００秒よりも短くなければ、アプリケーション特性判定部１３１は、ステップＳ２０５にて、アプリケーション種別の項目をオフバッチ処理「オフバッチ」と決定する。
　なお、ステップＳ２０１、Ｓ２０２にて用いる閾値はアプリケーション種別を識別するのに適切な値に予め設定しておけばよい。例えば、多数のアプリケーションとその実行時間を関連づけた情報を収集し、その情報から適切な閾値を決定することにしてもよい。
　ステップＳ２０３、Ｓ２０４、またはＳ２０５の後、アプリケーション特性判定部１３１は、ステップＳ２０６にて、ＣＰＵ時間／実行時間が８０％よりも大きいか否か判定する。ＣＰＵ時間／実行時間が８０％よりも大きければ、アプリケーション特性判定部１３１は、ステップＳ２１０にて、ＣＰＵバウンドであるか否かを示す項目を、ＣＰＵバウンドであることを示す「１」と決定する。
　ＣＰＵ時間／実行時間が８０％よりも大きくなければ、アプリケーション特性判定部１３１は、ステップＳ２０７にて、ＤＢアクセス時間／実行時間が８０％よりも大きいか否か判定する。ＤＢアクセス時間／実行時間が８０％よりも大きければ、アプリケーション特性判定部１３１は、ステップＳ２１１にて、ＤＢアクセスバウンドであるか否かを示す項目を、ＤＢアクセスバウンドであることを示す「１」と決定する。
　ＤＢアクセス時間／実行時間が８０％よりも大きくなければ、アプリケーション特性判定部１３１は、ステップＳ２０８にて、ファイルＩＯ時間／実行時間が８０％よりも大きいか否か判定する。ファイルＩＯ時間／実行時間が８０％よりも大きければ、アプリケーション特性判定部１３１は、ステップＳ２１２にて、ファイルＩＯバウンドであるか否かを示す項目を、ファイルＩＯバウンドであることを示す「１」と決定する。
　ファイルＩＯ時間／実行時間が８０％よりも大きくなければ、アプリケーション特性判定部１３１は、ステップＳ２０９にて、ＮＷＩＯ時間／実行時間が８０％よりも大きいか否か判定する。ＮＷＩＯ時間／実行時間が８０％よりも大きければ、アプリケーション特性判定部１３１は、ステップＳ２１３にて、ＮＷＩＯバウンドであるか否かを示す項目を、ＮＷＩＯバウンドであることを示す「１」と決定する。
　なお、ステップＳ２０６、Ｓ２０７、Ｓ２０８、およびＳ２０９にて用いる閾値はアプリケーションの特徴を判断するのに適切な値に設定すればよい。ここではアプリケーションの特徴を判定する際に一般的に用いられる８０％という値を用いた。
　ステップＳ２１０、Ｓ２１１、Ｓ２１２、あるいはＳ２１３の後、あるいはステップＳ２０９にてＮＯと判定されたとき、アプリケーション特性判定部１３１は、ステップＳ２１４にて、アプリケーション種別がオンラインであるか否か判定する。アプリケーション種別がオンラインであれば、アプリケーション特性判定部１３１は、ステップＳ２１５にて、ＣＰＵ時間が１００ｍｓｅｃより大きいか否か判定する。ＣＰＵ時間が１００ｍｓｅｃより大きければ、アプリケーション特性判定部１３１は、ステップＳ２１７にて、ＣＰＵコストが大きいか否かを示す項目をＣＰＵコストが大きいことを示す「１」と決定する。
　ＣＰＵ時間が１００ｍｓｅｃより大きくなければ、アプリケーション特性判定部１３１は、ステップＳ２１６にて、総メモリアロケート量が１００ＭＢより大きいか否か判定する。総メモリアロケート量が１００ＭＢより大きければ、アプリケーション特性判定部１３１は、メモリコストが大きいか否かを示す項目をメモリコストが大きいことを示す「１」と決定する。
　なお、ステップＳ２１５、Ｓ２１６にて用いる閾値はコストの大小を判定するのに適切な値に予め設定しておけばよい。例えば、多数のアプリケーションについて情報を収集し、その情報から適切な閾値を決定することにしてもよい。
　ステップＳ２１４の判定でＮＯのとき、あるいはステップＳ２１７、Ｓ２１８の後、図５に移り、アプリケーション特性判定部１３１は、ステップＳ３０１にて、排他待ち時間／実行時間が５％より大きいか否か判定する。排他待ち時間／実行時間が５％より大きければ、アプリケーション特性判定部１３１は、ステップＳ３０２にて、実行時間のうち排他待ち時間の割合が大きいか否かを示す項目を、その割合が大きいことを示す「１」と決定する。
　ステップＳ３０２の後、あるいはステップＳ３０１にてＮＯと判定されたとき、アプリケーション特性判定部１３１は、ステップＳ３０３にて、ＧＣ所要時間が１０秒より大きいか否か判定する。ＧＣ所要時間が１０秒よりも大きければ、アプリケーション特性判定部１３１は、ステップＳ３０５にて、ＧＣ所要時間が大きいか否かを示す項目を、ＧＣ所要時間が大きいことを示す「１」と決定する。
　ＧＣ所要時間が１０秒よりも大きくなれば、アプリケーション特性判定部１３１は、ステップＳ３０４にて、ＧＣ占有率が２％より大きいか否か判定する。ＧＣ占有率が２％より大きければ、アプリケーション特性判定部１３１は、ＧＣ占有率が大きいか否かを示す項目をＧＣ占有率が大きいことを示す「１」と決定する。
　ステップＳ３０５、Ｓ３０６の後、あるいはステップＳ３０４にてＮＯと判定されたとき、アプリケーション特性判定部１３１は、ステップＳ３０７にて、これまでの判定で得られたアプリケーション特性の各項目の情報をアプリケーション特性テーブルに出力する。
　なお、ステップＳ３０１、Ｓ３０３、Ｓ３０４にて用いる閾値はアプリケーションの各特徴を判定するのに適切な値に予め設定しておけばよい。例えば、多数のアプリケーションについて情報を収集し、その情報から適切な閾値を決定することにしてもよい。
　以上説明したように、本実施形態では、アプリケーション特性判定部１３１は、特徴点情報に基づいてアプリケーション特性の各項目について判定する。特に、アプリケーション特性判定部１３１は、アプリケーション特性として、オンライン処理か否かを含むアプリケーション種別を実行時間に基づいて判定し、アプリケーション種別がオンラインであれば、メモリコストを総メモリアロケート量に基づいて判定し、ＣＰＵコストをＣＰＵ時間に基づいて判定する。これらはアプリケーション特性として最小構成であり、本実施形態では、これらの項目を容易に判定することができる。
　図６は、本実施形態におけるサイジング式具体化処理のフローチャートである。
　図６を参照すると、サイジング計画部１５１は、ステップＳ４０１にて、アプリケーション種別がオンライン処理であるか否か判定する。この判定はアプリケーション特性テーブルを参照することにより行う。アプリケーション種別がオンライン処理であれば、サイジング計画部１５１は、ステップＳ４０３にて、オンライン処理のサイジング式の原型の式の設定可能箇所に対して、特徴点情報および運用要件の各値を設定し、具体的なサイジング式を生成する。
　ステップＳ４０１にてＮＯと判定された場合、サイジング計画部１５１は、ステップＳ４０２にて、アプリケーション種別がオンバッチ処理であるか否か判定する。アプリケーション種別がオンバッチ処理であれば、サイジング計画部１５１は、ステップＳ４０３に進み、オンライン処理のサイジング式の原型の式を用いて、具体的なサイジング式を生成する。
　ステップＳ４０２にてＮＯと判定された場合、サイジング計画部１５１は、バッチ処理のサイジング式の原型の式の設定可能箇所に対して、特徴点情報および運用要件の各値を設定し、具体的なサイジング式を生成する。
　ステップＳ４０３、Ｓ４０４の後、サイジング計画部１５１は、ステップＳ４０５にて、ステップＳ４０３またはＳ４０４で生成したサイジング式をスケジュール処理に渡す。
　図７は、本実施形態におけるコスト優先のスケジューリング処理について説明するための図である。図７を参照すると、特徴点情報、アプリケーション特性、および運用要件をサイジング式の原型に適用することにより各アプリケーションのサイジング式が具体化されている。その各アプリケーションのサイジング式と運用ポリシを、構成管理（サイジング）およびスケジューリングを行う最適化エンジンに適用する。
　ここではコスト優先の運用ポリシが用いられている。コスト優先の運用ポリシには、最適化目標として、運用コストが２００００００円以下という内容が設定されている。また、制約条件として先行条件や開始時刻および終了時刻が設定されている。
　サイジングの結果として得られた構成定義には、それぞれにＪａｖａＶＭを実行基盤として動作するアプリケーション１およびアプリケーション２にはＣＰＵ＃１、ＣＰＵ＃２、および１０ＧＢのメモリが割り当てられることが示されている。
　スケジューリングの結果として得られるスケジュール結果テーブルには、６：００～１８：００の時間帯にはＣＰＵ＃１およびＣＰＵ＃２上でアプリケーション１（０００１）が動作し、１８：００以降はＣＰＵ＃１およびＣＰＵ＃２上でアプリケーション２（０００２）が動作することが示されている。
　図８は、本実施形態における性能優先のスケジューリング処理について説明するための図である。図８を参照すると、ここでは性能優先の運用ポリシが用いられている。性能優先の運用ポリシには、最適化目標として、完了時刻が１８：００以前であることが必須であるという内容が設定されている。また、制約条件として先行条件や開始時刻および終了時刻が設定されている。
　サイジングの結果として得られた構成定義には、それぞれにＪａｖａＶＭを実行基盤として動作するアプリケーション１およびアプリケーション２にはＣＰＵ＃１、ＣＰＵ＃２、ＣＰＵ＃３、および１５ＧＢのメモリが割り当てられることが示されている。
　スケジューリングの結果として得られるスケジュール結果テーブルには、６：００～１８：００の時間帯に、ＣＰＵ＃１およびＣＰＵ＃２上でアプリケーション１（０００１）が動作し、ＣＰＵ＃３上でアプリケーション２（０００２）が動作することが示されている。
　図７と図８の構成定義を比較すると、図７の場合の方が図８の場合よりも少ないＣＰＵおよびメモリでアプリケーション１、２を動作させることが分かる。また、図７と図８のスケジュール結果テーブルを比較すると、図８の場合の方が図７の場合よりもアプリケーション１、２の処理を短い時間で完了させることが分かる。
　なお、サイジングおよびスケジューリングの処理には制約条件が課される場合がある。その場合、サイジング計画部１５１およびスケジュール決定部１５２は、運用要件および運用ポリシに加え、制約条件を満たすようにして構成定義およびスケジュールを算出する。
　どのような制約条件を用いるかは特に限定されないが、以下に制約条件のいくつかの例を示す。
　＜１＞ガベージコレクションの要件が厳しいＪａｖａ固有のアプリケーションに課される制約条件の例
　本例の制約条件は式（１）を満たすようにスケジューリングを行うことという制約条件である。数式中の各項の「：」は、「テーブル名：項目」を意味する。
Figure JPOXMLDOC01-appb-M000001
  
　なお、この制約条件は、アプリケーション特性におけるＧＣ占有率が大きいか否かという項目に、大きいことを意味するフラグ「１」が設定されているアプリケーションが対象となる。
　＜２＞ガベージコレクションの要件が厳しいＪａｖａ固有のアプリケーションに課される制約条件の他の例
　本例の制約条件は式（２）を満たすようにスケジューリングを行うことという制約条件である。式（２）により算出される１プロセスあたりのスループットを基に、サイジング式により1プロセスについてのサイジングを行う。サイジング処理は、上述した通り、アプリケーションの実行に利用するリソースを決定する処理である。得られたリソースに基づいて、運用要件を満たすためのプロセス数を決定する。運用要件を満たすプロセス数は式（３）により算出することができる。数式中の各項の「：」は、「テーブル名：項目」を意味する。
Figure JPOXMLDOC01-appb-M000002
Figure JPOXMLDOC01-appb-M000003
  
　なお、この制約条件は、アプリケーション特性におけるＧＣ所要時間が大きいか否かという項目に、大きいことを意味するフラグ「１」が設定されているアプリケーションが対象となる。
　＜３＞アプリケーション間でリソースを平準化するための制約条件（Ｊａｖａアプリケーションに限定されない）
　本例の制約条件は、ファイルＩＯバウンドであることを示すフラグが「１」またはＮＷＩＯバウンドであることを示すフラグが「１」であるアプリケーションが同時に実行されないようにスケジューリングを行うという制約条件である。ファイルＩＯバウンドとＮＷＩＯバウンドを総称してＩＯバウンドと呼ぶことがある。この制約条件は、ＩＯバウンドのいずれかのフラグが「１」であるアプリケーションが対象となる。
　図９および図１０は、本実施形態における運用改善候補探索処理のフローチャートである。
　図９を参照すると、運用改善候補探索部１６１は、ステップＳ５０１にて、アプリケーション種別がオンライン処理か否か判定する。オンライン処理であれば、運用改善候補探索部１６１は、ステップＳ５０２にて、ＣＰＵコストが大きいか否か判定する。ＣＰＵコストが大きければ、アプリケーションがオンライン処理であるかつＣＰＵ時間が重いため、運用改善候補探索部１６１は、ステップＳ５０３にて、ダイナミックステップの見直しを提案する。
　更に、運用改善候補探索部１６１は、ステップＳ５０４にて、メモリコストが大きいか否か判定する。メモリコストが大きければ、アプリケーションがオンライン処理かつメモリ使用量が多いため、運用改善候補探索部１６１は、ステップＳ５０５にて、メモリの使い方の見直しを提案する。
　更に、運用改善候補探索部１６１は、ステップＳ５０６にて、実行時間のうち排他待ち時間の割合が大きいか否か判定する。実行時間のうち排他待ち時間の割合が大きければ、排他待ち時間が比較的大きいため、運用改善候補探索部１６１は、ステップＳ５０７にて、排他処理の見直しを提案する。
　更に、運用改善候補探索部１６１は、ステップＳ５０８にて、アプリケーションがＤＢアクセスバウンドであるか否か判定する。アプリケーションがＤＢアクセスバウンドであれば、運用改善候補探索部１６１は、ＤＢアクセスが重いため、ステップＳ５０９にて、ＳＱＬまたはＤＢサーバチューニングを提案する。
　更に、運用改善候補探索部１６１は、ステップＳ５１０にて、アプリケーションがファイルＩＯバウンドであるか否か判定する。アプリケーションがファイルＩＯバウンドであれば、ファイルＩＯが重いため、運用改善候補探索部１６１は、ステップＳ５１１にて、ＩＯ処理またはディスクチューニングを提案する。
　更に、運用改善候補探索部１６１は、ステップＳ５１２にて、アプリケーションがＮＷＩＯバウンドであるか否か判定する。アプリケーションがＮＷＩＯバウンドであれば、ＮＷＩＯが重いため、運用改善候補探索部１６１は、ステップＳ５１３にて、ＮＷ処理またはＮＷチューニングを提案する。
　ステップＳ５０１の判定でアプリケーション種別がオンライン処理でなければ、図１０に示すように、運用改善候補探索部１６１は、ステップＳ６０１にて、実行時間のうち排他待ち時間の割合が大きいか否か判定する。実行時間のうち排他待ち時間の割合が大きければ、運用改善候補探索部１６１は、ステップＳ６０２にて、排他処理の見直しを提案する。
　更に、運用改善候補探索部１６１は、ステップＳ６０３にて、アプリケーションがＤＢアクセスバウンドであるか否か判定する。アプリケーションがＤＢアクセスバウンドであれば、運用改善候補探索部１６１は、ＤＢアクセスが重いため、ステップＳ６０４にて、ＳＱＬまたはＤＢサーバのチューニングを提案する。
　更に、運用改善候補探索部１６１は、ステップＳ６０５にて、アプリケーションがファイルＩＯバウンドであるか否か判定する。アプリケーションがファイルＩＯバウンドであれば、運用改善候補探索部１６１は、ファイルＩＯが重いため、ステップＳ６０６にて、ＩＯ処理またはディスクのチューニングを提案する。
　更に、運用改善候補探索部１６１は、ステップＳ６０７にて、アプリケーションがＮＷＩＯバウンドであるか否か判定する。アプリケーションがＮＷＩＯバウンドであれば、運用改善候補探索部１６１は、ＮＷＩＯが重いため、ステップＳ６０８にて、ＮＷ処理またはＮＷおｎのチューニングを提案する。
　図１１は、本実施形態における運用管理システムが実行する再スケジューリング処理のフローチャートである。再スケジューリング処理は既存のスケジュールを改善するための処理である。そのため、既存のスケジュールから得られる情報の範囲でのスケジュールの最適化を行う。
　オペレータは、本実施形態による運用管理システムを用いて、スケジュールを再度生成しなおすことができる。
　図１１を参照すると、運用ポリシ入力部１４２が、ステップＳ７０１にて、運用ポリシ３２０を取得する。続いて、ステップＳ７０２にて、再スケジュール部１５３は、スケジュール入力部１４３が入力した既存のスケジュール３３０を取得する。この既存のスケジュール３３０は例えばアプリケーション稼働環境２００に現在適用されているスケジュール３３０であってもよい。
　サイジング計画部１５１は、ステップＳ７０３にて、予め得られている特徴点情報、アプリケーション特性、および運用要件と、ステップＳ７０１で取得された運用ポリシ３２０とを用いてサイジングを行う。更に、再スケジュール部１５３は、ステップＳ７０４にて、ステップＳ７０２で取得した既存のスケジュール３３０を改善するスケジュールを生成する。このとき再スケジュール部１５３は、スケジュール決定部１５２に指示し、スケジューリング処理を実行させる。既存のスケジュール３３０よりも改善したスケジュールというのは、例えば、運用ポリシ３２０に適合したスケジュールである。
　続いて、運用改善候補探索部１６１は、ステップＳ７０５にて、運用改善候補を探索する。運用改善候補探索部１６１は、図９および図１０に示した運用改善候補探索処理を実行する。
　最後に、ステップＳ７０６にて、サイジング出力部１７１がステップＳ７０３のサイジングの結果を出力し、スケジュール出力部１７２がステップＳ７０４のスケジューリングの結果を出力し、運用改善候補出力部１７３がステップＳ７０５の運用改善候補探索の結果を出力する。
　図１２は、本実施形態における運用管理システムが実行する運用要件見直し処理のフローチャートである。運用要件見直し処理は、実際のアプリケーションの稼働に基づいて運用要件の充足を評価する処理である。稼働情報に基づいてアプリケーションの特徴点情報およびアプリケーション特性を再度取得し、その新たな情報に基づいて運用要件の充足を評価する。
　図１２を参照すると、稼働情報取得部１１０は、ステップＳ８０１にて、アプリケーション稼働環境２００の稼働情報取得部２１０と連携し、稼働情報３８０を取得する。次に、運用結果抽出部１２２が、ステップＳ８０２にて、稼働情報から運用結果を抽出する。
　次に、特徴点抽出部１２１は、ステップＳ８０３にて、アプリケーションの特徴点を抽出し、特徴点情報を生成する。続いて、アプリケーション特性判定部１３１は、ステップＳ８０４にて、特徴点情報に基づきアプリケーション特性を判定する。更に、運用ポリシ入力部１４２が、ステップＳ８０５にて、運用ポリシ３２０を入力する。
　サイジング計画部１５１は、ステップＳ８０６にて、ステップＳ８０３で取得された特徴点情報、ステップＳ８０４で取得されたアプリケーション特性、ステップＳ８０２にて、稼働情報から抽出した運用結果に含まれる運用要件、およびステップＳ８０５で取得された運用ポリシ３２０を用いてサイジングを行う。更に、スケジュール決定部１５２は、ステップＳ８０７にて、スケジューリング処理を実行する。
　続いて、運用改善候補探索部１６１は、ステップＳ８０８にて、運用改善候補を探索する。運用改善候補探索部１６１は、図９および図１０に示した運用改善候補探索処理を実行する。
　最後に、ステップＳ８０９にて、サイジング出力部１７１がステップＳ８０６のサイジングの結果を出力し、スケジュール出力部１７２がステップＳ８０７のスケジューリングの結果を出力し、運用改善候補出力部１７３がステップＳ８０８の運用改善候補探索の結果を出力する。オペレータは，実際の稼働情報に基づいて取得しなおした特徴点情報およびアプリケーション特性に基づいて実行したサイジング、スケジューリング、および運用改善候補探索の結果を見ることで、運用要件が適切かどうかを評価することができる。サイジングおよびスケジューリングが適切に行われていれば運用要件が適切であると推定できる。また、運用改善候補探索の結果を見れば、運用要件をどのように修正するとよいのかを知ることができる。
　続いて、サイジング式の例について説明する。
　オンライン処理とバッチ処理とではサイジングの考え方が異なるため、上述したようにそれぞれに基本構成に異なるサイジング式を用いる。最適化実行部１５０のサイジング計画部１５１は、アプリケーション種別に応じたサイジング式を用いて、リソース割り当てを算出する。リアルタイム性が要求されるアプリケーションであるか否かによりサイジングの仕方が異なるので、それらの算出式を分けることにより適切なサイジングが容易に可能となる。
　＜１＞オンライン処理のサイジング式の例
　オンライン処理のサイジング式の基本構成について説明する。ここでは、サイジング式により算出する対象を、アプリケーションの実行に割り当てる、Ｊａｖａヒープサイズ、ＣＰＵ数、および同時実行数とする。Ｊａｖａヒープサイズはメモリサイズに相当する。
　ＪａｖａヒープサイズはＪａｖａヒープサイズ＝Ｎｅｗ＋Ｏｌｄにより算出する。Ｎｅｗは、Ｎｅｗ＝（Ｔ×ＭＴ×ｃｄ）＋（Ｔ×Ｒ×ＭＲ×２）であり、ＯｌｄはＯｌｄ＝（Ｔ×ＭＡ×ｆｄ）＋（Ｔ×ＭＡ×ＭＬ）＋αである。Ｔはスループットであり、Ｔ＝総処理件数（ＴＴ）÷アプリケーションのスケジュール時間と表される。スケジュール時間は、スケジュールされた実行時間であり、スケジュールに依存する。なお、運用要件にてスループットが指定されている場合には、その指定されたスループットの値をＴに用いる。ＭＴは、総メモリアロケート量である。ｃｄは、ＣｏｐｙＧＣ発生間隔であり、例えば１０秒といった通常値を用いることができる。Ｒは、実行時間である。ＭＲは、最大メモリ参照サイズである。ＭＡは、実行後参照メモリサイズである。ｆｄは、ｆｕｌｌＧＣ発生間隔である。運用要件に指定されたｆｄを用いればよい。運用要件にｆｄが指定されていない場合には、例えば３６００秒といった通常値を用いてもよい。また、ガベージコレクションが無い場合、ｆｄはアプリケーションのスケジュール時間と同じとなる。ＭＬは、最大メモリ参照寿命である。αは、アプリケーションが業務以外に使用する管理用のメモリ領域のサイズであり、例えば、１００ＭＢ程度を見込んでおけばよい。
　ＣＰＵ数は、ＣＰＵ数＝Ｃ×Ｔにより算出する。ＣはＣＰＵ時間である。
　同時実行数は、同時実行数＝Ｔ×（Ｒ－特徴点：その他の待ち時間）により算出する。特徴点情報である、その他待ち時間は、ＪａｖａＶＭにおける実行待ちキューでの待ち時間を指す。
　＜２＞バッチ処理のサイジング式の例
　バッチ処理のサイジング式の基本構成について説明する。ここでも、サイジング式により算出する対象を、アプリケーションの実行に割り当てる、Ｊａｖａヒープサイズ、ＣＰＵ数、および同時実行数とする。
　ＪａｖａヒープサイズはＪａｖａヒープサイズ＝Ｎｅｗ＋Ｏｌｄにより算出する。ここでは、Ｎｅｗは、Ｎｅｗ＝αであり、ＯｌｄはＯｌｄ＝（Ｔ×ＭＴ×ｆｄ）＋（Ｔ×Ｒ×ＭＲ）＋βである。αは、アプリケーションが業務以外に使用する管理用のメモリ領域のサイズであり、例えば５００ＭＢ程度を見込んでおけばよい。ＭＴは、＜１＞と同様、総メモリアロケート量である。ｆｄは、＜１＞と同様、ｆｕｌｌＧＣ発生間隔である。Ｒは、＜１＞と同様、実行時間である。ＭＲは、＜１＞と同様、最大メモリ参照サイズである。βは、アプリケーションが業務以外に使用する管理用のメモリ領域のサイズであり、例えば、１００ＭＢ程度を見込んでおけばよい。
　ＣＰＵ数は、＜１＞と同様、ＣＰＵ数＝Ｃ×Ｔにより算出する。Ｃは＜１＞と同様、ＣＰＵ時間である。
　同時実行数は、＜１＞と同様、同時実行数＝Ｔ×（Ｒ－特徴点：その他の待ち時間）により算出する。特徴点情報である、その他待ち時間は、やはり、ＪａｖａＶＭにおける実行待ちキューでの待ち時間を指す。
　以上説明したように、特徴点情報には、アプリケーションに割り当てるＣＰＵの個数を示すＣＰＵ数があり、＜１＞および＜２＞のいずれにおいても同様に、最適化実行部１５０は、アプリケーションのプロセスがＣＰＵを使用する時間であるＣＰＵ時間に応じてＣＰＵ数を決定する。アプリケーションのプロセスに要する時間が長ければＣＰＵ数を増やして、運用要件にて要求されるスループットを実現するといった運用が可能である。
　また、特徴点情報には、アプリケーションのプロセスを並行して実行可能な個数である同時実行数があり、＜１＞および＜２＞のいずれにおいても同様に、最適化実行部１５０は、アプリケーションのプロセスが実行された時間である実行時間から、実行待ちキューでの待ち時間を減算して得られた時間に応じて同時実行数を決定する。アプリケーションのプロセスに実際に要する時間が長ければ同時実行数を増やして運用要件にて要求されるスループットを実現することができる。
　図１３は、本実施形態における特徴点情報テーブルの一例を示す図である。
　図１３を参照すると、アプリケーション毎に、アプリケーションＩＤ（アプリＩＤ）、実行時間（Ｒ）、ＣＰＵ時間（Ｃ）、総メモリアロケート量（ＭＴ）、最大メモリ参照サイズ（ＭＲ）、最大メモリ参照寿命（ＭＬ）、実行後参照メモリサイズ（ＭＡ）、ＤＢアクセス時間、ファイルＩＯ時間、ＮＷＩＯ時間、排他待ち時間、スループット、その他待ち時間、ＧＣ占有率、Ｊａｖａヒープ確保サイズ、ＧＣ所要時間、ＧＣ後ヒープサイズ残量が記録されている。
　実行時間は、内部保留時間であり、クライアントから見たレスポンス時間からネットワークによる通信時間を引いた時間である。その他待ち時間は、ＪａｖａＶＭにおける実行待ちキューでの待ち時間を指し、実行時間から、ＣＰＵ時間、ＤＢアクセス時間、ファイルＩＯ時間、ＮＷＩＯ時間、排他待ち時間を除いた時間である。
　アプリケーションの実行時間の間に、累積的にメモリのアロケートが行われる。実行時間の間にアロケートされたメモリの総量が、総メモリアロケート量である。実行中のアプリケーションにアロケートされているメモリのうち、参照されなくなった部分（ゴミ）を除いた部分（アクティブなメモリ）のメモリサイズを最大メモリ参照サイズと呼ぶ。また、アプリケーションの実行が終わったときに参照される部分として残っていたメモリのメモリサイズを実行後参照メモリサイズと呼ぶ。また、実行後参照メモリサイズのメモリが残り続ける期間を最大メモリ参照寿命と呼ぶ。
　なお、図１３においては、図１４に示すアプリケーション特性の判定にて参照される値を〇（丸印）で示している。
　図１４は、本実施形態におけるアプリケーション特性テーブルの例を示す図である。
　図１４を参照すると、アプリケーション毎に、アプリケーションＩＤ、アプリケーション種別、ＣＰＵバウンド、ＤＢアクセスバウンド、ファイルＩＯバウンド、ＮＷＩＯバウンド、ＣＰＵコスト大、メモリコスト大、排他割合大、ＧＣ所要時間大、ＧＣ占有率大という項目の値が記録されている。ＣＰＵバウンド、ＤＢアクセスバウンド、ファイルＩＯバウンド、ＮＷＩＯバウンド、ＣＰＵコスト大、メモリコスト大、排他割合大、ＧＣ所要時間大、およびＧＣ占有率大には、該当することを「１」により示すフラグが記録される。アプリケーション種別としては、オンライン処理、オンバッチ処理、オフバッチ処理の種別が記録されている。
　図１５は、本実施形態における運用要件テーブルの例を示す図である。
　図１５を参照すると、アプリケーション毎に、アプリケーションＩＤ、総処理件数（ＴＴ）、スループット（Ｔ）、実行時間（Ｒ）、サービス時間帯（ＳＴ）、先行条件、フルＧＣ間隔（ＦＬ）、およびフルＧＣ時間（ＦＤ）が記録されている。先行条件は、当該アプリケーションを実行する前に完了している必要のあるアプリケーションが設定されている。先行条件の欄には、事前に完了している必要のあるアプリケーションのアプリケーションＩＤが記録されている。実行時間の欄に括弧で示された数値は、最悪値を表している。最悪値は、括弧なしで示されている通常の実行時間に加えて、フルＧＣが発生した場合にフルＧＣに要する時間（フルＧＣ時間（ＦＤ））を考慮した時間である。
　次に、運用ポリシの例について説明する。
　運用ポリシは、運用要件およびその他の条件に基づいてアプリケーション毎に設定される。その他の条件は例えば運用コストなどである。運用ポリシには、複数項目が指定された運用要件のうち、どの項目を優先させるかというような内容が設定される。図１６は、運用ポリシの例について説明するための図である。図１６の例では、４項目の運用要件が設定されている。要件（１）は、ピーク時のスループットが１万件という要件である。要件（２）は、実行時間が２秒以内という要件である。要件（３）は、データ検索対象件数が１０万件という要件である。また、要件（４）は、平均表示件数が、１リクエスト当たり３０件という要件である。
　図１６には２つの運用ポリシの例が示されている。最初の運用ポリシは、月末の繁忙期に適用することを想定した運用ポリシである。目的関数として、要件（２）を絶対条件とすることが設定されている。また、制約条件として、要件（１）、要件（３）、要件（４）、およびＧＣがないという条件が課されている。最適化処理において目的関数は制約条件よりも優先度が高い。２つ目の運用ポリシは、通常時に適用することを想定した運用ポリシである。目的関数として、運用コストを最小化することが設定されている。また、制約条件として、要件（２）の実行時間が２．６秒以内され、更に、要件（１）、要件（３）、要件（４）、およびＧＣを許容するという条件が設定されている。
　図１６に示したように、運用ポリシには、コストに関する指定項目と性能に関する指定項目を含む複数の指定項目に優先度の重みづけが可能である。例えば、運用コスト最小化というのはコストに関する指定項目である。一方、要件（２）の実行時間など運用要件には性能に関する指定項目が含まれている。コスト優先あるいは性能優先など指定項目に優先度をつけて業務システムを適切に運用することができる。
　また、図１６に示したように、同じ運用要件から複数の異なる運用ポリシを設定することができ、また複数の運用ポリシを時期により切り替えて適用することが可能である。
　次にスケジュールの例について説明する。スケジューリング処理の結果であるスケジュールがスケジューリング結果テーブルに記録される。スケジューリング処理に適用した運用ポリシが異なれば、同じ運用要件、リソース制約、アプリケーションに対して得られえるスケジュールも異なる。
　図１７は、本実施形態におけるスケジューリング結果テーブルの例を示す図である。
　図１７には、運用ポリシがコスト優先の場合と、運用ポリシが性能優先の場合のそれぞれのスケジューリング結果テーブルが対比可能に示されている。スケジューリング結果テーブルには、当該アプリケーションのアプリケーションＩＤ、当該アプリケーションが利用可能なＣＰＵ数およびメモリサイズ、当該アプリケーションに許容されるプロセス数および同時実行数、当該アプリケーションを実行する実行期間、開始時刻および終了時刻が示されている。スケジューリングの結果は、各アプリケーションの開始時刻および終了時刻に表されている。テーブルを対比すると分かるように、複数のアプリケーションによる全体業務が終了する時刻が、コスト優先の場合には翌日の１：００となっているのに対して、性能優先の場合には２２：００と早まっている。
　図１８は、本実施形態によるスケジューリング結果の第１例について説明するための図である。第１例としてコスト優先のスケジューリング結果のタイムチャートが示されている。これは図１７の上段に示したスケジューリング結果テーブルに対応する。
　図１９は、本実施形態によるスケジューリング結果の第２例について説明するための図である。第２例として性能優先のスケジューリング結果のタイムチャートが示されている。これは図１７の下段に示したスケジューリング結果テーブルに対応する。
　図１８と図１９を対比すると、図１８のスケジュールよりも図１９のスケジュールの方がＣＰＵおよびメモリを多く使用するが、全体業務の終了時刻が早くなっていることが分かる。
　運用管理システム１００は、スケジューリング結果を図１８や図１９に示したように画面に視覚的に表示することにしてもよい。それにより、オペレータはスケジューリング結果を視覚により容易に理解し、把握することが可能となる。
　図２０は、本実施形態における運用改善候補の例を示す図である。
　運用改善候補探索部１６１により得られた運用要改善候補は運用改善候補出力部１７３から出力される。運用改善候補出力部１７３は、運用改善候補探索部１６１が図９および図１０に示した改善候補探索処理を実行することにより抽出された運用改善候補を出力する。図２０を参照すると、運用改善の対象となるアプリケーションのアプリケーションＩＤと、提示する運用改善候補の内容とが対応付けて示されている。その際、運用改善候補出力部１７３は、例えば運用改善候補の一覧を画面に表示してもよいし、運用改善候補の一覧情報をファイルに出力してもよい。
　次に、特徴点情報に基づくスケジューリングの一例について説明する。ここではガベージコレクションを考慮したスケジューリングについて説明する。
　図２１は、本実施形態におけるサイジング処理およびスケジューリング処理の様子を説明するための図である。図２１には、特徴点情報テーブルとスケジューリング結果テーブルが示されている。特徴点情報テーブルにて太線の四角形で囲われた部分の情報が、その四角形と矢印で結ばれた、スケジューリング結果テーブルにて楕円で囲われた部分の情報の生成に利用される。
　図２１においてアプリケーションＩＤ＝０００１のアプリケーションに着目すると、特徴点情報テーブルのスループット、その他待ち時間、ＧＣ占有率、およびＪａｖａヒープ確保サイズの情報が、スケジューリング結果テーブルのメモリサイズを決めるのに用いられていることが分かる。具体的には、ＧＣ占有率が高いことを考慮してＪａｖａヒープ確保サイズを拡大するために、メモリサイズを１０ＧＢから１２ＧＢに拡大している。
　このように、本例では、特徴点情報としてガベージコレクションのＧＣ占有率があり、最適化実行部１５０は、ガベージコレクションのＧＣ占有率に基づいてアプリケーションに割り当てるメモリのサイズを決定している。ここでＧＣ占有率とは、ＧＣの処理時間（アプリケーションの実行が停止する時間と同じ）が、単位時間あたりに占める割合を示す。一般にＧＣによるオーバヘッドに起因してアプリケーションのスループットやレスポンスといった性能が劣化する。しかし、本例の上記構成によれば、ＧＣによるオーバヘッドの指標としてＧＣ占有率を算出し、その値に基づいてアプリケーションに割り当てるメモリのサイズを決定するので、ＧＣによる性能劣化を考慮しても運用要件を満たすようなサイジングおよびスケジューリングを行うことができる。
　また、アプリケーションＩＤ＝０００２で示されたアプリケーションに着目すると、特徴点情報テーブルにおけるＧＣ所要時間とＧＣ後Ｊａｖａヒープサイズ残量との情報が、スケジューリング結果テーブルのメモリサイズ、プロセス数、および同時実行数を決めるのに用いられていることが分かる。具体的には、ＧＣ所要時間が長いため、アプリケーションをプロセスに分割してプロセス数を１から３に増やしていることが分かる。
　このように、本例では、特徴点情報としてガベージコレクションの所要時間があり、最適化実行部１５０は、ガベージコレクションの所要時間に応じて、アプリケーションのプロセス数を決定している。本例の上記構成によれば、ＧＣによるオーバヘッドの指標としてＧＣの所要時間を算出し、その値に基づいてアプリケーションのプロセス数を決定するので、ＧＣによる性能劣化を考慮して運用要件を満たすようなサイジングおよびスケジューリングを行うことができる。
　以上説明したように、本実施形態によれば、アプリケーション稼働環境２００は、リソースとしてメモリを有し、最適化実行部１５０は、メモリの割り当てについて、アプリケーション特性に基づいて、メモリをどのような領域の構成とするか決定し、特徴点情報に基づいて各領域のサイズを決定する。アプリケーションの定量的性質に基づいてメモリの領域構成を決定し、定量的性質に基づいて各領域のサイズを決定するので、好適な領域構成および領域サイズを有するメモリをアプリケーションに提供することができる。
　なお、上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。
１００…運用管理システム、１１０…稼働情報取得部、１２０…稼働情報編集部、１２１…特徴点抽出部、１２２…運用結果抽出部、１２３…スケジュール結果抽出部、１３０…特徴点解析部、１３１…アプリケーション特性判定部、１４０…入力部、１４１…運用要件入力部、１４２…運用ポリシ入力部、１４３…スケジュール入力部、１５０…最適化実行部、１５１…サイジング計画部、１５２…スケジュール決定部、１５３…再スケジュール部、１６０…運用改善候補提示部、１６１…運用改善候補探索部、１７０…出力部、１７１…サイジング出力部、１７２…スケジュール出力部、１７３…運用改善候補出力部、２００…アプリケーション稼働環境、２１０…稼働情報取得部、３１０…運用要件、３２０…運用ポリシ、３３０…スケジュール、３４０…サイジング情報、３５０…スケジュール、３６０…運用改善候補、３７０…アプリケーション、３８０…稼働情報

Claims (16)

  1. 　アプリケーションの実行に利用するリソースを定めた第１リソース割り当ておよびリソースをアプリケーションの実行に利用する時間帯を定めた第１スケジュールに従って計算機にて実行されたアプリケーションの履歴を記録した稼働情報を与えられ、前記稼働情報に基づいて、前記アプリケーションの所定の定量的性質を表す特徴点情報を生成する稼働情報編集部と、
    　前記特徴点情報に基づいて、前記アプリケーションの所定の定性的性質を表すアプリケーション特性を判定するアプリケーション特性判定部と、
    　前記アプリケーションに関連して要求される性能を指定した運用要件と、前記計算機にて利用可能なリソースの制約を示すリソース制約と、前記計算機の運用の指針を示す運用ポリシとを与えられ、前記アプリケーションの前記特徴点情報および前記アプリケーション特性に基づいて、前記運用要件および前記リソース制約を満たし、前記運用ポリシに示された指針に従うように、前記計算機にて利用する第２リソース割り当ておよび第２スケジュールを算出する最適化実行部と、
    を有する計算機運用管理システム。
  2. 　前記アプリケーション特性に基づき、前記アプリケーションまたは前記計算機の変更を伴う運用改善策を提案する運用改善候補探索部を更に有する、請求項１に記載の計算機運用管理システム。
  3. 　前記第２リソース割り当ておよび前記第２スケジュールを前記計算機に適用し、前記運用改善策を、前記計算機を運用する運用者に提示する出力部を更に有する、請求項２に記載の計算機運用管理システム。
  4. 　前記計算機は、前記リソースとしてメモリおよびＣＰＵを有し、
    　前記稼働情報編集部は、前記特徴点情報として少なくとも、前記アプリケーションの所定の実行単位ごとに割り当てるメモリ領域の総量である総メモリアロケート量と、前記実行単位を実行するのに前記ＣＰＵが稼働した時間であるＣＰＵ時間と、前記実行単位を実行するのに要した時間である実行時間と、を生成する、
    請求項１に記載の計算機運用管理システム。
  5. 　前記アプリケーション特性判定部は、前記アプリケーション特性として、オンライン処理か否かを含むアプリケーション種別を前記実行時間に基づいて判定し、前記アプリケーション種別がオンラインであれば、メモリコストを前記総メモリアロケート量に基づいて判定し、ＣＰＵコストを前記ＣＰＵ時間に基づいて判定する、請求項４に記載の計算機運用管理システム。
  6. 　前記最適化実行部は、前記アプリケーション種別に応じて前記第２リソース割り当てを算出する算出式を選択する、
    請求項５に記載の計算機運用管理システム。
  7. 　前記運用ポリシは、コストに関する指定項目と性能に関する指定項目を含む複数の指定項目に優先度の重みづけが可能である、請求項１に記載の計算機運用管理システム。
  8. 　前記計算機は、前記リソースとしてメモリを有し、
    　前記最適化実行部は、前記メモリの割り当てについて、前記アプリケーション特性に基づいて、前記メモリをどのような領域の構成とするか決定し、前記特徴点情報に基づいて前記各領域のサイズを決定する、請求項１に記載の計算機運用管理システム。
  9. 　前記特徴点情報としてガベージコレクションのメモリ占有率があり、
    　前記最適化実行部は、前記ガベージコレクションのメモリ占有率に基づいて前記アプリケーションに割り当てるメモリのサイズを決定する、
    請求項１に記載の計算機運用管理システム。
  10. 　前記特徴点情報として前記ガベージコレクションの所要時間があり、
    　前記最適化実行部は、前記ガベージコレクションの所要時間に応じて、前記アプリケーションのプロセス数を決定する、
    請求項１に記載の計算機運用管理システム。
  11. 　前記特徴点情報には、前記アプリケーションに割り当てるＣＰＵの個数を示すＣＰＵ数があり、
    　前記最適化実行部は、前記アプリケーションのプロセスがＣＰＵを使用する時間であるＣＰＵ時間に応じて前記ＣＰＵ数を決定する、
    請求項１に記載の計算機運用管理システム。
  12. 　前記特徴点情報には、前記アプリケーションのプロセスを並行して実行可能な個数である同時実行数があり、
    　前記最適化実行部は、前記アプリケーションのプロセスが実行された時間である実行時間から、実行待ちキューでの待ち時間を減算して得られた時間に応じて前記同時実行数を決定する、
    請求項１に記載の計算機運用管理システム。
  13. 　前記リソース制約は、前記計算機のハードウェア構成によるＣＰＵ数およびメモリ容量の制限を含み、
    　前記運用改善候補探索部は、前記計算機のＣＰＵまたはメモリを追加または削除する運用改善策を提案する、
    請求項２に記載の計算機運用管理システム。
  14. 　前記最適化実行部は、前記第２リソース割り当てとして、前記アプリケーションに割り当てるＣＰＵ、メモリ領域、およびプロセスの同時実行数を算出する、請求項１に記載の計算機運用管理システム。
  15. 　前記最適化実行部は、前記第２スケジュールとして、前記アプリケーションの開始時刻および終了時刻と利用するリソースとを算出する、請求項１に記載の計算機運用管理装置。
  16. 　アプリケーションの実行に利用するリソースを定めた第１リソース割り当ておよびリソースをアプリケーションの実行に利用する時間帯を定めた第１スケジュールに従って計算機にて実行されたアプリケーションの履歴を記録した稼働情報を与えられ、前記稼働情報に基づいて、前記アプリケーションの所定の定量的性質を表す特徴点情報を生成し、
    　前記特徴点情報に基づいて、前記アプリケーションの所定の定性的性質を表すアプリケーション特性を判定し、
    　前記アプリケーションに関連して要求される性能を指定した運用要件と、前記計算機にて利用可能なリソースの制約を示すリソース制約と、前記計算機の運用の指針を示す運用ポリシとを与えられ、前記アプリケーションの前記特徴点情報および前記アプリケーション特性に基づいて、前記運用要件および前記リソース制約を満たし、前記運用ポリシに示された指針に従うように、前記計算機にて利用する第２リソース割り当ておよび第２スケジュールを算出する、
    計算機運用管理方法。
PCT/JP2017/029058 2017-08-10 2017-08-10 計算機運用管理システムおよび方法 WO2019030889A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2018567962A JP6681484B2 (ja) 2017-08-10 2017-08-10 計算機運用管理システムおよび方法
PCT/JP2017/029058 WO2019030889A1 (ja) 2017-08-10 2017-08-10 計算機運用管理システムおよび方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/029058 WO2019030889A1 (ja) 2017-08-10 2017-08-10 計算機運用管理システムおよび方法

Publications (1)

Publication Number Publication Date
WO2019030889A1 true WO2019030889A1 (ja) 2019-02-14

Family

ID=65270975

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/029058 WO2019030889A1 (ja) 2017-08-10 2017-08-10 計算機運用管理システムおよび方法

Country Status (2)

Country Link
JP (1) JP6681484B2 (ja)
WO (1) WO2019030889A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014038458A (ja) * 2012-08-15 2014-02-27 Toshiba Corp スケジューリング装置、システム、方法およびプログラム
JP2015532992A (ja) * 2012-09-20 2015-11-16 アマゾン テクノロジーズ インコーポレーテッド リソース使用の自動プロファイル化

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014038458A (ja) * 2012-08-15 2014-02-27 Toshiba Corp スケジューリング装置、システム、方法およびプログラム
JP2015532992A (ja) * 2012-09-20 2015-11-16 アマゾン テクノロジーズ インコーポレーテッド リソース使用の自動プロファイル化

Also Published As

Publication number Publication date
JP6681484B2 (ja) 2020-04-15
JPWO2019030889A1 (ja) 2019-11-07

Similar Documents

Publication Publication Date Title
US10402225B2 (en) Tuning resources based on queuing network model
JP6447120B2 (ja) ジョブスケジューリング方法、データアナライザ、データ解析装置、コンピュータシステム及びコンピュータ可読媒体
Yan et al. Tr-spark: Transient computing for big data analytics
US10101991B2 (en) Managing a software-patch submission queue
JP5773554B2 (ja) タスク管理方法及びタスク管理装置
US9280391B2 (en) Systems and methods for improving performance of computer systems
CN106874084B (zh) 一种分布式工作流调度的方法、装置及计算机设备
US6631354B1 (en) Deriving and running workload manager enclaves from workflows
EP3267311B1 (en) System, controller, method, and program for executing simulation jobs
US20110154353A1 (en) Demand-Driven Workload Scheduling Optimization on Shared Computing Resources
CN110806933B (zh) 一种批量任务处理方法、装置、设备和存储介质
Chard et al. Cost-aware cloud provisioning
JP2012252422A (ja) 予測プログラム、予測装置および予測方法
US9329969B2 (en) Method and system of associating a runtime event with a component
KR101770191B1 (ko) 자원 할당 방법 및 그 장치
KR20140117905A (ko) 클라우드 서비스의 가상자원 할당을 위한 퍼지 로직 기반의 자원평가 장치 및 방법
Kumar et al. Identifying quick starters: towards an integrated framework for efficient predictions of queue waiting times of batch parallel jobs
US20040024673A1 (en) Method for optimizing the allocation of resources based on market and technology considerations
Moreira et al. Towards improvements on the quality of service for multi-tenant RDBMS in the cloud
JP6681484B2 (ja) 計算機運用管理システムおよび方法
US10067804B2 (en) Apparatus, method, and non-transitory computer-readable storage medium for storing program for performance requirement estimation
Kuehn et al. Predicting resource usage for enhanced job scheduling for opportunistic resources in HEP
Hermenier et al. Hotspot Mitigations for the Masses
JP2006040189A (ja) 人員選択装置およびその方法
CN117290185A (zh) 数据库检查点的监测方法、存储介质与设备

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2018567962

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17921363

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17921363

Country of ref document: EP

Kind code of ref document: A1