와스킹의 사건현장

https://waspro.tistory.com/198

■ 현상
파일 인코딩 값이 파일과 맞지 않을때

■ 원인
파일 업로드 시 계정에 따라 인코딩 값이 결정되어 파일의 인코딩값이 맞지 않아 변경이 필요

■ 조치사항
1) vi로 파일을 열고 나서
:set fileencoding=[인코딩값](utf8)
:w

2) 명령어로 바꾸기
iconv -f euc-kr -t utf-8 euc-kr.html --output utf8.html

■현상
http응답코드 405는 메소드매칭이 되지 않아 발생하는 에러이다.

■원인
사용자는 페이지에 대한 http요청을 get으로 하였는데
페이지에선 post방식으로 처리하게 되었을때 발생하게 된다.

■조치방법
처리방식과 요청을 맞추어주면 됨

■ 개요
http 헤더 내에 OS, 웹서버 정보를 담고 있는 값

■ 현상
# curl -I http://localhost
명령 시 헤더 정보에 OS와 웹서버 정보 출력

■ 조치사항
Node 절에 다음과 같이 설정
ServerTokens="OFF"  (default 값 off)

Specific Scope Cluster
특정 어플리케이션 들로 그룹을 설정하고 세션을 공유 및 유지하고자 할 때 설정

■ 조건
- 그룹 내 어플리케이션들은 context-path가 같아야 함
- 그룹 이름은 고유해야 한다
- jeus-web-dd.xml 파일에 그룹이름을 명시해야함

■ 적용 방법
WEBADMIN - Session - Specific Scope Cluster 추가

[리소스 홈]/WEB-INF/jeus-web-dd.xml 에 아래의 내용 추가
<jeus-web-dd> <target-session-cluster> 에 Specific Scope Cluster 이름 추가

웹 서비스를 구성하다보면 하나의 컨테이너에서 서로 다른 웹 어플리케이션의 구성을 요할때가 있다.
기본적으로 컨테이너는 context-path를 통해 context를 인지하지만, URL을 분기함으로써 context-path를 동일하게 설정해야 하는 경우도 생기게 된다.

다음과 같이 설정

■ JEUS6
${JEUS_CONFIG}/'HOSTNAME'_servlet_[컨테이너명]/WEBMain.xml

<web-container><context-group>로 분기

${JEUS_CONFIG}/JEUSMain.xml

<jeus-system><application><client-component><deployment-target><web-context-group><name> 에 WEBMain.xml 에서 정의한 context-group의 group-name값 부여

■ JEUS8
WEBADMIN - Servers - 컨테이너 선택 - Engine - Web Engine - Vitual Host 에 추가할 context-group이 사용하는 URL추가

해당 context-group의 어플리케이션 추가시
Virtual Host에서 URL선택

webtob의 동작을 분석하기 위해 trace를 해야 할때가 있다.

다음의 2가지 방법으로 가능하다.

1. 로그레벨을 trace로 변경
$ wsadmin
> ll .hth -l trace

2. 로그 설정을 변경
$ wsadmin
> ll .hth -o dcR,dcW,dsR,dsW

dcR - client가 보낸 데이터 출력
dcW - client로 전송된 데이터 출력
dsR - server가 보낸 데이터 출력
dsW - server로 전송된 데이터 출력

위와 같이 입력하면 아래의 파일로 trace가 생성
${WEBTOBDIR}\log\HTH-[PID]-[YYMMDD].trace

1번으로 살펴보고 분석에 대한 정보가 부족할시 2번으로 분석

webtob재기동시 설정된 trace는 모두 해제

원복
ll .hth -o -dcR,dcW
ll .hth -o -dsR,dsW
ll .hth -l INFO

■ 현상
JEUS6 ADMIN(ja) 호출 시 응답을 Null로 받음

■ 원인
패스워드의 암호화 키값에 대한 encoding/decoding을 하지 못하여 발생.

■ 조치사항
아래의 2개 파일에 대한 퍼미션 부여 필요
${JEUS_HOME}/bin/encryption (실행권한)
${JEUS_HOME}/config/`hostname`/security/security.key (읽기권한)

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값을 주되, 적정한 값은 설정 후 모니터링을 통해 찾아야 함.

java7 이상 4g 이상의 jvm은 G1 알고리즘이 적합

■ java의Default 옵션 알아내기
java -XX:+PrintCommandLineFlags -version

-Xms1024m -Xmx1024m
최초 Heap Size / 최대 Heap Size
-XX:PermSize=256m -XX:MaxPermSize=256m
최초 Prem영역 Size / 최대 Prem 영역 Size
-XX:-UseAdaptiveSizePolicy
JVM에서 Heap Size 조절
-verbosegc -XX:+PrintGCDetails -XX:+PrintGCTimesStamps
GC로그 상세출력
-XX:InitialTenuringThreshold=32 -XX:MaxTenuringThreshold=32
객체의 Mionr GC 수행 횟수 / 객체의 최대 Mionr GC 수행 횟수
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled
New 영역 병렬GC 수행 / Old 영역 병렬 GC 수행 / 클래스Data도 GC 수행 
-XX:+DisableExplicitGC
사용자 임의의 GC 수행 비활성화
-XX:SurvivorRatio=8
New영역의 Eden size 비율
Eden 8 : Survivor 1 : Survivor 1
-XX:NewSize=32m -XX:MaxNewSize=512m
최소 최대 New사이즈
-XX:NewRatio=3
Heap영역에서 Old와 New size 비율
Old 3 : New 1
※절대값 설정과 상대값 설정을 혼용한다면 절대값이 우선순위가 높음
-XX:ParallelGCThreads=8
다중 gc를 위해 사용될 gc thread 개수
※활용가능한 프로세서의 수를 기반으로 할 것.
같은 머신에서 여러개의 jvm을 가동할때도 개수 고려할 것
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC
new영역의 gc를 병렬적 사용 및 CMS gc 사용
-XX:+CMSClassUnloadingEnabled
클래스의 데이터도 gc의 대상이 되게 지정