| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
- 허리디스크
- aes
- EC2
- speed-measure-webpack-plugin
- S3
- 중고나라
- 안전결제
- AWS
- 척추관협착증
- LFI
- Malware Sample
- cve-2025-55182
- mitmproxy
- 변태는
- 내부확산
- 네이버카페
- XSS
- self-signed
- shell_gpt
- intelmac
- Frida
- jeb_mcp
- esbuild
- Sequoia
- ue4dumper
- react2shell
- 취약점
- 채팅환전사기
- 모의해킹
- 많다..
- Today
- Total
annyoung
AWS CPUUtilization 본문
우리 회사와 모회사에서 사용하는 AWS는 t3.micro 그리고 t2.medium을 사용하는 것으로 기억하는데, 가끔 가다가 cpu가 maximum을 찍어서 ssh나 웹서버가 죽는 현상이 발생했다. 사용자들이 많이 접속하지 않아 적은 스펙으로도 운영할 수 있는 그런 서비스들이라 생각했는데 인스턴스들이 자주 pending 되어버리는 현상이 발생했다.
t2나 t3 인스턴스들은 사용하지 않는 경우 CPU 크레딧을 적립하고 많이 사용되는 경우 적립된 크레딧을 가지고 CPU를 버스트하여 퍼포먼스를 끌어올릴 수 있는데, 버스트를 하고 있음에도 불구하고 뻗어버렸다.
공통적으로 알 수 있는건 CloudWatchd에서 CPUUtilization이 6이상 9까지 찍어버리는데, 이 경우 서버의 모든 프로세스가 pending되어 접속도 불가능하기 때문에 서버를 항상 재시작해줬다.
-> 이후 트러블슈팅은 불가능하다 생각해서 인스턴스 스펙이 낮은 모회사는 CloudWatch로 CPUUtilization이 임계치(>=7)를 넘어가는 경우 서버를 자동으로 재시작하도록 설정해놨다.
그렇게 시간이 지나고.. 원인을 찾으려고 노력해봤다.
MongoDB connections
우선각종 로그를 봤으나 파악이 불가능했는데, 첫 번째로 가장 의심이 드는 경우는 uwsgi/wsgi 앱에서 사용자 요청에 따라 DB 세션이 각각 생성되어 cpu를 많이 잡아먹는다 정도로 유추했으나, mongo 클라이언트로 주기적으로 확인해봤으나 세션이 무한정 생성되는 케이스는 아니였던 것으로 파악했다.
> db.serverStatus().connections
{
"current" : 9,
"available" : 51191,
"totalCreated" : 13,
"active" : 4,
"exhaustIsMaster" : 3,
"exhaustHello" : 0,
"awaitingTopologyChanges" : 3
}
주기적으로 ssh 접속해서 직접 확인해봤는데 가장 드는 의심은 메모리 사용량이였다.
A서버 Server Memory
root@ip-172-31-45-72:/home/nopsled# free -h
total used free shared buff/cache available
Mem: 914Mi 703Mi 104Mi 3.2Mi 264Mi 210Mi
Swap: 0B 0B 0B
B서버 Server Memory
root@ip-172-31-40-67:/var/www/copies-server# free -h
total used free shared buff/cache available
Mem: 1.9Gi 873Mi 78Mi 2.0Mi 1.0Gi 883Mi
스왑: 0B 0B 0B
B서버의 경우 A서버에 비해 그나마 스펙이 조금 높게 잡혀있는데, 아직까지는 메모리 사용량이 현저히 낮지만 어느 시점에 갑자기 이 메모리가 누적되기 시작하더니 가용 메모리가 3%미만으로 남아버리는 케이스가 발생했다. 그 이후 메모리가 부족하니 CPU 사용량이 높아지고 서버가 죽어버리는 케이스였다.
알고보니 wiredTiger 엔진의 cache 메모리를 좀 줄여야하는 상황인데, 당장 운영하기에는 테스트가 불가능할 것 같아서 현재는 crontab으로 주기적으로 MongoDB 서비스를 재시작함으로써 캐시를 초기화해주는 임시방편을 선택했다.
그래서 업무가 시작되기 전인 8시 50분과 점심시간이 끝나기전 12시 50분 그리고 업무가 끝난 후 18시 55분쯤 서비스를 재시작함으로써 잠시 숨을 돌릴 수 있게된 것 같다.(사실 바로 어제 주말에 작업해놔서 잘 되지 않을까 싶긴하다...)
cacheMemory를 줄이고 반영되면 이후 다시 쓰도록하겠다.
'데이터베이스' 카테고리의 다른 글
| mongodb combine two queries with aggregate (0) | 2022.01.25 |
|---|---|
| MongoDB 유저생성 및 데이터베이스 생성 (0) | 2019.01.08 |
| Install MongoDB + phpMongoDriver in Mac OSX High Sierra (0) | 2018.09.13 |
| [mongodb] how to find dictionary not null (0) | 2018.04.30 |
| mongodb not authorized? how to create database in mongodb (0) | 2018.04.18 |
