sejong.jeonjo@gmail.com

작성일: 2024년 12월 10일

Segmentation fault (core dumped)

분명 process가 segmentation fault 상황에서 core file이 dump되어야 하는데, 어디에도 core file이 없는 경우가 있다.

이럴 때는 coredump와 관련한 설정이 안 되어 있는 것이니까, 아래의 내용을 보고 coredump 관련 설정이 잘 되어 있는지 다시 확인해봐야 한다.

core dump file의 size 제한 설정이 있는지 확인

너무 큰 core dump file이 생성되는 부작용을 막기 위해 core file size limit 설정이 존재한다.

(2020년대 이후로는 SSD, HDD가 충분히 커서 이런 core file size limit이 유용한지 모르겠다.)

core file이 수십개가 dump되어도 문제 없을만큼 storage가 크다면, unlimit 설정값으로 바꾸는 것을 권장한다.

## 현재 설정값 확인하는 명령.
$ ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) unlimited
data seg size               (kbytes, -d) unlimited
... (내용 생략) ...

## core file size 제한을 푸는 명령 (무제한 크기로 변경)
$ ulimit -c unlimited

위와 같이 설정하면, 내 login shell 환경에만 즉시 적용되고  Linux 시스템 전체적으로는 아직도 옛날 core file size가 적용된다.

따라서 Linux 시스템 전체에 설정 값을 적용하려면 아래와 같이 limits.conf 파일을 수정해야 한다.

$  cat  /etc/security/limits.conf
(... 중간 내용 생략 ...)
*      soft    core      unlimited
(... 중간 내용 생략 ...)

core file 이름 패턴 및 경로 설정

core file이 어느 폴더에 저장되고, 어떤 이름으로 저장될지 설정해야 한다.

$ cat /proc/sys/kernel/core_pattern
/tmp/core.%e.%p.%h.%t

각 설정값이 의미하는 것은 이렇다.

• %e   프로그램 이름 (실행 binary file name)
• %p   Process ID (예: 3453)
• %h   Host name (예: mynode)
• %t    core file dump된 시각 

위와 같이 설정하면, 아래와 같이 실제로 core file이 /tmp 폴더에 dump된다.

$ ls /tmp/core.*
/tmp/core.myapp.104618.mynode.1733790395

위 파일 이름에 포함된 "1733790395" 값은 Unix time(또는 epoch time)라고 한다.

이 epoch time을 우리 눈에 익숙한 포맷으로 바꾸려면 아래와 같이 명령을 수행하면 된다.

## Timezone 설정이 UTC이면, 아래와 같이 출력 
$ date -d @1733790395
Tue 10 Dec 00:26:35 UTC 2024

## Timezone 설정이 Asia/Seoul이면, 아래와 같이 출력
$ date -d @1733790395
Tue Dec 10 09:26:35 KST 2024

epoch time 및 date 포맷 변경에 관한 자세한 내용은 아래 블로그 글을 참고

https://andrewpage.tistory.com/193

작성일: 2024년 12월 10일

대화형 방식으로 gdb 명령 사용하기 (interactive mode)

## 현재 실행중인 프로세스 '1234'에 attach하기 위해 아래와 같이 명령을 실행
$ gdb -p 1234

## 프로세스 '1234'의 모든 thread 목록을 출력
$ info thread
... ( 출력 내용 생략 ) ...
... 모든 쓰레드 정보가 출력됨 ...

## 전체 thread 중에서 thread '5'의 정보를 보기
$ thread 5

## thread '5'의 backtrace 정보를 출력
$ bt

batch 방식으로 gdb 명령 사용하기 (non-interactive mode)

gdb 명령을 batch 방식으로 사용할 수 있다. 

아래 예제처럼 2개의 gdb 내부 명령을 사용하고자 할 때는 '-ex' 옵션을 2번 사용하면 된다.

이렇게 하면, -ex 옵션 순서에 따라(즉, 왼쪽에서 오른쪽으로 순서에 따라) 명령이 차례대로 수행된다. 

$ gdb -batch -ex "info thread" -ex "thread apply all bt" -p 1234

위 예제의 경우,

  - 전체 thread list를 출력하고,

  - 각 thread의 call stack을 출력한다.

작성일: 2024년 11월 17일

내가 eBPF, XDP의 네트워크 패킷 처리 성능을 측정하다가 목표한 성능 값보다 낮게 나와서 다른 사람들은 얼마나 성능이 나오는지 궁금해서 찾아본 자료이다.

다른 사람들이 테스트한 eBPF 성능 측정 값을 보면, 꽤 좋은 수치가 나온다.

내가 너무 구형 장비에서 테스트한 것이 성능 저하의 원인인 듯하다.

(아래 cilium이 구성한 HW 장비보다 7년 정도 더 오래된 CPU를 사용했음 ㅠㅠ)

https://cilium.io/blog/2021/05/11/cni-benchmark/

네트워크 처리 성능을 끌어올리기 위해 eBPF, XDP를 사용하는 것에 대해 의심할 필요는 없어 보인다.

작성일: 2024년 11월 13일

Intel Xeon CPU의 다양한 제품 라이업을 보면, 어느 제품을 구입해서 써야 할지 막막할 때가 있다.

이럴 때, 각 CPU 모델의 성능 측정 값을 알면 딱 좋은데, 다행스럽게도 Intel이 제공하는 CPU 모델별 성능 정보 테이블이 있다. 

https://www.intel.com/content/dam/support/us/en/documents/processors/APP-for-Intel-Xeon-Processors.pdf

참고 정보

Intel은 MIPS 정보는 제공하지 않고 GFLOPS, APP 성능 지표만 제공한다고 한다. (아래 웹 사이트에 자세한 정보가 있다)

https://www.intel.com/content/www/us/en/support/articles/000057052/processors/intel-xeon-processors.html

작성일: 2024년 8월 14일

CPU 온도 모니터링

$ apt install lm-sensors

$ sensors-detect --auto

$ systemctl restart module-init-tools

$ watch sensors

프로세스 별 Network traffic 모니터링

$ apt install nethogs

$ nethogs eth0

$ apt install iftop

$ iftop -i eth0

작성일: 2024년 8월 14일

SSD, HDD 등 저장 장치에 대해서 Read, Write 성능을 측정하기 위해서는 dd 같은 명령어를 사용하면 성능 수치까지 나오지만

실제로 File copy를 하면서 실사용 환경과 같이 Read, Write 성능을 측정해보고 싶다면 아래 shell script를 활용해보는 것을 추천한다.

#!/bin/bash

fallocate -l 1G sample-big.file

CNT=0
while true; do
        CUR_DATE=`date +%4Y-%m-%d-%H-%M-%S`
        CNT=$(( ${CNT}+1 ))
        echo ""
        echo ""
        echo "============= TEST START ================"
        echo "Test time:  ${CUR_DATE}"
        echo "Test count: $CNT"
        START_TIME=`date +%s%N`
        cp sample-big.file sample-big-1.file
        sync
        END_TIME=`date +%s%N`
        INTERVAL_TIME_NANO=$(( ${END_TIME}-${START_TIME} ))
        INTERVAL_TIME_NANO_COMMA=$(numfmt --grouping ${INTERVAL_TIME_NANO})
        INTERVAL_TIME_MILI=$(( ${INTERVAL_TIME_NANO}/1000000 ))
        INTERVAL_TIME_MILI_COMMA=$(numfmt --grouping ${INTERVAL_TIME_MILI})
        echo "Total execution time: ${INTERVAL_TIME_NANO_COMMA} (nanosec)   ${INTERVAL_TIME_MILI_COMMA} (milisec)"
        BPS=$(( 1073741824*1000000/${INTERVAL_TIME_NANO} ))
        BPS_COMMA=$(numfmt --grouping ${BPS})
	echo "IO BPS: ${BPS_COMMA} (KBytes / Sec)"
        rm sample-big-1.file
        sync
        echo "============= TEST END =================="
        echo ""
        echo ""
        sleep 2
done

만약, Read, Write 부하를 더 많이 주고 싶다면 `fallocate` 명령으로 더 큰 사이즈의 file을 테스트하도록 하면 된다.
(위 코드에서 1G를 10G 또는 100G로 수정하면 됨)

위 스크립트를 실행하면, 아래와 같이 테스트가 되면서 출력물이 나온다.

$ my-run.sh

============= TEST START ================
Test time:  2024-08-14-10-58-10
Test count: 1
Total execution time: 1,400,259,865 (nanosec)   1,400 (milisec)
IO BPS: 766,816 (KBytes / Sec)
============= TEST END ==================




============= TEST START ================
Test time:  2024-08-14-10-58-14
Test count: 2
Total execution time: 758,501,406 (nanosec)   758 (milisec)
IO BPS: 1,415,609 (KBytes / Sec)
============= TEST END ==================

... 중간 생략 ...

여담:
내가 일하고 있는 연구소에서 사용중인 Ubuntu 18.04 장비 중에서 Linux 4.15.0-143-generic 커널 버전을 사용하는 모델만
SSD I/O와 HDD I/O 성능이 100분의 1 수준으로 떨어지는 증상이 있었다.
이를 쉽게 재현하기 위해서 위와 같은 Script를 만들었다.
위 IO 과부하 테스트를 해본 결과, 아래와 같은 Linux kernel version 들이 모두 IO 성능이 급격하게 떨어지는 현상이 있다.

4.15.0-136-generic   -> 정상
4.15.0-137-generic   -> SSD HDD IO 성능 저하 이슈 발생
4.15.0-138-generic   -> SSD HDD IO 성능 저하 이슈 발생
4.15.0-139-generic   -> SSD HDD IO 성능 저하 이슈 발생
4.15.0-140-generic   -> SSD HDD IO 성능 저하 이슈 발생
4.15.0-141-generic   -> SSD HDD IO 성능 저하 이슈 발생
4.15.0-142-generic   -> SSD HDD IO 성능 저하 이슈 발생
4.15.0-143-generic   -> SSD HDD IO 성능 저하 이슈 발생
4.15.0-144-generic   -> 정상

작성일: 2024년 8월 13일

특정 버전의 Linux Kernel 설치하기

apt 명령으로 아래와 같은 특정 kernel version을 설치한다.

예를 들어, linux kernel version 4.15.0-137 을 설치한다면, 아래 예제 명령과 같이 실행한다.

$ apt-get install linux-image-4.15.0-137-generic \
                  linux-headers-4.15.0-137-generic \
                  linux-modules-4.15.0-137-generic \
                  linux-modules-extra-4.15.0-137-generic

GRUB 설정하기

새로운 Linux kernel version이 설치되었다고 해서, 새로 설치한 Kernel version으로 부팅되는 것이 아니다.

GRUB 설정을 수정해야 내가 원하는 linux kernel version으로 부팅된다.

아래 예제 GRUB 파일과 같이 수정하면 된다.

$ vi /etc/default/grub

... 중간 생략 ...

## 방금 새로 설치한 linux kernel version에 대한 이름을 설정한다.
GRUB_DEFAULT='Advanced options for Ubuntu>Ubuntu, with Linux 4.15.0-137-generic'

## 아래와 같이 설정하면, 3초 동안 countdown하는 화면이 나온다.
## countdown하는 동안에 'ESC or F4 or SHIFT' 키를 누르면 GRUB 부팅 설정이 나온다.
## 이때 Default kernel version이 아닌 다른 kernel version을 고를 수 있다.
GRUB_TIMEOUT_STYLE=countdown
GRUB_TIMEOUT=3

... 중간 생략 ...

grub 설정 파일을 저장하고, 아래와 같이 update-grub 명령을 수행한다.

$ update-grub

Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.15.0-213-generic
Found initrd image: /boot/initrd.img-4.15.0-213-generic
Found linux image: /boot/vmlinuz-4.15.0-143-generic
Found initrd image: /boot/initrd.img-4.15.0-143-generic
Found linux image: /boot/vmlinuz-4.15.0-142-generic
Found initrd image: /boot/initrd.img-4.15.0-142-generic
Found linux image: /boot/vmlinuz-4.15.0-137-generic
Found initrd image: /boot/initrd.img-4.15.0-137-generic
done

$

Linux OS를 reboot

아래와 같이 reboot 명령을 수행하고, 부팅 초기에 "countdown" 화면이 나오면

[ESC] 또는 [SHIFT] 또는 [F4] 키를 눌러서 원하는 Linux kernel version을 선택한다.

$ reboot

Linux kernel version의 적용 여부 확인

아래와 같이 `uname -sr` 명령으로 새로 설치한 linux kernel version으로 부팅되었는지 확인한다.

$ uname -sr
Linux 4.15.0-137-generic
$

작성일: 2024년 8월 10일

차박 여행을 한지 1년 5개월이 지났다.

차박 용품 중에서 제일 중요한 아이템은 "매트"가 아닐까 생각한다.

비록 차에서 잠을 자더라도 잘 자야 다음 날 여행이 즐겁다.

1년 전에 구입해서 사용했던 차박용 자충매트는 사용해보니 몇 가지 불편함이 있었다.

• 자충 매트가 너무 컸다. 매트가 길어서 트렁크를 닫을 때 간섭이 있었다. 그래서 트렁크 문을 닫을 때마다 조심스러웠다.
• 매트가 크니까 접을 때 불편했다.
• 자충매트가 부풀 때는 빠르게 잘 부풀었는데, 반대로 접을 때는 엄청난 힘을 줘야 바람이 빠졌다.
• 매트 접는 것이 쉽지 않다보니 그냥 대충 둘둘 말아서 방 구석에 세워놓게 된다. (공간을 많이 차지함)
• 꿀잠을 자겠다고 두꺼운 자충 매트를 샀더니, 아무리 잘 접어도 부피가 크다.

위와 같은 불편함을 겪고 나서 좀더 나에게 잘 맞는 매트를 구입하고 싶었다.

그래서 구입한 것인 "네이터하이크 자동 충전 에어매트(Naturehike Automatic Inflatable Sleeping Pad)"라는 자충 매트이다.

Naturehike 홈페이지를 보니 등산 캠핑 용품을 판매하는 브랜드처럼 보인다.

(즉, 자동차 차박 용품 브랜드는 아니다)

일단, 차박 용품이 아니니까 차박에 어울릴까 걱정하면서 구입했다.

걱정은 했지만, 구입 후 만족하고 있다.

어떤 점이 좋았냐면,

• 접었을 때 작고 가볍다. 그리고 보관, 운반이 쉽다.
• 에어 패드(에어 매트) 스스로 잘 부풀어 오른다. (어느 정도 자동으로 부풀면 마지막에 약간 바람을 불어넣어주면 끝)
• 접기가 정말 편하다. 작은 힘으로 둘둘 말면, 잘 말린다.

https://youtu.be/ygA4SjrkOpA?si=YBebqpHog4noXj0y

에어 매트 사이즈: 185(길이) x 55(폭) x 3.5(두께)    단위: cm