문서유형ㅣ장애해결
분야ㅣ모니터링/점검
적용제품버전ㅣ5SP1FS01, 5SP1FS02, 5SP1FS03, 5SP1FS04, 5SP1FS06, 6FS01, 6FS02, 6FS03, 6FS04, 6FS05, 6FS06, 6FS07, 6FS07PS, 7FS01, 7FS02, 7FS02PS
문서번호ㅣTMOTS011
현상
정상적으로 운영되던 서버에 접속이 불가능하거나 접속되더라도 성능이 급격히 저하되며, 서버 내에서 구동 중인 데이터베이스 또한 평소보다 매우 느려지는 현상이 발생했습니다.
원인
리눅스 커널에서는 프로세스의 비정상적인 메모리 접근을 감지하게 되면, 메모리 덤프(Core Dump)를 수행하며 자원 사용량이 급격히 증가하여 시스템 성능 저하를 유발할 수 있습니다.
리눅스 커널은 메모리 보호 기능을 위해 프로세스의 비정상 접근을 실시간으로 감지하고, 문제가 발생한 경우 /var/log/messages에 Segmentation Fault 또는 General Protection 메시지를 남기고 해당 프로세스를 SIGSEGV (segmentation violation) 및 메모리 덤프를 수행 (dumping core)합니다.
프로세스는 일반적으로 다음과 같은 두 가지 메모리 영역을 사용합니다:
- VSS (Virtual Set Size): 프로세스가 매핑한 전체 메모리 영역
- RSS (Resident Set Size): 실제 사용 중인 영역
리눅스 커널에서 비정상적인 메모리 접근을 시도한 프로세스를 강제 종료 시킬 때 , 어느 메모리 구간에서 문제가 발생했는지 알 수 없기 때문에 전체 VSS 영역에 대해 덤프를 생성합니다.
메모리 덤프를 수행하는 동안 VSS 크기에 따라 CPU, Memory, DISK I/O 사용량이 발생합니다. VSS가 클수록 상대적으로 리소스 사용량이 급증합니다.
CPU 사용량 확인
- sar 명령어와 -q 옵션을 사용하여, core의 사용량을 확인합니다.
- ldavg-1, ldavg-5, ldavg-15 값은 일을 하고 있는 core의 개수를 나타냅니다.
(ldavg: 1분, 5분, 15분 Load Average 값을 의미)
- 24Core 서버에서 문제의 시점 할당된 core대비 요청하고 있는 core개수가 높은 수치를 띄고 있음을 알 수 있으며, 비정상적인 수치로 판단 할 수 있습니다.
$ sar -q 15시 20분 01초 runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked 15시 20분 01초 25 7690 20.82 17.63 15.00 0 15시 30분 01초 23 7684 19.23 18.55 16.61 0 15시 40분 01초 13 7694 14.25 14.82 15.41 0 16시 26분 37초 8 7782 148.43 165.40 171.44 0 <- 문제의 시점 16시 30분 01초 10 7789 127.00 146.79 162.90 0 <- 문제의 시점 16시 40분 01초 6 7785 92.69 104.66 133.27 1 <- 문제의 시점 16시 50분 01초 16 7816 62.64 75.12 105.34 0 <- 문제의 시점 17시 00분 01초 15 7815 11.63 27.52 67.23 1
Memory(Swap Out/In) 확인
- sar 명령어와 -W 옵션을 사용하여, swap 사용량을 확인합니다.
- 메모리 사용량이 급격하게 많아지면, swap 영역을 사용하게 됩니다.
- 메인 메모리 에서 swap 영역으로 메모리를 보내는 것을 swap out이라고 표현하고 swap 영역에서 메인 메모리로 돌아오는 것을 swap in이라고 표현합니다.
- swap out(pswout)과 swap in(pswin)이 문제 시점 굉장히 높은 수치가 나타남을 알 수 있습니다.
$ sar -W 15시 30분 01초 pswpin/s pswpout/s 15시 30분 01초 0.00 0.00 15시 40분 01초 0.00 0.00 16시 26분 37초 276.53 1627.42<- 문제의 시점 16시 30분 01초 75.30 2330.37<- 문제의 시점 16시 40분 01초 764.02 2450.31<- 문제의 시점 16시 50분 01초 599.91 1903.95<- 문제의 시점 17시 00분 01초 573.69 1108.47<- 문제의 시점 17시 10분 01초 98.03 0.00 17시 20분 01초 102.21 0.00
리눅스 커널의 감지 확인 (/var/log/message)
- mxg_tib (PID: 70809) 프로세스가 SIGSEGV 명령을 호출 받게 되며, 비정상 종료됩니다.
Apr 30 15:33:08 BPOTDB01 abrt-hook-ccpp: Process 70809 (mxg_tib) of user 1002 killed by SIGSEGV - dumping core Apr 30 15:33:09 BPOTDB01 abrt-server: Executable '/home/maxgauge/semas241/bin/mxg_tib' doesn't belong to any package and ProcessUnpackaged is set to 'no' Apr 30 15:33:09 BPOTDB01 abrt-server: 'post-create' on '/var/spool/abrt/ccpp-2025-04-30-15:33:08-70809' exited with 1 Apr 30 15:33:09 BPOTDB01 abrt-server: Deleting problem directory '/var/spool/abrt/ccpp-2025-04-30-15:33:08-70809'
- 이후 서버의 주요 일을 하는 데이터베이스 프로세스가 120초 이상 응답 없음을 의미하는 로그가 기록됩니다.
Apr 30 15:52:40 BPOTDB01 kernel: INFO: task tbsvr:22059 blocked for more than 120 seconds. Apr 30 15:52:40 BPOTDB01 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Apr 30 15:52:40 BPOTDB01 kernel: tbsvr D ffff8d91c015acc0 0 22059 21530 0x00000080 Apr 30 15:52:40 BPOTDB01 kernel: Call Trace: Apr 30 15:52:40 BPOTDB01 kernel: [<ffffffff83f87169>] schedule+0x29/0x70 Apr 30 15:52:40 BPOTDB01 kernel: [<ffffffff83f88b55>] rwsem_down_read_failed+0x105/0x1c0 Apr 30 15:52:40 BPOTDB01 kernel: [<ffffffff83b97528>] call_rwsem_down_read_failed+0x18/0x30 Apr 30 15:52:40 BPOTDB01 kernel: [<ffffffff83f86450>] down_read+0x20/0x40 Apr 30 15:52:40 BPOTDB01 kernel: [<ffffffff83f8e8fd>] __do_page_fault+0x4bd/0x500 Apr 30 15:52:40 BPOTDB01 kernel: [<ffffffff83f8e975>] do_page_fault+0x35/0x90 Apr 30 15:52:40 BPOTDB01 kernel: [<ffffffff83f8a778>] page_fault+0x28/0x30 Apr 30 15:52:40 BPOTDB01 kernel: INFO: task tbsvr:25337 blocked for more than 120 seconds. Apr 30 15:52:40 BPOTDB01 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Apr 30 15:52:40 BPOTDB01 kernel: tbsvr D ffff8d91c005acc0 0 25337 21530 0x00000080 Apr 30 15:52:40 BPOTDB01 kernel: Call Trace: Apr 30 15:52:40 BPOTDB01 kernel: [<ffffffffc065ce4e>] ? bond_start_xmit+0x1be/0x420 [bonding] ... 생략 ...
- max_tib 프로세스가 비정상적인 메모리를 감지하게 되며, 리눅스 커널에서 강제 종료 및 메모리 덤프를 수행한 것을 확인할 수 있습니다.
- 문제 발생 시점 모니터링하고 있던 프로세스 정보입니다.
- 기존 운영 되던 시점 max_tib 프로세스가 굉장히 높은 VSS를 가지고 있어 메모리 덤프 수행 시간이 길어지며 리소스 사용량이 급격하게 증가함을 확인할 수 있습니다.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 70809 maxgauge 20 0 130.7g 650664 632136 S 18.2 0.2 9:20.34 mxg_tib -c semas241 -r -D
해결
리눅스 커널은 비정상 메모리 접근 시 메모리 덤프를 수행하지만, 대부분의 경우 전체 덤프가 필요하지 않습니다.
VSS 전체를 덤프하면서 과도한 리소스 사용(CPU, 메모리, 디스크 I/O)으로 서버 성능 저하 및 디스크 풀 현상이 발생할 수 있습니다.
따라서 Core Dump 크기 제한 설정을 활성화 하는 것을 권장합니다.
데이터베이스를 구성하는 프로세스
Tibero 데이터베이스에서는 내부적으로 비정상 동작이 감지되면, 자체 모니터링 프로세스가 이를 인식하여 BackTrace 로그를 자동으로 기록합니다.
- 로그 경로: $TB_HOME/instance/$TB_SID
- 로그 파일: tbsvr.callstack.%PID
참고리눅스 커널에서 비정상적인 메모리 접근을 한 프로세스의 코어 덤프를 제한하는 방법
메모리 덤프 용량 제한 적용