메일서비스를 운영중인 서버가 i/o 병목현상이 일어나고 있습니다.
서버가 8코어라서 i/o wait 값이 12.5%인데
top 명령어로 확인하였을때, wa값이 20%이상으로 치솟고 있습니다.
병목현상이 맞죠??
혹시 해결방법 아시나요??
오늘 아침부터 갑자기 발생했고, 이거때문에 메일이 접속이 제대로 안되고있어요 ㅠ
메일서비스를 운영중인 서버가 i/o 병목현상이 일어나고 있습니다.
서버가 8코어라서 i/o wait 값이 12.5%인데
top 명령어로 확인하였을때, wa값이 20%이상으로 치솟고 있습니다.
병목현상이 맞죠??
혹시 해결방법 아시나요??
오늘 아침부터 갑자기 발생했고, 이거때문에 메일이 접속이 제대로 안되고있어요 ㅠ
7개의 답변이 있습니다.
음. 문제를 봤을때는 디스크 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 이하(대충 정함)등으로 설정하여 대용량일 경우 링크를 태워 보낼 수 있도록 설정해 주는게 좋습니다. 어쨋든 대용량도 메일 서버의 리소스를 쓰는 주요 원인입니다.
이처럼 메일 서버의 문제를 먼저 파악해보시는게 어떠실지 하는 생각으로 적어봅니다.
스토리지에 캐쉬를 강화 해보세요.
SSD 로 바꾸거나, 캐쉬 를 늘리거나, SSD를 추가해서 캐쉬로 사용 하거나... 엄청 좋아질 것 같아요.
disk i/o는 top 보다는
vmstat이나 sar 같은 명령을 사용하는게 좀 더 정확한 정보를 얻을 수 있어요~
wansoo | 4년 이상 전
top에서 wa가 wait군요...
wait가 높으면 disk 병목일 가능성이 있다..
오늘 하나 배워가네요...
병목이 맞는거 같구요~~어떤 쿼리가 병목을 일으키는지 찾아야 할듯하네요
메일서버는 매주 월요일은 병목 현상이 나타납니다.
주말을 통해 내부 메일 확인자와 그리고 (gmail , outlook)으로 땡겨 가는 사용자도 있겠지요?
ex) CPU core* 8ea라면 현 시스템의 wa값 병목 한계는 (1/8)* 100 =12.5%
그건 특정 서비스에 대한 부분인듯 하구요 전체 서비스로 병목 현상을 확인하는게 맞습니다.
부산갈매기 | 4년 이상 전