O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
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...
감사합니다.
Próximos SlideShares
Carregando em…5
×

Linux Performan tuning Part I

  • Seja o primeiro a comentar

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. 감사합니다.

    Seja o primeiro a comentar

    Entre para ver os comentários

  • daeshinpark9

    Apr. 9, 2015
  • NamYoulPark

    May. 15, 2015
  • zesch

    Jun. 1, 2015
  • agfe09

    Aug. 7, 2015
  • PhilYongJung

    Aug. 7, 2015
  • hyuntaeklee399

    Aug. 17, 2015
  • ssuserbe46cf

    Sep. 9, 2015
  • kjhyuni

    Oct. 5, 2015
  • hongkyupark12

    Dec. 21, 2015
  • DongHyunLee15

    Feb. 1, 2016
  • ssuser303ff4

    Jun. 3, 2016
  • SoonmKim

    Jun. 24, 2016
  • hojunji37

    Aug. 2, 2016
  • ssuser200156

    Apr. 4, 2017
  • gogohiman

    May. 23, 2017
  • ssusere85389

    Nov. 17, 2017
  • kdw91

    Dec. 3, 2017
  • JunhoSuh

    Aug. 18, 2019
  • chosangrae

    Jun. 6, 2020
  • ByungwoongShin1

    Aug. 6, 2020

Vistos

Vistos totais

7.613

No Slideshare

0

De incorporações

0

Número de incorporações

1.850

Ações

Baixados

21

Compartilhados

0

Comentários

0

Curtir

28

×