PowerPoint 프레젠테이션

Size: px

Start display at page:

Download "PowerPoint 프레젠테이션"

미영 성
5 years ago
Views:

1 Real Time JVM & JBoss 다우기술오픈소스기술팀

2 목차 1. Real Time 이란 2. RT 자바애플리케이션문제 3. Real-time Specification for Java(RTSJ) 4. Azul Zing 5. Azul Zing POC 사례

3 Real Time 1. Why Real-Time Java

4 Real-Time Real Time 예측가능하고일정한응답시간을요구하는시스템 Real-Time 이란임의의정보가시스템에입력되었을때주어진시간안에작업이완료되어결과가주어져야하는것을의미 리소스를낭비하더라도작업의제한된시간에맞추는데노력 공평성의개념보다는우선순위가높은 task(real-time task) 가많은시간동안수행됨

5 Hard Real-Time vs Soft Real-Time Real Time Soft Real-Time 어떤시간안에처리하면좋지만그렇지못한경우에그시간에서약간경과한후의값도인정하는경우 Soft Real-Time System Ex) cellular phone, router Hard Real-Time Real-Time System 중에는어떤작업을일정시간안에반드시처리해야하며, 그시간이지난후의결과값은정확해도소용이없는경우 Hard Real-Time System Ex) 군사장비, 비행기, 로켓위성

6 Real-Time 요구사항 Real Time 요구사항 응답시간 Real time(soft-rt,hard-rt) 어플리케이션을작성하는프로그래머들은응답시간제약에대한이해필요 1 마이크로초응답성이필요한기술과 100 밀리초응답이필요한기술은엄연히틀림 수십마이크로초이하의응답시간을맞추기위해 커스텀하드웨어와소프트웨어의조합이필요 OS (RealTime OS) 응답시간요구사항에부합하는애플리케이션을설계해야함 응답시간에대해예측할수없을경우시스템에큰영향을끼침

7 Real Time Java 문제 1. 쓰레드관리 2. 클래스로딩 3. 가비지컬렉션 4. 컴파일

RT 자바애플리케이션의문제 Problem Java 는실시간시스템개발에적합하지않다. 범용 OS, 범용 JVM 상에실행되는표준자바애플리케이션 수백밀리초레벨로소프트 RT 요구사항을맞출뿐이다. 자바의근본적인측면의문제 쓰레드관리 쓰레드스케줄링이나쓰레드우선순위를보장하지않는다.

8 RT 자바애플리케이션의문제 Problem Java 는실시간시스템개발에적합하지않다. 범용 OS, 범용 JVM 상에실행되는표준자바애플리케이션 수백밀리초레벨로소프트 RT 요구사항을맞출뿐이다. 자바의근본적인측면의문제 쓰레드관리 쓰레드스케줄링이나쓰레드우선순위를보장하지않는다. 클래스로딩 미디어 ( 디스크등 ) 의속도 클래스사이즈 클래스로더들의오버헤드 Just-in-time(JIT) 컴파일러액티비티 (*) Memory 할당 (Raw memory 접근을허용안함 ) GC Compile High resolution time(micro second 단위의시간측정 ) 을제공안함 (*) (*) Static compiler 와 Interpreter 의중간단계에있는컴파일러한번 interpreted 된코드들은 caching 해두었다가반복될때마다다시쓰는방식 (*) 기존의타이머모델보다더세밀한단위로시간을제어하기위한기법이다

9 쓰레드관리 쓰레드관리 표준자바는쓰레드스케줄링이나쓰레드우선순위를보장하지않는다. Real Time 어플리케이션의경우 낮은우선순위의쓰레드가높은우선순위의쓰레드에앞서스케줄링되지않도록하는방법이없다. 프로그래머는 OS 가다른우선순위로실행할수있도록애플리케이션세트로분활해야한다. 이러한파티셔닝은이벤트의오버헤드를높이고이벤트들간통신을더욱어렵게만든다.

10 클래스로딩 클래스로딩 범용 JVM 프로그램이첫번째로참조될때까지클래스로딩을지연 클래스로딩속도결정요소들 미디어 ( 디스크등 ) 의속도 클래스사이즈 클래스로더들의오버헤드 클래스로딩지연 10 밀리초 수십또는수백개의클래스들이로딩시예측할수없는지연상태발생

Stop-the-world Stop-the-world 는 GC 를실행하기위해 JVM 이애플리케이션실행을멈추는것 힙사이즈, 힙데이터양,

11 가비지컬렉션 가비지컬렉션 GC 의장점 메모리누수방지 커스텀메모리관리툴작성의필요성제거 Hard RT 자바프로그래머들의또다른좌절 GC 동작시오랜지연시간 보통수백밀리초지연 어플리케이션레벨에서해결하는방법 재사용되는객체생성하여자바힙메모리가소진되지않도록함으로써 GC 를방지 Stop-the-world Stop-the-world 는 GC 를실행하기위해 JVM 이애플리케이션실행을멈추는것 힙사이즈, 힙데이터양, 컬렉터가여유메모리를요구하는정도에따라다르다. 현대적 GC 들은 Concurrent Algorithm 과 Incremental Algorithm 을사용하여중지시간을줄임 여전히 GC 는무작위로발생

12 컴파일 컴파일 인터프리팅된코드와 < 컴파일코드로실행하는것의속도차이

13 Real-time Specification for Java RTSJ RTSJ 는 RT 실행환경에서자바언어의한계를해결하기위해만들어졌다. IBM, Sun and other partners formed Real-time for Java Expert Group sponsored by NIST in RTSJ 의 7 가지향상된영역 스케줄링 예측이가능하도록스케줄링되는것을보증 메모리관리 Immortal 메모리영역 Scope 메모리영역 스레딩 실시간스레드 No heap 실시간스레드 동기화 우선순위가높은스레드가낮은우선순위의스레드를기다려선안된다 시간과클럭 HighResoulutionTime 과 clock 비동기식이벤트핸들링 (*)NIST : 미국가표준기술연구소

14 Azul Zing 1. Azul systems

15 Azul systems 1. Azul systems 2. Azul product 3. Azul Zing

16 About Azul Systems Azul Systems Azul 시스템은자바어플리케이션성능에충실한제품을공급 Azul 은 2002 년설립된벤처기업 캘리포니아서니베일에본사 전세계에파트너와리셀러존재 2010 년순수소프트웨어기반의 Java runtime Zing 출시 Azul systems 는 Real-time 비즈니스환경에서자바를사용 Transform Java = Zing Azul Zing 의설계적측면 large working memory high transaction rates Low latency consistent response times high sustained throughput

17 About Azul Systems product Azul 제품 Zing JVM for real-time enterprise Zing PE With Websphere Zing Platform Edition 은 Websphere 와최적화된 Zing 이결합된제품 Zulu : Java for Windows Azure 오픈 JDK 기반의오픈소스 JVM Azure cloud 의 Windows Server 용 JVM jhiccup Open Source Java Performance Tool

18 Azul Zing 1. Zing 특징 2. Elastic memory 3. Zing requirement 4. Zing performance

19 Zing Zing 특징 Linux/x86 서버들을위한 JVM 엔터프라이즈어플리케이션에대한우려로 Garbage Collection 을최소화 응답시간이슈에대한구분 Transaction Rate Data set size Concurrent users Heap size Allocation rate 탄력적인운영을위해 Elastic memory 사용

20 Zing Zing 특징 일정한응답시간을보장하는유일한 JVM Low-latency, Realtime 업무에적합 Java Heap 메모리 300G 이상사용가능 빅데이터처리에적합 1core ~ 수십 core 사용가능 Stop The World 가없는현존하는최고의 C4(Continuously Concurrent Compacting Collector) GC 알고리즘 최소의튜닝으로최대의효과

21 Azul C4 Garbage Collector GC 비교 JVM Collector Name Young Generation Old Generation Oracle'sHotSpot Oracle'sHotSpot Oracle'sHotSpot Oracle'sJRockit* IBM J9* IBM J9* zul Zing ParallelGC CMS (Concurrent Mark/Sweep) G1 (Garbage First) Dynamic Garbage Collector Balanced optthruput C4 (Continuously Concurrent Co mpacting Collector) Monolithic, stop the world, copying Monolithic, stop the world, copying Monolithic, stop the world, copying Monolithic, stop-the-world, Mark/Sweep/Compact Mostly concurrent marker, concurrent, non-compacti ng sweeper, fall back to m onolithic stop-the-world c ompaction Mostly concurrent marker, mostly incremental compa ction, fall back to monolithi c stop-the-world Mark/Sweep - can choose mostly concurrent or paral Monolithic, stop-the-world, lel, incremental compactio copying n, fall back to monolithic st op-the-world Monolithic, stop-the-world, copying Monolithic, stop-the-world, copying Concurrent, compacting Mostly concurrent marker, mostly incremental compa ction, fall back to monolithi c stop-the-world Parallel Mark/Sweep, stop -the-world compaction Concurrent, compacting

22 Zing Elastic memory Elastic memory

23 Zing Zing configuration System Requirement Hardware Processors Intel : Xeon server AMD : Opteron server Memory and Cores Minimum 16-32GB 이상 (64GB) 4Core 이상 (6Core) Zing 지원플랫폼 X86:64bit (RHEL 5.2 이상이나 6.0 이상,CentOS, Ubuntu LTS and LTS, Amazon Linux AMI on 3.4.x kernel) Zing 배치아키텍쳐 Hardware, Virtualized (VMWare/Xen/KVM), and Cloud (Amazon EC2) 지원 JDK 버전 JavaSE 6 이상

24 Zing Zing performance Web-based apps(msec) Consistent Performance 튜닝없이 10msec 이하의최대지연시간제공 GC 일시정지불필요 많은부하시에도일관적인응답시간제공 특별한코딩이필요없거나기존어플리케이션코드의변화가없음 개발시간확보

25 Azul Zing 아키텍쳐 1. ZVM

26 Zing ZVM 기본구성은 ZVM 인스턴스가사용하는컴퓨터의물리적메모리의 75 % 를설정한다. Mem Total = Linux Mem + Zing Mem Zing Mem = Reserved + Contingency + Pause Prevention

27 Zing ZVM Zing Mem 전체 Mem 에서 ZVM 용으로사용할메모리를할당받는다. Reserved java Heap java heap 메모리를사용하는인스턴스가생성될때할당하는메모리의크기 (-Xmx) Contingency zing 이일시적으로 java 응용프로그램을실행시키는데있어서 ZVM 인스턴스에추가메모리를할당시켜줄수있다. OOM 을방지하고 Xmx 보다큰값을사용할수있도록한다 Pause Prevention zing 에서사용하는메모리 /percentage Zing's Generational Pauseless Garbage Collection(GPGC)

28 Azul Zing Performance 1. Performance 2. OracleVM performance 3. OracleVM Vs. Zing

Zing+JBoss EAP: Better application platform for your Business!

29 Zing 비교 >17x 이상동시유저접속 >6x 이상빠른응답시간 Greater throughput Higher availability Single JBoss EAP Instance Response Time (lower is better) 45 Users 6.8x better! Zing+JBoss EAP: Better application platform for your Business! 800 Users Azul Zing Oracle HotSpot LifeRay portal on 99.9% SLA of 5 second response times

30 Zing performance Native JVM: Peaks at 45 concurrent users LifeRay portal on 99.9% SLA of 5 second response times

31 Zing performance Instance capacity test: Fat Portal C4: still 800 concurrent users

32 Zing Zing5, 1GB in a 8GB heap Oralce HotSpot CMS, 1GB in a 8GB heap

33 Azul Zing + JBoss Data Grid Zing and JBoss Data Grid enable businesses to maximize the value of their in-memory grids by: 1. Increase throughput and reduce latency 1. Perfect for real-time apps and Big Data: Zing supports l arger in-memory nodes (up to 340 GB) and still meets st rict latency SLAs 2. Improve response time consistency and availability 1. Ideal for latency-sensitive or user-interactive apps: Zin g eliminates response time outliers, lowers max respons e time to 10s of milliseconds and reduces grid timeouts 3. Simplify deployment configurations (this is not con solidation) 1. By supporting very large nodes, Zing reduces the numb er of nodes needed in the cluster which simplifies deplo yment and management 4. Faster time to market 1. Ideal for apps with high change velocity or frequent new feature launches: Zing allows for less app tuning and in creases developer productivity

34 Azul Zing + JBoss Data Grid In-Memory Computing Made Simple Azul Zing Eliminates Response Time Outliers: 10 msec vs 1,500 msec

Outliers on Any Size Heaps HotSpot shows

zes, with max response times exceeding 5

Zing NEVER exceed 23 millise conds, even at 200

35 Azul Zing + JBoss Data Grid In-Memory Computing Made Simple Azul Zing Eliminates Response Time Outliers on Any Size Heaps HotSpot shows response time inconsistencies on all heaps si zes, with max response times exceeding 5 seconds. Zing NEVER exceed 23 millise conds, even at 200 GBs 250X Improvement 35

36 Azul tuning 1. GC tuning

일반적인 VM 튜닝 GC Tuning 실질적인커맨드라인 GC 튜닝파라미터샘플들 Java -Xmx12g -XX:MaxPermSize=64M -XX:PermSize=32M -XX:MaxNewSize=2g -XX:NewSize=1g -XX:SurvivorRatio=128 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC

37 일반적인 VM 튜닝 GC Tuning 실질적인커맨드라인 GC 튜닝파라미터샘플들 Java -Xmx12g -XX:MaxPermSize=64M -XX:PermSize=32M -XX:MaxNewSize=2g -XX:NewSize=1g -XX:SurvivorRatio=128 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=0 -XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSParallelRemarkEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:ParallelGCThreads=12 -XX:LargePageSizeInBytes=256m Java Xms8g Xmx8g Xmn2g -XX:PermSize=64M -XX:MaxPermSize=256M -XX:-OmitStackTraceInFastThrow -XX:SurvivorRatio=2 -XX:- UseAdaptiveSizePolicy -XX:+UseConcMarkSweepGC -XX:+CMSConcurrentMTEnabled -XX:+CMSParallelRemarkEnabled -XX:+CMSParallelSurvivorRemarkEnabled -XX:CMSMaxAbortablePrecleanTime= XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=63 -XX:+UseParNewGC Xnoclassgc

38 Zing GC 튜닝 Zing GC Tuning The complete guide to Zing GC tuning java -Xmx40g

39 POC 사례 1. Azul Zing + JBoss DataGrid

40 Zing Test POC Low Latency : 모든요청이 50ms 이내에처리되어야한다! 시스템안정성이매우중요하다. JBoss Data Grid JBoss EAP6.2 Replication mode JBoss Data Grid JBoss EAP6.2 JBoss Data Grid Server#1 JBoss Data Grid Server#2 JBoss Data Grid Server#3 JBoss Data Grid Server#4 Dist mode clustering

41 Oracle Hospot VM GC 개요 Hotspot

42 Oracle Hospot VM GC 시간분석 Hotspot

43 Azul Zing JVM GC Pause Duration Zing

44 Azul Zing JVM Application Delays Zing

45 GC 시간비교 Oracle JVM1.6 VS Azul zing JVM1.6 Oracle JVM 1.6 Azul Zing JVM 1.6

46 Resources 참고

47 THANK YOU 기술을가치있게제공하는기술서비스본부

untitled

untitled Memory leak Resource 力金 3-tier 見 Out of Memory( 不 ) Memory leak( 漏 ) 狀 Application Server Crash 理 Server 狀 Crash 類 JVM 說例行說說 Memory leak Resource Out of Memory Memory leak Out of Memory 不論 Java heap