와스킹의 사건현장

링크
https://blog.hexabrain.net/397

alternatives
개요
심볼릭링크를 생성,제거,관리,조회할 수 있는 기능을 제공하는 GNU 라이센스 툴
주로 리눅스환경에서 default 경로 잡을때 사용

사용법
alternatives --install <링크> <이름> <경로> <우선순위> [--initscript <서비스>] [--slave <링크> <이름> <경로>]* alternatives --remove <이름> <경로>
alternatives --auto <이름>
alternatives --config <이름>
alternatives --display <이름>
alternatives --set <이름> <경로>
alternatives --list

EX) 사용가능한 java목록에 신규 java등록
$ alternatives --install /usr/bin/java java /usr/lib/jvm/jdk8/bin/java 100
$ alternatives --config java
리스트에서 선택

OutOfMemory란?
Garbage Collector가 새로운 Object를 유지 하기 위해 충분한 메모리 공간을 확보하지 못할 때 발생.
Vendor사의 JVM 메모리 모델이 다르기 때문에 사용하는 JVM 메모리 모델을 인지하고 있어야 한다.
  ex) HPUX는 Heap에 Perm이 포함되어 있음.
   IBM 은 Heap과 Perm이 별도 산정.

OOM 유형별 현상 및 조치방법
 1. Heap Memory가 Full인 경우
  1.1 응용프로그램에서의 과도한 사용
   발생하는 시점의 Heap dump, Thread dump가 필요
   여기서 중요한 점은 OOM으로 인해 프로세스가 죽기 전인 해당 현상이 발생하고 있는 시점에서 떠야한다.
   특히 Thread dump는 생성할 당시의 스레드 상태만 알 수 있기 때문에 3초간격으로 3회를 추천.
   그래야 오래 수행되는 특정 스레드를 찾을 수 있기 때문 (3개의 Thread Dump에서 동일하게 수행되고 있는 스레드가 문제일 확률이 높음)
   생성한 Heap dump는 MemoryAnalyzer를 통해 분석
   MemoryAnalyzer에서 StackTrace까지 확인 가능하기에 제대로 된 Heap dump만 있어도 Thread dump는 필요 없다.

  1.2 leak에 의해 점차적으로 쌓이는 경우
   gc log 및 jtstat을 통해 해당 현상의 추이를 확인 할 수 있다.
   추이를 확인하여 메모리 사용률이 높은 지점을 포착하여 Heap dump 생성 후 MemoryAnalyzer를 통해 분석

 2. Perm이 Full인 경우
  Perm 영역은 Class loader에 의해 load되는 Class, Method 등에 대한 Meta 정보가 저장되는 영역이다.
  Code가 올라가는 부분이기 때문에 Code가 모두 Load되고 나면 거의 일정한 수치를 유지한다.
  특히 어플리케이션 디플로이/리디플로이시에 많이 겪을 수 있다.
  따라서 모니터링을 통해 적정한 수치까지 Perm size를 증가 시켜주어야 한다.

 3. C Heap(Native)이 문제인 경우
  3.1 Maxdsiz 
   Maxdsiz란 proccess의 data 세그먼트의 최대 사이즈를 의미하는 HPUX의 커널파라매터 이다.(default 값은 64MB)
   Heap에는 java heap과 c heap으로 나뉘는데 C heap은 jdk내부적으로 C라이브러리를 사용하거나 jni를 통해서 c프로그램을 호출할 시 Data 영역을 사용하게 된다.
   Maxdsiz 문제로 OOM을 마주하게 되었을 때의 조치사항
    1) Maxdsiz 는 최대값인 4G(0xfffff000)로 설정하고, 실행유저의 ulimit의 Data값을 따로 설정하지 말것.
      Maxdsiz는 limit을 지정하는 값이기 때문에, 최대값(4G)으로 설정하여도 아무런 부작용이 없다.
    2) java_q4p를 사용하는 것.(Heap size를 2G 이상 설정하면 자동으로 java_q4p로 실행)
※${JAVA_HOME}/bin/IA64N/java_q4p 로 실행하면 강제적으로 가능
       Maxdsiz로 최대값(4G)을 줘도,  Xmx 500M 로 사용중이라면, java_q2p 까지만 data영역으로 쓸수 있기 때문에, 2G까지 제한 됨.
    3) Glance를 통해 Data 영역 모니터링 방법
      glance 실행 → Shift + m 입력 → jvm PID 입력

  3.2 JAVA C heap small block arena corruption 
   C heap에서 메모리 주소를 침범하여 발생하는 메모리 corruption이 발생할 때(HPUX), _M_SBA_OPTS 옵션을 사용하여 해결 할 수 있다.

    메모리 corruption의 대표 예
    char *p = malloc (10); 
    char *name = (char *) malloc(11);      
    memcpy ( p,name,11); // Problem begins here 

   p는 10 bytes, name은 11 bytes  인데 p에 11bytes를 쓰면, 뒤에 1byte 에 memory corruption이 발생. 이걸 실행시에는 crash가 발생하지 않음. Compile도 문제없이 됨.
   그 1byte는 free list ptr값의 일부였는데 훼손이 된 상태로 있다가 해당 free list ptr값을 가지고 malloc을 하려고 했을때 뭔가 문제가 있다는 걸 감지하여 crash를 내며 죽음.
   Corruption이 언제 일어났는지 알수 없고, app에서 corruption code를 찾기 어렵다면, 편법으로 memory allocation마다 padding을 붙여서 corruption이 일어나는 것에 쿠션장치를 둘수 있으나,
   얼마의 padding이 적절한지는 crash가 안날 때까지 계속 고쳐나가면서 _M_SBA_OPTS 의 적정값을 찾아야 하고 padding만큼 app의 메모리 사용량은 증가하는 side effect가 있으며, 성능도 느려질 수 있다고 한다.

   환경 변수 _M_SBA_OPTS 설정은 두가지 목적으로 적용 및 사용하게 된다.
    1) small block allocator 를 사용하는 주 목적은 성능 개선
     molloc() 요청시 한번에 할당하는 개수를 지정할 수 있어, 할당 시 지정 값 만큼 한번에 할당되어 다음번 molloc() 요청시 미리 할당된 미사용 block을 사용하기 때문에 성능이 개선됨.
    2) C heap에서 corruption이 있을 때
     block 할당 단위를 요구량에 맞추는 것이 아니라 요구량 이상으로 (여기서는 100바이트 단위로) 할당을 하면, 오류로 인해 주소 범위가 조금 벗어나도 할당 범위 안에 있다면 문제를 일으키지 않음.

   환경변수 _M_SBA_OPTS=A:B:C 각 값의 의미 
    Default 값 _M_SBA_OPTS=512:100:16시 맨 앞 512 값보다 작은 값에 적용이란 뜻으로 맨 앞의 값보다 적은 값까지 SBA(small block allocator) 할당이 적용.
        가운데 100값은 한번에 할당 하는 개수를 의미
     마지막 16값은 malloc시 할당 되는 값의 단위
    그래서 Default 값 _M_SBA_OPTS=512:100:16시 malloc(10)을 요청하게 되면 16byte 100개 가 할당되며, 또 다시 malloc(10) 요청이 오면 기존에 16byte 100개 할당되었던 block중 미사용 block을 사용하게 되며, 만일 미사용 block이 없으면 다시 16bite 100개가 할당됨.
    Malloc()이 Malloc(16)byte가 넘게 되면 각 malloc값이 맞춰어 16,32,48,64,80….512까지 맞춰서 100개씩 할당되며 같은 값의 malloc시 할당되었던 block중 미사용 block을 사용하게 되며 만일 미사용 block이 없으면 다시 같은 크기의 byte로 100개 가 할당됨.

   결론적으로 _M_SBA_OPTS 옵션을 사용하여 메모리 corruption이 발생하지 않도록 padding값을 주되, 적정한 값은 설정 후 모니터링을 통해 찾아야 함.

출처 : https://blog.xenomity.com/Summary-Java-Agent-Bytecode-Instrumentation/

What are Java(JVM) Agent?
JVM Agent는 JVM에서 동작하는 Java 어플리케이션으로 JVM의 다양한 이벤트를 전달받거나 정보 질의, 바이트 코드 제어 등을 특정 API(Instrumentation API -java.lang.instrument-)를 통하여 수행할 수 있다.

보통 개발 도구 또는 모니터링 도구 개발에 응용된다.

바이트 코드 변조를 통한 개발의 편의성을 제공하는 AspectJ의 LTW(Load Time Weaver)나 Lombok과 같은 오픈소스가 대표적인 Java Agent의 활용 예이다.

Features
Agent는 지정된 JVM의 실행 가능한 최초 진입점인 ‘main’ 메서드를 가로채기 할 수 있다.
지정된 JVM에서 실행된다.
지정된 JVM의 동일한 System Class Loader 내에서 로드된다.
지정된 JVM의 Security Policy 및 Context의 영향을 받는다.
실행시간에 동적으로 bytecode를 조작할 수 있다.

Agent의 단일 진입점은 위와 같이 ‘premain’ 메서드를 구현하면 되며 바이트 코드를 포함한 추가적인 정보 수집 도구로 Instrumentation 인터페이스를 제공받을 수 있다.

출처 : https://m.blog.naver.com/PostView.nhn?blogId=rbtjqtjql&logNo=220993460343&proxyReferer=&proxyReferer=https:%2F%2Fwww.google.com%2F

■ BCI (Byte Code Instrumentation) ?
Java의 Byte Code에 직접 수정을 가해서, 소스 파일의 수정 없이 원하는 기능을 부여하는 기법
이러한 특징때문에 대부분의 Java 프로파일러나 모니터링 툴들이 BCI 기능을 사용하고 있다. Bytecode를 직접 수정할 수 있으므로 이를 통해 구현할 수 있는 기능은 무궁무진함.

■ Java Bytecode
JVM에서 인지할 수 있는 일종의 기계어(Machine Code)이며, 특정 OS / HW에 의존하지 않는, JVM에만 의존적이기 때문에 서로 다른 환경에서도 하나의 Bytecode로 구동이 가능(JVM은 공통이니까!!)

■ BCI를 활용하여 내가 생성한 클래스 파일 사용하게 하기
ClassReader 객체를 이용해 원래 클래스의 바이트 코드를 읽어들인다.
ClassAdapter 객체를 이용해 바이트 코드를 변경한다.
ClassWriter 객체를 이용해서 변경된 바이트 코드를 얻는다.

원래의 Exception 클래스를 변경(하진 않았지만)하여 새로운 Exception 클래스를 생성하고 파일을 확인하였다.

문제는 어떻게 하면 JVM의 rt.jar에서 제공하는 java.lang.Exception 클래스 파일이 아닌, 내가 생성한 Exception 클래스 파일을 쓰게 하느냐이다.

rt.jar파일을 직접 변경시킬순 없고 (매우 위험하고 법적인 문제가 될 수 있음!) 답은 -Xbootclasspath 옵션을 이용하는 것이다.

즉, -Xbootclasspath/p:<내가 작성한 Exception Class의 path>를 지정하면, JVM은 rt.jar보다 먼저(prepend) 내가 작성한 Exception Class 파일을 읽어들인다.

이렇게 함으로써 rt.jar 파일에 대한 수정을 가하지 않아도 된다.

개요
 HPUX JAVA Minor패치(1.6.0.20 -> 1.6.0.33) 후 특정 로직에서 Exception 발생.

현상
 HPUX JAVA Minor패치(1.6.0.20 -> 1.6.0.33) 후 특정 로직에서 java.lng.NoClassDefFoundEeeor : Could not initialize class com.sun.net.ssl.internal.ssl.SupportedEllipticCurvesExtension 발생

원인
 HPUX JAVA 1.6.0.33으로 업그레이드시 발생하는 exception는com/sun/net/ssl/internal/ssl/SupportedEllipticCurvesExtension에 대한 class를 찾지 못해서 생긴 메시지.
 해당 exception은 JDK-8148516 fix에서 시작합니다. 이 fix의 부작용으로 elliptic curve name extension field 처리에 필요한 elliptic curve cryptography support 를 잃어버렸음.
 잃어버린 elliptic curve cryptography support에 대한 내용 문서 http://bugs.java.com/view_bug.do?bug_id=8175005

해결방안
 https://bugs.openjdk.java.net/browse/JDK-8173783 에 의하면 해당 버그는 6u141 b32(HPE JDK 6.0.35)에서 해결

 

java 관련 명령어

HP-UX java 버전 분별법
IA64N - 32bit
IA64W - 64bit 

jinfo
 개요
 JVM option(java command option)을 확인

  java command option
    -X는 표준이 아닌 설정으로 Macro한 측면에서 JVM제어 기능을 제공 (모든 JVM에서 지원한다는 보장이 없음)
   -XX는 표준이 아닌 설정으로 안정적이지 않은 옵션. (-X Option보다 세밀한 제어 기능을 제공하며, 성능 튜닝/버그 Workaround를 위해서 주로 사용됨)
    -XX:+<옵션>은 해당 옵션을 활성화 -XX:-<옵션>은 해당 옵션을 비활성화
    -XX:<옵션>=<숫자> 시 'm','M'은 메가바이트 'k','K'는 킬로바이트 'g','G'는 기가바이트를 표현

 UNIX/Linux/Windows JAVA 5 이상 제공.
 Heap, PermSize 등 옵션지정 없는 프로세스에 대해 default값 확인 가능.
 HP-UX에서는 -flag 필수, Linux에서는 -flag없이 pid만 포함하면 해당 프로세스 JVM 전체 정보 출력.

 ex) jinfo -flag [JVMflag] [pid]
     5555라는 pid의 PermSize를 출력하라
   

$ jinfo -flag PermSize 5555
-XX:PermSize=134217728

jstat
 개요
 JVM 측정을 위한 성능 통계를 표시한다.

 항목 설명
  Timestamp : JVM의 시작 시간 이후의 시간
  S0 : Survivor0의 사용률
  S1 : Survivor0의 사용률
  E : Eden 영역의 사용률
  O : Old 영역의 사용률
  P : Permanent 영역의 사용률
  YGC : Young generation의 GC 이벤트 수
  YGCT : Young generation의 가비지 컬렉션 시간
  FGC : Full GC 이벤트 수
  FGCT : Full의 가비지 컬렉션 시간
  GCT : 가비지 콜렉션 시간

  Options
 -class : 클래스로드의 동작에 대한 통계
 -compiler : 핫스팟 컴파일러의 동작의 통계를 표시
  -gc : 가비지 콜렉트된 힙 영역에 대한 통계
 -gccapacity : Generation과 해당 공간의 용량 통계
 -gcutil : 가비지 콜렉션 통계 요약

  OutputOptions
 -h [n] : 칼럼 머리글마다 n개의 출력 행 표시 
 -t : 출력되는 첫번째 칼럼에 타임스탬프 표시 (타임스탬프는 JVM의 시작 시간 이후의 시간이다.)

 ex) jstat -options -outputoptions [pid] [interval] [count]
     22820의 pid에 10초(10000ms)간격으로 100개의 샘플을 취득해 -gcutil 옵션에 따라 출력하라(단 5개 출력 마다 머리글 표시 첫 번째 칼럼엔 타임스탬프를 표시)

$ jstat -gcutil -h 5 -t 22820 10000 100
Timestamp         S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
      1239777.3  32.23   0.00  98.88   1.54  13.76    430  100.417     0    0.000  100.417
      1239787.3  32.23   0.00  99.24   1.54  13.76    430  100.417     0    0.000  100.417
      1239797.3   0.00  36.26  19.20   1.54  13.76    431  100.490     0    0.000  100.490
      1239807.4   0.00  36.26  38.71   1.54  13.76    431  100.490     0    0.000  100.490
      1239817.4  29.82   0.00  15.43   1.54  13.76    432  100.722     0    0.000  100.722
Timestamp         S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
      1239827.4  29.82   0.00  34.67   1.54  13.76    432  100.722     0    0.000  100.722
      1239837.4  29.82   0.00  35.03   1.54  13.76    432  100.722     0    0.000  100.722

 2행과 3행을 보면 Minor gc가 발생하여 Eden 영역이 감소하고 YGC와 YGCT가 증가함을 볼 수 있다.

jstack
 개요
 java Thread dump 생성해주는 명령어로 java stack 확인할 때 사용.
 ※Unix/Linux 는 Java 5 부터 Windows 는 Java 6 부터 지원
   Unix/Linux 에서는 kill -3 명령어로도 Thread dump 생성 가능

 ex) jstack -l [JVM pid]
     4740이라는 pid에 대한 Thread dump를 td_4740.txt 라는 파일로 생성하라

$ jstack -l 4740 > td_4740.txt

jmap
 개요
 java Heap dump 생성해주는 명령어로 java Heap을 확인할 때 사용.

 Options
 -histo : 클래스별 객체 수와 메모리 사용량 확인
 -dump : heap dump 생성

 ex) jmap [-Options] [JVM pid]
     4740이라는 pid에 대한 Heap dump를 hd_4740.bin 라는 파일로 생성하라

$ jmap -dump:format=b,file=hd_4740.bin 4740

     24760이라는 pid에 대한 클래스별 객체 수와 메모리 사용량을 확인하라

$ jmap -histo:live 24760 | more
 num     #instances         #bytes  class name
----------------------------------------------
   1:        327969       19974168  [C
   2:        112277       15139136  <constMethodKlass>
   3:        112277        9886040  <methodKlass>
   4:        330181        7924344  java.lang.String
   5:        176627        7783016  <symbolKlass>
   6:         10189        6167032  <constantPoolKlass>
   7:         97618        4685664  com.sun.tools.javac.zip.ZipFileIndexEntry
   8:         10189        4531304  <instanceKlassKlass>
   9:         46349        3980768  [Ljava.util.HashMap$Entry;
  10:          8970        3606368  <constantPoolCacheKlass>