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/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/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/System 2016.12.01 11:06

KSpliceOracle 에서 인수한 Live patching 솔루션이다.

현재 RHEL 의 Kpatch 나 Suse 의 KGraf 가 비슷한 역할을 하고 있지만,

오라클에서 KSPlice 를 인수함으로 인해 대체된 프로젝트들이고,

단연 KSplice 의 기능이나 편의성이 더 뛰어난 상태이다.

일전에 LWN 기사 중 Kernel Live patching 에 대한 번역글을 포스팅 했었는데,

기사중, Micro-conference 중 User-space Bootless patch 에 대한 문의가 있었고,

커널개발자들이기 때문에 모두들 그 부분을 무시하고 넘어갔었다고 전한 적 있다.

오라클은 2015년 부터 KSplice 의 User-Space Bootless patching 을 준비해 왔고,

2015년 Oracle Announce utube 에서 Larry Alison 회장의 소개가 진행된 적 있다.

User-space 패치 가능한 영역은, 물론, 보안에 관련된 패키지들에 한정된다.

어플리케이션 레벨은 패치 후 리부팅하면 그만이지 않나? 라고 생각하기 쉽지만,

의외로 많은 크고작은 기업들의 시스템 엔지니어들은 이 부분에 대해서

많은 머리숱이 고난을 받았었음을 기억해야 한다.

"네, 당신들이 신경안쓰고 있던 부분... 오라클이 합니다."

PS : 그래.. 광고성 성향이 강하고 오라클 빠돌이같은 느낌이 있지만,
     그렇다고 오라클 리눅스 쓰라는거 아냐..쓰지마, 안써도 돼...
     지금 고객들만으로도 난 충분하고 귀찮어... 더 안늘어나도 돼...
     일하기 싫단말야... 고객들따위는 개에게나 줘버................ 아, 내가 "개" 지 ㅠㅠ

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