Skills/Linuxworld 2017. 1. 29. 22:01

이번 기사는 올해 열린 linux.conf.au 2017 의 발표 중 페이지 캐쉬의 미래에 대한 기사.
(유료컨텐츠..1주일 후 공개 열람 가능)

https://lwn.net/Articles/712467/

대규모의 persistent memory 에 대한 보장을 위해서는 많은 부분의 변화가 요구되었었고,
커널에 대한 페이지 캐쉬 기능이 계속 필요로 하는 부분인지에 대한
의문이 제기되었다고 한다.

----

무튼 기자 Corbet 의 윌콕스에 대한 감정은 썩 좋지 않은 것 같은 뉘앙스였지만,
페이지캐쉬와 그 동작에 대해서 상당히 많은 이해를 주는 기사 및 발표였다고 생각한다.

"코딩상의 문제라면... 알아서 해결하면 되겠네 ㅎㅎㅎㅎ"

posted by mirr

댓글을 달아 주세요

Skills/Linuxworld 2012. 10. 21. 05:11

기사 원문 : http://lwn.net/Articles/517465


이건 이달 초에 발간된 위클리 매거진에 실려있는 기사인데, 이미 공개된거라 여기에 쓸까말까


고민하다가, 어차피 남들이 보는것도 좋지만, 사실 내 공부가 더 중요하기 때문에 블로깅하는것이므로,


부끄럼없이 다뤄보기로 하겠다.. 물론 Transparent Huge Pages 를 먼저 다뤄야 좋겠지만,


이건 조금 더 복잡한 내용이 필요하므로 그 Huge Page 의 성능적 이슈를 해결하기 위해 나온,


Huge Zero Page 컨셉에 대해서 먼저 간략하게 알아볼 것이다.



코멘트들을 보면 재밌는게, KVM 같은 HugeTLB 를 사용하는 환경에서 HZP 로 인한 잇점과,


벤치마킹이나 PoC 등 몇몇 프로세스 테스팅등에서, HZP 로 인해 프로그램 코드의


특별한 수정 없이 퍼포먼스에 큰 향상을 볼 수 있었다는 얘기도 있다는거..

내 생각에도 이 Huge Zero Page 는


특히나 가상화 및 대용량 In-memory DB 의 발전을 위해서라도 반드시 사용되어져야 하는


기능이지 않을까 싶다..


솔직히 HZP 를 얘기하기 전에 우선 Zero Page 에 대한 더 상세한 설명과,


또한 Transparent Huge Page 나 TLB 에 대한 상세 설명이 필요하긴 했으나,


내 생각에는 늦은 커널 공부에는 작은기능부터 거꾸로 올라나가서, 왜 이 기능이 나타나게되었고,


이 기능들을 필요로한 핵심 매카니즘이 어떤건지에 대해서 거슬러 올라가는것이,


그나마 가장 나은 방법이라고 생각하기 때문에, HZP 에 대해서만 얘기해 보았다.


PS. Transparent HugePages 에 대한 것은 2011 년에 이미 Corbet 에 의해, 커널문서로

작성되어있고, 관련된 파라메터들도 잘 설명되어 있다...

기회가 되면 이것에 대한 실제 벤치마킹등을 이용한 테스트도 포스트 해보고 싶다.


PS2. 아마 다음포스팅은 정말로 HugeTLB 에 대한 글이 되야 할것 같다.

회사 Product 도 연관된 부분들이 많아서 ( 특히 Middleware 나 DB )


PS3. 사실 부족한 이해력으로 LWN 기사만 보고 즉석테스트 정도로만 해서 정리한 글이므로,

언제든지 잘못 이해한 부분이 있으면 지적질 좀 해주라고.. 제발..


기사 원문 : http://lwn.net/Articles/517465




posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2010. 9. 29. 20:13
병가받고 한달 뽀지게 쉬는중인데 중간중간 대전같은데 끌려가서 일하고 있느라,

나름 또 바빠버려서 정말 관심있는 커널 MM 에 대한 공부가 중단되었었다..

정리하는 셈 치고, 또한 최근 P 모사에서 OOM killer 가 동작되버려 kdump 조차 안된 상황(?)을 보니,

급 급해져서 살짜쿵 내용좀 정리해 본다...

사실 올 초반부터 OOM killer 의 성능을 향상시키기 위한 수 많은 토의가 있었다..

시작은 fork-bomb 를 검색하는 것에서 시작하였으나, 용자 'David' 의 주도로 인해,

반지원정대 못지않은 큰 여정이 되어버렸다...

AndrewDavid 의 패치를 검토하고, 또 싸우기도 많이 하면서 결국 2010-6-11 자로

패치를 적용시킨다... 이 패치에 대한 스토리와 내용은 너무 길고 길어서 여기서 단순간에 쓰기엔 어려우니

다음으로 미루도록 하고, 다시 말하지만, 내가 나름대로 연구해본 OOM killer 의 동작 과정에 대해 보기로 한다.

코드를 설명해야 하는 것을 최대한 배재하려고 하나, 나역시 프로그래머라고는 할 수 없는

시스템엔지니어일 뿐이기에, 좀 꼬일수도 있을것 같다... 대충 보자.. 쿨럭


위와 같은 함수와 동작 원리를 알고 이제 깊이 파다보면, background reclaim, direct reclaim 등이 있고,

reclaim 중에서는 또 write back 등 I/O 관련되는 것들이 주루룩 나오고,

그 전에 일단 커널 메모리 매핑이나 vm 매핑........ 엄청 쏟아진다... 머리 깨지며,

한달 동안 이것만 붙잡고 밥안먹으면서 살아도 모르겠다 ㅠㅠ

아참 참고로, 6월 적용된 패치로 인해 앞으로의 커널에서의 움킬러의 동작 방식.

즉, 메모리 reclaim 등에 대한 일부 부분들은 바뀌게 되었으니 참조로만 알아두길 바란다.

PS. 사실 내가 공부하면서 이해하고 있는 부분을 재정리 한 글이기때문에 부족함이 많을 수도 있다..

가르침 주실 분들은 언제든지 가르침 주시길 희망함 :)

스프링노트에 다시 좀 정리해서 플로우별로 정리했다...

http://mirr.springnote.com/pages/6484805

posted by mirr

댓글을 달아 주세요

Skills/System 2010. 3. 5. 01:14
본 글은 스스로에게 어디까지 기술력을 보유해야 한다고 생각하는 건지 자문하는 글로써,
정리되지 않던 글들은 다시 정리하여 공개합니다. 문제가 되는 부분들은 언제든지 얘기해 주십시오.

말 그대로, 시스템 엔지니어로써 갖춰야 할 기술력은 어느정도일까??

2월 3일부터 모 사이트에서 발생한 장애로 인하여, 2월 한달 내내 사람이 살듯 살고있지 못했다. ㅠㅠ

가상화 위에 올라가 있던 RHEL3 (kernel 2.4 smp - 16G) 시스템이 아무런 이유 없이 Hang up 에 빠진것.

우리측의 초기 대처는 일단 전반적인 시스템 메시지 및 로그를 살펴 보는 것..

메시지는 갑자기 파워오프된 서버들에서 흔히 볼 수 있게, 특별한 메시지 없이 뚝 떨어져 있다가,

restart 되는 것들만 있었고, sar 데이타 역시 특별한 이상유무를 찾을 수 없을 정도로

자원 상황은 원할한 상황이였다.
( 특별한 로그가 없이 죽으면 정말 난감할 수 밖에 없다 )

가상화 측 분석 요청도 한 상태였는데, 가상화측에서는 아무런 메시지가 남겨져 있는게 없다는 말...

결국 발칵 뒤집혀 지기 시작했다. OS 측의 문제인 것 아니냐는 식으로 몰려가기 시작한다.

sar 데이타는 디폴트 10분이기 때문에 물론 정확하지 않다는게 맞는 말이긴 하지만,

이 상황에서 장애 원인을 찾기란 힘든 상황이었다.

고객이 설정들을 직접 살펴본 결과, threads-max 커널파라메터가 다른 일반 서버들보다 낮게 설정되어

62327인가 라는 값으로 올려논 상태라고 하였고, 그 후로 모니터링 중이라고 하였다.

이차 분석을 하려고 방문 한 날, 고객측에서 테스트 (장애재현) 를 하게 되었고,

몇가지 간단한 시나리오를 바탕으로 테스트에 들어갔다.

주요 테스트는 단순한 Thread 생성 테스트를 통한 부하 테스트..
( sysrq 로그나 응용프로그램 로그등에 찍힌 fork(): not allocate memory 뭐 이런 로그로 인하여 )

테스트 프로그램을 실행 시키자, 순식간에 서버가 뻗는다.

아하 이거구나! 라고 생각한 전부는 threads-max 의 적절한 값을 정하지 못해서 그런것으로 판단,

R 사 에 문의 하기로 한다. ( 그상황에서 VMware 와 Diskdump 의 지원문제로 netdump 설정 함 )

간단한 R 사 의 답변은 SMP 커널의 경우 메모리가 어느정도이든,

프로세스나 스레드 생성을 위해서는 1G/3G 스플릿 모델에 의해 1G 영역에서 관리할 수 있게 되고,

소스상의 최대 생성가능 수는 32000 개로 정해져 있다는 것.

고로 이 시스템에선 1G / 8 * (8192/4096) = 14336 이라는 것. ( default threads-max 값 )

가상화 이전엔 Hugemem 이였던 시스템이였으나, VMware 의 hugemem 미지원으로 인해

smp 를 사용 하였다는 정보 추가. ( smp = Max 16G Ram ).

뭐, 결국 원점이 되버린건데, 장애의 원인은 결국 못찾았다는것이다.

그래서 다시 테스트를 해 보았고, 테스트 시점에서 netdump 와 sysrq 를 통해 core dump 를 받아

R 사 에 다시 문의 하였다.

R 사 에서 돌아오는 답변은 간략하게, 정확히 행업상태의 덤프가 아니라, 스냅샷식의 덤프라 의미가 없다는것.

분석 내용에서는 메모리가 부족하여 Hang-up 으로 보였을 뿐 Hang-up  은 아니라는 것이였다.

아차.. 그럴 수도 있었겠군... 그러나 몇일 뒤 다시 Hangup!! 게다가 netdump 문제로 not dump...

대략 여러가지 살펴보았고, 또다시 뜬 메모리 부족 및 fork 에러를 기반으로 다시 시나리오를 작성.

문제는 메모리할당이나 스레드 등등 이지 않을까 싶어 R 사 엔지니어 방문요청! 테스트를 해보았다. (와우~)

- 계속 -

posted by mirr

댓글을 달아 주세요

Skills/가상화(Hypervisors) 2009. 12. 14. 10:44
RHEV 즉 VMware 나 Citrix Xen 과 같은 KVM 기반 레드햇 하이퍼바이저 서버가

드디어 출시되었다. 물론 출시된지는 좀 됐지만....

일단 얼마전 싱가포르에서 열린 2009 Tech Summit 에서 발표를 대대적으로 했고,

RedHat 측에서 주력 상품 및 미래주도적 상품으로 밀겠다는 상품인데,

위에서 말했듯이 KVM 기반으로한, 최소한의 OS 를 RHEV-H (Hypervisor) 라고 하고,

이것들을 관리하기위한 RHEV-M (Management) 이 한 묶음으로써 RHEV 가 된다.

RHEV-H 야 일반적인 하이퍼바이저와 비슷한 모습이고, 설치 및 셋팅역시

기존 리눅스기반 아나콘다 설치가 아니라 간단한 TUI 로 메뉴를 선택하여 컨피그하면

자동으로 설치해 주는 모습을 갖고 있다.

VMware 에서밖에 구현되고 있지 않던 Memory Overcommit 의 구현이 가능해졌고,

HA, Dynamic Maintanance, 자원공유(Resouce Pool), LiveMigration, Snapshot, DPM 기능등

기존 가상화가 쌓아온 기술들을 모두 충족시키고 있다.

다만 VMware 에 비해 약간 아쉬운 점은, VMware 에 있는 Resource Pool 개념을 클러스터단위로

줄 수 있게 되어있고, 클러스터에서 사용되는 Resource Pool 은 Host서버 (물리적) 의 전체

리소스를 퍼센테이지로 분배하는 형식으로 되어 있었다는점.

( vSphere 의 경우 MHz 및 MB 또는 GB 단위로 세세하게 설정 가능 )

어쨋든 Direct I/O 등의 기술들이 적용된 커널의 패치역시 성능면에 있어서 대단하다고 볼 수 있었고,

모든 관리기능을 웹으로 구현하여, history 및 작업의 검색 등도 웹브라우저에서 편하게 할 수 있는점이

매우 매력적이였다.

단지 아이러니하고 어이없던 점은 이것들 역시 매니지먼트프로그램이 있어야 기능 사용이 가능한데,

Windows 2003 R2 Sp2 영문 + MSSQL (Express가능) + Powershell + IIS + AD + DNS

구성이 이루어 져 있어야만 한다는 것이다.

추후에 AD 는 LDAP 으로도 대체 가능하도록 할것이라고 하는데,

쿰라넷을 인수하고 채 포팅이 되지 않은 상태에서 너무 성급하게 시장에 제품을 내놓은건 아닌가

싶기도 했으나, RedHat 의 상황과 가상화 시장의 급진적 발전속도와 방향을 본다면

역시 어쩔 수 없는 선택이였거니 싶기도 한다.

어쨋든 가장 주목할 점은 역시 Memory Overcommit 기능으로써, 동일한 라이브러리 및 커널코드가

메모리에 적제될 경우, 코드를 비교하여 동일하다 판단 됬을 경우 실제 물리적 메모리의 주소를

하나로 통합하여 리드온리모드로 다른 VM ( Guest OS ) 에서 사용할 수 있게 하여,

그만큼의 나머지 물리적 메모리를 해제하여 좀 더 높은 통합비율과 성능을 보장해 주는 기능이다.

이게 왜 중요하냐면 특히나 서버 통합 ( consolidation ) 에서 투자비용등 TCO & ROI 의 문제인데,

Xen 의 경우 물리멤 4G 서버 하나에 Guest OS 들을 각각 1G 메모리씩 줘야 할 경우,

하이퍼바이저에 필히 할당되야할 메모리 때문에 ( 권장 1G 정도 ) 3 개의 VM 밖에 올릴 수 없게 된다.

이것은 일단 Guest 를 시작시킬때도 메모리 부족을 대비하여 동시에 실행 시키지 못하는 결과를

불러올 수도 있으며, 통합비율 자체도 3:1 의 비율로 현저하게 줄어들어 버리는 것이다.

결과적으로 서버 통합대수가 12대 일 경우 VMware 에서는 12 : 1 의 통합도 경우에 따라서 무리하지 않다고

하는 반면, Xen 의 경우에는 Host 서버(물리적)가 4대가량 필요해 질 수 도 있는 상황이 되버리는것이다.

이것은 MS 의 Hyper-V 또한 마찬가지이다.

하지만 KVM 은 리눅스 기반에서 커널과 함께 KSM ( Kernel Share Memory - 이름바뀔예정 ) 기능을 이용하여

메모리의 중복사용을 제거하였기 때문에 메모리 오버커밋이 가능한것이고, 이로써 VMware 에

가장 가깝게 쫒아 갈 기반이 생기게 된것이다.

( Memory overcommit 의 경우 동일한 OS 일 경우 효과가 최대화 되긴 하겠다. - 혹시몰라 설명함 )

물론 VMware 가 가상화 서버 시장의 정점에서 항상 새로운 개념과 새로운 기술들을 적용하고 선보이는

선두주자이긴 하지만, 역시 놀고만 있을 수는 없다는 것...

일단 RHEV 에대한 간단한 소개 만 하는 글로 시작되었기 때문에, 여기까지로 줄이겠고,

아직 가상화 서버들에 대한 할말은 많이 남아있고, 설명해야 하는 부분들도 많이 남아있다.

어쨋든 RedHat 쟁이로써 그리고 VMware 쟁이로써의 RHEV 에 대한 관심도와 기대치는 매우 높으며,

주목 할 수 밖에 없는 상품인 것이다...

끝으로 사족인데, RedHat 이든 VMware 에서든 Xen 은 경쟁대상으로도 안보더라. Overcommit 때문에 ㅎㅎ


posted by mirr

댓글을 달아 주세요