히포

• error_log off 지시문으로는 로깅을 비활성화 불가 → access_log 지시어와 달리 error_log는 off 매개 변수를 사용하지 않음
• 만약 nginx에 error_log off 지시어를 포함하면 nginx 구성 파일의 기본 디렉토리(/etc/nginx)에 off라는 이름의 에러 로그 파일을 생성됨
   
• error_log 로그는 nginx의 문제를 디버깅할 때 중요한 정보 소스이므로 비활성화하지 않는 것이 좋지 않음
• 만약 스토리지가 너무 제한적이어서 사용 가능한 디스크 공간을 모두 소진할 정도의 경우 오류 로깅을 비활성화하는 것이 좋음
  
  
• main 설정에 error_log 지시어 사용 예시
  

  error_log /dev/null emerg;​

• error_log 지시어
  • 여러 개의 로그를 지정 가능 
  • main configuration 수준에서 로그를 쓰는 것이 명시적으로 정의되어 있지 않으면 기본 파일이 사용
    

    구문 :	error_log file [level];
    기본 :	error_log logs/error.log error;
    문맥 :	main, http, mail, stream, server, location​

     

• error_log 지시어의 매개변수
  1. error_log 첫 번째 매개변수
     • 로그를 저장할 파일을 정의
     • stderr 특수 값은 표준 오류 파일(standard error file)을 선택 
     • "syslog:" 접두사를 지정하여 syslog에 로깅하도록 구성 가능 
     • "memory: size" 접두사와 버퍼 크기를 지정하여 순환 메모리 버퍼에 로깅 구성 가능. 일반적으로 디버깅에 사용
        
  2. erorr_log 두 번째 매개변수
     • 로깅 수준을 결정
     • debug, info, notice, warn, error, crit, alert 중 하나가 될 수 있음
     • 로그 수준(Log levels)은 심각도가 높아지는 순서대로 나열
     • 특정 로그 수준(certain log level)을 설정하면 지정된 로그 수준보다 더 심각한 로그 수준의 모든 메시지가 기록됨 → 예시) 오류 로그(error log)는  error, crit 및 alert  메시지가 기록됨
     • error_log 매개 변수를 생략하면 error가 사용

• error_log 지시어는 nginx가 구성을 읽고 유효성을 검사할 때까지 적용되지 않는다는 점에 유의
• nginx가 시작하거나 구성이 다시 로드될 때마다 구성의 유효성이 검사 → 기본 error log(/var/log/nginx/error.log) 로깅
• 로그 디렉터리를 변경하려면 nginx 명령에 -e <error_log_location> 파라미터를 포함

참고 자료 : Avoiding the Top 10 NGINX Configuration Mistakes - NGINX

• worker_connections 지시어는 nginx의 worker process가 열 수 있는 최대 동시 연결 수를 설정(기본값은 512). 
• 클라이언트 연결뿐만 아니라 모든 유형의 연결(프록시 서버와의 연결)이 최대 연결 수에 포함 → proxy_pass도 포함
• worker당 동시 연결 수에는 다른 제한이 있음 → 각 프로세스에 할당된 File Descriptors(파일 설명자)의 최대 수에 대한 OS 제한 
• 최신 UNIX 배포판에서  File Descriptors(파일 설명자)의 최대 수에 대한 기본 제한은 1024개
• 가장 작은 규모의 nginx 배포를 제외한 모든 배포에서 worker당 512개의 연결 제한은 너무 작을 수 있음 
• 이 문제를 해결하려면 기본 구성 컨텍스트에서 worker_rlimit_nofile 지시어를 사용하여 설정

• worker_rlimit_nofile 지시자
  • worker process의 최대 파일 열기 수 제한(RLIMIT_NOFILE)을 변경 
  • Main Process를 다시 시작하지 않고 제한을 늘리는 데 사용
    

    구문 :	worker_rlimit_nofile number;
    기본 :	—
    문맥 :	main​

• 더 많은 File Descriptors(파일 설명자)가 필요한 이유
  • nginx worker process에서 클라이언트 또는 업스트림 서버로의 각 연결은 File Descriptors를 소비 
  • nginx가 웹 서버로 작동하는 경우, 클라이언트 연결에 하나의 File Descriptors를 사용하고 제공되는 파일당 하나의 File Descriptors를 사용하여 클라이언트당 최소 2개의 File Descriptors를 사용
  • 프록시 서버로 작동하는 경우, nginx는 클라이언트 및 업스트림 서버 연결에 각각 하나의 File Descriptors 사용(2개 사용)하고, 서버의 응답을 임시로 저장하는 데 사용되는 파일에 세 번째 File Descriptors를 사용
  • nginx가 캐싱 서버로 작동하는 경우, 캐시된 응답에 대해서는 웹 서버처럼 작동하고 캐시가 비어 있거나 만료된 경우에는 프록시 서버처럼 작동
  • nginx는 로그 파일당 File Descriptors를 사용하고 Master 프로세스와 통신하기 위해 몇 개의 File Descriptors를 사용 → 일반적으로 몇 개의 File Descriptors 숫자는 연결 및 파일에 사용되는 File Descriptors의 수에 비해 작음

• UNIX는 프로세스당 File Descriptors 수를 설정하는 몇 가지 방법을 제공
  1. nginx를 시작하는 경우 ulimit 명령어
     • ulimit 명령어는 프로세스가 사용하는 자원에 대한 제어 및 관리할 수 있게 해줌
     • ulimit 명령어는 하나의 유저(쉘,프로세스)에 대해서 할당할 자원량의 한계를 정하는 것으로서 리눅스 시스템에서 과부하를 막아주는 방패가 되어 주는 유용한 설정
     • ulimit는 일시적 설정
       

       $ ulimit -n 65536

        
     • soft와 hard 두 가지 타입
       • soft → 새로운 프로그램을 생성하면 기본으로 적용되는 한도
       • hard → soft 한도에서 최대로 늘릴 수 있는 한도
          
  2. nginx를 서비스로 시작하는 경우 init 스크립트 또는 systemd 서비스 manifest 변수 사용
     

     $ vi /etc/systemd/system/nginx.service
     [Unit]
     Description=The NGINX HTTP and reverse proxy server
     After=syslog.target network.target remote-fs.target nss-lookup.target
     
     [Service]
     Type=forking
     PIDFile=/run/nginx.pid
     ExecStartPre=/usr/local/nginx/sbin/nginx -t
     ExecStart=/usr/local/nginx/sbin/nginx
     ExecReload=/usr/local/nginx/sbin/nginx -s reload
     ExecStop=/bin/kill -s QUIT $MAINPID
     PrivateTmp=true
     LimitNOFILE=65535
     LimitNOFILESoft=65535
     
     [Install]
     WantedBy=multi-user.target​​

      
  3. /etc/security/limits.conf 파일 → 유저의 프로세스별 file open을 설정
     • /etc/security/limits.conf 파일은 유저의 프로세스별 사용하는 자원에 대한 제어 및 관리할 수 있게 해줌
     • 할당할 자원량의 한계를 정함으로 리눅스 시스템에서 과부하를 막아줌
       
       
     • /etc/security/limits.conf 파일은 영구적 설정
       

       $ vi /etc/security/limits.conf
       
       ## nginx 사용자 계정에 수치를 지정
       nginx   soft  nofile  1048576
       nginx   hard  nofile  1048576
       nginx   soft  nproc   1048576
       nginx   hard  nproc   1048576
       
       ## *를 사용하여 모든 계정에 수치를 지정
       *   soft  nofile  1048576
       *   hard  nofile  1048576
       *   soft  nproc   1048576
       *   hard  nproc   1048576​

      
  4. sysctl.conf 의 file open 확인 및 커널 설정
     • sysctl.conf에서 시스템 전체에 대한 file open 개수를 설정
       

       $ cat /proc/sys/fs/file-nr
       3072    0       300000
       |         |       |
       |         |       |
       |         |       최대 오픈 파일 디스크립터 수(fs.file-max)
       |        할당되지 않은 파일 디스크립터 수 (2.6 커널에서는 항상 0으로 표기되며 이는 에러 아님)
       할당된 파일 디스크립터 수

        
     • 커널의 fs.file-max 파라미터는 시스템 전체에서 최대로 열 수 있는 파일 개수
     • 커널의 fs.file-max 파라미터는 시스템의 메모리를 KB로 표현한 값의 10%가 적당
     • 커널의 fs.nr_open 파라미터는 하나의 프로세스가 열 수 있는 최대 파일 개수
     • 커널의 fs.nr_open 파라미터는 기본값은 1024*1024 (1048576) → 대부분의 머신에서 충분(Actual limit depends on RLIMIT_NOFILE resource limit.)
        
     • 커널의 fs.file-max 파라미터와 fs.nr_open 파라미터 설정 확인 및 변경
       

       ## 기존 설정값 확인
       $ sysctl -a | grep fs.file-max
       fs.file-max = 300000
       
       $ cat /proc/sys/fs/file-max
       300000
       
       ## 기존 파라미터 값 수정
       $ vim /etc/sysctl.conf
       fs.file-max = 1048576
       
       ## 설정 값 적용
       $ sysctl -p
       
       
       ## 변경 설정값 확인
       $ sysctl -a | grep fs.file-max
       fs.file-max = 300000
       
       $ cat /proc/sys/fs/file-max
       300000
       
       $ cat /proc/sys/fs/file-nr
       3008    0       1048576

• 시스템 전체에 File Descriptors 수에 대한 제한이 있으며, OS의 sysctl fs.file-max 명령으로 설정 가능
• nginx를 시작하는 방법에 따라 다르지만, worker_rlimit_nofile은 nginx를 시작하는 방법에 작동
• 모든 nginx worker process가 사용할 수 있는 최대 파일 설명자 수(worker_rlimit_nofile * worker_processes)가 fs.file-max보다 훨씬 적은지 확인 필요
• nginx가 사용 가능한 모든 File Descriptors를 사용하는 경우(예: DoS 공격), 문제를 해결하기 위해 컴퓨터에 로그인하는 것조차 불가능해짐

※ File Descriptor(파일 디스크립터)

• 리눅스 혹은 유닉스 계열의 시스템에서 프로세스(process)가 파일(file)을 다룰 때 사용하는 개념
• 프로세스에서 특정 파일에 접근할 때 사용하는 추상적인 값
• File Descriptor(파일 디스크럽터)는 일반적으로 0이 아닌 정수값을 갖음

참고 자료 : 가장 많이 실수하는 NGINX 설정 에러 10가지 - NGINX STORE

참고 자료 : file open 확인 및 커널 설정 : 네이버 블로그 (naver.com)

D state란

• process 상태(STAT)가 D로 표시되는 process는 "uninterruptible sleep" 상태를 의미
• 일반적으로 I/O에 대해 대기하는 것으로 다른 어떤 일도 할 수 없는 상태 → I/O operation이 완료되기 전까지는 죽은 상태
• D 상태인 process들은 operation이 완료되어 R/S(Run/Sleep)에 돌아가기 전까지 보통 작은 시간동안(a fraction of a second)만 거기에 있음
   
• 서버가 I/O 집약적인 작업(intensive operations)을 수행할 때 프로세스가 "D" 상태로 표시되는 것은 정상 
• 성능이 문제가 되는 경우 디스크의 상태를 확인 필요
• 펌웨어 및 커널 디스크 드라이버가 업데이트되었는지 확인필요

• process가 D 상태에 빠지는 경우
  1. 연결될 수 없는 NFS나 다른 원격 파일시스템과 통신하려는 경우
  2. 문제가 있는 하드 드라이브에 접근하려는 경우
  3. 비정상적인 device 드라이버를 이용해 하드웨어를 사용하려고 경우

• D state process는 uninterruptible sleep으로 I/O를 대기 중 상태
  • ps 명령어는 uninterruptible sleep의 process에 대해 "D"를 표시 
  • vmstat 명령어는 "blocked" 상태이거나 "waiting on I/O" process를 표시 
  • "D" state Process는 SIGKILL 또는 kill -9를 사용해도 중단할 수 없음 → 서버를 재부팅하거나 I/O가 응답할 때까지 기다려야만 지울 수 있음

• Uninterruptible sleep 상태는 D state의 process로 아무것도 할 수 없는 상태
  • process는 일반적으로 D State를 오래 유지하지 않음
  • D State process가 쌓여 있으면 시스템의 일부 로직이 중단됨
  • ps 명령어에 l 옵션 추가하여 긴 포맷으로 출력 → 우선순위와 관련된 PRI와 NI값 확인 가능  
  • WCHAN 열에는 process가 sleeping인 커널 함수의 이름이 표시
    

    $ ps axl | awk '$10 ~ /D/'
    F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
    vass     13478  7.2  0.0   1732   624 pts/1    D+   17:36   0:00 find ./​

process STAT(프로세스 상태)

• Linux의 process는 running, sleeping 등 여러 가지 상태가 될 수 있음
• Running process는 방금 CPU에서 실행 중이고, Sleeping process는 CPU가 켜지거나 다른 이벤트가 발생할 때까지 기다리는 상태를 의미
• ps 명령어를 사용하면 시스템에서 각 process의 상태에 대한 정보를 얻을 수 있음
   
• ps 명령어의 STAT 열에 표시
  • 큰 S는 Sleeping을 의미
  • 작은 s는 process이 session leader을 의미 → process가 새로운 session을 생성하면 해당 process는 session leader가 됨(Session Process의 PID = Session ID)
  • 큰 R은 Running을 의미
  • +는 foreground process를 의미
    

    $ ps a
      PID TTY      STAT   TIME COMMAND
     4975 tty1     Ss+    0:00 /sbin/mingetty tty1
     4976 tty2     Ss+    0:00 /sbin/mingetty tty2
     6202 pts/0    Ss+    0:01 -bash
    10312 pts/1    Ss     0:00 -bash
      639 pts/1    R+     0:00 ps a​

참고 자료 : Processes in D state - OpenVZ Virtuozzo Containers Wiki

참고 자료 : [Linux] Uninterruptible sleep 프로세스 상태 D :: TOP GUN (tistory.com)

참고 자료 : Processes in an Uninterruptible Sleep (D) State | Support | SUSE

1. Linux 현재 시간 확인 (현재 타임존)

$ date
Mon Mar 25 22:50:28 EDT 2024

2. Linux 현재 타임존 확인 → New_York 설정 확인

$ ls -al /etc/localtime
lrwxrwxrwx. 1 root root 38 Mar 21 23:42 /etc/localtime -> ../usr/share/zoneinfo/America/New_York

3. 타임존을 한국 표준시(KST)로 변경

$ ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime

4. 변경된 타임존 확인

$ ls -al /etc/localtime
lrwxrwxrwx 1 root root 30 Mar 26 11:52 /etc/localtime -> /usr/share/zoneinfo/Asia/Seoul

5. 현재 시간 확인 (변경된 타임존)

$ date
Tue Mar 26 11:52:57 KST 2024

• HAR 파일은 HTTP Archive format의 약자
• HAR 파일은 웹 브라우저와 웹 사이트 간의 정보 추적에 사용되는 형식
• HAR 파일은 크롬 개발자 도구 네트워크 탭의 패널 정보가 JSON 형식으로 변환

• HAR 파일은 주로 페이지 렌더링 문제, 로딩 시간, API 호출하는 과정에서 발생한 에러를 분석하는 용도로 사용
• 예를 들어, API를 호출하는 과정에서 에러가 발생하였으며, 에러 내용을 웹 페이지 개발자에게 전달해야 하는 경우 HAR 파일만 전달하면 문제 파악하기 쉬움

1. HAR 파일이 유용한 경우

1. 차단된 요청 및 응답(Blocked request-responses)
   • 개발자는 HAR 파일을 통해 차단된 요청 및 응답에 대한 다양한 상황 파악하기 쉬움
   • 차단된 요청 및 응답에 대한 HAR 파일 분석을 통해 네트워크 역량을 향상 가능
     
     
2. 네트워크 시각화(Network Visualization)
   • HAR 파일에는 리소스 요청에 대한 자세한 로딩 시간이 포함됨
   • HAR 파일을 통해 웹 페이지의 성능을 파악하기 쉬움
     
     
3. 복호화된 트래픽 포렌식(Decrypted Traffic Forensics)
   • 프록시(Proxy)와 같은 중간 매개체는 요청 및 응답의 내용이 수정됨
   • HAR 파일의 내용을 통해 네트워크 트래픽으로부터 분리되어 있고 복호화되었기에 모든 리소스가 정상적으로 로드되었는지 확인 가능

2. HAR 파일 분석 시 주의사항

• 각 리소스에 대한 정보를 통해 로딩 병목 현상을 줄이고 사이트 속도를 개선할 수 있는 부분을 찾을 수 있음
  
  

1. DNS 조회 시간
   • DNS 조회 시간은 ISP, 위치 및 DNS와 같은 여러 요인에 따라 달라질 수 있음
   • 로드되는 리소스가 많은 경우 해당 리소스 때문에 DNS 조회 시간이 증가할 수 있음
     
     
2. 캐시 되지 않는 리소스
   • 웹 페이지를 로드할 때마다 정적인 리소스는 다시 로드하면 안됨
   • 해웹 페이지를 재방문할 때마다 동일한 리소스를 요청하는 경우, 페이지 로딩 시간에 영향을 미침
     
     
3.  로딩 시간이 긴 리소스
   • 리소스의 파일 형식에 따라 리소스를 압축하거나 사용하지 않는 요소를 결합 또는 제거를 통해 로딩 시간을 줄 일 수 있음
   • 리소스에 따라 로딩 시간이 길어 질 수 있음

3. 크롬에서 HAR 파일 내보내기(export) 방법

1. 네트워크 분석이 필요한 웹 페이지로 접속
2. 크롬 개발자 도구 실행 후 네트워크 탭을 선택
3. 이슈가 되었던 문제를 재현
4. Chrome에서 HAR 내보내기(export)를 클릭하여 다운로드

3.1.  HAR 내보내기(export) 아이콘 클릭

3.2. 마우스 우클릭 → 모두 콘텐츠가 포함된 HAR로 저장

4. 크롬에서 HAR 파일 가져오기(import) 방법

1. 크롬을 실행
2. 크롬 개발자 도구 실행 후 네트워크 탭을 선택
3. import(가져오기) 아이콘을 클릭
   

   

    
    
4. 파일 탐색기 창에서 HAR 파일을 가져오기(import)

참고 자료 : https://developer-talk.tistory.com/834

1. 파일 시스템(Filesystem)이란

• 운영체제(OS)가 파일을 시스템의 디스크에 구성하는 방식
• 컴퓨터에서 파일이나 자료를 쉽게 발견 및 접근할 수 있도록 보관 또는 조직하는 체제
• 사용자 영역이 아닌 커널 영역에서 동작
• 파일 시스템은 파일의 읽기, 쓰기, 삭제 등의 기능을 빠르고 원활하게 수행하기 위한 목적
• 파일 서버 상의 자료로의 접근을 제공하는 방식과 가상의 형태로서 접근 수단만이 존재하는 방식도 파일 시스템의 범위에 포함
  
  
• 파일 시스템의 구조

2. 파일 시스템(Filesystem) 종류

• 리눅스 전용 디스크 기반 파일 시스템

• 리눅스 전용 디스크 기반 파일 시스템 EXT4의 버전별 비교

• 저널링 파일 시스템
  • 시스템의 비정상적인 종료 시 저널(로그)을 이용해 빠르면서 안정적으로 복구 가능
  • 데이터를 디스크에 쓰기 전에 로그에 데이터를 남겨 시스템의 비정상적인 셧다운에도 로그를 사용해 빠르고 안정적인 복구 기능을 제공하는 기술
  • 저널링 기술이 적용된 파일 시스템 : ext3, ext4, XFS, JFS, ResierFS 등
    
    
  • 저널링 파일 시스템 운영 형태
    
    1. 저널이라는 로그에 시스템 전 상태 저장
    2. 시스템의 비정상적인 종료 시 저널(로그)을 검사
    3. 저널(로그) 정보를 바탕으로 파일 시스템에 수정 내용을 적용

• 추가 파일 시스템 설명

• 네트워크 파일 시스템

• 기타 지원 가능한 파일 시스템