KR100936967B1 - 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치 및 그 방법 - Google Patents

웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치 및 그 방법 Download PDF

Info

Publication number
KR100936967B1
KR100936967B1 KR1020090071654A KR20090071654A KR100936967B1 KR 100936967 B1 KR100936967 B1 KR 100936967B1 KR 1020090071654 A KR1020090071654 A KR 1020090071654A KR 20090071654 A KR20090071654 A KR 20090071654A KR 100936967 B1 KR100936967 B1 KR 100936967B1
Authority
KR
South Korea
Prior art keywords
memory
thread
transaction
memory size
repository
Prior art date
Application number
KR1020090071654A
Other languages
English (en)
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 KR1020090071654A priority Critical patent/KR100936967B1/ko
Application granted granted Critical
Publication of KR100936967B1 publication Critical patent/KR100936967B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3037—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a memory, e.g. virtual memory, cache
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs

Landscapes

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

Abstract

본 발명은 WAS 운영 하에서 메모리 주소, 메모리 사이즈, 쓰레드 식별자 및 트랜잰셕 식별자를 활용하여 사용자 프로그램의 메모리 누수를 추적하는 장치 및 그 방법에 관한 것이다. 본 발명에 의한 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 방법은, 쓰레드가 수행하는 트랜잭션의 종료 시점에 쓰레드의 메모리 사이즈와 객체의 메모리 사이즈를 수집하여 쓰레드 ID 및 트랜잭션 ID와 함께 리파지토리에 저장하는 단계; 리파지토리에 소정 기간 저장된 자료를 이용하여 메모리 증가가 있는 트랜잭션을 검출하고, 메모리 증가가 있는 트랜잭션에 대하여 메모리 사이즈 변화를 표시하는 단계; 및 리파지토리에 저장된 자료의 쓰레드 ID 및 트랜잭션 ID를 이용하여 상기 메모리 증가가 있는 트랜잭션과 대응하는 객체 중에서 메모리 증가가 있는 객체를 검출하고, 메모리 증가가 있는 객체의 메모리 사이즈 변화를 표시하는 단계;를 포함하여 구성된다.

Description

웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치 및 그 방법{Apparatus for tracing memory leaks of user programs on WAS environment and method thereof}
본 발명은 웹 어플리케이션 서버(Web Application Server : 이하 WAS라 한다) 운영 하에서의 성능 모니터링에 관한 것으로, 더욱 상세하게는 WAS 운영 하에서 메모리 주소, 메모리 사이즈, 쓰레드 식별자 및 트랜잰셕 식별자를 활용하여 사용자 프로그램의 메모리 누수를 추적하는 장치 및 그 방법에 관한 것이다.
1990년대 후반 인터넷의 보급과 일반화를 통해 각종 정보 서비스가 유연함과 사용자 접근성이 높은 웹 어플리케이션 형태로 구현되고, 이에 따라 IT 인프라 시스템은 클라이언트/서버 구조에서 웹 기반 구조로 변화되었다. 웹 기반 구조는 기본적으로 WEB - WAS - DBMS로 구성되며 더 복잡하게 구성될 수 있다.
WAS는 웹으로 구현되는 사용자 어플리케이션과 비즈니스 데이터를 관리하는 DBMS와의 연동을 지원하는 미들웨어로서의 기능과 시스템 보안 및 안정성, 그리고 다양한 웹 인프라의 구성 및 서비스 속도 향상을 위한 기능을 제공한다. WAS는 대부분이 자바 기반으로 J2EE(Java Platform Enterprise Edition) 표준을 수용하고 있으나, .Net이나 Citrix 기반인 비JAVA 계열도 존재한다. WAS의 대부분을 차지하 는 J2EE는 자바로 구현된 어플리케이션(대표적 웹)을 동작시킬 수 있는 환경을 표준화한 것이다.
JVM(Java Virtual Machine)의 가장 큰 장점은 생성된 객체에 대해서 자동 Garbage Collection(이하 GC라 한다) 기능을 제공한다는 것이다. 따라서, 개발자가 메모리 관리에 크게 신경을 쓰지 않고도 사용되지 않는 객체는 GC에 의해 메모리에서 지워진다.
그러나 문제는 JVM의 GC에 의해 메모리가 정리되지 않는 객체도 존재한다는 것이다. GC에 의해 메모리가 정리 되지 않는 경우는 아래와 같다.
1. 정적(static) 변수에 의한 객체 참조
2. 모든 현재 자바 쓰레드 스택 내의 지역 변수, 매개 변수에 의한 객체 참조
3. JNI(Java Native Interface) 프로그램에 의해 동적으로 만들어지고 제거되는 JNI 글로벌(global) 객체 참조
일반적으로 '메모리 누수'라는 것은 더 이상 사용되지 않는 객체(Object)를 프로그램이 참조(reference)함으로써 GC가 되지 않고 객체의 메모리 공간이 프로그램에 의해 점유되어 있는 상태이다. 그러한 메모리 누수 현상이 있으면 WAS에서 프로그램을 실행할 때마다 지속적으로 메모리가 증가되어 성능 저하뿐만 아니라 결국에는 Out Of Memory Exception 발생으로 프로그램이 종료되는 심각한 현상이 발생한다.
한편, '객체'는 저장공간에서 할당된 공간을 의미한다. 프로그래밍 언어는 변수를 이용해 객체에 접근하므로 객체와 변수라는 용어는 종종 함께 사용되지만, 메모리가 할당되기 전까지 객체는 존재하지 않는다는 점에서 차이가 있다.
또한, '트랜잭션'은 기본적으로 고객조회, 신규 고객 등록같이 사용자가 웹화면에서 실행하는 업무 단위 프로그램을 의미하고, '쓰레드'는 트랜잭션에 의해 요청되는 작업을 실제로 수행하는 흐름의 단위이다. WAS 운영 하에서는 하나의 트랜잭션에 대응하는 수많은 작업의 흐름이 동시에 또는 독립된 시간대에 존재하게 되고, 각 작업의 흐름은 쓰레드의 형태로 존재하게 된다.
종래에 사용되고 있는 메모리 누수 감지 기능은 도 1과 같이 수행된다.
먼저, 모니터링 대상을 먼저 예측 하고 감시 대상(주로 HashMap과 같은 collection 객체)를 지정한다(S10).
이후, 모니터링 대상 객체를 사용하는 시점의 collection 객체의 element count만을 수집하고, 쓰레드의 stack dump를 수행한다(S12). 이 때, 개수(count)의 증감만을 모니터링 하여 객체에 대한 사이즈 계산이 안되므로, 개수 변화를 확인하기 위해서는 객체를 사용하는 모든 경우를 모니터링 하여야 한다. 또한, 사후에 참조 관계 파악을 위해 모니터링 대상을 접근하는 모든 쓰레드에 대한 stack dump를 수집하여 상당한 부하를 발생 하게 된다.
다음, collection 객체의 element count의 증감을 추적하고(S14), stack dump 데이터를 분석하여 collection 객체를 사용한 트랜잭션을 파악한다(S16). 이 때, 어느 트랜잭션에서 메모리 누수를 발생하는 지는 수집된 데이터만으로는 알 수 없고, 파악된 모든 트랜잭션을 분석하거나 추정을 통해서 개발자의 도움(로직 분석)을 받아서 확정할 수 있다.
메모리 누수를 감지하기 위한 종래의 다른 방법은 JVM HEAP DUMP를 이용하는 것이다. 이 방법은 메모리 누수가 있는 상태에서 JVM HEAP DUMP를 받은 파일을 분석하여 메모리 누수가 있는 객체를 찾아내는 방식이다. 이 방법에서는 객체간의 상호 참조 관계가 복잡하기 때문에 추정에 의해 참조 관계를 단절시키는 방식으로 복잡한 참조 관계를 단순화 해 가면서 문제의 원인을 찾아간다. 그런데, 순환 참조관계에 있는 경우 순환 참조 관계를 벗어 나서 원인을 찾기가 대단히 어렵다는 문제점이 있다.
도 2에 도시된 단순한 그림을 통해서도 이를 확인할 수 있다. '바'에서 메모리 누수가 있을 때, 이를 참조하는 원인을 찾기 위해 참조관계를 추적하면, '라', '나', '다'의 순환 관계를 만나게 된다. 최종 원인인 '가'로 가기 위해서는 이 순환 관계에서 벗어나야만 한다.
위의 두 방식을 단순화하여 표현하면, 먼저 메모리 누수가 있는 객체를 찾아야 하고, 해당 객체를 찾은 후에는 이를 사용하는 응용프로그램을 찾아서 메모리 누수에 대한 로직을 검증해야 한다는 것이다. 이와 같은 종래의 방식의 단점은 먼저 대상을 예측해야 하므로 사전에 상당한 조사를 필요로 하고, 또한 모니터링의 결과를 가지고서도 객체의 사이즈를 구하지 못하므로 정확한 메모리 점유 크기 파악이 안되어 실제로 어느 정도 메모리 부하를 주는 지 계량할 수가 없고, 대상 객체를 사용한 쓰레드에 대한 참조 관계를 완전한 자동으로 분석할 수 없으므로 상당한 시간과 노력과 노하우를 필요로 하게 된다는 것이다.
또한 지연 메모리 누수(slow memory leak)의 경우에는 한 번의 heap dump 분석으로 해결할 수 없고, 여러 시점의 heap dump를 비교해야만 한다.
본 발명은 상기한 종래의 문제점을 해결하기 위하여 창안된 것으로, 쓰레드 ID 및 트랜잭션 ID 연결을 통해 참조 관계를 단순화하여 톱다운 및 보톰업 메모리 누수 추적을 단순화한 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치 및 그 방법을 제공함을 목적으로 한다.
또한, 모니터링 대상의 전수 조사가 아니라 샘플링 방식을 도입하여 모니터링에 따른 부하를 줄일 수 있는 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치 및 그 방법을 제공함을 목적으로 한다.
또한, 객체의 메모리 주소를 활용하여 메모리 증가 현상을 추적함으로써 해당 객체에서의 메모리 증가 현상을 보다 명확히 확인할 수 있는 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치 및 그 방법을 제공함을 목적으로 한다.
상기의 목적을 달성하기 위하여, 본 발명에 의한 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 방법은, (a) 쓰레드가 수행하는 트랜잭션의 종료 시점에 쓰레드의 메모리 사이즈와 객체의 메모리 사이즈를 수집하여 쓰레드 ID 및 트랜잭션 ID와 함께 리파지토리에 저장하는 단계; (b) 상기 리파지토리에 소정 기간 저장된 자료를 이용하여 메모리 증가가 있는 트랜잭션을 검출하고, 메모리 증가가 있는 트랜잭션에 대하여 메모리 사이즈 변화를 표시하는 단계; 및 (c) 상기 리파지토리에 저장된 자료의 쓰레드 ID 및 트랜잭션 ID를 이용하여 상기 메모리 증가가 있는 트랜잭션과 대응하는 객체 중에서 메모리 증가가 있는 객체를 검출하고, 메모리 증가가 있는 객체의 메모리 사이즈 변화를 표시하는 단계;를 포함하여 구성된다.
상기 메모리 누수 추적 방법에 있어서, 상기 (a) 단계는, (a1) 수집 주기를 설정하는 단계; (a2) 쓰레드가 수행하는 트랜잭션의 종료 시점에 쓰레드의 메모리 사이즈와 객체의 메모리 사이즈를 수집하고, 현재 시간을 최종 수집 시간으로 두고, 수집된 쓰레드의 메모리 사이즈, 객체의 메모리 사이즈, 쓰레드 ID, 트랜잭션 ID 및 최종 수집 시간을 리파지토리에 저장하는 단계; 및 (a3) 상기 (a2) 단계의 쓰레드에 대응하는 트랜잭션과 동일한 트랜잭션에 대응하는 쓰레드가 수행하는 트랜잭션의 종료 시점의 현재 시간과 상기 (a2) 단계의 수집 시간의 차이가 설정된 수집 주기를 초과한 경우, 쓰레드의 메모리 사이즈와 객체의 메모리 사이즈를 수집하고, 현재 시간을 최종 수집 시간으로 갱신하고, 수집된 쓰레드의 메모리 사이즈, 객체의 메모리 사이즈, 쓰레드 ID, 트랜잭션 ID 및 최종 수집 시간을 리파지토리에 저장하는 단계;를 포함함을 특징으로 한다.
상기 메모리 누수 추적 방법에 있어서, (d) 상기 리파지토리에 소정 기간 저 장된 자료를 이용하여 동일한 메모리 주소를 가진 객체 중 메모리 증가가 있는 객체를 검출하고, 메모리 증가가 있는 객체에 대하여 메모리 사이즈 변화를 표시하는 단계; 및 (e) 상기 리파지토리에 저장된 자료의 쓰레드 ID 및 트랜잭션 ID를 이용하여 상기 (d) 단계에서 검출된 객체를 사용하는 모든 트랜잭션을 표시하는 단계;를 더 포함함을 특징으로 한다.
상기 다른 목적을 달성하기 위하여, 본 발명에 의한 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치는, 쓰레드가 수행하는 트랜잭션의 종료 시점에 쓰레드의 메모리 사이즈와 객체의 메모리 사이즈를 수집하는 자료 수집부; 상기 자료 수집부에 의해 수집된 자료를 쓰레드 ID 및 트랜잭션 ID와 함께 저장하는 리파지토리; 및 상기 리파지토리에 소정 기간 저장된 자료를 이용하여 메모리 증가가 있는 트랜잭션을 검출하고, 메모리 증가가 있는 트랜잭션에 대하여 메모리 사이즈 변화를 표시하고, 상기 리파지토리에 저장된 자료의 쓰레드 ID 및 트랜잭션 ID를 이용하여 상기 메모리 증가가 있는 트랜잭션과 대응하는 객체 중에서 메모리 증가가 있는 객체를 검출하고, 메모리 증가가 있는 객체의 메모리 사이즈 변화를 표시하는 톱다운 메모리 누수 추적부;를 포함하여 구성된다.
상기 메모리 누수 추적 장치에 있어서, 상기 자료 수집부는, 수집 주기를 설정하는 수집 주기 설정부; 및 쓰레드가 수행하는 트랜잭션의 종료 시점에 현재 시간과 동일한 트랜잭션에 대응하는 쓰레드에 의해 설정된 최종 수집 시간과의 차이가 상기 수집 주기를 초과한 경우, 쓰레드의 메모리 사이즈와 객체의 메모리 사이즈를 수집하고, 현재 시간을 최종 수집 시간으로 갱신하고, 수집된 쓰레드의 메모리 사이즈, 객체의 메모리 사이즈, 쓰레드 ID, 트랜잭션 ID 및 최종 수집 시간을 상기 리파지토리에 저장하는 수집부;를 구비함을 특징으로 한다.
상기 메모리 누수 추적 장치에 있어서, 상기 리파지토리에 소정 기간 저장된 자료를 이용하여 동일한 메모리 주소를 가진 객체 중 메모리 증가가 있는 객체를 검출하고, 메모리 증가가 있는 객체에 대하여 메모리 사이즈 변화를 표시하고, 상기 리파지토리에 저장된 자료의 쓰레드 ID 및 트랜잭션 ID를 이용하여 상기 검출된 객체를 사용하는 모든 트랜잭션을 표시하는 보톰업 메모리 누수 추적부;를 더 포함함을 특징으로 한다.
본 발명에 의하면, 쓰레드 ID 및 트랜잭션 ID 연결을 통해 참조 관계를 단순화하여 톱다운 및 보톰업 메모리 누수 추적을 단순화 할 수 있고, 모니터링 대상의 전수 조사가 아니라 샘플링 방식을 도입하여 모니터링에 따른 부하를 줄일 수 있고, 또한, 객체의 메모리 주소를 활용하여 메모리 증가 현상을 추적함으로써 해당 객체에서의 메모리 증가 현상을 보다 명확히 확인할 수 있다.
이하에서는 첨부도면을 참조하여 본 발명에 대해 상세히 설명한다.
도 1에 도시된 바와 같이, 본 발명에 의한 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치는 자료 수집부(10), 리파지토리(20), 톱다운 메모리 누수 추적부(30) 및 보톰업 메모리 누수 추적부(40)를 포함하여 구성된다.
자료 수집부(10)는 쓰레드가 수행하는 트랜잭션의 종료 시점에 쓰레드의 메모리 사이즈와 객체의 메모리 사이즈를 수집한다.
자료 수집부(10)는 쓰레드가 수행하는 트랜잭션의 종료 시점에 쓰레드의 메모리 사이즈를 계산하는데, 이 때 쓰레드의 메모리 사이즈는 쓰레드의 멤버 객체의 메모리 사이즈를 각각 계산하여 이의 합으로 구한다. 각각의 멤버 객체의 메모리 사이즈는 각각의 멤버 객체가 가진 멤버 객체의 메모리 사이즈를 계산하고, 이를 더 이상 멤버가 없는 객체(Primitive type)까지 계속 계산한다. 각각의 객체의 메모리 사이즈는 메모리 주소와 함께 수집되어 리파지토리(20)에 보관된다.
간단한 계층 구조를 예시 하면 아래와 같다.
Thread { Member 1, Member 2, Member 3 }
Member 1 { member a, member b, member c }
member a { member x, member y, member z }
…
Member 2 { member a, member b, member c }
…
결국, 객체의 메모리 사이즈는 그 객체가 포함하고 있는 멤버 객체의 사이즈의 합으로 하여 계층적 포함 관계를 계속해서 내려가서 계산하게 되고, 최종적으로는 기본형( Primitive type )의 사이즈와 선언된 데이터 형의 기본 할당 사이즈의 합이다.
도 4는 트랜잭션의 쓰레드의 메모리 사이즈가 수집된 데이터 예제 화면과 트랜잭션의 쓰레드에서 사용된 멤버 변수(객체)의 메모리 사이즈가 수집된 데이터의 예제 화면을 대비하여 도시한다. 도 4에 도시된 바와 같이, 쓰레드 ID는 쓰레드와 맴버 객체를 연결하는 키(key)의 역할을 한다.
메모리 누수라는 것은 GC에 의해서 정리 되지 않는 객체가 존재하는 것이므로 쓰레드와 멤버 변수(객체)의 사이즈를 계산할 수 있으면, 모든 사용에 대해서 굳이 메모리 사이즈를 계산하지 않더라도 샘플링(SAMPLING) 방식의 조사만으로도 메모리 사이즈의 증가를 추적할 수 있게 된다. 즉 사용중인 객체에서 GC에 의한 정리가 되지 않고 메모리 증가가 있다면 모든 사용 시가 아닌 특정 시점에 그 객체의 메모리 사이즈를 계산하더라도 그 객체의 메모리 증가 여부를 시계열 추이 그래프로 파악할 수 있게 된다.
이를 위해서 메모리 누수 모니터링의 옵션에 트랜잭션 실행에 대해서 수집 주기를 30분 또는 60분 등으로 지정할 수 있다. 이렇게 하면 예를 들어 수집주기를 30분으로 지정한 경우 트랜잭션 T에 대해서 10시 30분 00초에 실행되는 것에 대해서 메모리 사이즈를 계산하고 데이터를 저장하였다면, 이후 계속해서 트랜잭션 T 가 실행되더라도 11시 00분 00초가 되기 전까지는 메모리 사이즈 계산이나 데이터 수집을 하지 않고 있다가, 이 시간 이후 실행되는 첫 번째 T 트랜잭션에 대해서 메모리 사이즈 계산을 하고 데이터 저장을 하면 된다.
전수 조사가 아닌 샘플링 방식의 메모리 사이즈 계산의 효과는 명백한 부하의 감소이며, 따라서 실제 운영환경 하에서도 안정적으로 메모리 누수 문제를 해결할 수 있게 하는 기본 기술이 된다. 기존 방식은 전수 조사 방식으로 상당한 부하를 수반하여 실제 운영환경에서 제대로 활용할 수 없었다는 문제점을 내포하고 있었다.
샘플링 방식을 적용한 자료 수집부(10)는 도 1에 도시된 바와 같이, 수집 주기 설정부(12) 및 수집부(14)를 구비한다.
수집 주기 설정부(12)는 수집 주기를 설정하는데, 수집 주기는 프로그램 상에 미리 설정된 값이 될 수도 있고, 모니터 담당자로부터 입력 받아 설정된 값이 될 수도 있다.
수집부(14)는 쓰레드가 수행하는 트랜잭션의 종료 시점에 현재 시간과 동일한 트랜잭션(T)에 대응하는 쓰레드에 의해 설정된 최종 수집 시간과의 차이가 수집 주기 설정부(12)에 의해 설정된 수집 주기를 초과한 경우, 쓰레드의 메모리 사이즈와 객체의 메모리 사이즈를 수집하고, 현재 시간을 최종 수집 시간으로 갱신하고, 수집된 쓰레드의 메모리 사이즈, 객체의 메모리 사이즈, 쓰레드 ID, 트랜잭션 ID 및 최종 수집 시간을 상기 리파지토리(20)에 저장한다.
JAVA 응용 프로그램이 컴파일되어 배포된 후에 임의의 코드를 삽입하는 것을 위빙(WEAVING) 이라고 한다. 위빙은 다른 말로 JAVA BYTE CODE 조작 이라고도 하는데, 이것은 개발자가 작성한 코드 내에 필요한 작업을 추가적으로 하기 위한 BYTE CODE를 원래 코드의 진행 흐름이나 로직 변경을 주지 않고 삽입하는 것을 말합니다. 본 발명에 의한 수집부(14)는 위빙 기법에 의해 트랜잭션을 구성하는 응용 프로그램에 삽입되어 쓰레드가 수행하는 트랜잭션의 종료 시점 필요한 자료를 수집하도록 구성될 수 있다.
리파지토리(20)는 자료 수집부(10)에 의해 수집된 자료를 쓰레드 ID 및 트랜잭션 ID와 함께 저장한다.
수집되는 데이터에는 수집시간, 트랜잭션 ID, 쓰레드 ID, 트랜잭션 시작 시간, 트랜잭션 종료시간, 쓰레드가 수행하는 트랜잭션의 종료 메모리 사이즈, 멤버 변수 이름, 멤버 객체의 메모리 주소, 멤버 객체를 선언한 상위 객체의 메모리 주소, 멤버 변수 클래스 형(type), 멤버 변수 메모리 사이즈, 참조 관계의 레벨(level), 메모리 사이즈 계산의 순서를 나타내는 SEQUENCE 등이 포함될 수 있다.
객체의 메모리 주소는 향후 동일한 객체인지 구분할 수 있는 기준이 되고, 지속적인 메모리 증가를 관찰할 수 있는 기준이 되는 데이터이다. 수집된 데이터는 사후 분석을 위해서 리파지토리(20)에 저장되어서 보관하게 된다.
톱다운 메모리 누수 추적부(30)는 리파지토리(20)에 소정 기간(예를 들면, 1일) 저장된 자료를 이용하여 메모리 증가가 있는 트랜잭션을 검출하고, 메모리 증가가 있는 트랜잭션에 대하여 메모리 사이즈 변화를 시계열 추이 그래프에 의해 표시한다. 또한, 톱다운 메모리 누수 추적부(30)는 리파지토리(20)에 저장된 자료의 쓰레드 ID 및 트랜잭션 ID를 이용하여 메모리 증가가 있는 트랜잭션과 대응하는 객체 중에서 메모리 증가가 있는 객체를 검출하고, 메모리 증가가 있는 객체의 메모리 사이즈 변화를 시계열 추이 그래프에 의해 표시한다.
보톰업 메모리 누수 추적부(40)는 리파지토리(20)에 소정 기간(예를 들면, 1일) 저장된 자료를 이용하여 동일한 메모리 주소를 가진 객체 중 메모리 증가가 있는 객체를 검출하고, 메모리 증가가 있는 객체에 대하여 메모리 사이즈 변화를 시계열 추이 그래프에 의해 표시한다. 또한, 보톰업 메모리 누수 추적부(40)는 리파지토리(20)에 저장된 자료의 쓰레드 ID 및 트랜잭션 ID를 이용하여 검출된 객체를 사용하는 모든 트랜잭션을 표시한다.
도 5에 의하면, 본 발명에 의한 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 과정은 자료 수집 과정(S100), 톱다운 메모리 누수 추적 과정(S200) 그리고 보톰업 메모리 누수 추적 과정(S300)을 포함하여 이루어진다.
먼저, 샘플링 방식을 사용한 자료 수집 과정(S100)은 다음과 같다.
1. 수집 주기를 설정하고, 설정된 값을 소정의 메모리에 저장한다(S110).
2. 쓰레드가 수행하는 트랜잭션의 종료 시점에 쓰레드의 메모리 사이즈와 객체의 메모리 사이즈를 수집하고(S120), 현재 시간을 최종 수집 시간으로 두고(S130), 수집된 쓰레드의 메모리 사이즈, 객체의 메모리 사이즈, 쓰레드 ID, 트랜잭션 ID 및 최종 수집 시간을 리파지토리(20)에 저장한다.
3. 모든 트랜잭션의 실행 시에 쓰레드가 수행하는 트랜잭션의 종료 시점을 확인하고(S140), 현재 시간과실행되는 트랜잭션과 동일한 트랜잭션 ID에 대응하는 최종 수집 시간과의 차이가 설정된 수집 주기를 초과한 경우(S150), 쓰레드의 메모리 사이즈와 객체의 메모리 사이즈를 수집하고, 현재 시간을 최종 수집 시간으로 갱신하고, 수집된 쓰레드의 메모리 사이즈, 객체의 메모리 사이즈, 쓰레드 ID, 트랜잭션 ID 및 최종 수집 시간을 리파지토리(20)에 저장한다. 이와 같은 3.번 과정을 소정 기간 동안 반복함으로써 분석에 필요한 자료를 수집하게 된다.
기존의 메모리 누수 추적 기능이 모니터링 대상 객체를 지정하고 이 객체를 사용하는 쓰레드를 찾기 위해 stack dump를 매번 실행해서 운영 시스템에 상당한 부하와 사용자 응답시간이 지연되는 문제가 있고, heap dump 방식은 참조 관계가 너무 복잡하여 쓰레드에 대한 정보는 찾기가 거의 불가능한 방식이다. 이런 점을 개선하기 위해서 본 방식은 쓰레드가 사용 중일 때는 메모리 사이즈 수집 대상만 파악하고 사용자 트랜잭션이 끝난 시점에 객체의 메모리 사이즈를 계산하면서 해당 쓰레드에 대한 ID도 같이 수집함으로써 메모리 누수가 있는 객체와 그 트랜잭션을 동시에 파악 가능한 데이터를 수집한다.
본 발명에 의한 톱다운(Top down) 방식의 메모리 누수 추적 과정(S200)은 다음과 같다. 도 6은 본 발명에 의한 톱다운(Top down) 방식의 메모리 누수 추적을 나타내는 예시적인 화면이다.
1. 리파지토리(20)에 소정 기간 저장된 자료를 이용하여 메모리 증가가 있는 트랜잭션 목록을 구한다. 이는 분석 기간 동안 수집된 동일 트랜잭션의 마지막 수 집된 메모리 사이즈에서 첫 번째 수집된 트랜잭션의 메모리 사이즈의 차이 값이 양의 정수인 것 들 중 차이 값이 큰 순서대로 나열함으로써 구해진다.
2. 메모리 증가가 있는 트랜잭션의 메모리 사이즈를 시계열 추이 그래프를 제공하여 직관적으로 메모리 증가의 형태를 보고 메모리 누수 여부를 판단할 수 있게 한다(S210). 이 때 시계열 추이 그래프가 우상향의 형태를 띠게 되면 지속적인 메모리 증가가 있다고 할 수 있다.
3. 리파지토리(20)에 저장된 자료의 쓰레드 ID 및 트랜잭션 ID를 이용하여 메모리 증가가 표시되는 트랜잭션의 멤버 객체의 메모리 사이즈를 시계열 추이 그래프를 제공하여 어떤 멤버 객체에서 메모리 증가가 있는 지 시각적으로 즉시 판단할 수 있도록 한다(S220). 멤버 객체에 대해서도 추이 그래프가 우상향의 형태를 띠게 되면 지속적인 메모리 증가가 있다고 할 수 있다.
메모리 증가가 있는 객체를 파악하고 난 뒤 이를 사용한 모든 트랜잭션을 추적할 수 있는 보톰업(BOTTOM UP) 방식 또한 본 발명에 의한 자료 수집으로는 간단 하게 가능하게 된다. 이것은 쓰레드 ID와 트랜잭션 ID를 함께 수집하기 때문에 자연스럽게 가능하게 되는 기능이다.
본 발명에 의한 보톰업(Bottom up) 방식의 메모리 누수 추적 과정(S300)은 다음과 같다. 도 7은 본 발명에 의한 보톰업(Bottom up) 방식의 메모리 누수 추적을 나타내는 예시적인 화면이다.
1. 메모리 증가가 있는 객체의 목록을 구한다. 이는 분석 기간 동안 수집된 동일 메모리 주소를 가진 객체의 마지막 메모리 사이즈에서 첫 번째 수집된 객체의 메모리 사이즈의 차이 값이 양의 정수인 것들 중 차이 값이 큰 순서대로 나열함으로써 구해 진다.
2. 메모리 증가가 있는 객체의 메모리 사이즈를 시계열 추이 그래프를 제공하여 직관적으로 메모리 증가의 형태를 보고 메모리 누수 여부를 판단할 수 있게 한다. 이 때 시계열 추이 그래프가 우상향의 형태를 띠게 되면 지속적인 메모리 증가가 있다고 할 수 있다(S310).
3. 메모리 증가가 표시되는 객체에서 TID와 TRANSACTION ID를 통해서 이 객체를 사용하는 모든 트랜잭션 목록을 손쉽게 파악할 수 있고, 해당 트랜잭션에 대한 정보를 분석하는 여타의 기능으로 이동할 수 있게 한다(S320). 여기에는 앞의 메모리 증가 현상을 파악하는 화면도 있고, 객체의 소스 보기 기능도 있을 수 있다.
객체의 메모리 사이즈와 함께 쓰레드 ID, 트랜잭션 ID를 같이 수집하는 것의 장점은 참조관계가 단순해지면서 문제가 되는 사용자 트랜잭션과 객체를 아주 단순하게 서로 알 수 있게 된다는 점이다.
사용 중인 객체의 메모리 주소를 가지고 이 객체의 메모리 사이즈를 계속해서 수집하여 사후 분석을 할 경우 명확하게 해당 객체에서 메모리 증가 현상이 있는지를 알 수 있게 된다. 기존의 방법은 객체의 이름이나 class type으로만 구분 되어 변수 명이 다르고 사용되는 쓰레드가 다를 경우 이를 동일 객체에서 메모리 증가 현상이 발생되고 있는 지 직접적으로 알 수 있는 방법이 없다.
도 8에 도시된 바와 같은 static 멤버를 가진 class C가 있고 이를 트랜잭션 T1, T2에서 각각 사용할 경우 트랜잭션 실행 시마다 메모리 사이즈를 구할 때, 각각의 멤버 객체에 대한 메모리 주소를 가지고 있다면 class c의 사용은 사용할 때마다 메모리 주소가 달라지지만, class c의 static 객체인 s에 대한 메모리 주소는 항상 동일한 값을 가지고 있다. 따라서 s에 대한 메모리 사이즈 추적을 통해서 메모리 증가 현상을 명확하게 밝힐 수 있게 된다. 도 8에 도시된 예에서는 트랜잭션 T1에서 사용할 때 메모리 증가가 있다는 것을 알 수 있게 되고, 그 원인이 static 변수인 HashMap이라는 것을 알 수 있다.
이제까지 본 발명에 대하여 그 바람직한 실시예들을 중심으로 살펴보았다.　 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다.　 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다.　 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.
도 1은 종래에 사용되고 있는 메모리 누수 감지 기능을 설명하기 위한 흐름도이고,
도 2는 JVM HEAP DUMP 방식에서 순환 참조 관계를 설명하기 위한 도면이고,
도 3은 본 발명에 의한 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치의 전체적인 구성을 도시한 블록도이고,
도 4는 트랜잭션의 쓰레드의 메모리 사이즈가 수집된 데이터 예제 화면과 트랜잭션의 쓰레드에서 사용된 멤버 변수(객체)의 메모리 사이즈가 수집된 데이터의 예제 화면을 대비하여 도시한 것이고,
도 5는 본 발명에 의한 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 방법을 도시한 흐름도이고,
도 6은 본 발명에 의한 톱다운(Top down) 방식의 메모리 누수 추적을 나타내는 예시적인 화면이고,
도 7은 본 발명에 의한 보톰업(Bottom up) 방식의 메모리 누수 추적을 나타내는 예시적인 화면이고,
도 8은 메모리 주소를 활용한 객체의 메모리 증가 현상 추적의 유용성을 설명하기 위한 예제를 도시한 것이다.
<도면의 주요 부분에 대한 부호의 설명>
10 : 자료 수집부 12 : 수집 주기 설정부
14 : 수집부 20 : 리파지토리
30 : 톱다운 메모리 누수 추적부 40 : 보톰업 메모리 누수 추적부

Claims (13)

  1. (a) 쓰레드가 수행하는 트랜잭션의 종료 시점에 쓰레드의 메모리 사이즈와 객체의 메모리 사이즈를 수집하여 쓰레드 ID 및 트랜잭션 ID와 함께 리파지토리에 저장하는 단계;
    (b) 상기 리파지토리에 소정 기간 저장된 자료를 이용하여 메모리 증가가 있는 트랜잭션을 검출하고, 메모리 증가가 있는 트랜잭션에 대하여 메모리 사이즈 변화를 표시하는 단계; 및
    (c) 상기 리파지토리에 저장된 자료의 쓰레드 ID 및 트랜잭션 ID를 이용하여 상기 메모리 증가가 있는 트랜잭션과 대응하는 객체 중에서 메모리 증가가 있는 객체를 검출하고, 메모리 증가가 있는 객체의 메모리 사이즈 변화를 표시하는 단계;를 포함하고,
    상기 (a) 단계는
    (a1) 수집 주기를 설정하는 단계;
    (a2) 쓰레드가 수행하는 트랜잭션의 종료 시점에 쓰레드의 메모리 사이즈와 객체의 메모리 사이즈를 수집하고, 현재 시간을 최종 수집 시간으로 두고, 수집된 쓰레드의 메모리 사이즈, 객체의 메모리 사이즈, 쓰레드 ID, 트랜잭션 ID 및 최종 수집 시간을 리파지토리에 저장하는 단계; 및
    (a3) 상기 (a2) 단계의 쓰레드에 대응하는 트랜잭션과 동일한 트랜잭션에 대응하는 쓰레드가 수행하는 트랜잭션의 종료 시점의 현재 시간과 상기 (a2) 단계의 수집 시간의 차이가 설정된 수집 주기를 초과한 경우, 쓰레드의 메모리 사이즈와 객체의 메모리 사이즈를 수집하고, 현재 시간을 최종 수집 시간으로 갱신하고, 수집된 쓰레드의 메모리 사이즈, 객체의 메모리 사이즈, 쓰레드 ID, 트랜잭션 ID 및 최종 수집 시간을 리파지토리에 저장하는 단계;를 포함함을 특징으로 하는 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 방법.
  2. 제1항에 있어서,
    상기 (a) 단계의 수집은 트랜잭션 별로 샘플링 된 쓰레드에 대하여 수행되는 것을 특징으로 하는 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 방법.
  3. 삭제
  4. 제1항에 있어서, 상기 (b) 단계 및 상기 (c) 단계에서의 메모리 사이즈 변화는,
    시계열 추이 그래프에 의해 표시하는 것을 특징으로 하는 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 방법.
  5. 제1항에 있어서, 상기 (a) 단계는
    쓰레드의 메모리 사이즈와 객체의 메모리 사이즈 뿐만 아니라, 객체의 메모리 주소를 더 수집하는 것을 특징으로 하는 웹 어플리케이션 서버 운영 하에서 사 용자 프로그램의 메모리 누수 추적 방법.
  6. 제5항에 있어서,
    (d) 상기 리파지토리에 소정 기간 저장된 자료를 이용하여 동일한 메모리 주소를 가진 객체 중 메모리 증가가 있는 객체를 검출하고, 메모리 증가가 있는 객체에 대하여 메모리 사이즈 변화를 표시하는 단계; 및
    (e) 상기 리파지토리에 저장된 자료의 쓰레드 ID 및 트랜잭션 ID를 이용하여 상기 (d) 단계에서 검출된 객체를 사용하는 모든 트랜잭션을 표시하는 단계;를 더 포함함을 특징으로 하는 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 방법.
  7. 제6항에 있어서, 상기 (b) 단계, 상기 (c) 단계 및 상기 (d) 단계에서의 메모리 사이즈 변화는,
    시계열 추이 그래프에 의해 표시하는 것을 특징으로 하는 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 방법.
  8. 쓰레드가 수행하는 트랜잭션의 종료 시점에 쓰레드의 메모리 사이즈와 객체의 메모리 사이즈를 수집하는 자료 수집부;
    상기 자료 수집부에 의해 수집된 자료를 쓰레드 ID 및 트랜잭션 ID와 함께 저장하는 리파지토리; 및
    상기 리파지토리에 소정 기간 저장된 자료를 이용하여 메모리 증가가 있는 트랜잭션을 검출하고, 메모리 증가가 있는 트랜잭션에 대하여 메모리 사이즈 변화를 표시하고, 상기 리파지토리에 저장된 자료의 쓰레드 ID 및 트랜잭션 ID를 이용하여 상기 메모리 증가가 있는 트랜잭션과 대응하는 객체 중에서 메모리 증가가 있는 객체를 검출하고, 메모리 증가가 있는 객체의 메모리 사이즈 변화를 표시하는 톱다운 메모리 누수 추적부;를 포함하고,
    상기 자료 수집부는
    수집 주기를 설정하는 수집 주기 설정부;
    쓰레드가 수행하는 트랜잭션의 종료 시점에 현재 시간과 동일한 트랜잭션에 대응하는 쓰레드에 의해 설정된 최종 수집 시간과의 차이가 상기 수집 주기를 초과한 경우, 쓰레드의 메모리 사이즈와 객체의 메모리 사이즈를 수집하고, 현재 시간을 최종 수집 시간으로 갱신하고, 수집된 쓰레드의 메모리 사이즈, 객체의 메모리 사이즈, 쓰레드 ID, 트랜잭션 ID 및 최종 수집 시간을 상기 리파지토리에 저장하는 수집부;를 구비함을 특징으로 하는 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치.
  9. 삭제
  10. 제8항에 있어서, 상기 톱다운 메모리 누수 추적부에서의 메모리 사이즈 변화는,
    시계열 추이 그래프에 의해 표시하는 것을 특징으로 하는 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치.
  11. 제8항에 있어서, 상기 자료 수집부는
    쓰레드의 메모리 사이즈와 객체의 메모리 사이즈 뿐만 아니라, 객체의 메모리 주소를 더 수집하는 것을 특징으로 하는 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치.
  12. 제11항에 있어서,
    상기 리파지토리에 소정 기간 저장된 자료를 이용하여 동일한 메모리 주소를 가진 객체 중 메모리 증가가 있는 객체를 검출하고, 메모리 증가가 있는 객체에 대하여 메모리 사이즈 변화를 표시하고, 상기 리파지토리에 저장된 자료의 쓰레드 ID 및 트랜잭션 ID를 이용하여 상기 검출된 객체를 사용하는 모든 트랜잭션을 표시하는 보톰업 메모리 누수 추적부;를 더 포함함을 특징으로 하는 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치.
  13. 제12항에 있어서, 상기 보톰업 메모리 누수 추적부에서의 메모리 사이즈 변화는,
    시계열 추이 그래프에 의해 표시하는 것을 특징으로 하는 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치.
KR1020090071654A 2009-08-04 2009-08-04 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치 및 그 방법 KR100936967B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020090071654A KR100936967B1 (ko) 2009-08-04 2009-08-04 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치 및 그 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020090071654A KR100936967B1 (ko) 2009-08-04 2009-08-04 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치 및 그 방법

Publications (1)

Publication Number Publication Date
KR100936967B1 true KR100936967B1 (ko) 2010-01-14

Family

ID=41809813

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020090071654A KR100936967B1 (ko) 2009-08-04 2009-08-04 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치 및 그 방법

Country Status (1)

Country Link
KR (1) KR100936967B1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014017701A1 (ko) * 2012-07-27 2014-01-30 부산대학교 산학협력단 메모리 누수 탐지 장치 및 방법, 그리고 컴퓨터로 읽을 수 있는 기록매체
KR101494328B1 (ko) * 2013-06-28 2015-02-23 부산대학교 산학협력단 힙 분석을 이용한 메모리 누수 탐지 장치 및 방법
CN112416793A (zh) * 2020-12-01 2021-02-26 新华三人工智能科技有限公司 一种内存泄漏检测方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008003945A (ja) 2006-06-23 2008-01-10 Toshiba Corp 監視制御システムとそのコンピュータ管理方法およびプログラム
JP2008134709A (ja) 2006-11-27 2008-06-12 Hitachi Ltd メモリリーク検出方法、メモリリーク検出装置及びメモリリーク検出プログラム
KR20080075293A (ko) * 2007-02-12 2008-08-18 삼성전자주식회사 이동통신 시스템에서 메모리 누수 프로세스를 복구하기위한 장치 및 방법

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008003945A (ja) 2006-06-23 2008-01-10 Toshiba Corp 監視制御システムとそのコンピュータ管理方法およびプログラム
JP2008134709A (ja) 2006-11-27 2008-06-12 Hitachi Ltd メモリリーク検出方法、メモリリーク検出装置及びメモリリーク検出プログラム
KR20080075293A (ko) * 2007-02-12 2008-08-18 삼성전자주식회사 이동통신 시스템에서 메모리 누수 프로세스를 복구하기위한 장치 및 방법

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014017701A1 (ko) * 2012-07-27 2014-01-30 부산대학교 산학협력단 메모리 누수 탐지 장치 및 방법, 그리고 컴퓨터로 읽을 수 있는 기록매체
KR101494328B1 (ko) * 2013-06-28 2015-02-23 부산대학교 산학협력단 힙 분석을 이용한 메모리 누수 탐지 장치 및 방법
CN112416793A (zh) * 2020-12-01 2021-02-26 新华三人工智能科技有限公司 一种内存泄漏检测方法及装置

Similar Documents

Publication Publication Date Title
US7293263B2 (en) System and method for memory leak detection in a virtual machine environment
US8359450B2 (en) Memory utilization analysis
Olbrich et al. Are all code smells harmful? A study of God Classes and Brain Classes in the evolution of three open source systems
US9864676B2 (en) Bottleneck detector application programming interface
US7904493B2 (en) Method and system for object age detection in garbage collection heaps
CN111756575B (zh) 存储服务器的性能分析方法及装置、电子设备
CN101615143B (zh) 用于内存泄漏诊断的方法和装置
US8473925B2 (en) Conditional dynamic instrumentation of software in a specified transaction context
Sandoval Alcocer et al. Learning from source code history to identify performance failures
JP5886712B2 (ja) 分散環境におけるトランザクション別に区別されたメトリックの効率的収集
US8418149B2 (en) Differential comparison system and method
US20100017789A1 (en) Selectively Obtaining Call Stack Information Based on Criteria
US20140189438A1 (en) Memory leak detection
US20110029822A1 (en) Tracking of java objects during request processing
US20110016347A1 (en) Tool for Analyzing and Resolving Errors in a Process Server
Habchi et al. On the survival of android code smells in the wild
CN110795357A (zh) 程序监控方法及装置
Habchi et al. The rise of android code smells: Who is to blame?
CN106980572B (zh) 分布式系统的在线调试方法和系统
Weninger et al. Utilizing object reference graphs and garbage collection roots to detect memory leaks in offline memory monitoring
KR100936967B1 (ko) 웹 어플리케이션 서버 운영 하에서 사용자 프로그램의 메모리 누수 추적 장치 및 그 방법
Šor et al. Memory leak detection in Plumbr
KR100965426B1 (ko) 메모리 누수 검출 장치 및 방법
KR101494328B1 (ko) 힙 분석을 이용한 메모리 누수 탐지 장치 및 방법
Fischer et al. System evolution tracking through execution trace analysis

Legal Events

Date Code Title Description
A201 Request for examination
A302 Request for accelerated examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20130104

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20140106

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20150107

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20160107

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20170106

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20171228

Year of fee payment: 9

FPAY Annual fee payment

Payment date: 20181227

Year of fee payment: 10

FPAY Annual fee payment

Payment date: 20200107

Year of fee payment: 11