ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 올플래시 스토리지로 교체 후 DB 성능 저하 현상
    성능 이슈 2020. 12. 17. 23:54

    구형 스토리지를 새로운 AFA (All-Flash Array)로 교체 후 발생한 DB 성능 저하 이슈에 대한 해결 사례를 공유한다.

     

    시스템 환경

    • Platform : AIX-Based Systems (64-bit)
    • CPU : 40 (10Cores)
    • Memory : 40GB
    • Database : Oracle 11g R2

     

    이상 현상

    • 스토리지 교체 (HDD → SSD) 후 DB (Oracle) 성능이 좋아진 것을 잘 모르겠으며, 오히려 더 느려진 업무도 있다는 고객 피드백

     

    원인 분석

    • 스토리지 교체 전과 후의 Oracle AWR 분석
    • SGA 크기 : 8800M (sga_target)
      교체 전 교체 후
    Buffer cache 5728M 3360M
    Shared pool 2848M 5216M
    Buffer Hit % 98.59 97.91

     

    성능 저하 원인

    • Oracle에 의한 System Global Area 메모리 자동 관리됨
    • All-flash 스토리지로 교체 후 이전보다 더 작은 버퍼 캐시 사이즈로 자동 설정 (기존의 58% 크기)
    • 이는, 스토리지의 교체로 전반적인 성능에 변화가 생기면서 Oracle Optimizer가 기존보다 Shared pool을 늘리고 Buffer cache를 작게 할당함으로써 Buffer cache hit율이 낮아져 DB 성능이 대체로 저하됨

     

    개선 방안

    • DB Buffer Cache 크기를 고정시킴
    • db_cache_size = 6144M 설정 권고

     

    개선 효과

    • 버퍼캐시 사이즈가 커지면서 디스크로부터 읽는 Physical Read 비율이 40~50% 감소될 것으로 예측 → 전반적인 DB 성능 향상

     

    정리

    옵티마이저는 데이터베이스 내 여러 가지 정보를 바탕으로 SQL을 가장 빠르고 효율적으로 수행할 수 있는 최적의 경로를 생성해주는 DBMS 내부의 엔진이다. 예를 들면, 자동차 내비게이션에서 교통 상황에 따라 최적의 길 안내를 해주는 네비게이션 엔진 (핵심 프로그램)과 같다.

    종류는 규칙 기반 (RBO)과 비용 기반 (CBO)이 있으며, 세션이나 인스턴스 레벨 등에서 여러 모드로 지정이 가능하다. 

     

    Oracle 10g부터, 전체 SGA 메모리 영역의 크기 설정을 위한 sga_target 파라미터를 통해, 버퍼 캐시, 공유 풀, 리두로그 버퍼와 같은 하부 영역을 자동으로 튜닝할 수 있게 되었다. 옵티마이저가 참조하는 데이터는 통계 정보이며, 테이블, 인덱스, 컬럼, 시스템 통계 등의 유형이 있다. 시스템 통계는 CPU 속도, I/O 속도, 초당 I/O 처리량 등을 바탕으로 가장 비용이 작다고 판단되는 결정을 내리게 되는데, 이것이 항상 베스트 결과로 이어지지는 않는다. 마치, 내비게이션이 언제나 가장 빠른 길을 안내해주지 못하는 것과 같다. 자주 다니는 길은 내비게이션보다 사람이 더 정확한 것처럼, 최적의 튜닝을 위해서는 튜너의 개입이 필요할 수밖에 없는 것이다.

     

    이번 경우는, 아마도 성능이 훨씬 좋은 올플래시 스토리지로 바뀌면서 옵티마이저가 버퍼캐시 사이즈는 기존보다 작아도 성능상 별 문제가 되지 않는다는 판단을 하였을 것이다. 이렇게 되면, 원래 버퍼 캐시 히트와 크게 관계가 없는, Full table scan이 많은 (디스크를 직접적으로 읽어야 하는) 배치 잡의 경우에는 성능 개선 효과가 컸을 것이나, 대부분의 OLTP 쿼리들은 올플래시 스토리지의 영향보다는 SGA의 버퍼캐시 메모리 영향을 직접적으로 받으므로, 기존보다 사이즈가 작아졌다면 성능 저하를 경험했을 수밖에 없었을 것이다. 빈도가 낮고, 주로 야간에 수행되는 배치 잡이었다면 빨리 수행되었다 한들 사용자가 인지하긴 어려운 상황이니, 성능 좋은 올플래시 스토리지의 영향을 체감하기보다는 스토리지와 관계없이 기존보다 버퍼 캐시가 줄어든 것만으로 드러나는 SQL 성능 저하 현상은 쉽게 목격할 수 밖에 없었던 것이다.

     

    db_cache_size 파라미터를 적용하기 위해서는 DB 재기동이 필요하므로, 만일 PM 작업이 잡히기 전에 성능 개선이 되는지 확인하기를 원한다면, alter system set db_cache_size=6144M; 명령을 통해 즉시 성능 향상을 체감할 수 있도록 가이드하였다.

     

     

    댓글

Designed by Tistory.