스프링 부트 메모리 사용량을 줄이는 방법

스프링 부트 메모리 사용량을 줄이는 방법

저는 스프링 부츠를 사용하여 클라이언트 애플리케이션을 개발하고 있습니다.(완전 실행 가능 jar를 사용하여) 스프링 부트 어플리케이션을 실행할 때 메모리 사용량은 x64 서버에서 약 190M, x86 서버에서 약 110M입니다.

JVM 옵션은 (-Xmx64M -XX:MaxPermSize=64M -server)입니다.x64 서버에서 메모리 사용량이 많은 이유는 무엇입니까?메모리 사용량을 1억5000만 미만으로 줄이는 방법

감사해요.

게임 시작은 조금 늦었지만 Docker의 컨테이너형 스프링 부츠 애플리케이션으로 같은 문제를 겪었습니다.싱글 컨트롤러와 임베디드 Tomcat을 탑재한 가장 심플한 Spring Boot 어플리케이션에서는 최소 7200만 개의 메모리만 사용할 수 있습니다.Spring Data REST, Spring Security 및 몇 개의 JPA 운영 주체만 포함하면 최소 2억~300M의 용량을 확보할 수 있습니다.다음의 JVM 옵션을 사용하면, 심플한 Spring Boot 앱을 합계 약 72M으로 줄일 수 있습니다.

와 함께 -XX:+UseSerialGC그러면 전용 GC 스레드 대신 힙 메모리를 할당하는 스레드와 함께 가비지 컬렉션이 인라인으로 수행됩니다.

와 함께 -Xss512k그러면 각 스레드 스택 메모리가 기본 1MB가 아닌 512KB로 제한됩니다.

와 함께 -XX:MaxRAM=72m이렇게 하면 힙 및 비 힙 관리 메모리에 대한 JVM 계산이 이 값의 제한 범위 내로 제한됩니다.

위의 JVM 옵션과 더불어 다음 속성을 사용할 수도 있습니다.application.properties파일:

server.tomcat.max-threads = 1그러면 HTTP 요청 핸들러 스레드 수가 1로 제한됩니다(기본값은 200).

---

의 예를 다음에 나타냅니다.docker stats위의 제한과 도커를 사용하여 매우 간단한 Spring Boot 어플리케이션을 실행합니다.-m 72m논쟁.이 값보다 작은 값을 줄이면 앱을 시작할 수 없습니다.

83ccc9b2156d: Mem Usage: 70.36MiB / 72MiB | Mem Percentage: 97.72%

여기서 종료 시 모든 네이티브 및 자바 힙메모리의 내역을 확인할 수 있습니다.

Native Memory Tracking:

Total: reserved=1398681KB, committed=112996KB
-                 Java Heap (reserved=36864KB, committed=36260KB)
                            (mmap: reserved=36864KB, committed=36260KB) 

-                     Class (reserved=1086709KB, committed=43381KB)
                            (classes #7548)
                            (  instance classes #7049, array classes #499)
                            (malloc=1269KB #19354) 
                            (mmap: reserved=1085440KB, committed=42112KB) 
                            (  Metadata:   )
                            (    reserved=36864KB, committed=36864KB)
                            (    used=36161KB)
                            (    free=703KB)
                            (    waste=0KB =0.00%)
                            (  Class space:)
                            (    reserved=1048576KB, committed=5248KB)
                            (    used=4801KB)
                            (    free=447KB)
                            (    waste=0KB =0.00%)

-                    Thread (reserved=9319KB, committed=938KB)
                            (thread #14)
                            (stack: reserved=9253KB, committed=872KB)
                            (malloc=50KB #74) 
                            (arena=16KB #26)

-                      Code (reserved=248678KB, committed=15310KB)
                            (malloc=990KB #4592) 
                            (mmap: reserved=247688KB, committed=14320KB) 

-                        GC (reserved=400KB, committed=396KB)
                            (malloc=272KB #874) 
                            (mmap: reserved=128KB, committed=124KB) 

-                  Compiler (reserved=276KB, committed=276KB)
                            (malloc=17KB #409) 
                            (arena=260KB #6)

-                  Internal (reserved=660KB, committed=660KB)
                            (malloc=620KB #1880) 
                            (mmap: reserved=40KB, committed=40KB) 

-                    Symbol (reserved=11174KB, committed=11174KB)
                            (malloc=8417KB #88784) 
                            (arena=2757KB #1)

-    Native Memory Tracking (reserved=1858KB, committed=1858KB)
                            (malloc=6KB #80) 
                            (tracking overhead=1852KB)

-               Arena Chunk (reserved=2583KB, committed=2583KB)
                            (malloc=2583KB) 

-                   Logging (reserved=4KB, committed=4KB)
                            (malloc=4KB #179) 

-                 Arguments (reserved=17KB, committed=17KB)
                            (malloc=17KB #470) 

-                    Module (reserved=137KB, committed=137KB)
                            (malloc=137KB #1616)

GC는 플레이할 여유 메모리가 많지 않기 때문에 이 셋업에서는 자주 실행되기 때문에 이 퍼포먼스를 얻을 수 있을 것으로 기대도 하지 마십시오.

검색 결과 stackoveflow에 이미 답이 있습니다.스프링 부트 메모리 소비량이 -Xmx 옵션 이상으로 증가

1. Number of http threads (Undertow starts around 50 threads per default, but you can increase / decrease via property the amount of threads needed)
2. Access to native routines (.dll, .so) via JNI
3. Static variables
4. Use of cache (memcache, ehcache, etc)
If a VM is 32 bit or 64 bit, 64 bit uses more memory to run the same application, so if you don't need a heap bigger than 1.5GB, so keep your application runnnig over 32 bit to save memory.

왜냐하면 스프링 부트는 http 서비스(Tomcat 또는 Undertow, Jetty)에 대해 기본값당 약 50 스레드를 시작하고 스레드당 1MB를 사용하기 때문입니다(64비트 jvm 기본 설정).

따라서 64비트 jvm의 메모리 사용량은 힙(64M) + Permgen(최대 64M) + 스레드 스택(1M x 50+) + 네이티브 핸들입니다.

참조:

• https://dzone.com/articles/how-to-decrease-jvm-memory-consumption-in-docker-u
• http://trustmeiamadeveloper.com/2016/03/18/where-is-my-memory-java/
• https://developers.redhat.com/blog/2017/04/04/openjdk-and-containers/

-XX를 사용할 수 있습니다.+SerialGC를 JVM 인수로 사용하여 메모리 힙을 줄이는 데 가장 적합한 시리얼 가비지 컬렉터를 지정합니다.

언급URL : https://stackoverflow.com/questions/44491257/how-to-reduce-spring-boot-memory-usage