카테고리 없음 2020. 4. 3. 18:36

아주 따끈따끈한 이슈를 발견해서 포스팅한다.

고객이 OL7 에서 kdump 테스트를 수행하는중, ext4 등 다른 파일시스템으로 저장이 되는데

별도로 연결한 xfs 파일시스템에는 저장이 되지 않는다는 문의를 해왔다.

"그럴리가 있남? 뭔가 잘못한거겠지 흥칫뿡" 속으로 생각하며,

직접 테스트를 하는데... 저장이 안된다...

"뭐지?" 하면서 살펴보기 시작한다.

이건 레드햇에서도 아직 답이 안나온  따끈따끈한 워크어라운드인것 같다.

혹시라도 OL7 에서 별도의 XFS 에 덤프를 저장해야 하는 경우, 해당 워크어라운드를 적용하도록 하자.

당연히 기존 루트 파일시스템에 저장하는 경우는 fsck 가 앞서 수행되므로 상관없이 잘 된다.

물론 환경에 따라서 sleep time 의 값이 더 필요할 수 도 있을것 같은데,

대부분 5~10초면 무난하지 않을까 싶다.

posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2016. 1. 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/System 2014. 1. 6. 14:17

자 막간을 이용해 간만에 kernel core dump 분석 들어간다...

사실 요즘 대박대박 대박사건으로 여러 사이트에서 터지고 있는 문제라,

뭐 보안이 필요한 부분인것도 아니고, patch 가 어차피 나와있으므로
( kspice 를 이용한 hot fix 이긴 하지만..)

과감하게 공개해 본다....



현재 Fixed kernel 버젼은 V2.6.32-400.34.1 이며, 아직 QA/Release ready 이다.

어렵다.. 아무튼, 해당 패치는 나와 있는 상태이지만, 릴리즈 된 각 커널마다,
또한 장비상황등등 마다 재발 가능성은 언제든지 있는 부분이기 때문에,
최신 official released kernel 로 업데이트 한후, ksplice 를 통한
추가적인 hot fix 를 적용해야 한다는 점!


ksplice 를 이용하면 커널에 대한 official release 가 나와있지 않은 상태에서,
리붓 없이 수정된 kernel space 로 교체, 사용이 가능하다.. 쯔앙!


끝. 짧고 간단하며, 일이 있는 상태에서도 이정도 글은 뭐.. 가능하다 ㅠㅠ
비슷한 이슈 보이는 Oracle Linux UEK 커널 사용자는 업데이트 꼭 하도록 하자.


2012/01/01 - [Skills/mY Technutz] - Kernel Dump Analysis #10


posted by mirr

댓글을 달아 주세요