본문 바로가기
Linux

[Linux] 리눅스 서버에서 장애 발생 시 대응 방안

by 꾸압 2022. 10. 6.

 

<서론>

  - 리눅스 server에 문제가 생기면 어디서부터 해결할 지 알아보자

  - 들어가기 전, sysstat package를 설치하고 가자. (시스템 정보 확인을 위해)

$ sudo yum install sysstat
$ sudo apt install sysstat

 


 

<본론>

  0) Error log 확인

    - "dmesg | tail" 로 error log 확인

    - dmesg 만 입력하면 모든 커널 msg를 출력하므로, tail 을 넣어 마지막 10줄만 출력하자.

    - "dmesg -w" 를 입력하면 실시간 로그 확인 가능.

$ dmesg | tail
[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0
[...]
[1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child
[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB
[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request.  Check SNMP counters.

[출처] Luavis' Dev Story

    - 위 예시에선 oom-killer(out of memory) 와 TCP request가 드랍했음을 출력.

 

  1) CPU 상태 확인

    - Server 성능에 문제가 있다면 top 명령어로 CPU 사용량 확인.

    - 제작한 applicaiton이 너무 많은 CPU(50% 이상) resource를 점유하는건 아닌지 확인.

$ top
top - 00:15:40 up 21:56,  1 user,  load average: 31.09, 29.87, 29.92
Tasks: 871 total,   1 running, 868 sleeping,   0 stopped,   2 zombie
%Cpu(s): 96.8 us,  0.4 sy,  0.0 ni,  2.7 id,  0.1 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  25190241+total, 24921688 used, 22698073+free,    60448 buffers
KiB Swap:        0 total,        0 used,        0 free.   554208 cached Mem

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 20248 root      20   0  0.227t 0.012t  18748 S  3090  5.2  29812:58 java
  4213 root      20   0 2722544  64640  44232 S  23.5  0.0 233:35.37 mesos-slave
 66128 titancl+  20   0   24344   2332   1172 R   1.0  0.0   0:00.07 top
  5235 root      20   0 38.227g 547004  49996 S   0.7  0.2   2:02.74 java
  4299 root      20   0 20.015g 2.682g  16836 S   0.3  1.1  33:14.42 java
     1 root      20   0   33620   2920   1496 S   0.0  0.0   0:03.82 init
     2 root      20   0       0      0      0 S   0.0  0.0   0:00.02 kthreadd
     3 root      20   0       0      0      0 S   0.0  0.0   0:05.35 ksoftirqd/0
     5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H
     6 root      20   0       0      0      0 S   0.0  0.0   0:06.94 kworker/u256:0
     8 root      20   0       0      0      0 S   0.0  0.0   2:38.05 rcu_sched
     
[출처] luavis' Dev Story

 

    - mpstat 으로 각 CPU 별 균형 상태 확인. (sysstat 설치 필요)

$ mpstat -P ALL 1
Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015  _x86_64_ (32 CPU)

07:38:49 PM  CPU   %usr  %nice   %sys %iowait   %irq  %soft  %steal  %guest  %gnice  %idle
07:38:50 PM  all  98.47   0.00   0.75    0.00   0.00   0.00    0.00    0.00    0.00   0.78
07:38:50 PM    0  96.04   0.00   2.97    0.00   0.00   0.00    0.00    0.00    0.00   0.99
07:38:50 PM    1  97.00   0.00   1.00    0.00   0.00   0.00    0.00    0.00    0.00   2.00
07:38:50 PM    2  98.00   0.00   1.00    0.00   0.00   0.00    0.00    0.00    0.00   1.00
07:38:50 PM    3  96.97   0.00   0.00    0.00   0.00   0.00    0.00    0.00    0.00   3.03
[...]

[출처] Luavis' Dev Story

    - 위 예시를 기준으로 한 CPU만 동작한다면 application이 single thread 상태임을 의미.

 


 

  2) 메모리 상태 확인

    - 적어도 500MB 이상의 "buffers" 및 "cached" 메모리가 남았는지 확인.

$ free -m
             total       used       free     shared    buffers     cached
Mem:        245998      24545     221453         83         59        541
-/+ buffers/cache:      23944     222053
Swap:            0          0          0

[출처] luavis' Dev Story

    @@ buffers : Block 장치 I/O 의 buffer 캐시 사용량

    @@ cached : 파일 시스템에 사용되는 page cache 양

    - 위 buffer & cached 값이 0에 가깝다는건 높은 Disk I/O가 발생함을 의미.(둘 다 500MB는 넘겨야 안정적)

 

    [안전한 메모리 상태]

      - free memery 값이 "0" 에 가까움

      - used memory 가 "total"에 가까움

      - available memory (또는 free + buffers/cache) 에 충분한 여유가 있음 (전체의 20% 정도)

      - swap used 값에 변화가 없음

 

    [끔직하게 위험한 메모리 상태]

      - available memory (또는 free + buffers/cache) 값이 "0" 에 가까움 (value < 500MB)

      - swap used 값이 증가하거나 변동중

      - dmesg | grep oom-killer 가 작업중에 "OutOfMemory-killer" 를 띄움

 


 

  3) 프로세스 (Thread) 상태 확인

    - 띄웠던 Process 가 살아있는지 확인

    - Process가 과하게 생기거나 혹은 아예 죽어버린 경우가 있음

$ ps -ef | grep <process name>

 

    - pidstat 으로 process 부하 확인. top 명령어와 유사하게 process 정보만을 정리하여 띄움

    - "%CPU" 항목에서 100% 당 1 CPU를 사용중. 아래 예시에선 java process 가 1600%로서 16 CPU를 점유.

    - sysstat package 설치 필요.

$ pidstat 1
Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015    _x86_64_    (32 CPU)

07:41:02 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
07:41:03 PM     0         9    0.00    0.94    0.00    0.94     1  rcuos/0
07:41:03 PM     0      4214    5.66    5.66    0.00   11.32    15  mesos-slave
07:41:03 PM     0      4354    0.94    0.94    0.00    1.89     8  java
07:41:03 PM     0      6521 1596.23    1.89    0.00 1598.11    27  java
07:41:03 PM     0      6564 1571.70    7.55    0.00 1579.25    28  java
07:41:03 PM 60004     60154    0.94    4.72    0.00    5.66     9  pidstat

07:41:03 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
07:41:04 PM     0      4214    6.00    2.00    0.00    8.00    15  mesos-slave
07:41:04 PM     0      6521 1590.00    1.00    0.00 1591.00    27  java
07:41:04 PM     0      6564 1573.00   10.00    0.00 1583.00    28  java
07:41:04 PM   108      6718    1.00    0.00    0.00    1.00     0  snmp-pass
07:41:04 PM 60004     60154    1.00    4.00    0.00    5.00     9  pidstat

[출처] Luavis' Dev Story

 


 

  4) Service / Daemon 확인

    - Server 프로그램이 Daemon으로 돌아간다면, 잘 동작하는지 확인.

    @@ Daemon : 데몬. 백그라운드에서 동작하는 Process. windows의 Service 같은 것.

$ service <daemon name> status

 


 

  5) 네트워크 상태 확인

    - 현재 Server 의 network 설정 및 상태 확인.

$ ipconfig

 

    - Host Server에 접속 가능 확인.

    - TCP 80, 443 (HTTP, HTTPS) 네트워크

nc <hostname> <port>
nc localhost 80
nc localhost 443

    - UDP 네트워크

$ nc -u <hostname> <port>

      ==> <Host Name> 을 외부 서버로 지정하면, 외부에서 해당 host로 접속이 되는지 확인 가능 (방화벽으로 막혔을 수 있기에)

      ==> 더 상세한 ouput에는 -v 를 추가.

$ nc <hostname> <port> -v

   

    - 다른 Process와 Port가 겹쳐 error 발생시, 어떤 Process 와 충돌한건지 확인. (아래 예시는 충돌 Port가 80 인 경우)

$ lsof -i TCP:80

 

    - 특정 Process가 어떤 Port 를 쓰는지 확인도 가능 (아래 예시는 httpd daemon의 경우)

lsof -c httpd

 

    - Server 응답이 계속 늦어지는 경우, 요청이 Server에 몰려 발생한 건지 확인. (네트워크 연결 수로 확인)

$ netstat -nap | grep ESTAB | wc

 

    - 네트워크 연결 수가 많은데 요청이 외부에서 들어와 몰리는게 아니라면 Server에 이상이 있는 것.

    - TIME_WAIT 의 숫자가 비정상적으로 많다면,  Server로 들어오는 요청을 제대로 처리하지 못하는 것. (병목 현상)

$ netstat -nap |grep TIME_WAIT | WC

 


 

  6) 디스크 상태 확인

    - Server 를 켜면 오랜시간 방치 및 재부팅 하지 않아 disk 에 쓰레기가 쌓임

    - Disk 가 꽉 차면 System에서 파일을 못 만들어 Server가 죽음.

    - 아래 명령어를 통해 Disk 볼륨 별로 얼마나 차 있는지, 빈 공간이 얼마나 남았는지 확인.

    - root 와 swap 볼륨에 여유가 있어야 함.

$ df -uh

    @@ swap 은 disk를 메모리로 사용하는 방법으로 물리적 메모리가 넉넉하더라도, 특정 app은 swap disk를 요구할 수 있으므로 미리 만드는걸 추천.

 

      - iostat 으로 Disk 성능 확인. (sysstat 설치 필요)

$ iostat -xz 1
Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015  _x86_64_ (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          73.96    0.00    3.73    0.03    0.06   22.21

Device:   rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvda        0.00     0.23    0.21    0.18     4.52     2.08    34.37     0.00    9.98   13.80    5.42   2.44   0.09
xvdb        0.01     0.00    1.02    8.94   127.97   598.53   145.79     0.00    0.43    1.78    0.28   0.25   0.25
xvdc        0.01     0.00    1.02    8.86   127.79   595.94   146.50     0.00    0.45    1.82    0.30   0.27   0.26
dm-0        0.00     0.00    0.69    2.32    10.47    31.69    28.01     0.01    3.23    0.71    3.98   0.13   0.04
dm-1        0.00     0.00    0.00    0.94     0.01     3.78     8.00     0.33  345.84    0.04  346.81   0.01   0.00
dm-2        0.00     0.00    0.09    0.07     1.35     0.36    22.50     0.00    2.55    0.23    5.62   1.78   0.03
[...]

[출처] Luavis' Dev Story

 

r/s w/s rkB/s wkB/s
read 요청 write 요청 read kB/s 속도 write kB/s 속도

      - r/s 나 w/s 값이 너무 크지 않은지 확인한다. (예상보다 과도한 요청으로 문제가 발생한 경우)

      - await : I/O 처리 평균 시간. 일반적인 장치의 요청 처리 시간보다 긴 경우(위 예시 dm-1), 블럭 장치 자체의 문제 혹은 장치가 포화 상태임을 뜻함.

 


 

  7) 로깅 상태 확인

    - Linux의 Server 로그는 /var/log 폴더 아래에 저장됨. 문제는 이 폴더에 app의 로그를 log rotation 시키지 않은 경우.

      ==> 단일 로그 파일 용량이 GB를 넘어 가면서, 파일 size 가 커짐에 따라 Process가 처리하기 힘들어져 성능 저하 발생.

 


 

<출처>

  1)  https://blog.hbsmith.io/linux-%EC%84%9C%EB%B2%84-%EC%9E%A5%EC%95%A0%EC%9B%90%EC%9D%B8-%ED%8C%8C%EC%95%85%EC%9D%80-%EC%96%B4%EB%96%BB%EA%B2%8C-7accec423bb5

  2) https://www.lesstif.com/lpt/linux-swap-disk-93127500.html

  3) https://luavis.me/server/linux-performance-analysis

  4) https://www.linuxatemyram.com/

 

 

'Linux' 카테고리의 다른 글

[Linux] Linux OS 부팅 순서  (0) 2023.10.28
[Kali] Kali 설치  (2) 2023.02.27
[Linux] vi (vim) 편집기  (0) 2022.07.27
[Linux] Ubuntu Terminal 명령어 [업데이트 예정]  (0) 2022.07.23

댓글