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