This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
해결! DB D&A>> 온라인 서비스 기업을 위한 DB 운영 가이드 - 1
“내 DB 시스템에 나도 모르는 비밀이 숨겨져 있다!?”
북토피아는 국내 최대의 e-Book 서비스 업체로 온라인을 통한 고객 서비스가 가장 활발하게 이뤄지고 있다. 북토피아의 김용우 이사는
최근 임계점 이상으로 사용량이 늘거나 갑자기 DB 가 느려지는 현상이 발생함에 따라, 자사의 DB 가 가진 문제점을 전반적으로 점검할
필요성을 느꼈다. 이에 자사 DB 시스템을 전반적으로 점검 받고, 평소 3 가지 이슈사항을 해결하고자 DB D&A 의 문을 두드렸다. 약 5
시간에 걸쳐 진행된 방문 점검 결과, 악성 쿼리로 인한 디스크 병목 현상과 통계 업데이트가 미비했던 점 등을 추가로 파악할 수 있었다.
tabl e rows(K)2 Reserved(KB) Data(KB) Used(KB) I ndex(KB)customer 4, 094 2, 910, 824 918, 288 2, 682, 368 1, 764, 080 royal t i es 3, 569 1, 549, 672 615, 480 1, 364, 048 748, 568 sel l _par t 7, 460 1, 743, 976 556, 296 1, 743, 784 1, 187, 488 member 4, 090 1, 251, 384 537, 008 1, 245, 792 708, 784 i d 4, 102 543, 760 287, 280 543, 496 256, 216 bookshel f 1, 859 673, 560 270, 128 475, 160 205, 032 mai l _fl ag 2, 970 533, 120 179, 992 530, 920 350, 928 eps_work_detai l 428 130, 344 54, 344 115, 344 61, 000 crm_sel l _hi story 942 92, 992 52, 184 91, 888 39, 704 phone_downl oad_hi story1, 009 134, 496 45, 744 133, 848 88, 104
전문가: 메인 DB 는 28GB 정도 되고, 현재 로그는 한 6GB 정도 사용하고 계시고, 데이터가 큰 사이즈들이 조금 있어요. 이런 부분에
대해서는 수동 통계 업데이트가 필요한 상황입니다. 지금 현재 통계 업데이트는 어떻게 하고 계신가요?
신청자: 따로 작업하는 거는 없는 걸로 알고 있어요
전문가: 백업은? 백업만 하고 계시네요. 트랜잭션 로그 백업은?
신청자: 매일 하루에 한번
전문가: 인덱스 최적화나 통계업데이트에 대한 보정작업이 데이터베이스 유지관리계획에 포함되어 있지 않습니다. 테이블에 저장된
행수가 많아지면 많아질수록 통계 업데이트가 될 수 있는 가능성은 그만큼 적어져요. 왜냐면 통계 업데이트는 전체 테이블에 저장된
행의 20%가 변경되어야지 통계 업데이트가 일어나거든요. 그러면 1000 행이면 20%면 200 행만 바뀌어도 되지만, 100 만행이 되면 20
만행이 업데이트 돼야지 통계 업데이트가 일어나기 때문에 데이터가 커지면 커질수록 통계 업데이트가 일어날 가능성이 적어져요.
그래서 그 부분에 대해서는 계속해서 통계 업데이트를 해줄 수 있도록 교정을 해야 됩니다.
전문가: 업데이트된 행 수를 확인하기 위해서는, ‘sysindexes’라는 시스템뷰의 내용을 살펴보면 됩니다. 예를 들어, customer 테이블의
경우 전체 약 400 만 건 데이터가 있습니다. 전체 이 400 만 건 중에 업데이트 된 게 현재 12 만 건 정도 있습니다. 통계 업데이트가
자동으로 발생하려면, 80 만 행이 업데이트 되어야 합니다. 이러한 문제 때문에, 상당히 오랫동안 통계 업데이트가 되지 않을 수 있고,
이렇게 오랫동안 업데이트되지 않은 통계로 인해 잘못된 실행계획이 수립되는 등의 문제가 발생할 수 있습니다. 통계 업데이트된
날짜를 확인하기 위해서는 STAT_DATE() 함수를 사용하면 됩니다. 확인한 결과, 통계 업데이트가 작년에 수행되고 현재까지 한 번도
업데이트되지 않은 테이블도 발견됩니다. 입력 후에 업데이트가 안 되는 이력 테이블이라면 상관없지만, 자주 사용하시는 테이블
중에서도 통계 업데이트가 안 된다면 분명히 문제가 발생할 가능성이 있습니다.
//
3 회에 나누어 연재됩니다.
앞으로 2 회 성능 카운터 진단 컨텐츠가 이어집니다.
해결! DB D&A>> 온라인 서비스 기업을 위한 DB 운영 가이드 - 2
“내 DB 시스템에 나도 모르는 비밀이 숨겨져 있다!?”
요청사항
1. Lock 을 거는 SQL 문
- 간혹 lock 이 걸려서 DB 가 거의 정지되다시피 하는 경우 발생, lock 이 걸렸을 때 빠르게 문제가 되는 SQL 문을 찾아내는 노하우가
필요
2. xp_sendmail
- 매일 밤 돌아가는 배치 작업 중 전날 매출 현황 등을 xp_sendmail 시스템 프로시저를 이용해 메일로 보내주는 job 이 있는데,
네트워크에 문제가 생길 경우 xp_sendmail 이 실행되는 SPID 는 죽지도 않고 리소스만 잡아먹는 문제 발생, 네트워크 문제가 발생했을
때 xp_sendmail 이 에러를 내고 종료할 수 있게 하는 방안 필요
3. 사용하지 않는 테이블과 프로시저
- 필요할 때마다 만들다 보니 테이블 개수가 300 개 이상, 프로시저 개수는 800 개에 육박하고 있음, 더 이상 사용하지 않는 테이블이나
프로시저를 걸러 낼 수 있는 방안 필요
연재 순서
1 회 – 시스템 진단(백업 및 시스템 현황, 디스크 및 메모리 현황)
2 회 – 성능카운터 진단
3 회 – 악성 쿼리 튜닝
2 회 | 성능 카운터 진단
디스크 병목 현상과 잠금의 상관관계
전문가: 이제 시스템 전반에 대해서 살펴보기 위해서 성능 카운터들을 살펴보려고 해요. 성능카운터 로그를 11 시부터 6 시까지 수집한
결과를 분석한 내용입니다.
전문가: CPU 를 보면 평균이 21%, 최대가 45%입니다. 평균 한 20% 정도 사용하고 계세요. SQL 서버 전용 머신에서 사용하고
계시니까, 전체 CPU 사용률 중 대부분을 SQL 서버에서 사용하는 게 맞고요. 메모리와 관련해서 1.7GB 정도 SQL 서버에서 사용하고
있고, 전체적으로 안정적으로 사용되고 있지만, 중간에 악성 쿼리로 인해서 메모리 중에서 전체가 비워지게 되는 경우가 발생하고
있습니다. PAGE LIFE EXPECTANCY 평균이 118밖에 안 되요. 최소 300 이상이 되어야 되거든요. 그러면 지금 메모리가 많이 모자라단
거에요. PAGE LIFE EXPECTANCY 의 단위는 초인데, 한번 데이터가 올라오면 300초(5분) 정도는 메모리에 머무를 수 있어야
메모리에 대기가 없는 건데, 지금은 애써 데이터를 가져오면 그걸 잠깐 쓰고 다음 번에 또 새로운 쿼리가 디스크로부터 또 다른
데이터를 가져와서 그 데이터를 갖다 퍼놓고 이전 데이터 올린 것은 또 쫓아내고, 그 다음에 또 다른 첫 번째 발생했던 쿼리가 다시
실행하면 두 번째 쿼리를 밀어내는 일들이 반복되는 거에요.
전문가: 디스크와 메모리에 관해서는 이슈가 있으신 상황입니다. 배치를 보면 초당 약 81 개의 쿼리가 실행되고 있어요. 그렇게
트랜잭션이 많은 시스템은 아닌데도 불구하고, 상황이 이렇다면 문제가 있다고 판단됩니다. 한 번 체크를 해보셔야 될 거 같습니다.
전문가: 지금 살펴본 것을 가지고 그래프를 그려보면 좀 더 명확하게 알 수 있는데요. CPU 를 보면 현재 빨간색이 토탈 평균은 20%
정도가 되요. 아침 10 시부터 저녁 6 시까지 하고, 오히려 저녁시간에 더 올라가서 지금은 딱 피크타임이 언제라고는 말하기는 어려운 거
같아요. 여기서 봐야 될 건 제일 중요한 건 CPU 평균 사용률이 50% 미만으로 안정적이지만 평균이 중간에서 계속 왔다갔다 거리고
있어요 이런걸 스파이크 현상이라고 하는데 이런 스파이크 현상이 발생하는 거는 이때 마다 CPU 를 올리게 하는 악성 쿼리들이 계속
발생하는 것이죠. 이런 상황은 계속 체크를 해서 튜닝을 해야 되는 상황이라고 판단됩니다.
<CPU 사용 현황>
전문가: 다음은 메모리와 관련된 성능카운터를 살펴보겠습니다. 버퍼캐치적중률(%) 평균은 99 인데 중간에 급격하게 떨어지는 부분이
문제가 됩니다. 이런 경우는 메모리에 있던 페이지를 모두 다 밀어내고, 새로운 데이터를 디스크로부터 메모리로 업로드해야 하기
때문에, 디스크 사용량과 메모리관련 대기가 발생할 수 있어서 성능에 악영향을 줄 수 있습니다. 역시 근본적인 원인은 이러한 대량의
IO 를 발생시키는 악성쿼리에 있으며, 해당 악성쿼리를 튜닝함으로써 문제를 완화할 수 있습니다.
<메모리 사용 현황>
전문가: 디스크 관련 성능카운터 수치를 살펴보겠습니다. 평균값은 안정적일 수 있지만, 중간중간 높은 값으로 치솟는 부분이 해당
시점에는 문제가 될 수 있습니다. 현재 디스크 시스템은 악성 쿼리 때문에 계속 이슈가 있는 상황이에요. 읽기 쓰기도 마찬가지고, 그
중에서 쓰기 보다는 읽기가 더 문제가 되고 있는 상황이에요.
<디스크 병목 현황>
전문가: 다음은 잠금과 차단에 대한 대한 진단내역입니다 파란색이 잠금이에요, 그리고 배치 요청는 80 회/초로 그리 높지 않은
상황입니다. 사용량이 많이 늘거나 줄거나 이런 건 아니고, 아침 10 시부터 저녁 6 시까지는 점심시간이 조금 줄기는 하지만 상당히 높은
잠금요청이 발생하고 있습니다. 컴파일은 전체 20% 정도 일어나고 있어요. 조금 더 낮출 필요가 있을 거 같고요. 잠금으로 봤을 때는
배치랑 거의 유사하게 진행되고 있지만 배치랑 상관 없이, 배치가 비슷한데도 불구하고 올라가는 경우에는, 악성 쿼리로 인해 문제가
발생하고 있다고 판단할 수 있습니다. 여기까지 살펴보면 될 거 같고요.
<배치 요청과 잠금 요청 현황>
전문가: 사전진단과정에서 수집한 11 시부터 30분간 데이터를 분석한 자료입니다. 30분간 15 만 건 정도에 쿼리가 실행되었습니다.
초당 약 86 회의 쿼리가 실행되었고. 평균 응답시간이 22 ms 이었어요. 이를 아래와 같은 그래프로 표시해 보면 전체 쿼리 중 약 5.25%
에 해당하는 악성쿼리가 논리적 읽기 기준으로 약 전체 리소스의 80.01 %를 점유하고 있는 것을 알 수 있고, 결국, 비교적 소수인
악성쿼리를 튜닝함으로써 전체 시스템의 성능을 개선할 수 있는 상황입니다.
<요청율과 점유율>
전문가: 문제의 원인이 되는 악성쿼리를 찾기 위해, 다음과 같은 쿼리 분포도를 그릴 수 있습니다. Y축은 논리적 읽기 수를 나타내고, X
축은 쿼리의 수행시간을 의미합니다. Y축의 수치가 높은 쿼리는 대량 IO 를 발생시켜서 메모리 및 디스크 리소스를 많이 소비하는
악성쿼리를 의미하고, X축의 수치가 높은 쿼리는 IO 는 많지 않으면서도 잠금 및 차단이슈로 인해 불필요하게 쿼리수행시간이 오래
걸리는 악성쿼리를 의미합니다.
<악성 쿼리 분포도>
전문가: 각 영역에 해당하는 쿼리를 찾아보면, 다음과 같이 정리할 수 있습니다. 각 리소스별로 악성쿼리 15 위가 나타나고 중복을
제거하고 정리해 보면, 아래와 같은 쿼리가 현재 시스템 리소스의 상당부분을 사용하는 악성쿼리로 정리할 수 있습니다.
Executes Avg Duration (ms)Avg CPU (ms)Avg Reads Example Query198 1,345 1,540 33,527 select top 5 MP.mp_m_id, MP.mp_m_nick, MP.mp_point,
I sNull(RI .mr_ id,20) from ssRedbookMemberPoint MP LEFT OUTERJ OIN ssRedbookRankInfo RI ON MP.mp_point betweenRI .mr_start_point and RI .mr_end_point where MP.site_ id='스서레드북' order by mp_point desc, mp_m_nick desc