단계별로 짚어보는 성능추적, 트러블슈팅(1) - 분류

Sibeet·2022년 4월 5일
0

Troubleshooting

목록 보기
1/1

기나긴 프로젝트가 끝이 났다.
반년 넘는 시간동안 여러 일이 있었으나 개인적으로 참 부족한 반년이었다는 생각이 듬.

DB 엔지니어지만 알아야 될 부분이 너무 많았고, 문제가 될 포인트도 너무 많아서 단계별로 트러블슈팅을 하거나 검토하지 못하는 상황이 계속되어 좀 힘들었음. 문제가 나오지 않으면 남탓하는게 사람 심리인지라 싸우기도 많이 싸웠던 것 같다.

DB를 다루는 입장에서 성능포인트를 단계별로 검토하고, 리눅스 기반으로 어떤 툴을 쓰거나 어떤 포인트에서 접근하면 좋을지, 어떤 방법으로 접근하고 분석할 지 고민하는 글을 차례로 써 보고자 한다.

이 글은 단순한 Brainstorming으로 이루어져 다소 장황할 수 있을 것이다.

분류를 해 보자.

AP(App) - DB 간 연결 포인트를 주축으로 생각해서... 점검이 가능한 부분은 다음처럼 될 것 같다.

  1. AP 로직
  2. AP 서버 자원
    1) CPU
    2) Memory 점유 등
    3) AP서버의 Network 설정
    4) AP서버의 기타 커널 설정
  3. AP - DB 간 네트워크
  4. DB 서버 자원
    1) CPU
    2) Memory
    3) disk stat
    4) Process 자원(세마포어와 같은)
    5) DB서버의 커널 설정(특히, hugepage와 같은 것들)
    6) 기타 등등?
  5. Database system
    1) Query Tuning
    2) DB 시스템 자원(latch, SGA(SSA), PSA, 내부 queue 등)
    3) 가능하다면, 통계를 통한 수집 데이터
    4) Lock 등의 성능에 영향을 줄 만한 문제들(AP 로직과 같이 분석해야 될 가능성이 높다)
    5) 동기화

대략 이정도로 요약이 될 지 모르겠다.
DBA 입장에서 AP로직을 손볼 순 없으니 1,2는 거의 볼 일이 없을 것이고, 3~5까지가 DBA가 확인할 만한 요소들이 될 것 같다. 물론 AP로직도 볼 수 있으면 좋겠지..

5번은 일단 mysql으로 검토해볼 예정. 잘 모르지만~

0개의 댓글