AppDynamics으로 프로덕션 시스템을 모니터링 중이며 시스템이 크롤링 속도가 느려지고 거의 멈추었습니다. AppDynamics는이 이벤트 직전에 몇 분 동안 모든 GC 활동 (마이너 및 메이저 모두)을 보여주었습니다 ... 그리고 나서 다시 살아납니다.OS에서 Java 프로세스가 가비지 수집을 중지 할 수 있습니까?
시스템에 극히 낮은 부하가 걸리는 기간 동안에도 우리는 여전히 GC 작업을 수행하는 JVM을 볼 수 있습니다. 우리는 결코 완전히 평탄 해졌고 0으로 떨어졌습니다.
또한 네트워크 입출력은 GC/메모리 플랫 라인과 같은 시간대에 플랫 라인 처리됩니다.
그래서 묻습니다 : 시스템 수준에서 무언가 JVM이 정지되거나 가비지 수집이 정지/정지 할 수 있습니까? 이것은 CentOS 컴퓨터에 있습니다.
OS에서 스와핑을 사용할 수 있습니까?
스와핑이 활성화 된 운영 체제의 모든 RAM을 가득 채우면 Java에 큰 문제가 있음을 알았습니다. 실제로 Windows 시스템을 devistate하여 효율적으로 잠그고 재부팅합니다.
내 이론이있다.
처음에는 시스템에 많은 영향을 미치지 않지만 많은 메모리가 필요한 응용 프로그램을 실행하려고하면 시간이 오래 걸리고 시스템이 계속 저하됩니다.
여러 대용량 VM은 이러한 상황을 악화시킬 수 있습니다. 3 대 또는 4 대 거대한 VM을 실행하면 시스템이 60-70 %의 RAM 사용량을 초과 할 때 이제는 시즈닝을 시작합니다.
이것은 추측이지만 테스트를 한 후에 본 행동을 설명합니다.
효과는 모든 스와핑이 gc를 "방지"하는 것으로 보입니다. 보다 정확하게 OS가 GC 시간 스와핑의 대부분을 소비하므로 GC 중에 아무 것도하지 않는 것처럼 보입니다.
수정 사항 - -Xmx를 더 낮은 값으로 설정하면 스와핑을 피하기에 충분한 공간이 확보 될 때까지 놓으십시오. 이것은 문제를 해결하지 못하면 항상 내 문제를 해결했습니다. 문제의 원인에 대해 잘못된 것입니다.
OS가 정확히 어떻게 프로세스에서 메모리를 요청할 수 있는가? – user93353
OS가 낮은 메모리 상태를 나타낼 수 있다고 생각하지만 참조를 찾을 수 없습니다.나는 틀릴 수도 있지만 그 효과는 설명 된 바와 같다. JAVA 앱이 대부분의 RAM을 차지한다면 얼마나 많은 스왑을 사용할 수 있느냐에 상관없이 램이 다 떨어지면 시스템은 멈춘다. 나는 리눅스에서 이것을 보았지만 윈도우에서는 훨씬 더 발음했다. -Xmx를 잘못 설정했을 때 램이 한계에 도달했을 때 컴퓨터를 재부팅해야했습니다. 또한 운영 체제가 시간을 모두 소비하기 때문에이 시간 동안 GC가 멈춘 것처럼 보입니다 (TicketMonster가 설명하는대로입니다). –
이 신호는 어떻습니까? http://msdn.microsoft.com/en-us/library/windows/desktop/aa366541(v=vs.85).aspx Java가 이에 대응하면, 필자가 설명한대로 동작을 설명 할 것입니다. –
자세한 내용없이 문제의 정확한 원인을 찾기가 정말 어렵습니다.
질문에 대답하려고 시도 할 수 있습니다.
OS가 가비지 수집을 차단할 수 있습니까?
OS가 스레드 가비지 컬렉터를 차단하고 다른 스레드가 실행되는 경우는 거의 없습니다. 그런 식으로 조사하면 안됩니다.
OS가 JVM을 차단할 수 있습니까?
예, perflecty가 할 수 있고 그렇게 많이하지만, 프로세스가 모두 동시에 실행되고 있다고 생각하는 것보다 훨씬 빠릅니다.
jvm은 OS의 통제하에있는 다른 것과 그의 프로세스와 같은 프로세스입니다. 응용 프로그램이 중단 될 때 응용 프로그램이 사용하는 CPU를 확인해야합니다 (jvm이 아닌 서버에서 모니터링). 매우 낮은 경우, 내가 (하지만 더있다)이 원인을 참조하십시오
이론상 예, 가능합니다. 그러나 연습해야합니다.
대부분의 Java 가상 시스템에서 응용 프로그램 스레드 만 실행중인 스레드가 아닙니다. 응용 프로그램 스레드 외에도 컴파일 스레드, 파이널 라이저 스레드, 가비지 수집 스레드 등이 있습니다. CPU 코어를 이러한 스레드에 할당하고 시스템에서 실행중인 다른 프로그램의 다른 스레드를 할당하는 결정은 많은 스레드 (스레드 우선 순위, 마지막 실행 시간 등)를 기반으로하며 모든 스레드에 공평하게 적용됩니다. 따라서 실제로 시스템의 쓰레드는 부당하게 오랜 시간 동안 CPU 할당을 기다리지 않아야하며 운영 체제는 무제한의 시간 동안 아무 스레드도 차단해서는 안됩니다.
가비지 콜렉션 스레드 (및 기타 VM 스레드)가 수행해야하는 최소한의 활동이 있습니다. 가비지 수집이 필요한지를 주기적으로 확인해야합니다. 응용 프로그램 스레드가 모두 일시 중단 된 경우에도 JIT 컴파일러 스레드 나 종료 기 스레드와 같은 다른 VM 스레드가있을 수 있으므로 작업을 수행하므로 개체를 할당하고 가비지 수집을 트리거합니다.특히 Java에서 VM 스레드를 구현하고 C/C++에서는 구현하지 않는 메타 원형 JVM의 경우에 특히 그렇습니다.
또한 대부분의 현대 JVM은 세대 별 가비지 수집기 (힙을 별도의 공간으로 분할하고 힙의 다른 부분에 다른 연령대의 객체를 넣는 가비지 수집기)를 사용합니다. 이는 객체가 오래되고 오래되면 필요하다는 것을 의미합니다. 다른 오래된 공간으로 옮길 수 있습니다. 따라서 객체를 수집 할 필요가없는 경우에도 세대 별 가비지 수집기가 객체를 한 공간에서 다른 공간으로 이동할 수 있습니다.
물론 각 가비지 컬렉터의 세부 사항은 JVM에서 JVM으로 다릅니다. 부상에 염분을 더 많이 넣기 위해 일부 JVM은 두 가지 유형 이상의 가비지 컬렉터를 지원합니다. 그러나 유휴 응용 프로그램에서 최소한의 가비지 수집 활동을 보는 것은 놀라운 일이 아닙니다.
_ "크롤링 속도가 느려지고 거의 동결됩니다."_ 메모리 누수가 있습니까? – phil
그래, 나는 그런 식으로 들리 겠지만 시간이 지남에 따라 사용 가능한 메모리가 줄어든다는 것을 알 수있다. 확실히 좋은 생각. –
Statement 객체가 절대로 닫히지 않고 잠시 후에 힙을 채 웠기 때문에 이전에 설명한 것과 같은 것을 보았습니다. VisualVM 또는 원하는 도구를 사용하여 대부분의 메모리를 사용하고 있는지 확인하고 계속 증가하는지 확인하십시오. – phil