우리는 jar 파일을로드하고 통계 모델을 실행할 수있는 플랫폼을 구성하고 있습니다. 현재 직면 한 문제는 일부 모델이 너무 커서 메모리 힙이 쌓이는 Google 플랫폼에 맞지 않을 수 있다는 것입니다. 나는 이것에 대한 연구가 있었지만 더 이상 찾을 수 없다는 것을 알고 있습니다. 본질적으로, 어떻게 Google 애플 리케이션 엔진이 어떻게합니까? 디스크 기반 힙 공간에 대해 들어 본 사람이 있습니까?힙 공간 문제에 대한 연구가 있습니까?
실제 메모리, 프로세서 아키텍처, JVM 및 OS의 제한 조건을 고려할 때 실제로 힙을 확장 한 것으로 가정합니다.
그 외에는 디스크 기반 힙 공간을 구현할 수있는 JVM이 없다는 답변이 있습니다. 그러나 그것은 완전히 우스꽝스러운 생각이 아닙니다. 한때 학계의 공동체가 있었는데 (대부분) 객체가 메모리와 영구 저장소간에 투명하게 마이그레이션되는 "직교성 지속성"문제에 대해 작업했습니다. 불행히도이 기술을 어렵게 만드는 근본적인 문제가있었습니다. 예를 들어, 영구 저장소를 가비지 수집하고, 멀티 스레드 응용 프로그램과 논리적으로 일관성있는 검사 점을 얻고 코드 변경을 처리합니다. 어쨌든, 연구 결과는 조용해졌습니다.
그다지 나쁘다. 우리가 이전에 찾은 연구 논문이 있었지만 지금은 찾을 수 없다는 것을 기억합니다. 나는 이것이 막 다른 골목이라고 생각한다. – critium
명령 줄 스위치를 사용하여 힙 공간을 늘릴 수 있습니다 (일반적으로 최대 2GB).
충분하지 않다면 앱의 메모리 사용을 신중하게 조정해야합니다. 디자인에 관한 더 많은 정보가 필요합니다.
디스크 기반 힙 공간은 흔히 가상 메모리라고하며, 디스크에서부터 나에게 다시 이동하는 프로세스를 스와핑이라고합니다. 지난 30 년 동안 설계된 모든 운영 체제가이를 수행 할 수 있습니다. 힙에 대해서뿐만 아니라 스택, 프로그램 메모리 자체 등에 대해서도 작동합니다. 꽤 느림보이며, 현대 메모리 가격은 종종 불필요합니다.
당신은 첫 번째가 초기 크기이며, 두 번째는 최대 크기입니다 힙 크기를
자바 -Xms1024m -Xmx2048m
을 지정하기위한 이러한 매개 변수를 사용할 수 있습니다. 이 힙 크기를 지원하는 RAM이 없으면 OS는이 메모리 크기를 수용하기 위해 자동으로 페이지 매김/스왑을 수행합니다. 물론, 그것은 분명히 느려질 것입니다.
JVM에서 참고 모델을 이미 조정했음을 언급해야합니다. 그러나 이것은 plaform이므로 사용자가로드하는 JAR이 힙 공간을 날려 버리지는 않는다는 것을 보장 할 수는 없습니다. 그게 왜 내가 특히 GAE의 솔루션에 관심이 있는지. 나는 그들 자신의 JVM을 굴려 왔다고 생각한다.하지만 그 외에는 세부 사항이 없다. 우리의 참조 모델은 2GB의 힙을 가진 파일을 실행했지만 그 이상을 사용하여 다음 모델을 쉽게 볼 수 있습니다. – critium