히포

1. 리눅스 디렉터리 및 저장 내용

2. 리눅스 설치 필요 정보

2.1. 하드웨어

2.2. 네트워크 설정

• 호스트명, 도메인, 컴퓨터 IP주소, 서브넷 마스크, 게이트웨이 주소, DNS 서버 주소

3. 커널

3.1.커널이란 

• 운영체제의 핵심 부분으로 CPU나 메모리, 기타 디바이스 등의 시스템 자원을 관리하고 하드웨어와 응용 프로그램 사이에서 인터페이스를 제공하는  역할
  
  
• 커널 기능
  1. 하드웨어 리소스(CPU, 메모리, 스토리지 등) 관리
  2. 소프트웨어에서 하드웨어 및 리소스에 대한 액세스를 추상화

3.2. 커널 역할 및 기능

• 추상화  
   • 물리적으로 하나 뿐인 하드웨어를 여러 사용자들이 번갈아 사용하게 중재함으로써 마치 한 개의 하드웨어가 여러 개인 것처럼 보여지도록 하는 기술
   • 물리적 자원을 추상화하여 쉽게 접근할 수 있도록 도와주는 것

• 디바이스 관리
  •  디바이스 드라이버라는 하드웨어 입출력 제어하는 소프트웨어를 이용하여 장치 관리
  
  
• 프로세스 관리
  • 리눅스에서는 프로그램 실행 시 파일 시스템 내 특정 디렉터리에 있는 프로그램의 파일을 읽어와 메모리에 적재 →프로그램이 메모리에서 실행되는 프로세스 
  •  프로세스가 이용할 수 있는 CPU는 하나로 동시에 실행되는 프로세스 간 CPU를 이용할 수 있는 시간 분배 필요 → 커널은 각 프로세스 PID를 통해 관리하는 역할
  
  
• 메모리 관리
  • 사용자 프로그램의 요구에 따라 메모리 영역을 분배하거나 이용이 끝난 메모리 영역 회수 등을 담당 
  • 가상 메모리 또한 지원(가상 메모리 영역 → swap)
  
  
• 시스템 콜
  • 표준 출력이나 파일 쓰기/읽기, 프로세스를 포크(프로세스 복제)하는 기능 등을 갖고 있어 사용자 프로그램에서 액세스 할 수 있도록 도움을 주는 역할

4. 하드웨어, CPU 작동 모드, 저장 장치의 특징, 소프트웨어

4.1. 하드웨어 목록

4.2. CPU 작동 모드

4.3.  저장 장치의 특징

4.4. 소프트웨어 목록

참고 자료 : https://www.devkuma.com/docs/linux/kernel/basic1/

작업 예약 스케줄러 파일인 cron

• 특정한 시간에 또는 특정 시간마다 어떤 작업을 자동으로 수행하게 해주고 싶을 때 사용하는 명령어
• cron은 특정한 시간에 특정한 작업을 수행하게 해주는 스케줄링 역할

1. 시스템 크론(system cron)

• cron 시스템에는 시스템에서 기본적으로 사용하는 cron 설정
• 시스템 운영에 필요한 작업은 root 권한으로 /etc/crontab에 등록해서 주기적으로 수행 가능

2. 사용자 크론(user cron)

• root나 일반 사용자가 자신의 cron 설정을 직접하여 사용
• 사용자는 crontab이라는 명령을 수행해서 등록
  
  
  

cron과 관련된 여러 파일들

1. cron

• /usr/sbin/cron → 크론 데몬 파일

2. crontab

• cron 작업을 설정하는 파일 → crontab 파일
• cron 프로세스는 /etc/crontab 파일에 설정된 값을 읽어서 수행
• crontab 파일은 OS에 따라 저장되는 위치가 다를 수 있음

• crontab의 파일 내용
  1. m h dom mon dow user command
  2. 분 시 일 월 요일 사용자 실행명령 → crontab의 형식
  3. *의 의미는 every
  4. 25 6 * * * root test -x /usr/sbin/anacron ~
  5. 6시 26분마다 root 사용자가 test -x /usr/sbin/anacron ~ 명령 실행
     

     

3. /usr/sbin/anacron

• cron과 비슷한 동작을 할 수 있게하는 프로그램
• 서버가 일정 시간 중지되었을 때에도 작업이 실행되는 것을 보장하기 위해 사용하는 도구

4. /etc/cron.daily, /etc/cron.hourly, /etc/cron.weekly, /etc/cron.monthly

• 시스템 크론 설정 디렉토리
• cron은 주기적으로 실행할 내용을 시스템 크론 설정 디렉토리에 넣어 놓고 작동
  

  

5. /var/log/cron

• 크론 실행 내용이 기록되는 로그 파일

6. /etc/cron.allow, /etc/cron.deny

• 크론 접근을 허용할 ID, 크론 접근을 허용하지 않을 ID 등을 설정
  
  
  

cron 동작 방식, cron 실행 흐름

• cron 동작 방식을 보면 cron 데몬(crond)가 crontab을 참조
• cron 데몬은 어떤 task를 언제 어떻게 수행할 지를 crontab에서 찾아서 실행
• cron 데몬은 시스템 스케줄러 정보 뿐만 아니라 각각 사용자가 설정한 작업 예약 정보도 crontab에서 확인
  

  

• cron 파일이 데몬이기 때문에 부팅시 백그라운드로 실행

  $ ps -ef | grep cron

  

crontab 설정 형식(crontab 파일의 7 필드)

• m h dom mon dow user command 설명
  

  

crontab 설정 값에 사용할 기호

1. * (별표)

• 각 필드 자리에 * 기호가 오면 해당 필드의 모든 값을 의미
• 두 번째 필드에 *가 오면 매 시간 마다
• 세 번째 필드에 *가 오면 매일
• 네 번째 필드에 *가 오면 매월

2. - (하이픈)

• 그 사이의 모든값을 의미
• 세 번째 필드에 '1-5' 값이 오면 1일, 2일, 3일, 4일, 5일 의미

3. , (쉼표)

• 지정한 모든 값을 의미
• 불규칙적인 값 지정할 때 주로 사용
• 두 번째 필드에서 "1,3,4"는 1시, 3시, 4시를 의미

4. / (슬래시)

• 연결된 설정 값 범위에서 특정 주기로 나눌 때 사용

• 일반적으로 FTP 서버를 이용한 파일 전송은 보안 기능이 적용 X
• 안전한 파일 전송을 위해 사용하는 가장 일반적인 방법 → SFTP와 FTPS를 사용

SFTP

• SFTP는 암호화된 SSH 연결을 이용
• SFTP는 서버 접속, 파일 전송, 그리고 파일 관리를 지원하기 위해 IETF(Internet Engineering Task Force)에서 개발한 네트워크 프로토콜
• SFTP를 사용하기 위해선 SSH2 프로그램을 설치한 후에 활성화 필요

SFTP의 특징

1. 안전한 파일 전송
   • SFTP는 안전한 파일 전송을 위해 SSH로 연결을 암호화

2. 안전한 FTP 서버 접속
   • 안전한 서버 접속을 위해 인증 방법으로서 패스워드 뿐만 아니라 공개키(Public Key)를 이용한 접속을 지원

3. 대부분의 플랫폼에서 사용 가능
   • SFTP는 Windows, Unix, linux 등 대부분의 플랫폼에서 지원

4. SSH 서버가 제공하는 프로그램 (VSFTP 서버와 별개)
   • VSFTP 서버와 별개의 프로그램이지만, 안전한 파일 전송을 지원한다는 점에서 FTP와 동일한 역할

SFTP 서버 설정

1. OpenSSH 패키지 다운

• sftp 명령어를 사용하려면 SSH 패키지가 필요
• OpenSSH 패키지를 설치하면 SSH 패키지를 설치 가능

  $ yum install openssh-server openssh -y

2. SSH 서버의 설정 파일 변경

• /etc/ssh/sshd_confg 파일을 수정

• 기존에 있던 설정을 internal-sftp로 변경 (아래에 설명)

  $ vi /etc/ssh/sshd_config
  
  # 기존에 있던 Subsystem을 주석처리하고 새로운 Subsystem을 추가
  # override default of no subsystems
  # Subsystem     sftp    /usr/libexec/openssh/sftp-server
  Subsystem       sftp    internal-sftp
  
  # Example of overriding settings on a per-user basis
  Match User sftp-users
      X11Forwarding no
      AllowTcpForwarding no
  #  ChrootDirectory /home/%u
      ForceCommand internal-sftp

3. /etc/ssh/sshd_config 파일 내 적용 요소 설명

1. #Subsystem sftp /usr/libexec/openssh/sftp-server
   • 서브시스템으로 사용되던 기존 sftp 프로그램을 사용 X → 앞에 주석 추가

2. Subsystem sftp internal-sftp
   • SSH 서버에서 외부 프로그램을 사용
   • 키워드 Subsystem에 이름 sftp와 명령어 internal-sftp를 지정
   • internal-sftp는 Match Group sftp-users의 ChrootDirectory 옵션을 사용해 각 사용자 별로 chroot를 적용하기 위해 sftp-server 대신 사용

3. Match Group sftp-users
   • sftp를 사용할 그룹 이름과 옵션을 정의
   • 그룹 안에 속한 사용자들은 ssh 및 scp를 사용 불가능 → 오직 sftp만 사용 가능
     1. X11Forwarding no → ssh 접속해서 GUI 기반의 어플리케이션 실행 X
     2. AllowTcpForwarding no → TCP 포워딩을 불가능
   • chroot를 적용돼 자신의 홈 디렉토리를 루트(/) 디렉토리로 인식
     1. ChrootDirectory는 root로 적용될 디렉토리 위치를 지정
     2. %u → 인증된 사용자의 사용자 이름을 지정
   • ForceCommand internal-sftp → internal-sftp를 강제 명령으로 실행

4. 그룹 생성 및 그룹에 사용자 포함

• SFTP 사용이 적용될 그룹 sftp-users를 생성하기 위해 명령어 groupadd를 사용

• 그룹을 만든 후 사용자를 그룹에 포함 → 예시 : hippo 사용자

• hippo 사용자의 홈디렉토리에 그룹 회원들이 접속할 수 있도록 권한을 변경

  # 변경한 /etc/ssh/sshd_config을 새로 적용
  $ systemctl restart sshd
  
  # sftp-users 그룹 생성
  $ groupadd sftp-users
  
  # sftp-users 그룹에 root 사용자를 추가
  # usermod -g sftp-users root를 하면 그룹 하나만 속함 -> 사용 X
  $ usermod -aG sftp-users root
  $ id root
  uid=0(root) gid=0(root) groups=0(root),10(wheel),1000(sftp-users)
  
  # hippo 사용자가 없기에 새로 추가 필요
  $ id hippo
  id: hippo: no such user
  
  # hippo 사용자 추가
  $ adduser hippo
  $ passwd hippo
  
  # sftp-users에 hippo 사용자 추가
  $ usermod -aG sftp-users hippo
  
  # hippo 사용자가 정상적으로 생성되고 sftp-users에 들어있는 지 확인
  # wheel 그룹에 속하려면 /etc/group의 wheel에 hippo를 추가해야 함
  $ id hippo
  uid=1000(hippo) gid=1001(hippo) groups=1001(hippo),10(wheel),1000(sftp-users)
  
  # 권한 변경
  $ chmod 755 /home/hippo
  
  $ ls -al /home
  drwxr-xr-x   2 hippo hippo 4096 Jan 30 21:54 hippo

리눅스 SFTP 클라이언트 테스트

• 접속하는 윈도우 SFTP 클라이언트

• 리눅스 클라이언트로 이용하여 테스트

• 리눅스 SFTP 접속 → IP 접속을 허용해줘야 함 (ACL 정책 확인 필요)

  $ sftp -P 22000 root@[서버 IP] 
  root@[서버 IP]'s password: 
  Connected to [서버 IP]. 
  
  # SFTP 접속 위치의 파일 확인 
  sftp> ls 
  test.sh   time 
  
  # SFTP 현재 위치 확인 
  sftp> pwd 
  Remote working directory: /root 
  
  # SFTP 접속 해제 
  sftp> exit`

C/G/S/P states

• intel_idle과 관련된 내용을 다루기에 앞서 P-States와 C-States에 대해서 간단히 정리
• Intel 아키텍처 환경에서 리눅스 커널과 CPU를 알아가다보면 P/S/G/C States에 대한 학습 필요

1. P-States

• P-States는 작업 부하에 따라서 CPU의 전압과 클럭주파수를 조절하는 정도를 정의 한 값
• 명령어 처리(Operation)상태를 기준으로 절전 및 성능 향상을 꾀하기 위한 기법
• 과거에는 SpeedStep이라는 기술로 소개 되었지만 정확히 같은 것은 아님
• P-States는 단순히 클럭주파수를 조절해서 에너지 절약을 위한 방안으로만 치부되었는데 CPU가 연산처리를 할 때의 상태를 반영
• 최근 사용되는 Intel CPU의 Turbo Boost 상태는 P-State 0(P0)를 의미

2. C-States

• C-States는 CPU 내부의 특정 부분이 활성화되거나 낮은 성능 상태로 실행될지를 반영하는 값
• CPU에서 사용중이 아닌 부분들을 비활성화하여 전원의 효율화를 높이기 위한 상태 값
• P-State와 다르게 C-State는 유휴(Idle)상태를 기준으로하여 평가
• C0는 활성화된 일반적인 상태를 의미하며, C0 상태에서 P0~Pn 상태로 나누어서 볼 수 있음
• Nehalem Microarchitecture(네할램)부터는 C6 상태가 추가되었는데 C6는 각종 작업들을 저장하고 이미 작동을 멈춘 CPU 코어에 공급되는 전원을 차단하는 상태
• Sandy Bridge Microarchitecture(샌디브리지)에서 C7이 추가되었고 이는 C6에서 추가로 L3캐시까지 비워버린(Flush) 상태를 의미

3. G-States

• Global States를 의미
• 사용자가 인지할 수 있는 상태를 반영
• G0는 동작상태 (전원 On)
• G1은 잠자기모드 상태
• G3는 전원 Off 상태

4. S-States

• Sleep States를 의미
• G1에서 세부적인 잠자기모드 상태를 나타냄

5. Processor Power States → 상태들을 알아보기 쉽게 도식화

intel_idle → Idle 상태를 관리

• C-States와 관련이 있는 모듈
• intel_idle이 사용되기 이전에는 C-States를 OS에서 관리하기 위해서 acpi_idle이란 모듈이 사용
• 기존 acpi_idle 모듈의 경우 C-State latency와 관련하여 정확도도 높지 않았고 기본적으로 BIOS 설정에 따라서 주어진 환경 내에서만 상태를 변경하는 정도로 효과 X
• intel_idle의 경우 BIOS 설정에 직접적으로 개입하여 C-State를 조절하는 모듈
• 서버시스템의 경우 빠른 응답속도를 목표로하기 때문에 소위 Performance 모드로 통칭되는 BIOS 설정상태를 유지하여 CPU가 잠들지 않도록 하는 설정하였지만, C-State를 커널이 개입하여 CPU 상태를 제어해 버리면 성능에 문제가 있을 수 있음
• 하드웨어에서 Performance이지만 커널에서 C6으로 C-State가 설정되어있으면 C6 상태에 있던 CPU가 C0 상태로 만들기 위한 시간(Wake-up time)이 소모되어 성능 저하 발생
• intel_idle 모듈 설정을 통해 BIOS 설정과 무관하게 커널의 C-State를 조절 필요

Idel 상태 관리 방법

• intel_idle.max_cstate 파라미터를 통해 C-State의 상태를 결정하거나 비활성화하여 apci_idle 사용가능
• 커널 부팅 파라미터에 intel_idle.max_cstate=0 값을 설정하면 apci_idle을 사용하여 하드웨어의 C-State로 부팅
• 커널파라미터의 경우 rebooting의 부담이 있기 때문에 기존에 운영하는 장비도 적용 할 수 있도록 tuned의 profile을 이용한 설정

1.커널 매개 변수로 intel_idle.max_cstate=0을 적용

• grub 파일을 쓰고 있다면, /etc/default/grub 파일에 intel_idle.max_cstate=0를 설정한 후 설정 적용(재부팅 가능)

• GRUB_CMDLINE_LINUX="crashkernel=auto spectre_v2=retpoline rhgb quiet" 항목에 intel_idle.max_cstate=0 추가

  # /etc/default/grub 파일 수정
  $ vi /etc/default/grub
  GRUB_TIMEOUT=5
  GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
  GRUB_DEFAULT=saved
  GRUB_DISABLE_SUBMENU=true
  GRUB_TERMINAL_OUTPUT="console"
  
  # 변경 전 내용 : GRUB_CMDLINE_LINUX="crashkernel=auto spectre_v2=retpoline rhgb quiet"
  # 아래 변경 후 내용
  GRUB_CMDLINE_LINUX="crashkernel=auto spectre_v2=retpoline rhgb quiet intel_idle.max_cstate=0"
  GRUB_DISABLE_RECOVERY="true"
  
  # /etc/default/grub 파일 적용
  $ grub2-mkconfig -o /boot/grub2/grub.cfg
  $ reboot

※ 참고

• 재부팅 후 intel_idle이 정상적으로 적용되었는지 확인 필요

  $ dmesg | grep -i intel_idle

2. tuned의 profile의 latency-performance의 profile을 이용한 설정

• tuned의 profile 중 latency-performance의 profile을 통해 커널파라미터의 경우 리부팅의 부담을 줄이고 C-state 변경 작업 적용
• 아래 결과를 통해 C7 상태까지 떨어지던 idle 상태가 C1이하로 내려가지 않는 것 확인

  $ tuned-adm profile latency-performance

• latency-performance 적용 전
  

  

• latency-performance 적용 후
  

  

3. E3/E5 계열(샌디브리지)의 CPU는 바로 적용이 되었으나 C6까지있는 네할렘 CPU에는 바로 적용 불가

• 실제 장비들을 샘플링하여 테스트 해 본 결과 tuned-adm을 설정하더라도 E3/E5 계열(샌디브리지)의 CPU는 바로 적용이 되었으나 C6까지있는 네할렘 CPU들은 적용 불가
• 네할렘 CPU에 C6은 계속 출력되는 것 확인
  

  

• /dev/cpu_dma_latency 장치(4바이트 값을 갖는 장치)에 직접 latency 값을 100으로 설정

  $ exec 3> /dev/cpu_dma_latency
  $ echo -ne '\0144\000\000\000' >&3

• 네할렘 CPU에 C3까지 출력되는 것 확인 → /dev/cpu_dma_latency 변경 확인
  

  

※ 아래 참조한 자료는 RHEL6 버전으로 RHEL7을 확인 필요

1. 참조 URL : https://lunatine.net/2015/01/06/rhel6-intel_idle-and-c-states/
2. 리눅스 ( Tuned 데몬을 이용한 OS 튜닝) 튜닝 참고 URL : http://justinsona.blogspot.com/2016/11/tuned-os.html

P-State란

• P-State는 시스템이 동작하는 동안, CPU의 클럭 주파수를 조절하여 어느 정도의 Performance로 CPU를 작동시킬 것인지 결정
• Intel의 X86 프로세서에서 P-State 기능을 SpeedStep이라는 이름으로 사용
• 리눅스는 P-State 기능을 "/sys/devices/system/cpu/cpu#/cpufreq/" 에 존재하는 파일을 이용하여 조절
• P-State는 시스템의 클럭수를 조절하여 동적으로 전체 시스템의 전력 소모를 조절
• CPU P-State는 Performace 상태로 정의된 voltage-frequency 제어 상태를 나타냄
• voltage-frequency 제어에서 회로를 구동하는 전압(voltage)과 클록(clock)은 작업 부하에 따라 증가하거나 감소함
• 운영 체제는 현재 작업 부하(workload)를 기반으로 특정 P-State를 요청
• 프로세서는 요청을 수락하거나 거부하고, 자체 상태를 기반으로 P-State를 설정 가능
• P-State는 프로세서가 지원하는 frequency와 수집 기간 동안 각 frequency에서 소요된 시간을 나타냄
• P-State에서는 SpeedStep, Speed Shift가 CPU의 클럭을 관리
  

  

P-State 핵심

• P-State가 CPU frequency를 떨어뜨려서 전력 소모를 줄이는 방법
• CPU 사용량이 적을때 CPU 코어의frequency를 떨어뜨려서 적은 voltage으로 CPU를 동작할 수 있게 하기 위해 사용
• CPU 코어 frequency와 voltage를 미리 정의 → 요청사항이 많을 때는 최대 frequency로 설정, 요청사항이 적은 때는 낮은 frequency로 동작
• Intel 계열 CPU에서는 SpeedStep이라는 이름을 사용
  
  
• Linux 상에서 cpufreq라는 인터페이스를 통해서 SpeedStep 기능 제어 → CPU frequency governor는 cpufreq로 frequency 결정
  1. cpufreq_performance → 전력은 많이 소비하지만 항상 최대의 성능으로 동작
  2. cpufreq_powersave → 최대한 전력을 아끼는 방법으로 동작
  3. cpufreq_ondemand → 주파수의 범위를 정해주고 부하 상황에 맞게 가변적으로 동작

P-State(active) 상태의 전원 관리

1. 스피트스텝(SpeedStep)

• 스피드 스텝 기술은 P-State를 제어하는 기술
• 인텔에서 개발한 기술
• CPU에 걸린 부하에 따라서 자동으로 클럭을 조절해주는 기술
• 배터리 소모량을 유연하게 조절하여 사용시간을 늘려주는 장점이 있지만, 클럭 조정시에 일시적으로 버벅임이 발생 가능
• SpeedStep의 주요 통제권은 OS가 가지고 있음
  
  
• 스피트스텝(SpeedStep) 작동원리
  1. 오피스 소프트웨어 이용하여 문서작업 등 비교적 부하가 낮게 걸리는 작업에서 CPU의 속도를 고의로 낮추어 작동
  2. HD급 동영상 재생 등 부하가 심하게 걸리는 작업에서는 CPU의 속도를 낮추지않는 방식으로 작동

2. 스피드 쉬프트(Speed Shift)

• 스카이레이크 마이크로 아키텍쳐를 가진 CPU 이후부터는 스피드 스텝을 하드웨어 단에 적용한 스피드 시프트 기술이 적용
• 베이스 클럭에서부터 터보 부스트 영역까지 확장된 기술
• 마이크로프로세서 안의 PCU(Power Control Unit)이라는 하드웨어가 밀리초 단위로 정해진 알고리즘에 따라 계산하면서 최적의 CPU 클럭과 전압으로 관리
• 스피드 쉬프트 기술을 이용하려면 OS에서 지원을 해야 사용 가능
• 스피드 시프트를 지원하지 않는 OS에서는 스피드 스텝으로 작동
• Speed Shift는 Speedstep과 달리 OS가 CPU 제어권을 대부분 PCU1에 넘겨 CPU의 클럭을 유동적으로 조절
• Speedstep과 비교하여 하드웨어적인 방식을 사용하기 때문에, CPU 클럭 제어 속도가 빨라졌고, 더욱 정밀한 클럭 계산이 가능해져 더 적은 에너지를 사용
• Speedstep이 20~30ms에 걸쳐 최대 클럭을 올릴 때, SpeedShift는 5~7ms만에 최대 클럭까지 도달 → 최대 50% 더 빠른 변속을 보여줌
• Speedstep과 Speed Shift는 동시에 적용 X

CPU frequency governor 이란

• CPU는 여러 주파수에서 동작이 가능하도록 설계되어 있으나, 리눅스 커널 대부분의 cpufreq 드라이버들은 CPU를 하나의 주파수로 설정
• CPU의 사용량이 많지 않으면 저속으로 많아지면 고속으로 동작할 필요가 있음
• 동적 주파수 확장을 제공하기 위해서 타겟 주파수를 드라이버에 알려줄 것이 필요가 있음
• CPU frequency governor는 CPUfreq policy내에서 무슨 주파수를 사용할 것인지 결정
• CPUfreq policy는 주파수 제한과 사용될 governor로 구성
• DB 서버에 CPUfreq policy가 활성화되어 있다면 CPU 주파수가 떨어질 때 쿼리 응답 속도가 갑자기 늘어난다던가 하는 이슈가 발생 가능
  
  

1. governor 종류

1. Performance→ CPU를 최고 주파수로 설정
2. Powersave→ CPU를 최저 주파수로 설정
3. OnDemand→ 현재 사용량에 따라 CPU frequnecy를 설정. CPU는 주파수를 빠르게 변경할 능력이 필요

2. 현재 설정된 governors 확인

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

3. 사용가능한 설정

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance powersave

4. governors 변경 → /sys/devices/system/cpu/ -> cpu[n] n 수만큼 다 변경해야함

# 먼저 CPU 개수 확인
$ cat /proc/cpuinfo | grep -i "^processor"
processor       : 0
processor       : 1
processor       : 2
processor       : 3
processor       : 4
processor       : 5
processor       : 6
processor       : 7
processor       : 8
processor       : 9
processor       : 10
processor       : 11
processor       : 12
processor       : 13
processor       : 14
processor       : 15
processor       : 16
processor       : 17
processor       : 18
processor       : 19
processor       : 20
processor       : 21
processor       : 22
processor       : 23
processor       : 24
processor       : 25
processor       : 26
processor       : 27
processor       : 28
processor       : 29
processor       : 30
processor       : 31
processor       : 32
processor       : 33
processor       : 34
processor       : 35
processor       : 36
processor       : 37
processor       : 38
processor       : 39

$ echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
$ echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
$ echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
#.... 중략....
$ echo performance > /sys/devices/system/cpu/cpu39/cpufreq/scaling_governor

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 접속(정확히는 네트워크 연결) 과정에 지연이 발생

• C-State 참고 자료 : http://emal.iptime.org/noriwiki/index.php/C-state
• DELL 참고 자료 : https://www.dell.com/support/kbdoc/ko-kr/000060621/c-state%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

• 리눅스에서는 서버에 접속실패 정보와 접속정보를 기록

접속 실패 로그 확인 → btmp

• ssh 접속 시도 실패 로그는 /var/log/btmp 파일에 특수하게 저장

• /var/log/btmp는 바이너리 파일로 이루짐

• /var/log/btmp 파일을 보기 위해서는 last -f 명령을 이용하여 확인 가능

• lastb 명령어는 last -f /var/log/btmp와 동일한 결과 출력

  $ last -f /var/log/btmp
  root     ssh:notty    [시스템 IP]    Tue May 25 03:07 - 09:57  (06:50)
  root     ssh:notty    [시스템 IP]    Tue May 25 03:07 - 03:07  (00:00)
  root     ssh:notty    [시스템 IP]    Tue May 25 00:52 - 03:07  (02:15)
  
  $ lastb
  lastb
  root     ssh:notty    [시스템 IP]    Tue May 25 03:07 - 03:07  (00:00)
  root     ssh:notty    [시스템 IP]    Tue May 25 03:07 - 03:07  (00:00)
  root     ssh:notty    [시스템 IP]    Tue May 25 00:52 - 00:52  (00:00)

  
  
  

접속정보 기록 확인 → wtmp

• 성공한 로그인/로그아웃 정보 및 시스템의 boot/shutdown의 히스트리 정보를 파일로 저장
• /var/log/wtmp는 바이너리 파일로 이루짐
• /var/log/wtmp 파일을 보기 위해서는 last -f 명령을 이용하여 확인 가능
• last 명령어는 last -f /var/log/wtmp와 동일한 결과 출력

  $ last -f /var/log/wtmp
  root     pts/0        [시스템 IP]    Mon Jun 21 23:11   still logged in
  root     pts/0        [시스템 IP]    Mon Jun 21 23:01 - 23:10  (00:08)
  root     pts/0        [시스템 IP]    Mon Jun 21 22:37 - 22:37  (00:00)
  root     pts/0        [시스템 IP]    Mon Jun 21 22:31 - 22:36  (00:05)

  
  
  

시스템에 현재 로그인한 사용자들에 대한 상태 정보 → utmp

• 로그파일은 binary 파일로 되어 있어 직접 확인 불가능 → 아래 명령어로 확인 가능
• 로그파일 확인 명령어 : w, who, finger

1. w 명령어

• utmp를 참조하여 출력
• 현재 시스템에 성공적으로 로그인한 사용자정보, 시스템로드 정보 및 uptime 정보 출력

  $ w
  23:34:07 up 145 days, 10:36,  1 user,  load average: 0.00, 0.01, 0.05
  USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
  root     pts/0      [시스템 IP]        23:24    7.00s  0.06s  0.02s w

2. who 명령어

• utmp를 참조하여 출력
• 현재 시스템에 성공적으로 로그인한 사용자의 정보와 접속한 Client IP를 출력

  $ who
  root     pts/0        2021-06-21 23:24 ([시스템 IP])

3. finger 명령어

• 사용자 계정 정보와 최근 로그인 정보, 이메일, 예약 작업 정보 등을 볼 수 있는 명령어

• yum install finger -y로 finger 명령어 설치

  # finger 패키지가 없는 경우 다운 필요
  $ yum install -y finger
  
  # root 사용자 계정 정보 확인
  $ finger root
  Login: root                               Name: root
  Directory: /root                        Shell: /bin/bash
  On since Mon Jun 21 23:24 (KST) on pts/0 from [시스템 IP]
   4 seconds idle
  New mail received Tue May 25 03:08 2021 (KST)
     Unread since Sat Jan 30 21:53 2021 (KST)
  No Plan.

  
  
  

lastlog 명령어

• 각 사용자들이 언제 마지막으로 접속하였는가를 확인
• /etc/passwd 파일에 정의되어 있는 모든 사용자들의 마지막 접속정보를 확인
• lastlog는 /var/log/lastlog 파일의 정보를 출력

1. /etc/passwd 파일에 정의된 모든 사용자의 마지막 접속 정보 확인

$ lastlog
Username         Port     From             Latest
root               pts/0    [시스템 IP]    Mon Jun 21 23:24:25 +0900 2021
bin                                               **Never logged in**
daemon                                        **Never logged in**
[...생략...]

2. 사용자의 마지막 접속 정보

# lastlog -u userid
$ lastlog -u root
Username         Port     From             Latest
root             pts/0    [시스템 IP]    Mon Jun 21 23:48:26 +0900 2021

3. N일 이전에 접속한 정보

# lastlog -b N -> N일 이후에 접속한 기록이 있는 사용자는 제외
$ lastlog -b 10
Username         Port     From             Latest
bin                                            **Never logged in**
daemon                                     **Never logged in**
[...생략...]

4. D일 부터 현재까지 접속한 정보

# lastlog -t D
$ lastlog -t 5
Username         Port     From             Latest
root             pts/0    [시스템 IP]    Mon Jun 21 23:48:26 +0900 2021

• 기본적으로 캐시를 생각하면, 빠르게 읽기 위해서 사용하는 저장공간으로 생각
• 캐시는 쓰기 명령을 수행할 때도 사용 → 아래의 그림처럼 캐시에 Write Buffer라는 걸 두어서 쓰기 성능 향상에 사용
• Write Buffer는 CPU가 쓰기 명령 수행 중에 좀 더 효율적으로 다른 일을 할 수 있도록 해줌
• 쓰기 버퍼 방식은 크게 두 가지가 존재 → Write Through와 Write Back
  

  

Write Through

• Write Through라는 용어는 쓰루 패스와 마찬가지로 Memory에 뭔가를 쓰기 명령을 수행할 때, Cache와 Memory 값을 일치 시켜주는 방식
• CPU가 주기억장치(RAM) 또는 디스크(Disk)로 데이터를 기입하고자 할 때 데이터는 먼저 캐시로 기입 → 데이터가 캐시 됨과 동시에 주기억장치(RAM) 또는 디스크(Disk)로 업데이트하는 구조
• 데이터 로스의 리스크가 있으면 안되는 상황에서는 Write Through를 사용하는 것이 바람직

Write Through 장점

• 캐시와 메모리에 업데이트를 같이 하여, 데이터 일관성을 유지할 수 있어서 안정적
• inconsistency(불일치)현상이 발생 X

Write Through 단점

• 속도가 느린 주기억장치 또는 디스크로 동시에 데이터를 기록
• 완료될 때까지 CPU가 대기하는 시간이 필요하기 때문에 성능이 떨어짐

Write Through를 사용하여 데이터를 처리하는 구조

Write Back

• CPU 데이터를 사용할 때 데이터는 먼저 캐시로 기록되는데, 캐시 내에 일시적으로 저장된 후에 블록 단위에 캐시로부터 해제되는 때(캐시안에 있는 내용을 버릴시) 에만 주기억장치 또는 보조기억장치에 기록되는 방식
• 데이터를 쓸 때 메모리에는 쓰지 않고 캐시에만 업데이트를 하다가 필요할 때에만 주기억장치나 보조기억장치에 기록하는 방법
• 데이터 로스의 리스크를 조금 감수하더라도 빠른 서비스를 요하는 상황에서는 Write Back을 사용하는 것이 바람직

Write Back 장점

• Write Through보다 훨씬 빠름

Write Back 단점

• 속도가 빠른 대신에 캐시에 업데이트 하고 메모리에는 바로 업데이트를 하지 않기 때문에 캐시와 메모리가 서로 값이 다른 경우가 발생 가능
• inconsistency(불일치)
• 캐시에만 써놓고 Device에 값을 안넘기는 경우가 발생하여서 문제 발생 가능
• Write Back 문제를 해결하기 위하여 Cache Flush 또는 Cache clean을 사용

Write Back을 사용하여 데이터를 처리하는 구조

※ 참조

• Cache Flush는 Cache Invalidate(캐시 무효화)로 Cache 안의 내용을 마치 Reset하듯이 정리함
• Cache Clean은 Cache에 있던 내용을 Memory에도 update해줌

Write Back과 Write Through의 성능 차이가 큼(데이터 베이스 로드 처리량 비교)