My Oracle Support Banner

RAC 환경에서 gc block lost 와 네트워크 성능 저하 해결 방법 (Doc ID 1557708.1)

Last updated on MARCH 22, 2019

적용 대상:

Oracle Database - Enterprise Edition - 버전 9.2.0.1 과(와) 그 후속
Oracle Database Cloud Schema Service - 버전 N/A 과(와) 그 후속
Oracle Database Exadata Cloud Machine - 버전 N/A 과(와) 그 후속
Oracle Cloud Infrastructure - Database Service - 버전 N/A 과(와) 그 후속
Oracle Database Backup Service - 버전 N/A 과(와) 그 후속
이 문서의 내용은 모든 플랫폼에 적용됩니다.
Oracle Clusterware & Oracle Real Application Clusters


증상

요약

오라클 RAC 환경에서 RDBMS 는 STATSPACK, AWRs, GRID CONTROL에서 보고되어지는 글로벌 캐시 워크로드 통계(global cache work load statistic)들을 수집합니다. 클러스터 각 노드에 글로벌 캐시 손실 블록 통계 ("gc cr block lost" and/or "gc current block lost") 뿐만이 아니라 클러스터의 집계 통계 또한 인터커넥트 트래픽을 위한 패킷 처리에 비효율 또는 문제를 보여줍니다. 이 통계들은 효율적인 인터커넥트 GCS/GES(Global Cache and Enqueue Service)를 보장하기 위해 주기적으로 모니터링 되어져야 하고 평가되어야 합니다. 블록의 손실은 네트워크 처리에 문제를 나타내며, 조사되어야 합니다.

RDBMS 글로벌 캐시 손실 블록에 이르게 하는 매우 방대한 단계적 확대는 잘못되거나 잘못 설정된 인터커넥트와 직접적으로 관련이 있을수 있습니다. 이 문서는 일반적인 원인들을 평가하고 조사할 수 있는 가이드를 제공합니다.

많은 논의가 성능 이슈로 초점이 맞추어지더라도, 이 문제들로 인해 노드/인스턴스 축출(eviction)이 발생할 수 있습니다. 오라클 클러스터웨어와 오라클 RAC 인스턴스들은 노드 멤버의 Heartbeat을 필요로 합니다. 네트워크 Heartheat이 지속적으로 삭제된다면, 인스턴스/노드 출축이 발생할 수 있습니다. 그러므로, 아래의 증상들은 노드/인스턴스 축출과 관련이 있습니다.

증상:

주요 사항:
  • 상위 5개 또는 주요 wait event 에서 "gc cr block lost" / "gc current block lost"

Secondary:

  • SQL 트레이스는 오랜 기간 동안 다수의 gc cr requests / gc current request / gc cr multiblock를 보고
  • 어플리케이션 성능 저하 / 낮은 처리량
  • Ifconfig 또는 벤더에서 제공된 유틸리티에서 보여지는 패킷 송수신 에러
  • Netstat는 에러/재전송/재어셈블리 실패를 보고
  • 노드 실패와 노드 통합 실패
  • 네트워크 처리에 영향을 주는 비정상적인 CPU 소모

 

주의: 손실 블록 문제는 자주 gc cr multiblock 대기와 함께 발생합니다. 그것은 연속된 블록들의 탐색에서 대기합니다.

 

원인:

글로벌 캐시 블록 손실(Global Cache Block Lost) 분석 가이드

    1. 잘못된 또는 잘못 장착된 케이블/카드/스위치

      설명: 잘못된 네트워크 케이블 접속, 잘못된 케이블, 잘못 설치된 케이블, 과도한 길이와 잘못된 포트 할당, 잘못된 스위치는 보다 낮은 비트율, 손상 프레임, 삭제된 패킷과 성능 저하를 유발할 수 있습니다.

      수행: 물리 네트워크 확인, 잘못된 네트워크 부품 교체를 위해 네트워크 벤더에 문의하십시오. CAT 5 품질 케이블 또는 더 좋은 것을 인터커넥트 링크를 위해 설치되어야 합니다. 해당이 된다면 모든 케이블은 LAN/port와 aggregation에 따라 안전하게 설치되고 라벨링 되어야 합니다. 케이블 길이는 벤더 이더넷 스펙을 따르십시오.
    2. 잘못된 크기를 가지는 UDP 수신(rx) 버퍼 크기 / UDP 버퍼 소켓 오버플로우

      설명: 오라클 RAC의 글로벌 캐시 블록(Global cache block)의 처리는 기본적으로 버스티하고, 그 결과 OS는 CPU를 사용을 기다리는 동안 수신(rx) 패킷을 버퍼할 필요가 있습니다. 사용가능하지 않은 버퍼 공간은 보여지지 않는 패킷 손실과 글로벌 캐시 블록 손실에 이르게 할 수 있습니다. 대부분의 UNIX 환경에서 'netstat -s' 또는 'netstat -su' 명령어는 UDPInOverflows, 패킷 수신 에러, 버퍼 풀 에러 때문에 삭제된 프레임을 결정하는데 도움을 줄 것입니다.

      수행: 패킷 손실은 수신 서버 측에 부적절한 (rx) UDP 버퍼 사이징으로 발생합니다. 그 결과, 버퍼 오버플로우와 글로벌 캐시 블록 손실이 발생합니다.소켓을 위한 UDP 수신(rx) 버퍼 크기는 오라클이 소켓을 열려고 할 때 OS 설정이 128k 보다 작으면 128k로 설정됩니다. OS 설정이 128k 보다 크다면 오라클은 그 값을 변경없이 반영합니다. UDP 수신 버퍼 크기는 데이터베이스 블록 크기가 8k 보다 더 큼에 따라 자동으로 증가시킬 겂입니다. 그러나, 이 작업은 OS 제한 값까지만 증가시킬 것입니다. UDP 버퍼 오버플로우. 패킷 손실과 손실 블록은 DB_FILE_MULTIBLOCK_READ_COUNT 값이 4보다 큰 환경에서 부적절한 버퍼 설정으로 인해 "global cache cr requests"에 과도한 타임아웃이 발생하는 환경에서 확인될 수 있습니다. 이 문제를 피하기 위해서는 UDP 버퍼 크기를 증가시키고, 시스템이나 활성화 세션을 위한 DB_FILE_MULTIBLOCK_READ_COUNT 값을 줄이십시오.

      UDP 소켓 버퍼 오버플로우와 패킷 손실을 경험하고 있으신 경우, 이것을 확인하기 위해 대부분의 unix 플랫폼에서 다음의 명령을 수행 하십시오.

      'netstat -s' or 'netstat -su' and look for either "udpInOverflowsudpInOverflows", "packet receive errors", "fragments dropped" or "outgoing packet drop" depending on the platform.

      주의: UDP 패킷 손실은 일반적으로 지연 증가, 대역폭 감소, CPU 활용율 증가(kernel / user ), 패킷 재전송을 위한 메모리 소모를 유발시킵니다.

      작업 로드가 수행되고 있는 원격 노드에서 netstat -s 결과에서 TCP section 중 "outgoing packets dropped" 이 상당히 증가한다면, wmem_default and wmem_max를 4MB(linux)로의 증가로 이슈를 해결할 수 있습니다.

      UDP 송수신 버퍼 파라미터는 OS에 종속적입니다. 그것들은 롤링 방식으로 변경될 수 있습니다(eg. 한번에 1 노드).
    3. 낮은 인터커넥트 성능과 높은 CPU 활용율. `netstat -s` 는 패킷 재어셈블리 실패를 보고합니다.

      설명: 큰 UDP 데이터그램은 조각이 날 수 있으며 MTU(Medium Transmission Unit) 크기를 기본으로 하여 여러 프레임으로 전송될 수 있습니다. 이 조각난 패킷들은 수신 노드에서 재어셈블리될 필요가 있습니다. 높은 CPU 활용율(지속적이고 잦은 튀는 현상), 부적절한 재어셈블리 버퍼와 UDP 버퍼 공간은 패킷 재어셈블리 실패를 야기할 수 있습니다. `netstat -s` 는 수신 노드의 "IP Statistics" 섹션의 결과에 많은 수의 IP "reassembles failed(재어셈블리 실패)" and "fragments dropped after timeout(타임아웃 후 삭제된 프레임)"를 보고해 줍니다.조각난 패킷들은 재어셈블리를 위해 . 재어셈블리 되지 않은 패킷들은 삭제되고 다시 요청됩니다. 도착하였으나 재어셈블리를 위한 공간이 없는 조각들은 조용히 삭제됩니다.


      `netstat -s` IP stat counters:
           3104582 fragments dropped after timeout
           34550600 reassemblies required
           8961342 packets reassembled ok
           3104582 packet reassembles failed.

      수행: 재어셈블리에 더 많은 공간을 할당하도록 조각 재어셈블리 버퍼를 증가시켜 주십시오. 패킷 조각을 재어셈블리하는 시간을 증가시켜주시고, 재어셈블리 실패를 악화의 원인이 되는 네트워크 처리 지연을 충분히 수용할 수 있도록 udp 수신 버퍼를 증가시켜 주시고, 네트워크 스택 처리에 부정적인 영향을 CPU 사용량을 확인하여 주십시오.
      주의 해주십시오. 다음의 설정값의 증가는 메모리 사용량 또한 증가할 것입니다.

      On LINUX:
      재어셈블리 버퍼 크기를 변경하기 위해, 다음의 기준치를 변경하십시오:

      /proc/sys/net/ipv4/ipfrag_low_thresh (default = 196608)
      /proc/sys/net/ipv4/ipfrag_high_thresh (default = 262144)

      패킷 조각 재어셈블리 시간을 변경하기 위해, 아래와 같이 변경하십시오:
      /proc/sys/net/ipv4/ipfrag_time (default = 30)

      동일한 OS 커맨드 문법을 확인하십시오. 주의하실 부분으로 위 내용은 RHEL 6.6 에는 적합하지 않습니다. RHEL 6.6 에서는 다음 노트를 참고해 주십시오.
      "RHEL 6.6: IPC Send timeout/node eviction etc with high packet reassembles failure" <Note 2008933.1>
    4. UDP 체크섬(Checksum) 에러 또는 송신(tx)/수신(tx) 전송 에러로 인한 네트워크 패킷 손상

      설명: UDP는 수신 시 읽는 패킷 헤더에 체크섬 필드를 포함합니다. 체크섬 손상은 패킷 삭제를 유발시킵니다. 체크섬 손상은 패킷 처리에 추가적인 요청과 지연으로 인해 패키 재전송과 추가적인 CPU 오버헤드를 유발시킵니다.

      수행: 체크섬 에러를 확인하고 체크섬 손상을 확정하기 위해 패킷 덤프를 캡쳐할 수 있는 tcpdump/snoop와 같은 네트워크 스니퍼(sniffer) 유틸리티를 사용하십시오.  주 원인을 위해 시스템 관리자와 네트워크 엔지니어에 문의하십시오. NIC 체크섬 오프로딩(NIC checksum offloading)은 체크섬 에러를 발생시킬 수 있는 것으로 알려져 있습니다. 설정되었고 테스트 되었다면, NIC 체크섬 오프로딩에 대해 비활성화 하는 것을 고려하여 주십시오. NIC 체크섬 오프로딩에 대해 비활성화 하는 것을 고려해 주시고, 설정이 되었다면 테스트해 주십시오. 리눅스에서는 ethtool -K <IF> rx off tx off 이 체크섬 오프로딩을 비활성화 합니다

    5. 통신 경로에서 일치하지 않는 MTU 크기

      설명: 일치하지 않는 MTU 크기는 글로벌 캐시 블록 손실과 과도한 패킷 재전송 요청을 이르게 하는 "packet too big" 실패와 silent 패킷 손실을을 유발할 것입니다.
      Action: MTU는 최대 전송 유닛(Maximum Transmission Unit) 또는 인터커넥트 인터페이스들에 설정된 프레임 크기입니다. 대부분의 Unix 기본 표준은 이더넷에서 1500 byte 입니다. MTU 정의는 인터커넥트 통신 경로에서 모든 장치들은 동일해야만 합니다. 인터커넥트 통신 패스에서 모든 장치들을 확인하고 감시하십시오. 통신 패스에서 불일치하는 MTU를 감지하기 위해 `ping`, `tracepath`, `traceroute` 와 같은 . 서버 NIC의 MTU 크기를 설정하고 결정하기 위해 `ifconfig` 또는 벤터에서 권장하는 유틸리티를 사용하십시오. 아래 #12의 점보 프레임(Jumbo Grames)을 확인하십시오. 주의: 인터커넥트에서 불일치하는 MTU 크기는 10g와 11g 클러스터 노드에 조인할 수 없게 할 것입니다.
    6. Interconnect LAN non-dedicated

      설명: 인터커넥트 LAN에 설정된 공유된 공개 IP 트래픽과(/또는) 공유된 NAS IP 트래픽은 어플리케이션 성능 저하, 네트워크 혼잡과 극단적인 경우 글로벌 캐시 블로 손실에 이르게 합니다.
      Action: 인터커넥트/클러스터웨어 트래픽은 라우팅되지 않은 서브넷에 정의된 단일 LAN에서여야만 합니다. 인터커넥트 트래픽은 인접한 스위치들에 분리되어야 합니다. e.g. 인터커넥트 트래픽은 링크가 부착된 억세스 레이어 스위치(Access Layer Switch)를 넘어 확장해서는 안됩니다. VLAN(Virtual LANs)이 사용되고 있다면, 인터커넥트는 단일의 라우팅 되지않은 서브넷에 매핑된 하나의 단일 VLAN 이어야합니다. 그리고 그것은 공개 또는 NAS 트래픽과는 분리되어야 합니다.
    7. 서버/스위치 인접성의 결여

      설명: 네트워크 장치들이 하나의 링크 레이어 사이에서 하나의 홉(hop)만으로 서로 도달할 수 있다면 인접하다고 말합니다. 통신 채널에서 다른 네트워크 장치들이 있다면, 여러 홉은 지연을 증가시키고 불필요한 복잡성과 위험성이 발생합니다.
      Action: 모든 GbE 서버 인터커넥트 링크들은 스위치에 직접적인 부착은 OSI 레이어 2 이어야 합니다.인터커넥트 통신 경로에서 라우터와 같이 중재 디바이스여서는 안됩니다. 유닉스 명령어 `traceroute`는 인접 이슈를 확인하는데 도움을 줄 것입니다.
    8. IPFILTER가 구성된 경우

      설명:IPFILTER(IPF)는 인터커넥트 트래픽에 문제를 발생시킬 수 있는 호스트 기반의 방화벽이나 NAT(Network Address Translation) 같은 소프트웨어 패키지입니다. IPF는 심각한 성능 저하와 패킷 손실과 글로벌 캐시 블록 손실(Global cache block lost)이 발생할 수 있습니다.
      수행: IPFILTER를 비활성화 하십시오
    9. 구버전의 네트워크 드라이버 또는 NIC 펌웨어

      설명: 구버전의 네트워크 드라이버 또는 NIC 펌웨어는 인터커넥트를 통한 패킷 처리에 문제를 발생시키는 원인으로 알려져있습니다. 노드 간 통신 시, 호환이 되지 않는 NIC 드라이버는 패킷 처리 지연, 비대칭 지연, 패킷 손실이 발생할 수 있습니다.
      수행: 서버 NIC는 같은 모델이어여 하고 모든 노드에 동일한 성능 설정을 가져야하며, 슬롯 ID에서 대칭적이어야 합니다. 펌웨어와 NIC 드라이버는 클러스터의 모든 서버에 있는 인터커넥트 NIC에서 최신의 동일한 rev 이어야 합니다.
    10. 고유 인터커넥트 링크 전송과 네트워크 프로토콜

      설명: LLT, HMP등 비표준, 고유 프로토콜은 디버그하기 힘든고 불안정한 것으로 확인되었습니다. 잘못 설정된 고유 프로토콜들은 어플리케이션 성능 저하와 패킷 드롭, 노드 장애를 발생시킵니다.
      수행: 오라클은 전송과 프로토콜로써 1GbE UDP에 표준화되었습니다. 이것은 안정적이고 신뢰할 수 있으며, 성능에 문제가 없음이 확인되었습니다. 고유 프로토콜과 비표준 프로토콜은 사용하지 않아야 합니다. 인피니밴드에 IP와 RDS는 인터커넥트 네트워크 설치 동안 가능하고 지원됩니다. 10GbE는 일부 플랫폼에서 인증되었습니다(상세사항을 위해 OTN을 확인하십시오). 이 부분에 대한 인증 작업은 진행 중입니다.
    11. 잘못 설정된 bonding/link aggregation

      설명: 서버에 부적절한 NIC Link Aggregation 이나 Bonding 또는 인터커넥트 통신을 위한 인접한 스위치에 aggregation 잘못된 설정은 묶여진 링크를 형성하는 스위치의 인터커넥트 포트들의 상태가 너무 자주 'UP'/'DOWN' 이 변경되는 "포트 플랩핑(port flapping)" 때문에 성능 저하와 블록 손실을 발생시킬 수 있습니다. 
      Action: 클러스터된 서버에서 link aggregation을 사용한다면, 스위치에 포트는 또한 인터커넥트 링크에 link aggregation 을 위해 지원되어야 하고 설정되어야 합니다. 스위치 상의 인터커넥트에 부적절하게 설정된 aggregation은 'port flapping'과 패킷 삭제를 유발시키는 스위치 포트 랜덤 삭제 을 유발시킬 것입니다.
      Bonding/Aggregation 은 드라이버 문서를 통해 올바르게 구성되어야만 하고 부하 상태에서 테스트 되어야 합니다. 테스트에 도움을 주는 많은 공개 도메인 유틸리티가 있습니다. 링크 대역폭과 지연된 성능을 측정하십시오. OS, 네트워크와 네트워크 드라이버 통계들은 bonding의 효율성을 결정하기 위해 평가되어야만 합니다.
    12. 잘못 구성된 점보 프레임(Jumbo Frames)

      설명: 잘못 구성된 점보 프레임은 아래에 설명되어 있는 일치하지 않는 MTU 크기를 만들수 있습니다.
      수행: 점보 프레임은 IEEE 표준이 아니며, 이 때문에 구성 시 주의가 필요합니다. 점보 프레임은 약 9000 byte의 프레임 크기입니다. 프레임 크기는 네트워크 장치 벤더에 따라 다를 수 있고, 통신하는 장치들 간에는 일치하지 않을 수 있습니다. 기본 설정 값이 9000 바이트가 아니라면 동일한 MTU 크기가 통신 채널의 모든 장치들에 설정되어야 합니다. 운영에 사용되는 모든 네트워크 장치, 스위치/NIC/라인 카드들은 같은 프레임 크기(MTU 크기)를 지원하도록 설정되어야 합니다. 스위치에서는 MTU:1500으로 설정되었지만 서버의 인터커넥트 인터페이스에서는 MTU:9000으로 설정된 불일치한 MTU 크기는 심각한 성능 저하와 클러스터 노드 패킷 손실, 패킷 조각화와 재어셈블리 에러와 클러스터 노드 장애에 이르게 할 것입니다. 대부분의 플랫폼에서 `netstat -s` 명령으로 IP 통계들은 프레임 조각화와 재어셈블리 에러를 판별할 것입니다. 대부분의 플랫폼에서 `ifconfig -a` 명령은 사용 중인 프레임 크기(MTU:1500)을 판별할 것입니다. S점보 프레임 지원을 확인하기 위해 스위치 벤더 문서를 확인하십시오.
    13. NIC 전-양방과 양방 모드 불일치

      설명: 양방 모드 불일치는 통신 채널에서 두 노드가 한 쪽에서는 반-이중(half-duplex)로 작동하고 있고, 다른 곳에서는 전 양방(full duplex)로 작동하고 있을 때 발생합니다. 이 증상은 매뉴얼로 잘못 설정된 이중 모드 또는 통신 파트너가 자동 협상(autonegotiation)되는 동안 한쪽이 반-이중으로 매뉴얼로 설정되었을 때 발생할 수 있습니다. 이중 모드 불일치는 심각하게 성능이 저하된 인터커넥트 통신을 유발시킵니다.
      수행: 이중 모드는 인터커넥트 링크를 서비스하는 스위치에서 클러스터의 모든 서버 NIC들과 라인 카드들에 대해 자동 협상이 되도록 설정되어야 합니다. 기가비트 이더넷 표준은 수행하기 위해 자동 협상을 "ON"으로 설정하는 것이 요구됩니다. 이중 모드 불일치는 심각한 네트워크 저하, 출돌 과 패킷 삭제를 유발할 수 있습니다. 자동 협상 이중 모드는 네트워크 인터페이스에 영향을 주는 모든 하드웨어와 소프트웨어가 업그레이드된 후 확인되어야 합니다. 모든 인터페이스에 자동 협상은 1000 전이중(full duplex)로 작동할 것입니다.

    14. 인터커넥트 경로에서 흐름-제어(Flow-control) 불일치

      설명: 흐름 제어는 서버 쪽에서 네트워크 피어(또는 경로에서 네트워크 디바이스)가 데이터를 받아들이는 것 보다 더 빠르게 데이터를 전송하고 있을 때의 상황입니다. 수신 측 장치는 송신 측에 일시적으로 전송을 정지하는 요청하는 PAUSE 프레임을 보내야할 수 있습니다.
      수행: 서버상에 스위치들과 NIC들 사이에 흐름 제어 불일치는 패킷 손실과 심각한 인터커넥트 네트워크 성능 저하를 유발할 수 있습니다. 대부분의 사례에서 기본 설정값 "ON"은 최대의 결과를 낼 것입니다. e.g:

      tx 흐름 제어는 "ON" 이어야 합니다
      rx 흐름 제어는 "ON" 이어야 합니다.
      tx/rx 흐름 제어는 스위치에서 "ON" 이어야 합니다

      그러나, OS 드라이버 또는 스위치 펌웨어에 버그와 같은 일부 특별한 사례(e.g. <note 400959.1>)에서 OFF 설정(모든 네트워크 경로에서)은 더 좋은 결과를 낼 것입니다..
      주의: 펌웨어/네트워크 드라이버 업그레이드 후 흐름 제어 정의들이 변경되었을 수 있습니다. NIC & 스위치 설정들은 업그레이드 후 확인되어져야 합니다. 하드웨어 벤더가 다른 것을 제안하지 않으면 기본 설정을 사용하십시오.
    15. OS, NIC 또는 스위치 레이어에서 패킷 삭제

      설명: OS, NIC 또는 스위치에서 보고되는 패킷 삭제는 철저히 조사되어야 하고 해결되어야 합니다. 패킷 손실은 인터커넥스 성능 저하, CPU 오버헤드, 네트워크/노드 장애를 유발시킬수 있습니다.
      수행: 특별한 툴들은 패킷/프레임 손실(프로세스/OS/네트워크/NIC/스위치)을 겪고 있는 특정 레이어를 확인하는 작업에 도움을 줄 것입니다. netstat, ifconfig, ethtool, kstat (OS에 종속됨) 그리고 스위치 포트 상태는 평가하기 위해 처음으로 분석해야할 것입니다. 이 문제를 해결하는데 도움을 얻는 end-to-end 패킷 통신을 추적하기 위해 네트워크 스니퍼를 사용할 수도 있습니다(snoop/wireshare/ethereal 같은 공개 툴들을 확인하십시오). 주의해주십시오. 더 낮은 레이어에서 패킷 손싱을 이해하기 위해서는 근본 원인을 밝히는 것이 필수적일 것입니다. 네트워크 인터페이스에 낮게 사이징된 링 버퍼와 수신 큐는 조용한 패킷 손실, 즉 어떠한 레이어에서도 보고되지않는 패킷 손실을 유발하는 것으로 알려져 있습니다. NIC 드라이버 이슈들과 커널 큐 길이를 확인하십시오. 근본 원인을 찾기 위해 시스템 관리자와 네트워크 엔지니어에게 문의하십시오.
    16. NIC 드라이버/펌웨어 설정

      설명: 튜닝이 가능한 NIC public 속성에 잘못 설정되거나 부적절한 기본 설정은 보이지 않는 패킷 손실과 재전송 요청 증가를 발생시킬 수 있습니다.
      수행: 기본 공장 설정은 대부분의 네트워크 설치에 만족해야만 합니다. 그러나, 일부 NIC 벤더들과 인터럽트 통합 설정 및 디바이스에 연관된 링 버퍼의 디스크립션의 수를 변경을 요구하는 인터커넥트 트래픽의 본연과 관련되어 이슈가 있습니다. 인터럽트 통합은 송신(tx)와 수신(rx) 패킷 처리를 위한 CPU 인터럽트 비율입니다. 링 버퍼들은 CPU 인터럽트들 사이에 처리를 위한 rx 패킷들을 잡고 있습니다. 이 레이어에 잘못된 설정은 가끔 silent 패킷 손실의 원인이 됩니다. 이 레이어의 분석은 시스템 관리자와 OS/벤더 부분의 확인이 필요합니다.
    17. NIC 송신(tx)와 수신(rx) 큐 크기

      설명: 부적절하게 크기가 설정된 NIC tx/rx 큐 크기는 큐가 가득찰 때 보이지 않게 패킷이 삭제될 수 있습니다.  이것으로 인해 글로벌 캐시 블록 손실(gc block loss), 늘어난 패킷 재전송, 인터커넥스 성능 저하를 유발시킵니다.
      수행: 패킷이 커널 네트워크 서브시스템과 네트워크 인터페이스 드라이버 사이로 이동할 때, 송신(tx) 와 수신(rx) 큐들은 패킷 전송과 처리를 관리하기 위해 구현되었습니다. 이 큐들의 크기는 설정 가능합니다. 이 큐들이 생성된 네트워크 트래픽 전체 또는 구성된 MTU 크기 대비해 낮게 설정되거나 잘못 설정되었다면, 큐가 가득차게 되어 오버플로우와 패킷 손실을 유발시킬 것입니다. 드라이버와 디바이스 수집된 통계의 품질에 따라 이 패킷은 탐지하기 쉽지 않을 수 있습니다. 이 레이어에 대한 분석은 시스템 어드민과 OS/벤더에 요청을 하십시오.(c.f. iftxtqueue and netdev_max_backlog on linux)
    18. 제한된 허용량과 포화 상태의 대역폭

      설명: 네트웍 사용량 포화는 인터커넥트 성능 저하와 패킷 손실에 이를 것입니다.
      수행: 인터커텍트 배치의 최적 사례는 인터커넥트 사용량과 대역폭을 인지하는 것입니다. 이것은 사용 현황을 확인하기 위해 일시적이던 영속적이던 주기적으로 감시되어야만 합니다. 인터커넥트에 증가하는 요청은 어플리케이션의 크기 조정 또는 Bad SQL 구문 같이 잘못된 사용 또는 예상하지 못한 트래픽 몰림 현상에 이를수 있습니다. 대역폭 포화의 원인을 가늠해보고 그것을 다루십시오.
    19. 높은 CPU 와 스케줄링 지연

      설명: 지속된 높은 로드 평균과 네트워크 스택 스케줄링 지연은 인터커넥트 패킷 처리에 부정적인 영향을 끼칠수 있고, 인터커넥스 성능 저하, 패킷 손실, 글로벌 캐시 블록 손실(gc block loss), 노드 장애의 원인이 될 수 있습니다.
      수행: 시스템이 높은 CPU 활용률을 보일 때의 스케줄링 지연은 네트워크 패킷 처리 지연에 이르게 합니다. 과도하고, 지속된 지연은 심각한 성능 저하을 유발시키고, 클러스터 노드 실패을 유발시킵니다. 지속된 높은 CPU 활용율이 조사되어져야 하는 것은 매우 중요합니다. 명령어 `uptime` 은 대부분의 플랫폼에서 로드 평균 정보를 보여줄 것입니다. 네트워크 스택 처리에 관련된 과도한 CPU 인터럽트는 NIC 인터럽트 통합과(또는) 하나의 CPU에 네트워크 인터럽트가 바인딩을 통해 약화될 수 있습니다. 최적화의 이러한 유형들을 위해 NIC 벤더와 함께 수행하십시오. 스케줄링 지연은 재어셈블리 에러를 유발시킬 수 있습니다. 위의 #2 를 확인하십시오.

    20. 패킷 처리 문제들과 관련된 스위치

      설명: 스위치 포트에 버퍼 오버플로우, MTU 크기 같은 잘못된 스위치 설정과 스위치 정체, aggregation 과 VLAN은 성능 저하와 클러스터 노드 장애에 원인이 되는 비효율적인 패킷 처리에 이르게 할 수 있습니다.
      수행: 오라클 인터커넥트는 스위치 이더넷 네트워크를 요구합니다. 스위치는 인터커넥트 트래픽의 끝을 잇는 패킷 통신에 핵심적인 구성요소입니다.  네트워크 장치로써 스위치는 인터커넥트 성능과 가용성에 부정적인 영향을 끼칠 수 있는 많은 요소 또는 조건들이 있을 수 있습니다. 스위치에서 비정상적 여부, 패킷 처리 이벤트, 임시적이거나 계속된 트래픽 혼잡과 효율적인 처리량이 감시되어야 하는 것은 중요합니다. 스위치 통계들은 인터커넥트 트래픽에 트렌드를 알고 잘못된 증상을 확인하기 위해 주기적인 간격으로 측정되어야 합니다.
    21. 인터커넥트 패킷 처리에 부정적인 영향을 주는 QoS

      설명: 인터커넥트 트래픽을 공유하는 스위치의 QoS(Quality of Service) 설정은 심각한 성능 저하가 원인이 되어 인터커넥트 네트워크 처리에 부정적인 영향을 줄 수 있습니다.
      수행: 인터커넥트가 VLAN에 의해 분할된 공유 스위치에 구성되었다면, 공유 스위치에 QoS 정의가 인터커넥트 패킷 처리에 부정적인 영향을 주지 않는 서비스 우선순위 같은 것이 설정되어야 합니다.  QOS 정의들은 설치되기전에 평가되어야 하고 영향이 측정되어야 합니다.
    22. 망 복구(reconvergence) 동안 스패닝 트리 브라운아웃(spanning tree brownout)

      설명: 이더넷 네트워크는 호스트에 중복 경로가 있는 루프-프리(loop-free) 토폴로지를 보장하기 위해 스패닝 트리 프로토콜(STP, Spanning Tree Protocol)을 사용합니다. STP 토폴로지에 참여하는 네트워크 장치의 장애는 호스트에 경로를 재설정하는 토폴로지의 망 복구를 수행합니다. LAN 에서 STP가 활성화 되었고, 잘못 설정되었으며 효율적이지 못하다면, 망복구 동안 다시 계산하기 위해 1분이나 그 이상이 소요될 수 있습니다(네트워크와 디바이스의 크기에 따라 달라짐). 이와 같은 지연은 인터커넥트 실패와 클러스터 전반적인 장애를 발생시킬 수 있습니다.
      수행: 많은 스위치 벤더들은 망 복구 시간을 더 빠르게 하기 위해 STP 에 더 효율적인 확장 기능을 제공합니다. RSTP(Rapid Spanning Tree Protocal), PVST(Per-VLAN Spanning Tree), MSTP(Multi-Spanning Tree) 같은 프로토콜을 제공하여 클러스터 전반의 장애를 피하도록 구축되어져야 합니다.
    23. STREAMS queuing 에서 부적절한 sq_max_size

      설명: AWR 에서 "gc cr block lost",  "gc current block lost" 에 높은 대기를 보고되고, netstat 결과는 어떠한 패킷 처리 에러를 보여주지 않았습니다. 'kstat -p -s'*nocanput*` 는 0이 아닌 값을 반환하였습니다. "nocanput" 메시지는 스트리밍 메시지에 큐들이 가득 찼으며(full) 패킷이 드롭되었다는 것을 나타냅니다. 고객고객은 Solaris 환경에 RAC에 STREAMS를 구동 중입니다.
      수행: udp 최대 버퍼 공간(udp_max_buf)을 증가시키고 STREAMS의 queuing 을 무제한으로 설정함으로써, 문제를 해결 하고 "nocanput" 손실 메시지를 제거해야 합니다. 다음은 이 변경 사항을 만들 수 있는 Solaris 명령입니다:

      `ndd -set /dev/udp udp_max_buf <NUMERIC VALUE>`
      set sq_max_size to 0 (unlimited) in /etc/system. Default = 2

      udp_max_buf는 UDP 소켓을 위해 송/수신 버퍼(in bytes)를 얼마나 크게 할 것인지 조절합니다. 기본 설정 값인 262,144 byte는 STREAMS 어플리케이션에서 부적절할 수 있습니다. sq_max_size 메시지 큐의 깊이(depth)입니다.
    24. VIPA 와 DGD 구성이 올바르지 않은 경우(only AIX platform)

      가상 IP 주소(VIPA)가 AIX 플랫폼에서 클러스터 인터커넥트로 사용되었다면, Dead Gateway Detection(DGD)를 위해 UDP 페일오버가 설정되어야만 합니다.
      기본값으로 DGD 파라미터들이 구동 시점에 수행되는 것이 권장되지만, 고객 환경에 맞게 튜닝되어질 필요는 있습니다. 그러나, 대부분 1 의 값보다 크게 설정되어야만 합니다. 기본 설정값은 다음과 같습니다.

      dgd_packets_lost = 3
      dgd_ping_time = 5
      dgd_retry_time = 5

      Refer to Using VIPA and Dead Gateway Detection on AIX for High Availability Networks, including Oracle RAC
      http://www-01.ibm.com/support/docview.wss?uid=tss1wp102177

    25. Solaris + Veritas LLT 환경에서 잘못 설정된 스위치

      VCS 명령 lltstat 에서 확인되었으며, "Snd retransmit data" 가 증가할 때마다 gc block lost 수치 또한 증가합니다.
      인터커넥트 스위치 속도를 fixed 에서 auto-negitiate 로 변경하시고, 인터커넥스 스위치에서 케이블들을 각각의 모듈들에 공평하게 분배하십시오.
      이렇게 하심으로써 "gc block lost"가 발생하지 않게 해줄 것입니다.

    26. 12.1.0.2 버전에서 <Bug 20922010> FALSE 'GC BLOCKS LOST' REPORTED ON 12.1 AFTER UPGRADING FROM 11.2.0.3

      본 이슈는 12.1.0.2.161018 와 12.2.0.1 에서 해결되었습니다. 더 많은 정보를 위해서는 다음의 문서들을 참고해 주십시오:
      <Note 20922010.8> Bug 20922010 - False 'gc blocks lost' reported on 12.1 after upgrading from 11.2
      <Note 2096299.1> False increase of 'Global Cache Blocks Lost' or 'gc blocks lost' after upgrade to 12c

 

변경 내역

위에서 설명한 대로 손실된 블록은 신뢰할 수 없는 사설 네트워크에 의해 일반적으로 발생합니다. 이것은 잘못된 패치나 잘못된 네트워크 설정이나 하드웨어 이슈에 의해 발생할 수 있습니다.

원인

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


이 문서에서
증상
 요약
 증상:
 원인:
 글로벌 캐시 블록 손실(Global Cache Block Lost) 분석 가이드
변경 내역
원인
해결책
 Community Discussions

참고

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.