sejong.jeonjo@gmail.com

작성일: 2024년 12월 16일

eBook(PDF) - Learning eBPF 

https://isovalent.com/books/learning-ebpf/

참고: 위 책에 소개된 예제 코드는 아래 github에서 열람할 것.

https://github.com/lizrice/learning-ebpf?tab=readme-ov-file

libbpfgo-beginners

https://github.com/lizrice/libbpfgo-beginners

책 저자 - Liz Rice

https://www.lizrice.com/#6

eBPF - Official Web Site

https://ebpf.io/get-started/

작성일: 2024년 12월 13일

기업형 VPN을 사용할 일이 생겨서 어떤 거를 써야 하나 고민하다가, 최근에 보편적으로 어떤 제품이 많이 쓰이는지 조사해봤다.

간단하게 요약하면, Cisco AnyConnect 제품이 독보적으로 가장 많이 사용된다.
그리고 회사별로 보면, Cisco 제품군이 전체 VPN 시장의 54%를 차지한다.
(데이터 출처:  DataNeeds, 2023)

• Cisco AnyConnect: 29%  (2,467 기업에서 사용중)
• Cisco VPN: 25%  (2,125 기업에서 사용중)
• Juniper VPN: 10%  (887개 기업에서 사용중)
• Ctric Gateway: 8%  (670개 기업에서 사용중)
• OpenVPN: 7%  (583개 기업에서 사용중)
• CheckPoint VPN: 3%  (228개 기업에서 사용중)
• NCP IPsec VPN: 2% 

시장 점유율이 높은 Cisco AnyConnect의 운영 매뉴얼, API 가이드를 보니까 아주 잘 만들어져 있었다.

왜 Cisco AnyConnect 제품이 잘 팔리는지 알 수 있었다.

그런데 가격이 넘사벽이다. ㅠㅠ

IPsec tunnel에서 1Gbps 대역 효과를 얻기 위해서 대략 5100만원 정도를 써야 한다.

(이 5100만원이라는 것도 순수 장비 구입비만.. ㅠㅠ  기술지원 비용까지 합하면, 실제 지출되는 금액은 훨씬 커진다.)

회사가 여러 빌딩이나 지사로 나누어져 있으면, VPN 장비를 여러 개 구입해야 하니까 비용은 수억원 정도 지출될듯.

작성일: 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   -> 정상