How to Java Max Heap Memory in SAP NetWeaver(PO,PI)

SAP PO/PI에서 송,수신 간 인터페이스 중 대용량이나 잘못된 로직으로 인하여 특정 노드에서 GC를 해도 더이상 할당가능한 메모리가 부족해 OOM(OutOfMemory)이 발생되는 경우가 있습니다. 그외 ESR(Enterprise Services Repository)에서도 메시지 매핑 오브젝틑 저장이나 편집하려고 할때 Java 힙공간이나 기타 내부문제로 OOM에러가 발생되는 경우가 있는데 자세한 내용은 아래 노츠를 참고하면 좋을것 같습니다.

1580914-Java heap space OutOfMemoryError in the PI Repository

그리고 PO개발자나 컨설턴트가 자주사용하는 개발도구(ESR, IB)를 사용하다보면 툴이 느려질때가 있고 그런경우 Heap메머리를 늘려주는 두가지 방법이 있는것 같은데 Max Heap Size를 늘리면 메모리의 New영역과 Perm영역에 대한 크기도 증가하여 Full GC의 수행시간이 증가, Stop-the-world현상이 발생될수 있어 자바튜닝이 필요할수 있다고 합니다.

stop-the-world란, GC을 실행하기 위해 JVM이 애플리케이션 실행을 멈추는 것이다. stop-the-world가 발생하면 GC를 실행하는 스레드를 제외한 나머지 스레드는 모두 작업을 멈춘다.

1. PO > NWA(SAP NetWeaver Administrator)설정

Configuration > Infrastructure > Java System Properties > Services > XPI Service: All Config Service.
Add property com.sap.aii.ib.client.jnlp.j2se.maxheapsize

2. .jnlp(Java Network Lunch Protocol)파일 수정

<resources>
<j2se java-vm-args="-Xms32m -Xmx512m -XX:MaxPermSize=128" Version=

이런 로컬이나 서버설정을 통해 개발도구의 힙크기를 증가시켜 사용부분에 대해 개선이 될수 있을것 같습니다.
[SAP PO]-INCREASE HEAP SIZE FOR ESR AND IB JAVA TOOLS

Memory

지금부터 Java Max Heap Memory에 대해 정리한 내용은 인터페이스 수행을 위한 Netweaver의 메모리에 대한 관련내용을 찾아본내용이며 자바기반의 플랫폼이나 OS사양에 따라 메모리 설정부분에 대해 차이는 있을것 같으며 관련 노츠를 찾아보는게 좋을것 같습니다.
메모리의 튜닝, 메모리 부족현상으로 인한 OOM발생, 스왑공간부족 등 이런현상을 대비하기 위해 초기 서버셋팅시 Java서버노드의 최대 힙 크기(최대허용크기)는 물리적 메모리, 기타 프로세스나 OS 등 맞춰 진행되어야 한다고 하며 그렇지 않은 경우 성능저하, 운영체제 등 안좋은 현상이 발생될수 있다고 합니다. 이런 JVM(자바가상머신)의 메모리 영역의 힙크기들은 Wily Introscope같은 도구들로 모니터링이 가능한걸로 알고 있습니다.

Java stack-based SAP 어플리케이션의 서버노드의 최대 할당 메모리는 움영체제에 따라 차이가 있다고 하는데요. 32비트는 1GB 64비트는 2GB를 권장하며 최대 3.5기가까지 늘릴수 있다고 합니다. 현재도 같은 권장기준인지는 모르겠지만 일반적으로 힙 크기를 더 늘리는 것보다 서버노드를 추가하는게 좋다고 하네요. 메모리 영역중 Young은 새로 생성된 객체를 보관, Old는 사용중인 객체를 유지하는데 사용된다고 합니다.

SAP의 서버노드는 Java기반의 노드는 다중스레드이고 멀티테스킹이 가능하다고 하며 ABAP기반의 작업프로세스는 단일스레드라 한번에 하나의 작업만 할수 있다고 합니다. 서버의 물리적 메모리, CPU, 리소스 등의 가용도에 따라 서버노드 수와 스레드 수 추가는 시스템 성능을 향상시키기 위에 중요한 것들일수 있을것 같습니다.

GC(Garbage Collection)

위에 언급했던 '노드에서 GC르 ㄹ해도 더이상 할당가능한 메모리가 부족' 내용처럼 GC(Garbage Collection)의 역할은 Java시스템에서 중요하며 Java는 객체에 대한 메모리가 자동으로 할당되 개발자가 수작업으로 메모리 할당, 해제할 필요가 없으며 오류로 인한 메모리 누수도 최소화 된다고 합니다. 시스템의 프로그램이 수행될때 GC의 종류를 보면 Minor Garbage Collection, Full Garbage Collection 등이 있으며 전부이해한건 아니지만 Minor GC같은 경우 에덴? 메모리 영역에서 해당 GC가 발생된다고 하며 빠르게 발생되어 성능 지연에 영향이 없어 사용자 관점에서는 눈치채지 못할정도의 경미한 것이라고 합니다.
반대로 Full GC는 시스템 성능에 상당한 시간과 성능에 영향을 미칠수 있다고 하며 Full GC가 완료된 후 메모리가 해제될때까지는 처리가 지속되는것 같고 결국에 사용가능한 메모리가 충분하지 않아 메모리 부족현상이 발생되고 오류가 발생하여 프로그램이 중단, 응답하지 않는 현상을 보게 된다고 합니다.

SAP에서는 Java스텍의 성능문제를 해결하기위한 여러도구를 제공한다고 하는데요. 그중 대표적인게 Wily Introscope가 있고 SAP Profiling 등을 통하여 힙, GC, 스레드 등 메모리 분석을 통한 장애발생 전에 성능문제를 해결하는데 유용할것 같고 만약 OOM이나 덤프가 발생된 경우 SAP PO에서는 Heap Dump, Thread Dump파일을 다운로드 받아 문제를 해결하기 위한 부분을 확인가능하다고 합니다. 하지만 파일내용을 열어봐도 어떤 인터페이스, 프로세스 등으로 인해 시스템 오류가 떨어졌는지 잘 모르겠더군요.

출처: 

SAP Performance Tuning in the Java Stack