Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
2013. 08.05
Performance Tuning for RHEL
주식회사 오픈소스컨설팅
- Internal Use Only -
Table of Content
 RHEL6 성능을 위한 특징 및 개선사항
 시스템 튜닝전 프로파일링
 RHEL6 리소스 컨트롤 (CGROUP)
 파일 시스템 튜닝
 가상 ...
1. RHEL6 성능을 위한 특징 및 개선 사항
 NUMA (Non-Uniform Memory Access) 개선
 Ticket Spinlocks
 Interrupt Timer 매커니즘 추가 (tickless Ke...
- Internal Use Only -
1.1 NUMA (None-Uniform Memory Access) 개선
 RHEL6 NUMA 아키텍쳐에 최적화 되어 있음.
 CPU의 코어 설정으로 인한 App 배치 용이
...
- Internal Use Only -
1.2 Ticket Spinlocks 개선
 프로세스가 동일한 메모리 영역을 접근(Access) 할경우 대기중인 프로세스가 공정 (Fair)하게 동작할수 있도록 기존의
Spinl...
- Internal Use Only -
1.2 Ticket Spinlocks 개선
 기존의 spinlock의 문제점을 보완하기 위해서 Kernel의 Tree base 알고리즘을 쓰는 CFS 스케쥴러에 적용된 알고리즘
...
- Internal Use Only -
1.3 Interrupt timer 기능 추가 (Tickless kernel)
 쓰레드 또는 프로세스에서 발생하는 예외 사항에 대해서 처리를 위한 타이머 매커니즘 사용
 이전에...
- Internal Use Only -
2. 리소스 독점을 막기 위한 컨트롤 그룹 (cgroup)
 여러 개의 어플리케이션을 포함 시킨 시스템에서 단일 어플리케이션이 전체 리소스를 독점하여 성능일 저하될수 있음
 관...
2.시스템 튜닝전 프로파일링 (Profiling)
 CPU Profiling
 System BIOS Profiling
 Profiling NUMA Arch
 Disk Latency Profiling
- Internal Use Only -
2.1 CPU Profiling
 c-state는 사용하지 않은 cpu에 대해서는 비활성화하여 전원을 절약할수 있도록 Sleep 상태로 전환한다.
http://www.ibm.co...
- Internal Use Only -
2.1 CPU Profiling
 튜닝전 어떤 CPU가 전력을 가장 많이 사용하며 어떤 프로세스가 CPU core에 인터럽트를 가장 많이 발생 시키는지에 등에
대한 프로 파일링은...
- Internal Use Only -
2.1 CPU Profiling
 튜닝전 운영 시스템에 대해서 어떤 프로세스 또는 쓰레드가 cpu interrupt 발생 시키는 가를 확인할수 있다 .
 Idle stats 및...
- Internal Use Only -
2.1 CPU Profiling
 Idle stats 항목에서는 현재 시스템의 core에 대한 idle 현황을 Profiling 이 가능함
 C-State를 사용하는 시스템의 ...
- Internal Use Only -
2.1 CPU Profiling
 Frequency stats는 각 core 별 전력 사용량을 나타내고 있음
 아래 예제의 그림은 idle 상태로 전환되는 Core가 없음으로 ...
- Internal Use Only -
2.2 System BIOS Profiling
 현재 시스템에 대한 하드웨어 BIOS 현황에 대한 Profiling은 dmidecode 명령어를 이용하여 진행
 dmidecod...
- Internal Use Only -
2.3 Profiling NUMA Arch
 NUMA 아키텍쳐를 지원하는 시스템들에 대한 Node (소켓) 들에 대한 core 배치 현황 및 hit rate등을 확인
 Numa...
- Internal Use Only -
2.3 Disk Latency Profiling
출처: https://code.google.com/p/ioping/
 파일 시스템에 대한 i/o latency를 측정하기 위한 오...
3. RHEL6 어플리케이션 리소스 컨트롤
 RHEL6 CGROUP 정의
 NUMA Pining
 NUMA Memory interleave
 CGROUP 이용한 리소스 생성
- Internal Use Only -
3.1 RHEL6 CGROUP 정의
 여러 개의 어플리케이션이 운영하고 있는 시스템중 특정 어플리케이션의 리소스 독점으로 인한 성능 저하를 방지할수 있음
 실제로 동작중이 태스...
- Internal Use Only -
3.1 NUMA Pining
 어플리케이션의 intensive 한 워크로드를 처리하기 위해 NUMA의 Context switch를 고려하여 구성
 어플리케이션 처리 영역과 운영...
- Internal Use Only -
3.1 NUMA Pining
# CPU isolation
title Red Hat Enterprise Linux Server (2.6.32-220.4.2.el6.x86_64)
ro...
- Internal Use Only -
3.3 NUMA Memory interleaving
 메모리의 접근 속도를 빠르게 하기 위해서 인접한 메모리의 위치를 서로 다른 메모리 뱅크에 위치 시킴으로써 메모리 접근 속도를...
- Internal Use Only -
3.1 CGROUP을 이용한 리소스 생성
mkdir -p /opt/service_group
# yum –y install libcgroup
# mount -t cgroup –o c...
- Internal Use Only -
3.1 CGROUP을 이용한 리소스 생성
 /etc/cgconfig.conf 파일을 이용한 cgroup 정의
mount {
cpuset = /opt/service_group/we...
- Internal Use Only -
3.1 CGROUP을 이용한 리소스 생성
group mysql {
perm {
task {
uid = mysql;
gid = ,mysql;
}
}
cpuset {
cpuset.cp...
4. 파일 시스템 튜닝
 I/O Scheduler & Elevators
I/O Subsystem (CFQ, Deadline, Anticipatory, noop)
 Switching I/O Scheduling
 Fi...
- Internal Use Only -
4.1 I/O Scheduler & Elevators
 I/O 스케쥴러는 디스크의 I/O를 효율화 하기 위한 기능이다.
 커널 2.6에서는 기본적으로 4가지 형태의 스케쥴러를 ...
- Internal Use Only -
4.2 CFQ (Complete Fair Queue)
 RHEL5, RHEL6 운영체제 에서는 Default Scheduler 이다.
 각 프로세스 대기열 마다 큐(queue)...
- Internal Use Only -
4.2 Anticipatory
 Read request에 대해서 완전히 commit 한후에 바로 다른 request를 처리하는 것이 아니라 일정시간 대기 했다가
(default ...
- Internal Use Only -
4.2 Deadline
 Request별 start 시간을 기억하고 있다가 I/O 대기 시간의 한계점 (Deadline)을 정하고 한계점에 가까운 request 부터
처리하는 방...
- Internal Use Only -
4.2 NOOP (No Operation)
 i/O 스케쥴러중 가장 간단하게 구현된 스케쥴러
 별도의 우선순위 알고리즘 없이 순서없이 FIFO 처리한다.
 대용랭의 캐쉬를 가...
- Internal Use Only -
4.3 switching I/O Scheduling
 i/O 스케쥴러를 변경하기 위해서는 아래와 같이 두가지 방법을 이용해서 변경할수 있다.
# /etc/fstab를 이용한 커널...
- Internal Use Only -
4.3 Filesystem noatime, nobarrier tuning
 noatime 옵션을 사용하게 되면 .파일의 access time를 기록하지 않음.
 파일에 대한 a...
5. 가상 메모리 튜닝
 Memory Addressing
- Translation Lookaside Buffer (TLB) and Hugepage
- Transparent HugePage
 Swap Memory
- Internal Use Only -
5.1 Translation Lookaside Buffer (TLB) and Huge Page
 TLB (Translation Lookaside Buffer) 란 ?
- virt...
- Internal Use Only -
5.1 Translation Lookaside Buffer (TLB) and Huge Page
 Standard Huge Page
- 최대 2MB
- /proc/sys/vm/nr...
- Internal Use Only -
5.1 Translation Lookaside Buffer (TLB) and Huge Page
 Transparent HugePages
- 생성, 관리, 사용에 대한 전반적을 것...
- Internal Use Only -
5.1 Translation Lookaside Buffer (TLB) and Huge Page
http://www.oracle-base.com/articles/linux/confi...
- Internal Use Only -
5.2 SWAP Memory Tuning
 Tuning swappiness
- page table + vm.swappiness > = 100 이면 swap이 가동되는 구조
- v...
6. 리눅스 매니지 먼트
- Internal Use Only -
6.1 리눅스 시스템 관리 방안
RHN Satellite 기능
• Monitoring
• Provisioning
• Patch Management
• Configuration Ma...
감사합니다.
Upcoming SlideShare
Loading in …5
×

Linux Performan tuning Part I

6,175 views

Published on

  • 안녕하세요 혹시 linux performan tuning part 자료 다운로드 받을 수 없을까요...?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Linux Performan tuning Part I

  1. 1. 2013. 08.05 Performance Tuning for RHEL 주식회사 오픈소스컨설팅
  2. 2. - Internal Use Only - Table of Content  RHEL6 성능을 위한 특징 및 개선사항  시스템 튜닝전 프로파일링  RHEL6 리소스 컨트롤 (CGROUP)  파일 시스템 튜닝  가상 메모리 튜닝  리눅스 시스템 매니지먼트
  3. 3. 1. RHEL6 성능을 위한 특징 및 개선 사항  NUMA (Non-Uniform Memory Access) 개선  Ticket Spinlocks  Interrupt Timer 매커니즘 추가 (tickless Kernel)  리소스 독점을 막기 위한 컨트롤 그룹 (cgroup)
  4. 4. - Internal Use Only - 1.1 NUMA (None-Uniform Memory Access) 개선  RHEL6 NUMA 아키텍쳐에 최적화 되어 있음.  CPU의 코어 설정으로 인한 App 배치 용이  CPU Affinity Binding 가능 하도록 설계 ( numactl 제어그룹 또는 cgroup 을 통한 리소스제어)  taskset을 통한 App Core 바인딩  numactl 을 이용한 NUMA 아키텍쳐 interleave 제어  커널자체의 tickless 기능 또는 realtime의 지원으로 인한 app의 latency를 고려한 구성 가능  튜닝 프로파일 제공  Huge Page 및 Huge TLB 기능 제공  RHEL6의 성능에 대한 개선은 NUMA 아키텍쳐 에서의 어플리케이션 관리 및 추가 기능들이 최적화되어 있음.  대용량 메모리 지원과 관련된 기능들이 개선됨.
  5. 5. - Internal Use Only - 1.2 Ticket Spinlocks 개선  프로세스가 동일한 메모리 영역을 접근(Access) 할경우 대기중인 프로세스가 공정 (Fair)하게 동작할수 있도록 기존의 Spinlock 알고리즘을 개선하여 Ticket Spinlock 으로 개선  기존의 spinlock을 개선하기 우해서 커널 2.6.25 버전부터 지속적으로 개선을 진행 (www.kernel.org) /* include/linux/spinlock.h */ #define spin_lock(lock) _spin_lock(lock) /* kernel/spinlock.c */ void __lockfunc _spin_lock(spinlock_t *lock) { preempt_disable(); spin_acquire(&lock->dep_map, 0, 0, _RET_IP_); LOCK_CONTENDED(lock, _raw_spin_trylock, _raw_spin_lock); }  O(1) 스케쥴러 기반의 Locking Algorithm  Task의 Priority 에 따라서 Lock우선배정  Releas된 Lock에 대해서는 재사용하여 다음 Process에 Lock을 할당하는 형태 (Cache 방식)  Lock을 얻을수 없다면 Busy wating 으로 전환될수 있음  Busy Waiting 무한루프 진입 다른 thread에게 CPU 양보하지 않음. (sleep 상태로 전환될수 있음)  Thread가 lock을 유지하면 CPU 사용시간 높아짐  Lock 배정이 공정하지 못함 (Unfair) Spinlock 정의
  6. 6. - Internal Use Only - 1.2 Ticket Spinlocks 개선  기존의 spinlock의 문제점을 보완하기 위해서 Kernel의 Tree base 알고리즘을 쓰는 CFS 스케쥴러에 적용된 알고리즘  순차적으로 Lock 을 할당 받아 무한전 write를 대기 하는 것에 비해서 ticket이 할당된 쓰레드에 대해서만 write 대기  Lock을 재사용 하는 형태가 아니기 때문에 Cache missing을 줄일수 있는 장점이 있다. static __always_inline void __raw_spin_lock(raw_spinlock_t *lock) { __ticket_spin_lock(lock); } static __always_inline int __raw_spin_trylock(raw_spinlock_t *lock) { return __ticket_spin_trylock(lock); } static __always_inline void __raw_spin_unlock(raw_spinlock_t *lock) { __ticket_spin_unlock(lock); } Ticket_Spinlock 함수정의
  7. 7. - Internal Use Only - 1.3 Interrupt timer 기능 추가 (Tickless kernel)  쓰레드 또는 프로세스에서 발생하는 예외 사항에 대해서 처리를 위한 타이머 매커니즘 사용  이전에는 tickless kernel을 별도로 제공해 주는 형태로 지원하였으나 RHEL6 Kernel에 구현되어 있음  Mili/sec 단위로 Time Slice 하여 interrupt 속도를 빠르게 진행 CPU 및 시스템의 부하량을 낮춰줌 Milli/sec 단위로 Time Slice
  8. 8. - Internal Use Only - 2. 리소스 독점을 막기 위한 컨트롤 그룹 (cgroup)  여러 개의 어플리케이션을 포함 시킨 시스템에서 단일 어플리케이션이 전체 리소스를 독점하여 성능일 저하될수 있음  관리자 필요에 따라서 cgroup 을 이용하여 특정 어플리케이션에 리소스를 할당할수 있음.  예를 들어서 2개의 CPU 에서 node0 은 http, node2는 MySQL 에 할당, 메모리 및 네트워크 대역폭도 조정 가능
  9. 9. 2.시스템 튜닝전 프로파일링 (Profiling)  CPU Profiling  System BIOS Profiling  Profiling NUMA Arch  Disk Latency Profiling
  10. 10. - Internal Use Only - 2.1 CPU Profiling  c-state는 사용하지 않은 cpu에 대해서는 비활성화하여 전원을 절약할수 있도록 Sleep 상태로 전환한다. http://www.ibm.com/developerworks/library/l-cpufreq-1/
  11. 11. - Internal Use Only - 2.1 CPU Profiling  튜닝전 어떤 CPU가 전력을 가장 많이 사용하며 어떤 프로세스가 CPU core에 인터럽트를 가장 많이 발생 시키는지에 등에 대한 프로 파일링은 Powertop 툴을 이용하여 전체적인 현황을 파악할수 있다  낮은 전력 소비를 위해서 어떻게 튜닝이 진행되어야 할지에 대한 분석과 기준을 마련할수 있다. https://01.org/powertop/
  12. 12. - Internal Use Only - 2.1 CPU Profiling  튜닝전 운영 시스템에 대해서 어떤 프로세스 또는 쓰레드가 cpu interrupt 발생 시키는 가를 확인할수 있다 .  Idle stats 및 Frequency stats , Device stats 와 전체적인 BIOS 튜닝 상태를 Profiling 이 가능함.  전체 Overview 에서는 커널에서 스케쥴링 되는 현황에 대해서 Monitoring이 가능
  13. 13. - Internal Use Only - 2.1 CPU Profiling  Idle stats 항목에서는 현재 시스템의 core에 대한 idle 현황을 Profiling 이 가능함  C-State를 사용하는 시스템의 경우 어떤 Core가 C-State에 오려 머물러 있는지, 사용률을 얼마인지 파악이 가능함
  14. 14. - Internal Use Only - 2.1 CPU Profiling  Frequency stats는 각 core 별 전력 사용량을 나타내고 있음  아래 예제의 그림은 idle 상태로 전환되는 Core가 없음으로 전력 사용량이 높다고 판단해도 됨
  15. 15. - Internal Use Only - 2.2 System BIOS Profiling  현재 시스템에 대한 하드웨어 BIOS 현황에 대한 Profiling은 dmidecode 명령어를 이용하여 진행  dmidecode –s 옵션 또는 –t 옵션을 이용해서 원하는 BIOS 항목을 Query 할수 있다.
  16. 16. - Internal Use Only - 2.3 Profiling NUMA Arch  NUMA 아키텍쳐를 지원하는 시스템들에 대한 Node (소켓) 들에 대한 core 배치 현황 및 hit rate등을 확인  Numactl 소켓 코어의 배치 현황을 확인할수 있으며 numastat 명령어는 core 의 hit rate를 확인 가능 numactl --hardware available: 2 nodes (0-2) node 0 cpus: 1 2 3 4 5 6 node 0 size: 16373 MB node 0 free: 15322 MB node 1 cpus: 1 2 3 4 5 6 node 1 size: 16384 MB node 1 free: 15905 MB 0: 10 20 20 20 1: 20 10 20 20
  17. 17. - Internal Use Only - 2.3 Disk Latency Profiling 출처: https://code.google.com/p/ioping/  파일 시스템에 대한 i/o latency를 측정하기 위한 오픈소스 툴인 ioping 을 사용하여 튜닝전/후 비교가능  네트워크의 ping 테스트와 유사한 output을 보여줌으로써 직관적인 latency 현황 파악이 가능함
  18. 18. 3. RHEL6 어플리케이션 리소스 컨트롤  RHEL6 CGROUP 정의  NUMA Pining  NUMA Memory interleave  CGROUP 이용한 리소스 생성
  19. 19. - Internal Use Only - 3.1 RHEL6 CGROUP 정의  여러 개의 어플리케이션이 운영하고 있는 시스템중 특정 어플리케이션의 리소스 독점으로 인한 성능 저하를 방지할수 있음  실제로 동작중이 태스크를 그룹으로 구성하여 할당 가능하며, 별도의 추가적인 부가기능 없이 그룹핑 가능함.  태스크 그룹에 할당될 리소스들은 subsystem에서 담당하게 된다. 출처 : http://studyfoss.egloos.com/5506102
  20. 20. - Internal Use Only - 3.1 NUMA Pining  어플리케이션의 intensive 한 워크로드를 처리하기 위해 NUMA의 Context switch를 고려하여 구성  어플리케이션 처리 영역과 운영체제 영역을 분리하여 Core Resource 간섭을 최소화 하도록 구성  어플리케이션 영역의 경우 속도에 민감한 업무 프로세스를 가장 빠른 Core 번호에 배치.  numactl 또는 taskset 명령어를 이용하여 pining Node 0 Node 1 어플리케이션 영역 운영체제 영역 App 1 배치 App 2 배치 커널 스케쥴러 동작
  21. 21. - Internal Use Only - 3.1 NUMA Pining # CPU isolation title Red Hat Enterprise Linux Server (2.6.32-220.4.2.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-220.4.2.el6.x86_64 ro root=UUID=2e9a6a7a-582c-44a4-a4d5- d16768805257 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD quiet SYSFONT=latarcyrheb-sun16 rhgb crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us Isolcpus=0-5  cpu core를 isolation 하가 위해 아래와 같이 fstab에서 설정 # taskset core pining # taskset –cp <core> < pid> or taskset –c <core> your_command # numactl core pining # numactl –physcpubind= 0,1,2,,3,4,5 ./program
  22. 22. - Internal Use Only - 3.3 NUMA Memory interleaving  메모리의 접근 속도를 빠르게 하기 위해서 인접한 메모리의 위치를 서로 다른 메모리 뱅크에 위치 시킴으로써 메모리 접근 속도를 빠르게 하기 위함., 블록단위 전송이 가능하며 DMA에서 많이 사용  Memory interleaving 을 못하게 하면 해당 코어에 할당된 노드에서만 메모리를 할당 받게되며, 해당영역에서 swap 발생  numactl 옵션에서 –interleave=all 은 모든 메모리 노드와는 무관하게 Page Allocation 정책에 따라서 메모리 할당 부족하면 인근 노드로 부터 나머지를 할당  하드웨어 BIOS 에서는 Default Enable 되어 있으며 numactl로 제어하기 위해서는 반드시 Disable 전환  메모리 사용량이 많은 DB 서버의 경우 고려될수 있는 튜닝 포인트
  23. 23. - Internal Use Only - 3.1 CGROUP을 이용한 리소스 생성 mkdir -p /opt/service_group # yum –y install libcgroup # mount -t cgroup –o cpu,memory,nodev /opt/service_group # cd /opt/service_group # cgcreate –g cpu,memory /opt/service_group/httpd # cgcreate –g cpyu,memory /opt/service_group/mysql # cgset –r cpuset.cpus = ‘0,2,4,6,8,10,12,14’ httpd # cgset –r cpuset.mems = ‘0 ’ httpd # cgset –r cpuset.cpus = ‘1,3,5,7,9,11,13,15’ mysql # cgset –r cpuset.mems = ‘1’ mysql  커널은 cgroup이라는 파일 시스템을 제공하며, 아래와 같이 바로 마운트 하여 사용이 가능하다.  해당 디렉토리에 하위 디렉토리를 생성하게 되면 새로운 그룹이 생성하게 되는 방식으로 이루어 진다  CGROUP 생성 및 활성화
  24. 24. - Internal Use Only - 3.1 CGROUP을 이용한 리소스 생성  /etc/cgconfig.conf 파일을 이용한 cgroup 정의 mount { cpuset = /opt/service_group/webserver/cpuset; memory = /opt/service_group/webserver/memory; cpuset = /opt/service_group/dbserver/cpuset; memory = /opt/service_group/dbserver/memory; } group httpd { perm { task { uid = apache; gid = apache; } } cpuset { cpuset.cpus=0,2,4,6,8,10,12,14; cpuset.mems=0; [1번째 메모리 뱅크] } }
  25. 25. - Internal Use Only - 3.1 CGROUP을 이용한 리소스 생성 group mysql { perm { task { uid = mysql; gid = ,mysql; } } cpuset { cpuset.cpus=1,3,5,7,9,11,13,15; cpuset.mems=1; [2번째 메모리 뱅크] } } # chkconfig cgconfig on # service cgconfig start
  26. 26. 4. 파일 시스템 튜닝  I/O Scheduler & Elevators I/O Subsystem (CFQ, Deadline, Anticipatory, noop)  Switching I/O Scheduling  Filesystem barrier tuning (noatime, nobarrier)
  27. 27. - Internal Use Only - 4.1 I/O Scheduler & Elevators  I/O 스케쥴러는 디스크의 I/O를 효율화 하기 위한 기능이다.  커널 2.6에서는 기본적으로 4가지 형태의 스케쥴러를 제공한다 ( cfq, noop, deadline, anticipatory)  일반적으로 커널 2.6에서 제공하는 스케쥴러의 디자인은 throught vs latency (response time) 핵심 요소가 된다  I/O 스케쥴러의 특성은 디스크의 geometry 특성을 고려해서 I/O를 스케쥴링 하게 된다. ( Cylinder, header,sector )  하드 디스크의 seek time 및 head의 이동 거리 최소화를 고려하여 I/O의 순서를 변경한다.  Block I/O 에서 Request가 전혀 없는 굼주림 (starvation) 방지 알고리즘.
  28. 28. - Internal Use Only - 4.2 CFQ (Complete Fair Queue)  RHEL5, RHEL6 운영체제 에서는 Default Scheduler 이다.  각 프로세스 대기열 마다 큐(queue)를 가지고 있어서 I/O Request에 대해서 공정하게 할당한다.  RR (Round-Robin) 방식으로 큐에 있는 request를 순서대로 처리를 하게 된다.  많은 프로세스 들이 동일한 시간내에 디스크의 세세한 I/O를 생성할때 적합한 스케쥴러.
  29. 29. - Internal Use Only - 4.2 Anticipatory  Read request에 대해서 완전히 commit 한후에 바로 다른 request를 처리하는 것이 아니라 일정시간 대기 했다가 (default 6ms) 근접한 영역에 대한 reuqest를 먼저 처리  지연시간을 줄이고 처리량을 높이기 위한 방식  입출력 시간을 대기하고 있다가 한꺼번에 처리하는 특성이 있어서 지연 시간에 않좋을 영향을 줄수 있음  외부에서 끊이지 않고 주기적으로 들어오는 데이터를 처리하는 서버에 적합 (웹서버, was서버등)
  30. 30. - Internal Use Only - 4.2 Deadline  Request별 start 시간을 기억하고 있다가 I/O 대기 시간의 한계점 (Deadline)을 정하고 한계점에 가까운 request 부터 처리하는 방식. (요청 처리 시간을 기준으로 우선 즉시 처리)  Sorted Queue 를 처리하기 전 Deadline에 가까운 request 부터 우선 처리  읽기와 쓰기를 모두 균형있게 처리  I/O 가 많은 시스템에 적합 (Heavy i/O), 리얼타임 어플리케이션 또는 데이터 베이스 시스템에 적합
  31. 31. - Internal Use Only - 4.2 NOOP (No Operation)  i/O 스케쥴러중 가장 간단하게 구현된 스케쥴러  별도의 우선순위 알고리즘 없이 순서없이 FIFO 처리한다.  대용랭의 캐쉬를 가진 스토리지 시스템, SSD디스크, Random Access 등을 사용하는 시스템에 적합,  가상화 시스템에서도 noop 를 권장 하고 있음. (출처 : A New I/O Scheduler for Solid State Devices / 저자 : Marcus Dunn and A.L. Narasimha Reddy)
  32. 32. - Internal Use Only - 4.3 switching I/O Scheduling  i/O 스케쥴러를 변경하기 위해서는 아래와 같이 두가지 방법을 이용해서 변경할수 있다. # /etc/fstab를 이용한 커널 스케쥴러 변경 title Red Hat Enterprise Linux Server (2.6.32-220.4.2.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-220.4.2.el6.x86_64 ro root=UUID=2e9a6a7a-582c-44a4-a4d5- d16768805257 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD quiet SYSFONT=latarcyrheb-sun16 rhgb crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us elevator=[deadline|cfq|noop|anticipatory] # sysfs를 직접 수정하여 변경 # cat /sys/block/<device>/queme/schduler noop anticipatory deadline [cfq] # echo noop > /sys/block/<device>/queue/schduler
  33. 33. - Internal Use Only - 4.3 Filesystem noatime, nobarrier tuning  noatime 옵션을 사용하게 되면 .파일의 access time를 기록하지 않음.  파일에 대한 access time을 기록하지 않기 때문에 meta data 업데이트를 기록하지 않기 때문에 성능 향상을 볼수 있다.  noatime을 설정하면 nodiratime 도 함께 활성화 됨으로 두가지의 옵션을 동시에 설정할 필요는 없다  Write barrier를 사용할 경우 파일 시스템에 write시에 데이터의 손상에 대한 위험을 완화 시키는데 효과적이다. - fsync( ) 통해서 메타 데이터를 확인 전송된 데이터가 영구적으로 지속될수 있도록 영구적으로 지속 - 스토리지의 경우 전원에 문제가 생겨서 cache write back 과정이 진행되며 fsync 또한 동작을 하게 됨 - 이부분에서 속도 저하가 나타나게 됨. - 일반적으로 스토리지에서 battery-backed write caches를 사용하게 되는경우 nobarrier 옵션을 적용한다. 파일 시스템에 I/O 가 발생하는 데이터 파티션이 있다면 아래와 같이 옵션을 추가합니다. UUID=2e9a6a7a-582c-44a4-a4d5-d16768805257 / ext4 defaults,noatime,nobarrier 1 1 UUID=d55773f3-f5b8-4e04-a758-0380a272f945 /boot ext4 defaults 1 2 UUID=0bda937e-341a-4adc-baf8-79f664fc57e5 /data ext4 defaults,noatime,nobarrier 1 2
  34. 34. 5. 가상 메모리 튜닝  Memory Addressing - Translation Lookaside Buffer (TLB) and Hugepage - Transparent HugePage  Swap Memory
  35. 35. - Internal Use Only - 5.1 Translation Lookaside Buffer (TLB) and Huge Page  TLB (Translation Lookaside Buffer) 란 ? - virtual address 에서 Physical Memory 로 최근에 접근하였던 가상 주소의 Page Table Entry를 저장, - 자주사용 하는 Page table를 저장해 함으로써 물리적인 메모리 주소로 Translation 해주는 속도를 높여 높여준다  Huge Page 란? - 메모리 관리는 페이지 (Page) 라는 블록에서 관리 되어짐 - 일반적인 프로세스 아키텍쳐에서 제공하는 HugePage size 는 4KiB - HugPage size 가 늘어날수록 Page Table Entri는 줄어들게 되고 물리적인 메모리의 주소 변환에 대한 Hit 율을 높아짐 (ex: 1GB = 4Kib 쪼개서 물리적인 메모리 주소를 변환하면 256,000 Page 가 요구됨)
  36. 36. - Internal Use Only - 5.1 Translation Lookaside Buffer (TLB) and Huge Page  Standard Huge Page - 최대 2MB - /proc/sys/vm/nr_hugepages 에 HugePage Memory Reserved 함 ( ex: 2MB * 24000 = 48GB Page Huge Page 공간확보) - hugetlbfs를 이용하여 설정 가능  GB HugePage (RHEL6 only) - 최대 1GB - Boot time 시에 Reserved 해야함 hugepages=1GB
  37. 37. - Internal Use Only - 5.1 Translation Lookaside Buffer (TLB) and Huge Page  Transparent HugePages - 생성, 관리, 사용에 대한 전반적을 것들을 자동으로 설정함 - 2MB 지원 - Boot 파라메터를 통해서 진행하거나 /sys 파일 시스템을 통해서 수정 - Oracle DB를 사용하는 시스템의 경우 아직은 권장하지 않는 설정 방법  Boot Argument - /etc/grub.conf 에 커널 항목에 transparent_hugepages=always|never 선택하여 설정  Dynamic enable/Disable # cat /sys/kernel/mm/redhat_transparent_hugepage/enable # echo always > /sys/kernel/mm/redhat_transparent_hugepage/enable # echo never > /sys/kernel/mm/redhat_transparent_hugepage/enable
  38. 38. - Internal Use Only - 5.1 Translation Lookaside Buffer (TLB) and Huge Page http://www.oracle-base.com/articles/linux/configuring-huge-pages-for- oracle-on-linux-64.php#configuring-hugepages  오라클 DB를 위한 참고 사이트 - HugePage 설정과 관련해서 Oracle DB의 경우 Transparent Huge Page 보다는 HugePages를 우선 적용
  39. 39. - Internal Use Only - 5.2 SWAP Memory Tuning  Tuning swappiness - page table + vm.swappiness > = 100 이면 swap이 가동되는 구조 - vm.swappiness 스왑 메모리에 대한 활용 빈도를 결정하게 된다. - swappiness 기본값은 60초 [값의 범위 0 ~ 100] - echo 0 > /pro/sys/vm/swappiness : 스왑을 사용하지 않겠다. - echo 60 > /pro/sys/vm/swappiness : 기본값 - echo 100 > /pro/sys/vm/swappiness : 스왑을 적극적으로 사용하겠다.
  40. 40. 6. 리눅스 매니지 먼트
  41. 41. - Internal Use Only - 6.1 리눅스 시스템 관리 방안 RHN Satellite 기능 • Monitoring • Provisioning • Patch Management • Configuration Management
  42. 42. 감사합니다.

×