절차

1. 커널을 업데이트하려면 다음을 사용합니다.

   # yum update kernel

   이 명령은 커널과 모든 종속성을 함께 사용 가능한 최신 버전으로 업데이트합니다.

2. 시스템을 재부팅하여 변경 사항을 적용합니다.

절차

1. 로드할 커널 모듈을 선택합니다.

   모듈은 /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ 디렉터리에 있습니다.

2. 관련 커널 모듈을 로드합니다.

   # modprobe <MODULE_NAME>

   참고

   커널 모듈 이름을 입력할 때 이름 끝에 .ko.xz 확장을 추가하지 마십시오. 커널 모듈 이름에는 확장 기능이 없으며 해당 파일은 다음과 같습니다.

3. 선택적으로 관련 모듈이 로드되었는지 확인합니다.

   $ lsmod | grep <MODULE_NAME>

   모듈이 올바르게 로드된 경우 이 명령은 관련 커널 모듈을 표시합니다. 예를 들면 다음과 같습니다.

   $ lsmod | grep serio_raw
   serio_raw              16384  0

절차

1. lsmod 명령을 실행하고 언로드할 커널 모듈을 선택합니다.

   커널 모듈에 종속성이 있는 경우 커널 모듈을 언로드하기 전에 해당 모듈을 언로드합니다. 종속성이 있는 모듈 식별에 대한 자세한 내용은 현재 로드된 커널 모듈 및 커널 모듈 종속성 목록을 참조하십시오.

2. 관련 커널 모듈을 언로드합니다.

   # modprobe -r <MODULE_NAME>

   커널 모듈 이름을 입력할 때 이름 끝에 .ko.xz 확장을 추가하지 마십시오. 커널 모듈 이름에는 확장 기능이 없으며 해당 파일은 다음과 같습니다.

   주의

   실행 중인 시스템에서 커널 모듈을 사용할 때 커널 모듈을 언로드하지 마십시오. 이렇게 하면 불안정하거나 작동하지 않는 시스템으로 이어질 수 있습니다.

3. 필요한 경우 관련 모듈이 언로드되었는지 확인합니다.

   $ lsmod | grep <MODULE_NAME>

   모듈을 성공적으로 언로드하면 이 명령은 출력을 표시하지 않습니다.

절차

1. 부팅 프로세스 중에 로드할 커널 모듈을 선택합니다.

   모듈은 /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ 디렉터리에 있습니다.

2. 모듈에 대한 구성 파일을 생성합니다.

   # echo <MODULE_NAME> > /etc/modules-load.d/<MODULE_NAME>.conf

   참고

   커널 모듈 이름을 입력할 때 이름 끝에 .ko.xz 확장을 추가하지 마십시오. 커널 모듈 이름에는 확장 기능이 없으며 해당 파일은 다음과 같습니다.

3. 선택적으로 재부팅 후 관련 모듈이 로드되었는지 확인합니다.

   $ lsmod | grep <MODULE_NAME>

   위의 예제 명령은 성공하고 관련 커널 모듈을 표시해야 합니다.

절차

1. 거부 목록에 넣을 커널 모듈을 선택합니다.

   $ lsmod
   
   Module                  Size  Used by
   fuse                  126976  3
   xt_CHECKSUM            16384  1
   ipt_MASQUERADE         16384  1
   uinput                 20480  1
   xt_conntrack           16384  1
   …​

   lsmod 명령은 현재 실행 중인 커널에 로드된 모듈 목록을 표시합니다.

   • 또는 잠재적으로 로드되지 않도록 하려는 로드되지 않은 커널 모듈을 식별합니다.

     모든 커널 모듈은 /lib/modules/<KERNEL_VERSION>/kernel/<SUBSYSTEM>/ 디렉터리에 있습니다.

2. 거부 목록에 대한 구성 파일을 생성합니다.

   # vim /etc/modprobe.d/blacklist.conf
   
   	# Blacklists <KERNEL_MODULE_1>
   	blacklist <MODULE_NAME_1>
   	install <MODULE_NAME_1> /bin/false
   
   	# Blacklists <KERNEL_MODULE_2>
   	blacklist <MODULE_NAME_2>
   	install <MODULE_NAME_2> /bin/false
   
   	# Blacklists <KERNEL_MODULE_n>
   	blacklist <MODULE_NAME_n>
   	install <MODULE_NAME_n> /bin/false
   	…​

   이 예제에서는 vim 편집기에서 편집한 blacklist.conf 파일의 내용을 보여줍니다. blacklist 행을 사용하면 부팅 프로세스 중에 관련 커널 모듈이 자동으로 로드되지 않습니다. 그러나 blacklist 명령은 거부 목록에 없는 다른 커널 모듈의 종속성으로 모듈이 로드되지 않도록 방지하지 않습니다. 따라서 install 행은 모듈을 설치하는 대신 /bin/false 가 실행됩니다.

   해시 기호로 시작하는 행은 파일을 읽기 쉽게 만드는 주석입니다.

   참고

   커널 모듈 이름을 입력할 때 이름 끝에 .ko.xz 확장을 추가하지 마십시오. 커널 모듈 이름에는 확장 기능이 없으며 해당 파일은 다음과 같습니다.

3. 다시 빌드하기 전에 현재 초기 ramdisk 이미지의 백업 사본을 생성합니다.

   # cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).bak.$(date +%m-%d-%H%M%S).img

   새 버전에 예기치 않은 문제가 발생하는 경우 위의 명령은 백업 initramfs 이미지를 생성합니다.

   • 또는 커널 모듈을 거부 목록에 배치하려는 커널 버전에 해당하는 다른 초기 램디스크 이미지의 백업 사본을 생성합니다.

     # cp /boot/initramfs-<SOME_VERSION>.img /boot/initramfs-<SOME_VERSION>.img.bak.$(date +%m-%d-%H%M%S)

4. 변경 사항을 반영하려면 새 초기 램디스크 이미지를 생성합니다.

   # dracut -f -v

   • 현재 부팅된 것과 다른 커널 버전의 초기 램디스크 이미지를 빌드하는 경우 대상 initramfs 및 커널 버전을 둘 다 지정합니다.

     # dracut -f -v /boot/initramfs-<TARGET_VERSION>.img <CORRESPONDING_TARGET_KERNEL_VERSION>

5. 시스템을 재부팅합니다.

   $ reboot

절차

1. 다음 콘텐츠를 사용하여 /root/testmodule/test.c 파일을 생성합니다.

   #include <linux/module.h>
   
   #include <linux/kernel.h>
   
   int init_module(void)
       { printk("Hello World\n This is a test\n"); return 0; }
   
   void cleanup_module(void)
       { printk("Good Bye World"); }

   test.c 파일은 커널 모듈에 기본 기능을 제공하는 소스 파일입니다. 파일은 조직 용도로 전용 /root/testmodule/ 디렉토리에 생성되었습니다. 모듈 컴파일 후 /root/testmodule/ 디렉토리에 여러 파일이 포함됩니다.

   test.c 파일은 시스템 라이브러리에서 포함합니다.

   • 예제 코드의 printk() 함수에는 linux/kernel.h 헤더 파일이 필요합니다.

   • linux/module.h 파일에는 C 프로그래밍 언어로 작성된 여러 소스 파일 간에 공유할 함수 선언과 매크로 정의가 포함되어 있습니다.

     다음으로 init_module() 및 cleanup_module() 함수를 따라 텍스트를 인쇄하는 커널 로깅 함수 printk() 를 시작하고 종료합니다.

2. 다음 콘텐츠를 사용하여 /root/testmodule/Makefile 파일을 만듭니다.

   obj-m := test.o

   Makefile에는 컴파일러에서 특별히 test.o 라는 개체 파일을 생성해야 하는 명령이 포함되어 있습니다. obj-m 지시문은 결과 test.ko 파일이 로드 가능한 커널 모듈로 컴파일되도록 지정합니다. 또는 obj-y 지시문은 test.ko 를 기본 제공 커널 모듈로 빌드하도록 지시합니다.

3. 커널 모듈을 컴파일합니다.

   # make -C /lib/modules/$(uname -r)/build M=/root/testmodule modules
   make: Entering directory '/usr/src/kernels/4.18.0-305.el8.x86_64'
     CC [M]  /root/testmodule/test.o
     Building modules, stage 2.
     MODPOST 1 modules
   WARNING: modpost: missing MODULE_LICENSE() in /root/testmodule/test.o
   see include/linux/module.h for more information
     CC      /root/testmodule/test.mod.o
     LD [M]  /root/testmodule/test.ko
   make: Leaving directory '/usr/src/kernels/4.18.0-305.el8.x86_64'

   컴파일러는 최종 커널 모듈(test.ko)에 연결하기 전에 각 소스 파일(test.c)에 대한 오브젝트 파일(test.c)을 중간 단계로 생성합니다.

   컴파일에 성공하면 /root/testmodule/ 에 컴파일된 사용자 지정 커널 모듈과 관련된 추가 파일이 포함됩니다. 컴파일된 모듈 자체는 test.ko 파일로 표시됩니다.

검증

1. 선택 사항: /root/testmodule/ 디렉토리의 내용을 확인합니다.

   ls -l /root/testmodule/
   total 452
   -rw-r—​r--. 1 root root     16 Jul 12 10:16 Makefile
   -rw-r—​r--. 1 root root     32 Jul 12 10:16 modules.order
   -rw-r—​r--. 1 root root      0 Jul 12 10:16 Module.symvers
   -rw-r—​r--. 1 root root    197 Jul 12 10:15 test.c
   -rw-r—​r--. 1 root root 219736 Jul 12 10:16 test.ko
   -rw-r—​r--. 1 root root    826 Jul 12 10:16 test.mod.c
   -rw-r—​r--. 1 root root 113760 Jul 12 10:16 test.mod.o
   -rw-r—​r--. 1 root root 107424 Jul 12 10:16 test.o

2. kernel 모듈을 /lib/modules/$(uname -r)/ 디렉터리에 복사합니다.

   # cp /root/testmodule/test.ko /lib/modules/$(uname -r)/

3. 모듈 종속성 목록을 업데이트합니다.

   # depmod -a

4. 커널 모듈을 로드합니다.

   # modprobe -v test
   insmod /lib/modules/4.18.0-305.el8.x86_64/test.ko

5. 커널 모듈이 성공적으로 로드되었는지 확인합니다.

   # lsmod | grep test
   test                   16384  0

6. 커널 링 버퍼에서 최신 메시지를 읽습니다.

   # dmesg
   …​
   [74422.545004] Hello World
                   This is a test

절차

1. 키 쌍 생성에 대한 매개 변수를 사용하여 구성 파일을 생성합니다.

   # cat << EOF > configuration_file.config
   [ req ]
   default_bits = 4096
   distinguished_name = req_distinguished_name
   prompt = no
   string_mask = utf8only
   x509_extensions = myexts
   
   [ req_distinguished_name ]
   O = Organization
   CN = Organization signing key
   emailAddress = E-mail address
   
   [ myexts ]
   basicConstraints=critical,CA:FALSE
   keyUsage=digitalSignature
   subjectKeyIdentifier=hash
   authorityKeyIdentifier=keyid
   EOF

2. 다음 예와 같이 X.509 공용 및 개인 키 쌍을 만듭니다.

   # openssl req -x509 -new -nodes -utf8 -sha256 -days 36500 \
   -batch -config configuration_file.config -outform DER \
   -out my_signing_key_pub.der \
   -keyout my_signing_key.priv

   공개 키는 my_signing_key_pub.der 파일에 작성되고 개인 키는 my_signing_key.priv 파일에 작성됩니다.

   중요

   RHEL 8에서는 키 쌍의 유효 날짜가 중요하지 않습니다. 키는 만료되지 않지만 서명 키의 유효 기간 내에 커널 모듈에 서명하는 것이 좋습니다. 그러나 sign-file 유틸리티는 사용자에게 경고하지 않으며 유효 날짜에 관계없이 키를 사용할 수 있습니다.

3. 필요한 경우 아래 예와 같이 공개 키의 유효 날짜를 검토할 수 있습니다.

   # openssl x509 -inform der -text -noout -in my_signing_key_pub.der
   
   Validity
               Not Before: Feb 14 16:34:37 2019 GMT
               Not After : Feb 11 16:34:37 2029 GMT

4. 인증하고 커널 모듈을 로드하려는 모든 시스템에 공개 키를 등록합니다.

절차

1. MOK 목록에 공개 키 추가를 요청합니다.

   # mokutil --import my_signing_key_pub.der

   MOK 등록 요청의 암호를 입력하고 확인하라는 메시지가 표시됩니다.

2. 시스템을 재부팅합니다.

   보류중인 MOK 키 등록 요청은 shim.efi 에 의해 감지되고 UEFI 콘솔에서 등록을 완료할 수 있도록 MokManager.efi 가 시작됩니다.

3. "Enroll MOK"를 선택하고 메시지가 표시되면 이전에 이 요청과 연결된 암호를 입력하고 등록을 확인합니다.

   공개 키는 영구 MOK 목록에 추가됩니다.

절차

1. 공개 키가 시스템 인증 키에 있는지 확인합니다.

   # keyctl list %:.platform

2. /lib/ modules/$(uname -r)/extra/ 디렉터리를 생성하는 kernel- modules-extra 패키지를 설치합니다.

   # yum -y install kernel-modules-extra

3. 커널 모듈을 원하는 커널의 /extra/ 디렉토리에 복사합니다.

   # cp my_module.ko /lib/modules/$(uname -r)/extra/

4. 모듈 종속성 목록을 업데이트합니다.

   # depmod -a

5. 커널 모듈을 로드하고 성공적으로 로드되었는지 확인합니다.

   # modprobe -v my_module
   # lsmod | grep my_module

   1. 선택적으로 부팅 시 모듈을 로드하려면 /etc/modules-loaded.d/my_module.conf 파일에 추가합니다.

      # echo "my_module" > /etc/modules-load.d/my_module.conf

절차

1. GRUB 2 부팅 메뉴가 나타나면 시작할 커널을 선택하고 e 키를 눌러 커널 매개 변수를 편집합니다.
2. 커서를 아래로 이동하여 커널 명령행을 찾습니다. 커널 명령줄은 64비트 IBM Power Series 및 x86-64 BIOS 기반 시스템에서 linux 로 시작하거나 UEFI 시스템에서 linuxefi 로 시작합니다.

3. 커서를 행 끝으로 이동합니다.

   참고

   Ctrla를 눌러 행의 시작 부분으로 건너뛰고 Ctrle를 눌러 행의 끝으로 건너뜁니다. 일부 시스템에서 Home 및 End 키도 작동할 수 있습니다.

4. 필요에 따라 커널 매개 변수를 편집합니다. 예를 들어 시스템을 긴급 모드로 실행하려면 linux 줄 끝에 emergency 매개변수를 추가합니다.

   linux   ($root)/vmlinuz-4.18.0-348.12.2.el8_5.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet emergency

   시스템 메시지를 사용하려면 rhgb 및 quiet 매개 변수를 제거합니다.

5. Ctrlx를 눌러 선택한 커널과 수정된 명령행 매개 변수를 사용하여 부팅합니다.

절차

1. /etc/default/grub 파일에 다음 두 행을 추가합니다.

   GRUB_TERMINAL="serial"
   GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8 --parity=no --stop=1"

   첫 번째 줄에서는 그래픽 터미널을 비활성화합니다. GRUB_TERMINAL 키는 GRUB_TERMINAL_INPUT 및 GRUB_TERMINAL_OUTPUT 키의 값을 재정의합니다.

   두 번째 줄은 baud 속도(--speed), 패리티 및 기타 값을 사용자 환경과 하드웨어에 맞게 조정합니다. 예를 들어 115200과 같은 작업에는 훨씬 높은 세례 비율을 사용하는 것이 다음 로그 파일과 같은 작업에 적합합니다.

2. GRUB 2 설정 파일을 업데이트합니다.

   • BIOS 기반 시스템에서 다음을 수행합니다.

     # grub2-mkconfig -o /boot/grub2/grub.cfg

   • UEFI 기반 시스템에서 다음을 수행합니다.

     # grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

3. 변경 사항을 적용하려면 시스템을 재부팅합니다.

절차

1. 모든 매개변수와 해당 값을 나열하려면 다음을 사용합니다.

   # sysctl -a

   참고

   # sysctl -a 명령은 런타임 및 부팅 시 조정할 수 있는 커널 매개 변수를 표시합니다.

2. 매개 변수를 일시적으로 구성하려면 다음 예와 같이 명령을 사용합니다.

   # sysctl <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>

   위의 샘플 명령은 시스템이 실행되는 동안 매개 변수 값을 변경합니다. 변경 사항은 재시작 없이 즉시 적용됩니다.

   참고

   시스템이 재부팅되면 변경 사항은 기본값으로 돌아갑니다.

절차

1. 모든 매개변수를 나열하려면 다음을 사용합니다.

   # sysctl -a

   명령은 런타임 시 구성할 수 있는 모든 커널 매개 변수를 표시합니다.

2. 매개변수를 영구적으로 구성하려면 다음을 수행합니다.

   # sysctl -w <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE> >> /etc/sysctl.conf

   sample 명령은 튜닝 가능 항목을 변경하고 커널 매개 변수의 기본값을 재정의하는 /etc/sysctl.conf 파일에 씁니다. 변경 사항은 재시작 없이 즉시 영구적으로 적용됩니다.

절차

1. /etc/sysctl.d/에 새 구성 파일을 만듭니다.

   # vim /etc/sysctl.d/<some_file.conf>

2. 다음과 같이 행당 하나씩 커널 매개변수를 포함합니다.

   <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>
   <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>

3. 구성 파일을 저장합니다.

4. 시스템을 재부팅하여 변경 사항을 적용합니다.

   • 또는 재부팅하지 않고 변경 사항을 적용하려면 다음을 실행합니다.

     # sysctl -p /etc/sysctl.d/<some_file.conf>

     명령을 사용하면 이전에 만든 구성 파일의 값을 읽을 수 있습니다.

절차

1. 설정할 커널 매개변수를 식별합니다.

   # ls -l /proc/sys/<TUNABLE_CLASS>/

   명령에서 반환한 쓰기 가능한 파일은 커널을 구성하는 데 사용할 수 있습니다. 읽기 전용 권한이 있는 파일은 현재 설정에 대한 피드백을 제공합니다.

2. 커널 매개변수에 target 값을 할당합니다.

   # echo <TARGET_VALUE> > /proc/sys/<TUNABLE_CLASS>/<PARAMETER>

   명령은 시스템을 다시 시작하면 구성 변경이 사라집니다.

3. 선택적으로 새로 설정된 커널 매개 변수의 값을 확인합니다.

   # cat /proc/sys/<TUNABLE_CLASS>/<PARAMETER>

1. 값. 콘솔 로그 수준은 콘솔에 인쇄된 메시지의 우선 순위를 가장 낮은 우선 순위를 정의합니다.
2. 값. 명시적인 로그 수준이 연결되지 않은 메시지의 기본 로그 수준입니다.
3. 값. 콘솔 로그 레벨에 가능한 최저 로그 수준 구성을 설정합니다.

4. 값. 부팅 시 콘솔 로그 수준의 기본값을 설정합니다.

   위의 각 값은 오류 메시지를 처리하는 다른 규칙을 정의합니다.

절차

1. Kdump 필드로 이동합니다.
2. kdump 를 활성화합니다.
3. kdump 용으로 예약해야 하는 메모리 양을 정의합니다.

절차

1. kdump 가 시스템에 설치되어 있는지 확인하십시오.

   $ rpm -q kexec-tools

   패키지가 설치된 경우 출력합니다.

   kexec-tools-2.0.17-11.el8.x86_64

   패키지가 설치되지 않은 경우 출력합니다.

   package kexec-tools is not installed

2. 다음을 수행하여 kdump 및 기타 필요한 패키지를 설치합니다.

   # yum install kexec-tools

절차

1. /etc/default/grub 파일을 편집합니다.

2. crashkernel= 옵션을 설정합니다.

   예를 들어 128MB의 메모리를 예약하려면 다음을 사용합니다.

   crashkernel=128M

   또는 설치된 메모리의 총 크기에 따라 예약된 메모리 양을 변수로 설정할 수 있습니다. 메모리 예약을 변수에 대한 구문은 crashkernel=<range1> :< size1>,< range2>:<size2> 입니다. 예를 들면 다음과 같습니다.

   crashkernel=512M-2G:64M,2G-:128M

   위 예제에서는 총 시스템 메모리가 512MB에서 2GB 사이인 경우 64MB의 메모리를 예약합니다. 총 메모리 양이 2GB를 초과하면 128MB가 예약됩니다.

   • 예약된 메모리를 오프셋합니다.

     일부 시스템은 crashkernel 예약이 매우 일찍 시작되므로 특정 고정 오프셋으로 메모리를 예약해야 하며, 특별한 용도로 일부 영역을 예약하려고 합니다. 오프셋이 설정되면 예약된 메모리가 여기서 시작됩니다. 예약된 메모리를 오프셋하려면 다음 구문을 사용하십시오.

     crashkernel=128M@16M

     위의 예에서 kdump 는 16MB(실제 주소 0x01000000)부터 128MB의 메모리를 예약합니다. offset 매개 변수가 0으로 설정되거나 완전히 생략된 경우 kdump 는 예약된 메모리를 자동으로 오프셋합니다. 변수 메모리 예약을 설정할 때 이 구문을 사용할 수도 있습니다. 이 경우 오프셋은 항상 마지막으로 지정됩니다(예: crashkernel=512M-2G:64M,2G-:128M@16M).

3. 다음 명령을 사용하여 GRUB2 설정 파일을 업데이트합니다.

   # grub2-mkconfig -o /boot/grub2/grub.cfg

절차

1. 루트 로서 /etc/kdump.conf 구성 파일을 편집하고 #core_collector makedumpfile -l --message-level 1 -d 31 부터 해시 기호("#")를 제거합니다.
2. 크래시 덤프 파일 압축을 활성화하려면 다음을 실행합니다.

절차

1. 루트 로서 /etc/kdump.conf 구성 파일의 #failure_action 행의 시작 부분에서 해시 기호("#")를 제거합니다.

2. 값을 원하는 작업으로 바꿉니다.

   failure_action poweroff

절차

1. kdump 가 활성화된 시스템을 재부팅합니다.

2. kdump 가 실행 중인지 확인합니다.

   ~]# systemctl is-active kdump
   active

3. Linux 커널이 충돌하도록 강제 적용합니다.

   echo 1 > /proc/sys/kernel/sysrq
   echo c > /proc/sysrq-trigger

   주의

   위의 명령은 커널을 충돌하고 재부팅해야 합니다.

   다시 부팅되면 주소- octets-MM-DD-HH:MM:SS/vmcore 파일은 /etc/kdump.conf 파일에 지정한 위치에 생성됩니다(기본적으로 /var/crash/).

   참고

   이 작업은 구성의 유효성을 확인합니다. 또한 이 작업을 사용하여 대표 작업 부하로 충돌 덤프를 완료하는 데 걸리는 시간을 기록할 수 있습니다.

절차

1. 설치된 모든 커널에 crashkernel=auto 명령줄 매개변수를 추가합니다.

   # /grubby --update-kernel=ALL --args="crashkernel=auto"

2. kdump 서비스를 활성화합니다.

   # systemctl enable --now kdump.service

절차

1. 머신에 설치된 커널을 나열합니다.

   # ls -a /boot/vmlinuz-*
   /boot/vmlinuz-0-rescue-2930657cd0dc43c2b75db480e5e5b4a9 /boot/vmlinuz-4.18.0-330.el8.x86_64 /boot/vmlinuz-4.18.0-330.rt7.111.el8.x86_64

2. 시스템의 GRUB(GRUB) 2 설정 파일에 특정 kdump 커널을 추가합니다.

   예를 들면 다음과 같습니다.

   # grubby --update-kernel=vmlinuz-4.18.0-330.el8.x86_64 --args="crashkernel=auto"

3. kdump 서비스를 활성화합니다.

   # systemctl enable --now kdump.service

절차

1. 현재 세션에서 kdump 서비스를 중지하려면 다음을 수행합니다.

   # systemctl stop kdump.service

2. kdump 서비스를 비활성화하려면 다음을 수행합니다.

   # systemctl disable kdump.service

절차

1. kexec 유틸리티를 실행합니다.

   # kexec -l /boot/vmlinuz-3.10.0-1040.el7.x86_64 --initrd=/boot/initramfs-3.10.0-1040.el7.x86_64.img --reuse-cmdline

   명령은 kexec 시스템 호출의 커널과 initramfs 이미지를 수동으로 로드합니다.

2. 시스템을 재부팅합니다.

   # reboot

   명령은 커널을 감지하고 모든 서비스를 종료한 다음 kexec 시스템 호출을 호출하여 이전 단계에서 제공한 커널로 재부팅합니다.

절차

1. 로드를 차단하려는 커널 모듈을 선택합니다.

   $ lsmod
   
   Module                  Size  Used by
   fuse                  126976  3
   xt_CHECKSUM            16384  1
   ipt_MASQUERADE         16384  1
   uinput                 20480  1
   xt_conntrack           16384  1

   lsmod 명령은 현재 실행 중인 커널에 로드된 모듈 목록을 표시합니다.

2. /etc/sysconfig/kdump 파일에서 KDUMP_COMMANDLINE_APPEND= 변수를 업데이트합니다.

   # KDUMP_COMMANDLINE_APPEND="rd.driver.blacklist=hv_vmbus,hv_storvsc,hv_utils,hv_netvsc,hid-hyperv"

   또한 modprobe.blacklist=<modules> 구성 옵션을 사용하여 다음 예제를 고려합니다.

   # KDUMP_COMMANDLINE_APPEND="modprobe.blacklist=emcp modprobe.blacklist=bnx2fc modprobe.blacklist=libfcoe modprobe.blacklist=fcoe"

3. kdump 서비스를 다시 시작합니다.

   # systemctl restart kdump

절차

1. 추정 crashkernel= 값을 출력합니다.

   # kdumpctl estimate
   
   Encrypted kdump target requires extra memory, assuming using the keyslot with minimum memory requirement
      Reserved crashkernel:    256M
      Recommended crashkernel: 652M
   
      Kernel image size:   47M
      Kernel modules size: 8M
      Initramfs size:      20M
      Runtime reservation: 64M
      LUKS required size:  512M
      Large modules: <none>
      WARNING: Current crashkernel size is lower than recommended size 652M.

2. crashkernel= 을 원하는 값으로 증가하여 필요한 메모리 양을 구성합니다.
3. 시스템을 재부팅합니다.

절차

1. Kernel Dump 탭을 열고 kdump 서비스를 시작합니다.
2. 명령줄을 사용하여 kdump 메모리 사용량을 구성합니다.

3. Crash dump 위치 옵션 옆에 있는 링크를 클릭합니다.

   

4. 드롭다운에서 Local Filesystem 옵션을 선택하고 덤프를 저장할 디렉터리를 지정합니다.

   

   • 또는 드롭다운에서 Remote over SSH (SSH를 통한 원격) 옵션을 선택하여 SSH 프로토콜을 사용하여 vmcore를 원격 시스템으로 전송합니다.

     Server,ssh 키 및 디렉터리 필드를 원격 시스템 주소, ssh 키 위치 및 대상 디렉토리로 채웁니다.

   • 또 다른 선택 사항은 드롭다운에서 NFS를 통한 Remote (원격) 옵션을 선택하고 NFS 프로토콜을 사용하여 vmcore를 원격 시스템으로 보내도록 Mount (마운트) 필드를 채우는 것입니다.

     참고

     압축 확인란을 선택하여 vmcore 파일의 크기를 줄입니다.

5. 커널을 충돌하여 구성을 테스트합니다.

   
   1. 테스트 구성 을 클릭합니다.

   2. Test kdump 설정 필드에서 Crash 시스템을 클릭합니다.

      주의

      이 단계에서는 커널 실행을 중단하고 시스템이 충돌하고 데이터가 손실됩니다.

절차

1. '/etc/kdump.conf 파일을 편집하고 final_action 매개 변수를 추가합니다.

   final_action <reboot | halt | poweroff>

2. kdump 서비스를 다시 시작하십시오.

   kdumpctl restart

절차

1. kdump 설치 및 구성.

2. /etc/default/grub 파일의 GRUB_CMDLINE_LINUX 행에 fadump=on 을 추가합니다.

   GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/swap crashkernel=auto
   rd.lvm.lv=rhel/root rhgb quiet fadump=on"

3. (선택 사항) 기본값을 사용하는 대신 예약된 부팅 메모리를 지정하려면 /etc/default/grub 에서 crashkernel=xxM 을 GRUB_CMDLINE_LINUX 로 구성합니다. 여기서 xx 는 메가바이트 단위로 필요한 메모리 양입니다.

   GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/swap crashkernel=xxM rd.lvm.lv=rhel/root rhgb quiet fadump=on"

   중요

   Red Hat은 부팅 구성 옵션을 실행하기 전에 모든 부팅 구성 옵션을 테스트하는 것이 좋습니다. 크래시 커널에서 부팅할 때 OOM(메모리 부족) 오류를 관찰하는 경우 크래시 커널이 정상적으로 부팅될 때까지 crashkernel= 인수에 지정된 값을 늘립니다. 이 경우 시험 및 오류가 필요할 수 있습니다.

절차

1. /etc/sysctl.conf 파일에서 다음 행을 추가하거나 편집하여 kdump가 expect ump 에서 예상대로 시작되도록 합니다.

   kernel.panic=0
   kernel.unknown_nmi_panic=1

   주의

   특히 kdump 후에 시스템이 재부팅되지 않도록 하십시오. kdump 가 vmcore 파일을 저장하지 못한 후 시스템이 재부팅되면 안 됩니다.

2. /etc/kdump.conf 에서 halt 또는 shell 으로 적절하게 failure_action 매개변수를 설정합니다.

   failure_action shell

절차

1. 관련 리포지토리를 활성화합니다.

   # subscription-manager repos --enable baseos repository

   # subscription-manager repos --enable appstream repository

   # subscription-manager repos --enable rhel-8-for-x86_64-baseos-debug-rpms

2. crash 패키지를 설치합니다.

   # yum install crash

3. kernel-debuginfo 패키지를 설치합니다.

   # yum install kernel-debuginfo

   패키지는 실행 중인 커널에 해당하며 덤프 분석에 필요한 데이터를 제공합니다.

절차

1. crash 유틸리티를 시작하려면 명령에 두 개의 매개 변수를 전달해야 합니다.

   • 특정 kernel-debuginfo 패키지를 통해 제공되는 debug-info(예: /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux )

   • 실제 vmcore 파일(예: /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore)

     결과 crash 명령은 다음과 같습니다.

     # crash /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore

     kdump 에서 캡처한 동일한 <kernel> 버전을 사용합니다.

     예 16.1. crash 유틸리티 실행

     다음 예제에서는 4.18.0-5.el8.x86_64 커널을 사용하여 14:05 PM에 생성된 코어 덤프를 분석하는 방법을 보여줍니다.

     ...
     WARNING: kernel relocated [202MB]: patching 90160 gdb minimal_symbol values
     
           KERNEL: /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux
         DUMPFILE: /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore  [PARTIAL DUMP]
             CPUS: 2
             DATE: Sat Oct  6 14:05:16 2018
           UPTIME: 01:03:57
     LOAD AVERAGE: 0.00, 0.00, 0.00
            TASKS: 586
         NODENAME: localhost.localdomain
          RELEASE: 4.18.0-5.el8.x86_64
          VERSION: #1 SMP Wed Aug 29 11:51:55 UTC 2018
          MACHINE: x86_64  (2904 Mhz)
           MEMORY: 2.9 GB
            PANIC: "sysrq: SysRq : Trigger a crash"
              PID: 10635
          COMMAND: "bash"
             TASK: ffff8d6c84271800  [THREAD_INFO: ffff8d6c84271800]
              CPU: 1
            STATE: TASK_RUNNING (SYSRQ)
     
     crash>

2. 대화형 프롬프트를 종료하고 크래시 를 종료하려면 exit 또는 q 를 입력합니다.

   예 16.2. crash 유틸리티 종료

   crash> exit
   ~]#

절차

1. Kernel Oops Analyzer 툴 액세스.

2. 커널 충돌 문제를 진단하려면 vmcore 에 생성된 커널 oops 로그를 업로드합니다.

   • 또는 텍스트 메시지 또는 vmcore-dmesg.txt 를 입력으로 제공하여 커널 크래시 문제를 진단할 수도 있습니다.

     
3. DEœT (삭제)를 클릭하여 makedumpfile 의 정보를 알려진 솔루션과 기준으로 oops 메시지를 비교합니다.

절차

1. kdump 서비스가 활성화되어 활성 상태인지 확인합니다.

   # systemctl is-enabled kdump.service && systemctl is-active kdump.service enabled active

   kdump 가 활성화되어 실행되고 있지 않으면 필요한 모든 구성을 설정하고 kdump 서비스가 활성화되었는지 확인합니다.

2. 초기 kdump 기능을 사용하여 부팅 커널의 initramfs 이미지를 다시 빌드합니다.

   dracut -f --add earlykdump

3. rd.earlykdump 커널 명령줄 매개변수를 추가합니다.

   grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="rd.earlykdump"

4. 시스템을 재부팅하여 변경 사항을 반영합니다.

   reboot

5. 선택적으로 that rd.earlykdump 가 성공적으로 추가되었으며 초기 kdump 기능이 활성화되었는지 확인합니다.

   # cat /proc/cmdline
   BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-187.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet rd.earlykdump
   
   # journalctl -x | grep early-kdump
   Mar 20 15:44:41 redhat dracut-cmdline[304]: early-kdump is enabled.
   Mar 20 15:44:42 redhat dracut-cmdline[304]: kexec: loaded early-kdump kernel

1. 커널 패치 모듈은 /var/lib/kpatch/ 디렉토리에 복사되고 다음 부팅 시 systemd 를 통해 커널에 재애플리케이션을 등록합니다.
2. kpatch 모듈은 실행 중인 커널에 로드되고 새 함수는 새 코드 메모리에 있는 위치에 대한 포인터를 사용하여 ftrace 메커니즘에 등록됩니다.
3. 커널이 패치된 기능에 액세스하면 원래 기능을 무시하고 커널을 패치된 함수 버전으로 리디렉션하는 ftrace 메커니즘에 의해 리디렉션됩니다.

절차

1. 선택적으로 커널 버전을 확인합니다.

   # uname -r
   4.18.0-94.el8.x86_64

2. 커널 버전에 해당하는 라이브 패치 패키지를 검색합니다.

   # yum search $(uname -r)

3. 라이브 패치 패키지를 설치합니다.

   # yum install "kpatch-patch = $(uname -r)"

   위의 명령은 특정 커널에 대해서만 최신 누적 라이브 패치를 설치하고 적용합니다.

   라이브 패치 패키지 버전이 1-1 이상인 경우 패키지에 patch 모듈이 포함됩니다. 이 경우 라이브 패치 패키지를 설치하는 동안 커널이 자동으로 패치됩니다.

   커널 패치 모듈은 향후 재부팅 중에 systemd 시스템 및 서비스 관리자가 로드할 /var/lib/kpatch/ 디렉토리에도 설치됩니다.

   참고

   지정된 커널에 사용할 수 있는 라이브 패치가 없는 경우 빈 라이브 패치 패키지가 설치됩니다. 비어 있는 라이브 패치 패키지에는 kpatch_version-kpatch_release 가 0-0입니다(예: kpatch-patch-4_18_0-94-0.el8.x86_64.rpm ). 빈 RPM 설치는 지정된 커널의 향후 모든 라이브 패치에 대해 시스템을 서브스크립션합니다.

4. 선택적으로 커널이 패치되었는지 확인합니다.

   # kpatch list
   Loaded patch modules:
   kpatch_4_18_0_94_1_1 [enabled]
   
   Installed patch modules:
   kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)
   …​

   출력은 커널 패치 모듈이 커널에 로드되었음을 보여주므로 이제 kpatch-patch-4_18_0-94-1-1.el8.x86_64.rpm 패키지의 최신 수정 사항과 패치됩니다.

절차

1. 선택적으로 설치된 모든 커널과 현재 실행 중인 커널을 확인합니다.

   # yum list installed | grep kernel
   Updating Subscription Management repositories.
   Installed Packages
   ...
   kernel-core.x86_64         4.18.0-240.10.1.el8_3           @rhel-8-for-x86_64-baseos-rpms
   kernel-core.x86_64         4.18.0-240.15.1.el8_3           @rhel-8-for-x86_64-baseos-rpms
   ...
   
   # uname -r
   4.18.0-240.10.1.el8_3.x86_64

2. kpatch-dnf 플러그인을 설치합니다.

   # yum install kpatch-dnf

3. 커널 라이브 패치에 대한 자동 서브스크립션을 활성화합니다.

   # yum kpatch auto
   Updating Subscription Management repositories.
   Last metadata expiration check: 19:10:26 ago on Wed 10 Mar 2021 04:08:06 PM CET.
   Dependencies resolved.
   ==================================================
    Package                             Architecture
   ==================================================
   Installing:
    kpatch-patch-4_18_0-240_10_1        x86_64
    kpatch-patch-4_18_0-240_15_1        x86_64
   
   Transaction Summary
   ===================================================
   Install  2 Packages
   …​

   이 명령은 현재 설치된 커널을 모두 서브스크립션하여 커널 라이브 패치를 수신합니다. 또한 명령은 설치된 모든 커널에 대해 최신 누적 라이브 패치를 설치하고 적용합니다.

   나중에 커널을 업데이트하면 새 커널 설치 프로세스 중에 라이브 패치가 자동으로 설치됩니다.

   커널 패치 모듈은 향후 재부팅 중에 systemd 시스템 및 서비스 관리자가 로드할 /var/lib/kpatch/ 디렉토리에도 설치됩니다.

   참고

   지정된 커널에 사용할 수 있는 라이브 패치가 없는 경우 빈 라이브 패치 패키지가 설치됩니다. 빈 라이브 패치 패키지에는 kpatch_version-kpatch_release 가 0-0입니다(예: kpatch-patch-4_18_0-240-0.el8.x86_64.rpm . 빈 RPM 설치는 지정된 커널의 모든 향후 라이브 패치에 시스템을 등록합니다.

절차

1. 선택적으로 설치된 모든 커널과 현재 실행 중인 커널을 확인합니다.

   # yum list installed | grep kernel
   Updating Subscription Management repositories.
   Installed Packages
   ...
   kernel-core.x86_64         4.18.0-240.10.1.el8_3           @rhel-8-for-x86_64-baseos-rpms
   kernel-core.x86_64         4.18.0-240.15.1.el8_3           @rhel-8-for-x86_64-baseos-rpms
   ...
   
   # uname -r
   4.18.0-240.10.1.el8_3.x86_64

2. 커널 라이브 패치에 대한 자동 서브스크립션을 비활성화합니다.

   # yum kpatch manual
   Updating Subscription Management repositories.

절차

1. 라이브 패치 패키지를 선택합니다.

   # yum list installed | grep kpatch-patch
   kpatch-patch-4_18_0-94.x86_64        1-1.el8        @@commandline
   …​

   위의 예제 출력에는 설치된 라이브 패치 패키지가 나열되어 있습니다.

2. 라이브 패치 패키지를 제거합니다.

   # yum remove kpatch-patch-4_18_0-94.x86_64

   라이브 패치 패키지가 제거되면 다음 번 재부팅할 때까지 커널이 패치되지만 커널 패치 모듈은 디스크에서 제거됩니다. 나중에 재부팅할 때 해당 커널은 더 이상 패치되지 않습니다.

3. 시스템을 재부팅합니다.

4. 라이브 패치 패키지가 제거되었는지 확인합니다.

   # yum list installed | grep kpatch-patch

   패키지가 성공적으로 제거된 경우 명령은 출력을 표시하지 않습니다.

5. 선택적으로 커널 라이브 패치 솔루션이 비활성화되었는지 확인합니다.

   # kpatch list
   Loaded patch modules:

   예제 출력에서는 현재 로드된 패치 모듈이 없으므로 커널이 패치되지 않았음을 보여줍니다.

절차

1. 커널 패치 모듈을 선택합니다.

   # kpatch list
   Loaded patch modules:
   kpatch_4_18_0_94_1_1 [enabled]
   
   Installed patch modules:
   kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)
   …​

2. 선택한 커널 패치 모듈을 제거하십시오.

   # kpatch uninstall kpatch_4_18_0_94_1_1
   uninstalling kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

   • 설치 제거된 커널 패치 모듈이 계속 로드됩니다.

     # kpatch list
     Loaded patch modules:
     kpatch_4_18_0_94_1_1 [enabled]
     
     Installed patch modules:
     <NO_RESULT>

     선택한 모듈이 제거되면 다음 번 재부팅할 때까지 커널이 패치되지만 커널 패치 모듈은 디스크에서 제거됩니다.

3. 시스템을 재부팅합니다.

4. 선택적으로 커널 패치 모듈이 제거되었는지 확인합니다.

   # kpatch list
   Loaded patch modules:
   …​

   위의 예제 출력에서는 로드되거나 설치된 커널 패치 모듈이 표시되지 않으므로 커널이 패치되지 않고 커널 라이브 패치 솔루션이 활성화되어 있지 않습니다.

절차

1. kpatch.service 가 활성화되었는지 확인합니다.

   # systemctl is-enabled kpatch.service
   enabled

2. kpatch.service 를 비활성화합니다 :

   # systemctl disable kpatch.service
   Removed /etc/systemd/system/multi-user.target.wants/kpatch.service.

   • 적용된 커널 패치 모듈이 계속 로드됩니다.

     # kpatch list
     Loaded patch modules:
     kpatch_4_18_0_94_1_1 [enabled]
     
     Installed patch modules:
     kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

3. 시스템을 재부팅합니다.

4. 필요한 경우 kpatch.service 의 상태를 확인합니다 :

   # systemctl status kpatch.service
   ● kpatch.service - "Apply kpatch kernel patches"
      Loaded: loaded (/usr/lib/systemd/system/kpatch.service; disabled; vendor preset: disabled)
      Active: inactive (dead)

   예제 출력은 kpatch.service 가 비활성화되었으며 실행되고 있지 않음을 확인합니다. 따라서 커널 라이브 패치 솔루션이 활성화되어 있지 않습니다.

5. 커널 패치 모듈이 로드 해제되었는지 확인합니다.

   # kpatch list
   Loaded patch modules:
   <NO_RESULT>
   
   Installed patch modules:
   kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

   위의 예제 출력은 커널 패치 모듈이 여전히 설치되어 있지만 커널이 패치되지 않았음을 보여줍니다.

절차

1. zswap 을 영구적으로 활성화합니다.

   # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="zswap.enabled=1"

2. 변경 사항을 적용하려면 시스템을 재부팅합니다.

절차

1. CPU 사용량에서 제한할 애플리케이션의 PID(프로세스 ID)를 식별합니다.

   # top
   top - 11:34:09 up 11 min,  1 user,  load average: 0.51, 0.27, 0.22
   Tasks: 267 total,   3 running, 264 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 49.0 us,  3.3 sy,  0.0 ni, 47.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.0 st
   MiB Mem :   1826.8 total,    303.4 free,   1046.8 used,    476.5 buff/cache
   MiB Swap:   1536.0 total,   1396.0 free,    140.0 used.    616.4 avail Mem
   
     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    6955 root      20   0  228440   1752   1472 R  99.3   0.1   0:32.71 sha1sum
    5760 jdoe      20   0 3603868 205188  64196 S   3.7  11.0   0:17.19 gnome-shell
    6448 jdoe      20   0  743648  30640  19488 S   0.7   1.6   0:02.73 gnome-terminal-
       1 root      20   0  245300   6568   4116 S   0.3   0.4   0:01.87 systemd
     505 root      20   0       0      0      0 I   0.3   0.0   0:00.75 kworker/u4:4-events_unbound
   ...

   top 프로그램의 예제 출력에서는 PID 6955(유연 적 애플리케이션 sha1sum)가 많은 CPU 리소스를 사용함을 보여줍니다.

2. cpu 리소스 컨트롤러 디렉터리에 하위 디렉터리를 생성합니다.

   # mkdir /sys/fs/cgroup/cpu/Example/

   위의 디렉터리는 특정 프로세스를 배치하고 프로세스에 특정 CPU 제한을 적용할 수 있는 제어 그룹을 나타냅니다. 동시에 일부 cgroups-v1 인터페이스 파일과 cpu 컨트롤러별 파일이 디렉터리에 생성됩니다.

3. 선택적으로 새로 생성된 제어 그룹을 검사합니다.

   # ll /sys/fs/cgroup/cpu/Example/
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.clone_children
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.procs
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.stat
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_all
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_sys
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_user
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_sys
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_user
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_period_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_quota_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_period_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_runtime_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.shares
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpu.stat
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 notify_on_release
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 tasks

   예제 출력에서는 Example 제어 그룹의 프로세스에 대해 설정할 수 있는 특정 구성 및/또는 제한을 나타내는 cpuacct. us, cpu.cfs._period_us 와 같은 파일을 보여줍니다. 각 파일 이름 앞에 속해 있는 제어 그룹 컨트롤러의 이름이 붙습니다.

   기본적으로 새로 생성된 제어 그룹은 제한 없이 시스템의 전체 CPU 리소스에 대한 액세스를 상속합니다.

4. 제어 그룹에 대한 CPU 제한을 구성합니다.

   # echo "1000000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us
   # echo "200000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us

   cpu.cfs_period_us 파일은 제어 그룹의 CPU 리소스에 대한 액세스를 재할당해야 하는 빈도에 대한 마이크로초(여기에서 "us"로 표시되는 시간)를 나타냅니다. 상한값은 1초이고 하한값은 1000마이크로초입니다.

   cpu.cfs_quota_us 파일은 제어 그룹의 모든 프로세스가 하나의 기간(cpu. cfs_period_us에서 정의한 대로) 동안 실행되는 총 시간(마이크로초)을 나타냅니다. 제어 그룹의 프로세스가 한 기간 동안 할당량에 지정된 모든 시간을 사용하는 즉시 나머지 기간 동안 제한되며 다음 기간까지 실행할 수 없습니다. 하한값은 1000마이크로초입니다.

   위의 예제 명령은 CPU 시간 제한을 설정하여 Example 제어 그룹에서 집계된 모든 프로세스가 1초(cpu .cfs_quota_us로 정의됨)마다 0.2초(cpu.cfs_ period_us로 정의됨) 동안만 실행할 수 있습니다.

5. 선택적으로 제한을 확인합니다.

   # cat /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us
   1000000
   200000

6. Example 제어 그룹에 애플리케이션의 PID를 추가합니다.

   # echo "6955" > /sys/fs/cgroup/cpu/Example/cgroup.procs
   
   or
   
   # echo "6955" > /sys/fs/cgroup/cpu/Example/tasks

   이전 명령을 사용하면 원하는 애플리케이션이 Example 제어 그룹의 구성원이 되므로 Example 제어 그룹에 대해 구성된 CPU 제한을 초과하지 않습니다 . PID는 시스템의 기존 프로세스를 나타냅니다. 여기에서 PID 6955 는 CPU 컨트롤러의 사용 사례를 설명하는 데 사용되는 sha1sum /dev/zero & 프로세스에 할당되었습니다.

7. 애플리케이션이 지정된 제어 그룹에서 실행되는지 확인합니다.

   # cat /proc/6955/cgroup
   12:cpuset:/
   11:hugetlb:/
   10:net_cls,net_prio:/
   9:memory:/user.slice/user-1000.slice/user@1000.service
   8:devices:/user.slice
   7:blkio:/
   6:freezer:/
   5:rdma:/
   4:pids:/user.slice/user-1000.slice/user@1000.service
   3:perf_event:/
   2:cpu,cpuacct:/Example
   1:name=systemd:/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service

   위의 예제 출력은 원하는 애플리케이션의 프로세스가 Example 제어 그룹에서 실행되며 애플리케이션의 프로세스에 CPU 제한을 적용하는 것을 보여줍니다.

8. 제한된 애플리케이션의 현재 CPU 사용량을 식별합니다.

   # top
   top - 12:28:42 up  1:06,  1 user,  load average: 1.02, 1.02, 1.00
   Tasks: 266 total,   6 running, 260 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 11.0 us,  1.2 sy,  0.0 ni, 87.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.2 st
   MiB Mem :   1826.8 total,    287.1 free,   1054.4 used,    485.3 buff/cache
   MiB Swap:   1536.0 total,   1396.7 free,    139.2 used.    608.3 avail Mem
   
     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    6955 root      20   0  228440   1752   1472 R  20.6   0.1  47:11.43 sha1sum
    5760 jdoe      20   0 3604956 208832  65316 R   2.3  11.2   0:43.50 gnome-shell
    6448 jdoe      20   0  743836  31736  19488 S   0.7   1.7   0:08.25 gnome-terminal-
     505 root      20   0       0      0      0 I   0.3   0.0   0:03.39 kworker/u4:4-events_unbound
    4217 root      20   0   74192   1612   1320 S   0.3   0.1   0:01.19 spice-vdagentd
   ...

   PID 6955 의 CPU 사용량이 99%에서 20%로 감소했습니다.

절차

1. 제한하려는 CPU 소비 애플리케이션의 PID(프로세스 ID)를 식별합니다.

   # top
   Tasks: 104 total,   3 running, 101 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 17.6 us, 81.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.8 hi,  0.0 si,  0.0 st
   MiB Mem :   3737.4 total,   3312.7 free,    133.3 used,    291.4 buff/cache
   MiB Swap:   4060.0 total,   4060.0 free,      0.0 used.   3376.1 avail Mem
   
       PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     34578 root      20   0   18720   1756   1468 R  99.0   0.0   0:31.09 sha1sum
     34579 root      20   0   18720   1772   1480 R  99.0   0.0   0:30.54 sha1sum
         1 root      20   0  186192  13940   9500 S   0.0   0.4   0:01.60 systemd
         2 root      20   0       0      0      0 S   0.0   0.0   0:00.01 kthreadd
         3 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_gp
         4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_par_gp
   ...

   예제 출력은 PID 34578 및 34 579 ( sha1sum의 설명 애플리케이션 2개)가 CPU라는 많은 리소스를 사용한다는 것을 알 수 있습니다. 두 애플리케이션 모두 cgroups-v2 기능 관리를 시연하는 데 사용되는 예제 애플리케이션입니다.

2. cpu 및 cpu set 컨트롤러를 /sys/fs/cgroup/cgroup.controllers 파일에서 사용할 수 있는지 확인합니다.

   # cat /sys/fs/cgroup/cgroup.controllers
   cpuset cpu io memory hugetlb pids rdma

3. CPU 관련 컨트롤러를 활성화합니다.

   # echo "+cpu" >> /sys/fs/cgroup/cgroup.subtree_control
   # echo "+cpuset" >> /sys/fs/cgroup/cgroup.subtree_control

   이러한 명령을 사용하면 /sys/fs/cgroup/ 루트 제어 그룹의 즉시 하위 그룹에 대해 cpu 및 cpuset 컨트롤러를 사용할 수 있습니다. 하위 그룹은 기준에 따라 프로세스를 지정하고 각 프로세스에 제어 검사를 적용할 수 있는 위치입니다.

   사용자는 모든 수준에서 cgroup.subtree_control 파일의 내용을 읽고 즉시 하위 그룹에서 활성화에 사용할 수 있는 컨트롤러를 파악할 수 있습니다.

   참고

   기본적으로 root 제어 그룹의 /sys/fs/cgroup/cgroup.subtree_control 파일에는 메모리 및 Pids 컨트롤러 가 포함되어 있습니다.

4. /sys/fs/cgroup/Example/ 디렉토리를 생성합니다.

   # mkdir /sys/fs/cgroup/Example/

   /sys/fs/cgroup/Example/ 디렉토리는 하위 그룹을 정의합니다. 또한 이전 단계에서 이 하위 그룹에 대해 cpu 및 cpuset 컨트롤러를 활성화했습니다.

   /sys/fs/cgroup/Example/ 디렉터리를 생성하면 일부 cgroups-v2 인터페이스 파일과 cpu 및 cpuset 컨트롤러별 파일이 디렉터리에 자동으로 생성됩니다. /sys/fs/cgroup/Example/ 디렉터리에는 메모리 및 pids 컨트롤러에 대한 컨트롤러별 파일도 포함되어 있습니다.

5. 선택적으로 새로 생성된 하위 제어 그룹을 검사합니다.

   # ll /sys/fs/cgroup/Example/
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cgroup.controllers
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cgroup.events
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.freeze
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.max.depth
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.max.descendants
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.procs
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cgroup.stat
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.subtree_control
   …​
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cpuset.cpus
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cpuset.cpus.effective
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cpuset.cpus.partition
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cpuset.mems
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cpuset.mems.effective
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 cpu.stat
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cpu.weight
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 cpu.weight.nice
   …​
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 memory.events.local
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 memory.high
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 memory.low
   …​
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 pids.current
   -r—​r—​r--. 1 root root 0 Jun  1 10:33 pids.events
   -rw-r—​r--. 1 root root 0 Jun  1 10:33 pids.max

   예제 출력에는 cpuset.cpus 및 cpu. max 와 같은 파일이 표시됩니다. 이러한 파일은 cpuset 및 cpu 컨트롤러에 따라 다릅니다. cpuset 및 cpu 컨트롤러는/sys/fs/cgroup/cgroup _control 파일을 사용하여 루트의(/ sys/fs/cgroup/cgroup_control) 직접 하위 제어 그룹에 대해 수동으로 활성화됩니다.

   디렉터리에는 활성화된 컨트롤러에 관계없이 모든 제어 그룹에 공통된 cgroup.procs 또는 cgroup.controllers 와 같은 일반적인 cgroup 제어 인터페이스 파일도 포함되어 있습니다.

   memory.high 및 pids. max 와 같은 파일은 루트 제어 그룹(/sys/fs/cgroup/)에 있으며 항상 기본적으로 활성화되는 메모리 및 pids 컨트롤러와 관련이 있습니다.

   기본적으로 새로 생성된 하위 그룹은 제한 없이 모든 시스템의 CPU 및 메모리 리소스에 대한 액세스를 상속합니다.

6. /sys/fs/cgroup/Example/ 에서 CPU 관련 컨트롤러를 활성화하여 CPU와만 관련된 컨트롤러를 가져옵니다.

   # echo "+cpu" >> /sys/fs/cgroup/Example/cgroup.subtree_control
   # echo "+cpuset" >> /sys/fs/cgroup/Example/cgroup.subtree_control

   이러한 명령을 사용하면 즉시 하위 제어 그룹에는 메모리 또는 피드 컨트롤러가 아닌 CPU 시간 배포를 규제하는 것과 관련된 컨트롤러 만 사용할 수 있습니다.

7. /sys/fs/cgroup/Example/tasks/ 디렉터리를 생성합니다.

   # mkdir /sys/fs/cgroup/Example/tasks/

   /sys/fs/cgroup/Example/tasks/ 디렉터리는 cpu 및 cpu set 컨트롤러에만 관련된 파일이 있는 하위 그룹을 정의합니다.

8. 선택적으로 다른 하위 제어 그룹을 검사합니다.

   # ll /sys/fs/cgroup/Example/tasks
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.controllers
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.events
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.freeze
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.max.depth
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.max.descendants
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.procs
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.stat
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.subtree_control
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.threads
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.type
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.max
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.pressure
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus.effective
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus.partition
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.mems
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpuset.mems.effective
   -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpu.stat
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.weight
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.weight.nice
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 io.pressure
   -rw-r—​r--. 1 root root 0 Jun  1 11:45 memory.pressure

9. CPU 시간을 제어할 프로세스가 동일한 CPU에서 경쟁하는지 확인합니다.

   # echo "1" > /sys/fs/cgroup/Example/tasks/cpuset.cpus

   이전 명령을 실행하면 Example/tasks 하위 제어 그룹에 배치할 프로세스가 동일한 CPU에서 경쟁합니다. 이 설정은 cpu 컨트롤러가 활성화하는 데 중요합니다.

   중요

   cpu 컨트롤러는 관련 하위 제어 그룹에 단일 CPU에서 시간을 위해 경쟁하는 최소 2개의 프로세스가 있는 경우에만 활성화됩니다.

검증 단계

1. 선택사항: 즉시 하위 cgroups에 대해 CPU 관련 컨트롤러가 활성화되었는지 확인합니다.

   # cat /sys/fs/cgroup/cgroup.subtree_control /sys/fs/cgroup/Example/cgroup.subtree_control
   cpuset cpu memory pids
   cpuset cpu

2. 선택사항: CPU 시간을 제어할 프로세스가 동일한 CPU에서 경쟁할지 확인합니다.

   # cat /sys/fs/cgroup/Example/tasks/cpuset.cpus
   1

절차

1. 제어 그룹 내에서 리소스 제한을 수행하도록 CPU 대역폭을 구성합니다.

   # echo "200000 1000000" > /sys/fs/cgroup/Example/tasks/cpu.max

   첫 번째 값은 마이크로초(마이크로)에서 허용된 시간 할당량으로, 하위 그룹의 모든 프로세스를 한 기간 동안 전체적으로 실행할 수 있습니다. 두 번째 값은 기간 길이를 지정합니다.

   단일 기간 동안 제어 그룹의 프로세스가 이 할당량에서 지정한 시간을 집합적으로 고갈하면 나머지 기간 동안 제한되고 다음 기간 동안 실행되지 않습니다.

   이 명령은 CPU 시간 분배 제어를 설정하여 /sys/fs/cgroup/Example/tasks 하위 그룹의 모든 프로세스가 1초마다 0.2초 동안만 CPU에서 실행될 수 있습니다. 즉, 1초의 5분의 1이 됩니다.

2. 선택적으로 시간 할당량을 확인합니다.

   # cat /sys/fs/cgroup/Example/tasks/cpu.max
   200000 1000000

3. 애플리케이션의 PID를 Example/tasks 하위 그룹에 추가합니다.

   # echo "34578" > /sys/fs/cgroup/Example/tasks/cgroup.procs
   # echo "34579" > /sys/fs/cgroup/Example/tasks/cgroup.procs

   예제 명령은 원하는 애플리케이션이 Example/tasks 하위 그룹의 구성원이 되어 이 하위 그룹에 대해 구성된 CPU 시간 배포를 초과하지 않도록 합니다.

검증 단계

1. 애플리케이션이 지정된 제어 그룹에서 실행되는지 확인합니다.

   # cat /proc/34578/cgroup /proc/34579/cgroup
   0::/Example/tasks
   0::/Example/tasks

   위의 출력은 Example/tasks 하위 그룹에서 실행되는 지정된 애플리케이션의 프로세스를 보여줍니다.

2. 제한된 애플리케이션의 현재 CPU 사용량을 검사합니다.

   # top
   top - 11:13:53 up 23:10,  1 user,  load average: 0.26, 1.33, 1.66
   Tasks: 104 total,   3 running, 101 sleeping,   0 stopped,   0 zombie
   %Cpu(s):  3.0 us,  7.0 sy,  0.0 ni, 89.5 id,  0.0 wa,  0.2 hi,  0.2 si,  0.2 st
   MiB Mem :   3737.4 total,   3312.6 free,    133.4 used,    291.4 buff/cache
   MiB Swap:   4060.0 total,   4060.0 free,      0.0 used.   3376.0 avail Mem
   
       PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     34578 root      20   0   18720   1756   1468 R  10.0   0.0  37:36.13 sha1sum
     34579 root      20   0   18720   1772   1480 R  10.0   0.0  37:41.22 sha1sum
         1 root      20   0  186192  13940   9500 S   0.0   0.4   0:01.60 systemd
         2 root      20   0       0      0      0 S   0.0   0.0   0:00.01 kthreadd
         3 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_gp
         4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_par_gp
   ...

   PID 34578 및 PID 34 579 의 CPU 사용량이 10%로 감소했습니다. Example/tasks 하위 그룹은 프로세스를 전체적으로 CPU 시간의 20%로 조정합니다. 제어 그룹에는 두 개의 프로세스가 있으므로 각각 CPU 시간의 10%를 활용할 수 있습니다.

절차

1. 제어 그룹 내에서 리소스 제한을 달성하도록 원하는 CPU 가중치를 구성합니다.

   # echo "150" > /sys/fs/cgroup/Example/g1/cpu.weight
   # echo "100" > /sys/fs/cgroup/Example/g2/cpu.weight
   # echo "50" > /sys/fs/cgroup/Example/g3/cpu.weight

2. 애플리케이션의 PID를 g1, g 2 및 g 3 하위 그룹에 추가합니다.

   # echo "33373" > /sys/fs/cgroup/Example/g1/cgroup.procs
   # echo "33374" > /sys/fs/cgroup/Example/g2/cgroup.procs
   # echo "33377" > /sys/fs/cgroup/Example/g3/cgroup.procs

   예제 명령을 사용하면 원하는 애플리케이션이 예제/g*/ 하위 cgroups의 멤버가 되고 해당 cgroups의 구성에 따라 CPU 시간이 배포됩니다.

   프로세스가 실행 중인 하위 cgroup(g1,g2, g3)의 가중치는 상위 cgroup(Example) 수준에서 요약됩니다. 그런 다음 CPU 리소스는 해당 가중치에 비례하여 배포됩니다.

   결과적으로 모든 프로세스가 동시에 실행되면 커널은 해당 cgroup의 cpu.weight 파일에 따라 각 CPU 시간을 비례합니다.

   하위 cgroup	cpu.weight file	CPU 시간 할당
   g1	150	~50% (150/300)
   g2	100	~33% (100/300)
   g3	50	~16% (50/300)

   cpu.weight 컨트롤러 파일의 값은 백분율이 아닙니다.

   한 프로세스가 중단되어 cgroup g2 에 실행 중인 프로세스가 없으면 계산에서는 cgroup g2 가 생략되고 cgroup g 1 및 g 3 의 가중치만 줄어듭니다:

   하위 cgroup	cpu.weight file	CPU 시간 할당
   g1	150	~75% (150/200)
   g3	50	~25% (50/200)

   중요

   하위 cgroup에 여러 개의 실행 중인 프로세스가 있는 경우 해당 cgroup에 할당된 CPU 시간이 해당 cgroup의 멤버 프로세스에 동일하게 배포됩니다.

검증

1. 애플리케이션이 지정된 제어 그룹에서 실행되는지 확인합니다.

   # cat /proc/33373/cgroup /proc/33374/cgroup /proc/33377/cgroup
   0::/Example/g1
   0::/Example/g2
   0::/Example/g3

   명령 출력에는 Example/g*/ 하위 cgroup에서 실행되는 지정된 애플리케이션의 프로세스가 표시됩니다.

2. 제한된 애플리케이션의 현재 CPU 사용량을 검사합니다.

   # top
   top - 05:17:18 up 1 day, 18:25,  1 user,  load average: 3.03, 3.03, 3.00
   Tasks:  95 total,   4 running,  91 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 18.1 us, 81.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  0.0 si,  0.0 st
   MiB Mem :   3737.0 total,   3233.7 free,    132.8 used,    370.5 buff/cache
   MiB Swap:   4060.0 total,   4060.0 free,      0.0 used.   3373.1 avail Mem
   
       PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     33373 root      20   0   18720   1748   1460 R  49.5   0.0 415:05.87 sha1sum
     33374 root      20   0   18720   1756   1464 R  32.9   0.0 412:58.33 sha1sum
     33377 root      20   0   18720   1860   1568 R  16.3   0.0 411:03.12 sha1sum
       760 root      20   0  416620  28540  15296 S   0.3   0.7   0:10.23 tuned
         1 root      20   0  186328  14108   9484 S   0.0   0.4   0:02.00 systemd
         2 root      20   0       0      0      0 S   0.0   0.0   0:00.01 kthread
   ...

   참고

   명확한 설명을 위해 모든 예제 프로세스를 단일 CPU에서 실행하도록 했습니다. CPU 가중치는 여러 CPU에서 사용되는 경우에도 동일한 원칙을 적용합니다.

   PID 33373, PID 33374 및 PID 33 377 의 CPU 리소스가 해당 하위 cgroup에 할당된 가중치 150, 100, 50에 따라 할당되었습니다. 가중치는 각 애플리케이션의 CPU 시간을 약 50%, 33%, 16%에 해당합니다.

절차

1. 서비스의 메모리 사용량을 제한하려면 다음과 같이 /usr/lib/systemd/system/example.service 파일을 수정합니다.

   …​
   [Service]
   MemoryLimit=1500K
   …​

   위의 구성에서는 제어 그룹에서 실행되는 프로세스의 최대 메모리 사용 제한( 예.service )을 배치합니다.

   참고

   K, M, G 또는 T 접미사를 사용하여 킬로바이트, 킬로바이트, 기가바이트 또는 테라바이트를 측정 단위로 식별합니다.

2. 모든 장치 구성 파일을 다시 로드합니다.

   # systemctl daemon-reload

3. 서비스를 다시 시작하십시오.

   # systemctl restart example.service

4. 시스템을 재부팅합니다.

5. 선택적으로 변경 사항이 적용되었는지 확인합니다.

   # cat /sys/fs/cgroup/memory/system.slice/example.service/memory.limit_in_bytes
   1536000

   예제 출력에서는 메모리 사용량이 약 1,500KB로 제한되었음을 보여줍니다.

   참고

   memory.limit_in_bytes 파일은 메모리 제한을 AMD64 및 Intel 64에 고유한 4096바이트의 배수로 저장합니다. 실제 바이트 수는 CPU 아키텍처에 따라 다릅니다.

절차

1. 서비스 유닛을 중지합니다.

   # systemctl stop <name>.service

2. 서비스 유닛을 비활성화합니다.

   # systemctl disable <name>.service

3. 관련 장치 구성 파일을 제거합니다.

   # rm /usr/lib/systemd/system/<name>.service

4. 변경 사항이 적용되도록 모든 장치 구성 파일을 다시 로드합니다.

   # systemctl daemon-reload

절차

1. 프로세스가 상호 작용하는 리소스 컨트롤러를 보려면 # cat proc/<PID>/cgroup 명령을 실행합니다.

   # cat /proc/11269/cgroup
   12:freezer:/
   11:cpuset:/
   10:devices:/system.slice
   9:memory:/system.slice/example.service
   8:pids:/system.slice/example.service
   7:hugetlb:/
   6:rdma:/
   5:perf_event:/
   4:cpu,cpuacct:/
   3:net_cls,net_prio:/
   2:blkio:/
   1:name=systemd:/system.slice/example.service

   예제 출력은 관심 있는 프로세스와 관련이 있습니다. 이 경우 PID 11269 로 식별되며 example.service 유닛에 속하는 프로세스입니다. 프로세스가 systemd 유닛 파일 사양에 정의된 대로 올바른 제어 그룹에 배치되었는지 확인할 수 있습니다.

   참고

   기본적으로 모든 기본 리소스 컨트롤러를 자동으로 마운트하므로 리소스 컨트롤러 목록의 항목과 순서는 systemd 에서 시작한 모든 유닛에서 동일합니다.

절차

1. 현재 cgroups 를 실행 중인 동적 계정을 보려면 # systemd-cgtop 명령을 실행합니다.

   # systemd-cgtop
   Control Group                            Tasks   %CPU   Memory  Input/s Output/s
   /                                          607   29.8     1.5G        -        -
   /system.slice                              125      -   428.7M        -        -
   /system.slice/ModemManager.service           3      -     8.6M        -        -
   /system.slice/NetworkManager.service         3      -    12.8M        -        -
   /system.slice/accounts-daemon.service        3      -     1.8M        -        -
   /system.slice/boot.mount                     -      -    48.0K        -        -
   /system.slice/chronyd.service                1      -     2.0M        -        -
   /system.slice/cockpit.socket                 -      -     1.3M        -        -
   /system.slice/colord.service                 3      -     3.5M        -        -
   /system.slice/crond.service                  1      -     1.8M        -        -
   /system.slice/cups.service                   1      -     3.1M        -        -
   /system.slice/dev-hugepages.mount            -      -   244.0K        -        -
   /system.slice/dev-mapper-rhel\x2dswap.swap   -      -   912.0K        -        -
   /system.slice/dev-mqueue.mount               -      -    48.0K        -        -
   /system.slice/example.service                2      -     2.0M        -        -
   /system.slice/firewalld.service              2      -    28.8M        -        -
   ...

   예제 출력에는 리소스 사용량(CPU, 메모리, 디스크 I/O 로드)에 따라 정렬된 cgroup 이 현재 실행 중인 것으로 표시됩니다. 이 목록은 기본적으로 1초마다 새로 고쳐집니다. 따라서 각 제어 그룹의 실제 리소스 사용량에 대한 동적 인사이트를 제공합니다.

1. 선택한 서비스에서 할당된 CPU 시간 할당 정책 옵션 값을 확인합니다.

   $ systemctl show --property <CPU time allocation policy option> <service name>

2. CPU 시간 할당 정책 옵션의 필수 값을 루트로 설정합니다.

   # systemctl set-property <service name> <CPU time allocation policy option>=<value>

   참고

   cgroup 속성은 설정된 직후 적용됩니다. 따라서 서비스를 다시 시작할 필요가 없습니다.

1. 선택한 서비스에서 메모리 할당 구성 옵션의 할당된 값을 확인합니다.

   $ systemctl show --property <memory allocation configuration option> <service name>

2. 메모리 할당 구성 옵션의 필요한 값을 루트로 설정합니다.

   # systemctl set-property <service name> <memory allocation configuration option>=<value>

1. 선택한 서비스에서 할당된 I/O 대역폭 구성 옵션 값을 확인합니다.

   $ systemctl show --property <I/O bandwidth configuration option> <service name>

2. I/O 대역폭 구성 옵션의 필수 값을 루트로 설정합니다.

   # systemctl set-property <service name> <I/O bandwidth configuration option>=<value>

1. 선택한 서비스에서 CPUAffinity 유닛 파일 옵션의 값을 확인합니다.

   $ systemctl show --property <CPU affinity configuration option> <service name>

2. 루트로 선호도 마스크로 사용되는 CPU 범위에 필요한 CPUAffinity 장치 파일 옵션 값을 설정합니다.

   # systemctl set-property <service name> CPUAffinity=<value>

3. 서비스를 다시 시작하여 변경 사항을 적용합니다.

   # systemctl restart <service name>

1. /etc/systemd/system.conf 파일을 편집합니다.

   # vi /etc/systemd/system.conf

2. CPUAffinity= 옵션을 검색하고 CPU 번호 설정
3. 편집한 파일을 저장하고 서버를 다시 시작하여 변경 사항을 적용합니다.

1. 선택한 서비스에서 NUMAPolicy 장치 파일 옵션의 값을 확인합니다.

   $ systemctl show --property <NUMA policy configuration option> <service name>

2. 루트로 NUMAPolicy 장치 파일 옵션의 필요한 정책 유형을 설정합니다.

   # systemctl set-property <service name> NUMAPolicy=<value>

3. 서비스를 다시 시작하여 변경 사항을 적용합니다.

   # systemctl restart <service name>

1. /etc/systemd/system.conf 파일에서 NUMAPolicy 옵션을 검색합니다.
2. 정책 유형을 편집하고 파일을 저장합니다.

3. systemd 구성을 다시 로드합니다.

   # systemd daemon-reload

4. 서버를 재부팅합니다.