메모리 성능
성능 문제는 일반적으로 ThingWorx 솔루션의 전체 메모리 사용률에서 확인할 수 있습니다. 솔루션에서 Java 메모리 힙을 적극적으로 사용하고 계속해서 큰 메모리 객체를 만들고 무시하는 경우 이 시스템의 메모리 메트릭에 일부 불량 성능 지표를 볼 수 있습니다. Java 가비지 수집의 빈도와 기간은 시스템의 전체 응답성에서 중요한 역할을 합니다. 지속적인 가비지 수집 루프가 있는 경우 솔루션은 메모리에 대해 스트레스를 가지며, 이로 인해 전체 ThingWorx Platform이 완전히 응답하지 않게 될 수 있습니다.
시간 경과에 따른 Java 메모리 사용 및 가비지 수집을 모니터링하려면 GC 로깅을 사용하는 것이 좋습니다. VisualVM 같은 도구에도 메모리 사용률 정보가 표시됩니다. 그러나 전체 GC 루프로 인해 JVM이 응답하지 않는 경우 이러한 외부 솔루션에서 메모리 문제를 표시하기 위해 데이터를 검색하지 못할 수 있습니다.
운영 체제 수준에서 메모리를 모니터링할 때 ThingWorx 솔루션에 할당된 메모리를 사용하는 방법에 대한 정보를 제공하지 않습니다. 모니터링 도구는 Java가 운영 체제에서 요청한 메모리의 양을 검색하지만 Java에서 이 메모리를 사용하는 방법을 표시하진 않습니다. 대부분의 성능 문제는 운영 체제 메모리 할당이 아니라 Java 힙 공간의 내부 메모리 사용으로 인해 발생합니다.
Java에 할당된 전체 메모리는 런타임 시 로드되는 -Xms(최소) 및 -Xmx(최대) 매개 변수에 의해 결정됩니다. -Xms 및 -Xmx 매개 변수는 tomcat8w 구성 패널을 사용하여 Tomcat이 구성된 경우 초기 및 최대 메모리 풀 크기를 지정합니다.
시작 시 최소값 또는 최대값이 지정되지 않은 경우 시작 시 Java 프로세스에서 추론을 사용하여 이러한 양을 미리 할당합니다. 기본적으로 Java는 운영 체제에서 사용 가능한 전체 RAM 중 1/4을 할당하려고 합니다.
메모리 문제를 일으키는 작업
메모리 문제를 일으킬 수 있는 다음 작업을 모니터링해야 합니다.
• 45초 이상의 시간이 걸리는 매우 길고 자주 수행되는 전체 GC 작업 - 전체 GC는 모든 동작을 중지시키는 작업이므로 바람직하지 않습니다. JVM이 일시 중지하는 기간이 길수록 다음과 같은 메모리 문제가 발생할 가능성이 높아집니다.
◦ JVM에서 사용 가능한 메모리를 더 많이 확보하는 동안 다른 모든 활성 스레드는 중지됩니다.
◦ 전체 GC는 시간이 많이 걸리고, 때로는 몇 분 동안 솔루션이 응답하지 않을 수 있습니다.
• 루프에서 발생하는 전체 GC - 빠르게 연속적으로 발생하는 전체 GC를 전체 GC 루프라고 합니다. 다음과 같은 문제가 발생할 수 있습니다.
◦ JVM에서 추가 메모리를 정리할 수 없는 경우 루프가 무기한으로 계속될 수 있습니다.
◦ 루프가 계속되는 동안 사용자가 ThingWorx 솔루션을 사용할 수 없습니다.
• 메모리 누수 - 메모리에 점점 더 많은 수의 객체가 유지되면 솔루션에서 메모리 누수가 발생합니다. JVM에서 수행하는 가비지 수집 유형에 관계없이 이러한 객체는 정리할 수 없습니다.
◦ 시간 경과에 따른 메모리 소비량을 확인할 때 메모리 누수는 메모리 사용이 회수되지 않고 계속 늘어나기만 하는 것처럼 보입니다.
◦ 결국 서버는 설정된 상한에 상관없이 메모리가 부족하게 됩니다.