베어메탈 솔루션에서 Oracle 성능 조정
목표
이 문서에서는 베어메탈 솔루션에서 Oracle을 사용하여 성능 관련 문제에 접근하는 방법에 대한 가이드라인을 제공합니다.
1단계: 진단 데이터 수집
문제를 최대한 자세히 파악합니다. 다음을 포함하여 최대한 많은 정보를 수집하세요.
- 데이터베이스 환경 정보 - 머신 ID/IP, 데이터 센터 위치, Oracle 환경 세부정보 등
- 타임라인을 포함한 문제 설명
- 영향의 범위 - 예를 들어 문제가 단일 세션이나 서버, 또는 관련 세션 및 서버 집합, 또는 데이터베이스의 모든 사용자에게 영향을 주는지 여부입니다.
- 지금까지 진행된 조사를 설명합니다. 해결 방법이 있나요?
- 문제를 재현할 수 있습니까? 확인할 수 있는 경우 확인 방법을 설명해 주세요.
- 비교할 수 있는 적합한 기준 데이터가 있나요?
- 워크로드에 대한 변경사항을 포함하여 데이터베이스, 호스트, 네트워크, 스토리지 또는 애플리케이션 레이어의 구성에 최근 변경사항이 있나요?
- ASH, AWR, 알림 로그, trace 파일 및 TFA/OS 감시자 로그를 포함한 모든 관련 로그 및 trace를 수집합니다.
# TFA command to generate a bundled package containing files like
# the AWR report, ADDM report, ASH report, OSWatcher and ORAchk performance
# related checks.
tfactl diagcollect -srdc dbperf
2단계: 분석 및 빌드 추천
위에서 수집한 데이터에 따라 여기서는 섹션을 건너뛸 수 있습니다.
2.1 데이터베이스 호스트 상태
데이터베이스 호스트에서 빠른 상태 확인을 수행하는 것이 좋습니다. 문제 발생 시 TFA/OSWatcher 파일을 사용할 수 있어야 합니다. 여기에서는 기본적으로 리소스 포화, 사용률 또는 오류의 징후를 찾습니다. 또한 BMS Infrascope를 사용하여 machine-id, lun-id 등을 통해 환경을 대략적으로 파악할 수도 있습니다.
2.2.1 시스템 로그
/var/log/messages또는dmesg를 사용하여 시스템에 표시되는 스토리지, n/w 계층에 잠재적인 문제가 있는지 식별할 수 있습니다.# System messages cat /var/log/messages Or dmesg -T
2.2.2 CPU
'uptime'/'top'은 지난 1/5/15분 동안의 시스템 로드 평균을 확인하는 데 사용할 수 있습니다. 이 수치를 볼 때 CPU 코어 수를 고려하세요. Linux에서 이 숫자에는 cpu/대기 중인 procs의 수와 무중단 절전 모드(일반적으로 디스크 i/o)의 수가 포함됩니다. 다음은 몇 가지 유용한 명령어입니다.
# To find load average "w" Or "uptime" Or "top" [root@svr001 ~]# uptime 21:32:09 up 12 days, 1:04, 3 users, load average: 0.31, 0.44, 0.64 # To find CPU Usage over time "sar -u 5" [root@svr001 ~]# sar -u 5 Linux 4.14.35-2025.401.4.el7uek.x86_64 (svr001) 12/16/2020 _x86_64_ (16 CPU) 09:52:20 PM CPU %user %nice %system %iowait %steal %idle 09:52:25 PM all 0.63 0.00 0.73 0.11 0.00 98.52 09:52:30 PM all 1.10 0.00 0.82 0.15 0.00 97.93 # To list the no. of processes in Runnable (R) and in Uninterruptible sleep (D) states "ps -eo s,user,cmd | grep ^[RD] | sort | uniq -c | sort -nbr | head -20"
2.2.3 메모리
'사용 가능한' 여유 메모리를 찾으려면 'free'를 사용합니다. 정상적인 시스템에는 충분한 공간이 있어야 합니다.
# Find system memory usage "free -m" [root@svr001 ~]# free -m total used free shared buff/cache available Mem: 385423 16603 188217 153744 180602 211778 Swap: 16383 0 16383'vmstat'은 스왑 통계(si,so)를 보는 데 사용될 수 있습니다. 정상 시스템에는 0이 표시되어야 합니다. 또한 문제에 따라 사용자가 관심을 가질 수 있는 procs/memory/cpu 등에 대한 다른 흥미로운 열도 제공합니다.
# Virtual Mem stats 5 snapshots 5 secs apart "vmstat 5 5" [root@svr001 ~]# vmstat 5 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 192717472 497132 184439376 0 0 82 35 2 0 1 1 98 0 0 1 0 0 192717520 497132 184439616 0 0 3225 719 15118 29594 1 1 98 0 0Hugepages를 사용 설정하지 않았다면 사용 설정하여 페이지 크기 확대, 시스템 메모리의 sga 잠금 기능을 활용하세요.
- awr 보고서의 init.ora 섹션(use_large_pages가 설정된 경우에만) 또는 alert.log의 인스턴스 시작 섹션에서 hugepage 사용량을 확인합니다.
- hugepage를 사용하지 않으면 시스템이 교체되고 db의 연결당 메모리 사용량이 증가할 수 있습니다.
2.2.4 스토리지
'iostat'을 사용하여 스토리지 포화도, sub-par 성능 등을 나타낼 수 있는 await, avgqu-sz, %util과 같은 블록 기기 통계를 볼 수 있습니다.
# IO Stats with extended per-disk statistics "iostat -x 5 5" Or "sar -dp" # For devices with 90% utilization and above "sar -dp | awk '/%util/ || ($11 > 90)'" [root@svr001 ~]# iostat -x 5 5 Linux 4.14.35-2025.401.4.el7uek.x86_64 (svr001) 12/16/2020 _x86_64_ (16 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 1.05 0.01 0.77 0.09 0.00 98.08 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sde 0.00 0.00 0.17 0.83 7.10 20.12 54.46 0.04 41.10 18.91 45.57 1.12 0.11 sdf 0.00 0.00 0.00 0.00 0.00 0.00 43.50 0.00 1.03 1.03 0.00 0.75 0.00 sdc 0.00 0.00 0.00 0.00 0.00 0.00 40.15 0.00 0.40 0.40 0.00 0.22 0.00 sda 0.00 0.00 1.16 20.80 7.76 177.15 16.84 0.02 0.82 0.73 0.83 0.14 0.31 sdd 0.00 0.00 43.24 8.03 639.16 97.67 28.75 0.01 0.20 0.18 0.31 0.18 0.92IO로 포화도를 볼 수 있는 경우 다음과 같은 방법으로 시작할 수 있습니다.
- SSD 볼륨에 대한 IOPS(8K 블록) 수의 QOS는 테라바이트당 6,000입니다. Google은 HDD를 위한 QOS를 제공하지 않습니다. 이 수치를 사용하여 올바른 기대치를 설정하세요.
- 위의 예상 QOS가 표시되지 않으면 다음 단계는 스토리지 구성과 관련된 권장사항을 준수하는지 확인하는 것입니다.
각 BMS 서버에는 4개의 NIC(각 25Gbps)가 있으며, 802.3ad 동적 링크 집계(활성-활성)를 사용하여 50Gb NIC 2개에 결합됩니다.
# Interface Transfer Speed # bond0 is the primary interface in this case. [root@svr001 ~]# ethtool bond0 | grep -i speed Speed: 50000Mb/s즉, 기본 네트워크 인터페이스의 포화점은 50000Mb/s = 6250MB/s = 6,400,000KB/s입니다.
# Interface stats "sar -n DEV | head -3 && sar -n DEV | grep bond0" [root@svr001 ~]# sar -n DEV | head -3 && sar -n DEV | grep bond0 12:00:01 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s 12:10:01 AM bond0.118 87.30 49.94 69.45 24.93 0.00 0.00 0.00 12:10:01 AM bond0 89.31 52.26 71.58 25.59 0.00 0.00 2.00 12:20:01 AM bond0.118 21.91 13.21 18.92 8.02 0.00 0.00 0.00 12:20:01 AM bond0 23.94 15.55 19.65 8.39 0.00 0.00 2.00
핑, traceroute, tnsping 등 일반적인 도구를 사용하여 사용자/앱 머신과 DB 서버 간의 패킷 손실/지연 시간 같은 네트워크 문제를 찾아보세요. 자세한 내용은 이 튜토리얼을 참조하세요.
# Quick check for 9000 mtu. # If not configured correctly, we will see "Message too long" errors ping -c 5 -s 8972 -M do <IP>awr 보고서에서 상호 연결 통계를 살펴보고 'netstat -s' 명령어(IP 통계 카운터)를 사용하여 올바른 기준과 비교하면 단편화/리어셈블리 실패, 버퍼 오버플로 문제 등을 확인할 수 있고 비공개 네트워크의 상태에 대한 정보를 볼 수 있습니다.
# Interface errors: [root@svr001 ~]netstat -s | egrep "IP|Ip|ip:|TCP|Tcp|tcp:|UDP|Udp|udp:|ICMP|Icmp|icmp:|IGMP|igmp:|icmpv6:|ipv6:|drop|Drop|dropped|Dropped|error|Error|discard|Discard|timeout|Timeout|fail|Fail|Receive|receive" Ip: 168848352 total packets received 0 incoming packets discarded 701 outgoing packets dropped 3265322 fragments received ok
2.3 데이터베이스 상태
이제 전체 시스템 상태를 확인하고 유용한 관찰을 했으므로 데이터베이스 레이어를 더 자세히 살펴볼 수 있습니다. 문제의 특성에 따라 문제를 진단하는 데 도움이 될 수 있는 모든 관련 보고서(aw, ash 등)와 로그 파일(tfa, 알림 로그, trace 파일 등)을 수집해야 합니다.
awr 보고서에서 확인할 주요 영역은 다음과 같습니다.
보고서 상단
- 환경 요약은 Oracle s/w 정보, 코어, 메모리, 경과 시간 및 db 시간 등의 호스트 정보에 대한 정보를 제공합니다.
- 부하 프로필은 Db 시간과 DB CPU, 파싱 통계, io 통계 등에 대한 정보를 제공합니다.
- DB 시간 = DB CPU + 대기 시간 + CPU 대기(실행 큐)
- DB CPU = CPU에서 실행되는 시간(runqueue는 포함되지 않음)
- 평균 활성 세션 = 데이터베이스 시간 / 경과 시간
- 초당 db CPU / (num_cpus * 경과 시간) - db의 CPU 포화도 정보 제공
Init.ora
- 여기에서 트리거될 수 있는 매개변수(밑줄, 데이터 가드 관련 등)를 찾습니다.
상위 포그라운드 시간이 지정된 이벤트
- 데이터베이스 시간 분포를 조사하여 개선의 가장 큰 가능성을 파악합니다.
- 섹션에 나타나는 상위 대기 시간의 이벤트와 DBTime%, 대기 클래스, avg. 시간 등 해당 이벤트의 성능 특성을 찾습니다.
- 이 섹션에서 찾을 수 있는 이벤트에 따라 awr 보고서의 다른 섹션으로 더 자세히 살펴볼 수 있습니다.
시간 모델 통계
- 이 섹션에서 살펴볼 중요한 통계는 파싱 관련, 백그라운드 CPU 시간, sql 실행 경과 시간, db cpu입니다.
- 일반적으로 SQL 처리 시간이 길고 파싱 시간이 짧으면 좋습니다. sql 실행 경과 시간이 db cpu보다 훨씬 길면 대기 시간이 길다는 의미일 수 있습니다.
인프라 문제와 관련된 일반적인 Oracle 대기 이벤트
로그 파일 동기화:
- 로그 파일 동기화는 기본 인프라 문제 또는 애플리케이션 설계로 인해 발생할 수 있습니다. 다음은 성능이 저하된 인프라가 이 대기 이벤트에 기여하는지 확인하는 데 사용할 수 있는 몇 가지 가이드라인입니다.
- 로그 파일 동기화는 데이터 스토리지가 관련된 경우 로컬 스토리지는 물론 원격 스토리지 또는 네트워크의 성능 저하로 인해 발생할 수 있습니다.
- 로그 파일 병렬 쓰기 성능은 로그 파일 동기화 성능에 직접 영향을 미치는 로컬 스토리지에 지연 시간이 존재하는지 여부를 알 수 있는 좋은 지표입니다. 대기 이벤트 히스토그램을 보고 적절한 기준과 비교하여 최근 변형을 식별할 수 있습니다. 일반적으로 디스크에 최적인 쓰기는 10ms에 가깝습니다.
- 이때 최대 가용성/보호 데이터 가드 설정을 설정할 수 있습니다. 데이터 가드 관련 대기와 히스토그램을 통해 네트워크 지연 시간 또는 대기 사이트의 IO 문제를 파악할 수 있습니다.
- 또 다른 원인은 과도한 커밋 또는 CPU 부족으로 인해 사용량이 많은 lgwr입니다. '백그라운드 CPU 시간' 통계를 확인하여 db 시간의 많은 부분을 차지하지 않는지 확인하세요.
- 로그 파일 동기화는 기본 인프라 문제 또는 애플리케이션 설계로 인해 발생할 수 있습니다. 다음은 성능이 저하된 인프라가 이 대기 이벤트에 기여하는지 확인하는 데 사용할 수 있는 몇 가지 가이드라인입니다.
Cloud Storage 관련 대기:
- 채팅 애플리케이션 조정 또는 부하 집중 문제 외에도 상호 연결 성능 병목 현상을 방지해야 합니다.
- GLOBAL CACHE BLOCKS LOST/CORRUPT는 최대한 0에 수렴해야 합니다.
- LOST - 전송 중의 블록 손실. 네트워크 문제를 나타낼 수 있습니다.
- CORRUPT - 이 값이 높으면 IPC, 네트워크, 또는 하드웨어 문제를 나타냅니다.