카테고리 없음 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/mY Technutz 2018. 2. 13. 23:40

이젠 뭐, 커널에 대한 덤프 분석이라기 보다는

CRASH tool 의 사용법과, 이슈에 따라서 분석을 진행하는 방법에 대한 Guide 가 되어가는 것 같다.

이전엔 주절주절 말을 많이한것 같았는데, 오늘은 주로 코드나 어셈의 흐름을 위주로 설명해 볼까 한다.

시스템이 갑작스럽게 코어와 함께 리붓되었단다.

참고로 현재 이슈는 다른 이슈와 연결되어 발생한 이슈로써,

아직 해결되지는 않은 이슈이며, fc_lport 의 값을 찾기 위한 이유에 대해서 밝히지 않고 있었다.

물론 이어지는 덤프분석이 또 있을 것이며, 거기서 이유가 밝혀질 것이다.

여기서 중요한 부분은 위의 로그에서 빨간색으로 표현한 두줄의 스택로그이다.

현재 의심되는 부분은 RBX 로 들어가는 메모리가 Corruption 되거나 used-after-freed 현상인데,

두줄의 로그를 보았을 경우 used-after-freed 가 되지 않을까 싶다.

이번 경우에는 확실히 used-after-freed 현상이 가장 가깝기 때문이다.

즉, 해제된 것을 다시 사용하거나, Double free race condition 등이 발생하고 있다는 것이다.

물론... 소스코드상에서는 아직 오류를 찾을 수 없는 상황이다.

보다 자세하고 큰 그림은 다음 분석을 통해 함께 그려보도록 하겠다.

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

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
커널이 지원하는 기능을 확인하는 습관.  (1) 2017.02.06
Kexec/Kdump 의 제약사항에 대해서  (4) 2016.01.14
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. 1. 8. 13:38


원문 : https://lwn.net/Articles/710545/

이번주 LWN 에서 내가 흥미로와 하는 내용중 하나인 메모리 관련 기사가 올라와 번역해 본다.


----

즉, 기존의 빠른 발전을 위해 여러가지 추가해 왔던 메모리 관리 관련 기능들을 예로 들면서,

25년이 넘은 만큼, 리눅스 개발 전반적으로 "더 나은 진화를 위한 한발 물러섬"

에 대한 내면적 리뷰가 필요한 시점임을 전달하고 싶었던 것이 아닐 까 싶다.

자세한 내용은 다음주 수요일 이후 공개가 되니 직접 살펴보기 바란다.

근데 이렇게 이야기 해주면 다들 알긴 아나? 좀 회의가 들어 요즘 -_-


posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2014. 3. 12. 15:47

Kernel Crash 분석 업데이트 하나 더.


일이.... 있긴있는데, 분석하기 좀 집중안되는 놈이라 다른짓 하고 있음..


(우선순위가 이게 더 높기에 하고 있는거다. 절대 우선순위 무시하는법 없다... )


백업용도로 사용하는 몇개 서버군들중 두대의 서버가 비 동시적 시간에 Crash 되어


리붓되었다는 것이 배경...



사실, 이 과정만 보아서는 igxbe 드라이버가 Invalid data 를 넘겨주었기 때문인지,

애초에 Kernel 에서 skb allocation 에 논리적 이슈가 있었던 것인지 알 수 없으나,


어찌되었든, 둘다 커널에 포함되어 제공되는 Internal 부분이고,


Shipped driver 이며, allocation 이슈이기 때문에,


커널 Defect 로 판단되어 업그레이드나 픽스가 필요 한 상황...


(실제로 UEK2 커널의 sk_buff allocation 부분을 보면, memory allocation 체크하는 부분이

더 간결하게 정리되어 있다. )


게다가 역시나 이녀석도 UEK R1 인지라.... UEK Release 2 로 업그레이드를


하라는 것으로 가이드 할 수 밖에 없었다..........


이번엔 좀 더 Advanced crash 사용법을 보여준것 같아서.....


별로 뿌듯하진 않은데, 어차피 알아듣는 사람은 안알랴줌에도 스스로  깨우칠 것이고,


깨우치려 들지 않는 자는 알랴줌에도 깨우치지 못할 것이기에....


"밥줄" 좀 품....막 confidential 위반이라고 머라카면,

( 아... UEK 소스라인이 문제되려나? 근데 별반 차이 없는데 Vanila 커널이랑 ㅋ )


"옴마~? 앙대욤"



2014/01/06 - [Skills/System] - Kernel dump analysis about the bug called as "devide by zero"

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



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

Kexec/Kdump 의 제약사항에 대해서  (4) 2016.01.14
Patch of Egypt timezone data - Urgent  (0) 2014.06.18
Kernel Dump Analysis - #11  (0) 2014.03.12
HAL 데몬 사용하기 (Simple)  (0) 2012.04.03
Enhanced Using Sar data collector  (1) 2012.03.18
Kernel Dump Analysis #10  (2) 2012.01.01
posted by mirr

댓글을 달아 주세요

Skills/가상화(Hypervisors) 2014. 3. 9. 15:26

오랜만에 또 테크니컬 노트를 올린다.


일단, 이 글의 아이디어는 N 모 게임회사를 다니는 System Engineer 박모 씨의


질문으로 인해 떠올라 작성된 글이다.


배경 :

Ubuntu 10.04 를 개발팀에서 요구하였으나, IBM X3XXX M4 장비의 LSI 드라이버를

인식하지 못해 Bare-metal 한 설치가 불가능 한 상황.


하지만 나의 배경은 Oracle Linux 를 이용한다...


준비물 : OL6, 맥주(킬케니) 12캔, 파파이스 포테이토칩, 하인즈캐찹!


앞서 설명했던 오라클에서 제공하는 템플릿을 사용하면, 매우매우 편하게


yum repository 에서 명시된 릴리즈 버젼을 다운받아 설치를 진행 해 준다.


OL6 에서 OL5 의 이미지를 돌리고, 그것을 chroot 환경으로 제공하겠다는 것!

( 참고로 사용된 OL6 host 는 OVM 에 가상화로 돌아가는 가상머신이다 ㅋㅋ )



오랜만에 포스팅 끝..


담엔 간단히 Kpartx 를 함께 이용해 이미 존재하는 vDIsk 의 내용을 확인하는 방법과,

LVM 복구를 하는 걸 간단히 작성 해 보도록 하겠음. 물론 지켜진적 한번도 없으나 ㅋ



2012/09/03 - [Skills/가상화(Hypervisors)] - 가상화 시스템에서 자원컨트롤에 대한 신요소! Linux Container - 1부


2012/09/09 - [Skills/가상화(Hypervisors)] - 가상화 시스템에서 자원컨트롤에 대한 신요소! Linux Container - 2부




posted by mirr

댓글을 달아 주세요

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

댓글을 달아 주세요