CPU 및 다양한 모드와 관련된 C 상태에 대한 설명

  • CPU는 유휴 상태일 때 에너지를 절약하기 위해 CPU에 저전력 모드를 시작하도록 명령 가능
  • CPU는 여러 전력 모드를 종합적으로 "C-State" 또는 "C-Mode"라고 칭함
  • 최근에는 CPU의 전력 소비를 줄일 수 있도록 향상 → C-State는 CPU의 기능을 하나씩 종료시켜서 전력 소모를 줄임
  • CPU 내부의 유휴 장치에서 클록 신호와 전원을 차단하면 작동 → 클록을 차단하고 전압을 줄이거나 완전히 종료하여 더 많은 장치를 중지할수록 더 많은 에너지가 절약
  • C-state는 보다 공격적인 방법으로 전력소모를 최소화하여 절전모드에 주로 사용
  • CPU가 절전 모드에서 완전히 "해제"되는 데 더 많은 시간이 발생
  • C-State는 C0에서 시작 → 정상 CPU 작동 모드(100% CPU 활성화)
  • C 번호가 클수록 CPU 절전 모드가 더 길게 설정 → 즉, 더 많은 회로와 신호가 꺼져 있고 CPU가 C0 모드로 완전히 해제되는 데 더 많은 시간이 걸림
  • 각 C-State에는 이름 有 → 몇 개에는 절전 수준과 해제 시간이 각각 다른 하위 모드가 존재
  • 최근에는 C7 기술이 추가되었는데 이는 최종적으로 남아있는 L3 공유 캐시까지 작동을 멈춰, DDR3 메모리나 PCI-Express 연결과 관련된 전력도 차단

 

현재 사용 가능한 모든 C-State 모드 요약본

  • C1~C3 모드는 CPU의 클록 신호를 차단하면 작동
  • C4~C6 모드는 CPU 전압을 줄이면 작동
  • "향상된" 모드는 동시에 모두 실행 가능

 

C-states 상태

 

※ 주의 → 전력관리 기술 적용에 따라 성능 저하 발생 가능

  • CPU의 C-State 기술은 전력의 효율성을 높이기 위한 전력관리 기술들의 기반
  • CPU의 C-State 기술은 CPU 자체의 클럭이나 전압을 크게 낮추고 대기모드에 들어가는 작업을 행함
  • CPU의 클럭이나 전압을 줄여 소비전력을 줄이는 단계로 진입했다 다시 기본 클럭으로 돌아오는 과정에서의 지연이나 기본클럭 및 전압이 복귀되지 못하는 등으로 CPU 성능이나 그래픽카드 등의 성능이 저하 가능
  • CPU의 경우 전력관리 기능의 버그로 인해 성능이 제대로 나타나지 못하는 문제들이 종종 발생
  • C-state 레벨에 따라 코어 내부 클럭이 중단되거나 L1/L2 캐시 Flush 및 Off 시키는 등의 동작이 발생
  • 레벨이 높아질수록 많은 컴포넌트들이 꺼짐으로써 전력 소모량은 줄지만, 그에 비례해서 정상 상태(C0)로 복귀하는데 더 많은 리소스와 시간이 소요되는 문제
  • DB 서버에서 발생했던 connect timeout 현상의 원인 역시 높은 레벨의 C-states 상태에서 정상 상태(C0)로 복귀하면서 DB 접속(정확히는 네트워크 연결) 과정에 지연이 발생

 

 

DELL의 BIOS System Profile의 설정 값

1. Performance Per Watt(DAPC)

  • Performance Per Watt(DAPC)는 BIOS System Profile의 기본값
  • 전력 소비 감소와 균형을 이루는 뛰어난 성능 조합
  • Dell Active Power Control (또는 DAPC)은 대부분의 환경에서 성능에 미치는 영향을 최소화하면서 뛰어난 전력 효율성 이점을 제공하는 BIOS 중심의 전원 제어 메커니즘을 사용
  • 전체 시스템 프로필에 대한 CPU 전원 관리 선택

2. Performance Per Watt(OS)

  • CPU 전원 관리를 제외한 모든 하위 옵션에 대한 DAPC 프로필과 유사
  • Performance Per Watt(OS)는 전원 관리 체계를 "OS DBPM"이라고 함
  • 운영 체제가 더 높은 전력 효율성을 위해 프로세서 주파수를 조작 가능
  • 전체 시스템 전력 소비를 줄이는 효과는 운영 체제가 하드웨어 리소스를 얼마나 효과적으로 제어 할 수 있는지에 따라 달라짐
  • Performance Per Watt(OS)는 운영 체제에서 영향받음

3. Performance

  • Performance는 프로세서 주파수를 최대화
  • C-states 및 같은 특정 절전 기능을 비활성화하여 잠재적으로 향상된 성능을 제공
  • 성능 최적화

4. Dense Configuration

  • 상당한 성능을 희생하면서 신뢰성 기능을 향상시키고 전력 소비를 줄여줌
  • 향상된 안정성이 요구되고 온도가 밀도가 낮은 데이터 센터에서 발생하는 임계 값을 초과 할 수있는 운영 환경을 대상으로 사용

5. custom

  • custom으로 설정하면 각 옵션의 설정 변경 가능


OMSA에서 BIOS의 System Profile 확인 절차

  1. 서버 IP:1311을 통해 OMSA 접속 후 System → Main System Chassis → BIOS 클릭

  2. Setup 클릭

  3. System Profile Settings 클릭

  4. System Profile으로 설정 값 확인


  • 서버의 Power supply redundant 는 두가지 모드가 존재
    1. A/B Grid Redundant (1+1)
    2. PSU Redundant (2+0)

 

1. Grid redundant

  • Grid redundant의 다른 말로 A/B Grid Redundant(1+1)이라고 함
  • 평소에는 파워서플라이 하나로만 운영하다가 전력 소모가 늘어나면 나머지 하나를 추가하여 절반씩 전력을 사용
  • 버려지는 전력 소모를 줄이고자 서버의 전력 사용량이 475W 이하일때는 Primary PSU만 사용하고 그 이상일때 두 개를 모두 사용
  • 1번 파워가 Primary PSU 로 설정되어 있고 서버의 전력 사용량이 475W 이하일 때에는 2번 파워는 사용 X
  • PSU 2를 사용하지 않을 때, PSU 1에서 AC lost가 발생
    1. Primary PSU가 넘어가는 과정에서 PSU 2의 Power supply의 전력이 부족하면서 서버의 전반적인 퍼포먼스가 떨어지거나 hang 발생
    2. 전력이 많이 부족하다면 재부팅 또는 전원 off 발생 가능

 

2. PSU Redundant (2+0)

  • PSU Redundant (2+0)의 다른 말로 Not Redundant이라고 함
  • 전력 소모량과 상관없이 무조건 두 개를 함께 사용 → 모든 PSU가 Online 상태로 유지
  • PSU Redundant (2+0)는 이중화가 아님
  • 전력을 효율적 사용하지는 못하지만, 1개의 PSU에 문제가 발생하였을 때도 서버에 문제가 발생하지 않음

 

TRIM이란

  • TRIM은 ATA 인터페이스를 위한 명령어
  • TRIM 명령어는 인터페이스마다, 운영 체제에 따라 이름도 모두 다르지만, 일반적으로 "Trim"이라고 칭함
  • TRIM은 SSD(Solid State Drive)에 어떤 데이터를 삭제할 수 있는지 알려줌
  • TRIM은 능동적 데이터 재배치와 함께 SSD(Solid State Drive)를 말끔하게 정리함
  • TRIM은 매우 유용하지만 필수 기능은 아님
  • 일부 운영 체제의 경우 Trim을 지원하지 않기 때문에 SSD 제조업체들은 Trim을 사용하지 않는다는 가정하에 드라이브를 설계, 생성 및 검증함
  • TRIM 명령을 사용하면 운영 체제에서 더 이상 사용되지 않는 것으로 간주되는 데이터 블록을 SATA SSD에서 삭제 가능
  • TRIM은 지원되는 운영 체제에 대한 Write amplification(쓰기 증폭)를 해결 가능
  • 운영 체제에서 파일이 삭제된 경우 파일은 파일 시스템에서 삭제로 표시되지만 디스크 컨텐츠는 실제로 지워지지 않음 → TRIM의 도입으로 파일이 삭제된 경우 운영 체제에서 유효한 데이터를 포함하지 않는 LBA로 TRIM 명령을 전송


TRIM의 역할

  • TRIM 명령어는 특정 영역에 더 이상 사용하지 않는 데이터가 있음을 SSD에 알려줌
  • 사용자의 관점에서는 해당 데이터는 문서에서 삭제된 것임 → 실제 SSD(Solid State Drive)가 정보를 읽고 쓰는 방식 때문에 해당 데이터는 사용자의 명령에 의해 드라이브에서 삭제된 상태가 아님
  • 사용자의 관점에서 삭제는 SSD에서 해당 데이터를 포함하는 SSD 영역은 더 이상 사용하지 않는 것으로 표시됨
  • TRIM 명령어는 해당 데이터가 삭제될 수 있음을 드라이브에 알려줌 → 컴퓨터가 유휴 상태가 되면, 능동적 데이터 재배치를 통해 해당 데이터는 삭제
  • TRIM 명령어가 존재하지 않았을 경우, SSD(Solid State Drive)는 드라이브의 일부 구간에 유효하지 않은 정보가 포함되어 있다는 것을 알지 못하며 추후 컴퓨터가 해당 위치에 새 정보를 쓰기 위해 이를 드라이브에 알려줄 때 비로소 인식
  • 드라이브는 기존 정보를 삭제한 다음에야 새 정보를 쓸 수 있음 → 단순히 새 정보를 쓰는 시간보다 더 많은 시간이 걸림
  • TRIM과 능동형 GC(Garbage Collect)을 활용한다면 SSD는 쓰기 명령을 더 빨리 실행 가능
  • TRIM을 사용하면 SSD(Solid State Drive)의 수명에도 영향 有
  • 유휴 시간 동안 삭제 가능한 셀을 SSD에 알려주고, 드라이브는 남아 있는 데이터가 채워진 셀과 쓰기 가능한 빈 셀을 정리하므로 불필요한 삭제 및 다시 쓰기를 하지 않아도 됨(SSD 블록의 수명을 균형있게 해줌)


TRIM의 이점

  1. 쓰기 과정에 많은 시간을 사용하여 유효하지 않은 데이터를 삭제하는 대신에 컴퓨터가 유휴 상태일 때 SSD(Solid State Drive)에서 데이터를 삭제하여 시간을 절약 가능
  2. TRIM는 능동형 GC(Garbage Collect)이 함께 작동하여 SSD의 수명을 늘릴 수 있음
  3. 능동형 GC(Garbage Collect)은 데이터 중에 관련 세그먼트를 나란히 위치할 수 있도록 이동시키므로 역동적이고 효과적인 Ware leveling 가능


TRIM 지원 환경

1. TRIM을 지원하는 SSD 환경(TRIM & GC를 지원)

  • Intel RAID controller를 사용하기에 SSD에 TRIM 사용 불가
  • SSD에서 TRIM을 지원하는 지 확인하는 방법
    1. hdparm -I /dev/sda 명령어
    2. lsblk -D 명령어
    3. /sys/block/sda/queue/discard_max_bytes 내용 확인
    4. /sys/block/sda/queue/discard_granularity 내용 확인

2. TRIM을 지원하는 커널 버전 → uname -r으로 확인 가능

  • 일반 SSD TRIM 지원 : Linux kernel 2.6.33 이상
  • NVMe SSD TRIM 지원 : Linux kernel 3.3 이상
  • RHEL6부터 TRIM 지원

3. 파일 시스템 확인 → TRIM 기능을 활성화 하기 위해 ext4 또는 xfs를 사용 → mount | grep -i "/dev/sd"로 확인

  • ext4에 TRIM을 적용하기 위해서는 명령어로 discard를 추가하거나 또는 /etc/fstab에 아래 discard를 추가

    # 명령어로 파일시스템에 TRIM 가능하도록 설정
    $ mount -t ext4 -o discard /dev/sda3 /
    
    # 영구적으로 파일시스템에 TRIM 가능하도록 설정
    $ vi /etc/fstab
    /dev/sda1 / ext4 defaults,discard 0 0



※ TRIM 사용 시 주의 사항

  • TRIM을 사용하는 조건은 까다롭기에 Linux 커널 버전, SSD TRIM 지원, 파일시스템(ext4, xfs)을 충족해야 실행 가능
  • 위 조건을 모두 충족하더라도, 현재 사용하고 있는 RAID contoller가 Intel RAID controller를 사용하는 경우 TRIM 사용 불가
  • Intel RAID controller에서 Window는 지원하는데, 아직 Linux는 지원 X
  • 향후 Inter RAID controller가 Linux도 TRIM을 실행할 수 있는 것을 대비하여 학습 진행
  • Boss card RAID contoller를 사용하는 경우 TRIM 사용 가능

  • turbostat 명령어는 X86 프로세서의 프로세서 topology, frequency, idle 전력 상태 통계, 온도 및 전력을 출력
  • turbostat 명령어는 전체 시스템의 카운터 결과 요약을 출력하고 제목 아래에 각 카운터 결과를 5 초마다 출력
  • turbostat 명령어는 kernel-tools 패키지에서 제공
  • 전력 사용량이나 유휴 시간이 비효율적인 서버 식별 가능
  • 시스템에서의 시스템 관리 인터럽트(SMI)의 비율 식별 가능
  • 전력 관리 튜닝 효과 확인

 

옵션

1. --Dump 옵션

  • raw 카운터 값을 표시

2. --debug 옵션

  • 추가 시스템 구성 정보를 표시
  • 내부 터보 스탯 디버그 정보가 활성화됨

3. --interval [seconds] 옵션

  • --interval 옵션 뒤에 seconds 값을 통해 출력되는 값을 설정
  • default 값은 5.0초

4. --out [output_file] 옵션

  • Turbostat 출력은 지정된 output_file에 기록
  • 파일이 이미 존재하면 잘리고 존재하지 않으면 생성

5. --Summary 옵션

  • 각 간격에 대해 출력을 1줄 시스템 요약으로 제한

 

turbostat 명령어 실행 결과

$ turbostat
Package Core    CPU     Avg_MHz Busy%   Bzy_MHz TSC_MHz IRQ     SMI     POLL    C1      C1E     C6      POLL%   C1%     C1E%    C6%     CPU%c1  CPU%c6  CoreTmp PkgTmp  PkgWatt RAMWatt PKG_%   RAM_%
-       -       -       0       0.05    810     2195    2285    0       0       580     140     1364    0.00    0.57    0.40    98.98   2.96    97.00   41      43      41.72   39.62   0.00    0.00
0       0       0       0       0.05    801     2195    40      0       0       0       2       37      0.00    0.00    0.01    99.94   0.78    99.17   37      39      21.61   21.51   0.00    0.00
0       0       20      0       0.02    805     2195    30      0       0       0       2       20      0.00    0.00    0.01    99.97   0.82

 

출력 필드 설명

필드명 설명
usec
  • 각 CPU에 대해 카운터 수집 중 경과된 시간(마이크로초)
  • 기본적으로 비활성화
  • --enable usec 또는 --debug로 활성화 가능
Time_Of_Day_Seconds
  • 각 CPU 별 gettimeofday(2) 값
  • 측정 종료 시 시간
  • 기본적으로 비활성화
  • --enable Time_Of_Day_Seconds 또는 --debug로 활성화 가능
Core
  • 프로세서 코어 번호
CPU
  • Linux CPU 번호
Package
  • 프로세서 패키지 번호
  • 패키지란 두 개 이상의 독립 코어를 단일 집적 회로로 이룰 때 사용
Avg_MHz
  • 평균 클럭 속도
  • 실행된 사이클 수를 경과 시간으로 나눈 값
Busy%
  • CPU가 명령을 실행하는 시간(백분율)
Bzy_MHz
  • CPU가 idel 상태가 아닌 동안의 평균 클럭 속도
TSC_MHz
  • TSC가 실행 된 평균 MHz
  • TSC는 Time Stamp Counter의 약어
  • CPU 차원에서 제공되는 카운터
  • CPU가 리셋된 이후 동작한 CPU 사이클의 수
IRQ
  • 측정 주기 동안 CPU가 처리한 인터럽트 수
  • /proc/interrupts 이용
SMI
  • 측정 주기 동안 CPU를 지원하는 SMI 인터럽스 수
  • CPU 단위 이지만 모든 프로세서에서 SMI가 트리거 되기 때문에 모든 CPU 값이 동일해야 함
  • SMI는 System Management Interrupts의 약어
C1, C2, C3...
  • 측정 주기 동안 C1, C2, C3 idle 상태를 요구한 횟수
  • c0: CPU가 켜져 있고 미작동 상태
  • c1: 자동 정지, 프로세서가 명령을 수행 하지는 않지만 실행 상태로 즉각 돌아갈 수 있음
  • c2: 스톱 클럭, 프로세서는 몯믄 소프트웨어 표시 상태를 유지 하지만 깨우기에 시간이 더 걸림
  • c3: 딥 슬립, 프로세서는 캐시의 일관성을 유지할 필요 없지만 다른 상태 유지 관리
  • c4: 더 깊은 슬립, VCC 감소, VCC ==> main cpu voltage(전압)
  • dc4: 더 깊은 c4 슬립 VCC 감소
%c1, %c2, %c3
  • 프로세서가 C1, C2, C3 상태였던 비율
CPU%c1, CPU%c2,
CPU%c3
  • 각 idle 상태로 있는 비율
  • H/W residency counter에서 획득 한 값
CoreTmp
  • Core 당 디지털 열 세선에 의해 보고 된 섭씨 온도
PkgTtmp
  • 패키지 당 패키지 열 모니터에 의해 보고 된 섭씨 온도
GFX%rc6
  • 측정 주기 동안 GPU가 렌더링 c6 상태에 있는 시간(백분율)
  • /sys/class/drm/card0/power/rc6_residency_ms 에서 획득
GFXMHz
  • 측정이 끝날 시점의 sysfs의 스냅샷
  • /sys/class/graphics/fb0/device/drm/card0/gt_cur_freq_mhz 에서 획득
Pkg%pc2, Pkg%pc3,
Pkg%pc6, Pkg%pc7
  • H/W 패키지 idle 상태 비율(백분율)
  • H/W residency counter에서 획득
PkgWatt
  • 전체 패키지에서 소비한 전력량(Watt)
CorWatt
  • 패키지의 core에서 소비한 전력량(Watt)
GFXWatt
  • 패키지의 그래픽 부분에서 소비한 전력량(Watt)
  • 클라이언트 프로세서에서만 사용 가능
RAMWatt
  • DRAM DIMMS에서 소비한 전력량(Watt)
  • 서버 프로세서에서만 사용 가능
PKG_%
  • RAPL throttling이 패키지에서 활성화 된 비율
  • RAPL는 Running Average Power Limit의 약어
RAM_%
  • RAPL throttling이 DRAM에서 활성화 된 비율

 

 

※ 참고

1. SMI (System Management Interrupt)

  • SMI를 통해 하드웨어가 트리거됨
  • 프로세서 칩에 물리적 핀(Pin)이 있음
  • SMI (System Management Interrupt)를 활성화되면 프로세서가 SMM으로 들어가게됨

 

2. gettimeofday(2) 함수

  • 1970-01-01 00:00:00 +0000 (UTC) 이후의 현재까지의 경과된 초와 micro초(백만분의 1초) 값을 얻는 함수
  • 정밀한 시간 정보가 필요한 경우에 사용
  • tz(timezone) 정보는 사용하지 않으므로 무시됨

 

human time에서 unix time으로 변환 코드 예시

$ vi unix_time_to_real_time_convert.py
#! /bin/python3
from datetime import datetime, date, timedelta
from time import localtime, strftime, time


# unix time -> real time
def unix_time_to_real_time_convert(unix_time):
    local_tuple = localtime(unix_time)
    time_format= '%Y-%m-%d %H:%M:%S'
    time_str = strftime(time_format, local_tuple)
    return time_str


# real time을 unix time으로 변경 -> 2022년 07월 20일 23시 59분 59초의 real time을 unix time으로 변환
# 아래 출력 결과 : 1658329199
print(real_time_to_unix_time_convert('2022-07-20'))

unix time에서 human time으로 변환 코드 예시

$ vi real_time_to_unix_time_convert.py
#! /bin/python3
from datetime import datetime, date, timedelta
from time import localtime, strftime, time


# real time -> unix time
# (날짜를 구분할 때 '-'을 사용)
def real_time_to_unix_time_convert(real_time):
    time_year = real_time.split('-')[0]
    time_month = real_time.split('-')[1]
    time_day = real_time.split('-')[2]
    real_time = datetime(int(time_year),int(time_month), int(time_day), 23, 59, 59)
    time_str = int(real_time.timestamp())
    return time_str


# unix time을 real time으로 변경 -> 1658129100의 unix time을 real time으로 변환
# 아래 출력 결과 : 2022-07-18 16:25:00
print(unix_time_to_real_time_convert(1658129100))

  • 파이썬을 자주 사용하는 경우 if name == 'main': 을 코드에서 자주 보게 됨
    if __name__ == '__main__':
      코드
  • __name__은 모듈의 이름이 저장되는 변수
  • 파이썬 인터프리터로 스크립트 파일을 직접 실행했을 때는 모듈의 이름이 아니라 __name__에 '__main__'이 들어감
  • import로 모듈을 가져왔을 때 모듈의 이름이 '__main__'에 들어감
  • 어떤 스크립트 파일이든 파이썬 인터프리터가 최초로 실행한 스크립트 파일의 __name__에는 '__main__'이 들어감
  • __name__ == '__main__'은 프로그램의 시작점(entry point)을 의미

__name__의 대한 설명 및 예시

  • __name__는 스크립트 파일이 실행되는 상태를 파악하기 위해 사용
  • 테스트를 통해 hello.py 파일과 main.py 파일의 __name__ 변수 값이 출력
  • 파이썬에서 import로 모듈을 가져오면, 모듈 파일을 한 번 실행함 → hello 모듈을 가져오면 hello.py 안의 코드가 실행
  • hello.py의 __name__ 변수에는 'hello'가 들어가고, main.py의 __name__ 변수에는 '__main__'이 들어감
  1. hello.py 파일에 __name__ 등록
    hello.py
    print('hello 모듈 시작')
    print('hello.py __name__:', __name__)    # __name__ 변수 출력
    print('hello 모듈 끝')
  1. main.py 파일에 __name__ 등록

    main.py
    import hello    # hello 모듈을 가져옴
    
    print('main.py __name__:', __name__)    # __name__ 변수 출력
  1. main.py 파일 실행
    # 실행 결과
    $ python3 main.py
    hello 모듈 시작
    hello.py __name__: hello
    hello 모듈 끝
    main.py __name__: __main__
  1. hello.py 모듈을 main.py 파일에서 import한 예시
  1. hello.py 파일을 실행 → hello.py 스크립트가 실행되기에 hello.py가 main이 됨
    • hello.py 파일의 name 변수에는 'hello'가 아니라 'main'이 들어갑니다
      $ python3 hello.py
      hello 모듈 시작
      hello.py __name__: __main__
      hello 모듈 끝
  1. hello.py 파일을 실행하였을 때 예시

참고 URL : https://dojang.io/mod/page/view.php?id=2448

  • 파이썬으로 pip, pip3명령으로 설치 시 egg_info 실패가 발생 가능
  • egg_info 에러는 setuptools에서 에러가 발생한 것
  • setuptools을 업그레이드 하면 해결 가능

증상: pip install시 에러 Command python setup.py egg_info failed with error code 1


해결: pip setuptools 재설치 → root 권한 필요

$ pip3 install --upgrade --ignore-installed pip setuptools

pip setuptools 재설치 후 pip3로 패키지 재설치 시 정상 확인

# requests 패키지 설치
$ pip3 install requests

참고 URL : https://melonicedlatte.com/android/2018/05/21/221524.html
참고 URL : https://musclebear.tistory.com/131

+ Recent posts