본문 바로가기
[AWS]/MEGA-SAM-FM

DISK I/O 병목현상 해결방법 아시나요???

by SAMSUNG CLOUD-OKY 2021. 11. 22.
반응형

 

메일서비스를 운영중인 서버가 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을 사용하진 않아서요.

 

 

 

반응형

댓글