WO2010113212A1 - メモリリーク監視装置、及び方法 - Google Patents

メモリリーク監視装置、及び方法 Download PDF

Info

Publication number
WO2010113212A1
WO2010113212A1 PCT/JP2009/001503 JP2009001503W WO2010113212A1 WO 2010113212 A1 WO2010113212 A1 WO 2010113212A1 JP 2009001503 W JP2009001503 W JP 2009001503W WO 2010113212 A1 WO2010113212 A1 WO 2010113212A1
Authority
WO
WIPO (PCT)
Prior art keywords
memory
program
memory leak
leak monitoring
memory area
Prior art date
Application number
PCT/JP2009/001503
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 PCT/JP2009/001503 priority Critical patent/WO2010113212A1/ja
Priority to JP2011506844A priority patent/JPWO2010113212A1/ja
Publication of WO2010113212A1 publication Critical patent/WO2010113212A1/ja
Priority to US13/240,395 priority patent/US20120072779A1/en

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/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/073—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 memory management context, e.g. virtual memory or cache management
    • 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/0715—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 system implementing multitasking
    • 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/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
    • 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/0793—Remedial or corrective actions

Definitions

  • the present invention relates to a technique for monitoring a memory leak caused by not releasing a memory area to be released by a program.
  • a program that is executed on a computer as an information processing apparatus is normally assigned a resource as a usable hardware resource.
  • a memory area that can be used by the program is secured as a part of the resource.
  • a running program is also called a “process”.
  • the process includes a system process (hereinafter referred to as “kernel process”) that realizes a part of an OS (Operating System) function, and a user process (for example, an application program to be executed) executed by a user instruction. It is divided roughly into.
  • This management function dynamically determines the memory area according to the parameters specified in the program. The determined memory area is notified to the program by, for example, the start address and size of the memory area.
  • the secured memory area is released by the memory release instruction from the program. However, if a memory release instruction is not issued from the program due to a defect (bug) or the like, the reserved memory area is not required but is not released by the management function. A so-called “memory leak” occurs in the memory area that is not released.
  • Virtual OS OS separates virtual memory into kernel space and user space.
  • the kernel space is the entire memory area that can be used by the kernel process and is strictly reserved for the kernel process such as the kernel and the device driver.
  • the user space is a memory area individually reserved for user processes.
  • the application running on the OS is usually a user process.
  • the memory area (user space) allocated to the user process is automatically released upon termination of the program (for example, application). Therefore, the memory area where the memory leak has occurred can be released by terminating the program.
  • a memory area where a memory leak has occurred in a kernel process such as a system call, a kernel daemon, or an interrupt process does not have an opportunity to be released unlike a user process.
  • the memory area corresponding to the memory leak cannot be released unless the OS is terminated. For this reason, the memory area where the memory leaks is accumulated while the OS is operating.
  • a memory leak that occurs in the kernel space reduces the usable memory area and hinders the operation of the OS.
  • the memory area corresponding to the memory leak becomes large, the execution of the application is stopped because the memory area for continuing the operation cannot be secured. There is a case where the entire apparatus executing the OS is brought down.
  • the OS may be installed in the embedded system as an embedded OS (real-time OS).
  • the embedded system is a computer system developed for a specific application, and is often mounted on a device that is continuously operated for a long time, such as a vending machine or a ticket vending machine. In such a device, even if a small amount of memory leaks are accumulated over a long period of time, it is easy to press memory resources and there is a high risk of hindering the operation of the embedded OS.
  • a mechanism (interface for notifying the management function of the maximum survivable time and warning time of the memory area secured by the process so that the management function determines whether or not the secured memory area should be released) ) Is known to prepare.
  • the management function issues a warning when the warning time has elapsed since the memory area was secured, and forcibly releases the memory area when the maximum survivable time has elapsed since the memory area was secured.
  • the present invention provides a technique that appropriately copes with a memory leak that occurs in an address space in which a memory area that can be used by each process is secured without changing each program to be monitored for memory leak. Objective.
  • a survival time that is the time that has elapsed since the memory area used by the program is secured is acquired, and the acquired survival time is set as a threshold in advance. Compare with time to detect programs that may have a memory leak.
  • the present invention when the present invention is applied, it is suitable for a memory leak occurring in an address space where a memory area that can be used by each process is secured without changing each program to be monitored for memory leak. It can correspond to.
  • FIG. 6 is a diagram for explaining a data configuration of a memory area list 212. It is a figure explaining the data structure of the exclusion list
  • FIG. (A) And (b) is a figure explaining the kernel process registered into the exclusion list 212.
  • FIG. It is a histogram explaining the memory area number by survival time. It is a flowchart of a memory securing process. It is a flowchart of a memory release process. It is a flowchart of a memory leak monitoring process.
  • FIG. 1 is a diagram for explaining a computer system as an information processing apparatus constructed using a system control apparatus and a server apparatus equipped with a memory leak monitoring apparatus according to the present embodiment.
  • a management board (MMB: ManagementMent Board) 20 which is a system control device (SVP) for managing the server device 10 is connected to the server device 10 and its management is performed.
  • the display device 30 is connected to the board 20.
  • the memory leak monitoring apparatus according to the present embodiment is mounted on the management board 20.
  • the server device 10 has a configuration in which processing units 11 which are a plurality of system boards (SB: System Board) are mutually connected by a crossbar as a data transfer device (not shown).
  • processing unit 11 for example, as shown in FIG. 1, a CPU 12, a memory 13, an external storage device 14, and an IO device 15 are mounted.
  • Communication with the management board 20 is performed via an IO (Input Output) device (input / output device) 15.
  • the management board 20 includes a CPU 21, a memory 22, an IO device 23, and an external storage device 24. Communication with the server device 10 is performed via the IO device 23.
  • the external storage device 24 stores a program group 25 such as a device management application that is a program for managing the embedded OS and the server device 10.
  • FIG. 2 is a diagram for explaining the software configuration of the management board 20.
  • the program group 25 the embedded OS 200 of this embodiment and a device management application 250 that operates on the embedded OS 200 are mounted on the management board 20.
  • the embedded OS 200 and the device management application 250 constitute an embedded system for the management board 20 that performs system control of the server device 20.
  • the embedded OS 200 adds an additional function 202 for enabling monitoring of a memory leak according to the present embodiment to the function 201 of the embedded OS in which the memory area management processing unit 210, which is a program for managing the memory area, is installed. It is constituted by doing.
  • FIG. 2 shows a system call 231, a kernel daemon 232, and an interrupt process 233 as processes for realizing the function 201 of the embedded OS.
  • the system call 231 is executed for an application to call the function 201 of the embedded OS.
  • the kernel daemon 232 is a subprogram that is resident for process control and the like.
  • the interrupt process is an execution process that processes a hardware interrupt.
  • These kernel processes are assigned memory areas from within the kernel space, which is a fixed memory resource secured by the memory area management processing unit 211. Processes to be monitored for memory leak are all kernel processes operating on such an embedded OS 200.
  • the additional function 202 includes a memory area monitoring daemon 220 that is a program for monitoring a memory leak.
  • the memory area monitoring daemon 220 operates as one of kernel processes.
  • the memory area management processing unit 210 is provided with an additional processing unit 211 as a subprogram thereof.
  • the additional processing unit 211 manages a memory area list 212 indicating memory areas allocated to each kernel process.
  • the memory area list 212 is an array variable whose value is stored in the memory 22, for example.
  • FIG. 3 is a diagram for explaining the data structure of the memory area list 212.
  • the memory area list 212 includes a record in which data related to the memory area is stored for each memory area secured from the kernel space. Each record stores an address, a secured size, a secured time, a process name, and a leak flag as data.
  • the address is the start address of the reserved memory area.
  • the secured size is the number of addresses in the memory area.
  • the reserved time is the time when the corresponding memory area is allocated to the kernel process. This time is, for example, the current time measured by a hard timer mounted on the CPU 21.
  • the process name is identification data of a process to which a memory area is allocated.
  • the leak flag indicates the possibility that a memory leak has occurred. “0” indicates that there is no possibility that a memory leak has occurred, and “1” indicates that this possibility exists.
  • Securing and releasing the memory area by the kernel process is performed by a request to the memory area management processing unit 210.
  • the management processing unit 210 executes the memory securing process shown in FIG. 7 when a memory area allocation is requested from the kernel process.
  • step S1 a memory area securing process is performed in step S1, and the address (start address) and size of the memory area secured by the securing process are passed to the kernel process.
  • step S 2 in addition to the address and size, a leak flag whose reserved time, process name, and value are 0 is registered in the memory area list 212. After the registration, the memory securing process is terminated.
  • the memory area management processing unit 210 executes the memory releasing process shown in FIG. In the memory release process, the following process is executed.
  • step S11 processing for releasing the memory area requested by the kernel process is executed.
  • step S12 a memory release process is performed by extracting and deleting a record corresponding to the memory area to be released. Thereafter, the memory release process is terminated.
  • the additional processing unit 212 is realized by executing the above steps S2 and S12.
  • the memory area monitoring daemon 220 manages the exclusion list 221, the threshold 222, and the operation start time variable 223.
  • the exclusion list 221 is used for managing processes to be excluded from memory leak monitoring targets in the kernel process. As shown in FIG. 4, the identification data (process name here) of the process to be excluded from the monitoring target is registered. In this embodiment, as will be described later, the possibility that a memory leak has occurred is determined by paying attention to the time (survival time) that has elapsed since the memory area was secured.
  • the threshold 222 is a reference time that is compared to the survival time to determine its likelihood.
  • the operation start time variable 223 is a variable to which the operation start time when the embedded OS 200 is activated is substituted. What is actually substituted into the operation start time variable 223 is the time when the memory area monitoring daemon 220 is activated.
  • the exclusion list 221 and the threshold value 222 are data given in advance by an administrator or the like.
  • FIGS. 5A and 5B are diagrams for explaining kernel processes registered in the exclusion list 212.
  • FIG. FIG. 5A shows an example of securing a memory area in a kernel process that should not be registered in the exclusion list 212
  • FIG. 5B shows an example of securing a memory area in a kernel process that is excluded from the monitoring target.
  • black circles indicate the time when the memory area is secured
  • black squares indicate the time when the memory area is released.
  • the line connecting the black circle and the black square indicates the survival time in which the memory area is secured.
  • a kernel process in which such a memory leak may occur may set the value of the leak flag to 1 when the survival time exceeds the threshold value 222.
  • the condition for releasing the memory area is that the survival time exceeds the threshold 222. Not desirable. This is because it is considered that a relatively long time is required to execute the processing. For this reason, such a kernel process is registered in the exclusion list 221 to avoid releasing a memory area that should not be released.
  • FIG. 6 is a histogram explaining the number of memory areas depending on the survival time.
  • the vertical axis represents the number of memory areas, and the horizontal axis represents the survival time (the lifetime based on the operation start time or the secured time).
  • Some kernel processes such as the interrupt processing 233 and the system call 231, release a memory area secured in a relatively short time, and do not release the secured memory area for a long time.
  • the former is within range A
  • the latter is within range B and range C.
  • An area in the range C is a memory area secured by a process executed when the embedded OS 200 is started or immediately after the embedded OS 200 is started. For this reason, a bug that a memory leak has occurred in the memory area is easily found during debugging.
  • the memory area in the range C is excluded from the monitoring target as a highly reliable memory area, and only the memory area having the lifetime in the range B between the range A and the range C is monitored. set to target.
  • the threshold value 222 can be set, for example, by executing a threshold value setting process as shown in FIG. This setting process is to extract a time as an option to be set as the threshold value 222 by securing the memory area.
  • This setting process is to extract a time as an option to be set as the threshold value 222 by securing the memory area.
  • the processes of steps S51 to S53 are executed between steps S11 and S12.
  • the added processing will be described in detail.
  • step S51 the opening time is recorded.
  • step S52 it is determined whether or not the result (survival time) obtained by subtracting the secured time from the release time is greater than the previous threshold. If the calculated survival time is greater than the threshold, the determination is yes, and after the survival time is newly set as the threshold in step S53, the process proceeds to step S12. If the survival time is less than or equal to the threshold, the determination is no and the process moves to step S12.
  • the memory area monitoring daemon 220 acquires the current time from, for example, a hard timer and substitutes it into the operation start time variable 223. Thereafter, for example, the memory leak monitoring process shown in FIG. 9 is executed at a predetermined time interval or at a preset timing.
  • the memory leak monitoring process will be described in detail.
  • step S21 for each record (memory area) constituting the memory area list 212, a process for each record for determining the possibility of a memory leak is executed.
  • step S22 it is determined whether or not a memory area having a possibility of memory leak is found by executing the process for each record. If a memory area having such a possibility is found, the determination is yes and the process proceeds to step S23. If a memory area having such a possibility cannot be found, the determination is no, and the memory leak monitoring process ends here.
  • step S23 the device management application 250 is notified of the record whose leak flag is 1 in the memory area list 212.
  • the memory usage for each process that is, the size of the memory area is calculated, and the average value of the memory usage per process is obtained.
  • the predetermined number of processes that can be started is multiplied by the obtained average value. The result of the multiplication is hereinafter referred to as “limit size”.
  • step S26 it is determined whether or not the limit size is larger than the free area size of the memory 22 that can be allocated to the kernel space. If the limit size is larger than the free area size, the determination is yes, and after the memory area managed by the record having the leak flag of 1 is forcibly released in step S27, the memory leak monitoring process is terminated. If the limit size is equal to or less than the free area size, the determination is no, and the memory area monitoring process ends here.
  • step S26 is a process for determining whether or not the memory resources of the memory 22 have a relatively large margin.
  • margin is not limited to the above.
  • the margin may be determined based on whether or not a memory area having a preset ratio is secured from the kernel space. Even in that case, an average value may be considered.
  • the device management application 250 includes a status display processing unit 251 as a subprogram.
  • the status display processing unit 251 is for causing the display device 30 to display information about a memory leak that may have occurred to the user, using the record notified from the memory area monitoring daemon 220.
  • the state display processing unit 251 is realized by the apparatus management application 250 executing the state display process shown in FIG. In this status display process, as shown in FIG. 10, the process name, address, and size are displayed for each memory area in step S31.
  • FIG. 11 is a flowchart of processing for each record executed as step S21. Next, this process will be described in detail with reference to FIG. For convenience, FIG. 11 shows only a portion corresponding to one record.
  • step S41 it is determined whether or not the process name of the target record is registered in the exclusion list 221. If the process name is registered in the exclusion list 221, the determination is yes, and the processing for one record ends here. If the process name is not registered, the determination is no and the process proceeds to step S42.
  • step S42 it is determined whether the secured time is before the operation start time. If the target memory area has been secured before the memory area monitoring daemon 220 is activated, the determination is yes, and the processing for the record ends here. If the secured time is after the operation start time, the determination is no and the process proceeds to step S43.
  • step S43 the time elapsed from the secured time is calculated as the survival time.
  • step S44 it is determined whether or not the survival time is shorter than the threshold value 222. If the survival time is shorter than the threshold 222, the determination is yes, and the processing for one record is terminated here. If the survival time is greater than or equal to the threshold value 222, the determination is no, the leak flag of the target record is set to 1 in step S45, and the processing for one record is terminated.
  • the process name is registered in the exclusion list 221, but other information may be registered together.
  • the number of memory areas may be registered together. This is because the same process may secure a plurality of memory areas as shown in FIG. Therefore, when the number of memory areas (the maximum number of memory areas that can be secured by a process) is also registered, it is possible to more reliably avoid an abnormal increase in the number of memory areas.
  • a memory area (program) in which a memory leak may occur is detected. This avoids the need to change the program on the kernel process side to be monitored. For this reason, it is possible to monitor the memory leak at a lower cost compared to the case of changing the kernel process program.
  • step S41 the determination in step S41 is Yes and the process proceeds to step S61, where the number of records corresponding to the process, that is, the total number of records storing the process name of the target record is registered in the exclusion list 221. Judge whether it is less than the number. If the total number of records is less than the number of memory areas, the determination is yes, and the processing for each record ends here. If the total number of records is greater than the number of memory areas, the determination is no and the process moves to step S42.
  • the memory area monitoring daemon records a time (referred to as an operation start time) for starting the operation management of the server device in the operation start time variable after the embedded OS of the management board and the device management application are activated.
  • a memory leak is caused by adding a program surrounded by a thick line in FIG. 2 and causing the management board (computer) 20 to execute the embedded OS 200 and the device management application 250 including the added portion.
  • the monitoring device is realized, the memory leak monitoring device may be realized by another method. Thereby, all the functions to be installed in the memory leak monitoring program for realizing the memory leak monitoring apparatus may be installed in one program, or may be installed in a plurality of programs.
  • the memory leak monitoring program may be distributed via a computer-accessible recording medium or a communication network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

　本発明を適用した１システムでは、メモリリークの監視対象から除外すべきプロセスを予め登録する、或いは条件を設定することにより除外し、監視対象とするプロセスは、メモリ領域を確保してから現在までの生存時間を計算し、計算した生存時間が閾値として定めた基準時間以上となっていた場合に、メモリリークが発生した可能性があると見なす。それにより、監視対象とするプロセスのプログラム変更を回避しつつ、メモリリークの検出を可能とさせる。

Description

メモリリーク監視装置、及び方法
　本発明は、プログラムが開放すべきメモリ領域を開放しないことによって発生するメモリリークを監視するための技術に関する。
　情報処理装置としてのコンピュータ上で実行されるプログラムには通常、使用可能なハードウェア資源としてのリソースが割り当てられる。プログラムが使用可能なメモリ領域は、そのリソースの一部として確保される。実行中のプログラムは「プロセス」とも呼ばれる。そのプロセスは、ＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ：オペレーティングシステム）の機能の一部を実現するシステムプロセス（以降「カーネルプロセス」）と、ユーザの指示で実行されるユーザプロセス（例えば実行されるアプリケーション・プログラム）とに大別される。
　ＯＳには、メモリ領域の管理機能が搭載される。この管理機能は、プログラム内で指定されたパラメータに応じて、メモリ領域を動的に決定する。決定されたメモリ領域は、例えばそのメモリ領域の先頭アドレスと大きさでプログラムに通知される。
　確保されたメモリ領域は、プログラムからのメモリ開放指示によって開放される。しかし、不備（バグ）などによってプログラムからメモリ開放指示が行われない場合、確保されたメモリ領域は不必要であるにもかかわらず、管理機能によって開放されない。この開放されないメモリ領域にいわゆる「メモリリーク」が発生する。
　仮想記憶方式のＯＳは仮想メモリをカーネル空間とユーザ空間に分離する。カーネル空間はカーネルやデバイスドライバ等のカーネルプロセス用に厳密に確保される、カーネルプロセスが使用可能な全メモリ領域である。ユーザ空間はユーザプロセス用に個別に確保されるメモリ領域である。
　ＯＳ上で動作しているアプリケーションは通常ユーザプロセスである。ユーザプロセスに割り当てられたメモリ領域（ユーザ空間）は、そのプログラム（例えばアプリケーション）の終了により、自動的に開放される。このため、メモリリークが発生したメモリ領域の開放はプログラムを終了させることによって行うことができる。
　一方、システムコール、カーネルのデーモン、割り込み処理などのカーネルプロセスでメモリリークが発生したメモリ領域は、ユーザプロセスのように開放できる機会がない。基本的に、ＯＳを終了させなければメモリリーク分のメモリ領域を開放することができない。このため、メモリリークしたメモリ領域はＯＳが動作している間、蓄積されていくことになる。
　カーネル空間上に発生したメモリリークは、使用可能なメモリ領域を減少させ、ＯＳの動作を阻害する。メモリリーク分のメモリ領域が大きくなると、動作を継続あせるためのメモリ領域が確保できないことにより、アプリケーションの実行を停止させる。ＯＳを実行している装置全体をダウンさせる場合がある。
　ＯＳは、組み込みシステムに組み込みＯＳ（リアルタイムＯＳ）として搭載される場合がある。その組み込みシステムは、特定の用途向けに開発されるコンピュータシステムであり、自動販売機や券売機等の長時間、連続で運用される装置に搭載されることが多い。そのような装置では、たとえ微量なメモリリークであっても、長期間、蓄積される結果、メモリ資源を圧迫しやすく、組み込みＯＳの動作を阻害する危険性が高い。
　メモリリークを根絶するためにはプログラムのデバッグ時に全てのメモリリークの発生原因を検出し修正する必要がある。しかし、デバック時に全ての運用条件を網羅して長時間の運用によるプログラムの継続動作を保障することは完全にはできないのが実情である。このようなことから、カーネル空間上に発生するメモリリークにも適切に対応できるようにすることが極めて重要である。これは、カーネル空間とは異なる固定のアドレス空間上から複数のプロセスのメモリ領域を割り当てる場合も同様である。
　メモリリーク監視装置としては、確保されたメモリ領域を開放すべきか否か管理機能が判定するために、プロセスが確保したメモリ領域の最大生存可能時間、及び警告時間を管理機能に通知する仕組み（インターフェイス）を用意することが知られている。それにより、管理機能は、メモリ領域の確保から警告時間が経過した場合に警告を行い、メモリ領域の確保から最大生存可能時間が経過した場合にそのメモリ領域を強制的に開放する。
　最大生存可能時間等を管理機能に通知するには、メモリリークの監視対象とする各プログラムの変更を行わなければならない。しかし、プログラムの変更には、大きなコストがかかる。このため、カーネル空間上に発生するメモリリークへの対応も、メモリリークの監視対象とする各プログラムの変更を回避する、つまり新たなインターフェイスを用意しないようにすることが望ましいといえる。
特開２００２－１０８６９８号公報 特開２００８－３９４５号公報
　本発明は、メモリリークの監視対象とする各プログラムを変更することなく、その各プロセスが使用可能なメモリ領域が確保されるアドレス空間に発生したメモリリークに適切に対応する技術を提供することを目的とする。
　本発明を適用したメモリリーク監視装置においては、プログラム毎に、該プログラムが使用するメモリ領域を確保してから経過した時間である生存時間を取得し、取得した生存時間を予め閾値として定めた基準時間と比較して、メモリリークが発生している可能性のあるプログラムを検出する。
　プロセスのなかには、生存時間とメモリリークの発生に相関関係が存在する場合がある。このことから、本発明を適用した場合には、メモリリークの監視対象とする各プログラムを変更することなく、その各プロセスが使用可能なメモリ領域が確保されるアドレス空間に発生したメモリリークに適切に対応することができる。
本実施形態によるメモリリーク監視装置を搭載したシステム制御装置を用いて構築されたコンピュータシステムの構成を説明する図である。 本実施形態によるメモリリーク監視装置を搭載したマネジメントボード２０のソフトウェア構成を説明する図である。 メモリ領域リスト２１２のデータ構成を説明する図である。 除外リスト２２１のデータ構成を説明する図である。 （ａ）及び（ｂ）は、除外リスト２１２に登録されるカーネルプロセスを説明する図である。 生存時間によるメモリ領域数を説明するヒストグラムである。 メモリ確保処理のフローチャートである。 メモリ開放処理のフローチャートである。 メモリリーク監視処理のフローチャートである。 装置管理アプリケーションがメモリリークに関する情報表示用に実行する処理のフローチャートである。 各レコードに対する処理のフローチャートである。 閾値設定処理のフローチャートである。 除外リスト２２１のデータ構成を説明する図である（変形例）。 各レコードに対する処理のフローチャートである（変形例）。
　以下、開示のメモリリーク監視装置、方法、及びプログラムに係る実施形態について図面を参照しながら説明する。
　図１は、本実施形態によるメモリリーク監視装置を搭載したシステム制御装置とサーバ装置を用いて構築された情報処理装置としてのコンピュータシステムを説明する図である。このコンピュータシステムは、図１に示す様に、サーバ装置１０にそのサーバ装置１０の管理用のシステム制御装置（ＳＶＰ：ＳｅｒＶｉｃｅ　Ｐｒｏｃｅｓｓｏｒ）であるマネジメントボード（ＭＭＢ：ＭａｎａｇｅＭｅｎｔ　Ｂｏａｒｄ）２０を接続し、そのマネジメントボード２０に表示装置３０を接続した構成となっている。本実施形態によるメモリリーク監視装置は、マネジメントボード２０に搭載される。
　サーバ装置１０は、複数のシステムボード（ＳＢ：Ｓｙｓｔｅｍ　Ｂｏａｒｄ）である処理ユニット１１を不図示のデータ転送装置としてのクロスバで相互に接続した構成となっている。その処理ユニット１１には、例えば図１に示す様に、ＣＰＵ１２、メモリ１３、外部記憶装置１４、及びＩＯ装置１５が搭載されている。マネジメントボード２０との通信は、ＩＯ（Ｉｎｐｕｔ　Ｏｕｔｐｕｔ）装置（入出力装置）１５を介して行われる。
　マネジメントボード２０は、図２に示す様に、ＣＰＵ２１、メモリ２２、ＩＯ装置２３、及び外部記憶装置２４を備えた構成となっている。サーバ装置１０との通信は、ＩＯ装置２３を介して行われる。外部記憶装置２４には、組み込みＯＳやサーバ装置１０管理用のプログラムである装置管理アプリケーション等のプログラム群２５が格納されている。
　図２は、マネジメントボード２０のソフトウェア構成を説明する図である。図２に示す様に、プログラム群２５として、本実施形態の組み込みＯＳ２００、その組み込みＯＳ２００上で動作する装置管理アプリケーション２５０がマネジメントボード２０に搭載されている。組み込みＯＳ２００と装置管理アプリケーション２５０は、サーバ装置２０のシステム制御を行うマネジメントボード２０用の組み込みシステムを構成している。
　組み込みＯＳ２００は、メモリ領域を管理するプログラムであるメモリ領域の管理処理部２１０が搭載される組み込みＯＳが持つ機能２０１に、本実施形態によるメモリリークの監視を可能とするための付加機能２０２を追加することにより構成される。
　組み込みＯＳが持つ機能２０１を実現させるプロセスとして、図２ではシステムコール２３１、カーネルのデーモン２３２、割り込み処理２３３を示している。システムコール２３１は、組み込みＯＳが持つ機能２０１をアプリケーションが呼び出すために実行される。カーネルのデーモン２３２は、プロセス制御等のために常駐するサブプログラムである。割り込み処理は、ハードウェア割り込みを処理する実行プロセスである。これらカーネルプロセスには、メモリ領域の管理処理部２１１によって確保された固定のメモリ資源であるカーネル空間内からメモリ領域が割り当てられる。メモリリークの監視対象とするプロセスは、このような組み込みＯＳ２００上で動作する全てのカーネルプロセスである。
　付加機能２０２には、メモリリークを監視するためのプログラムであるメモリ領域監視デーモン２２０が搭載される。メモリ領域監視デーモン２２０はカーネルプロセスの１つとして動作する。
さらに、メモリ領域の管理処理部２１０には、そのサブプログラムである追加処理部２１１が搭載される。この追加処理部２１１によって、各カーネルプロセスに割り当てたメモリ領域を示すメモリ領域リスト２１２が管理される。このメモリ領域リスト２１２は、例えばメモリ２２に値が格納される配列変数である。
　図３は、メモリ領域リスト２１２のデータ構成を説明する図である。図３に示す様に、メモリ領域リスト２１２には、カーネル空間内から確保されたメモリ領域毎に、そのメモリ領域に係わるデータが格納されたレコードを備える。各レコードには、データとして、アドレス、確保したサイズ、確保時刻、プロセス名、リークフラグが格納される。アドレスは、確保されたメモリ領域の先頭アドレスである。確保したサイズは、メモリ領域のアドレス数である。確保時刻は、対応するメモリ領域をカーネルプロセスに割り当てた時刻である。この時刻は、例えばＣＰＵ２１に搭載されるハードタイマが計時する現在時刻である。プロセス名は、メモリ領域を割り当てたプロセスの識別データである。リークフラグは、メモリリークが発生した可能性を示すものである。「０」はメモリリークが発生した可能性がないことを示し、「１」はその可能性が存在することを示している。
　カーネルプロセスによるメモリ領域の確保、及び開放は、メモリ領域の管理処理部２１０への要求によって行われる。管理処理部２１０は、メモリ領域の割り当てがカーネルプロセスから要求された場合、図７に示すメモリ確保処理を実行する。
　このメモリ確保処理では、先ず、ステップＳ１でメモリ領域の確保処理を行い、その確保処理で確保したメモリ領域のアドレス（先頭アドレス）、及びサイズをカーネルプロセスに渡す。次にステップＳ２において、アドレス、サイズの他に、確保時刻、プロセス名、値が０のリークフラグをメモリ領域リスト２１２に登録する。その登録後、このメモリ確保処理を終了する。
　一方、カーネルプロセスからメモリ領域の開放が要求された場合には、メモリ領域の管理処理部２１０は図８に示すメモリ開放処理を実行する。そのメモリ開放処理では、以下の処理が実行される。
　先ず、ステップＳ１１では、カーネルプロセスから要求されたメモリ領域を開放するための処理を実行する。続くステップＳ１２では、開放するメモリ領域に対応するレコードを抽出し、削除することによりメモリ開放処理を行う。その後、このメモリ開放処理を終了する。
　追加処理部２１２は、上記ステップＳ２及びＳ１２を実行することで実現される。
　メモリ領域監視デーモン２２０は、除外リスト２２１、閾値２２２、運用開始時刻変数２２３を管理する。除外リスト２２１は、カーネルプロセスのなかでメモリリークの監視対象から除外するプロセスの管理に使用される。図４に示す様に、監視対象から除外するプロセスの識別データ（ここではプロセス名）が登録されている。本実施形態では、後述するように、メモリ領域を確保してから経過した時間（生存時間）に着目してメモリリークが発生した可能性を判定する。閾値２２２は、その可能性を判定するために、生存時間と比較される基準時間である。運用開始時刻変数２２３は、組み込みＯＳ２００が起動した運用開始時刻が代入される変数である。その運用開始時刻変数２２３に実際に代入されるのは、メモリ領域監視デーモン２２０が起動した時刻である。除外リスト２２１及び閾値２２２は、管理者等により予め与えられるデータである。
　図５（ａ）及び（ｂ）は、除外リスト２１２に登録されるカーネルプロセスを説明する図である。図５（ａ）は、除外リスト２１２に登録すべきでないカーネルプロセスでのメモリ領域の確保、図５（ｂ）は、監視対象から除外するカーネルプロセスでのメモリ領域の確保の例をそれぞれ示している。図５（ａ）及び（ｂ）中、黒丸はメモリ領域を確保した時刻、黒四角はメモリ領域を開放した時刻をそれぞれ示している。それにより、黒丸と黒四角を結ぶ線はメモリ領域を確保している生存時間を示している。
　図５（ａ）に示す様に、カーネルプロセスでメモリリークが発生した場合、そのプロセスで確保されたメモリ領域は、組み込みＯＳ２００を終了するか、或いは強制的に開放しない限り、開放されない。そのようなメモリリークが発生する可能性が考えられるカーネルプロセスは、生存時間が閾値２２２を越えた時点でリークフラグの値を１にする。一方、図５（ｂ）に示す様に、生存時間が閾値２２２を越えてもメモリ領域が開放されるカーネルプロセスでは、生存時間が閾値２２２を越えることをメモリ領域の開放の条件にするのは望ましくない。なぜなら、処理を実行するために比較的に長い時間を必要としていると考えられるからである。このことから、そのようなカーネルプロセスは除外リスト２２１に登録することにより、開放すべきでないメモリ領域の開放を回避させる。
　図６は、生存時間によるメモリ領域数を説明するヒストグラムである。縦軸にメモリ領域数、横軸に生存時間（運用開始時刻、或いは確保時刻を基準とした生存時間）をそれぞれ取っている。
　カーネルプロセスには、割り込み処理２３３及びシステムコール２３１などのように、比較的に短時間に確保したメモリ領域を開放するもの、確保したメモリ領域を長時間開放しないものが存在する。前者は範囲Ａ内のものであり、後者は範囲Ｂ内と範囲Ｃ内のものである。また、範囲Ｃ内の領域については組み込みＯＳ２００の起動時、或いは起動後直ちに実行されるプロセスによって確保されるメモリ領域である。このため、そのメモリ領域についてメモリリークが発生しているというバグはデバッグ時に発見され易い。従って、本実施形態では範囲Ｃ内のメモリ領域を信頼性の高いメモリ領域として監視対象から除外し、範囲Ａと範囲Ｃの間である範囲Ｂ内の生存時間となっているメモリ領域のみを監視対象とする。範囲Ｂ内に含まれるメモリ領域はすべてメモリリークが発生している可能性があると見なすようにしているが、範囲Ｂ内のメモリ領域であっても信頼性が高いカーネルプロセスが確保したものは除外リスト２２１に格納することにより監視対象から除外する。このようなことから、閾値２２２を用いたメモリリークの監視であっても、そのメモリリークが発生したカーネルプロセスを高精度に特定することができる。
　上記閾値２２２は、例えばデバック時に、図１２に示す様な閾値設定処理を実行することにより設定することができる。この設定処理は、メモリ領域の確保により、閾値２２２として設定する選択肢となる時間を抽出するものである。図８に示すメモリ開放処理において、ステップＳ１１とＳ１２の間にステップＳ５１～Ｓ５３の処理を実行する。ここで、その加えた処理について詳細に説明する。
　ステップＳ５１では、開放時刻を記録する。次のステップＳ５２では、開放時刻から確保時刻を減算した結果（生存時間）が、それまでの閾値より大きいか否か判定する。計算した生存時間が閾値より大きい場合、判定はＹｅｓとなり、ステップＳ５３でその生存時間を新たに閾値とした後、ステップＳ１２に移行する。生存時間が閾値以下であった場合には、判定はＮｏとなってステップＳ１２に移行する。
　この閾値設定処理は、監視対象とすべきでないプロセスを対象として、閾値を抽出することが望ましい。
　メモリ領域監視デーモン２２０は、組み込みＯＳ２００の起動によって起動した後、現在時刻を例えばハードタイマから取得し、運用開始時刻変数２２３に代入する。その後は、例えば一定時間間隔、或いは予め設定されたタイミングで、図９に示すメモリリーク監視処理を実行する。ここでそのメモリリーク監視処理について詳細に説明する。
　先ず、ステップＳ２１では、メモリ領域リスト２１２を構成するレコード（メモリ領域）毎に、メモリリークが発生している可能性を判定するための各レコードに対する処理を実行する。続くステップＳ２２では、各レコードに対する処理の実行によって、メモリリークの可能性があるメモリ領域が発見されたか否か判定する。その可能性があるメモリ領域が発見された場合、判定はＹｅｓとなってステップＳ２３に移行する。その可能性があるメモリ領域が発見できなかった場合には、判定はＮｏとなり、ここでメモリリーク監視処理を終了する。
　ステップＳ２３では、装置管理アプリケーション２５０に、メモリ領域リスト２１２中のリークフラグが１のレコードを通知する。次のステップＳ２４では、プロセスごとのメモリ使用量、つまりメモリ領域のサイズを計算し、１プロセスあたりのメモリ使用量の平均値を求める。その次に移行するステップＳ２５では、予め定められた起動可能なプロセス数に、求めた平均値を乗算する。その乗算結果は以降「限界サイズ」と呼ぶ。
　ステップＳ２５に続くステップＳ２６では、限界サイズがカーネル空間に割り当てることのできるメモリ２２の空き領域サイズより大きいか否かを判定する。限界サイズが空き領域サイズより大きい場合、判定はＹｅｓとなり、ステップＳ２７でリークフラグが１のレコードで管理するメモリ領域を強制的に開放した後、このメモリリーク監視処理を終了する。限界サイズが空き領域サイズ以下であった場合、判定はＮｏとなり、ここでこのメモリ領域監視処理を終了する。
　限界サイズは、１プロセスあたりのメモリ使用量の平均値が大きいほど、大きくなる。これは、プロセスがメモリ２２のメモリ資源を大きく消費する可能性が高いことを意味する。空き領域サイズはプロセスが確保できるメモリ２２のメモリ資源の最大値である。このようなことから、ステップＳ２６は、メモリ２２のメモリ資源に比較的に余裕があるか否かを判定するための処理となっている。
　なお、余裕の判定は、上記のようなものに限定されない。例えば予め設定した割合のメモリ領域をカーネル空間から確保したか否かにより余裕を判定するようにしても良い。その場合であっても、平均値を考慮しても良い。
　装置管理アプリケーション２５０には、サブプログラムとして状態表示処理部２５１が搭載されている。この状態表示処理部２５１は、メモリ領域監視デーモン２２０から通知されたレコードを用いて、ユーザに発生した可能性のあるメモリリークについての情報を表示装置３０に表示させるためのものである。この状態表示処理部２５１は、装置管理アプリケーション２５０が図１０に示す状態表示処理を実行することで実現される。この状態表示処理では、図１０に示す様に、ステップＳ３１でメモリ領域毎にプロセス名、アドレス、及びサイズを表示する。
　図１１は、上記ステップＳ２１として実行される各レコードに対する処理のフローチャートである。次に図１１を参照して、この処理について詳細に説明する。ここでは便宜的に、図１１には１レコード分に相当する部分のみを抽出して示す。
　先ず、ステップＳ４１では、対象とするレコードのプロセス名が除外リスト２２１に登録されているか否か判定する。そのプロセス名が除外リスト２２１に登録されていた場合、判定はＹｅｓとなり、ここで１レコード分の処理を終了する。そのプロセス名が登録されていない場合には、判定はＮｏとなってステップＳ４２に移行する。
　ステップＳ４２では、確保時刻が運用開始時刻の前か否か判定する。対象とするメモリ領域がメモリ領域監視デーモン２２０の起動前に確保されていた場合、判定はＹｅｓとなり、ここでレコード分の処理を終了する。確保時刻が運用開始時刻以降であった場合には、判定はＮｏとなってステップＳ４３に移行する。
　ステップＳ４３では、確保時刻から経過した時間を生存時間として計算する。次のステップＳ４４では、生存時間が閾値２２２より短いか否か判定する。生存時間が閾値２２２より短い場合、判定はＹｅｓとなり、ここで１レコード分の処理を終了する。生存時間が閾値２２２以上であった場合には、判定はＮｏとなり、ステップＳ４５で対象とするレコードのリークフラグを１にした後、１レコード分の処理を終了する。
　なお、本実施形態では、除外リスト２２１にはプロセス名のみを登録するが、他の情報も併せて登録するようにしても良い。例えば図１３に示す様に、メモリ領域数を併せて登録するようにしても良い。これは図３に示す様に、同じプロセスが複数のメモリ領域を確保することがあるからである。このことから、メモリ領域数（プロセスで確保可能な最大メモリ領域数）も登録する場合には、メモリ領域数が異常に増えるのをより確実に回避することができる。
　このようにして、本実施形態では、メモリリークが発生する可能性のあるメモリ領域（プログラム）を検出するようにしている。それにより、監視対象とするカーネルプロセス側のプログラムを変更する必要性を回避している。このため、カーネルプロセスのプログラムを変更する場合と比較して、より低コストでメモリリークの監視を行うことができる。
　図１３に示す様な除外リスト２２１を採用する場合、図１１に示す各レコードに対する処理は、図１４に示す様に変形すれば良い。その図１４では、ステップＳ４１の判定がＹｅｓとなってステップＳ６１に移行し、プロセスに該当するレコード数、つまり対象するレコードのプロセス名を格納した全レコード数が除外リスト２２１に登録されたメモリ領域数未満か否か判定する。全レコード数がメモリ領域数未満であった場合、判定はＹｅｓとなり、ここで各レコードに対する処理を終了する。全レコード数がメモリ領域数より大きい場合には、判定はＮｏとなってステップＳ４２に移行する。
メモリ領域監視デーモンは、マネジメントボードの組み込みＯＳおよび装置管理アプリケーションが起動した後、サーバ装置の運用管理を開始する時刻（運用開始時刻と呼ぶ）を運用開始時刻変数に記録する。
　また、本実施形態では、図２中、太線で囲った部分のプログラムを追加し、その追加した部分を含む組み込みＯＳ２００及び装置管理アプリケーション２５０をマネジメントボード（コンピュータ）２０に実行させることにより、メモリリーク監視装置を実現させているが、別の方法によりメモリリーク監視装置を実現させても良い。それにより、メモリリーク監視装置を実現させるメモリリーク監視プログラムに搭載させる機能は、１つのプログラムに全てを搭載しても良く、複数のプログラムに分けて搭載しても良い。このメモリリーク監視プログラムは、コンピュータがアクセス可能な記録媒体、或いは通信ネットワークを介して配布するようにしても良い。

Claims (10)

  1. 　実行されるプログラムがメモリ領域を開放しないことにより発生するメモリリークを監視するメモリリーク監視装置において、
    　前記プログラム毎に、プログラムが使用するメモリ領域を確保してから経過した時間である生存時間を取得する生存時間取得部と、
    　前記生存時間取得部が取得した生存時間を閾値として定められる基準時間と比較することにより、前記メモリリークが発生する可能性のあるプログラムを検出する検出部と、
    　を有することを特徴とするメモリリーク監視装置。
  2. 前記メモリリーク監視装置はさらに、
    　前記メモリリークの検出対象のプログラムが確保するメモリ領域として全メモリ領域が定められている場合に、前記全メモリ領域のうち未使用分に基づいて、前記検出部が検出したプログラムが確保しているメモリ領域を強制的に開放するメモリ領域開放部と、
    　を有することを特徴とする請求項１記載のメモリリーク監視装置。
  3. 前記メモリリーク監視装置において、
    　前記検出部は、前記メモリリークの検出を不要とするプログラムの識別情報が登録された除外リストに基づいて、前記識別情報に対応するプログラム以外のプログラムを対象にして、前記メモリリークを検出する、
    　ことを特徴とする請求項１記載のメモリリーク監視装置。
  4. 前記メモリリーク監視装置において、
    　前記プログラムは、
    前記メモリリーク監視装置上で動作するオペレーティングシステムの機能を実現させるシステムプロセスとして実行されるプログラムである、
    　ことを特徴とする請求項１記載のメモリリーク監視装置。
  5. 前記メモリリーク監視装置において、
    　前記基準時間は、
    前記メモリリークを検出すべきプログラムがメモリ領域を確保してから開放するまでの生存時間に基づいて設定される、
    　ことを特徴とする請求項１記載のメモリリーク監視装置。
  6. 前記メモリリーク監視装置において、
    　前記除外リストにはさらに、
    前記プログラム毎に、プログラムが確保可能なメモリの最大領域の数を示す最大領域数が登録され、
    　前記検出部は、
    前記除外リストに登録されたプログラムのうち前記最大領域数を超えるメモリ領域を確保するプログラムを監視対象とする、
    　ことを特徴とする請求項３記載のメモリリーク監視装置。
  7. 実行されるプログラムがメモリ領域を開放しないことにより発生するメモリリークを監視するメモリリーク監視装置のメモリリーク監視方法において、
    前記メモリリーク監視装置が有する生存時間取得部が、前記プログラム毎に、プログラムが使用するメモリ領域を確保してから経過した時間である生存時間を取得するステップと、
    前記メモリリーク監視装置が有する検出部が、前記生存時間取得部が取得した生存時間を閾値として定められる基準時間と比較することにより、前記メモリリークが発生する可能性のあるプログラムを検出するステップと、
    を有することを特徴とするメモリリーク監視方法。
  8. 前記メモリリーク監視方法はさらに、
    前記メモリリーク監視装置が有するメモリ領域開放部が、前記メモリリークの検出対象のプログラムが確保するメモリ領域として全メモリ領域が定められている場合に、前記全メモリ領域のうち未使用分に基づいて、前記検出部が検出したプログラムが確保しているメモリ領域を強制的に開放するステップと、
    を有することを特徴とする請求項７記載のメモリリーク監視方法。
  9. 前記メモリリーク監視方法はさらに、
    　前記検出部は、前記メモリリークの検出を不要とするプログラムの識別情報が登録された除外リストに基づいて、前記識別情報に対応するプログラム以外のプログラムを対象にして、前記メモリリークを検出するステップ、
    有することを特徴とする請求項７記載のメモリリーク監視方法。
  10. 　前記メモリリーク監視方法において、
    前記基準時間は、
    前記メモリリーク監視装置が有する演算処理装置に、
    　前記メモリリークの検出対象とするプログラム毎に、プログラムがメモリ領域を確保してから開放するまでの生存時間を算出する算出ステップと、
    　前記算出ステップで算出した生存時間のなかから前記基準時間を抽出する抽出ステップと、
    　を実行させることにより算出されることを特徴とする請求項７記載のメモリリーク監視方法。
PCT/JP2009/001503 2009-03-31 2009-03-31 メモリリーク監視装置、及び方法 WO2010113212A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2009/001503 WO2010113212A1 (ja) 2009-03-31 2009-03-31 メモリリーク監視装置、及び方法
JP2011506844A JPWO2010113212A1 (ja) 2009-03-31 2009-03-31 メモリリーク監視装置、及び方法
US13/240,395 US20120072779A1 (en) 2009-03-31 2011-09-22 Memory leak monitoring device and method for monitoring memory leak

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2009/001503 WO2010113212A1 (ja) 2009-03-31 2009-03-31 メモリリーク監視装置、及び方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/240,395 Continuation US20120072779A1 (en) 2009-03-31 2011-09-22 Memory leak monitoring device and method for monitoring memory leak

Publications (1)

Publication Number Publication Date
WO2010113212A1 true WO2010113212A1 (ja) 2010-10-07

Family

ID=42827546

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/001503 WO2010113212A1 (ja) 2009-03-31 2009-03-31 メモリリーク監視装置、及び方法

Country Status (3)

Country Link
US (1) US20120072779A1 (ja)
JP (1) JPWO2010113212A1 (ja)
WO (1) WO2010113212A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016012208A (ja) * 2014-06-27 2016-01-21 富士通株式会社 監視対象プログラムの選択方法、監視対象選択プログラム及び監視対象選択装置
JP2021089745A (ja) * 2014-04-17 2021-06-10 アビニシオ テクノロジー エルエルシー 処理環境の統合監視および制御

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104239192A (zh) * 2013-06-21 2014-12-24 中兴通讯股份有限公司 内存监控处理方法及装置
US8880757B1 (en) * 2013-09-24 2014-11-04 International Business Machines Corporation RDMA resource leakage detection and reporting
US11307923B2 (en) * 2019-07-23 2022-04-19 Vmware, Inc. Memory leak detection
CN110851281A (zh) * 2019-11-13 2020-02-28 北京无限光场科技有限公司 检测内存泄漏的方法、服务器、终端、系统及存储介质
US11334421B2 (en) * 2019-11-15 2022-05-17 Dell Products L.P. Method and apparatus to identify a problem area in an information handling system based on latencies

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04367951A (ja) * 1991-06-17 1992-12-21 Fujitsu Ltd メモリ滞留防止方式
JP2002108698A (ja) * 2000-10-04 2002-04-12 Nissin Electric Co Ltd メモリ管理システム及びメモリ管理方法
JP2005250751A (ja) * 2004-03-03 2005-09-15 Hitachi Ltd メモリリーク監視方法、これを実行するプログラム及び装置
JP2005267434A (ja) * 2004-03-19 2005-09-29 Fujitsu Ltd アプリケーション監視装置、そのプログラム、及びその記録媒体。
JP2007147533A (ja) * 2005-11-30 2007-06-14 Omron Corp センサシステム、安全検知装置の設定機器、安全検知装置の設定方法、プログラム、および、コンピュータ読取り可能な記録媒体
JP2007188244A (ja) * 2006-01-12 2007-07-26 Nec Corp プロセス共有メモリ管理方式、プロセス共有メモリ管理方法及びプログラム
JP2007207213A (ja) * 2006-02-03 2007-08-16 Movell Software:Kk ワイヤレスデバイスのリアルタイム診断に適用する診断情報収集手法
JP2008003945A (ja) * 2006-06-23 2008-01-10 Toshiba Corp 監視制御システムとそのコンピュータ管理方法およびプログラム
JP2008040540A (ja) * 2006-08-01 2008-02-21 Nec Corp エミュレーション装置及びエミュレーション方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7281040B1 (en) * 2000-03-07 2007-10-09 Cisco Technology, Inc. Diagnostic/remote monitoring by email
US20060173877A1 (en) * 2005-01-10 2006-08-03 Piotr Findeisen Automated alerts for resource retention problems
US7434206B2 (en) * 2005-03-10 2008-10-07 Hewlett-Packard Development Company, L.P. Identifying memory leaks in computer systems
US7793161B2 (en) * 2007-05-29 2010-09-07 International Business Machines Corporation Method and apparatus to anticipate memory exhaustion in an open services gateway initiative environment
US20090210750A1 (en) * 2008-02-19 2009-08-20 Sas Institute Inc. Systems And Methods For Identifying Memory Leaks In A Computer System

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04367951A (ja) * 1991-06-17 1992-12-21 Fujitsu Ltd メモリ滞留防止方式
JP2002108698A (ja) * 2000-10-04 2002-04-12 Nissin Electric Co Ltd メモリ管理システム及びメモリ管理方法
JP2005250751A (ja) * 2004-03-03 2005-09-15 Hitachi Ltd メモリリーク監視方法、これを実行するプログラム及び装置
JP2005267434A (ja) * 2004-03-19 2005-09-29 Fujitsu Ltd アプリケーション監視装置、そのプログラム、及びその記録媒体。
JP2007147533A (ja) * 2005-11-30 2007-06-14 Omron Corp センサシステム、安全検知装置の設定機器、安全検知装置の設定方法、プログラム、および、コンピュータ読取り可能な記録媒体
JP2007188244A (ja) * 2006-01-12 2007-07-26 Nec Corp プロセス共有メモリ管理方式、プロセス共有メモリ管理方法及びプログラム
JP2007207213A (ja) * 2006-02-03 2007-08-16 Movell Software:Kk ワイヤレスデバイスのリアルタイム診断に適用する診断情報収集手法
JP2008003945A (ja) * 2006-06-23 2008-01-10 Toshiba Corp 監視制御システムとそのコンピュータ管理方法およびプログラム
JP2008040540A (ja) * 2006-08-01 2008-02-21 Nec Corp エミュレーション装置及びエミュレーション方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021089745A (ja) * 2014-04-17 2021-06-10 アビニシオ テクノロジー エルエルシー 処理環境の統合監視および制御
JP2016012208A (ja) * 2014-06-27 2016-01-21 富士通株式会社 監視対象プログラムの選択方法、監視対象選択プログラム及び監視対象選択装置

Also Published As

Publication number Publication date
US20120072779A1 (en) 2012-03-22
JPWO2010113212A1 (ja) 2012-10-04

Similar Documents

Publication Publication Date Title
WO2010113212A1 (ja) メモリリーク監視装置、及び方法
WO2017063505A1 (zh) 一种服务器硬件故障检测方法及其装置和服务器
JP5176837B2 (ja) 情報処理システム及びその管理方法、制御プログラム並びに記録媒体
CN111767184A (zh) 一种故障诊断方法、装置及电子设备和存储介质
US10545807B2 (en) Method and system for acquiring parameter sets at a preset time interval and matching parameters to obtain a fault scenario type
US20110004791A1 (en) Server apparatus, fault detection method of server apparatus, and fault detection program of server apparatus
TWI632462B (zh) 開關裝置及偵測積體電路匯流排之方法
JP2010086364A (ja) 情報処理装置、動作状態監視装置および方法
JP5506918B2 (ja) コンピュータ・システムを監視するための装置、方法、およびコンピュータ・プログラム
US20110209148A1 (en) Information processing device, virtual machine connection method, program, and recording medium
KR20040047209A (ko) 네트워크 상의 컴퓨터 시스템의 자동 복구 방법 및 이를구현하기 위한 컴퓨터 시스템의 자동 복구 시스템
CN105512000B (zh) 一种操作系统异常信息收集方法、装置及计算机
US9389942B2 (en) Determine when an error log was created
CN114586013A (zh) 启动诊断操作以收集主机信息的基板管理控制器
US11822419B2 (en) Error information processing method and device, and storage medium
JP5623557B2 (ja) 診断データを収集するためのマルチスレッド化コンピューティング環境における方法、装置、およびコンピュータ・プログラム
US20050033952A1 (en) Dynamic scheduling of diagnostic tests to be performed during a system boot process
JP2009176139A (ja) Ｏｓ優先度変更装置及びｏｓ優先度変更プログラム
US8271711B2 (en) Program status detecting apparatus and method
KR102137891B1 (ko) Bmc 환경에서의 사용자 특화 운용 메커니즘에 의한 서버 관리 방법, 기록매체, 및 서버
JP2018180982A (ja) 情報処理装置、およびログ記録方法
KR101783201B1 (ko) 서버 통합 관리 시스템 및 방법
CN109062718B (zh) 一种服务器及数据处理方法
JP2015130023A (ja) 情報記録装置、情報処理装置、情報記録方法、及び情報記録プログラム
JPWO2010018619A1 (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: 09842569

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2011506844

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09842569

Country of ref document: EP

Kind code of ref document: A1