DevOps에서 참고하면 좋은 리눅스 커널 정보 확인 (1)

최근 읽고있는 DevOps와 SE를 위한 리눅스 커널 이야기라는 책에서 좋은 정보들이 있어, 기본적으로 리눅스 커널에 대해 알고 업무한다면 도움이 될만한 내용들에 대해 기록과 공유를 위해 글을 작성해보려 합니다.

 

요즘 IT시스템에는 클라우드를 통해 누구나 서버를 만들고, 서버에 애플리케이션을 설치하고 서비스할 수 있게 되었습니다. 인프라와 관련된 많은 부분이 소프트웨어화 되어가고 있고 더 편리하게 사용할 수 있게 되었습니다.

 

그래서 상대적으로 인프라에 대한 관심이 적어지는 것도 사실이지만, 역설적으로 누구나 인프라를 구축할 수 있기 때문에 인프라에 더 많은 관심을 가져야 한다고 생각합니다. 내가 만들고 운영하는 서버이기에, 스스로 문제를 해결할 수 있어야 하고 애플리케이션이 구동되는 서버에 대해서는 지식이 꼭 필요합니다. 애플리케이션이 어떻게 동작하는지, 발생할 수 있는 문제는 없는지, 그리고 문제가 발생하고 있다면 원인은 무엇인지 확인하고 조치할 수 있어야 할 것입니다.

또한 적절한 성능 테스트와 성능 튜닝을 통해서 서비스를 운영하는 데 필요한 서버 대수를 정확하게 산정하고 운영할 수 있는 것이 시스템 엔지니어링과 관련된 작업이라 할 수 있습니다.

 

즉, 시스템 엔지니어링은 서버에서 발생할 수 있는 다양한 이슈들을 확인하고 해결하는 작업입니다. 리눅스 커널 역시 소프트웨어이며, 하드웨어를 관리하고 애플리케이션에 하드웨어 자원을 할당하고 프로스스끼리 영향을 주지 않도록 다양한 방법으로 권한을 제어, 관리합니다.

그래서 커널이 어떤 원리를 가지고 동작하는지를 이해하고 모니터링하는 것은 매우 중요한 일입니다! 그래야 내가 운영하고 있는 애플리케이션이 적당한 자원을 할당 받아서 제대로 된 일을 하고 있는지를 알 수 있고 또 그렇게 동작하도록 지시할 수 있기 때문입니다. 특히나 요즘과 같이 클라우드 기반으로 서버들이 동작하는 경우야말로 서버가 낼 수 있는 최대의 성능을 끌어낼 수 있어야 하며, 이러한 작업은 커널에 대한 이해가 바탕이 되어야 합니다.

 

물론, 방대하며 수시로 개선되고 변경되는 커널의 동작 원리를 완벽하게 이해한다는 것은 불가능에 가깝지만, 변하지 않는 근간이 되는 기능들(프로세스를 생성하거나, 프로세스에 자원을 할당하거나, 네트워크 통신에 TCP를 이용하는 등)에 대한 이해를 바탕으로 시스템의 문제점을 파악하거나 발생할 수 있는 문제점들을 대처하는 것이 시스템 엔지니어링의 기본이 아닐까 싶습니다. 예를 들어, 기본적인 커널의 이해를 바탕으로 서버에서 발생하고 있는 여러 가지 사건들(프로세스 간 경합, 비정상적 메모리 사용률)을 해결하기 위한 방법을 살펴볼 것 같습니다. 그리고 그런 일들이 왜 발생하지는지에 대해서도 커널에 대한 이해가 있다면 훨씬 많은 도움이 될 것 같습니다.

 

 

 

먼저 간단하게 시스템 구성 정보를 확인하는 방법에 대해 알아보려 합니다.

시스템의 문제점을 분석하고 확ㅇ니하기 위해서는 현재 시스템의 구성 정보를 정확하게 확인해야 할 것 같습니다. 현재 사용 중인 커널의 버전과 부팅 시 사용한 커널 파라미터, 그리고 하드웨어 CPU와 메모리는 어떤 것을 사용하고 있는지에 대해서도 알고 접근해야 할 것입니다.

 

커널의 버전 정보를 확인하는 방법은 여러가지가 있습니다. 이중 대표적인 방법으로는 uname 명령어가 있습니다. 아래와 같이 uname -a옵션으로 확인할 수 있습니다.

$ uname -a
Linux xxx-bastion 6.8.0-1019-aws #21~22.04.1-Ubuntu SMP Thu Nov  7 17:33:30 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

 

또한 dmesg 명령을 사용하여 커널의 디버깅 메세지로, 커널을 부팅할 때 나오는 메세지와 운영 중에 발생하는 메시지를 볼 수 있게 해주는 명령입니다. 즉, 커널 메시지 버퍼에 저장된 메세지를 출력하는 명령어입니다.

(dmesg 명령을 필터링하여 커널이 메모리르 인식하는 과정과 부팅 시 사용한 파라미터 등을 확인할 수 있습니다.)

 

 

dmesg를 이용해 확인하는 커널 정보 이외에 현재 사용 중인 커널의 컴파일 옵션도 확인할 필요가 있습니다. 커널의 기능 중 컴파일 옵션이 포함되어야만 사용할 수 있는 기능들이 있기 때문입니다.

$ sudo cat /boot/config-`uname -r` | more
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 6.5.0-41-generic Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="x86_64-linux-gnu-gcc-12 (Ubuntu 12.3.0-1ubuntu1~22.04) 12.3.0"
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=120300
CONFIG_CLANG_VERSION=0
CONFIG_AS_IS_GNU=y
CONFIG_AS_VERSION=23800
CONFIG_LD_IS_BFD=y
CONFIG_LD_VERSION=23800
...
CONFIG_FUNCTION_TRACER=y # ftrace와 같은 커널 함수 레벨의 추적이 필요한 경우

 

 

 

 

다음으로는 CPU 정보를 확인하는 방법입니다.

시스템의 하드웨어 정보를 알고 어던 제조사에서 만든 어떤 제품인지, 메모리는 물리적으로 어떻게 구성되어 있는지 등에 대한 이해도 있어야 커널에 대한 이해가 가능합니다. 그중에서도 CPU, BIOS에 대해 먼저 알아보려합니다.

리눅스에서는 dmidecode 명령을 사용하여 하드웨어 정보를 확인합니다. dmidecode는 DMI(Desktop Management Interface) 테이블의 정보를 읽고 출력하는 명령어로, 해당 테이블은 시스템 하드웨어 정보를 저장하는 구조입니다.

 

CPU, BIOS정보를 확인하는데 사용하는 옵션은 -t system, bios, processor이며, bios부터 살펴보고자 합니다.

$ sudo dmidecode -t bios
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.5.0 present.
# SMBIOS implementations newer than version 3.3.0 are not
# fully supported by this version of dmidecode.

Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
	Vendor: American Megatrends International, LLC.
	Version: P01SEB.024.230106.CL
	Release Date: 01/06/2023
...

bios키워드는 보통 특정 BIOS버전에 문제가 있다는 보고가 있고, 내가 사용하는 버전이 이 버전에 해당하는지 확인할 때 주로 사용합니다. 아래는 system 키워드의 결과입니다. 아마 가장 많이 사용하는 옵션일 것 같습니다.

$ sudo dmidecode -t system
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.5.0 present.
# SMBIOS implementations newer than version 3.3.0 are not
# fully supported by this version of dmidecode.

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
	Product Name: 400TFA/400SFA
...

장비가 어떤 제조사에서 만든 어떤 모델명인지 아는 것은 중요합니다. 이는 성능을 얼마나 낼 수 있는지를 알수 있습니다.

또한 다음으로는 CPU정보를 알기위해 processor 옵션을 사용해보려 합니다.

$ sudo dmidecode -t processor
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.5.0 present.
# SMBIOS implementations newer than version 3.3.0 are not
# fully supported by this version of dmidecode.

Handle 0x002B, DMI type 4, 48 bytes
Processor Information
	Socket Designation: U3E1
	Type: Central Processor
	Family: Core i7
	Manufacturer: Intel(R) Corporation
	ID: 71 06 0B 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 183, Stepping 1
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
		PSE (Page size extension)
...

        Core Count: 16
	Core Enabled: 16
	Thread Count: 24
...

위 내용을 보면 Interl의 i7 CPU를 사용하고 있으며 코어의 개수는 16개라는 것을 파악할 수 있습니다. 이 다음 나오는 thread count는 물리적 코어가 아닌 논리적 코어의 개수 즉, 하이퍼스레딩을 통해 각 코어에서 동시에 실행할 수 있는 작업의 수를 의미합니다. 보통 코어 하나당 2개의 스레드를 처리할 수도 있지만, Intel의 하이브리드 아키텍처의 경우 효율 코어와 성능 코어로 나뉘어져 있어 성능코어 8개는 16개 스레드, 효율코어 8개는 8개 스레드를 처리하기에 24개입니다.

물론, CPU에 대한 정보는 dmidecode 이외에 /proc/cpuinfo에 있는 정보나 lscpu를 통해서도 확인할 수 있습니다 🙂

 

 

 

 

다음으로는 메모리에 대한 정보를 확인해보겠습니다.

마찬가지로 dmidecode 명령을 사용하여 -t memory옵션으로 확인할 수 있습니다. 이 때 출력되는 정보를 통해 각 메모리 슬롯에 있는 메모리의 정보 및 제조사까지 확인할 수 있습니다.

$ sudo dmidecode -t memory
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.5.0 present.
# SMBIOS implementations newer than version 3.3.0 are not
# fully supported by this version of dmidecode.

Handle 0x0015, DMI type 16, 23 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 128 GB
	Error Information Handle: Not Provided
	Number Of Devices: 4

Handle 0x0016, DMI type 17, 92 bytes
Memory Device
	Array Handle: 0x0015
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
...

메모리는 크게 Physical Memory Array와 Memory Device의 두 영역으로 나눌 수 있습니다.

Physical Memory Array는 하나의 CPU 소켓과 함께 할당된 물리 메모리의 그룹을 의미합니다. 최근 프로세서는 NUMA라는 개념을 이용해서 각각의 CPU가 사용할 수 있는 로컬 메모리를 제공합니다. Physical Memory Array는 바로 이 개념에서 시작하며, CPU소켓마다 Physical Memory Array가 있습니다.

반대로 Memory Device는 실제로 시스템에 꽂혀 있는 메모리를 의미하며, 위 정보에서 메모리 용량, 제조사(제공되지 않을 수 있음)등의 정보를 볼 수 있습니다. 메모리 크기를 확인하기 위해서는 아래 명령어를 비교해보면 됩니다.

$ dmidecode -t memory | grep -i size:
$ free -m

 

 

(2) 편에 계속..https://ks1171-park.tistory.com/252