Skills/mY Technutz 2020. 4. 6. 16:35

Oracle Linux 7 의 RHCK 를 사용하는 고객인데, Crash dump 가 발생하여 분석을 요청했다.

그냥 넘어가려고 했는데 eBPF 를 사용중인 서버에서 발생한 이슈라 흥미를 갖고

한번 살펴보기로 했다.

재밌는건 위 bpftool 은 sosreport 를 수집할때 systemtab 에 의해 수행되는 명령이었다.

재현테스트를 테스트머신을 만들어 수행해 보았으나, 아무런 이상없이

정상적으로 수집되고, 값도 정상적이다.

또한 bpftool 명령이 설치되어 있지 않다면 sosreport 수행 시행되지 않는다.

현재 고객은 위에서 보다시피 seos 등 3rd party 모듈을 여럿 사용하고 있었고,

filesystem permission 등의 관리가 이루어지고 있었기 때문에,

보안모듈을 의심할 수 밖에 없는 상황이였다.

안타깝게도, eBPFOL/RHEL 7 에서 Technical Preview 로 제공되므로,

더 깊은 상태의 investigation 이나 패치는 제공되지 않는다.

보다 상위의 커널들 ( Kernel 4.x, UEK4/5 ) 에서는 security_ops 를 아예 제거했고,

기본적으로 보안체크를 거치지 않고 다른 방법으로 처리하고 있었기에

적용하기도 어려운 상태였다.

결국 임시방편으로 고객에게 3rd-party 솔루션에서 bpftool 를 사용하는지 확인 후,

사용하지 않고, 필요로 하지 않는다면,

해당 패키지를 삭제하고 사용하지 않도록 하라고 권고하였다.

해당 패키지 (bpftool) 삭제 후 현재까지 이상없이 잘 운영중으로 보인다.

** Notes : 사실 Herbert 나 Todd 등 유수한 개발자님들께서 Technical Preview 라 귀찮다고
             코어덤프 거들떠보지도 않으셔서 상당히 어렵게 확인함 ㅋ

posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply Favicon of https://cuzmall.com/스포츠-레저/조아캠프-캠핑테이블-120-전용.. BlogIcon 조아캠프

     

    2020.06.14 03:37

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

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

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

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

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

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

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

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

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

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

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

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

posted by mirr

댓글을 달아 주세요

Skills/System 2020. 3. 23. 21:29

메모리의 사용량 그리고 메모리의 어느정도 사용시 Swap 이 발생하고

이 비율을 어떻게 조절하는지에 대한 인터넷사이트나 페이지, 문서는 상당히 많은데,

막상 다소 잘못된 내용들이 너무 넘쳐나는 것 같고, 제대로 짚어주는 사람은 아무도 없어

글을 급하게 쓰기 시작한다.

사람의 인체와 마찬가지로 컴퓨터의 CPU 와 메모리라는 것은 상당히 복잡한 영역이다.

따라서 단순한 계산으로 쉽게 계산할 수 있는 방법은 존재하지 않는다.

결국 그때 그때의 사용정도만 종합적으로 보여준는 것이 다들 알고 있는

Free, top, mpstat, vmstat 등 의 명령인 것이다.

그 값에 의심을 갖지 말고 그냥 좀 믿자 .. 뇌피셜이 많아질수록 꼰대가 된다..

다시한번 결론!

Swappiness 가 0 으로 설정되어 있다고 해서 스왑을 안쓴다는건 아니다. 명심하자.

* 읽으신분들이 쪼금 되서 급하게 추가 :
"Swappiness 를 그럼 언제 쓰란 말이냐"

** File-backed 관련 테스트를 위한 간단한 Python code.
( file 은 dd if=/dev/zero of={filename} bs=1024M count=XXX 로 생성 )

#!/usr/bin/env python

import sys
import os

if len(sys.argv) != 2:
    print "usage: %s <file-name>" % sys.argv[0]
    sys.exit()

pid = os.getpid()

f = open(sys.argv[1], "r")
size=f.read()

print ("File read test (%d) : %s read - %dM") % (pid, sys.argv[1], len(size)/1024**2)

while True:
    pass

테스트를 할때 여러조건으로 중복으로 실행하며 테스트 해보시면 좋다..
(난 귀찮아서 ㅠㅠ)

*** 관련 하여 회사 Mailing List 에서 커널개발팀 답변 :

Also we *very strongly recommend* not setting vm.swappiness=0. That can
result in some corner cases where the system has sputtering hang-ups
when it finally does have to swap for some reason.

Unless oswatcher is showing major %so/%si (swap-out/in) activity, it's
not having any impact on system performance, so if the underlying
question is about performance, you're probably looking at the wrong thing.

Swappiness 가 메모리를 더 적극적으로 활용하도록 하는 것은 맞지만,

Pinch 상황 즉, 시스템 부하가 높아지는 상황에서는 심각한 서비스 영속성 ( service continuty )

손상시키는 결과를 불러올 수 있다는 점을 경고하고 있다.


posted by mirr

댓글을 달아 주세요

Skills/System 2020. 2. 5. 15:20

한국은 별로 이슈가 없는데,

글로벌에서는 Oracle Unbreakable Linux Network ( 이하 ULN ) 에서 제공하는 패키지관리를

미러링하여 내부에서 사용하는 환경이 많다.

이를 위해 오라클에서는 ULN 에 등록된 서버프로파일에 yum server 로 사용하는지 확인하여

해당 채널 패키지를 미러링하는 서비스도 제공하고 있는데, 간단하게 해당 방법을 알아보도록 하겠다.

1. Prerequisuites

 - Oracle Linux 6 (x86_64) or later
- linux.oracle.com 와 linux-update.oracle.com 에 http/https 접근이 가능해야 한다.
- 당연하게도 Oracle Linux CSI (customer support identifier).

- ULN site 에 등록된 Oracle SSO ID
- 메타데이터 생성을 위한 최소 2G 이상의 공간과 6G 이상의 RAM

- Package 들을 저장하기 위한 충분한 저장공간

- 끝

posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2019. 12. 13. 17:44

요즘 다시 혼자서 근무하다보니, 업무량이 훅 늘어나고

분석에 대해서는 반복적인 부분이 많이 발생하는데 그에 대한 시간은 여전히 동일하게 들어서

간편화 하는 방법이 없을까 해서 간단히 python 으로 crash utility 에 대한 extension 을 직접 만들고 있었는데,

하늘아래 새로운 것은 없듯이 역시나 이미 만들어져 있었다는 것을 발견하였다.

그것은 바로 mPyKdump 라는 crash extension 이다.

https://sourceforge.net/p/pykdump/wiki/Home/

일단 커널 코어덤프 분석을 위한 도구인 crash 툴은 C/Python 형태의 외부 스크립트를

내부에서 불러와 사용할 수 있다.

대부분 c 로 컴파일되어 모듈형태로 crash 툴이 실행된 후 로드하는 형태로 사용되는데

mPyKdump 는 파이선 기준으로 작성되어 내용을 수정하더라도 특별히 컴파일이 필요없이

바로바로 적용이 가능하다는 장점이 있었다.

해당 모듈을 이용하여 얼마나 간편하게 기존 삽질을 줄일 수 있는지 확인해보자.

(Host정보 삭제함)


여기까지 PyKdump 모듈의 기능에 대해서 살펴보았다.

이제 커널정보들도 상당히 공개되고 알려져 먹고살기 참 힘든 세상이 되었다.

추가 팁 : 자동으로 mPyKdump 모듈을 로드시키고 싶을 경우,

.crashrc 파일을 만들어 아래와 같이 넣어주면 실행시 자동 로드한다.

.crashrc 는 크래쉬 툴 명령명과 동일하게 만들어 주면 된다.
(.crash64rc 와 같이.)

# cat ~/.crash64rc
extend /usr/local/lib64/mpykdump64.so


posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2018. 3. 29. 13:31

결국 같은 이슈였다.

내가 전에 올렸던 Kernel Dump Analysis #14 / #15 두개의 이슈..

결국 #15 와 #14 모두 동일한 rport reference count 관련 race condition bug 였다.

비록 양상이 다르긴 했지만 모두 Kref 를 감소시키며 0 으로 만드는 과정에서

Race condition 으로 인해 다른 메모리 값을 참조하게 되는 버그였다.

아래는 해당 버그에 대한 Patchwork (GIT) 링크 이다.

https://patchwork.kernel.org/patch/9132823/

대략 reference count초기화 하는 과정에서 Mutex lock 을 걸어

Violation 을 방지하려고 했는데, 매 타임마다 Locking 을 하고 그 값을 대기하다보니

대기시간중에 다른 스레드가 해당 구조체에 엑세스 할 기회를 만들어주게 되어

결국 해당 값이 바뀌어 버리는 일이 생길 수 있다는 것이고, ( Race condition )

이 과정을 단순히 Remote port 에 대한 참조카운트를 추가하여

해당 값을 Lookup 할때 (디스크 제거시에만) 참조값을 줄이면 되기 때문에

디스크를 제거/검색 하는 과정에서 매번 디스크 뮤텍스를 걸 필요가 없게 수정한 이다.

개 빡치는것은, 내가 분명 두가지 모두 최종 Call trace 는 다르지만 모두 libfc 모듈에서

fc_lport / fc_rport 관련 구조체에 대한 Referencing 에서 나오는 이슈이므로

동일한 것같다고 이야기 했지만,

커널 개발팀에서 계속 "아니다, 다르다, 재현해서 다시 살펴봐야 한다" 라고 우기는 바람에

고객이 너무 빡쳐서 "그냥 다 때려쳐 씨밤, 너네 구려!" 이랬다는 것...

졸라 중요고객이라고 지랄들을 해대서,

어떻게 해야 할지 몰라 냅뒀더니 두달이 지난 지금에서야

We are unable to reproduce the crash in QA setup which is often hard to do because it is not possible to replicate customer environment in the lab.
However, The two core dumps even though showed different symptoms, but the underlying root cause is the same, the kref count being zero. 

Rajan provided the Ksplice patch and rpms which has the fix to address kref handling.

'응 그래, 재현이 졸라 안되서 미안하지만...그래도 동일 이슈맞는것 같아

우린 이미 앞선 패치를 통해 솔루션을 제공했어. 우린 잘했다고'

이지랄을 떨고 있다.

개발자들 일안하냐? 내가 호구로 보이냐? ㅎㅎㅎㅎㅎ 아몰랑!


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

kernel Dump Analysis #18  (0) 2019.05.11
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
posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2018. 2. 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. 2. 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. 4. 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. 4. 5. 00:24

이번달은 거의 LSFMM summit 내용이 무지막지하게 쏟아져 나오고,

내가 관심있어하는 내용들이기 때문에 잘 따라갔어야 했으나,

너무 쏟아저나오는 나머지... MM 쪽은 도저히 따라갈 수 가 없어,

그중 가장 논의를 할 만한 흥미있는 기사 하나만 잡고 끊을 놓치않기 위해 안간힘을 써 본다.

논의할 사람이 너무 없다.. IT 진짜 사람 너무 없다.. 다들 좀 지원안하나?

밥짓기 3년 빨래 3년 청소 3년만 하면 나랑 말이 통할거 같은데...
( 농담같지만 진담이다. )

기사 제목은 Container-aware Filesystems 이며, 구독자 전용이라..

공개여부는 잘 모르겠다. 일주일 뒤 한번 보시라...
( https://lwn.net/Articles/718639/ )

-----

----

여기서 내가 궁금하고 흥미로운 건 말이지... 이게 정말이냐? 라는 것이다.

DevOpser 들에게 묻는거다.. 도커나 컨테이너 많이 쓰는 ... 많이들 쓴다며?

난 쓰는애들 제대로 본적이 없어서 묻는건데, 이런 권한문제들을 다들 어떻게 처리하고있는지 ...

이런것도 모르면서 우리나라에서 데브옵스를 해야한다 어쩐다 할 수 있을까? 라는 걱정이 들었다.

다들 어떤 방식으로 Unprivilege 의 파일시스템을 사용하고,

왜 필요한지 논의해 보면 좋겠다.

일단 여기까지 쓰고 나니 한 30분정도 걸린거같다... 술이 취해서 더이상 글을 보기가 싫다 -_-


posted by mirr

댓글을 달아 주세요