뭐..비교가 될리가 있겠어? ㅎㅎ
그냥 단순하게 메모리 사용량이랑 Tuned 의 위력,
그리고 kvm_stat 이라는 debugfs 를 이용한 kvm 모니터링툴,
powertop 과, perf 를 이용한 커널 기반 모니터링을 통한 사용법을 깨작대보려고 해봤다.
일전에 RHEL6 설명하면서 매우 재밌는 녀석들이라고 소개하고 제대로 사용하는걸
연구하기로 해놓구선 안하고 있었는데 그 초입이랄까..일단,
X201 = 4G, DualCore i5 520M, L3 cache ( 64bit, VT enable )
vs
X60s = 1.5G, Hyperthreaded 2 Core (32bit, not VT feature ) 정도만 설명하자 쿨럭
대략 사양만봐도 사실 어이가 없긴한데, 그냥 노트북 새로 사면서 심심해서 해봤다고 생각하자.
일단 동일하게 WinXP 32bit 이미지 기존에 사용하고 있던 것을 그대로
X201 에 마이그레이션 하여 동일한 상황으로 맞춰놓고 작업하였다. (스크롤 쩐다)
가장 첫번째 보이는건 resched.. ssse3 ia32_syscall 등..
잘보면 재밌다.. 64비트와 VT 라는 점이다... resched 를 통한 Hypervisor 스케쥴링은 나중에
얘기 할 기회가 있으면 하겠고... ssse3 는 vt 를 위해 올라온 내용일거라는점이다.
그 다움부터는 역시 64비트라면서 32 비트 시스템콜을 지원하기 위한 커널모듈에 힘을쓰네..
자 다음을 비교해보자..재밌다..정말..
x60s
hpet 보이는가?? 저게 바로 Real-Time 을 위해 - 라기보다는 정확한 시스템시간을 얻기위한 -
고기능성 시간타이머 알고리듬인 hpet 이다... 그걸 위해 커널이 대부분의 자원을,
소모시키고 있다는게 너무나도 감탄에 놀라움에, 흥미를 유발시키지 않느냐는거다 (읭~?)
재밌는점은 VT 가 켜지고 안켜지고의 재미... VT 와 64비트가 꺼지면 32비트인 60s 의
vmx 콜이 동일하게 보이게 된다. 비교는 못했다. (64비트끌수가 없더라 흑..)
결국 kvm_intel 모듈에서 잡아먹는 자원이 5위 안에 든다는거~
5.다시 아버지가 회사에도 감사하고, 우리가족들에게도 감사하다며 싱싱한 해산물 가져오셔서
청하 마시고 나중에 써야할듯하다 흑....탐구에 대한 정리를 방해하는건 회사나 집이나 흑...
악 이미 좀 취해서 기억이 안나기 시작한데, 이건 꼭 써야되서 일단락 시켜야되겠음둥..
자자 이 화면으로 말씀드리자면....이게 바로 그 kvm_stat 이다....
사실 석달쯤 전에 debugfs에 대해서 언급 약간 했었는데,
다음주 쯤에는 debugfs 와 ftrace 를 좀 다뤄볼까 한다.
x201
X60s
아오 자꾸 맥주마시다 어디갔냐고 난리라 여기까지 해야겠다..
(어제에 이어 마무리)
일단 어제 막판 췻기가 올라 욕으로만 난무되는 마무리였는데 다시 정정한다.
위 비교에서 봐야 할 부분은 mmu 와 tlb 부분이다.
이름만 봐도 알겠다시피, 메모리 관리를 담당하는 녀석들인데,
32비트에 VT 마저 지원 되지 않는 x60s 로써는, cache miss 비율이 높고,
pte 갱신이 잦으며, 메모리 내용이 sync 되지 않는 부분들이 많이 발생된다.
tlb 의 flush 도 자주 일어나는 이유는 context switch 가 잦기 때문인데,
문제는 이 과정에서 새로운 메모리 엔트리들을 할당하는 과정이 들어가고,
그로써 다시 또 오버헤드가 오버헤드를 불러일으키는 악순환으로 인해
가상머신이 정상적인 동작을 거의 못할만큼 느리게 동작을 하게 된다.
대략 실제 비교해본 결과 cpu 자체는 크게 차이 안났지만, 디스크 I/O 와 네트워크성능에서
5배가량 차이가 났었다.
게다가 Disk 조건을 writeback 으로 캐슁 하는 것으로 설정해 놓았더니,
Disk I/O 에 대한 연산이 더욱 높아져 오히려 x60s 에서 엄청 성능이 떨어졌다.
딱히 벤치마킹툴을 돌리기에는 너무 느려서 안돌렸는데, 나중에 한번 돌려봐야겠다..
결국엔 결론은 x60s 쓰다 새로 산 노트북에서의 성능덕분에 기분이 좋아졌다... 일 뿐이지만,
가상화 테스트나 기타 여러가지 커널에 대한 공부 및 테스트를 할 여건이 됐다는 점에,
의이가 있.....(데스크탑을사면더 좋았잖아?? ㅡ,.ㅡ:::)
Disk Cache 를 writeback 으로 하는것과, none 혹은 writethrou 로 하는것의 차이는 뭐..
대부분 알것이라 판단하고 설명 안하겠고...
스크린샷도 몇개 찍었는데 현재 갑자기 올리기가 귀찮을 만큼 스크롤이 늘어나버린관계로
패스하도록 하겠다.
어쨋든 노트북 새로 사서 좋고, 가상머신에 윈도우 잘 돌아서 좋고.... 64비트라서 좋고....
(흑...내 레츠노트는 아쉽지만 빠이빠이~)
그냥 단순하게 메모리 사용량이랑 Tuned 의 위력,
그리고 kvm_stat 이라는 debugfs 를 이용한 kvm 모니터링툴,
powertop 과, perf 를 이용한 커널 기반 모니터링을 통한 사용법을 깨작대보려고 해봤다.
일전에 RHEL6 설명하면서 매우 재밌는 녀석들이라고 소개하고 제대로 사용하는걸
연구하기로 해놓구선 안하고 있었는데 그 초입이랄까..일단,
X201 = 4G, DualCore i5 520M, L3 cache ( 64bit, VT enable )
vs
X60s = 1.5G, Hyperthreaded 2 Core (32bit, not VT feature ) 정도만 설명하자 쿨럭
대략 사양만봐도 사실 어이가 없긴한데, 그냥 노트북 새로 사면서 심심해서 해봤다고 생각하자.
일단 동일하게 WinXP 32bit 이미지 기존에 사용하고 있던 것을 그대로
X201 에 마이그레이션 하여 동일한 상황으로 맞춰놓고 작업하였다. (스크롤 쩐다)
1. Tuned 를 이용한 동일한 커널 파라메터 설정.
-> Tuned 를 이용하면 파라메터 자체를 프로필대로 수정해준다.
커스터마이징 시켜 줄 수도 있지만, 일단 동일하게 throughput-performance 로 설정했다.
참고로 /etc/tune-profile 에 보면 각 프로필 별 sysctl.conf 등의 내용이 있다. (+.,+)
2. powertop 을 이용한 튜닝은 미리 KVM 돌리기 전에 해주었다.
-> 대략적으로 공통적으로 vm.dirty_writeback_centisecs = 1500 정도로만 되어있는 상황,
wireless 역시 파워컨트롤 되고 있는 상황.
3. 이제 본격적인 모니터링을 들어가보자.
사전에 KVM 에서 Disk I/O 와 Network Monitoring 을 위해선 virt-manager 의 기본설정에서
두 항목을 활성화 시켜주어야 한다.
4.쓰려다가 치틴에맥주가 달려와서 중단 ㅠㅠ 이따 또 쓰겠....
아흑..우리 치맥님덕에 치틴이라고 쓰는 실수를... ㅠㅠ(바로잇겠음)
perf 라는 툴에 대해서 아는가?? 이녀석은 kernel 기반 프로파일링을 위주로 만들어진,
시스템 (커널) 성능 모니터링 툴이다.
원랜 지속적인 프로파일링을 목적으로 만들어진 녀석이지만, 실시간으로 볼 수 있고,
실시간으로 보기 위해선, perf top 이라는 옵션포함 명령을 주면 된다.
일단 kvm 실행 당시의 perf top 을 비교해보자.
X201
--------------------------------------------------------------------------------
PerfTop: 2014 irqs/sec kernel:50.3% exact: 0.0% [1000Hz cycles], (all, 2 CPUs)
--------------------------------------------------------------------------------
samples pcnt function DSO
_______ _____ ________________________ ____________
4861.00 22.1% need_resched [kernel]
1623.00 7.4% __memcpy_ssse3_back libc-2.13.so
1007.00 4.6% copy_user_generic_string [kernel]
997.00 4.5% rb_next [kernel]
306.00 1.4% page_fault [kernel]
262.00 1.2% ia32_syscall [kernel]
239.00 1.1% walk_system_ram_range [kernel]
228.00 1.0% do_raw_spin_lock [kernel]
205.00 0.9% _dl_sysinfo_int80 ld-2.13.so
205.00 0.9% strcmp [kernel]
181.00 0.8% down_read_trylock [kernel]
181.00 0.8% avc_has_perm_noaudit [kernel]
179.00 0.8% drm_clflush_pages [drm]
174.00 0.8% _raw_spin_lock_irqsave [kernel]
174.00 0.8% _int_malloc libc-2.13.so
가장 첫번째 보이는건 resched.. ssse3 ia32_syscall 등..
잘보면 재밌다.. 64비트와 VT 라는 점이다... resched 를 통한 Hypervisor 스케쥴링은 나중에
얘기 할 기회가 있으면 하겠고... ssse3 는 vt 를 위해 올라온 내용일거라는점이다.
그 다움부터는 역시 64비트라면서 32 비트 시스템콜을 지원하기 위한 커널모듈에 힘을쓰네..
자 다음을 비교해보자..재밌다..정말..
x60s
-------------------------------------------------------------------------------
PerfTop: 395 irqs/sec kernel:63.3% exact: 0.0% [1000Hz cycles], (all, 2 CPUs)
-------------------------------------------------------------------------------
samples pcnt function DSO
_______ _____ _______________________ ___________________
977.00 25.4% read_hpet [kernel.kallsyms]
302.00 7.9% acpi_idle_do_entry [kernel.kallsyms]
281.00 7.3% acpi_os_read_port [kernel.kallsyms]
136.00 3.5% vmx_vcpu_run [kvm_intel]
125.00 3.3% do_raw_spin_lock [kernel.kallsyms]
124.00 3.2% hpet_next_event.clone.4 [kernel.kallsyms]
87.00 2.3% acpi_os_write_port [kernel.kallsyms]
83.00 2.2% PyEval_EvalFrameEx libpython2.7.so.1.0
63.00 1.6% vmcs_readl [kvm_intel]
63.00 1.6% system_call [kernel.kallsyms]
50.00 1.3% _raw_spin_lock_irqsave [kernel.kallsyms]
39.00 1.0% do_select [kernel.kallsyms]
37.00 1.0% native_flush_tlb_single [kernel.kallsyms]
32.00 0.8% x86_decode_insn [kvm]
32.00 0.8% kvm_arch_vcpu_ioctl_run [kvm]
hpet 보이는가?? 저게 바로 Real-Time 을 위해 - 라기보다는 정확한 시스템시간을 얻기위한 -
고기능성 시간타이머 알고리듬인 hpet 이다... 그걸 위해 커널이 대부분의 자원을,
소모시키고 있다는게 너무나도 감탄에 놀라움에, 흥미를 유발시키지 않느냐는거다 (읭~?)
재밌는점은 VT 가 켜지고 안켜지고의 재미... VT 와 64비트가 꺼지면 32비트인 60s 의
vmx 콜이 동일하게 보이게 된다. 비교는 못했다. (64비트끌수가 없더라 흑..)
결국 kvm_intel 모듈에서 잡아먹는 자원이 5위 안에 든다는거~
5.다시 아버지가 회사에도 감사하고, 우리가족들에게도 감사하다며 싱싱한 해산물 가져오셔서
청하 마시고 나중에 써야할듯하다 흑....탐구에 대한 정리를 방해하는건 회사나 집이나 흑...
악 이미 좀 취해서 기억이 안나기 시작한데, 이건 꼭 써야되서 일단락 시켜야되겠음둥..
자자 이 화면으로 말씀드리자면....이게 바로 그 kvm_stat 이다....
사실 석달쯤 전에 debugfs에 대해서 언급 약간 했었는데,
다음주 쯤에는 debugfs 와 ftrace 를 좀 다뤄볼까 한다.
x201
efer_reload 0 0
exits 21069344 7769
fpu_reload 343718 131
halt_exits 610013 182
halt_wakeup 607199 182
host_state_reload 3896921 1734
hypercalls 0 0
insn_emulation 11012731 3564
insn_emulation_fail 0 0
invlpg 0 0
io_exits 1626895 295
irq_exits 2792742 1803
irq_injections 3095859 1043
irq_window 751003 347
largepages 0 0
mmio_exits 236148 142
mmu_cache_miss 617 0
mmu_flooded 0 0
mmu_pde_zapped 0 0
mmu_pte_updated 0 0
mmu_pte_write 768 0
mmu_recycled 0 0
mmu_shadow_zapped 151 0
mmu_unsync 0 0
nmi_injections 0 0
nmi_window 0 0
pf_fixed 453204 291
pf_guest 0 0
remote_tlb_flush 4229 3
request_irq 0 0
signal_exits 0 0
tlb_flush 98370 0
X60s
efer_reload 0 0
exits 26034501 11228
fpu_reload 263912 114
halt_exits 635759 313
halt_wakeup 627670 300
host_state_reload 2122981 701
hypercalls 1506109 612
insn_emulation 9732899 3991
insn_emulation_fail 33 0
invlpg 919682 755
io_exits 1285485 295
irq_exits 1316557 512
irq_injections 2566135 1073
irq_window 1569275 632
largepages 0 0
mmio_exits 183976 89
mmu_cache_miss 640917 307
mmu_flooded 474976 220
mmu_pde_zapped 21224 0
mmu_pte_updated 1097462 593
mmu_pte_write 2064888 976
mmu_recycled 0 0
mmu_shadow_zapped 651775 310
mmu_unsync 1290 -1
nmi_injections 0 0
nmi_window 0 0
pf_fixed 6622083 3121
pf_guest 962307 325
remote_tlb_flush 1008772 549
request_irq 0 0
signal_exits 0 0
tlb_flush 2806257 1673
아오 자꾸 맥주마시다 어디갔냐고 난리라 여기까지 해야겠다..
(어제에 이어 마무리)
일단 어제 막판 췻기가 올라 욕으로만 난무되는 마무리였는데 다시 정정한다.
위 비교에서 봐야 할 부분은 mmu 와 tlb 부분이다.
이름만 봐도 알겠다시피, 메모리 관리를 담당하는 녀석들인데,
32비트에 VT 마저 지원 되지 않는 x60s 로써는, cache miss 비율이 높고,
pte 갱신이 잦으며, 메모리 내용이 sync 되지 않는 부분들이 많이 발생된다.
tlb 의 flush 도 자주 일어나는 이유는 context switch 가 잦기 때문인데,
문제는 이 과정에서 새로운 메모리 엔트리들을 할당하는 과정이 들어가고,
그로써 다시 또 오버헤드가 오버헤드를 불러일으키는 악순환으로 인해
가상머신이 정상적인 동작을 거의 못할만큼 느리게 동작을 하게 된다.
대략 실제 비교해본 결과 cpu 자체는 크게 차이 안났지만, 디스크 I/O 와 네트워크성능에서
5배가량 차이가 났었다.
게다가 Disk 조건을 writeback 으로 캐슁 하는 것으로 설정해 놓았더니,
Disk I/O 에 대한 연산이 더욱 높아져 오히려 x60s 에서 엄청 성능이 떨어졌다.
딱히 벤치마킹툴을 돌리기에는 너무 느려서 안돌렸는데, 나중에 한번 돌려봐야겠다..
결국엔 결론은 x60s 쓰다 새로 산 노트북에서의 성능덕분에 기분이 좋아졌다... 일 뿐이지만,
가상화 테스트나 기타 여러가지 커널에 대한 공부 및 테스트를 할 여건이 됐다는 점에,
의이가 있.....(데스크탑을사면더 좋았잖아?? ㅡ,.ㅡ:::)
Disk Cache 를 writeback 으로 하는것과, none 혹은 writethrou 로 하는것의 차이는 뭐..
대부분 알것이라 판단하고 설명 안하겠고...
스크린샷도 몇개 찍었는데 현재 갑자기 올리기가 귀찮을 만큼 스크롤이 늘어나버린관계로
패스하도록 하겠다.
어쨋든 노트북 새로 사서 좋고, 가상머신에 윈도우 잘 돌아서 좋고.... 64비트라서 좋고....
(흑...내 레츠노트는 아쉽지만 빠이빠이~)
'Skills > 가상화(Hypervisors)' 카테고리의 다른 글
| IBM Developerworks 의 KVM 관련 글. (0) | 2011.07.15 |
|---|---|
| virt-manager 및 가상화 관련 라이브러리들에대한 깨알정보 (0) | 2011.05.12 |
| vSphere 4 update1a (0) | 2010.04.15 |
| RHEV 이야기 두번째 (1) | 2010.01.12 |
| RHEV (RedHat Enterprise Virtualization ) (0) | 2009.12.14 |