Skills/mY Technutz 2018.02.22 13:27

와.. 대박... 일이 엄청나게 들어와..

공격적으로 오라클 리눅스를 장사하면 내가 쓰일만한 일이 있긴 하구나 하면서도

일이 이렇게 많아지면 개빡쳐서 아무것도 하기 싫어지는 현자타임같은게 온다는..

무튼, 요즘 핫하게 밀려들어오는 업무량 덕에 코어분석 일도 숭풍숭풍 막 쳐 들어오는..

이번에는 레드햇 커널 즉, Oracle Linux 에서 Cmompatibility 를 위해 제공하는

Redhat Compatible Kernel ( RHCK ) 와 관련된 커널 덤프 분석을 해주시겠다.

Technical Preview 이기 때문에 해당 부분에 대한 코드는

ASSERTCMP(op->state, ==, FSCACHE_OP_ST_DEAD);

로 수정되는 식으로 상황을 정리하는 코드가 추가된 것 같다.
( 수정된 코드 다운받거나 찾기 귀찮다! 바쁘다. 점심안에 써야한다 글을. )

물론 픽스는 해당 fscache 모듈을 사용하지 않도록 하거나,

( cachefilesd 데몬을 Disable 한다. )

ELSA-2017-0307 또는 ELSA-2017-0817 ( RHSA-2017-0817 대응) 에서 권고하는

kernel-2.6.32-696.el6 이후의 최신 버젼으로 업그레이드 하거나

6.8 GA kernel-2.6.32-642.el6 이하 커널로 다운그레이드 하면 된다고

Redhat 에서 이야기 하는 것 같다.

사실 개인생각으로는 커널 업그레이드를 해봤자 동일할것 같긴 해서

구지 필요하지 않다면 Cachefilesd 를 Off 하는게 더 좋을것 같다고 생각된다.

mount option 에서 fsc 가 생겼는데 이게 없으면 자동으로 fscache 가 활성화 된다고 하는 것 같다.

레드햇 이슈라 명확하게 솔루션 코드가 확인되지 않는 상태라 잘 모르겠으나

분석 방법이랑 워크어라운드 기입되 있음 이미 난 충분히 세계를 위해 기여한거시다...

'Skills > mY Technutz' 카테고리의 다른 글

Kernel Dump Analysis #17  (0) 2019.04.04
libfc: Update rport reference counting bug - 1368175  (0) 2018.03.29
Kernel Dump Analysis #16  (0) 2018.02.22
Kernel Dump Analysis #15  (0) 2018.02.19
Kernel Dump Analysis #14  (0) 2018.02.13
Kernel Crash dump Analysis - #13  (0) 2017.12.20
posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2018.02.19 13:18

저번 14 에 이어진 내용이라고 볼 수 있다.

지난시간 왜 시스템 커널 분석에서 fc_stat, fc_lport 에 집중했는지 나오는 부분이다.

이전 게시글에서와 동일하게 ffff880103e67a00  를 참조하는 부분에서 문제가 발생하였다.

따라서 fc_lport 에 관련되어 메모리를 사용함에 있어, 이미 해제된 메모리를 재참조하거나,

메모리 corruption 조건이 발생되고 있다는 것을 의미한다.

역시 저번 게시글과 같이 해당 코드에 논리적 오류나 Race condition 발생 여부,

Used-after-freed 현상에 대해서 더 살펴봐야 하는 상태이지만,

코드 상 특별히 문제될만한 부분은 발견되지 않았다는 점이 현 문제의 가장 큰 난관이다.

지금은 개발팀에서 in-house 로 동일 환경을 구성 후 재현테스트를 하고 있는 중이다.

이는 장비에 대한 특성 ( 펌웨어 문제 또는 하드웨어 관련 된 정보의 괴리 ),

즉 하드웨어 문제를 배제할 수 없는 의심스러운 부분이 있다는 것을 의미한다.



posted by mirr

댓글을 달아 주세요

Skills/Linuxworld 2017.04.26 04:02

나에게 흥미로운 내용이 또 한가지 있다면, 파일시스템 관련 즉, I/O 관련 이슈이다.

이것은 천상 System Engineer 인 나로써는, 성능에 가장 영향을 미치는 부분중,

튜닝이 가능한 부분을 살펴보게 되기 때문일 것이다.

기사 본문(아직 유료) : https://lwn.net/Articles/720675/

일주일뒤 확인하면 무료일듯...

--------

밑의 댓글들 중에는 Kyber 에 대한 벤치마크 결과가 있냐고 묻기도 하고,

그 결과로 8ms 에서 1ms 으로 줄였다는 메일링 내용도 있기도 하며,
( http://marc.info/?l=linux-block&m=148978871820916&w=2 )

이런 스케쥴러가 BTRFS 같이 별도의 내부적 IO scheduler 나 Thread procedure 를 갖는
환경에서 정상동작 할지 우려하기도 하며,

확실한건 아닌데, 성능이 더 좋게 잘 동작하는것 같다고 하는 답변도 달려있다.

언제나, 리눅스는 물론, 시스템에 대한 엔지니어링을 하면서 항상 땔 수 없고,

내려놓을 수 없는 부분이 바로 성능이라고 생각된다.

디스크 성능에 대한 이야기를 쓰면서,

한때, 가상화에 한참 심취했을때, Disk I/O 에 대한 스케쥴러를 Deadline 과 NOOP 으로 바꿔

상당한 이득을 경험했을 때의 기억이 새삼 떠올랐다.

그때 엄청 감동이였는데... ㅎㅎㅎ

아무튼 리눅스의 성능에 중요한 요소인, Memory Management 와

Disk I/O scheduler 에 대한 것은 언제나 놓지 않아야 한다고 본다.

일단 술한잔 마시고, 예정화랑 구지성 같은 몸매종결 연애인들 나오는 프로 하악대며 보다보니,

어느덧 네시다 ㅠㅠ 제길... 오늘 회사 못나갈듯...

놀러나가야 하는데 징징징....

*PS : 멀티큐 블록 레이어에 대한 참고기사 (공개)
*PS2 : BFQ 소개 , Kyber 소개


posted by mirr

댓글을 달아 주세요

Skills/Linuxworld 2017.02.26 00:33

최근 한 2주정도를 계속 게임과 미드에 몰입하던 터라 흥미로운 기사가 몇개 있었음에도 불구하고

그냥 '에이 제껴 어차피 일주일단위로 공개되는데 구지 내가....' 라는 마인드로 넘겨버리고 있었는데...

오늘은 좀 무료한 감이 있더라..(금방 질리는 게임불감증 ㅠㅠ)

그래서 그냥 여러가지 외국 기사들 보며 맥주나 마시던 중 Cgroup 내용이 있어서 살짝 소개하려고 한다.

-----

우리나라의 기라성같은 은둔고수들중에 가장 유명해진(?)
Full time kernel hacker 인 허태준님께서 메인테이너로 개발하고 있는 CGroup 에 대한 내용이라서
내가 실전에서 사용한지 너무 오래되서 가물가물한 지식임에도 불구하고, 다루어 보았다.

현재 커널개발에 대해서 상당히 여러부분에 걸쳐
다양한 변화 및 움직임이 일어나고 있음을 알려주기 위해서이며,
우리나라에선 혁신이란 말을 유행처럼 쓰지만,
외래문화를 바탕으로 두고 있는 사람들- 그냥 외국인 - 의 경우,
정말 필요할 때 자신을 깨부숴 갈 의향을 알리며 사용한다는 말임을
이해해야 한다는 것을 말하고 싶다.

맥주가 다 떨어져서 자야겠.......

원문은 : https://lwn.net/Articles/715051/
- 일주일 뒤 무료공개.

** 엮인글들을 읽어가는 재미가 쏠쏠하다는 점...
*** 태준님 짱이라는...


posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2017.02.06 19:01

가끔 커널소스를 받아 make config 또는 make menuconfig 를 해보면,

자신의 커널이 어떤 기능을 디폴트로 지원하고 있는지 확인 할 수 있다.

이렇게 보다 보면 커널 디버깅에 대한 기능들도 일부 얻을 수 있고,

어떤 기능들을 리눅스에서 지원하고 있는지  확인 할 수 있어 가끔 도움이 되곤 한다.

참고로 난 Memory debugging 을 좀 해볼게 있어 디버깅모드를 상당히 많이

Enable 시켜 Recompile 중이다. 특히 debugfs 와 sysfs, ftrace 의 기능들을 좀 더 추가했다.

( 사실 Perf 랑 DTrace 등을 이용해도 되는데 왜때문에? ㅠㅠ )

또한 사용된 리눅스 커널은 바닐라 커널이 아닌 오라클의 UEK2 커널이며,

호환성 등을 위해 Linux kernel 2.6.39 (Flesh-Eating Bats with Fangs) 와

3.0.60 sneaky weasel 을 믹스하여 개발된 커널로

컴파일되는 버젼은 2.6.39 로 컴파일된다.

이건 오라클 UEK2 의 최신 바닐라커널인 셈이다.


주 : 자주는 보지 말자 -_-

주2 : 원래 LWN 기사 관련 번역을 어제 작성하다가 다 날려먹어서 멘붕에 그냥 간단한걸로..

posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply 푸우

    좋은 정보 감사해요

    2017.02.06 20:40

Skills/Linuxworld 2017.01.29 22:01

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

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

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

----

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

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

posted by mirr

댓글을 달아 주세요

Skills/Linuxworld 2016.11.18 12:00

LWN 에 흥미로운 기사가 떠서 이야기 해 보기로 결정하였다.

http://lwn.net/Articles/706327/

기사에 대한 간략한 요약과 필요하다 생각되는 부분에 대한 개인적 설명

** Notes : Notes 나 괄호 형태의 글은 본인의 생각 및 의견을 나타냄.

기사명 : Topics in live kernel patching

Kernel Mainline 에서 Live patching 에 대한 기능을 추가하는 작업은 여러해 동안 이루어져 왔고, 마침네 4.0 커널에 기본적인 Live patching support 기능을 추가하여 배포하게 되었다.

문제는 이 Live patching 에 대한 Validation 매카니즘을 어떻게 구현하는 것이 옳을까에 대한 문제에서 시작된다.

이번 Linux Plumber Conference 2016 에서 해당 내용을 주제로 토론하였다.

이 글은 토론의 내용을 요약하거나 정리해서 알려주는 기사가 아니라, 라이브패치를 개발하는 개발자들이 나아가야 하는 방향과 해결해야 하는 과제, 극복과정 등을 중점으로 작성되었다.

---------

여기까지가 Corbet 의 기사를 설명한 부분이다.

아무래도 스크롤의 압박이 강하고, 복잡한 부분도 많지만, 사실상 상당히 간단히 설명한 부분이며, 해석에 오역이 있을 수 도 있다고 생각하지만,

상당히 잘 요약했다고 생각한다. (나말이야...난 잘 한거같다고... ㅎㅎㅎ)

약간 미국식 스크립트(코멘터리) 형태로 표현하긴 했는데 재미없을수도 있겠다..

그냥.. 패스... 귀찮아.. 일주일 뒤 공개되니까 그때 기사 읽어....미안 영알못이라 ㅠㅠ

그래도 요즘 보안이슈등으로 라이브패치에 대한 관심이 많아져서 흥미로운 기사라 오랜만에 포스팅한다

Oracle KSPlice 의 방식도 나중에 포스팅 해보겠다.. 끝

** Notes : 관련해서 이미 공개된 기사들 링크
- http://lwn.net/Articles/634649/
- http://lwn.net/Articles/658333/



posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2016.01.14 23:08

정말 백만년만의 글인가.... 하고 보니 작년 6월에 글 썼었네... ㅎ


일년에 두개정도면 많은거 같은데..


무튼 어느순간 일이 증가하고, 같이 일하는 사람들이 생겼다 없어졌다 다시 생기는 등


신경써야 할 것들이 많았던 터라 영 공부를 할 수 없었는데,


최근 회사 엔지니어들이 주고받는 메일링 리스트를 보고 다시 이쪽저쪽 들쑤시려고 하는 중...


메일링 리스트에 고객이 많은 메모리를 쓰고 있고, 어떤 이슈가 생겨서, kdump 설정을 통해 덤프를 떠


분석하려고 하는데 이게 자꾸 설정이 안된다는 것이다..


답변으로 오는 것들은 대부분 이것저것 crashkernel 값을 조절해 보라 정도...


그래서 살펴보았다 어떤 공식을 통해 해당 영역이 Allocation 되는지를 말이다.




여기서 내 결론은 일반적으로 crash kernel 은 전체 메모리를 완벽하게 다 뜬다고 볼 수 없으며,


Kernel 에 대한 영역을 위주로 커널이 갖고 있는 PTE 등의 Linked List 정보를 덤프한다고 볼 수 있으므로,.


물리적 메모리 양이 많이 있다고 해서 crashkernel 을 무턱대고 올리는 것이 아니라,


2G - 256M 를 기준으로  64M 씩 올려가면서 테스트 해야 한다는 것이다...


참고로 레드햇 기준으로는 2G-256M, 6G - 512M, 8G - 768M, 그 이상이어도 869M 넘지 않도록


권고하고 있다... ( 난 8G - 768 M 도 too much 하다고 본다.. )


이슈에 대한 추이가 기대되는 부분이다...














posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply BlogIcon k

    최대...768m...그정도면..1tb 메모리도이상없는듯...
    메모리보다는....장착되어있는..디바이스에 따라 차이를 보이는듯하네요...물론..메모리도 상관 있는듯...

    2016.01.15 18:56
    •  Addr  Edit/Del Favicon of https://seblog.mirr4u.com BlogIcon mirr

      드라이버 등에 영향을 받을 수 는 있죠, 문제는 100테라 넘는 애들에 대한 문제인데, 이부분에선 사실 글에서 언급하지 않은 copy_to_user 의 개선이필요하다고 보는거죠 이부분에서 memcpy 부분의 효율 개선이나 다른 방식의 improve 가 필요하다고 봐요.. OOM 이 발생했다는게 이슈니까요 ㅎㅎ

      2016.01.16 00:14 신고
  2.  Addr  Edit/Del  Reply BlogIcon k

    최대...768m...그정도면..1tb 메모리도이상없는듯...
    메모리보다는....장착되어있는..디바이스에 따라 차이를 보이는듯하네요...물론..메모리도 상관 있는듯...

    2016.01.15 18:56
  3.  Addr  Edit/Del  Reply Favicon of http://seblog.mirr4u.com BlogIcon 미르

    낚임.. 결국 800M 로 덤프 성공.. OOM 부분은 역시 각종 모듈이 영향을 준 것이긴 한데, kdump 에선 이를 위해 blacklist 라는 옵션을 kdump.conf 레벨에서 제공..
    이를 다 블랙리스트로 처리하고 dump 를 뜨면 충분히 떠진다는 점....

    2016.01.18 15:20

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

댓글을 달아 주세요

가상화 시스템에서 자원컨트롤에대한 신요소로 Linux Container 라는 녀석이 있다.


엄밀히 얘기하면 Full Virtualization 을 위한 메카니즘은 아니지만, 서버 가상화에대한


뚜렷한 효용성을 못느끼는 분들이나, 서버팜의 확실성에 대한 강한 신뢰를 내려놓지


못하는 불신으로 똘똘 뭉친 고리타풍(ㅋㅋ) 하신 분들은 한번쯤 보아둬도 좋을듯하다.



뚜구둥~ 쉽게 만들어 지었다..


템플릿은 입맛에 맞게 수정하면 되고, 간단하게 가상머신이 하나 생성되는 셈이니,


왜 이녀석을 사용하는게 좋은지 다들 알것이다.


구지 에뮬레이팅되는 가상머신을 설치하여 GUI 등을 이용해 구동할 필요 없이,


간단한 자원 할당을 통해서도 이렇게 가상머신의 역할을 수행 할 수 있다는 점,


그리고 실제로 가상화에 대한 개념 그리고 발전모습을 더 디테일하게 밟아 볼 수


있다는 점이 내가 LXC 를 보고 열광하며 글을 쓰게 된 이유임을 알린다..

( 사실은 CGroup 이나 BtrFS 등은 RedHat 에 찾아보니 이미 새로운 문서들이 있더라는 ㅠㅠ )


 - 예고편 2부

 2부에서는 실제 운용하고 모니터링하는 부분에 대해서 서술하겠다.


 Bridge 네트워크를 이용해서 외부와도 통신이 가능한 Container 를 만들고,

 VLAN 을 이용해 Segement 의 구분을 지은 통신을 하는 모습,


 컨테이너의 CPU 나 Network 등 리소스를 직접적으로 Controlling 하는 부분,

 그리고 몇가지 기타 유용한 LXC 커맨드들을 살펴보도록 하겠다..


빠이빠이~


posted by mirr

댓글을 달아 주세요