Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- CloudWatch
- Pinpoint
- Kubernetes
- APM
- 정보처리기사 실기
- Spring
- AWS EKS
- 티스토리챌린지
- AI
- IntelliJ
- kotlin spring
- CKA 기출문제
- 기록으로 실력을 쌓자
- mysql 튜닝
- 정보처리기사 실기 기출문제
- kotlin
- kotlin coroutine
- Java
- Elasticsearch
- aws
- 오블완
- minikube
- Linux
- 코틀린 코루틴의 정석
- CKA
- kotlin querydsl
- 정보처리기사실기 기출문제
- 공부
- MySQL
- PETERICA
Archives
- Today
- Total
피터의 개발이야기
[DevOps] MongoDB 롱쿼리 조회하고 kill하는 방법 본문
반응형
ㅁ 개요
ㅇ API 요청에 대한 상세정보의 히스토리 관리를 위해 사용하고 있던 MongoDB에 부하가 발생하였다.
ㅇ 부하의 원인이 된 요청을 찾고 Kill하여 부하를 해소하였고, 그 과정을 정리하였다.
ㅁ 장애인지
ㅇ MongoDB가 사용하는 볼륨의 DISK I/O가 96%가 넘었다고 알람이 발생하였다.
ㅇ DISK I/O가 100%가 되었다.
ㅇ CPU 사용량을 30%미만이었고, DISK I/O만 높은 상태였다.
ㅇ 히스토리 관리를 위한 저장용으로 사용하다보니 단건에 대한 확인용으로만 설계되어 있어서
Collection당 많은 데이터가 존재하였다.
ㅇ Key값이 아닌 다른 비교조건을 넣는 경우 상당한 데이터가 조회되는 구조였다.
ㅇ 어떤 요청인지 정확히 알 수는 없지만(사실 원인파악보다 장애해결이 우선이다), 특정 쿼리로 인해 부하가 발생하고 있었다.
ㅇ 부하를 발생시키는 원인을 찾아야만 했다.
ㅁ MongoDB 프로세스 확인(롱쿼리 확인)
db.currentOp({"secs_running": {$gte: 3}})
ㅇ 3초 이상의 롱쿼리를 조회 명령문이다.
ㅇ 위의 이미지는 inprog의 샘플을 보여주는 것이다.
ㅇ 장애 발생 시에는 급해서 캡쳐를 할 수 없었다.
ㅇ secs_running 타임을 확인하고 오래도니 쿼리인 경우 opid를 복사해 둔다.
ㅁ MongoDB 프로세스(opid) kill
db.killOp(807992146)
ㅇ 복사해둔 opid를 붙여서 kill 처리를 한다.
ㅇ 이후 부하가 되었던 DISK I/O는 정상화 되었다.
ㅇ 다행이었다.
반응형
'DevOps' 카테고리의 다른 글
[DevOps 개념정리] 사일로(Silo Effect)란? (0) | 2022.08.14 |
---|---|
DevOps 로드맵 (0) | 2022.06.28 |
[Rocket.Chat] Incoming WebHook Script (0) | 2022.06.10 |
[Rocket.Chat] Rocket.Chat 설치하기 (4) | 2022.06.07 |
[Redis] Redis scan의 performance 테스트 (0) | 2022.05.28 |
Comments