Linux Performan tuning Part I

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 Kernel)
 리소스 독점을 막기 위한 컨트롤 그룹 (cgroup)

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 아키텍쳐 에서의 어플리케이션 관리 및 추가 기능들이 최적화되어 있음.
 대용량 메모리 지원과 관련된 기능들이 개선됨.

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 정의

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 함수정의

1.3 Interrupt timer 기능 추가 (Tickless kernel)
 쓰레드 또는 프로세스에서 발생하는 예외 사항에 대해서 처리를 위한 타이머 매커니즘 사용
 이전에는 tickless kernel을 별도로 제공해 주는 형태로 지원하였으나 RHEL6 Kernel에 구현되어 있음
 Mili/sec 단위로 Time Slice 하여 interrupt 속도를 빠르게 진행 CPU 및 시스템의 부하량을 낮춰줌
Milli/sec 단위로 Time Slice

2. 리소스 독점을 막기 위한 컨트롤 그룹 (cgroup)
 여러 개의 어플리케이션을 포함 시킨 시스템에서 단일 어플리케이션이 전체 리소스를 독점하여 성능일 저하될수 있음
 관리자 필요에 따라서 cgroup 을 이용하여 특정 어플리케이션에 리소스를 할당할수 있음.
 예를 들어서 2개의 CPU 에서 node0 은 http, node2는 MySQL 에 할당, 메모리 및 네트워크 대역폭도 조정 가능

2.시스템 튜닝전 프로파일링 (Profiling)
 CPU Profiling
 System BIOS Profiling
 Profiling NUMA Arch
 Disk Latency Profiling

2.1 CPU Profiling
 c-state는 사용하지 않은 cpu에 대해서는 비활성화하여 전원을 절약할수 있도록 Sleep 상태로 전환한다.
http://www.ibm.com/developerworks/library/l-cpufreq-1/

2.1 CPU Profiling
 튜닝전 어떤 CPU가 전력을 가장 많이 사용하며 어떤 프로세스가 CPU core에 인터럽트를 가장 많이 발생 시키는지에 등에
대한 프로 파일링은 Powertop 툴을 이용하여 전체적인 현황을 파악할수 있다
 낮은 전력 소비를 위해서 어떻게 튜닝이 진행되어야 할지에 대한 분석과 기준을 마련할수 있다.
https://01.org/powertop/

2.1 CPU Profiling
 튜닝전 운영 시스템에 대해서 어떤 프로세스 또는 쓰레드가 cpu interrupt 발생 시키는 가를 확인할수 있다 .
 Idle stats 및 Frequency stats , Device stats 와 전체적인 BIOS 튜닝 상태를 Profiling 이 가능함.
 전체 Overview 에서는 커널에서 스케쥴링 되는 현황에 대해서 Monitoring이 가능

2.1 CPU Profiling
 Idle stats 항목에서는 현재 시스템의 core에 대한 idle 현황을 Profiling 이 가능함
 C-State를 사용하는 시스템의 경우 어떤 Core가 C-State에 오려 머물러 있는지, 사용률을 얼마인지 파악이 가능함

2.1 CPU Profiling
 Frequency stats는 각 core 별 전력 사용량을 나타내고 있음
 아래 예제의 그림은 idle 상태로 전환되는 Core가 없음으로 전력 사용량이 높다고 판단해도 됨

2.2 System BIOS Profiling
 현재 시스템에 대한 하드웨어 BIOS 현황에 대한 Profiling은 dmidecode 명령어를 이용하여 진행
 dmidecode –s 옵션 또는 –t 옵션을 이용해서 원하는 BIOS 항목을 Query 할수 있다.

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

2.3 Disk Latency Profiling
출처: https://code.google.com/p/ioping/
 파일 시스템에 대한 i/o latency를 측정하기 위한 오픈소스 툴인 ioping 을 사용하여 튜닝전/후 비교가능
 네트워크의 ping 테스트와 유사한 output을 보여줌으로써 직관적인 latency 현황 파악이 가능함

3. RHEL6 어플리케이션 리소스 컨트롤
 RHEL6 CGROUP 정의
 NUMA Pining
 NUMA Memory interleave
 CGROUP 이용한 리소스 생성

3.1 RHEL6 CGROUP 정의
 여러 개의 어플리케이션이 운영하고 있는 시스템중 특정 어플리케이션의 리소스 독점으로 인한 성능 저하를 방지할수 있음
 실제로 동작중이 태스크를 그룹으로 구성하여 할당 가능하며, 별도의 추가적인 부가기능 없이 그룹핑 가능함.
 태스크 그룹에 할당될 리소스들은 subsystem에서 담당하게 된다.
출처 : http://studyfoss.egloos.com/5506102

3.1 NUMA Pining
 어플리케이션의 intensive 한 워크로드를 처리하기 위해 NUMA의 Context switch를 고려하여 구성
 어플리케이션 처리 영역과 운영체제 영역을 분리하여 Core Resource 간섭을 최소화 하도록 구성
 어플리케이션 영역의 경우 속도에 민감한 업무 프로세스를 가장 빠른 Core 번호에 배치.
 numactl 또는 taskset 명령어를 이용하여 pining
Node 0 Node 1
어플리케이션 영역 운영체제 영역
App 1 배치 App 2 배치 커널 스케쥴러 동작

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

3.3 NUMA Memory interleaving
 메모리의 접근 속도를 빠르게 하기 위해서 인접한 메모리의 위치를 서로 다른 메모리 뱅크에 위치 시킴으로써 메모리 접근 속도를
빠르게 하기 위함., 블록단위 전송이 가능하며 DMA에서 많이 사용
 Memory interleaving 을 못하게 하면 해당 코어에 할당된 노드에서만 메모리를 할당 받게되며, 해당영역에서 swap 발생
 numactl 옵션에서 –interleave=all 은 모든 메모리 노드와는 무관하게 Page Allocation 정책에 따라서 메모리 할당
부족하면 인근 노드로 부터 나머지를 할당
 하드웨어 BIOS 에서는 Default Enable 되어 있으며 numactl로 제어하기 위해서는 반드시 Disable 전환
 메모리 사용량이 많은 DB 서버의 경우 고려될수 있는 튜닝 포인트

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 생성 및 활성화

 /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번째 메모리 뱅크]
}
}

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

4. 파일 시스템 튜닝
 I/O Scheduler & Elevators
I/O Subsystem (CFQ, Deadline, Anticipatory, noop)
 Switching I/O Scheduling
 Filesystem barrier tuning (noatime, nobarrier)

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)
방지 알고리즘.

4.2 CFQ (Complete Fair Queue)
 RHEL5, RHEL6 운영체제 에서는 Default Scheduler 이다.
 각 프로세스 대기열 마다 큐(queue)를 가지고 있어서 I/O Request에 대해서 공정하게 할당한다.
 RR (Round-Robin) 방식으로 큐에 있는 request를 순서대로 처리를 하게 된다.
 많은 프로세스 들이 동일한 시간내에 디스크의 세세한 I/O를 생성할때 적합한 스케쥴러.

4.2 Anticipatory
 Read request에 대해서 완전히 commit 한후에 바로 다른 request를 처리하는 것이 아니라 일정시간 대기 했다가
(default 6ms) 근접한 영역에 대한 reuqest를 먼저 처리
 지연시간을 줄이고 처리량을 높이기 위한 방식
 입출력 시간을 대기하고 있다가 한꺼번에 처리하는 특성이 있어서 지연 시간에 않좋을 영향을 줄수 있음
 외부에서 끊이지 않고 주기적으로 들어오는 데이터를 처리하는 서버에 적합 (웹서버, was서버등)

4.2 Deadline
 Request별 start 시간을 기억하고 있다가 I/O 대기 시간의 한계점 (Deadline)을 정하고 한계점에 가까운 request 부터
처리하는 방식. (요청 처리 시간을 기준으로 우선 즉시 처리)
 Sorted Queue 를 처리하기 전 Deadline에 가까운 request 부터 우선 처리
 읽기와 쓰기를 모두 균형있게 처리
 I/O 가 많은 시스템에 적합 (Heavy i/O), 리얼타임 어플리케이션 또는 데이터 베이스 시스템에 적합

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)

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

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

5. 가상 메모리 튜닝
 Memory Addressing
- Translation Lookaside Buffer (TLB) and Hugepage
- Transparent HugePage
 Swap Memory

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 가 요구됨)

 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

 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

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를 우선 적용

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 : 스왑을 적극적으로 사용하겠다.

6.1 리눅스 시스템 관리 방안
RHN Satellite 기능
• Monitoring
• Provisioning
• Patch Management
• Configuration Management

Linux Performan tuning Part I

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Linux Performan tuning Part I

Similar to Linux Performan tuning Part I (20)

More from sprdd

More from sprdd (20)

Linux Performan tuning Part I