본문 바로가기 메뉴 바로가기

어제보다 나은 오늘

프로필사진
  • 글쓰기
  • 관리
  • 태그
  • 방명록
  • RSS

어제보다 나은 오늘

검색하기 폼
  • 전체보기 (203)
    • 어제보다 나은 오늘을 위하여 (19)
    • IT Trends (119)
    • 보고 듣고 느끼고 생각하며.. (4)
    • 새로운 생각들 (18)
    • 기술이야기 (42)
  • 방명록

기술이야기 (42)
[JVM Internal]Java Performance Fundamental 교재를 공유합니다.

엑셈에서 유료로 진행되는 Java Performance Fundamental 교재를 공유하기로 하였습니다. 세미나에 참석하셨던 분들의 요청이 가장 큰 동기였습니다. 그러나 책을 출간하고 나서 책의 내용을 요약하여 포스팅하는 작업이 계속 밀리더라구요. 요즘 관심사가 좀 다른데 있어서 말입니다. 그래서 PDF로 공유하는 것보다 PT도 가능한 형태로 공유하기 위해 이러한 방식을 사용하였습니다. 이 교재 내용은 제가 쓴 Java Performance Fundamental이라는 책을 바탕으로 한 것이기 때문에 자세한 설명을 원하시면 책을 참고하시는 방법도 있습니다. 책을 쓴 목적도 자바, WAS성능의 근간을 이루는 JVM의 내부 구조를 파악하기 위한 것이었고 이 지식은 Java개발자, 운영자 분들이 모두 습득하시..

기술이야기 2010. 1. 27. 10:21
Hotspot JVM의 Garbage Collector

Hotspot JVM, 다시말해 Sun사에서 만들어 HP, Solaris, Windows, Linux, Mac 등에서 사용하는 JVM은 Garbage Collector를 추가하는 방식으로 Garbage Collection이 개선되어 왔다. 다시말해 버전이 올라가면서 기존의 Garbage Collector 보다 더 나은 알고리즘을 가진 Garbage Collector를 추가하여 제공하는 방식으로 진화해왔다는 것이다. 그러므로 Hotspot JVM에서는 Garbage Collector를 이해하는 것이 바로 Garbage Collection자체를 이해하는 것을 의미하게 된다. 다음의 그림은 Java 6까지 Hotspot JVM에서 제공하는 Garbage Collector를 정리한 것이다. Hotspot JVM..

기술이야기 2009. 12. 15. 16:48
Hotspot JVM Garbage Collection의 기본 가정

Hotspot JVM 그러니까 Sun, HP, Windows, Linux, Mac 등에서 사용되는 JVM은 Generational Heap 구조를 가지고 있다. Generational Heap이란 Java Object의 활용도에 따라 Object가 위치하는 영역을 구분해 놓은 것으로 말할 수 있다. Hotspot JVM의 Heap Generation의 구조는 아래의 그림과 같은데 Sun사에서 Heap을 이렇게 디자인한 것은 경험적으로 알게된 어떠한 사실들 때문이다. 그 경험적 지식을 Weak Generation Hypothesis라고 한다. 이 가설은 두가지 사실로 구성이 되어 있다. 첫 번째는 바로 High Infant Mortality. 우리말로 하면 높은 유아 사망률 정도가 된다. 이것은 Java ..

기술이야기 2009. 12. 14. 18:19
Hotspot JVM의 Garbage Collection의 기본 가설과 특징

Sun, HP, Windows, Linux에서 사용되는 Hotspot JVM은 Young Generation과 Old Generation으로 나뉘는 Generational Heap을 가진다고 하였다. 이 Hotspot JVM의 Garbage Collection에는 하나의 가설이 뒤를 든든히 받치고 있다. 그것은 바로 Weak Generational Hypothsis이다. 내용은 두 가지로 구성되어 있다. 첫째. High Infant Mortality, 우리말로 하면 높은 유아 사망률 정도로 해석할 수 있는데 이것은 대부분의 Object는 생성된 후 얼마 되지 않아 Garbage 가 된다는 것이다. 둘째, Few References from Older to Younger Objects Exists, 살아남..

기술이야기 2009. 11. 12. 12:22
IBM JVM Heap Object Layout

IBM JVM은 1.4 버전까지는 Object와 Array의 구분 없이 세개의 Header를 가진다. 역시 각 header는 1 Word (32bit 머신 32 bits)의 크기를 가진다. 첫번째 header는 Object Size와 Flag정보를 보유하고 있다. Flag는 GC를 위한 정보와 Pinned 또는 Dosed Object 여부를 체크한다. 두번째 header는 Object의 경우 Method Table을 위한 Pointer를 가지고 있게 되고 Array의 경우는 Array 엔트리 개수 정보를 가지고 있게 된다. 세번째 header는 lock 정보를 저장한다. Fat Lock mode라면 Monitor Index를 위해 23 bit가 할당되고 Thin Lock의 경우 15 bits의 Threa..

기술이야기 2009. 11. 3. 15:24
Hotspot JVM Heap Object Layout

Hotspot JVM이란 Hotspot Compiler를 사용하는 Sun, HP, Oracle에서 배포하는 JVM을 말한다. 이 Hotspot JVM의 Heap Object Layout은 왼편의 그림과 같다. Heap에는 Object와 Array만이 존재하는데 Hotspot JVM의 경우 Object는 Header가 2개, Array에는 Header가 3개 존재한다. Array도 사실은 Object의 Layout에 Array Size를 알려주는 Header만 하나 더 추가된 셈이다. 각 Header는 1Word의 크기를 가지며 1 Word란 32 bit머신에서는 32bit의 크기를 가지게 되고 63 bit머신에서는 64 bit의 크기를 가진다. 첫번째 Word인 Mark Word는 Garbage Coll..

기술이야기 2009. 11. 3. 14:31
Runtime Data Areas - IBM JVM Heap의 구조

IBM JVM의 Heap은 Java5에 와서 그 구조가 달라지기 시작하였다. Java 1.4.2 버전까지는 One-Heap 구조로 고수하다가 Java 5에서는 Hotspot JVM 처럼 Generational Heap 구조를 사용할 수 있게 되었다. One Heap구조는 아래의 그림과 같이 구성되어 있다. Heapbase라고 하는 Heap의 처음 주소에서부터 Heaptop 까지 확장이 가능하며 가변크기일 경우 현재까지 할당된 부분을 Heaplimit라고 한다. Kcluster는 Pinned Class Object가 할당되는 곳으로 Default 1280개의 class entries가 저장이 가능하다. 1개의 Class Entry는 300byte(32it), 560byte(64bit)를 의미한다. Pclu..

기술이야기 2009. 11. 3. 10:35
Runtime Data Areas - Hotspot JVM Heap의 구조

Hotspot JVM은 Generational Heap으로 되어 있다. Heap은 Young Generation과 Old Generation으로 되어 있으며 Young Generation은 Eden 영역과 Survivor 영역으로 구성되어 있다. Eden 영역은 Object가 처음으로 할당되는 장소이며 Eden이 꽉 차게 되면 Live Object만 골라 Survivor 영역으로 복사하게 된다. 이를 Minor Garbage Collection이라 한다. 반면 Old Generation에는 Object가 Allocation 되는 것이 아니라 Promotion된다. 즉 새로 Heap에 생성되는 Object가 들어오는 것이 아니라 비교적 오랜 시간동안 참조 되고 이용되어 앞으로도 계속 Heap에 머무를 확률..

기술이야기 2009. 10. 29. 11:23
Root Set과 Memory Leak

Memory Leak을 다루는 방법을 강구하기 전에 Root Set에 대해 좀 더 알아볼 필요가 있습니다. 이 그림은 구동 중인 JVM의 메모리 구조입니다. 간략하게 설명하자면 JVM은 실행 데이터 영역과 그 밖의 JVM의 엔진 역할을 하는 모듈 등으로 구성됩니다. 실행 데이터 영역은 다시 Stack과 같이 Thread에게 속해 있는 메모리 영역과 Thread가 공유하는 Heap, Method Area 같은 것이 있습니다. Java에서 Object를 생성하는 메소드를 수행하면 해당 Thread의 Stack에 이 메소드에 해당하는 Stack Frame이 생성되죠. 그리고 이 reference를 따라가 Heap에 Object가 생성됩니다. 그래서 Stack이 Root Set이 됩니다. 또 Object를 생성..

기술이야기 2009. 10. 28. 17:46
Memory Leak 개요

Java는 Garbage Collection이라는 자동 메모리 관리 기능을 가지고 있습니다. 이것은 메모리 관리의 부담을 덜어 생산성을 향상하려는 좋은 기능입니다. 하지만 모든 자동 기능이 그러하듯 이것도 완벽하게 동작하지는 않습니다. 그래서 Java에서는 메모리 문제가 더 부각되는 경향이 있습니다. 우선 Memory Leak이란 무엇일까요? Memory Leak을 말 그대로 풀자면 메모리 누수, 즉 메모리가 샌다는 것을 의미합니다. 일상생활에서도 샌다는 표현을 사용하죠. 써야 할 곳에 쓰지 않고 이상한데다 돈을 쓰면 어디선가 돈이 줄줄 샌다던가 하는 식으로요. 메모리도 마찬가지입니다. 불필요하게 메모리가 사용되면 메모리가 샌다고 표현하는 것이죠. 이 버섯똘이 같은 그림을 보시죠. 이 검은 점들이 바로 ..

기술이야기 2009. 10. 28. 17:38
Runtime Data Areas - Heap과 Object Layout

Java Heap은 Instance또는 Java Object나 Array가 저장되는 공간으로 모든 Thread들에 의해 공유된다. 그렇기 때문에 동기화 문제도 발생할 수도 있는 공간이기도 하다. Heap도 JVM이 기동할 때 같이 생성된다. JVM는 Heap에 메모리를 할당하는 instruction만 존재한다. Bytecode로는 new, newarray, anewarray, multianewarray만이 존재한다. 그리고 메모리 해제를 위한 명시적인 java code나 bytecode도 존재하지 않는다. 메모리의 해제는 오로지 Garbage Collection를 통해 수행된다. Java Heap의 구현은 역시 Vendor의 재량이기 때문에 각 JVM Vendor마다 Heap의 구조 및 Garbage C..

기술이야기 2009. 10. 28. 17:33
Runtime Data Areas - Native Method Stacks

Java Method를 Call할 때 Thread의 Java Stack에 새로운 Stack Frame을 생성하여 Push하는 것처럼 Native Method를 Call하게 되면 Java Stack에서 Native Method Stack영역으로 나와서 직접 Native Method를 수행 이는 Java Stack에서 Dynamic Link를 통해 Native 까지 확장하는 것으로 볼 수 있음. 만약 JNI를 사용하고 있고 이것이 C로 구현이 되어 있다면 Native Stack은 C Stack으로 생성되고 마치 Native Code처럼 Stack Operation을 수행하게됨 Native Method의 수행이 끝나면 Natve Method Stack에서 나와 다시 Java Stack에 새로운 Stack Fr..

기술이야기 2009. 10. 28. 16:09
Runtime Data Areas - Method Table

Method Area는 Reference시 빈번하게 접근되는 곳이므로 원하는 정보를 찾는 속도가 중요한 이슈가 될 수 있다. Class의 Method들에 대한 direct reference를 갖는 자료구조이며 Method 호출을 위한 데이터 구조이다. 이를 사용하게 되면 Method 참조를 빠르게 수행할 수 있게 된다. Type중 interface나 abstract class가 아닌 class에서 존재하며 해당 Class의 Method뿐만이 아니라 superclass에서 상속된 Method의 reference도 포함한다. Method Table은 Class가 Loading 될 때 생성된다. Method Table이 없다면 왼편의 그림처럼 A를 상속받은 B Object에서 상속된 Method A()를 호출..

기술이야기 2009. 10. 28. 14:44
Runtime Data Areas - Method Area

Class Loader에 의해 Load된 모든 Class의 메타 정보를 저장하는 메모리 공간으로 모든 Thread들에 의해 공유된다. Method Area는 JVM 이 시작할 때 생성된다. Method Area의 구현도 역시 JVM 벤더가 알아서 하게 되어 있다. Sun JVM에서는 이 Method Area를 Permanent Area라는 명칭을 가진 특정 메모리 영역으로 구현하고 있고 IBM JVM의 경우 별도의 영역 구분 없이 Heap내에 Class Object의 형태로 저장된다. Class Loader에게 넘겨 받은 Class File에서 Type에 대한 메타 정보를 추출하게 되는데 추출되는 메타 정보는 위의 그림과 같이 7가지 정도이다. Type Information Type의 전체 이름 (Pac..

기술이야기 2009. 10. 28. 13:42
Runtime Data Areas - Java Virtual Machine Stacks

Java virtual Machine Stacks는 Thread의 수행정보를 기록하는 Stack Frame을 저장하고 있는 영역이다. Java virtual Machine Stacks도 Thread 별로 한 개씩 존재하며 Thread와 함께 생성된다. Java Virtual Machine Stacks는 Thread의 배타적인 영역으로 서로 공유되지 않는다. Java Virtual Machine Stacks은 각각 분리된 Stack Frame을 Pop, Push하는 작업을 수행하게 된다. Java Virtual Machine Stacks의 구현은 JVM Vendor가 알아서 하게 된다. Stack Frame은 Method별로 하나씩 생성된다. Method가 수행되면 해당 Thread의 Java Virtua..

기술이야기 2009. 10. 27. 17:39
Runtime Data Areas - PC Register

Program Counter라고도 불리는 PC register는 각 Thread마다 하나씩 존재한다. 이것은 Thread가 생성될 때 같이 생성되며 Native Pointer와 Return Address를 가지고 있다. Thread가 Java Method를 수행할 때 현재 수행되고 있는 Instruction의 주소를 포함하고 있다. 이 Instruction의 주소는 Native Pointer일 수도 있고 Method Bytecode의 시작 offset일 수도 있다. Thread가 Native Method를 수행할 때는 값이 undefined 상태로 할당되지 않게 된다.

기술이야기 2009. 10. 27. 16:05
Runtime Data Areas의 구조

Runtime Data Areas는 JVM이 Java 프로그램을 수행하기 위해 OS로 부터 할당받는 메모리 영역이라고 정의내릴 수 있다. Runtime Data Areas는 각각의 목적에 따라 PC Register, Java Virtual Machine Stacks, Native Method Stacks, Method Area, Heap 이라는 5개의 영역으로 나뉘게 된다. 이중 PC Register, Java Virtual Machine Stacks, Native Method Stacks은 각 Thread별로 생성되고 Method Area와 Heap은 모든 Thread에게 공유된다. Java Virtual Machine Stacks, Native Method Stacks은 1.3버전 이상의 JVM에서 ..

기술이야기 2009. 10. 27. 15:59
JVM Architecture

Java Virtual Machine은 Java를 실행하기 위한 핵심적인 위치를 차지한다. 그러나 Java Virtual Machine의 실체는 사실 없다. JVM은 하나의 스펙 또는 약속된 개념에 지나지 않기 때문이다. JVM이 모든 구현은 이 스펙을 보고 Vendor에서 알아서 한다. 하지만 이 스펙에 어떻게 구현하라는 명시적인 이야기는 담겨져 있지 않다. 대부분 어때야 한다 정도의 정의만이 있을 뿐이다. JVM은 여러개의 모듈로 구성된다. 우리가 Java 프로그램을 실행시키기 위해서는 JVM안으로 Class 파일을 불러 들여야 한다. 이러한 작업을 하는 것이 Class Loader System이다. 이렇게 Loding된 class는 Execution Engine을 통해 해석되어 Runtime Da..

기술이야기 2009. 10. 27. 15:51
Java Performance Fundamental 책이 출간되었습니다.

Oracle 성능을 하다가 Java 성능으로 영역을 확장하면서 힘들었던 것은 무엇을 공부해야 할지를 정하는 것이었다. Java라는 것이 용어부터 너무도 많고 기술도 너무 많았기 때문에 이것 저것 하다보면 남는 것도 없이 분주하기만 할 뿐이었다. WAS 벤더들의 교육을 찾아 다녀도 마찬가지였다. 자신들의 WAS에 특화된 부분에 대해서 얘기를 듣다보면 성능 문제를 일으키는 근본적인 요소들에 대해서는 잘 파악이 되지 않았던 것이다. 그래서 마늘과 쑥을 가지고 동굴로 들어간 곰과 호랑이 처럼 파묻혀 고민을 하던 차에 갑자기 눈앞이 밝아짐을 느꼈다. 자바는 어떤 것이든 JVM위에서 움직이게 되고 WAS라 할지라도 JVM의 입장에서 보면 하나의 어플리케이션에 지나지 않는다는 것과 시스템 입장에서 JVM은 하나의 프..

기술이야기 2009. 10. 26. 17:56
Exem OnAir

Oracle 성능을 하면서도 항상 이 지식들이 어렵다는 것을 고민해 왔다. 가장 어려운 것은 개별 지식 보다도 개념을 잡는 것이라 생각하는데 이를 위해 Exem OnAir라는 동영상을 제작하기로 결정하였다. 첫번째 것은 Oracle 성능 관리의 가장 중요한 요소인 Wait Event의 개념을 잡기 위한 것이다. 여자친구를 만나러 가다가 예기치 못한 일로 약속에 늦는다는 가상 설정으로 Wait Event의 개념을 잡을 수 있도록 하였다. 두번째는 Oracle 11gR2의 새로운 기능인 Pending Statistics에 대한 개념을 소개한 동영상이다. 태국영화 "13 Beloved"를 소스로 사용했다. 영화 내용은 참 심각한데 여기서는 좀 황당하게 설정되었다. 지식을 전달하는 동영상을 제작하면서도 항상 재..

기술이야기 2009. 10. 13. 13:34
Heap Memory는 어떻게 할당될까..?

이전 글에서는 프로세스의 RSS와 VSZ로 모니터링 되는 java 프로세스의 메모리가 어떤 의미인지를 살펴보았다. 이번에는 이 Pmap의 결과에서 Heap메모리가 어디에 할당되는지를 알아보도록 하겠다. 이것이 1052 프로세스의 Pmap의 결과이다. 이 결과는 할당 받은 메모리 block마다 한 row씩 표현이 되어 있다. 각 Memory Block은 네 부분의 정보로 구성이 되어 있다. 첫번째 정보는 메모리가 시작하는 주소이다. 이것은 16자리의 16bit Hexa로 표현되어 있다. 다시 말해 64bit( = 16^16= (2^4)^16))를 표현할 수 있다는 얘기가 되는데 이 머신은 32bit이기 때문에 상위 8자리는 아무 의미가 없고 하위 8자리만 의미가 있다. 두번째는 memory block의 크..

기술이야기 2009. 6. 4. 16:07
Java Process의 가상 메모리와 실제 메모리의 차이

JVM Internal 세미나를 진행하다 보면 자신이 설정한 Heap Size와 OS 프로세스 메모리에 대해 질문은 받는 경우가 많았다. 질문의 내용은 대충 다음과 같다. Heap Size를 -Xms512m, -Xmx1024m로 잡은 경우 Java Process가 실제로 점유한 메모리는 얼마인가? 그리고 Top이나 ps를 통해 모니터링 된 rss, vsz의 크기는 어떤 것을 의미하는가? 이 질문에 답을 하기 위해 32bit의 linux머신에서 수행 중인 WAS Process를 추적해 보기로 하였다. [jeus5@InterMax2 ~]$ ps -eo pid,cmd | grep 1052 1052 /usr/local/java_1.4/bin/java -server -Xmx512m -Xbootclasspath/p..

기술이야기 2009. 6. 3. 17:05
JDBC Connection때 Client 정보를 내맘대로…

가끔 테스트를 할 때나 모니터링을 할 때 JDBC를 통해 접속한 세션의 정보를 필요로 할 때가 있다. 이럴 때면 해당 세션의 SID를 가져 오기 위해 SQL을 수행하거나 아니면 세션 정보를 지정하기 위해 DBMS_APPLICATION_INFO 팩키지를 수행해야 한다. 이러한 작업은 번거롭기도 하고 Session의 정확한 일량을 체크하고자 할 때 껄끄러울 수도 있다. 그러나 JDBC Connection을 맺을 때 이런 정보를 설정해 놓고 시작한다면 이러한 작업 없이도 원하는 정보를 쉽게 찾을 수 있다. 아래와 같이 Connection을 위한 정보를 제공할 때 v$session의 정보도 포함시켜 보자. 테스트 결과 Oracle Server 10.2.0.4, JDBC Version 10.2.0.1.0 의 환경..

기술이야기 2009. 5. 27. 17:26
Connection Cache

1) connection과 session의 의미 - Connection과 Session은 엄밀히 말해 다른 것임 - Connection은 물리적인 Network Path를 의미 - Session은 유저가 인증을 통과하여 접속할 때부터 접속을 끊을 때까지의 Oracle과의 상호작용을 의미 - Session은 물리적인 Connection을 통해 Oracle에 접속됨 - Session과 Connection이 1:1일 경우도 있지만 0:1, N:1의 경우도 가능 2) Connection Pool - Connection Pool은 다수의 client Session들이 공유할 수 있는 물리적인 Connection을 모아놓은 것을 의미 - Connection Pool은 보통 Application단위로 구성되어 App..

기술이야기 2009. 5. 26. 19:07
Oracle JDBC Driver

1) JDBC Driver - JDBC는 관계형 데이터베이스를 접근하기 위한 표준 API를 의미 - 다양한 DBMS 벤더들은 각자의 방식으로 DBMS에 접근하고 사용해야만 했었으나 Java진영에서는 표준 API를 정하여 각 벤더들로 하여금 이를 구현하게 함 - 이것을 JDBC라고 하고 이를 구현한 것이 JDBC Driver로 각 벤더들은 표준 API와 함께 각자 이를 확장한 나름의 API도 제공하고 있음 - 표준 JDBC API는 java.sql과 javax.sql 두 개의 package로 구성되어 있음 - java.sql은 database에 접근하고 정보를 열람 및 저장 할 수 있는 핵심 JDBC API를 제공 - javax.sql은 JDBC client가 server-side의 data source를..

기술이야기 2009. 5. 26. 19:06
Statement Cache

Statement Cache - JDBC3.0에 소개된 기능으로 루프내에서 반복적으로 수행되는 Statement에 대한 Oracle Cursor를 캐시하는 기능임 - 이는 Statement가 close될 때 JDBC드라이버가 cursor와 연결된 Statement를 cache하게 되고 다음번 작업에서 같은 Statement를 수행하게 되면 Cache목록에서 이 Statement를 재사용하게 되어 Oracle에서는 soft parsing을 하지 않게 됨. - Statement가 cache되어 있는 동안 Oracle에서 cursor를 Open하고 있는 지는 다음의 테스트를 통해 알 수 있음 - 수행 source code package exem.oracle.statementcache; import java.s..

기술이야기 2009. 5. 26. 19:02
Oracle Update Batching

대량의 DML작업을 하기 위해서는 기본적으로 각각 insert, update, delete문을 만들어 수행하게 된다. 그러나 같은 SQL이라 하더라도 이를 실행(Execute)하는 방법에 따라 그 성능의 차이가 나타날 수 있다. 우리는 일반적으로 SQL을 수행할 때 PreparedStatement라는 객체를 이용하여 작업을 한다. 대량의 DML을 할 때 우리는 PreparedStatement에 SQL을 지정하고 루프내에서 파라메터를 바인딩 하여 실행한다. 그러나 실제로 이 바인딩 된 SQL의 실행은 언제 하느냐에 따라 처리 속도의 차이는 극명하게 나타난다. 우리가 PreparedStatement를 사용하게 되면 SQL의 실행에 있어 두가지 옵션을 가지게 된다. 첫째로 바인딩 이후에 Execute를 하는 ..

기술이야기 2009. 5. 26. 18:59
성능에서의 풍선효과

지금 된서리를 맞고 있는 참여정부 시절에 한 때 지면을 화려하게 장식했던 단어가 있다. 그것은 바로 '풍선 효과' 이다. 이 풍선 효과라는 말은 집값을 잡으려고 한쪽에 규제를 몰아주니 그 곳의 집값의 오름세는 둔화되었지만 그 근처의 집값이 오르는 현상을 일컫는다. 풍선 한 쪽을 꾸욱 누르니 반대 편으로 공기가 밀려 부풀어 오르는 모양새를 빗댄 것이다. 이런 풍선 효과가 비단 부동산에만 있는 것은 아니다. 오라클의 성능에서도 이러한 풍선효과는 엄연히 존재하고 있다. 간단하게 말하자면 어느 한 곳의 경합이 해결되었을 때 성능이 마냥 좋아지는 것이 아니라 경합의 위치가 이동하는 현상을 말하는 것이다. 이러한 현상은 Oracle의 특정 영역이 아닌 모든 지점에서 관찰된다. 오라클의 경합을 설명할 때 즐겨 사용하..

기술이야기 2009. 4. 14. 14:18
Transaction 중심의 성능 분석법

이 글은 내가 InterMax라는 툴을 지원할 때 작성한 글이다. PC에서 썩고 있길래 여기에 올린다. 1) WAS에서 성능이란 무엇인가? 우선 Web Application Server(이하 WAS)에서 성능을 분석하는 방법을 논의하기 이전에 WAS에서 성능이란 무엇인가에 대해 먼저 생각을 해 볼 필요가 있다. 쉬운 설명을 위해 자동차를 예로 들어 보도록 하자. 자동차는 용도에 따라 다양한 종류가 있다. 우리 주위에서 흔히 볼 수 있는 고급 승용차, 덤프 트럭 그리고 경주용 자동차까지 상당히 다양한 분류가 존재한다. 그렇다면 이러한 자동차의 성능은 어떻게 얘기 할 수 있을까? 아마도 앞서 열거한 자동차들에 대해 같은 지표로 성능을 얘기할 수는 없을 것이다. 속도만으로 성능을 따진다면 경주용 자동차를 따라..

기술이야기 2009. 4. 1. 17:41
SSD와 Performance...

오늘 회사의 고문으로 계시는 이상원 박사님이 방문을 하셔서 SSD를 이용한 OLTP 성능 향상 방안에 애해 많은 이야기를 해 주셨다. SSD란 Flash Memory로 만든 하드디스크 정도로 생각하면 쉽다. 기존의 Arm이 움직여 플레이트에 있는 정보를 읽는 기계적인 방식에서 Flash Memory를 통해 전자적인 방식으로 변경하기 때문에 속도 측면에서 많은 이점이 있고 전기도 절약되는 효과가 있다고 한다. 그런데 가격은 착하지가 못하기 때문에 아직 시장에 많이 퍼지지 않고 있다. SSD에 대한 나의 입장은 보편화되면 쓰겠다는 것이다. SSD에 대한 심리적인 저항 같은 것은 없고 다만 가격이 문제가 될 뿐인데 SSD가 보편화되는 것도 역시 가격이라고 생각한다. 오늘 세미나에서 내가 느낀 것은 박사님이 S..

기술이야기 2009. 4. 1. 17:36
이전 1 2 다음
이전 다음
공지사항
최근에 올라온 글
  • Big Data Myth 1. 우리 회⋯
  • Big Data Myth의 연재를⋯
  • 데이터가 우리 눈 앞에 펼⋯
  • RDBMS에서 실시간빅데이터⋯
최근에 달린 댓글
  • 이 글을 쓴 이유는 악을 보고⋯
  • 잘 읽었습니다.
  • 미국문화를 점령한 유태인에⋯
  • 나치만을 악으로 정의하고 인⋯
Total
403,527
Today
5
Yesterday
14
링크
TAG
  • 구글
  • SNS
  • 전자책
  • ebook
  • 빅데이터
  • 애플
  • 소셜네트워크
  • 스티브잡스
  • bigdata
  • jvm internal
  • 아이패드
  • facebook
  • 앱스토어
  • 트위터
  • Google
  • 안드로이드
  • 아이폰
  • garbage collection
  • Twitter
  • 소셜네트워크서비스
  • runtime data areas
  • Splunk
  • hotspot
  • iPhone
  • jvm
  • 스마트폰
  • Web2.0
  • 페이스북
  • Apple
  • iPad
more
«   2022/07   »
일 월 화 수 목 금 토
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
글 보관함
  • 2015/04 (3)
  • 2015/03 (1)
  • 2014/11 (2)
  • 2014/09 (3)
  • 2014/08 (1)

Blog is powered by Tistory / Designed by Tistory