현상
정상적으로 운영되던 서버에 접속이 불가능하거나 접속되더라도 성능이 급격히 저하되며, 서버 내에서 구동 중인 데이터베이스 또한 평소보다 매우 느려지는 현상이 발생했습니다.
원인
리눅스 커널에서는 프로세스의 비정상적인 메모리 접근을 감지하게 되면, 메모리 덤프(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
SQL
복사
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
SQL
복사
리눅스 커널의 감지 확인 (/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'
SQL
복사
•
이후 서버의 주요 일을 하는 데이터베이스 프로세스가 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]
... 생략 ...
SQL
복사
•
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
SQL
복사
해결
리눅스 커널은 비정상 메모리 접근 시 메모리 덤프를 수행하지만, 대부분의 경우 전체 덤프가 필요하지 않습니다.
VSS 전체를 덤프하면서 과도한 리소스 사용(CPU, 메모리, 디스크 I/O)으로 서버 성능 저하 및 디스크 풀 현상이 발생할 수 있습니다.
따라서 Core Dump 크기 제한 설정을 활성화 하는 것을 권장합니다.
데이터베이스를 구성하는 프로세스
Tibero 데이터베이스에서는 내부적으로 비정상 동작이 감지되면, 자체 모니터링 프로세스가 이를 인식하여 BackTrace 로그를 자동으로 기록합니다.
•
로그 경로: $TB_HOME/instance/$TB_SID
•
로그 파일: tbsvr.callstack.%PID
참고
리눅스 커널에서 비정상적인 메모리 접근을 한 프로세스의 코어 덤프를 제한하는 방법
•
/etc/security/limits.conf 설정 파일을 수정합니다.
•
수정된 정보는 프로세스 재기동이 되어야만 적용됩니다.
메모리 덤프 용량 확인
•
확인하고자 하는 프로세스의 PID를 확인합니다.
•
프로세스 PID를 통해 적용되어 있는 메모리 덤프 크기를 확인합니다.
•
"Max core file size" 항목이 메모리 덤프 용량에 해당되며, unlimited로 적용되어 있으면 제한되어 있지 않음을 의미합니다.
$ ps -ef |grep tbsvr
tibero 1111133 1 0 May14 pts/3 00:00:26 tbsvr -t NORMAL -SVR_SID psource1
tibero 1111134 1111133 0 May14 pts/3 00:00:00 /tibero/tibero_engine/bin/tblistener -n 11 -t NORMAL -SVR_SID psource1
tibero 1111135 1111133 0 May14 pts/3 00:00:00 tbsvr_MGWP -t NORMAL -SVR_SID psource1
tibero 1111136 1111133 0 May14 pts/3 00:00:00 tbsvr_FGWP000 -t NORMAL -SVR_SID psource1
tibero 1111137 1111133 0 May14 pts/3 00:00:00 tbsvr_FGWP001 -t NORMAL -SVR_SID psource1
tibero 1111138 1111133 0 May14 pts/3 00:00:00 tbsvr_FGWP002 -t NORMAL -SVR_SID psource1
... 생략 ...
$ cat /proc/1111133/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max processes unlimited unlimited processes
Max open files 1048576 1048576 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 159739 159739 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
SQL
복사
메모리 덤프 용량 제한 적용
•
서버의 유저별로 적용이 가능합니다.
•
데이터베이스는 서버의 tibero 유저로 구성되어 있어, tibero 계정에 메모리 덤프 용량 제한을 적용 합니다.
•
설정 파일 수정 후 즉시 적용 되지 않으며, 프로세스의 재기동 후 확인하면 정상적으로 적용된 것을 확인할 수 있습니다.
# cat /etc/security/limits.conf
tibero soft core 0
tibero hard core 0
!! 데이터베이스 재기동 !!
$ ps -ef|grep tbsvr
tibero 1583929 1 14 06:49 pts/1 00:00:00 tbsvr -t NORMAL -SVR_SID psource1
tibero 1583936 1583929 0 06:50 pts/1 00:00:00 tbsvr_MGWP -t NORMAL -SVR_SID psource1
tibero 1583937 1583929 0 06:50 pts/1 00:00:00 tbsvr_FGWP000 -t NORMAL -SVR_SID psource1
tibero 1583938 1583929 0 06:50 pts/1 00:00:00 tbsvr_FGWP001 -t NORMAL -SVR_SID psource1
tibero 1583939 1583929 0 06:50 pts/1 00:00:00 tbsvr_FGWP002 -t NORMAL -SVR_SID psource1
tibero 1583940 1583929 0 06:50 pts/1 00:00:00 tbsvr_FGWP003 -t NORMAL -SVR_SID psource1
tibero 1583941 1583929 0 06:50 pts/1 00:00:00 tbsvr_FGWP004 -t NORMAL -SVR_SID psource1
tibero 1583942 1583929 0 06:50 pts/1 00:00:00 tbsvr_FGWP005 -t NORMAL -SVR_SID psource1
tibero 1583943 1583929 0 06:50 pts/1 00:00:00 tbsvr_FGWP006 -t NORMAL -SVR_SID psource1
$ cat /proc/1111133/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 0 bytes
Max resident set unlimited unlimited bytes
Max processes unlimited unlimited processes
Max open files 1048576 1048576 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 159739 159739 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
SQL
복사