메일서비스를 운영중인 서버가 i/o 병목현상이 일어나고 있습니다.
서버가 8코어라서 i/o wait 값이 12.5%인데
top 명령어로 확인하였을때, wa값이 20%이상으로 치솟고 있습니다.
병목현상이 맞죠??
혹시 해결방법 아시나요??
오늘 아침부터 갑자기 발생했고, 이거때문에 메일이 접속이 제대로 안되고있어요 ㅠ
======================
문제를 봤을때는 디스크 i/o의 문제에 초점을 맞추기보다는 갑자기 왜 i/o 가 증가했는지를 확인해보셔야 할 것 같습니다.
메일 서버를 별도로 구축하신거 같은데, 릴레이 설정이 몇으로 되어 있는지, 메일 핑퐁에 대한 deny 설정이 되어 있는지, 과도한 스팸 인입으로 메일 큐가 많이 쌓이지는 않았는지등 확인해볼 필요가 있을 것 같습니다.
- 1.메일 릴레이 설정이 none 으로 되어 있다면 타겟측 메일서버와 핑퐁할 가능성이 매우 큽니다.
- a 메일 서버와 b 메일 서버가 있다고 가정할 경우 a가 b에게 송신시 잘못된 호스트를 기재할 경우 b는 a에게 잘못왔다고 회신을 줍니다. 이때 릴레이 설정이 0 또는 none 이라면 a는 다시 b에게 정상적인 메일이라고 다시 보내고 b는 a에게 다시 반송합니다. 이게 무한적으로 핑퐁하게 될 경우 메일 서버 큐가 풀이 차게되고 이것을 처리하기 위해 disk i/o를 높게 사용할 수도 있습니다.(단순 메모리, cpu를 많이 사용할 것 같으나 disk i/o 일 수도 있다는 말입니다.)
- 2.과도한 스팸이 인입될 경우 발생할 수 있습니다.
- 과도한 스팸이 인입될 경우 메일 큐가 쌓이게되고, 이를 처리하기 위해 시스템 리소스를 사용할 가능성이 큽니다. 이럴 경우 메일 서버의 적절한 필터링등을 통해 해소가 가능합니다.
- 3.메일 서버의 대용량 첨부 사이즈 제한
- 과도한 대용량 첨부로 인하여 메일 서버의 리소스를 많이 사용한다면 문제가 발생할 수 있습니다. 이럴 경우 첨부 용량 사이즈를 150MB 이하(대충 정함)등으로 설정하여 대용량일 경우 링크를 태워 보낼 수 있도록 설정해 주는게 좋습니다. 어쨋든 대용량도 메일 서버의 리소스를 쓰는 주요 원인입니다.
이처럼 메일 서버의 문제를 먼저 파악해보시는게 어떠실지 하는 생각으로 적어봅니다.
=========================
disk i/o는 top 보다는
vmstat이나 sar 같은 명령을 사용하는게 좀 더 정확한 정보를 얻을 수 있어요~
=============================
top에서 wa가 wait군요...
wait가 높으면 disk 병목일 가능성이 있다..
====================
메일서버는 매주 월요일은 병목 현상이 나타납니다.
주말을 통해 내부 메일 확인자와 그리고 (gmail , outlook)으로 땡겨 가는 사용자도 있겠지요?
ex) CPU core* 8ea라면 현 시스템의 wa값 병목 한계는 (1/8)* 100 =12.5%
그건 특정 서비스에 대한 부분인듯 하구요 전체 서비스로 병목 현상을 확인하는게 맞습니다.
============================
확인해보니, 서버랑 연결된 스토리지의 DISK가 하나 문제있어 보여요..
스토리지 및 서버 리부팅 후에는 12.5% 아래로 유지하고 있네요.. 저희는 outlook을 사용하진 않아서요.
'[AWS] > MEGA-SAM-FM' 카테고리의 다른 글
[AWS] 리눅스 CPU Load Average의 위험 범위는? (0) | 2021.12.02 |
---|---|
[Linux 명령어 ] uptime : load average 확인 (0) | 2021.12.01 |
[AWS - 활용] Linux에서 DISK I/O 사용량 확인 (0) | 2021.11.22 |
Grafana 설치 및 Grafana를 활용한 EC2 모니터링 (0) | 2021.11.14 |
Grafana와 CloudWatch 연동 (0) | 2021.11.14 |
댓글