바쁜 시간에도 프로덕션 환경에서 오버 헤드 방식으로 JVM 메모리 모니터를 수행하는 방법을 생각하고 있습니다.
프로덕션 환경에 두 개의 Tomcat 앱 서버가 있고 그 뒤에로드 밸런스가 설정되어 있다고 가정하십시오. jvm 메모리 통계를 볼 수 있으면 OOM 문제가 발생할 서버로 요청 전송을 중지하도록로드 밸런스를 알릴 수 있습니다. 말이 되나요? Jconsole 또는 VisualVM은 더 많은 성능을 제공합니다.
답변:
JMX가 정답입니다 (Jolokia는 JMX 인터페이스 임).
https : //.com/questions/242958/best-tools-to-monitor-tomcat
다른 사람들은 메모리 사용량을 모니터링하는 방법에 대한 제안을 제공했습니다 ...
프로덕션 환경에 두 개의 Tomcat 앱 서버가 있고 그 뒤에로드 밸런스가 설정되어 있다고 가정하십시오. jvm 메모리 통계를 볼 수 있으면 OOM 문제가 발생할 서버로 요청 전송을 중지하도록로드 밸런스를 알릴 수 있습니다. 말이 되나요?
일종의. 그러나 반드시 문제를 해결하는 가장 좋은 방법은 아닙니다.
문제의 근원 인 오 메스로 되돌아갑니다. Tomcat과 관련하여 OOME은 다음 중 하나에 의해 발생할 수 있습니다.
문제를 해결하려면 먼저 어떤 문제가 발생했는지 확인해야합니다. 솔루션마다 문제가 다르기 때문입니다.
1) 이것이 메모리 누수인지 확인하려면 메모리 분석 도구를 사용하여 장기 메모리 사용 패턴을 검사해야합니다. 이것은 아마도 톱니 패턴을 보여줄 것입니다 ... 정상입니다. 당신이 찾아야 할 것은 시간이 지남에 따라 상승하는 "치아"의 바닥 수준입니다. 이는 수집 할 수없는 가비지를 작성하고 있음을 나타냅니다. 즉, 메모리 누수.
메모리 누수가있는 경우 가장 좋은 해결책은 코드의 어떤 부분이 책임이 있는지 파악하고 수정하는 것입니다. 로드 밸런싱을 포함한 다른 모든 것은 반창고 솔루션이며 트랙 아래로 더 나쁜 문제를 일으킬 수 있습니다.
2) 메모리 누수를 제거하면 한 번에 너무 많은 요청을 처리하고 있다는 것이 문제인지 파악해야합니다. 최선의 방법은 확실하지 않지만 이것이 문제 (또는 의심되는 경우) 인 경우 몇 가지 가능한 해결책이 있습니다.
작업자 스레드 수를 줄이려면 Tomcat 서버 구성을 조정하십시오.
요청이 I / O 바운드 인 경우, 또 다른 가능성은 최신 버전의 서블릿 스펙에서 사용 가능한 비동기 요청 처리 지원을 보는 것입니다. http://docs.oracle.com/javaee/7/tutorial/doc/ servlets012.htm . 그러나 그것은 더 많은 일이 될 것입니다.
3) 문제가 특정 요청이 너무 많은 메모리를 사용하고있는 것으로 판명되면 사전에 해당 요청을 감지하고 "처리"하는 방법을 알아 내야합니다. 이러한 요청을 감지하고 처리하는 것은 어려울 수 있으며 응용 프로그램에 대한 세부 정보 없이는 조언하기가 어렵습니다. 그러나 몇 가지 실용적인 솔루션은 다음과 같습니다.
비정상적인 요청을 힙이 큰 다른 서버로 전달합니다. OOME이 "정상"요청을 방해하지 않습니다.
힙 크기를 늘리십시오. 실제 메모리가 충분하면 더 큰 힙으로 실행하면 실제로 Tomcat 서버가 더 효율적으로 만들어지고 OOME을 피할 수 있습니다.
요약하면, OOME을 피하기 위해로드 밸런스를 시도하는 대신 OOME 을 얻는 이유 를 파악하고 OOME의 원인을 직접 처리하려고합니다.