구성은 웹사이트, mssql, 어플리케이션 이렇게 3개입니다.
웹으로도 어플리케이션으로도 db에 접근이 가능합니다.
헌데 현재 mssql이 메모리 점율율이 너무 높습니다. 하루에 1기가 이상 마구 치솟고 있고요 덕분에 매일 서비스 재가동으로 위기 모면중입니다.
의심가는건 어플리케이션입니다.
어플리케이션이 나중에 도입이 되었고 그 이전에는 문제가 없었기 때문에..
일단 어플리케이션 개발자는 문제가 없다는 입장입니다만은....
이 상황에서 어딘가에서 메모리 누수가 생기고 있고 메모리 환원이 잘 안되고 있는것 같습니다.
그것을 진단하고자 모니터링을 하고 싶은데..
일단 무료 적당한 툴 몇개를 돌려봤는데..
툴이 영문 버전일 경우 로그를 이해하는데 약간의 어려움이 있더군요...
이왕이면 한글이거나 직관성이 좋은 툴이었으면 좋겠습니다.
이왕이면 무료툴이면 좋겠으나 유료툴일경우 적당히 타협이 가능한정도의 툴이었으면 좋겠습니다.
접속 사용자별 메모리 사용현황 같은걸 알수 있었으면 좋겠습니다.
어플리케이션 쪽인지 웹쪽인지 알기 위해 db 접속 사용자를 다르게해볼 생각입니다.
좋은 툴 추천 좀 부탁드리겠습니다.^^
Comment 4
-
항해자™
2016.07.14 14:19
xevent 만한 모니터링 툴도 없습니다,,, -
tmon
2016.08.18 12:52
늦었지만 답변 감사합니다.^^
-
minsouk
2016.07.17 01:10
sql server 는 읽은 데이터를 다른 데이터가 메모리로 들어갈 자리가 없기 전까지는 읽은 데이터를 다시 디스크로 보내고 메모리 해지를 하지 않습니다(캐시 히트를 높일려고). 이 부분을 이해를 못하는 분이 생각보다 많습니다. 그러니 0) max 메모리를 정하지 않으면 서버 메모리의 끝까지 올라갈려고 합니다. 그걸보고 사용자는 리부팅으로 메모리를 낮게 유지 할려는 상황으로 보이구요. server 의 물리 메모리와 os 와 필수 app 이 실행될 수 있는 메모리를 남겨두고 max 메모리만 설정하면 간단히 해결될 문제로 보입니다. (sp_configure 명령어로 설정하면 됩니다.) 혹은 정말 어떤 1) 프로그램이 특정 메모리를 가득 차지 하거나, 2) 비 페이징 풀이 야금 야금 차 올라 1달이나 수일이 지나면 다운되는 경우도 있지요. 이 경우는 오히려 쉽게 정기적인 쿼리 몇 방과 Poolmon 같은걸로 잡을 수 있습니다. 질문 하신분의 경우 단순히 SQL Server 메모리가 너무 많이 차지하고 있는 0번 경우가 아닐까 생각 됩니다. (이불킥....) 그리고, xevent 가 만병 통치약은 아닙니다. 쿨럭~
그런 툴 필요없이 perfmon + dbcc memorystatus 만 보면 거의 대부분 답 나옵니다.
-
tmon
2016.08.18 12:54
늦었지만 답변 감사합니다.
바로 확인 조치 해봐야겠습니다.^^
