WO2009147738A1 - 情報処理装置及びその制御方法並びにモニタプログラム - Google Patents

情報処理装置及びその制御方法並びにモニタプログラム Download PDF

Info

Publication number
WO2009147738A1
WO2009147738A1 PCT/JP2008/060336 JP2008060336W WO2009147738A1 WO 2009147738 A1 WO2009147738 A1 WO 2009147738A1 JP 2008060336 W JP2008060336 W JP 2008060336W WO 2009147738 A1 WO2009147738 A1 WO 2009147738A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
operating system
physical register
processing device
program
Prior art date
Application number
PCT/JP2008/060336
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 JP2010515714A priority Critical patent/JPWO2009147738A1/ja
Priority to PCT/JP2008/060336 priority patent/WO2009147738A1/ja
Publication of WO2009147738A1 publication Critical patent/WO2009147738A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0778—Dumping, i.e. gathering error/state information after a fault for later diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0712—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a virtual computing platform, e.g. logically partitioned systems

Definitions

  • the present invention relates to a technique for detecting the cause of a malfunction in an information processing apparatus.
  • the dump of memory contents and register contents is collected while the information processing device is slowed down. Is identified.
  • tools such as flight recorders are used to collect trace data such as parameters to functions, return values from functions, and error conditions during program operation. Elucidate the behavior of the program by analyzing the data.
  • JP 2002-32244 A Japanese Patent Laid-Open No. 04-1834 JP 2000-259435 A IBM, iSeries Information Center, Flight Recorder, Internet, ⁇ http://publib.boulder.ibm.com/html/as400/v5r1/ic2962/index.htm?info/rzahw/rzahwflyco.htm>, search date 2008.03.18
  • the above method of collecting dumps can only collect the state at a certain point in time, and the cause may not be investigated depending on the timing of collection. For example, if lock contention is generated and resolved intermittently, even if the overall slowdown occurs, lock contention is resolved instantaneously, and the contention is resolved if a dump is collected. If you do, you can not find the cause.
  • the information processing apparatus in order to collect a dump, the information processing apparatus must be completely stopped when a slowdown occurs so that the contents of the memory and registers are not rewritten. That is, the business must be stopped, and there is a great disadvantage. In particular, the system that continues to work while slowing down will be stopped, and damage will be spread.
  • the monitor program obtains information for investigating the cause of the malfunction by referring to the information of the first OS.
  • the information processing apparatus of the present case is A processing unit having a physical register; A first operating system having first information, holding the first information in the physical register, and operating an application program; The second information is stored, the second information is held in the physical register, the instruction issued by the first operating system to the processing device is controlled, and the information included in the physical register is stored.
  • a monitor program to refer to The processing device executes each while switching, When the processing device is executing the monitor program, the information held in the physical register is changed from the second information to the first information, and the processing device holds in the physical register.
  • the first information is referred to.
  • FIG. 1 Schematic diagram of information processing apparatus according to an embodiment Hardware configuration diagram of information processing device Illustration of the area allocated to physical memory Explanatory diagram of dispatch in the embodiment Figure showing the flow to get a snapshot during dispatch Figure showing snapshot collection processing Figure showing an example of a snapshot Diagram showing the configuration of the physical register from which the snapshot is acquired Diagram showing the configuration of physical memory from which snapshots are acquired Explanation of snapshot storage and report
  • FIG. 1 is a schematic diagram of an information processing apparatus according to the present embodiment.
  • the information processing apparatus 10 of this example operates as a virtual machine (VM) system in which a host OS operates a plurality of guest OSs via a hypervisor.
  • VM virtual machine
  • FIG. 2 is a hardware configuration diagram of the information processing apparatus 10.
  • the information processing apparatus 10 is a computer including a processing device (for example, CPU: central processing unit) 11, a main memory 12, and an input / output interface 13.
  • the input / output interface 13 includes a storage device (hard disk) 14 that stores data and software for arithmetic processing, a communication control unit (CCU: Communication Control Unit) 15 that controls communication with other computers, and a console (CON). 16 is connected.
  • the console 16 has an operation unit (keyboard or the like) for performing an input operation by an operator and a display unit for performing display output.
  • the information processing apparatus 10 performs processing according to a program read by the CPU 11 from the storage device (recording medium) 14. That is, programs such as a host OS (second OS), a driver OS (third OS), a hypervisor (monitor program), a guest OS (first OS), a front-end driver, and a back-end driver are described later. By causing the information processing apparatus to execute processing, a virtual machine (VM system) is realized.
  • a host OS second OS
  • driver OS third OS
  • hypervisor monitor program
  • guest OS first OS
  • front-end driver a front-end driver
  • back-end driver a back-end driver
  • the host OS is automatically activated when the VM system (information processing apparatus 10) is activated, and operates as a domain 0.
  • the host OS is an OS for operating and managing the entire VM system including the driver domain and the guest domain. Note that the host OS can also operate as a driver OS.
  • the hypervisor performs dispatch of each OS, emulation of privileged instructions executed by each OS, hardware control related to the CPU 11, and the like. Note that the hypervisor may include a host OS.
  • the driver OS controls I / O devices such as the storage device 14, the communication control unit 15, and the console 16.
  • I / O devices such as the storage device 14, the communication control unit 15, and the console 16.
  • a plurality of guest OSs do not have I / O devices, but request the input / output of each guest OS to the driver OS, and the driver OS performs the input / output of each guest OS. Control is virtualized.
  • an FE (front end) driver is hyperlinked.
  • the information is transmitted to the visor, and the driver OS receives the information from the hypervisor via the back-end driver.
  • the driver OS sends the received information to the I / O device by the actual driver, and actually performs I / O control.
  • the driver OS when receiving information from the I / O device via the actual driver, the driver OS transmits the information to the hypervisor via the back-end driver, and the guest OS passes the information via the front-end driver. Receive from the hypervisor.
  • the driver OS can also operate on the host OS and the guest OS.
  • the driver OS When the driver OS is operated on the guest OS, the OS becomes the driver OS.
  • the guest OS virtually implements the functions of the information processing apparatus using hardware resources allocated via the hypervisor. That is, each guest OS is the same as an OS installed in a normal information processing apparatus, and a plurality of guest OSs realize the functions (domain U) of a plurality of information processing apparatuses.
  • ⁇ Regarding physical memory allocation In the physical memory 12, as shown in FIG. 3, areas are allocated to the host OS, the driver OS, and the guest OS, respectively.
  • the hypervisor controls the memory access of each OS so that each OS accesses each area. For example, when the guest OS accesses a certain address, the hypervisor converts the address on the guest OS to the address on the memory 12 assigned to the guest OS, thereby controlling the memory access of each guest OS. .
  • the hypervisor operates using the memory area allocated for the hypervisor, but can also access other memory areas.
  • the host OS and driver OS can also access memory areas assigned to other OSs by receiving permission from the hypervisor.
  • the hypervisor activates the dispatcher in response to an interrupt from a timer inside the CPU or an external physical device. That is, the CPU 11 functions as a dispatcher (switching unit).
  • the dispatcher switches domains at a predetermined timing, that is, changes the guest OS assigned to the CPU.
  • FIG. 4 is an explanatory diagram of dispatch according to this embodiment.
  • the dispatcher operates the OS (step 1, also abbreviated as S1 hereinafter), and when an interrupt occurs (S2), returns control to the hypervisor (S3).
  • the dispatcher stores the register information in the CPU 11 when the OS is operating in an area managed by the hypervisor in the memory 12 (S4). That is, the first information held by the guest OS in the register, the third information held by the host OS in the register, or the fourth information held by the driver OS in the register is saved in the memory. . Further, the second information used by the hypervisor is read from the memory 12 and held in the physical register of the CPU 11.
  • the dispatcher determines whether or not it is time to change (dispatch) the allocation of the guest OS (S5).
  • the dispatcher selects the OS to be dispatched when it is time to dispatch (S6), reads the register information of the OS from the memory 12 and reflects it in the CPU 11 (S7), and returns to step 1 to Run the OS. If it is not time to dispatch in step 5, the process returns to step 1 without dispatching.
  • the hypervisor (virtual computer monitor) allocates the physical CPU to the guest OS at a certain time interval to virtualize the CPU.
  • a certain time for example, 10 milliseconds
  • control is always returned to the hypervisor, and the hypervisor can refer to the contents of the register and memory of the guest OS at that time.
  • the hypervisor activates the debugger and causes the CPU 11 to function as a snap acquisition unit, and collects and records the guest OS state (information in the register and memory) as a snapshot to investigate the cause of the slowdown. Get information about.
  • FIG. 6 is an explanatory diagram of the snapshot collection process (S20) of FIG.
  • the hypervisor determines whether the OS that was operating immediately before the control returns, that is, the OS that was operated in step S1, is the guest OS subject to snapshot (S21).
  • a predetermined snapshot collection interval For example, if a snapshot is acquired every 10 milliseconds, the amount of information becomes enormous, so an appropriate collection interval is set. In this example, it is acquired at intervals of 5 seconds.
  • the hypervisor changes the hypervisor register so that the memory of the guest OS can be referred to by a virtual address (S23).
  • the hypervisor starts the debugger (S24) and prepares to collect guest OS information.
  • the debugger acquires the state (first information) of the guest OS as a snapshot (S25) and stores it in the memory 12 (S26).
  • the hypervisor or the host OS reports on the snapshot (S27).
  • the snapshot collects information on items such as domain, register, backtrace, ps, task, irq, log, and virtual memory.
  • Each item of snapshot shows the following information.
  • the snapshot acquires first information by referring to a physical register in the CPU 11.
  • the register may be referred to indirectly by reading from the memory 12 the first information transferred from the register in the CPU 11 to the memory 12 during dispatch.
  • the debugger of this example starts from a physical register in the CPU 11, an area allocated to the guest OS in the memory 12 shown in FIG. Take a snapshot.
  • FIG. 8 is a diagram illustrating a configuration of a physical register from which a snapshot is acquired.
  • the physical register of the CPU 11 includes a general register, a control register, a branch register, and an application register.
  • the debugger acquires a part of the back trace information and a part of the interrupt (irq) information from the physical register.
  • FIG. 9 is a diagram showing the configuration of the physical memory from which the snapshot is acquired.
  • the memory 12 has areas for a hypervisor, a host OS, and a guest OS.
  • the debugger acquires part of domain information and interrupt information from the hypervisor and host OS areas.
  • the debugger acquires a part of log, task, process, backtrace information, and part of interrupt information from the guest OS area on the memory 12.
  • FIG. 10 shows an example in which the host OS, driver OS, and hypervisor are independent.
  • the hypervisor activates the debugger and acquires a snapshot (FIG. 6, S25)
  • the acquired snapshot is saved (stored) in the shared memory of the host OS and the hypervisor or in the memory in the hypervisor, and the host OS Notify
  • the host OS Upon receiving the notification, the host OS activates the report program and outputs a snapshot. That is, the CPU 11 functions as a report unit according to the report program.
  • the report unit may simply output the snapshot stored in the memory as a report, or may analyze the snapshot and output the analysis result as a report. When outputting, the host OS transfers the created report to the driver OS.
  • the driver OS performs output processing such as writing the report to a local disk using a real I / O driver, displaying the report on a display unit, and transferring the report to another computer via a network.
  • FIG. 11 shows an example using a host OS that can also operate as a driver OS.
  • the report unit of the host OS creates a report based on the snapshot stored in the memory, and performs processing until the report is output using the real I / O driver.
  • FIG. 12 shows an example using a host OS built-in hypervisor.
  • a snapshot is acquired, a report program is started, and all operations up to analysis and output are performed in the hypervisor.
  • FIG. 13 shows an example of notification when the storage physical memory is used up.
  • a storage area is set in which N snapshots can be stored.
  • N snapshots can be stored sequentially in the storage area as the first time, second time, third time, etc., and when the Nth time is saved, the host OS or hypervisor Notify
  • the host OS or hypervisor Upon receiving this notification, the host OS or hypervisor activates the report program, analyzes the snapshot, and creates a report.
  • FIG. 14 is a diagram illustrating a specific example when a slowdown occurs.
  • Process A repeatedly acquires and releases a large amount of memory.
  • A1 and A3 indicate a large amount of memory acquisition, and A2 indicates a large amount of memory release.
  • Process B performs an operation of acquiring memory at a certain timing. In FIG. 14, the memory is acquired by B1 and B3.
  • the process B performs a busy wait using the CPU until the memory can be acquired. In FIG. 14, the memory acquisition fails at B1, and the busy wait is performed until the memory can be acquired at B2.
  • the process B is busy waiting, the process A releases the memory, so both the processes A and B are delayed and a slowdown occurs.
  • slowdown occurs in the period R1 from the operation B1 to B2 of the process B and the period R3 after the operation B3. That is, process A releases a large amount of memory (A2), process B acquires memory (B2), process A acquires a large amount of memory again (A3), and process B fails to acquire memory During the period R2 up to B3, the busy wait is eliminated.
  • FIGS. 15 and 16 show examples of snapshots acquired second time in FIG.
  • Examples of report conditions for analyzing whether snapshot data collected at each timing and determining whether to send a report are shown below.
  • character strings such as “warning” and “error” in the message log.
  • memories usage of the entire system is high M times or more in N times of vm information.
  • memories usage of the entire system is high M times or more in N times of vm information.
  • FIG. 17 illustrates the processing of the report of FIG.
  • the debugger determines whether or not a predetermined number of snapshots have been acquired (S31). If the predetermined number of snapshots (N times) has been acquired (S31 Yes), the debugger notifies the report unit (S32).
  • the report unit statistically processes the N snapshots (S33), and determines whether or not the snapshot meets the predetermined report condition (S34).
  • the report unit extracts information on the conforming portion and adds it to the N snapshots to create a report (S35).
  • the report unit outputs the created report (S36). For example, if the configuration is such that the driver OS and the host OS are separated, the report unit passes the report to the driver OS, and the driver OS outputs it to a storage, a display, another computer, etc. using the actual driver.
  • FIGS. 18 and 19 show examples of information in which locations corresponding to report conditions are summarized.
  • back trace information when the same register information is obtained M times in N snapshots is extracted as request_memory ()-> alloc_memory ()-> wait_loop ().
  • process A 30%: 5%
  • process name of the process that had high CPU usage and memory usage by N snapshots and the memory usage and CPU usage list.
  • B Extract as 7%: 90%.
  • the cause of the problem can be easily solved based on the snapshot.
  • the probability that the snapshot can be collected at the timing of falling down is very high.
  • the snapshot is collected while the guest OS is running, there is no need to stop the business.
  • the cause is identified from the collected snapshots, it is possible to take measures such as stopping the application causing the problem, and there is an advantage that it can be solved while the slowdown itself is operated.
  • the guest OS does not collect the snapshot, but the hypervisor collects the snapshot when the guest OS is dispatched. In other words, since the guest OS can operate normally while taking a snapshot, there is no influence on the work to be performed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Debugging And Monitoring (AREA)

Abstract

　第１のオペレーティングシステム（ＯＳ）の不具合の原因を解明するためのスナップショットを第１のＯＳの処理を継続したまま取得する。物理レジスタを有する処理装置を備えた情報処理装置において、第１のＯＳが用いる第１の情報を前記物理レジスタに保持するとともに、処理装置が、物理レジスタに保持する情報をモニタプログラムが用いてる第２の情報から第１のＯＳが用いる第１の情報に変更するとともに、前記処理装置が、前記物理レジスタに保持された前記第１の情報を参照する。

Description

情報処理装置及びその制御方法並びにモニタプログラム
　本発明は、情報処理装置における不具合の原因を検出する技術に関する。
　従来、情報処理装置おいて、ハードウェア資源や並行するアプリケーションプログラムの動作状況によっては、不都合が生じることがあった。
　この不都合としては、例えば、アプリケーションの動作に時間が掛かったり、レスポンスが低下したりといったスローダウンが、比較的発生し易い。
　スローダウンに陥る原因としては、以下のケースが多く見られる。
　１．メモリやＩ／Ｏ等のハードウェア資源の取得に競合が発生し、資源待ち状態になった場合。
　２．複数アプリケーション間でのロック競合が発生し、ロック獲得に時間を要し、処理が進まない場合。
　スローダウンが発生すると、レスポンスの悪化等の現象が現れるため、発生したことは容易に判断可能であるが、発生原因はプログラムの動作に依拠するので、現れた現象から単純に判断することはできない。
　このため、原因を究明し対処を行うためには、ダンプの採取や動作のトレースといった手法が採られる。
　ダンプを採取する手法では、情報処理装置がスローダウンとなっている状態でメモリの内容やレジスタの内容のダンプを採取し、その内容から動作しているプログラムと処理を推測し、スローダウンの原因を特定する。
　また、プログラムの動作をトレースする手法では、フライトレコーダーに代表されるツールで、プログラムの動作中に関数へのパラメタや関数からの戻り値、エラー条件などのトレースデータを採取し、この採取したトレースデータを解析することでプログラムの動作を解明する。
　例えば、下記の文献に開示される技術がある。
特開２００２－３２２４４号公報 特開平０４－１８３４号公報 特開２０００－２５９４３５号公報 ＩＢＭ、iSeries Information Center、フライトレコーダー、インターネット、〈http://publib.boulder.ibm.com/html/as400/v5r1/ic2962/index.htm?info/rzahw/rzahwflyco.htm〉、検索日2008.03.18
　上記ダンプを採取する手法では、ある一時点の状態を採取できるだけであり、採取のタイミングによっては原因の究明に至らないこともある。例えば、ロック競合の発生と解消が断続的に繰り返されている場合、全体的なスローダウンが生じていても、瞬間的にはロック競合が解消しており、ダンプを採取した時にもし競合が解消していたら原因を究明できない。
　また、ダンプを採取するためには、メモリやレジスタの内容が書き換わらないように、スローダウンが生じた時点で情報処理装置を完全に停止させなければならない。即ち、業務を停止させなければならず、不利益が大きい。特に、スローダウンしつつも業務を続けているシステムを停止することとなり、ダメージを広げてしまう。
　更に、容量が数ＴＢのメモリのダンプを磁気記録媒体へ出力する作業は、数時間かかるため、安易にダンプの取得を繰り返せるものではない。
　また、上記プログラムの動作をトレースする手法では、トレースデータを採取すること自体がオーバヘッドとなり、スローダウンに拍車をかけてしまう可能性が高い。
　逆に、トレースデータを採取する動作が追加されることで、プログラムの動作タイミングが変化して、スローダウンが起きなくなり、原因の究明ができなくなる可能性もある。
　さらに、トレース機能自体のソフトウェア障害（バグ）により、業務が正常にできなくなる可能性がある。
　そこで、モニタプログラムが第１のＯＳの情報を参照することにより、不具合の原因究明のための情報を取得する技術を提供する。
　上記課題を解決するため、本件の情報処理装置は、
　物理レジスタを有する処理装置を備え、
　第１の情報を有し、前記第１の情報を前記物理レジスタに保持するとともに、アプリケーションプログラムを動作させる第１のオペレーティングシステムと、
　第２の情報を有し、前記第２の情報を前記物理レジスタに保持するとともに、前記第１のオペレーティングシステムが前記処理装置に対して発行する命令の制御を行い、前記物理レジスタが有する情報を参照するモニタプログラムと、
　を前記処理装置が、それぞれ切り替えながら実行するとともに、
　前記処理装置が、前記モニタプログラムを実行している場合に、前記物理レジスタに保持する情報を前記第２の情報から前記第１の情報に変更するとともに、前記処理装置が、前記物理レジスタに保持された前記第１の情報を参照する。
　本件で開示の物又は方法によれば、第１のオペレーティングシステム（ＯＳ）の不具合の原因を解明するためのスナップショットを第1のＯＳの処理を継続したまま取得する技術を提供できる。
実施例に係る情報処理装置の概略図 情報処理装置のハードウェア構成図 物理メモリに割り当てられた領域の説明図 実施例のディスパッチの説明図 ディスパッチ時にスナップショットを取得するフローを示す図 スナップショット採取の処理を示す図 スナップショットの例を示す図 スナップショットの取得元である物理レジスタの構成を示す図 スナップショットの取得元である物理メモリの構成を示す図 スナップショットの格納及びレポートの説明図 ドライバＯＳとしても動作可能なホストＯＳを用いた例を示す図 ホストＯＳ内蔵型のハイパーバイザを用いた例を示す図 レポートを作成するタイミングを通知する例を示す図 スローダウンが発生した場合の具体例を示す図 スナップショットの例を示す図 スナップショットの例を示す図 レポートの処理の説明図 レポート条件に該当した箇所をまとめた情報の例を示す図 レポート条件に該当した箇所をまとめた情報の例を示す図
　図１は、本実施例に係る情報処理装置の概略図である。図１に示すように、本例の情報処理装置１０は、ホストＯＳがハイパーバイザを介して複数のゲストＯＳを動作させる仮想計算機（ＶＭ：Virtual Machine）システムとして動作する。
　図２は、情報処理装置１０のハードウェア構成図である。図２に示すように、情報処理装置１０は、処理装置（例えばＣＰＵ：central processing unit）１１や、メインメモリ１２、入出力インタフェース１３を備えたコンピュータである。
　入出力インタフェース１３には、演算処理の為のデータやソフトウェアを記憶した記憶装置（ハードディスク）１４、他のコンピュータとの通信を制御する通信制御部（ＣＣＵ：Communication Control Unit）１５、コンソール（ＣＯＮ）１６が接続されている。また、コンソール１６は、オペレータによる入力操作を行う操作部（キーボード等）や表示出力を行う表示部を有している。
　情報処理装置１０は、ＣＰＵ１１が記憶装置（記録媒体）１４から読み出したプログラムに従って処理を行う。即ち、ホストＯＳ（第２のＯＳ）、ドライバＯＳ（第３のＯＳ）、ハイパーバイザ（モニタプログラム）、ゲストＯＳ（第１のＯＳ）、フロントエンドドライバ、バックエンドドライバ等のプログラムが、後述の処理を情報処理装置に実行させることで、仮想計算機（ＶＭシステム）を実現させている。
　ホストＯＳは、ＶＭシステム（情報処理装置１０）の起動が開始されると自動で起動され、ドメイン０として動作する。ホストＯＳは、ドライバドメインやゲストドメインなどを含めたＶＭシステム全体の操作、管理を行うためのＯＳである。なお、ホストＯＳは、ドライバＯＳとしても動作可能である。
　ハイパーバイザは、各ＯＳのディスパッチや、各ＯＳが実行する特権命令のエミュレーション、ＣＰＵ１１に関するハードウェア制御等を行う。なお、ハイパーバイザがホストＯＳを含んでも良い。
　ドライバＯＳは、記憶装置１４や通信制御部１５、コンソール１６等のＩ／Ｏ装置を制御する。ＶＭシステムにおいては、複数のゲストＯＳがそれぞれＩ／Ｏ装置を有しているのではなく、各ゲストＯＳの入出力をドライバＯＳに依頼し、ドライバＯＳが代行することで各ゲストＯＳの入出力制御を仮想化している。
　具体的には、図１に示すように各ゲストＯＳが入力或は出力の制御（Ｉ／Ｏ制御）のため、Ｉ／Ｏ装置に対して情報を送信すると、ＦＥ（Front end）ドライバがハイパーバイザに伝達し、ドライバＯＳがバックエンドドライバを介して前記情報をハイパーバイザから受信する。ドライバＯＳは、この受信した情報を実ドライバによりＩ／Ｏ装置に送り、実際にＩ／Ｏ制御を行う。
　反対に、Ｉ／Ｏ装置から実ドライバを介して情報を受信した場合、ドライバＯＳは、バックエンドドライバを介して該情報をハイパーバイザに伝達し、ゲストＯＳがフロントエンドドライバを介して前記情報をハイパーバイザから受信する。
　ドライバＯＳは、ホストＯＳ上やゲストＯＳ上でも動作可能である。なお、ゲストＯＳ上でドライバＯＳを動作させた場合に、そのＯＳがドライバＯＳとなる。
　ゲストＯＳは、ハイパーバイザを介して割り当てられたハードウェア資源を用いて仮想的に情報処理装置の機能を実現する。即ち、各ゲストＯＳは、通常の情報処理装置にインストールされているＯＳと同じであり、複数のゲストＯＳがそれぞれ複数の情報処理装置の機能（ドメインＵ）を実現する。
　《物理メモリの割り当てに関して》
　物理メモリ１２は、図３に示すように、ホストＯＳや、ドライバＯＳ、ゲストＯＳに対して、それぞれ領域が割り当てられている。ハイパーバイザは、各ＯＳが夫々の領域にアクセスするように各ＯＳのメモリアクセスを制御する。例えば、ゲストＯＳが或るアドレスにアクセスする場合、ハイパーバイザが該ゲストＯＳ上のアドレスを当該ゲストＯＳに割り当てられたメモリ１２上のアドレスに変換することで、各ゲストＯＳのメモリアクセスを制御する。
　ハイパーバイザは、ハイパーバイザ用に割り当てられたメモリ領域を用いて動作するがその他のメモリ領域に関してもアクセスすることができる。ホストＯＳ、ドライバＯＳもハイパーバイザから許可を受けることにより他のＯＳに割り当てられたメモリ領域にアクセスすることが出来る。仮想計算機のメモリ割り当て方法は、幾つか在るが本例の情報処理装置はメモリの割り当て手法が限定されるものではなく、どのようなメモリの割り当て手法であっても利用可能である。
　《ゲストのディスパッチ》
　ハイパーバイザは、ＣＰＵ内部のタイマや外部の物理デバイスからの割込みを契機にディスパッチャを起動する。即ち、ＣＰＵ１１がディスパッチャ（切替部）として機能する。
　ディスパッチャは、所定のタイミングでドメインの切り替え、即ち、ＣＰＵに割り当てるゲストＯＳの変更を行う。
　なお、仮想計算機のディスパッチャの実装手法は、幾つか在るが、本例の情報処理装置はディスパッチャの実装手法が限定されるものでは無く、どのような実装手法であっても利用可能である。
　図４は、本実施例のディスパッチの説明図である。
　ディスパッチャは、ＯＳを動作させ(ステップ１、以下Ｓ１のようにも略記する）、割り込みがあがった場合（Ｓ２）、ハイパーバイザに制御を戻す（Ｓ３）。
　ディスパッチャは、ＯＳが動作していた際のＣＰＵ１１内のレジスタの情報をメモリ１２のハイパーバイザが管理する領域に保存する（Ｓ４）。即ち、ゲストＯＳがレジスタに保持させていた第１の情報、ホストＯＳがレジスタに保持させていた第３の情報、或はドライバＯＳがレジスタに保持させていた第４の情報をメモリに退避させる。また、ハイパーバイザが用いる第２の情報をメモリ１２から読み出してＣＰＵ１１の物理レジスタに保持させる。
　そして、ディスパッチャは、ゲストＯＳの割り当てを変更（ディスパッチ）すべきタイミングか否かを判定する（Ｓ５）。
　ここでディスパッチャは、ディスパッチすべきタイミングであれば該ディスパッチすべきＯＳを選択し（Ｓ６）、当該ＯＳのレジスタの情報をメモリ１２から読み出してＣＰＵ１１に反映させ（Ｓ７）、ステップ１に戻って当該ＯＳを動作させる。なお、ステップ５でディスパッチすべきタイミングでなければ、ディスパッチせずにステップ１に戻る。
　《スナップショットの採取》
　上述のように本例の情報処理装置１０は、ハイパーバイザ（仮想計算機モニタ）が物理ＣＰＵをゲストＯＳにある時間間隔で配分することで、ＣＰＵの仮想化を行っている。一定時間（例えば、１０ミリ秒）経過すると、必ずハイパーバイザに制御が戻り、その時点でハイパーバイザはゲストＯＳのレジスタやメモリの内容を参照することができる。
　そこで、ハイパーバイザは、デバッガを起動してＣＰＵ１１をスナップ取得部として機能させ、ゲストＯＳの状態（レジスタやメモリ内の情報）をスナップショットとして採取し、記録することでスローダウンの原因調査のための情報を取得する。
　スナップショットを採取する場合、図４に示したディスパッチの処理において、ゲストＯＳからハイパーバイザに制御が戻った時にスナップショット採取の処理（Ｓ２０）を追加して、図５のように変更する。
　図６は、図５のスナップショット採取の処理（Ｓ２０）の説明図である。
　ハイパーバイザは、制御が戻る直前に動作していたＯＳ、即ちステップＳ１で動作させたＯＳがスナップショット対象のゲストＯＳか否かを判定する（Ｓ２１）。
　対象のゲストＯＳであれば（Ｓ２１ Yes）、所定のスナップショット採取間隔に達したか否かを判定する（Ｓ２２）。例えば、１０ミリ秒毎のディスパッチの度にスナップショットを取得したのでは情報量が膨大となるため、適切な採取間隔を設定しておく。本例では５秒間隔で取得する。
　スナップショット採取間隔に達した場合（Ｓ２２ Yes）、ハイパーバイザは、ゲストＯＳのメモリを仮想アドレスで参照できるように、ハイパーバイザのレジスタを変更する（Ｓ２３）。
　また、ハイパーバイザは、デバッガを起動して（Ｓ２４）、ゲストＯＳの情報を採取できるように準備する。
　デバッガは、ゲストＯＳの状態（第１の情報）をスナップショットとして取得し（Ｓ２５）、メモリ１２に記憶させる（Ｓ２６）。
　そして、ハイパーバイザ或はホストＯＳは、前記スナップショットについてレポートする（Ｓ２７）。
　前記スナップショットは、例えば図７に示すように、ドメイン、レジスタ、バックトレース、ｐｓ、タスク、ｉｒｑ、ログ、仮想メモリといった項目の情報を採取する。
　スナップショットの各項目は、以下の情報を示す。
　ドメイン：スナップショットの対象ゲスト名、ｖｃｐｕ数、メモリ量
　レジスタ：対象のゲストＯＳが実行されているＣＰＵのレジスタ内に保持された情報
　バックトレース：レジスタの内容から関数の呼び出し関係（呼び出した処理の履歴）や、パラメタを遡って採取するデータ
　プロセス（ｐｓ）：プロセスの動作状況のデータ
　タスク：現在動作しているタスクのタスク管理用構造体
　割り込み（ｉｒｑ）：ハードウェアおよびソフトウェア割込み情報
　ログ：ＯＳから出力されたメッセージのログ
　仮想メモリ（ｖｍ）：レジスタから特定した現在動作中のプロセスが使用しているメモリ情報
　《スナップショットの参照先》
　スナップショットは、ＣＰＵ１１内の物理レジスタを参照して第１の情報を取得する。なお、ディスパッチ時にＣＰＵ１１内のレジスタからメモリ１２へ移された第１の情報をメモリ１２から読み出すことで、間接的にレジスタを参照しても良い。即ち、本例のデバッガは、ＣＰＵ１１内の物理レジスタや、図３に示すメモリ１２のうちゲストＯＳに割り当てられた領域及びハイパーバイザが管理するメモリ領域のうち当該ゲストＯＳの情報を格納した部分からスナップショットを取得する。
　図８は、スナップショットの取得元である物理レジスタの構成を示す図である。
　図８に示すように、ＣＰＵ１１の物理レジスタは、一般レジスタ、制御レジスタ、分岐レジスタ、アプリケーションレジスタを備えている。デバッガは、この物理レジスタからバックトレース情報の一部と、割り込み（ｉｒｑ）情報の一部を取得する。
　また、図９は、スナップショットの取得元である物理メモリの構成を示す図である。
　図９に示すように、メモリ１２は、ハイパーバイザやホストＯＳ、ゲストＯＳ用の領域を夫々有している。デバッガは、前記ハイパーバイザやホストＯＳの領域からドメイン情報や割り込み情報の一部を取得する。
　更に、デバッガは、メモリ１２上のゲストＯＳの領域から、ログ、タスク、プロセス、バックトレース情報の一部、割り込み情報の一部を取得する。
　《スナップショット取得後の処理》
　次にスナップショット取得後の処理（例えば格納及びレポート）について示す。該処理は、ホストＯＳ、ドライバＯＳ、ハイパーバイザが独立しているか兼用されているかといった構成によって異なる。
　図１０は、ホストＯＳ、ドライバＯＳ、ハイパーバイザが独立している場合の例を示す。
　ハイパーバイザは、デバッガを起動してスナップショットを取得すると（図６，Ｓ２５）、取得したスナップショットをホストＯＳとハイパーバイザの共有メモリまたはハイパーバイザ内のメモリに保存（格納）して、ホストＯＳに通知する。
　該通知を受けたホストＯＳはレポート用プログラムを起動してスナップショットを出力する処理を行う。即ち、ＣＰＵ１１はレポート用プログラムに従ってレポート部として機能する。
　レポート部は、前記メモリに蓄積されたスナップショットをレポートとして単に出力しても良いし、スナップショットを解析して解析結果をレポートとして出力しても良い。なお、出力に際してホストＯＳは、作成したレポートをドライバＯＳへ転送する。
　そしてドライバＯＳは、実Ｉ／Ｏドライバを使用して前記レポートをローカルディスクへ書き出す、表示部に表示する、ネットワークを経由して別のコンピュータへ転送するといった出力処理を行う。
　また、図１１は、ドライバＯＳとしても動作可能なホストＯＳを用いた例を示している。この場合、ホストＯＳのレポート部は、前記メモリに蓄積されたスナップショットに基づいてレポートを作成し、実Ｉ／Ｏドライバを使用してレポートを出力するまでの処理を行う。
　更に、図１２は、ホストＯＳ内蔵型のハイパーバイザを用いた例を示している。この場合、スナップショットを取得し、レポートプログラムを起動して分析及び出力までのすべての操作をハイパーバイザ内で行う。
　《スナップショットを複数回取る方法の例》
　図６に示すように、ゲストＯＳからハイパーバイザに制御が戻った際、デバッガが起動され、スナップショットを取得する。このときデバッガは、あらかじめＮ回分のデータが保存できるように用意された物理メモリにスナップショットを保存する。
　この複数蓄積したスナップショットからレポートを作成する契機となるようにホストＯＳまたはハイパーバイザに通知する手法は幾つか考えられる。例えば、図１３は、保存用物理メモリを使い切った場合に通知する例を示す。
　図１３の物理メモリ１２は、Ｎ回分のスナップショットが保存可能な保存用領域が設定されている。デバッガは、スナップショットを取得する度に、１回目、２回目、３回目・・・のように保存用領域に順次保存してゆき、Ｎ回目の保存を行ったときにホストＯＳ或はハイパーバイザに通知する。
　この通知を受けたホストＯＳ或はハイパーバイザは、レポートプログラムを起動して、スナップショットの解析及びレポートの作成を行う。
　《スローダウンが発生した場合の具体例》
　図１４は、スローダウンが発生した場合の具体例を示す図である。
　図１４では、プロセスＡ，Ｂの下記の動作を時間軸上に示している。
（１）プロセスＡがメモリの大量獲得と解放を繰り返している。図１４においてＡ１，Ａ３がメモリの大量獲得、Ａ２がメモリの大量解放を示す。
（２）プロセスＢは、あるタイミングでメモリを獲得する動作を行う。図１４ではＢ１とＢ３でメモリを獲得しようとしている。
（３）プロセスＢは、メモリが獲得できない場合、メモリが獲得できるまでＣＰＵを使うビジーウェイトをする。図１４では、Ｂ１でメモリの獲得に失敗し、Ｂ２でメモリが獲得できるまでビジーウェイトとしている。
（４）プロセスＢがビジーウェイトしていると、プロセスＡによるメモリの解放動作が遅れるためプロセスＡ，Ｂともに遅滞し、スローダウンが生じる。
　図１４において、プロセスＢの動作Ｂ１からＢ２までの期間Ｒ１と、動作Ｂ３以降の期間Ｒ３でスローダウンが生じている。即ち、プロセスＡがメモリを大量に解放して（Ａ２）、プロセスＢがメモリを獲得（Ｂ２）してから、プロセスＡが再びメモリを大量に獲得（Ａ３）してプロセスＢがメモリ獲得に失敗するＢ３までの期間Ｒ２はビジーウェイトが解消する。
　図１４の状況で、従来のようにシステムを停止してダンプ採取を行う場合、期間Ｒ１でダンプを採取できればスローダウン中であるが、期間Ｒ２でダンプを採取した場合、ビジーウェイトは解消されているためダンプから問題を解析することが困難である。
　これに対し本例では、設定されたタイミングで複数回にわたりスナップショットを取得するため、不具合（性能劣化）が発生しているタイミングでスナップショットを取得できる可能性が高くなる。
　図１５，１６は、上図１４で２回目に取得したスナップショットの例を示す。
　図１５，１６のスナップショットより以下のことが容易にわかる。
－　システム全体でメモリの使用量が大きい（vm情報）
－　ＣＰＵを占有しているプロセスがある。（ps情報）
　従って、メモリの獲得待ちのためにスローダウンが発生していることが推定できる。また、ＣＰＵを占有しているプロセスを停止させるといった対応を行うことができる。
　また、不具合が長いループ処理の中で生じていた場合、例えば図１４の動作Ａ１～Ａ３の間隔が長い場合、不具合の原因となる他のプロセスの動作Ｂ１～Ｂ３との時間的隔たりが大きくなる。このため、従来技術のメモリダンプのように1回だけのメモリ情報では、各プロセスの動作Ａ１～Ａ３，Ｂ１～Ｂ３の因果関係が把握できず、システムが正常に動作しているように見えるため障害箇所の特定が非常に困難である。
　しかし、本実施例では所定の時間間隔で複数回のスナップショットを採取するため、時間的に隔たった動作であっても把握でき、長いループ処理を行っていることを容易に判断できる。
　各タイミングで採取したスナップショットデータを解析しレポートを送るかどうかを判断するレポート条件の例を以下に示す。
－　メッセージログの中に”warning”、”error”などの文字列がある。
－　Ｎ回のps情報の中でＭ回以上CPU使用率の高いプロセスがある。
－　Ｎ回のtask情報の中でＭ回以上メモリ使用率の高いプロセスがある。
－　Ｎ回のバックトレース情報の中でＭ回以上同じバックトレースである。
－　Ｎ回のvm情報の中でＭ回以上システム全体のメモリ使用量が高い。
－　Ｎ回のレジスタ情報の中でＭ回以上同じ内容がある。
　図１７は、図６のレポートの処理の説明を示す。
　デバッガは、所定回数のスナップショットが取得されたか否かを判定し（Ｓ３１）、所定回数(Ｎ回）のスナップショットが取得済みであれば（Ｓ３１ Ｙｅｓ）、レポート部に通知する（Ｓ３２）。
　レポート部は、Ｎ回分のスナップショットを統計処理し（Ｓ３３）、該スナップショットが所定の前記レポート条件に適合しているか否かを判定する（Ｓ３４）。
　前記スナップショットがレポート条件に適合している場合（Ｓ３４ Ｙｅｓ）、レポート部は、適合している部分の情報を抽出し、前記Ｎ回分のスナップショットに付加してレポートを作成する（Ｓ３５）。
　そしてレポート部は、作成したレポートを出力する（Ｓ３６）。例えばドライバＯＳとホストＯＳが分かれている構成であれば、レポート部はレポートをドライバＯＳに渡し、ドライバＯＳが実ドライバを用いてストレージやディスプレイ、他のコンピュータ等に出力する。
　図１８，１９は、レポート条件に該当した箇所をまとめた情報の例を示す。
　図１８，１９に示すように、レジスタの項目では、Ｎ回のスナップショットでＭ回同じレジスタ情報であった場合にレジスタの内容をr1=0x00ab0010 r2=0x00cd0123・・・のように抽出する。・・
　バックとレースの項目では、Ｎ回のスナップショットでＭ回同じレジスタ情報であったときのバックトレース情報をrequest_memory()->alloc_memory()->wait_loop ()のように抽出する。
　プロセス（ps）の項目では、Ｎ回のスナップショットでＭ回ＣＰＵ、メモリ使用率が高かったプロセスのプロセス名と、メモリ使用率とＣＰＵ使用率のリストをプロセスＡ：30%：5%、プロセスＢ：7%：90%…のように抽出する。
　タスクの項目では、Ｎ回のスナップショットでＭ回ＣＰＵ、メモリ使用率が高かったプロセスのタスク構造体をstructure task {  task_name = “プロセスＡ”  uptime = 12345 (プロセスの動作時間)  memory = 268435456(使用メモリ)  task_list = next_task (プロセスB)}structure task {  task_name = “プロセスＢ”  uptime = 67891234(プロセスの動作時間)  memory = 3145728(使用メモリ)  task_list = next_task (プロセスC)}…のように抽出する。
　割り込み（irq）の項目では、Ｎ回採取した中での割込み情報と割込み回数をexternal(timer) :2software(signal):4・・・・のように抽出する。
　ログ（log）の項目では、レポート採取条件に該当したメッセージをapplication job1 errorapplication job7 warning・・・・のように抽出する。
　仮想メモリ（vm）の項目では、Ｎ回のスナップショットでの時系列の仮想メモリ情報をstructure memory[1回目] {total_memory = 1073741824（システム全体のメモリ量）free_memory = 16384(空メモリ量)}structure memory[2回目] {total_memory = 108681824（システム全体のメモリ量）free_memory = 965076384 (空メモリ量)}のように抽出する。
　本実施例のレポートの例ではプロセスＡ，Ｂに問題があることがps情報、task情報から明らかであり、バックトレース情報およびレジスタ情報からメモリ獲得待ちの関数が何度も呼ばれていることがわかる。
　また、vm情報からメモリリソースの獲得待ちであることを確定することが容易である。
　このように本実施例では、スナップショットに基づいて、不具合の要因を容易に解決することができる。
　特に、本実施例によれば、スナップショットを複数回採取するため、スローダウンに陥っているタイミングでスナップショットを採取できる確率が非常に高い。
　ゲストＯＳを動作させたままスナップショットを採取しているので、業務を停止する必要がない。また、採取したスナップショットから原因が特定できた後は、原因となっているアプリケーションを停止するなどの対処が可能であり、スローダウン自体を運用したまま解決できるメリットがある。
　更に、ゲストＯＳがスナップショットを採取するのではなく、ゲストＯＳのディスパッチ時にハイパーバイザがスナップショットを採取するため、ゲストＯＳのオーバヘッドとならない。即ち、スナップショットを採取しながらゲストＯＳは通常どおり動作できるので、遂行すべき業務への影響が無い。
　デバッガによるスナップショットの採取が、ゲストＯＳとは別に動作するため、ゲストＯＳの動作タイミングには変化がなく、スローダウンの再現性に影響を与えない。
　また、ゲストＯＳ内のプログラムを変更しないため、トレース機能のソフトウェア障害（バグ）が発生することがなく、信頼性が高い。

Claims (12)

  1. 　物理レジスタを有する処理装置を備えた情報処理装置において、
    　第１の情報を有し、前記第１の情報を前記物理レジスタに保持するとともに、アプリケーションプログラムを動作させる第１のオペレーティングシステムと、
    　第２の情報を有し、前記第２の情報を前記物理レジスタに保持するとともに、前記第１のオペレーティングシステムが前記処理装置に対して発行する命令の制御を行い、前記物理レジスタが有する情報を参照するモニタプログラムと、
    　を前記処理装置が、それぞれ切り替えながら実行するとともに、
    　前記処理装置が、前記モニタプログラムを実行している場合に、前記物理レジスタに保持する情報を前記第２の情報から前記第１の情報に変更するとともに、前記処理装置が、前記物理レジスタに保持された前記第１の情報を参照することを特徴とする情報処理装置。
  2. 　前記処理装置はさらに、
    　第３の情報を有し、前記第３の情報を前記物理レジスタに保持するとともに、前記第１のオペレーティングシステムの制御を行う第２のオペレーティングシステムに切り替えて実行することを特徴とする請求項１記載の情報処理装置。
  3. 　前記情報処理装置はさらに、
    　入出力装置を有するとともに、
    　前記処理装置はさらに、
    　第４の情報を有し、前記第４の情報を前記物理レジスタに保持するとともに、前記第１のオペレーティングシステムからの入出力要求を、前記入出力装置に対して発行する第３のオペレーティングシステムに切り替えて実行させることを特徴とする請求項１記載の情報処置装置。
  4. 　前記処理装置が参照する前記第１の情報は、
    　前記第１のオペレーティングシステム又は前記アプリケーションプログラムに含まれる関数に関する情報、
    　前記第１のオペレーティングシステム又は前記アプリケーションプログラムのプログラムの動作状況に関する情報、
    　前記第１のオペレーティングシステム又は前記アプリケーションプログラムにおいて、動作中のプログラムが有する構造体に関する情報、
    　前記第１のオペレーティングシステム又は前記アプリケーションプログラムが出力するメッセージに関する情報、
    　前記第１のオペレーティングシステム又は前記アプリケーションプログラムが使用している前記記憶装置に関する情報、
    　のいずれかであることを特徴とする請求項１記載の情報処理装置。
  5. 　物理レジスタを有する処理装置を備えた情報処理装置の制御方法において、
    　第１のオペレーティングシステムが用いる第１の情報を前記物理レジスタに保持するとともに、前記処理装置が、アプリケーションプログラムを動作させる前記第１のオペレーティングシステムを実行するステップと、
    　モニタプログラムが用いる第２の情報を前記物理レジスタに保持するとともに、前記処理装置が、前記第１及び第２のオペレーティングシステムが前記処理装置に対して発行する命令の制御を行い、前記物理レジスタが有する情報を参照するモニタプログラムを実行するステップと、
    　前記処理装置が、前記モニタプログラムを実行する場合に、前記物理レジスタに保持する情報を前記第２の情報から前記第１の情報に変更するとともに、前記処理装置が、前記物理レジスタに保持された前記第１の情報を参照するステップを有することを特徴とする制御方法。
  6. 　前記制御方法はさらに、
    　第２のオペレーティングシステムが用いる第３の情報を前記物理レジスタに保持するとともに、前記処理装置が、前記第１のオペレーティングシステムの制御を行う前記第２のオペレーティングシステムを実行するステップを有することを特徴とする請求項５記載の制御方法。
  7. 　前記情報処理装置はさらに、
    　入出力装置を有するとともに、
    　前記制御方法はさらに、
    　前記処理装置が、第３のオペレーティングシステムが用いる第４の情報を前記物理レジスタに保持するとともに、前記第１のオペレーティングシステムからの入出力要求を、前記入出力装置に対して発行する第３のオペレーティングシステムに切り替えて実行するステップを有することを特徴とする請求項５記載の制御方法。
  8. 　前記処理装置が参照する前記第１の情報は、
    　前記第１のオペレーティングシステム又は前記アプリケーションプログラムに含まれる関数に関する情報、
    　前記第１のオペレーティングシステム又は前記アプリケーションプログラムのプログラムの動作状況に関する情報、
    　前記第１のオペレーティングシステム又は前記アプリケーションプログラムにおいて、動作中のプログラムが有する構造体に関する情報、
    　前記第１のオペレーティングシステム又は前記アプリケーションプログラムが出力するメッセージに関する情報、
    　前記第１のオペレーティングシステム又は前記アプリケーションプログラムが使用している前記記憶装置に関する情報、
    　のいずれかであることを特徴とする請求項５記載の制御方法。
  9. 　物理レジスタを有する処理装置を備えた情報処理装置のモニタプログラムにおいて、
    　前記処理装置に、第１のオペレーティングシステムが用いる第１の情報を前記物理レジスタに保持するとともに、前記処理装置が、アプリケーションプログラムを動作させる前記第１のオペレーティングシステムを実行させるステップと、
    　前記処理装置に、前記物理レジスタに保持する情報を前記第２の情報から前記第１の情報に変更するとともに、前記処理装置が、前記物理レジスタに保持された前記第１の情報を参照させるステップを有することを特徴とするモニタプログラム。
  10. 　前記モニタプログラムはさらに、
    　前記処理装置に、第２のオペレーティングシステムが用いる第３の情報を前記物理レジスタに保持させるとともに、前記第１のオペレーティングシステムの制御を行う前記第２のオペレーティングシステムを実行させるステップを有することを特徴とする請求項９記載のモニタプログラム。
  11. 　前記情報処理装置はさらに、
    　入出力装置を有するとともに、
    　前記モニタプログラムはさらに、
    　前記処理装置に、第３のオペレーティングシステムが用いる第４の情報を前記物理レジスタに保持させるとともに、前記第１のオペレーティングシステムからの入出力要求を、前記入出力装置に対して発行する第３のオペレーティングシステムに切り替えて実行させるステップを有することを特徴とする請求項９記載のモニタプログラム。
  12. 　前記処理装置が参照する前記第１の情報は、
    　前記第１のオペレーティングシステム又は前記アプリケーションプログラムに含まれる関数に関する情報、
    　前記第１のオペレーティングシステム又は前記アプリケーションプログラムのプログラムの動作状況に関する情報、
    　前記第１のオペレーティングシステム又は前記アプリケーションプログラムにおいて、動作中のプログラムが有する構造体に関する情報、
    　前記第１のオペレーティングシステム又は前記アプリケーションプログラムが出力するメッセージに関する情報、
    　前記第１のオペレーティングシステム又は前記アプリケーションプログラムが使用している前記記憶装置に関する情報、
    　のいずれかであることを特徴とする請求項９記載のモニタプログラム。
PCT/JP2008/060336 2008-06-05 2008-06-05 情報処理装置及びその制御方法並びにモニタプログラム WO2009147738A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2010515714A JPWO2009147738A1 (ja) 2008-06-05 2008-06-05 情報処理装置及びその制御方法並びにモニタプログラム
PCT/JP2008/060336 WO2009147738A1 (ja) 2008-06-05 2008-06-05 情報処理装置及びその制御方法並びにモニタプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2008/060336 WO2009147738A1 (ja) 2008-06-05 2008-06-05 情報処理装置及びその制御方法並びにモニタプログラム

Publications (1)

Publication Number Publication Date
WO2009147738A1 true WO2009147738A1 (ja) 2009-12-10

Family

ID=41397830

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2008/060336 WO2009147738A1 (ja) 2008-06-05 2008-06-05 情報処理装置及びその制御方法並びにモニタプログラム

Country Status (2)

Country Link
JP (1) JPWO2009147738A1 (ja)
WO (1) WO2009147738A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013008326A1 (ja) * 2011-07-13 2013-01-17 富士通株式会社 ソフトウェア検証方法、およびソフトウェア検証システム
JP2014170482A (ja) * 2013-03-05 2014-09-18 Fujitsu Ltd 仮想計算機システム及びその管理方法並びに仮想計算機システムの管理プログラム
JPWO2013008326A1 (ja) * 2011-07-13 2015-02-23 富士通株式会社 ソフトウェア検証方法、およびソフトウェア検証システム

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS593651A (ja) * 1982-06-30 1984-01-10 Fujitsu Ltd フア−ムウエアによる性能測定システム
JPH02307145A (ja) * 1989-05-22 1990-12-20 Nippon Telegr & Teleph Corp <Ntt> 仮想計算機システム
JPH0373031A (ja) * 1989-08-14 1991-03-28 Fujitsu Ltd メモリアクセス制御方式
JPH0850556A (ja) * 1994-08-04 1996-02-20 Fujitsu Ltd 仮想計算機システム
JP2007219757A (ja) * 2006-02-15 2007-08-30 Fujitsu Ltd 仮想計算機システムを機能させるためのプログラム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6285350A (ja) * 1985-10-11 1987-04-18 Hitachi Ltd モニタリング方式

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS593651A (ja) * 1982-06-30 1984-01-10 Fujitsu Ltd フア−ムウエアによる性能測定システム
JPH02307145A (ja) * 1989-05-22 1990-12-20 Nippon Telegr & Teleph Corp <Ntt> 仮想計算機システム
JPH0373031A (ja) * 1989-08-14 1991-03-28 Fujitsu Ltd メモリアクセス制御方式
JPH0850556A (ja) * 1994-08-04 1996-02-20 Fujitsu Ltd 仮想計算機システム
JP2007219757A (ja) * 2006-02-15 2007-08-30 Fujitsu Ltd 仮想計算機システムを機能させるためのプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SHIMOKAWA H.: "Tokushu 3: Kasoka Gijutsu Dai 3 Sho: FreeBSD/Xen o Tsukao", FREEBSD EXPERT 2006, 25 May 2006 (2006-05-25), pages 186 - 188 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013008326A1 (ja) * 2011-07-13 2013-01-17 富士通株式会社 ソフトウェア検証方法、およびソフトウェア検証システム
JPWO2013008326A1 (ja) * 2011-07-13 2015-02-23 富士通株式会社 ソフトウェア検証方法、およびソフトウェア検証システム
JP2014170482A (ja) * 2013-03-05 2014-09-18 Fujitsu Ltd 仮想計算機システム及びその管理方法並びに仮想計算機システムの管理プログラム
US9524180B2 (en) 2013-03-05 2016-12-20 Fujitsu Limited Managing virtual machines using tracing information

Also Published As

Publication number Publication date
JPWO2009147738A1 (ja) 2011-10-20

Similar Documents

Publication Publication Date Title
US8949671B2 (en) Fault detection, diagnosis, and prevention for complex computing systems
US8370841B2 (en) Optimizing deterministic event record and replay operations
EP2787444B1 (en) Central processing unit, information processing apparatus, and intra-virtual-core register value acquisition method
US8839271B2 (en) Call stack sampling to obtain information for analyzing idle states in a data processing system
US9081629B2 (en) Excluding counts on software threads in a state
US9449314B2 (en) Virtualization of a central processing unit measurement facility
US8448013B2 (en) Failure-specific data collection and recovery for enterprise storage controllers
US7774647B2 (en) Method for counting instructions for logging and replay of a deterministic sequence of events
US8132170B2 (en) Call stack sampling in a data processing system
US8612937B2 (en) Synchronously debugging a software program using a plurality of virtual machines
EP1870810A2 (en) Kernel-aware debugging system, medium, and method
US20090178036A1 (en) Method and Apparatus for Call Stack Sampling Using a Virtual Machine
JP4562568B2 (ja) 異常検出プログラムおよび異常検出方法
US20100017583A1 (en) Call Stack Sampling for a Multi-Processor System
US20120304184A1 (en) Multi-core processor system, computer product, and control method
US20130096880A1 (en) System test method
US20140259011A1 (en) Virtual computer system and management method thereof
WO2012095762A1 (en) Activity recording system for a concurrent software environment
JP5623557B2 (ja) 診断データを収集するためのマルチスレッド化コンピューティング環境における方法、装置、およびコンピュータ・プログラム
JP4992740B2 (ja) マルチプロセッサシステム、障害検出方法および障害検出プログラム
WO2009147738A1 (ja) 情報処理装置及びその制御方法並びにモニタプログラム
US8312433B2 (en) Operating system aided code coverage
Chen et al. Asymmetric virtual machine replication for low latency and high available service
JP7564447B2 (ja) 異常要因判定方法および異常要因判定プログラム
JPH05181631A (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: 08765149

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010515714

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08765149

Country of ref document: EP

Kind code of ref document: A1