WO2016017161A1 - 仮想計算機システム、スケジューリング方法、および、プログラム記憶媒体 - Google Patents

仮想計算機システム、スケジューリング方法、および、プログラム記憶媒体 Download PDF

Info

Publication number
WO2016017161A1
WO2016017161A1 PCT/JP2015/003798 JP2015003798W WO2016017161A1 WO 2016017161 A1 WO2016017161 A1 WO 2016017161A1 JP 2015003798 W JP2015003798 W JP 2015003798W WO 2016017161 A1 WO2016017161 A1 WO 2016017161A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
priority
thread
hypervisor
identifier
Prior art date
Application number
PCT/JP2015/003798
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 日本電気株式会社
Publication of WO2016017161A1 publication Critical patent/WO2016017161A1/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
    • 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/48—Program initiating; Program switching, e.g. by interrupt
    • 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 virtual machine system, a scheduling method, a program, and a program storage medium.
  • the present invention relates to a virtual computer system including a virtual computer constructed in a physical computer, a scheduling method in the virtual computer system, a program, and a program storage medium.
  • the virtual computer system is a system in which a plurality of virtual computers are built on one physical computer.
  • an OS called a “guest OS (Operating System)” operates in each virtual machine.
  • an OS operating on a physical computer is referred to as a “virtual machine monitor (VMM: Virtual Machine Monitor)”.
  • the guest OS manages applications that run on the guest OS in the same way as a normal OS.
  • the VMM manages the virtual machine as its own application.
  • the resource that the guest OS gives to the application under management is called “virtual CPU (Central Processing Unit)”.
  • the virtual CPU is a pseudo CPU created by a software program and operates as a thread of a physical computer.
  • the resource that the VMM gives to the virtual machine is called “physical CPU”.
  • the VMM may not assign a physical CPU to the virtual machine. In this case, the application cannot be executed. Conversely, even if the VMM assigns a physical CPU to a virtual machine, the guest OS may not assign a virtual CPU to an application. In this case, the CPU time of the allocated physical CPU is wasted.
  • FIG. 16 is a block diagram illustrating the configuration of the virtual machine system described in Patent Document 1.
  • the virtual computer system 1 includes a physical computer 2.
  • the physical computer 2 includes a virtual computer 5, a VMM 3, and hardware 4.
  • the virtual machine 5 includes a guest OS 6.
  • the VMM 3 includes a guest OS interface unit 7, a guest OS dependency creation module 8, a guest OS dependency table 9, a dispatcher 10, a CPU allocation table 11, and a guest OS scheduler 12.
  • the hardware 4 includes a CPU 13.
  • the guest OS scheduler 12 includes a CPU allocation table management unit 14, a determination unit 15, a server guest OS schedule unit 16, a client guest OS search unit 17, and a client guest OS schedule unit 18.
  • the virtual computer system shown in FIG. 16 operates as follows. That is, the guest OS interface unit 7 of the VMM 3 includes an interface that notifies the following when an arbitrary guest OS functioning as a client of the guest OS 6 requests processing from another guest OS functioning as a server. That is, the guest OS interface unit 7 has an interface for notifying the VMM 3 of a server / client relationship in which the guest OS that is the request source of the process is a client and the guest OS that is the request destination of the process is a server. Including.
  • the guest OS scheduler 12 of the VMM 3 adjusts the time for allocating the CPU to the guest OS 6 based on the server / client relationship notified by this interface.
  • an application can be executed by simultaneously assigning a virtual CPU and a physical CPU.
  • the guest OS does not necessarily have one virtual CPU.
  • the number of physical CPUs possessed by the VMM is not limited to one. In other words, if there is a virtual CPU assigned to the application by the guest OS and a physical CPU is not assigned to a thread that embodies the assigned virtual CPU in the VMM, the application does not operate.
  • a percentage of the physical CPU usage rate is given to the guest OS, and it is possible to determine which virtual CPU (thread) can be assigned a physical CPU. Can not.
  • a virtual computer holds four virtual CPUs 1 to 4.
  • the threads on the VMM that embody the virtual CPUs 1 to 4 are referred to as threads 1 to 4, respectively.
  • the virtual CPU 1 is assigned to the application.
  • the thread to which the VMM should allocate a physical CPU is thread 1.
  • the VMM does not have a function of allocating a physical CPU to the thread 1 when the virtual CPU 1 is allocated to an application.
  • each of a virtual machine serving as a client and a virtual machine serving as a server registers a relationship with the VMM. That is, the client designates a virtual machine that becomes a server, and the server designates a virtual machine that becomes a client. Thereby, the relationship between the client and the server is built in the VMM, and the physical CPU time required for each virtual machine is adjusted. However, it is not considered whether the client and server actually exchange requests. Therefore, there is a possibility that physical CPU time is allocated even when the client and the server are not transmitting and receiving requests.
  • An object of the present invention is to provide a virtual computer system, a scheduling method, and a program storage medium that contribute to solving such a problem.
  • the virtual computer system includes a guest OS (Operating System) and a hypervisor, and the guest OS stores a storage unit that stores received requests, and an unprocessed storage stored in the storage unit When the number of requests exceeds a predetermined number, or when the retention period of unprocessed requests accumulated in the storage unit exceeds a predetermined period, an application that processes the unprocessed requests is executed.
  • a changing unit for changing the execution time of the physical CPU.
  • a guest OS (Operating System) stores accepted requests in a storage unit, and the number of unprocessed requests stored in the storage unit exceeds a predetermined number. If the retention period of the unprocessed requests accumulated in the storage unit exceeds a predetermined period, the identifier of the virtual CPU (Central Processing Unit) that executes the application that processes the unprocessed requests is set. A hypervisor call is issued to the hypervisor, and the hypervisor changes the execution time of the physical CPU assigned to the thread that realizes the virtual CPU corresponding to the identifier.
  • the virtual CPU Central Processing Unit
  • a program storage medium in which a guest OS (Operating System) stores a received request in a storage unit and a number of unprocessed requests stored in the storage unit is predetermined.
  • Virtual CPU Central Processing Unit
  • a computer program to be executed by a computer is stored.
  • the program storage medium may be provided as a non-transitory computer-readable storage medium.
  • the scheduling method, and the program storage medium according to the present invention it is possible to quickly process a request with a large number of stays or a request with a long stay period in the virtual computer system.
  • SIP Session * Initiation * Protocol
  • FIG. 2 is a block diagram illustrating a configuration of a virtual computer system described in Patent Document 1.
  • FIG. It is a figure which shows an example of the hardware constitutions which implement
  • FIG. 1 is a block diagram illustrating the configuration of a virtual machine system according to an embodiment.
  • the virtual machine system includes a guest OS (Operating System) 20 and a hypervisor 30.
  • the guest OS 20 has a request unit 22 that issues a hypervisor call including an identifier of a virtual CPU (Central Processing Unit) to the hypervisor 30.
  • the hypervisor 30 includes a changing unit 32 that changes the execution time of the physical CPU assigned to the thread that realizes the virtual CPU corresponding to the identifier.
  • the guest OS 20 issues a hypervisor call by designating a virtual CPU on which an application for processing a request arriving at a virtual machine running the guest OS 20 is executed, and the hypervisor is a thread that realizes the designated virtual CPU. This is because the execution time of the physical CPU can be changed.
  • the guest OS 100 includes a first queue (scheduling queue 170) that holds the application that processes the received request and the identifier of the virtual CPU that executes the application in association with each other.
  • the request unit 120 may specify the identifier of the virtual CPU that executes the application with reference to the first queue (170), and may issue a hypervisor call including the identifier of the specified virtual CPU.
  • the guest OS 100 includes a storage unit (staying request storage unit 150) that accumulates received requests.
  • a storage unit (staying request storage unit 150) that accumulates received requests.
  • the request unit 120 may issue a hypervisor call including an identifier of a virtual CPU that executes an application that processes an unprocessed request.
  • a physical CPU is preferentially assigned to a thread corresponding to a virtual CPU that executes an application that processes the request. Execution time can be assigned. Therefore, it is possible to quickly process a staying request or a request having a long staying period.
  • the hypervisor 200 includes a second queue (scheduling queue 240) that holds the threads classified according to priority and the physical CPU that executes the threads according to the priority in association with each other. .
  • the changing unit executes the execution time of the thread. In other cases, the changing unit (220) may change the priority of the thread in the second queue (240) and / or the order of the thread in the second queue (240).
  • the execution time can be extended. If the application is not being executed, the execution can be started by the physical CPU immediately after the currently executing application is terminated.
  • the guest OS 100 includes a priority calculation unit 180 that calculates the priority of the received request.
  • the request unit 120 is an identifier of a virtual CPU that executes an application that processes an unprocessed request when the priority of an unprocessed request accumulated in the storage unit (the stay request storage unit 150) exceeds a predetermined priority.
  • a hypervisor call including the above may be issued.
  • the hypervisor 200 includes a warning unit (limit load warning unit 270) that outputs a warning when the frequency of hypervisor calls issued by the request unit (request unit 120) exceeds a predetermined frequency. You may have.
  • a warning unit limit load warning unit 270
  • FIG. 2 is a block diagram illustrating the configuration of the virtual machine system of this embodiment.
  • the virtual machine system of this embodiment includes a virtual machine 300 and a hypervisor 200.
  • the virtual machine 300 includes a guest OS (Operating System) 100.
  • the guest OS 100 includes a UDP (User Datagram Protocol) packet transmission / reception unit 110, a SIP (Session Initiation Protocol) processing amplification determination unit 140, a thread activation unit 160, a retention amount acquisition unit 130, a retention request storage unit 150, a request unit 120, and A scheduling queue 170 is provided.
  • the hypervisor 200 includes a receiving unit 210, an execution time changing unit 220, a scheduler 230, and a scheduling queue 240.
  • the UDP packet transmission / reception unit 110 transmits / receives a UDP packet within the guest OS 100.
  • the UDP packet transmission / reception unit 110 creates a stay request identifier 151 from the SIP request and stores the stay request identifier 151 in the stay request storage unit 150.
  • the UDP packet transmitting / receiving unit 110 executes the SIP processing amplification determination unit 140 after storing the stay request identifier 151. Further, when the UDP packet transmitting / receiving unit 110 encapsulates the SIP request in a UDP packet and transmits it to another physical computer, since the SIP request has been processed, the stay request identifier 151 matches from the stay request storage unit 150. Delete the entry.
  • the SIP processing amplification determination unit 140 acquires the request retention amount calculated by the retention amount acquisition unit 130 and determines whether to issue a scheduling policy change request to the hypervisor 200.
  • the SIP processing amplification determination unit 140 issues a scheduling policy change request when the number of staying requests exceeds a predetermined number.
  • the predetermined number is set in advance by the user.
  • the SIP processing amplification determination unit 140 issues a scheduling policy change request when the stay period of a stay request exceeds a predetermined period. The predetermined period is set in advance by the user.
  • T1 which is the default timeout time of SIP is used as the predetermined period
  • T1 is the time when retransmission of the SIP request is started, and the default value is 500 ms.
  • the value of T1 can be changed, and the current value of T1 is stored in the setting file of the SIP server (application in the virtual machine 300).
  • the SIP process amplification determination unit 140 confirms the current value of T1 in advance from the setting file of the SIP server before starting the process.
  • the thread activation unit 160 activates a thread.
  • the application includes a plurality of threads. Specifically, when a UDP packet arrives, the thread activation unit 160 activates a thread that processes the UDP packet.
  • the stay amount acquisition unit 130 counts the number of stay requests stored in the stay request storage unit 150 and notifies the SIP processing amplification determination unit 140 of the count. In addition, the stay amount acquisition unit 130 updates the period during which the stay request stored in the stay request storage unit 150 stays in the guest OS 100. The stay amount acquisition unit 130 is periodically started by a timer or the like, and increments the stay period 152 of the stay request stored in the stay request storage unit 150.
  • the stay request storage unit 150 stores information regarding requests currently staying in the virtual machine 300.
  • FIG. 3 illustrates the contents of the table held by the stay request storage unit 150.
  • the stay request storage unit 150 holds the stay request identifier 151 and the stay period 152 in association with each other.
  • the UDP packet transmission / reception unit 110 generates a stay request identifier 151.
  • FIG. 4 illustrates the data structure of the SIP request.
  • the UDP packet transmission / reception unit 110 generates a stay request identifier 151 using “Call-ID” and “CSeq” shown in FIG.
  • the UDP packet transmission / reception unit 110 sets Call-ID and CSeq connected by an underbar as a stay request identifier 151 (FIG. 3).
  • the stay request identifier 151 is not limited to the aspect shown in FIG.
  • the UDP packet transmission / reception unit 110 deletes the entry having the same retention request identifier 151 from the retention request storage unit 150.
  • the request unit 120 requests the hypervisor 200 to extend the execution time given to the thread that implements the virtual CPU.
  • the request unit 120 does not know the thread number that is paired with the virtual CPU number when issuing the scheduling policy change request. Therefore, the request unit 120 issues a hypervisor call with the virtual CPU number as an argument.
  • the hypervisor 200 holds a table that is a pair of a virtual CPU number and a thread number.
  • the hypervisor call is provided in hardware used for the virtual machine 300 to voluntarily request “some processing” from the hypervisor 200, similar to a system call (System call) of a general OS. It is a function. In the present embodiment, the virtual machine 300 requests the hypervisor 200 to change the scheduling policy as an example of “some processing”.
  • the scheduling queue 170 is a data structure that manages CPU allocation of applications executed on the virtual machine 300.
  • FIG. 5 illustrates the data structure of the scheduling queue 170.
  • a scheduling queue 170 is created for each CPU included in the computer.
  • the data structure of the scheduling queue 170 of the virtual machine 300 and the data structure of the scheduling queue 240 of the hypervisor 200 are the same.
  • the CPU in FIG. 5 represents a virtual CPU.
  • the CPU of FIG. 5 represents a physical CPU.
  • an application waiting for execution (“Process” in FIG. 5) is registered.
  • the scheduler 230 selects an application to be executed next from the scheduling queue 170.
  • the queue is divided for each priority 153. If the priority 153 having a small number is set as the high priority, the scheduler 230 first selects Process A.
  • the request unit 120 uses the scheduling queue 170 to confirm in which virtual CPU the SIP application that processes the arrived SIP request is scheduled to be executed.
  • the SIP application (“SIPSProcess” in FIG. 5) is registered in CPU # 1.
  • the SIP processing amplification determination unit 140 calls the request unit 120 using the CPU # 1 as an argument.
  • the accepting unit 210 accepts the scheduling policy change request sent from the requesting unit 120.
  • the receiving unit 210 converts the sent virtual CPU number into a thread number, and calls the execution time changing unit 220 in order to extend the CPU time given to the thread having the thread number.
  • the execution time changing unit 220 extends the CPU time given to the thread.
  • the scheduler 230 provided in the guest OS 100 or the hypervisor 200 executes the thread selected from the scheduling queue 170 by the CPU.
  • the scheduler 230 gives execution time to the thread at the start of execution of the thread.
  • the scheduler 230 advances its processing using the CPU until the given execution time elapses.
  • the scheduler 230 selects the next thread from the scheduling queue 170 and gives the CPU time.
  • the thread that has consumed the given execution time is stored in the scheduling queue 170 by the scheduler 230.
  • the scheduler 230 manages the execution time.
  • the execution time changing unit 220 extends the execution time when the thread of the hypervisor 200 that implements the virtual CPU is being executed.
  • the scheduler 230 appropriately executes threads registered in the scheduling queue 240 by the CPU. When executing a thread, execution time is assigned to the thread as described above. The thread can proceed with processing for a given execution time.
  • the scheduler 230 manages the execution time of the currently executing thread.
  • the execution time changing unit 220 changes the execution time managed by the scheduler 230.
  • the virtual computer system confirms the request amount that has already stayed, and if the staying request exceeds a certain threshold, Extends the physical CPU time allocated to the virtual CPU that is processing the SIP request. Thereby, sufficient physical CPU time for request processing is obtained.
  • the UDP packet transmitting / receiving unit 110 receives a UDP packet (step S1).
  • the UDP packet transmitting / receiving unit 110 extracts the SIP header from the UDP packet (step S2).
  • the UDP packet transmission / reception unit 110 creates a stay request identifier 151 when extracting the SIP header.
  • the SIP processing amplification determination unit 140 refers to the stay request storage unit 150 and confirms the current request stay amount (step S3).
  • the SIP processing amplification determination unit 140 obtains the request retention amount by counting the number of entries in the retention request storage unit 150 via the retention amount acquisition unit 130.
  • Step S4 When the SIP processing amplification determination unit 140 determines that the request retention amount exceeds the threshold (Yes in Step S4), the request unit 120 acquires the virtual CPU number on which the SIP server is executed (Step S5), and A hypervisor call is issued with the virtual CPU number as an argument (step S6).
  • the accepting unit 210 receives the hypervisor call and extends the execution time of the thread corresponding to the virtual CPU included in the hypervisor call (step S7).
  • the SIP processing amplification determination unit 140 registers the arrived SIP request in the stay request storage unit 150. Specifically, the SIP processing amplification determination unit 140 creates an entry in which the first created stay request identifier 151 and the stay period 152 are paired, and adds the entry to the stay request storage unit 150 (step S8). . The SIP processing amplification determination unit 140 sets the residence period 152 to zero at the time of entry addition. The staying amount acquisition unit 130 periodically increments the staying period 152.
  • Step S8 when the request retention amount is equal to or less than the threshold (No in Step S4), only Step S8 is executed and the process is terminated.
  • a virtual CPU that requires a physical CPU can be identified and a physical CPU can be allocated. The reason is that the virtual machine scheduling queue is checked and the hypervisor is informed on which virtual CPU an incoming request is executed.
  • a physical CPU for request processing can be sufficiently allocated to a request staying in a server (corresponding to an application in the background art).
  • the virtual computer system of this embodiment has the following configuration. That is, the virtual computer system of this embodiment monitors the number of requests that have arrived at the server and the number of requests that have been processed at the server and returned to the client, and stores the difference as a stay request. If the staying request exceeds a certain threshold, the virtual machine system extends the physical CPU time allocated to the virtual CPU that is processing the SIP request.
  • FIG. 7 is a block diagram illustrating the configuration of the virtual machine system according to this embodiment.
  • the virtual machine system of the present embodiment further includes an execution priority changing unit 250 and an execution queue rearranging unit 260 in addition to the hypervisor 200 of the virtual machine system (FIG. 2) of the first embodiment. I have.
  • the execution priority changing unit 250 changes the priority 153 of the thread registered in the scheduling queue 240.
  • the scheduling queue 240 has the same configuration as the scheduling queue 170 described with reference to FIG. 5 in the first embodiment. Referring to FIG. 5, the scheduling queue 240 holds an array divided for each priority 153, and an application that requests CPU time (denoted as Process in FIG. 5) is registered in the array. Yes.
  • “changing the execution priority” means that an application is moved from one priority 153 array to another priority 153 array.
  • SIP Process is registered in the priority 2 array.
  • SIP Process is registered in an array of priority 0.
  • the execution priority changing unit 250 changes the priority 153 of the application to, for example, the highest priority 153 (priority 0 in the case of FIG. 5). However, the execution priority changing unit 250 may accept designation of the priority of the change destination from the user.
  • the execution queue rearrangement unit 260 changes the order of the threads in the thread array registered in the scheduling queue 240.
  • the scheduling queue 240 divides and holds the thread array for each priority 153.
  • an application requesting CPU time (“Process” in FIG. 5) is registered.
  • “Reordering the execution queue” means rearranging the order of the threads included in the array divided for each priority 153.
  • SIP ⁇ Process is placed behind Process D.
  • the scheduler 230 first selects Process D as the application.
  • the execution queue rearrangement unit 260 arranges the target application at the top of the array.
  • the execution queue rearrangement unit 260 changes the order of SIP Process and Process D.
  • the execution time changing unit 220 changes the execution time of the thread corresponding to the sent virtual CPU.
  • the execution time changing unit 220 even when the corresponding thread is waiting to be executed and is registered in the scheduling queue 240, it is possible to assign an execution time to the SIP server immediately after the currently executing application is terminated. Become.
  • the request unit 120 issues a hypervisor call (step S6).
  • the accepting unit 210 confirms whether or not the thread corresponding to the virtual CPU notified in the hypervisor call is being executed (step S9). If the thread is being executed (Yes in step S10), the execution time changing unit 220 extends the execution time of the thread corresponding to the transmitted virtual CPU (step S7).
  • step S10 when the thread is not being executed (No in step S10), the execution priority changing unit 250 increases the priority 153 of the thread (step S11). Next, the execution queue rearrangement unit 260 changes the order of the run queue in which the thread is stored (step S12).
  • Steps S11 and S12 will be described with reference to FIG. If the application is SIPSProcess, the execution priority changing unit 250 changes the SIP Process registration destination array to a zero priority array, and then the execution queue reordering unit 260 sets the Process ⁇ A in the priority zero array. Move SIP Process forward.
  • FIG. 9 is a block diagram illustrating the configuration of the virtual machine system according to this embodiment.
  • the hypervisor 200 of the virtual computer system (FIG. 2) of the first embodiment further includes a limit load warning unit 270 and an execution history storage unit 280.
  • the execution history storage unit 280 stores how many times the scheduling policy change request sent from the virtual machine 300 is sent per unit time.
  • the limit load warning unit 270 confirms the execution history storage unit 280, and issues an alarm to the user when the scheduling policy change request per unit time exceeds the threshold.
  • the alarm may be a voice or GUI (Graphical User Interface) display.
  • GUI Graphic User Interface
  • the mode of the alarm issued by the limit load warning unit 270 is not limited to these.
  • the limit load warning unit 270 checks the execution history storage unit 280, and issues an alarm to the user when the scheduling policy change request per unit time exceeds the threshold. Therefore, it is possible to notify the user that there are a large number of requests that cannot be processed in the virtual machine 300.
  • FIG. 10 is a block diagram illustrating the configuration of the virtual machine system according to this embodiment.
  • the virtual machine system of this embodiment further includes a priority calculator 180 and a priority table 190 in the virtual machine 300 of the virtual machine system (FIG. 2) of the first embodiment. .
  • the priority calculation unit 180 uses the priority table 190 to store the request source (From entry) and request destination (To entry) information described in the received SIP (Session Initiation Protocol) request with the priority 192. Convert to The priority calculation unit 180 records the converted priority 192 as an additional entry in the stay request storage unit 150.
  • SIP Session Initiation Protocol
  • the priority table 190 is a table that summarizes the relationship between the information of the request source (From entry) and the request destination (To entry) and the priority 192.
  • FIG. 11 illustrates the contents of the priority table 190.
  • the priority table 190 holds a telephone number 191 and a priority 192 in association with each other.
  • the telephone number 191 indicates a From entry or To entry in SIP. For example, when “110” is entered in the From entry, the priority 192 is 1. On the other hand, in the case of a normal number (such as a user ID), the priority 192 is 60.
  • the priority calculation unit 180 refers to the SIP protocol in the left column of FIG. 12 and confirms the From entry and To entry. In the left column of FIG. 12, the From entry is “0901234567”, while the To entry is “110”. The telephone numbers described in the From entry and To entry correspond to the telephone number 191 in the priority table 190 (FIG. 11).
  • the right column of FIG. 12 shows an example of creating the priority 192 by the priority calculation unit 180.
  • the priority calculation unit 180 converts each of the From entry and the To entry into the priority 192 using the priority table 190.
  • the From entry “0901234567” has “090” in the third digit from the left.
  • a telephone number 191 beginning with “090,080,070” is a mobile telephone number in Japan. Therefore, the priority of the telephone number of the From entry is 50 from the priority table 190.
  • the priority of the telephone number “110” of the To entry is 1 from the priority table 190.
  • the priority calculation unit 180 sends the priority “51” obtained by adding the priorities “50” and “1” to the stay request storage unit 150.
  • the priority calculation unit 180 may use another method using the From entry and To entry and the priority table 190.
  • the priority calculation unit 180 may generate the priority of the SIP session by multiplying the priority of the From entry and the priority of the To entry. Further, the priority calculation unit 180 may use the higher priority of the priority of the From entry and the To entry as the priority of the SIP session.
  • FIG. 13 shows a state when the priority 192 is added to the table held by the stay request storage unit 150.
  • the UDP (User Datagram Protocol) packet transmitting / receiving unit 110 receives a UDP packet (step S1).
  • the UDP packet transmitting / receiving unit 110 extracts the SIP header from the UDP packet (step S2). Further, the UDP packet transmission / reception unit 110 creates a stay request identifier 151 when extracting the SIP header.
  • the priority calculation unit 180 calculates the priority 192 of the request (step S13).
  • the calculation method of the priority 192 by the priority calculation unit 180 is as described above with reference to the priority table 190.
  • the request unit 120 confirms the priority 192 of the arrived request (step S14).
  • the request unit 120 acquires the virtual CPU number on which the SIP server is executed (step S5), and uses the virtual CPU number as an argument to perform a hypervisor call (Hypervisor call). ) Is issued (step S6).
  • the reception unit 210 receives the hypervisor call and extends the execution time of the thread corresponding to the transmitted virtual CPU using the execution time changing unit 220 (step S7).
  • the SIP processing amplification determination unit 140 registers the SIP request that has arrived at the stay request storage unit 150. Specifically, the SIP processing amplification determination unit 140 creates an entry that is a set of the stay request identifier 151 and the stay period 152 created first, and adds the entry to the stay request storage unit 150 (step S8). At this time, the residence period 152 is set to zero. The staying amount acquisition unit 130 periodically increments the staying period 152.
  • step S15 when there is no high priority request (No in step S15), only step S8 is executed and the process is terminated.
  • the thread execution time is extended. Thereby, the CPU time can be allocated to the SIP server regardless of the number of staying requests and the staying period.
  • FIG. 15 is a block diagram illustrating the configuration of the virtual computer system of this embodiment.
  • Linux (registered trademark) 400 is used as the guest OS 100 executed in the virtual machine 300
  • KVM (Kernel-based Virtual Machine) 500 is used as the hypervisor 200.
  • sock_def_readable 410 in the Linux kernel is used.
  • try_to_wake_up 460 is used as the thread activation unit 160.
  • PVOP_VCALL3420 is used as a hypervisor call issued by the request unit 120.
  • run_queue 470 is used as the scheduling queue 170.
  • schedule 530 is used as scheduler 230 in KVM 500.
  • run_queue 540 is used as the scheduling queue 240.
  • sock_def_readable 410 is a function executed after Linux 400 finishes the UDP packet processing and before the data in the packet is passed to the user program.
  • the sock_def_readable 410 executes try_to_wake_up 460 after executing its own process to start an application that processes UDP packets.
  • sock_def_readable 410 calls the SIP processing amplification determination unit before executing try_to_wake_up 460 and extends the given CPU time, it operates to issue a hypervisor call using PVOP_VCALL3420. Accordingly, the virtual computer system according to the first embodiment can be realized based on Linux 400 and KVM 500.
  • each unit of the virtual machine system shown in FIG. 1 and the like is realized by the hardware resources illustrated in FIG. That is, the configuration shown in FIG. 17 includes a processor 50, a RAM (Random Access Memory) 51, a ROM (Read Only Memory) 52, an external connection interface 53, and a storage device 54. Each component is connected by a bus 55.
  • the hardware configuration for realizing the virtual machine system is not limited to the configuration shown in FIG.
  • each block in FIG. 1 and the like are realized by supplying a computer program capable of realizing the above-described functions to each device and then reading the computer program into the RAM 51 and executing the computer program. May be. Alternatively, some or all of the functions shown in each block in FIG. 1 and the like may be realized as hardware.
  • the supplied computer program may be stored in a computer-readable storage device such as a readable / writable memory (temporary storage medium) or a hard disk device.
  • a computer-readable storage device such as a readable / writable memory (temporary storage medium) or a hard disk device.
  • the present invention can be understood as being configured by a code representing the computer program or a storage medium storing the computer program.
  • the virtual computer system according to the first aspect is as described above.
  • the guest OS includes a first queue that holds an application that processes an accepted request and an identifier of a virtual CPU that executes the application,
  • the request unit refers to the first queue, identifies an identifier of a virtual CPU that executes the application, and issues a hypervisor call including the identified virtual CPU identifier.
  • the guest OS includes a storage unit that accumulates received requests, The request unit is configured such that when the number of unprocessed requests accumulated in the storage unit exceeds a predetermined number, or the retention period of unprocessed requests accumulated in the storage unit exceeds a predetermined period
  • a hypervisor call including an identifier of a virtual CPU that executes an application that processes the unprocessed request, The virtual computer system according to mode 1 or 2.
  • the hypervisor includes a second queue that holds a thread classified according to priority and a physical CPU that executes the thread according to the priority in association with each other.
  • the changing unit extends the execution time of the thread when the thread that realizes the virtual CPU corresponding to the identifier is being executed by a physical CPU, and otherwise, the priority of the thread in the second queue Change the order of the threads in the second queue, and
  • the virtual machine system according to any one of forms 1 to 3.
  • the guest OS includes a priority calculation unit that calculates the priority of the received request,
  • the request unit includes a hypervisor call including an identifier of a virtual CPU that executes an application that processes the unprocessed request when the priority of the unprocessed request accumulated in the storage unit exceeds a predetermined priority. Issue The virtual machine system according to any one of forms 1 to 4.
  • the hypervisor includes a warning unit that outputs a warning when the frequency of a hypervisor call issued by the request unit exceeds a predetermined frequency.
  • the virtual machine system according to any one of forms 1 to 5.
  • the scheduling method according to the second aspect is as described above.
  • the guest OS associating an application that processes the received request with an identifier of a virtual CPU that executes the application in a first queue; Referring to the first queue, identifying an identifier of a virtual CPU that executes the application, and issuing a hypervisor call including the identified identifier of the virtual CPU.
  • [Mode 10] The hypervisor associating a thread classified by priority with a physical CPU that executes the thread according to the priority in a second queue; If the thread that implements the virtual CPU corresponding to the identifier is executing on the physical CPU, the execution time of the thread is extended; otherwise, the priority of the thread in the second queue, and / or Changing the order of the threads in the second queue.
  • the scheduling method according to any one of Forms 7 to 9.
  • [Form 11] The guest OS calculating the priority of the accepted request; Issuing a hypervisor call including an identifier of a virtual CPU executing an application that processes the unprocessed request when the priority of the unprocessed request accumulated in the storage unit exceeds a predetermined priority; ,including, 11.
  • the hypervisor includes outputting a warning when the frequency of hypervisor calls issued by the guest OS exceeds a predetermined frequency;
  • the program according to the third aspect is as described above.
  • [Form 14] A process in which the guest OS associates an application that processes the received request with an identifier of a virtual CPU that executes the application and stores the associated information in a first queue; Referring to the first queue, identifying an identifier of a virtual CPU that executes the application, and causing the computer to execute a process of issuing a hypervisor call including the identified identifier of the virtual CPU.
  • the program according to Form 13 A process in which the guest OS associates an application that processes the received request with an identifier of a virtual CPU that executes the application and stores the associated information in a first queue; Referring to the first queue, identifying an identifier of a virtual CPU that executes the application, and causing the computer to execute a process of issuing a hypervisor call including the identified
  • Form 15 A process in which the guest OS accumulates received requests in a storage unit; When the number of unprocessed requests accumulated in the storage unit exceeds a predetermined number, or when the retention period of unprocessed requests accumulated in the storage unit exceeds a predetermined period, the unprocessed requests Causing the computer to execute a process of issuing a hypervisor call including an identifier of a virtual CPU that executes an application that processes the request.
  • the program according to Form 13 or 14.
  • [Form 17] A process in which the guest OS calculates the priority of the received request; A process of issuing a hypervisor call including an identifier of a virtual CPU that executes an application that processes the unprocessed request when the priority of the unprocessed request accumulated in the storage unit exceeds a predetermined priority; , Causing the computer to execute The program according to any one of forms 13 to 16.
  • the hypervisor causes the computer to execute a process of outputting a warning when the frequency of hypervisor calls issued by the guest OS exceeds a predetermined frequency; The program according to any one of forms 13 to 17.
  • the virtual computer system, scheduling method, and program storage medium according to the present invention are applied, for example, to applications such as stabilization of the quality of telephone services in the field of NFV (Network Functions Virtualization) that provides telephone services with virtual machines. be able to.
  • NFV Network Functions Virtualization

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)

Abstract

　滞留数の多いリクエストや滞留期間の長いリクエストを迅速に処理する仮想計算機システムが開示される。係る仮想計算機システムは、ゲストＯＳとハイパーバイザを備え、ゲストＯＳは、受け付けたリクエストを蓄積する記憶手段と、前記記憶手段に蓄積された未処理のリクエストの数が所定の数を超えた場合、または、前記記憶手段に蓄積された未処理のリクエストの滞留期間が所定の期間を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵの識別子を含むハイパーバイザコールを前記ハイパーバイザに対して発行する要求手段とを有し、ハイパーバイザは、識別子に対応する仮想ＣＰＵを実現するスレッドに割り当てられた物理ＣＰＵの実行時間を変更する変更手段を有する。

Description

仮想計算機システム、スケジューリング方法、および、プログラム記憶媒体
　本発明は、仮想計算機システム、スケジューリング方法、プログラム、および、プログラム記憶媒体に関する。特に、本発明は、物理計算機に構築された仮想計算機を備える仮想計算機システム、仮想計算機システムにおけるスケジューリング方法、プログラム、および、プログラム記憶媒体に関する。
　仮想計算機システムとは、１台の物理計算機に複数の仮想計算機が構築されたシステムをいう。仮想計算機システムでは、各仮想計算機で「ゲストＯＳ（Operating System）」と呼ばれるＯＳが動作する。一方、物理計算機で動作するＯＳを「バーチャルマシンモニタ（ＶＭＭ：Virtual Machine Monitor）」と呼ぶ。
　ゲストＯＳは、通常のＯＳと同様に、ゲストＯＳで動作するアプリケーションを管理する。一方、ＶＭＭは、仮想計算機を自身のアプリケーションとして管理する。ゲストＯＳが管理下のアプリケーションに与えるリソースを「仮想ＣＰＵ（Central Processing Unit）」という。仮想ＣＰＵは、ソフトウェアプログラムによって作られた擬似的なＣＰＵであり、物理計算機のスレッドとして動作する。一方、ＶＭＭが仮想計算機に与えるリソースを「物理ＣＰＵ」という。
　仮想計算機システムにおいては、ＶＭＭによるスケジューリングとゲストＯＳによるスケジューリングとの時間的な「ズレ」によって、ゲストＯＳ上のアプリケーションが正常に動作しないという問題がある。アプリケーションを動作させるには、ゲストＯＳに仮想ＣＰＵが割り当てられ、かつ、ＶＭＭに物理ＣＰＵが割り当てられなければならない。仮想ＣＰＵを割り当てるゲストＯＳのスケジューラと、物理ＣＰＵを割り当てるＶＭＭのスケジューラは、相手方が当該アプリケーションに対していつＣＰＵを割り当てているかを関知しない。
　したがって、ゲストＯＳが仮想ＣＰＵをアプリケーションに割り当てたとしても、ＶＭＭが仮想計算機に物理ＣＰＵを割り当てていない場合がある。この場合、アプリケーションを実行することができない。逆に、ＶＭＭが仮想計算機に物理ＣＰＵを割り当てても、ゲストＯＳがアプリケーションに仮想ＣＰＵを割り当てていない場合がある。この場合、割り当てられた物理ＣＰＵのＣＰＵ時間が無駄になる。
　かかる問題を解決する技術が、一例として、特許文献１に記載されている。図１６は、特許文献１に記載された仮想計算機システムの構成を例示するブロック図である。
　図１６を参照すると、仮想計算機システム１は物理計算機２を備えている。物理計算機２は、仮想計算機５、ＶＭＭ３、および、ハードウェア４を備えている。仮想計算機５は、ゲストＯＳ６を備えている。ＶＭＭ３は、ゲストＯＳインターフェイス部７、ゲストＯＳ依存関係作成モジュール８、ゲストＯＳ依存関係テーブル９、ディスパッチャ１０、ＣＰＵ割り当てテーブル１１、および、ゲストＯＳスケジューラ１２を備えている。ハードウェア４は、ＣＰＵ１３を備えている。さらに、ゲストＯＳスケジューラ１２は、ＣＰＵ割り当てテーブル管理部１４、判定部１５、サーバゲストＯＳスケジュール部１６、クライアントゲストＯＳ探索部１７、および、クライアントゲストＯＳスケジュール部１８を備えている。
　図１６に示した仮想計算機システムは、次のように動作する。すなわち、ＶＭＭ３のゲストＯＳインターフェイス部７は、ゲストＯＳ６のうちのクライアントとして機能する任意のゲストＯＳが、サーバとして機能する他のゲストＯＳに処理を要求する際、以下を通知するインターフェイスを含む。すなわち、ゲストＯＳインターフェイス部７は、上記処理の要求元のゲストＯＳがクライアントとなり、処理の要求先のゲストＯＳがサーバとなるサーバ／クライアント関係を、要求元のゲストＯＳからＶＭＭ３に通知するインターフェイスを含む。ＶＭＭ３のゲストＯＳスケジューラ１２は、このインターフェイスによって通知されたサーバ／クライアント関係に基づいて、ゲストＯＳ６に対してＣＰＵを割り当てる時間を調整する。
特開２０１０－２１８１５１号公報
　上記特許文献の全開示内容は、本書に引用をもって繰り込み記載されているものとする。以下の分析は、発明者によってなされたものである。
　特許文献１に記載された仮想計算機システムによると、仮想計算機のどの仮想ＣＰＵでアプリケーションが動作しているかが考慮されておらず、アプリケーションが動作しないおそれがある。
　その理由は、ゲストＯＳを対象として、割り当てる物理ＣＰＵ時間を調整しているためである。背景技術で述べた通り、仮想ＣＰＵと物理ＣＰＵを同時に割り当てることによってアプリケーションを実行することができる。ゲストＯＳが持つ仮想ＣＰＵは１つとは限らない。また、ＶＭＭが持つ物理ＣＰＵも１つとは限らない。つまり、ゲストＯＳがアプリケーションに割り当てた仮想ＣＰＵが存在し、かつ、割り当てられた仮想ＣＰＵをＶＭＭで具現するスレッドに対して物理ＣＰＵを割り当てなければ、アプリケーションは動作しない。
　特許文献１に記載された仮想計算機システムでは、ゲストＯＳに対して物理ＣＰＵ使用率の割合が与えられており、どの仮想ＣＰＵ（スレッド）に対して物理ＣＰＵを割り当ててよいかを判断することができない。一例として、ある仮想計算機が４つの仮想ＣＰＵ１～ＣＰＵ４を保持するものとする。また、仮想ＣＰＵ１～ＣＰＵ４を具現化したＶＭＭ上のスレッドを、それぞれ、スレッド１～スレッド４とする。ここで、仮想ＣＰＵ１がアプリケーションに対して割り当てられたとする。このとき、ＶＭＭが物理ＣＰＵを割り当てるべきスレッドは、スレッド１である。しかしながら、特許文献１に記載された仮想計算機システムでは、仮想ＣＰＵ１がアプリケーションに割り当てられたときに、ＶＭＭが物理ＣＰＵをスレッド１に割り当てる機能を備えていない。
　また、特許文献１に記載された仮想計算機システムでは、リクエストの滞留量を考慮していないため、物理ＣＰＵ時間を余分に割り当てている可能性がある。
　その理由は、クライアントとサーバ間でやり取りされるリクエストがなければ、割り当てられた物理ＣＰＵ時間は使用されないからである。特許文献１では、クライアントとなる仮想計算機とサーバとなる仮想計算機のそれぞれがＶＭＭに対してそれぞれの関係を登録する。すなわち、クライアントはサーバとなる仮想計算機を指定し、サーバはクライアントとなる仮想計算機を指定する。これにより、クライアントとサーバの関係をＶＭＭ内で構築し、それぞれの仮想計算機に必要な物理ＣＰＵ時間を調整している。しかし、実際にクライアントとサーバがリクエストをやり取りしているかどうかは考慮されていない。したがって、クライアントとサーバがリクエストを送受信していなくても、物理ＣＰＵ時間が割り当てられるおそれがある。
　そこで、仮想計算機システムにおいて、滞留数の多いリクエストや滞留期間の長いリクエストを迅速に処理することが課題となる。本発明の目的は、かかる課題解決に寄与する仮想計算機システム、スケジューリング方法、および、プログラム記憶媒体を提供することにある。
　本発明の第１の態様に係る仮想計算機システムは、ゲストＯＳ（Operating System）とハイパーバイザを備え、前記ゲストＯＳは、受け付けたリクエストを蓄積する記憶部と、前記記憶部に蓄積された未処理のリクエストの数が所定の数を超えた場合、または、前記記憶部に蓄積された未処理のリクエストの滞留期間が所定の期間を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵ（Central Processing Unit）の識別子を含むハイパーバイザコールを、前記ハイパーバイザに対して発行する要求部とを有し、前記ハイパーバイザは、前記識別子に対応する仮想ＣＰＵを実現するスレッドに割り当てられた物理ＣＰＵの実行時間を変更する変更部を有する。
　本発明の第２の態様に係るスケジューリング方法は、ゲストＯＳ（Operating System）が、受け付けたリクエストを記憶部に蓄積し、前記記憶部に蓄積された未処理のリクエストの数が所定の数を超えた場合、または、前記記憶部に蓄積された未処理のリクエストの滞留期間が所定の期間を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵ（Central Processing Unit）の識別子を含むハイパーバイザコールを、ハイパーバイザに対して発行し、前記ハイパーバイザが、前記識別子に対応する仮想ＣＰＵを実現するスレッドに割り当てられた物理ＣＰＵの実行時間を変更する。
　本発明の第３の態様に係るプログラム記憶媒体は、ゲストＯＳ（Operating System）が、受け付けたリクエストを記憶部に蓄積する処理と、前記記憶部に蓄積された未処理のリクエストの数が所定の数を超えた場合、または、前記記憶部に蓄積された未処理のリクエストの滞留期間が所定の期間を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵ（Central Processing Unit）の識別子を含むハイパーバイザコールをハイパーバイザに対して発行する処理と、前記ハイパーバイザが、前記識別子に対応する仮想ＣＰＵを実現するスレッドに割り当てられた物理ＣＰＵの実行時間を変更する処理と、をコンピュータに実行させるコンピュータ・プログラムを記憶する。なお、プログラム記憶媒体は、非一時的なコンピュータ可読記憶媒体（non-transitory computer-readable storage medium）として提供することもできる。
　本発明に係る仮想計算機システム、スケジューリング方法、および、プログラム記憶媒体によると、仮想計算機システムにおいて、滞留数の多いリクエストや滞留期間の長いリクエストを迅速に処理することが可能となる。
一実施形態に係る仮想計算機システムの構成を例示するブロック図である。 第１の実施形態に係る仮想計算機システムの構成を例示するブロック図である。 第１の実施形態における滞留リクエスト記憶部の構成を例示する図である。 第１の実施形態におけるＳＩＰ（Session Initiation Protocol）リクエストのデータ構造を説明する図である。 第１および他の実施形態におけるスケジューリングキューの構成を説明する図である。 第１の実施形態に係る仮想計算機システムの動作を例示するフロー図である。 第２の実施形態に係る仮想計算機システムの構成を例示するブロック図である。 第２の実施形態に係る仮想計算機システムの動作を例示するフロー図である。 第３の実施形態に係る仮想計算機システムの構成を例示するブロック図である。 第４の実施形態に係る仮想計算機システムの構成を例示するブロック図である。 第４の実施形態における優先度表のデータ構造を例示する図である。 第４の実施形態における優先度作成例を例示する図である。 第４の実施形態における優先度追加後の滞留リクエスト記憶部のデータ構造を例示する図である。 第４の実施形態に係る仮想計算機システムの動作を例示するフロー図である。 第５の実施形態に係る仮想計算機システムの構成を例示するブロック図である。 特許文献１に記載された仮想計算機システムの構成を例示するブロック図である。 上記実施形態に係る仮想計算機システムを実現するハードウエア構成の一例を示す図である。
　はじめに、一実施形態の仮想計算機システムの概要について説明する。なお、この概要に付記する図面参照符号は、専ら理解を助けるための例示であり、本発明を図示の態様に限定することを意図するものではない。
　図１は、一実施形態に係る仮想計算機システムの構成を例示するブロック図である。図１を参照すると、仮想計算機システムは、ゲストＯＳ（Operating System）２０とハイパーバイザ３０を備える。ゲストＯＳ２０は、仮想ＣＰＵ（Central Processing Unit）の識別子を含むハイパーバイザコールをハイパーバイザ３０に対して発行する要求部２２を有する。ハイパーバイザ３０は、識別子に対応する仮想ＣＰＵを実現するスレッドに割り当てられた物理ＣＰＵの実行時間を変更する変更部３２を有する。
　かかる仮想計算機システムによると、アプリケーションを実行する仮想ＣＰＵを実現するスレッドに対して、物理ＣＰＵの実行時間を適切に割り当てることが可能となる。なぜなら、ゲストＯＳ２０は、ゲストＯＳ２０が稼働する仮想マシンに到着したリクエストを処理するアプリケーションが実行される仮想ＣＰＵを指定してハイパーバイザコールを発行し、ハイパーバイザは指定された仮想ＣＰＵを実現するスレッドに対する物理ＣＰＵの実行時間を変更することができるからである。
　また、図２を参照すると、ゲストＯＳ１００は、受け付けたリクエストを処理するアプリケーションとアプリケーションを実行する仮想ＣＰＵの識別子を関連付けて保持する第１のキュー（スケジューリングキュー１７０）を備える。要求部１２０は、第１のキュー（１７０）を参照して、アプリケーションを実行する仮想ＣＰＵの識別子を特定し、特定した仮想ＣＰＵの識別子を含むハイパーバイザコールを発行するようにしてもよい。
　さらに、ゲストＯＳ１００は、受け付けたリクエストを蓄積する記憶部（滞留リクエスト記憶部１５０）を備える。要求部１２０は、記憶部（１５０）に蓄積された未処理のリクエストの数が所定の数を超えた場合、または、記憶部（１５０）に蓄積された未処理のリクエストの滞留期間が所定の期間を超えた場合、以下を行うようにしてもよい。すなわち、要求部１２０は、未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵの識別子を含むハイパーバイザコールを発行するようにしてもよい。
　かかる仮想計算機システムによると、滞留しているリクエストの数、または、リクエストの滞留期間に応じて、当該リクエストを処理するアプリケーションを実行する仮想ＣＰＵに相当するスレッドに対して、優先的に物理ＣＰＵの実行時間を割り当てることが可能となる。したがって、滞留しているリクエストや、滞留期間が長期化しているリクエストを、迅速に処理することができる。
　また、図７を参照すると、ハイパーバイザ２００は、優先度ごとに分類されたスレッドと、スレッドを優先度に応じて実行する物理ＣＰＵを関連付けて保持する第２のキュー（スケジューリングキュー２４０）を備える。変更部（実行時間変更部２２０）は、識別子に対応する仮想ＣＰＵを実現するスレッドが物理ＣＰＵで実行中である場合、当該スレッドの実行時間を延長する。それ以外の場合、変更部（２２０）は、当該スレッドの第２のキュー（２４０）における優先度、および／または、当該スレッドの第２のキュー（２４０）における順序を変更してもよい。
　かかる仮想計算機システムによると、特定のアプリケーションを実行する仮想ＣＰＵに対して、当該アプリケーションが物理ＣＰＵで実行中であれば、実行時間が延長されるようにすることができる。実行中でなければ、現在実行中のアプリケーションの終了後、直ちに物理ＣＰＵで実行が開始されるようにすることができる。
　図１０を参照すると、ゲストＯＳ１００は、受け付けたリクエストの優先度を計算する優先度計算部１８０を備える。要求部１２０は、記憶部（滞留リクエスト記憶部１５０）に蓄積された未処理のリクエストの優先度が所定の優先度を超えた場合、未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵの識別子を含むハイパーバイザコールを発行するようにしてもよい。
　かかる仮想計算機システムによると、優先度が高いリクエストを処理するアプリケーションを実行する仮想ＣＰＵを実現するスレッドに対して、優先的に物理ＣＰＵの実行時間を割り当てることが可能となる。
　図９を参照すると、ハイパーバイザ２００は、要求部（要求部１２０）によって発行されるハイパーバイザコールの頻度が所定の頻度を超えた場合、警告を出力する警告部（限界負荷警告部２７０）を備えていてもよい。
　かかる仮想計算機システムによると、単位時間当たりのハイパーバイザコールの回数が閾値を超えた場合、ユーザに対してアラームを発行する。これにより、ゲストＯＳが稼働する仮想マシンに対して、処理能力を超えたリクエストが到着していることをユーザに通知することができる。
＜実施形態１＞
　次に、第１の実施形態に係る仮想計算機システムについて、図面を参照して詳細に説明する。図２は、本実施形態の仮想計算機システムの構成を例示するブロック図である。
　図２を参照すると、本実施形態の仮想計算機システムは、仮想マシン３００とハイパーバイザ（Hypervisor）２００を備えている。仮想マシン３００は、ゲストＯＳ（Operating System）１００を備えている。ゲストＯＳ１００は、ＵＤＰ（User Datagram Protocol）パケット送受信部１１０、ＳＩＰ（Session Initiation Protocol）処理増幅判定部１４０、スレッド起動部１６０、滞留量取得部１３０、滞留リクエスト記憶部１５０、要求部１２０、および、スケジューリングキュー１７０を備えている。また、ハイパーバイザ２００は受付部２１０、実行時間変更部２２０、スケジューラ２３０、および、スケジューリングキュー２４０を備えている。
　ＵＤＰパケット送受信部１１０は、ゲストＯＳ１００内でＵＤＰパケットを送受信する。到着したＵＤＰパケットがＳＩＰリクエストである場合、ＵＤＰパケット送受信部１１０は、当該ＳＩＰリクエストから滞留リクエスト識別子１５１を作成し、滞留リクエスト記憶部１５０に格納する。ＵＤＰパケット送受信部１１０は、滞留リクエスト識別子１５１の格納後、ＳＩＰ処理増幅判定部１４０を実行する。また、ＵＤＰパケット送受信部１１０は、ＳＩＰリクエストをＵＤＰパケットでカプセル化して他の物理計算機に送信する際、当該ＳＩＰリクエストは処理済みであるため、滞留リクエスト記憶部１５０から滞留リクエスト識別子１５１が一致するエントリを削除する。
　ＳＩＰ処理増幅判定部１４０は、滞留量取得部１３０が計算したリクエスト滞留量を取得して、ハイパーバイザ２００に対してスケジューリングポリシーの変更要求を発行するかどうかを判断する。ＳＩＰ処理増幅判定部１４０は、滞留リクエストの数が所定の数を超えた場合、スケジューリングポリシーの変更要求を発行する。ここで、所定の数は、予めユーザによって設定されているものとする。また、ＳＩＰ処理増幅判定部１４０は、ある滞留リクエストの滞留期間がある所定の期間を超えた場合、スケジューリングポリシーの変更要求を発行する。所定の期間は、予めユーザによって設定されているものとする。
　ただし、所定の期間として、ＳＩＰのデフォルトタイムアウト時間であるＴ１を用いる場合、ユーザによる設定は必要とされない。ここで、Ｔ１とは、ＳＩＰリクエストの再送が開始される時間であり、デフォルト値は５００ｍｓである。Ｔ１の値は変更可能であり、ＳＩＰサーバ（仮想マシン３００におけるアプリケーション）の設定ファイルに現在のＴ１の値が格納されている。ＳＩＰ処理増幅判定部１４０は、処理を開始する前に、ＳＩＰサーバの設定ファイルから、現在のＴ１の値を予め確認しておく。
　スレッド起動部１６０は、スレッドを起動する。アプリケーションは、複数のスレッドを含む。具体的には、スレッド起動部１６０は、ＵＤＰパケットが届くと、当該ＵＤＰパケットを処理するスレッドを起動する。
　滞留量取得部１３０は、滞留リクエスト記憶部１５０に格納された滞留リクエスト数をカウントして、ＳＩＰ処理増幅判定部１４０に通知する。また、滞留量取得部１３０は、滞留リクエスト記憶部１５０に格納されている滞留リクエストがゲストＯＳ１００内で滞留している期間を更新する。滞留量取得部１３０は、タイマー等によって定期的に起動し、滞留リクエスト記憶部１５０に格納された滞留リクエストの滞留期間１５２をインクリメントする。
　滞留リクエスト記憶部１５０は、現在仮想マシン３００に滞留しているリクエストに関する情報を記憶する。図３は、滞留リクエスト記憶部１５０が保持するテーブルの内容を例示する。滞留リクエスト記憶部１５０は、滞留リクエスト識別子１５１と滞留期間１５２とを関連付けて保持する。ＵＤＰパケット送受信部１１０は、ＳＩＰリクエストを含むＵＤＰパケットが到着すると、滞留リクエスト識別子１５１を生成する。
　図４は、ＳＩＰリクエストのデータ構造を例示する。ＵＤＰパケット送受信部１１０は、図４に示した「Call-ID」と「CSeq」を用いて滞留リクエスト識別子１５１を生成する。ＵＤＰパケット送受信部１１０は、一例として、Call-IDとCSeqをアンダーバーで接続したものを滞留リクエスト識別子１５１とする（図３）。ただし、Call-IDとCSeqを使用して一意に識別子を表現できればよい。したがって、滞留リクエスト識別子１５１は図３に示した態様に限定されない。また、ＵＤＰパケット送受信部１１０は、処理済みのＳＩＰリクエストをリクエスト要求元に送信する際、滞留リクエスト識別子１５１が一致するエントリを滞留リクエスト記憶部１５０から削除する。
　要求部１２０は、仮想ＣＰＵを具現するスレッドに与えられた実行時間の延長をハイパーバイザ２００に対して要求する。要求部１２０は、スケジューリングポリシー変更要求を出す際、仮想ＣＰＵ番号と対になるスレッド番号を知らない。そこで、要求部１２０は、仮想ＣＰＵ番号を引数としてハイパーバイザコールを発行する。ハイパーバイザ２００は、仮想ＣＰＵ番号とスレッド番号の対となるテーブルを保持している。ハイパーバイザコールとは、一般のＯＳが持つシステムコール（System call）と同様に、仮想マシン３００が自発的にハイパーバイザ２００に対して「何らかの処理」を要求するために使われるハードウェアに備わった機能である。本実施形態では、仮想マシン３００は、「何らかの処理」の例として、スケジューリングポリシーの変更をハイパーバイザ２００に対して要求する。
　スケジューリングキュー１７０は、仮想マシン３００で実行されるアプリケーションのＣＰＵ割り当てを管理するデータ構造である。図５は、スケジューリングキュー１７０のデータ構造を例示する。計算機に含まれる各ＣＰＵにはそれぞれスケジューリングキュー１７０が作成される。
　なお、仮想マシン３００のスケジューリングキュー１７０のデータ構造と、ハイパーバイザ２００のスケジューリングキュー２４０のデータ構造は、同一である。ただし、図５をゲストＯＳ１００におけるスケジューリングキュー１７０とみなした場合、図５のＣＰＵは仮想ＣＰＵを表す。一方、図５をハイパーバイザ２００におけるスケジューリングキュー２４０とみなした場合、図５のＣＰＵは物理ＣＰＵを表す。
　スケジューリングキュー１７０には、実行を待つアプリケーション（図５の「Process」）が登録されている。スケジューラ２３０は、次に実行すべきアプリケーションをスケジューリングキュー１７０から選択する。図５に例示したスケジューリングキュー１７０では、優先度１５３毎にキューが分割されている。優先度１５３の数が小さいものを高優先度とすると、スケジューラ２３０は最初にProcess Aを選択する。本実施形態では、要求部１２０は、到着したＳＩＰリクエストを処理するＳＩＰアプリケーションがどの仮想ＣＰＵで実行される予定であるのかを確認するために、スケジューリングキュー１７０を用いる。図５では、ＳＩＰアプリケーション（図５の「SIP Process」）はＣＰＵ＃１に登録されている。このとき、ＳＩＰ処理増幅判定部１４０は、変更要求を発行するものと決定した場合、ＣＰＵ＃１を引数として要求部１２０を呼び出す。
　受付部２１０は、要求部１２０が送出したスケジューリングポリシー変更要求を受け付ける。受付部２１０は、送られてきた仮想ＣＰＵ番号をスレッド番号に変換し、当該スレッド番号を持つスレッドに与えられたＣＰＵ時間を延長するために、実行時間変更部２２０を呼び出す。
　実行時間変更部２２０は、スレッドに与えられているＣＰＵ時間を延長する。ゲストＯＳ１００またはハイパーバイザ２００に設けられたスケジューラ２３０は、スケジューリングキュー１７０から選択したスレッドを、ＣＰＵで実行する。スケジューラ２３０は、スレッドの実行開始時にスレッドに対して実行時間を与える。スケジューラ２３０は、与えられた実行時間が経過するまでは、当該スレッドがＣＰＵを使って自身の処理を進めていく。スケジューラ２３０によって与えられた実行時間が経過すると、スケジューラ２３０は、次のスレッドをスケジューリングキュー１７０から選択してＣＰＵ時間を与える。与えられた実行時間を消費したスレッドは、スケジューラ２３０によってスケジューリングキュー１７０に格納される。スケジューラ２３０は、実行時間を管理する。実行時間変更部２２０は、仮想ＣＰＵを実現するハイパーバイザ２００のスレッドが実行中である場合、実行時間を延長する。
　スケジューラ２３０は、スケジューリングキュー２４０に登録されているスレッドをＣＰＵで適宜実行していく。スレッドを実行する際、上述のようにスレッドに対して実行時間が割り当てられる。当該スレッドは、与えられた実行時間の間だけ処理を進めることができる。スケジューラ２３０は、現在実行中スレッドの実行時間を管理する。また、実行時間変更部２２０は、スケジューラ２３０が管理する実行時間を変更する。
　本実施形態の仮想計算機システムは、上記構成に基づいて、ＳＩＰリクエストが送られてきた際、すでに滞留しているリクエスト量を確認し、滞留しているリクエストがある閾値を超過している場合、ＳＩＰリクエストを処理している仮想ＣＰＵに割り当てられる物理ＣＰＵ時間を延長する。これにより、リクエスト処理のための物理ＣＰＵ時間が十分に得られる。
　次に、図６のフロー図を参照して本実施形態の仮想計算機システム（図２）の動作について詳細に説明する。
　まず、ＵＤＰパケット送受信部１１０は、ＵＤＰパケットを受信する（ステップＳ１）。次に、ＵＤＰパケット送受信部１１０は、ＵＤＰパケットからＳＩＰヘッダを取り出す（ステップＳ２）。ＵＤＰパケット送受信部１１０は、ＳＩＰヘッダを取り出す際に、滞留リクエスト識別子１５１を作成する。
　次に、ＳＩＰ処理増幅判定部１４０は、滞留リクエスト記憶部１５０を参照して、現在のリクエスト滞留量を確認する（ステップＳ３）。ＳＩＰ処理増幅判定部１４０は、滞留量取得部１３０を介して、滞留リクエスト記憶部１５０のエントリ数をカウントすることによってリクエスト滞留量を求める。
　リクエスト滞留量が閾値を超過しているとＳＩＰ処理増幅判定部１４０が判定した場合（ステップＳ４のＹｅｓ）、要求部１２０はＳＩＰサーバが実行される仮想ＣＰＵ番号を取得し（ステップＳ５）、当該仮想ＣＰＵ番号を引数としてハイパーバイザコールを発行する（ステップＳ６）。
　受付部２１０は、ハイパーバイザコールを受け取り、ハイパーバイザコールに含まれる仮想ＣＰＵに該当するスレッドの実行時間を延長する（ステップＳ７）。
　次に、ＳＩＰ処理増幅判定部１４０は、滞留リクエスト記憶部１５０に、到着したＳＩＰリクエストを登録する。具体的には、ＳＩＰ処理増幅判定部１４０は、最初に作成した滞留リクエスト識別子１５１と滞留期間１５２を組にしたエントリを作成して、そのエントリを滞留リクエスト記憶部１５０に追加する（ステップＳ８）。ＳＩＰ処理増幅判定部１４０は、エントリの追加時点では、滞留期間１５２をゼロにセットしておく。滞留量取得部１３０は、定期的に滞留期間１５２をインクリメントする。
　一方、リクエスト滞留量が閾値以下である場合（ステップＳ４のＮｏ）、ステップＳ８のみを実行して処理を終了する。
　本実施形態の仮想計算機システムでは、ＳＩＰパケットが到着した際、仮想マシン内に滞留しているリクエスト量を確認して、追加の物理ＣＰＵ時間をハイパーバイザ（Hypervisor）に要求することができる。
　特に、本実施形態によると、物理ＣＰＵを必要とする仮想ＣＰＵを特定して物理ＣＰＵを割り当てることができる。その理由は、仮想マシンのスケジューリングキューを確認し、到着したリクエストがどの仮想ＣＰＵで実行されるかをハイパーバイザに伝えるからである。
　また、本実施形態によると、サーバ（背景技術におけるアプリケーションに相当）内に滞留しているリクエストに対してリクエスト処理のための物理ＣＰＵを十分に割り当てることができる。その理由は、本実施形態の仮想計算機システムは、以下の構成を有するからである。すなわち、本実施形態の仮想計算機システムは、サーバに到着したリクエスト数とサーバでの処理を終えてクライアントに返信されるリクエスト数を監視して、その差分を滞留リクエストとして記憶する。滞留しているリクエストが、ある閾値を超過している場合、仮想計算機システムは、ＳＩＰリクエストを処理している仮想ＣＰＵに割り当てられる物理ＣＰＵ時間を延長する。
＜実施形態２＞
　次に、第２の実施形態に係る仮想計算機システムついて図面を参照して詳細に説明する。
　図７は、本実施形態に係る仮想計算機システムの構成を例示するブロック図である。図７を参照すると、本実施形態の仮想計算機システムは、第１の実施形態の仮想計算機システム（図２）のハイパーバイザ２００に、さらに、実行優先度変更部２５０と実行キュー並べ替え部２６０を備えている。
　これらの各部は、次のように動作する。
　実行優先度変更部２５０は、スケジューリングキュー２４０に登録されているスレッドの優先度１５３を変更する。スケジューリングキュー２４０は、上記実施形態１において図５を参照して説明したスケジューリングキュー１７０と同様の構成を有する。図５を参照して説明すると、スケジューリングキュー２４０は、優先度１５３毎に配列を分割して保持しており、配列にはＣＰＵ時間を要求するアプリケーション（図５においてProcessと記載）が登録されている。
　ここで、「実行優先度を変更する」とは、ある優先度１５３の配列から別の優先度１５３の配列にアプリケーションを移動させることをいう。図５では、SIP Processは優先度２の配列に登録されている。SIP Processの実行優先度を変更すると、例えば、SIP Processは優先度０の配列に登録される。実行優先度変更部２５０は、該当アプリケーションの優先度１５３を、例えば、最高の優先度１５３（図５の場合、優先度０）に変更する。ただし、実行優先度変更部２５０は、変更先の優先度の指定をユーザから受け付けるようにしてもよい。
　実行キュー並べ替え部２６０は、スケジューリングキュー２４０に登録されているスレッドの配列において、スレッドの順序を入れ替える。図５を参照すると、スケジューリングキュー２４０は、優先度１５３毎にスレッドの配列を分割して保持する。配列には、ＣＰＵ時間を要求するアプリケーション（図５の「Process」）が登録されている。
　「実行キューを並べ替える」とは、優先度１５３毎に分割された配列に含まれるスレッドの順序を並べ替えることをいう。図５では、SIP ProcessがProcess Dの後ろに配置されている。このとき、スケジューラ２３０は、優先度２のアプリケーションを実行する際、最初にアプリケーションとしてProcess Dを選択する。実行キュー並べ替え部２６０は、対象アプリケーションを配列の一番先頭に配置する。図５に例示したスケジューリングキュー２４０の場合、実行キュー並べ替え部２６０は、SIP ProcessとProcess Dの順序を入れ替える。
　次に、図８のフロー図を参照して、本実施形態の仮想計算機システム（図７）の動作について詳細に説明する。
　図８のフロー図に示す動作は、受付部２１０が仮想マシン３００から要求を受け取った後に開始される。第１の実施形態では、要求を受け取った後、実行時間変更部２２０が、送られてきた仮想ＣＰＵに相当するスレッドの実行時間を変更した。一方、本実施形態では、該当スレッドが実行待ち状態であり、スケジューリングキュー２４０に登録されている状態であっても、現在実行中のアプリケーションの終了後に直ちにＳＩＰサーバに実行時間を割り当てることが可能となる。
　まず、要求部１２０は、ハイパーバイザコール（Hypervisor call）を発行する（ステップＳ６）。
　次に、受付部２１０は、ハイパーバイザコールにおいて通知された仮想ＣＰＵに該当するスレッドが実行中かどうかを確認する（ステップＳ９）。当該スレッドが実行中である場合（ステップＳ１０のＹｅｓ）、実行時間変更部２２０は送られてきた仮想ＣＰＵに該当するスレッドの実行時間を延長する（ステップＳ７）。
　一方、当該スレッドが実行中でない場合（ステップＳ１０のＮｏ）、実行優先度変更部２５０は、当該スレッドの優先度１５３を上げる（ステップＳ１１）。次に、実行キュー並べ替え部２６０は、当該スレッドが格納されているランキューの順序を変更する（ステップＳ１２）。
　図５を参照して、ステップＳ１１およびＳ１２について説明する。該当アプリケーションがSIP Processである場合、実行優先度変更部２５０がSIP Processの登録先の配列を優先度ゼロの配列に変更した後、実行キュー並べ替え部２６０が優先度０の配列においてProcess Aの前にSIP Processを移動する。
　次に、本実施形態の効果について説明する。本実施形態では、対象となるＳＩＰサーバにＣＰＵ時間が与えられておらず、スケジューリングキュー２４０に登録されている場合でも、実行優先度変更部２５０と実行キュー並べ替え部２６０を組み合わせて使用することにより、現在実行中のアプリケーションの終了後に直ちにＳＩＰサーバに対して実行時間を割り当てることができる。
＜実施形態３＞
　次に、第３の実施形態に係る仮想計算機システムについて、図面を参照して詳細に説明する。
　図９は、本実施形態に係る仮想計算機システムの構成を例示するブロック図である。図９を参照すると、本実施形態は、第１の実施形態の仮想計算機システム（図２）のハイパーバイザ２００に、さらに、限界負荷警告部２７０と実行履歴記憶部２８０を備えている。
　これらの各部は、次のように動作する。
　実行履歴記憶部２８０は、仮想マシン３００から送られてきたスケジューリングポリシー変更要求が単位時間当たり何回送られてきているかを記憶する。
　限界負荷警告部２７０は、実行履歴記憶部２８０を確認し、単位時間当たりのスケジューリングポリシー変更要求が閾値を超えた場合、ユーザに対してアラームを発行する。アラームは、音声やＧＵＩ（Graphical User Interface）の表示であってもよい。ただし、限界負荷警告部２７０が発行するアラームの態様は、これらに限定されない。
　次に、本実施形態の効果について説明する。本実施形態では、限界負荷警告部２７０が実行履歴記憶部２８０を確認し、単位時間当たりのスケジューリングポリシー変更要求が閾値を超えた場合、ユーザに対してアラームを発行する。したがって、仮想マシン３００に処理しきれない量のリクエストが滞留していることをユーザに通知することができる。
＜実施形態４＞
　次に、第４の実施形態に係る仮想計算機システムについて、図面を参照して詳細に説明する。
　図１０は、本実施形態に係る仮想計算機システムの構成を例示するブロック図である。図１０を参照すると、本実施形態の仮想計算機システムは、第１の実施形態の仮想計算機システム（図２）の仮想マシン３００に、さらに、優先度計算部１８０と優先度表１９０を備えている。
　これらの各部は、次のように動作する。
　優先度計算部１８０は、送られてきたＳＩＰ（Session Initiation Protocol）リクエストに記載されている要求元（Fromエントリ）と要求先（Toエントリ）の情報を、優先度表１９０を用いて優先度１９２に変換する。優先度計算部１８０は、変換した優先度１９２を滞留リクエスト記憶部１５０の追加エントリとして記録する。
　優先度表１９０は、要求元（Fromエントリ）と要求先（Toエントリ）の情報と優先度１９２の関係をまとめた表である。図１１は、優先度表１９０の内容を例示する。図１１を参照すると、優先度表１９０は、電話番号１９１と優先度１９２を関連付けて保持する。電話番号１９１とは、ＳＩＰにおけるFromエントリまたはToエントリを指している。例えば、Fromエントリに「１１０」が入っている場合、優先度１９２は１となる。一方、通常の番号（ユーザＩＤ等）の場合、優先度１９２は６０となる。
　図１２を参照して、ＳＩＰから優先度１９２を作成する手順を説明する。優先度計算部１８０は、図１２の左欄のＳＩＰプロトコルを参照して、FromエントリとToエントリを確認する。図１２の左欄において、Fromエントリは「0901234567」であり、一方、Toエントリは「110」である。FromエントリおよびToエントリに記載された電話番号が優先度表１９０（図１１）の電話番号１９１に相当する。図１２の右欄は、優先度計算部１８０による優先度１９２の作成例を示す。
　まず、優先度計算部１８０は、FromエントリとToエントリのそれぞれを、優先度表１９０を用いて優先度１９２に変換する。Fromエントリ「0901234567」は、左から３ケタが「090」である。「090,080,070」から始まる電話番号１９１は、我が国では携帯電話番号である。したがって、Fromエントリの電話番号の優先度は、優先度表１９０より50となる。一方、Toエントリの電話番号「110」の優先度は、優先度表１９０より１となる。優先度計算部１８０は、これらの優先度「５０」と「１」を足し合わせた優先度「５１」を滞留リクエスト記憶部１５０に送る。
　ここでは、一例として、足し算による優先度の作成方法を示した。ただし、優先度計算部１８０は、FromエントリおよびToエントリと、優先度表１９０を用いた他の方法を用いてもよい。例えば、優先度計算部１８０は、Fromエントリの優先度とToエントリの優先度を掛け合わせて、当該ＳＩＰセッションの優先度を生成してもよい。また、優先度計算部１８０は、FromエントリとToエントリの優先度のうちの優先度の高い方を、当該ＳＩＰセッションの優先度としてもよい。
　図１３は、滞留リクエスト記憶部１５０が保持するテーブルに対して優先度１９２を追加したときの様子を示す。
　次に、図１４のフロー図を参照して、本実施形態の仮想計算機システム（図１０）の動作について詳細に説明する。
　まず、ＵＤＰ（User Datagram Protocol）パケット送受信部１１０は、ＵＤＰパケットを受信する（ステップＳ１）。次に、ＵＤＰパケット送受信部１１０は、ＵＤＰパケットからＳＩＰヘッダを取り出す（ステップＳ２）。また、ＵＤＰパケット送受信部１１０は、ＳＩＰヘッダを取り出す際、滞留リクエスト識別子１５１を作成する。
　次に、優先度計算部１８０は、当該リクエストの優先度１９２を計算する（ステップＳ１３）。優先度計算部１８０による優先度１９２の計算手法は、優先度表１９０を参照して上述した通りである。
　次に、要求部１２０は、到着済みリクエストの優先度１９２を確認する（ステップＳ１４）。高優先度のリクエストが存在する場合（ステップＳ１５のＹｅｓ）、要求部１２０はＳＩＰサーバが実行される仮想ＣＰＵ番号を取得し（ステップＳ５）、当該仮想ＣＰＵ番号を引数としてハイパーバイザコール（Hypervisor call）を発行する（ステップＳ６）。
　受付部２１０は、ハイパーバイザコールを受け取り、送られてきた仮想ＣＰＵに該当するスレッドの実行時間を、実行時間変更部２２０を用いて延長する（ステップＳ７）。
　次に、ＳＩＰ処理増幅判定部１４０は、滞留リクエスト記憶部１５０に到着したＳＩＰリクエストを登録する。具体的には、ＳＩＰ処理増幅判定部１４０は、最初に作成した滞留リクエスト識別子１５１と滞留期間１５２を組にしたエントリを作成して、滞留リクエスト記憶部１５０に追加する（ステップＳ８）。この時点では、滞留期間１５２をゼロにセットしておく。滞留量取得部１３０は、定期的に滞留期間１５２をインクリメントする。
　一方、高優先度のリクエストが存在しない場合（ステップＳ１５のＮｏ）、ステップＳ８のみを実行して処理を終了する。
　本実施形態の仮想計算機システムでは、高優先のＳＩＰリクエストが存在する場合に、スレッドの実行時間を延長する。これにより、リクエストの滞留数や滞留期間にかかわらず、ＳＩＰサーバに対してＣＰＵ時間を割り当てることができる。
＜実施形態５＞
　次に、第５の実施形態に係る仮想計算機システムについて、図面を参照して説明する。本実施形態は、第１の実施形態の仮想計算機システムの具体的な実装例に相当する。
　図１５は、本実施形態の仮想計算機システムの構成を例示するブロック図である。図１５を参照すると、本実施形態では、仮想マシン３００で実行されるゲストＯＳ１００としてLinux（登録商標）４００を用い、ハイパーバイザ２００としてＫＶＭ（Kernel-based Virtual Machine）５００を用いる。また、ＵＤＰパケット送受信部１１０の受信処理において、Linuxカーネル内のsock_def_readable４１０を用いる。さらに、スレッド起動部１６０として、try_to_wake_up４６０を用いる。また、要求部１２０が発行するハイパーバイザコールとしてPVOP_VCALL3４２０を用いる。さらに、スケジューリングキュー１７０としてrun_queue４７０を用いる。
　また、ＫＶＭ５００内のスケジューラ２３０として、schedule５３０を用いる。また、スケジューリングキュー２４０として、run_queue５４０を用いる。
　通常、sock_def_readable４１０は、Linux４００がＵＤＰパケット処理を終えてから当該パケット内のデータがユーザプログラムに渡される前に実行される関数である。sock_def_readable４１０は、自身の処理を実行した後にtry_to_wake_up４６０を実行してＵＤＰパケットを処理するアプリケーションを起動する。本実施形態では、sock_def_readable４１０がtry_to_wake_up４６０を実行する前にＳＩＰ処理増幅判定部を呼び出し、与えられているＣＰＵ時間を延長する場合、PVOP_VCALL3４２０を用いてハイパーバイザコールを発行するように動作する。これにより、Linux４００とＫＶＭ５００を基盤として、第１の実施形態に係る仮想計算機システムを実現することができる。
　なお、図１等に示した仮想計算機システムの各部は、図１７に例示するハードウエア資源において実現される。すなわち、図１７に示す構成は、プロセッサ５０、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）５１、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）５２、外部接続インタフェース５３および記憶装置５４を備える。各構成要素は、バス５５により接続されている。仮想計算機システムを実現するハードウエア構成は、図１７に示す構成に限定されない。
　図１等の各ブロックに示す機能は、各装置に対して、上述した機能を実現可能なコンピュータ・プログラムを供給した後、そのコンピュータ・プログラムを、プロセッサ５０がＲＡＭ５１に読み出して実行することによって実現されてもよい。あるいは、図１等の各ブロックに示す機能は、一部または全部を、ハードウエアとして実現されてもよい。
　係る供給されたコンピュータ・プログラムは、読み書き可能なメモリ（一時記憶媒体）またはハードディスク装置等のコンピュータ読み取り可能な記憶デバイスに格納すればよい。そして、このような場合において、本発明は、係るコンピュータ・プログラムを表すコード或いは係るコンピュータ・プログラムを格納した記憶媒体によって構成されると捉えることができる。
　なお、本発明において、下記の形態が可能である。
［形態１］
　上記第１の態様に係る仮想計算機システムのとおりである。
［形態２］
　前記ゲストＯＳは、受け付けたリクエストを処理するアプリケーションと前記アプリケーションを実行する仮想ＣＰＵの識別子を関連付けて保持する第１のキューを備え、
　前記要求部は、前記第１のキューを参照して、前記アプリケーションを実行する仮想ＣＰＵの識別子を特定し、特定した仮想ＣＰＵの識別子を含むハイパーバイザコールを発行する、
　形態１に記載の仮想計算機システム。
［形態３］
　前記ゲストＯＳは、受け付けたリクエストを蓄積する記憶部を備え、
　前記要求部は、前記記憶部に蓄積された未処理のリクエストの数が所定の数を超えた場合、または、前記記憶部に蓄積された未処理のリクエストの滞留期間が所定の期間を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵの識別子を含むハイパーバイザコールを発行する、
　形態１または２に記載の仮想計算機システム。
［形態４］
　前記ハイパーバイザは、優先度ごとに分類されたスレッドと前記スレッドを優先度に応じて実行する物理ＣＰＵを関連付けて保持する第２のキューを備え、
　前記変更部は、前記識別子に対応する仮想ＣＰＵを実現するスレッドが物理ＣＰＵで実行中である場合、当該スレッドの実行時間を延長し、それ以外の場合、当該スレッドの前記第２のキューにおける優先度、および／または、当該スレッドの前記第２のキューにおける順序を変更する、
　形態１ないし３のいずれか一に記載の仮想計算機システム。
［形態５］
　前記ゲストＯＳは、受け付けたリクエストの優先度を計算する優先度計算部を備え、
　前記要求部は、前記記憶部に蓄積された未処理のリクエストの優先度が所定の優先度を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵの識別子を含むハイパーバイザコールを発行する、
　形態１ないし４のいずれか一に記載の仮想計算機システム。
［形態６］
　前記ハイパーバイザは、前記要求部によって発行されるハイパーバイザコールの頻度が所定の頻度を超えた場合、警告を出力する警告部を備える、
　形態１ないし５のいずれか一に記載の仮想計算機システム。
［形態７］
　上記第２の態様に係るスケジューリング方法のとおりである。
［形態８］
　前記ゲストＯＳが、受け付けたリクエストを処理するアプリケーションと前記アプリケーションを実行する仮想ＣＰＵの識別子を関連付けて第１のキューに蓄積するステップと、
　前記第１のキューを参照して、前記アプリケーションを実行する仮想ＣＰＵの識別子を特定し、特定した仮想ＣＰＵの識別子を含むハイパーバイザコールを発行するステップと、を含む、
　形態７に記載のスケジューリング方法。
［形態９］
　前記ゲストＯＳが、受け付けたリクエストを記憶部に蓄積するステップと、
　前記記憶部に蓄積された未処理のリクエストの数が所定の数を超えた場合、または、前記記憶部に蓄積された未処理のリクエストの滞留期間が所定の期間を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵの識別子を含むハイパーバイザコールを発行するステップと、を含む、
　形態７または８に記載のスケジューリング方法。
［形態１０］
　前記ハイパーバイザが、優先度ごとに分類されたスレッドと前記スレッドを優先度に応じて実行する物理ＣＰＵを関連付けて第２のキューに蓄積するステップと、
　前記識別子に対応する仮想ＣＰＵを実現するスレッドが物理ＣＰＵで実行中である場合、当該スレッドの実行時間を延長し、それ以外の場合、当該スレッドの前記第２のキューにおける優先度、および／または、当該スレッドの前記第２のキューにおける順序を変更するステップと、を含む、
　形態７ないし９のいずれか一に記載のスケジューリング方法。
［形態１１］
　前記ゲストＯＳが、受け付けたリクエストの優先度を計算するステップと、
　前記記憶部に蓄積された未処理のリクエストの優先度が所定の優先度を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵの識別子を含むハイパーバイザコールを発行するステップと、を含む、
　形態７ないし１０のいずれか一に記載のスケジューリング方法。
［形態１２］
　前記ハイパーバイザが、前記ゲストＯＳによって発行されるハイパーバイザコールの頻度が所定の頻度を超えた場合、警告を出力するステップを含む、
　形態７ないし１１のいずれか一に記載のスケジューリング方法。
［形態１３］
　上記第３の態様に係るプログラムのとおりである。
［形態１４］
　前記ゲストＯＳが、受け付けたリクエストを処理するアプリケーションと前記アプリケーションを実行する仮想ＣＰＵの識別子を関連付けて第１のキューに蓄積する処理と、
　前記第１のキューを参照して、前記アプリケーションを実行する仮想ＣＰＵの識別子を特定し、特定した仮想ＣＰＵの識別子を含むハイパーバイザコールを発行する処理と、を前記コンピュータに実行させる、
　形態１３に記載のプログラム。
［形態１５］
　前記ゲストＯＳが、受け付けたリクエストを記憶部に蓄積する処理と、
　前記記憶部に蓄積された未処理のリクエストの数が所定の数を超えた場合、または、前記記憶部に蓄積された未処理のリクエストの滞留期間が所定の期間を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵの識別子を含むハイパーバイザコールを発行する処理と、を前記コンピュータに実行させる、
　形態１３または１４に記載のプログラム。
［形態１６］
　前記ハイパーバイザが、優先度ごとに分類されたスレッドと前記スレッドを優先度に応じて実行する物理ＣＰＵを関連付けて第２のキューに蓄積する処理と、
　前記識別子に対応する仮想ＣＰＵを実現するスレッドが物理ＣＰＵで実行中である場合、当該スレッドの実行時間を延長し、それ以外の場合、当該スレッドの前記第２のキューにおける優先度、および／または、当該スレッドの前記第２のキューにおける順序を変更する処理と、を前記コンピュータに実行させる、
　形態１３ないし１５のいずれか一に記載のプログラム。
［形態１７］
　前記ゲストＯＳが、受け付けたリクエストの優先度を計算する処理と、
　前記記憶部に蓄積された未処理のリクエストの優先度が所定の優先度を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵの識別子を含むハイパーバイザコールを発行する処理と、を前記コンピュータに実行させる、
　形態１３ないし１６のいずれか一に記載のプログラム。
［形態１８］
　前記ハイパーバイザが、前記ゲストＯＳによって発行されるハイパーバイザコールの頻度が所定の頻度を超えた場合、警告を出力する処理を前記コンピュータに実行させる、
　形態１３ないし１７のいずれか一に記載のプログラム。
　なお、上記特許文献の全開示内容は、本書に引用をもって繰り込み記載されているものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。
　この出願は、２０１４年７月３１日に出願された日本出願特願２０１４－１５６５６３を基礎とする優先権を主張し、その開示の全てをここに取り込む。
　本発明に係る仮想計算機システム、スケジューリング方法、および、プログラム記憶媒体は、一例として、電話サービスを仮想マシンで提供するＮＦＶ（Network Functions Virtualization）の分野において、電話サービスの品質安定化といった用途に適用することができる。
１　　仮想計算機システム
２　　物理計算機
３　　ＶＭＭ
４　　ハードウェア
５　　仮想計算機
６　　ゲストＯＳ
７　　ゲストＯＳインターフェイス部
８　　ゲストＯＳ依存関係作成モジュール
９　　ゲストＯＳ依存関係テーブル
１０　　ディスパッチャ
１１　　ＣＰＵ割り当てテーブル
１３　　ＣＰＵ
１２　　ゲストＯＳスケジューラ
１４　　ＣＰＵ割り当てテーブル管理部
１５　　判定部
１６　　サーバゲストＯＳスケジュール部
１７　　クライアントゲストＯＳ探索部
１８　　クライアントゲストＯＳスケジュール部
２０　　ゲストＯＳ
２２　　要求部
３０　　ハイパーバイザ
３２　　変更部
１００　　ゲストＯＳ
１１０　　ＵＤＰパケット送受信部
１２０　　要求部
１３０　　滞留量取得部
１４０　　ＳＩＰ処理増幅判定部
１５０　　滞留リクエスト記憶部
１５１　　滞留リクエスト識別子
１５２　　滞留期間
１５３　　優先度
１６０　　スレッド起動部
１７０　　スケジューリングキュー
１８０　　優先度計算部
１９０　　優先度表
１９１　　電話番号
１９２　　優先度
２００　　ハイパーバイザ
２１０　　受付部
２２０　　実行時間変更部
２３０　　スケジューラ
２４０　　スケジューリングキュー
２５０　　実行優先度変更部
２６０　　実行キュー並べ替え部
２７０　　限界負荷警告部
２８０　　実行履歴記憶部
３００　　仮想マシン
４００　　Linux
４１０　　sock_def_readable
４２０　　PVOP_VCALL3
４６０　　try_to_wake_up
４７０　　run_queue
５００　　ＫＶＭ
５３０　　schedule
５４０　　run_queue

Claims (15)

  1. 　ゲストＯＳ（Operating System）とハイパーバイザを備え、
    　前記ゲストＯＳは、
    　受け付けたリクエストを蓄積する記憶手段と、
    　前記記憶手段に蓄積された未処理のリクエストの数が所定の数を超えた場合、または、前記記憶手段に蓄積された未処理のリクエストの滞留期間が所定の期間を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵ（Central Processing Unit）の識別子を含むハイパーバイザコールを、前記ハイパーバイザに対して発行する要求手段とを有し、
    　前記ハイパーバイザは、
    　前記識別子に対応する仮想ＣＰＵを実現するスレッドに割り当てられた物理ＣＰＵの実行時間を変更する変更手段を有する
    　仮想計算機システム。
  2. 　前記ゲストＯＳは、前記受け付けたリクエストを処理するアプリケーションと前記アプリケーションを実行する仮想ＣＰＵの識別子を関連付けて保持する第１のキューを備え、
    　前記要求手段は、前記第１のキューを参照して、前記アプリケーションを実行する仮想ＣＰＵの識別子を特定し、特定した前記仮想ＣＰＵの識別子を含むハイパーバイザコールを発行する、
    　請求項１に記載の仮想計算機システム。
  3. 　前記ハイパーバイザは、優先度ごとに分類されたスレッドと前記スレッドを優先度に応じて実行する物理ＣＰＵを関連付けて保持する第２のキューを備え、
    　前記変更手段は、前記識別子に対応する仮想ＣＰＵを実現するスレッドが物理ＣＰＵで実行中である場合、当該スレッドの実行時間を延長し、それ以外の場合、少なくとも当該スレッドの前記第２のキューにおける優先度および当該スレッドの前記第２のキューにおける順序のいずれかを変更する、
    　請求項１または２に記載の仮想計算機システム。
  4. 　前記ゲストＯＳは、前記受け付けたリクエストの優先度を計算する優先度計算手段を備え、
    　前記要求手段は、前記記憶手段に蓄積された未処理のリクエストの優先度が所定の優先度を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵの識別子を含むハイパーバイザコールを発行する、
    　請求項１ないし３のいずれか１項に記載の仮想計算機システム。
  5. 　前記ハイパーバイザは、前記要求手段によって発行されるハイパーバイザコールの頻度が所定の頻度を超えた場合、警告を出力する警告手段を備える、
    　請求項１ないし４のいずれか１項に記載の仮想計算機システム。
  6. 　ゲストＯＳ（Operating System）が、受け付けたリクエストを記憶手段に蓄積し、
    　前記記憶手段に蓄積された未処理のリクエストの数が所定の数を超えた場合、または、前記記憶手段に蓄積された未処理のリクエストの滞留期間が所定の期間を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵ（Central Processing Unit）の識別子を含むハイパーバイザコールを、ハイパーバイザに対して発行し、
    　前記ハイパーバイザが、前記識別子に対応する仮想ＣＰＵを実現するスレッドに割り当てられた物理ＣＰＵの実行時間を変更する、
    　スケジューリング方法。
  7. 　前記ゲストＯＳが、前記受け付けたリクエストを処理するアプリケーションと前記アプリケーションを実行する仮想ＣＰＵの識別子を関連付けて第１のキューに蓄積し、
    　前記第１のキューを参照して、前記アプリケーションを実行する仮想ＣＰＵの識別子を特定し、特定した前記仮想ＣＰＵの識別子を含むハイパーバイザコールを発行する、
    　請求項６に記載のスケジューリング方法。
  8. 　前記ハイパーバイザは、優先度ごとに分類されたスレッドと前記スレッドを優先度に応じて実行する物理ＣＰＵを関連付けて第２のキューに蓄積し、
    　前記識別子に対応する仮想ＣＰＵを実現するスレッドが物理ＣＰＵで実行中である場合、当該スレッドの実行時間を延長し、それ以外の場合、少なくとも当該スレッドの前記第２のキューにおける優先度および当該スレッドの前記第２のキューにおける順序のいずれかを変更する、
    　請求項６または７に記載のスケジューリング方法。
  9. 　前記ゲストＯＳは、前記受け付けたリクエストの優先度を計算し、
    　前記記憶手段に蓄積された未処理のリクエストの優先度が所定の優先度を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵの識別子を含むハイパーバイザコールを発行する、
    　請求項６ないし８のいずれか１項に記載のスケジューリング方法。
  10. 　前記ハイパーバイザは、前記発行されるハイパーバイザコールの頻度が所定の頻度を超えた場合、警告を出力する、
    　請求項６ないし９のいずれか１項に記載のスケジューリング方法。
  11. 　ゲストＯＳ（Operating System）が、受け付けたリクエストを記憶手段に蓄積する処理と、
    　前記記憶手段に蓄積された未処理のリクエストの数が所定の数を超えた場合、または、前記記憶部に蓄積された未処理のリクエストの滞留期間が所定の期間を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵ（Central Processing Unit）の識別子を含むハイパーバイザコールをハイパーバイザに対して発行する処理と、
    　前記ハイパーバイザが、前記識別子に対応する仮想ＣＰＵを実現するスレッドに割り当てられた物理ＣＰＵの実行時間を変更する処理と、
    　をコンピュータに実行させる、コンピュータ・プログラムを記憶したプログラム記憶媒体。
  12. 　前記ゲストＯＳが、前記受け付けたリクエストを処理するアプリケーションと前記アプリケーションを実行する仮想ＣＰＵの識別子を関連付けて第１のキューに蓄積する処理と、
    　前記第１のキューを参照して、前記アプリケーションを実行する仮想ＣＰＵの識別子を特定し、特定した前記仮想ＣＰＵの識別子を含むハイパーバイザコールを発行する処理と、
    　をコンピュータに実行させる、請求項１１に記載のコンピュータ・プログラムを記憶したプログラム記憶媒体。
  13. 　前記ハイパーバイザは、優先度ごとに分類されたスレッドと前記スレッドを優先度に応じて実行する物理ＣＰＵを関連付けて第２のキューに蓄積する処理と、
    　前記識別子に対応する仮想ＣＰＵを実現するスレッドが物理ＣＰＵで実行中である場合、当該スレッドの実行時間を延長し、それ以外の場合、少なくとも当該スレッドの前記第２のキューにおける優先度および当該スレッドの前記第２のキューにおける順序のいずれかを変更する処理と、
    　をコンピュータに実行させる、請求項１１または１２に記載のコンピュータ・プログラムを記憶したプログラム記憶媒体。
  14. 　前記ゲストＯＳは、前記受け付けたリクエストの優先度を計算する処理と、
    　前記記憶手段に蓄積された未処理のリクエストの優先度が所定の優先度を超えた場合、前記未処理のリクエストを処理するアプリケーションを実行する仮想ＣＰＵの識別子を含むハイパーバイザコールを発行する処理と、
    　をコンピュータに実行させる、請求項１１ないし１３のいずれか１項に記載のコンピュータ・プログラムを記憶したプログラム記憶媒体。
  15. 　前記ハイパーバイザは、前記発行されるハイパーバイザコールの頻度が所定の頻度を超えた場合、警告を出力する処理
    　をコンピュータに実行させる、請求項１１ないし１４のいずれか１項に記載のコンピュータ・プログラムを記憶したプログラム記憶媒体。
PCT/JP2015/003798 2014-07-31 2015-07-29 仮想計算機システム、スケジューリング方法、および、プログラム記憶媒体 WO2016017161A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2014-156563 2014-07-31
JP2014156563A JP2017199044A (ja) 2014-07-31 2014-07-31 仮想計算機システム、スケジューリング方法、および、プログラム

Publications (1)

Publication Number Publication Date
WO2016017161A1 true WO2016017161A1 (ja) 2016-02-04

Family

ID=55217073

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/003798 WO2016017161A1 (ja) 2014-07-31 2015-07-29 仮想計算機システム、スケジューリング方法、および、プログラム記憶媒体

Country Status (2)

Country Link
JP (1) JP2017199044A (ja)
WO (1) WO2016017161A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111324438A (zh) * 2020-02-18 2020-06-23 北京嘀嘀无限科技发展有限公司 请求的调度方法、装置、存储介质及电子设备

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI756974B (zh) 2020-12-09 2022-03-01 財團法人工業技術研究院 機器學習系統及其資源配置方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09106358A (ja) * 1995-10-12 1997-04-22 Hitachi Ltd 仮想計算機システムのスケジューリング方法および装置
JP2002202959A (ja) * 2000-12-28 2002-07-19 Hitachi Ltd 動的な資源分配をする仮想計算機システム
US7752623B1 (en) * 2004-09-16 2010-07-06 Hewlett-Packard Development Company, L.P. System and method for allocating resources by examining a system characteristic

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09106358A (ja) * 1995-10-12 1997-04-22 Hitachi Ltd 仮想計算機システムのスケジューリング方法および装置
JP2002202959A (ja) * 2000-12-28 2002-07-19 Hitachi Ltd 動的な資源分配をする仮想計算機システム
US7752623B1 (en) * 2004-09-16 2010-07-06 Hewlett-Packard Development Company, L.P. System and method for allocating resources by examining a system characteristic

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111324438A (zh) * 2020-02-18 2020-06-23 北京嘀嘀无限科技发展有限公司 请求的调度方法、装置、存储介质及电子设备
CN111324438B (zh) * 2020-02-18 2023-09-19 北京嘀嘀无限科技发展有限公司 请求的调度方法、装置、存储介质及电子设备

Also Published As

Publication number Publication date
JP2017199044A (ja) 2017-11-02

Similar Documents

Publication Publication Date Title
EP3567829B1 (en) Resource management method and apparatus
CN109564528B (zh) 分布式计算中计算资源分配的系统和方法
US9525644B2 (en) Method and system for managing resources among different clients for an exclusive use
JP6449872B2 (ja) ネットワーク環境における効率的なパケット処理モデルおよびパケット処理のための最適化されたバッファ利用をサポートするためのシステムおよび方法
CN107800768B (zh) 开放平台控制方法和系统
EP2701074B1 (en) Method, device, and system for performing scheduling in multi-processor core system
KR102128357B1 (ko) 주소 할당 방법, 게이트웨이 및 시스템
CN112783659B (zh) 一种资源分配方法、装置、计算机设备及存储介质
JP6636142B2 (ja) スケールアウト関連付けの方法および装置、ならびにシステム
WO2013117136A1 (zh) 一种基于容量的多任务调度方法、设备及系统
JP2015144020A5 (ja)
WO2016061935A1 (zh) 一种资源调度方法、装置及计算机存储介质
US9342369B2 (en) System and method for increasing throughput of a PaaS system
WO2018107945A1 (zh) 一种实现硬件资源分配的方法、装置及存储介质
US8458702B1 (en) Method for implementing user space up-calls on java virtual machine before/after garbage collection
CN108028806B (zh) 网络功能虚拟化nfv网络中分配虚拟资源的方法和装置
WO2016017161A1 (ja) 仮想計算機システム、スケジューリング方法、および、プログラム記憶媒体
CN109426561A (zh) 一种任务处理方法、装置及设备
JP6047941B2 (ja) タスク実行順序制御機能を含む監視制御システム
WO2017070869A1 (zh) 一种内存配置方法、装置及系统
KR101491689B1 (ko) 다중 사용자를 위한 자원 할당 방법 및 장치
JP6158751B2 (ja) 計算機資源割当装置及び計算機資源割当プログラム
JP6204287B2 (ja) 分散処理方法、処理サーバ、および、プログラム
JP6059259B2 (ja) 計算機システム及び計算機リソースの割当方法
JP6511006B2 (ja) リソース割当管理装置および割当て先サーバ決定方法

Legal Events

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

Ref document number: 15826845

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: 15826845

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP