it-swarm.com.de

wie kann ich die Speicherbelegung des Spring Boot reduzieren?

Ich benutze Spring Boot, um eine Client-Anwendung zu entwickeln. und wenn Sie eine Spring-Boot-Anwendung ausführen (unter Verwendung einer vollständig ausführbaren jar), beträgt die Speicherauslastung in x64-Server etwa 190 MB und in x86-Server 110 MB.

meine jvm-Option ist (-Xmx64M -Xms64M -XX: MaxPermSize = 64M-Server),. Wie kann der Speicherverbrauch unter 150 MB reduziert werden?

vielen Dank.

7
Hailong Li

Etwas spät zum Spiel hier, aber ich hatte das gleiche Problem mit einer containerisierten Spring Boot-Anwendung auf Docker. Das Nötigste, mit dem Sie rechnen müssen, ist bei den einfachsten Spring Boot-Anwendungen mit einem einzigen Controller und integriertem Tomcat etwa 72 Millionen Arbeitsspeicher. Wenn Sie Spring Data REST, Spring Security und einige JPA-Entitäten einwerfen, werden Sie mindestens 200M-300M erwarten. Mit den folgenden JVM-Optionen erhalten Sie eine einfache Spring Boot-App mit einer Gesamtlänge von rund 72 Millionen.

With-XX:+UseSerialGC Dies führt die Garbage Collection inline mit dem Thread durch, der den Heapspeicher anstelle eines dedizierten GC-Threads zuordnet.

With-Xss512k Dies beschränkt den Stack-Speicher aller Threads auf 512 KB anstelle der Standardkapazität von 1 MB

With-XX:MaxRAM=72m Dadurch werden die Berechnungen der JVM für den verwalteten Heap- und Nicht-Heap-Speicher auf die Grenzen dieses Werts beschränkt.

Zusätzlich zu den obigen JVM-Optionen können Sie auch die folgende Eigenschaft in Ihrer application.properties-Datei verwenden:

server.Tomcat.max-threads=5 Dadurch wird die Anzahl der HTTP-Request-Handler-Threads auf 1 begrenzt (Standardeinstellung ist 50).


Hier ein Beispiel für docker stats, das eine einfache Spring Boot-Anwendung very mit den oben angegebenen Grenzwerten und dem Andock-Argument -m 72m ausführt. Wenn ich die Werte niedriger setze, kann ich die App nicht starten.

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

Und hier sehen Sie eine Aufschlüsselung des nativen und des Java-Heap-Speichers beim Beenden.

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)

Erwarten Sie nicht, dass Sie eine anständige Leistung erzielen, da ich davon ausgehen könnte, dass der GC bei diesem Setup häufig ausgeführt wird, da er nicht über genügend freien Speicher verfügt

7
CCob

Nach der Suche habe ich festgestellt, dass sie bereits eine Antwort in stackoveflow hat . Der Speicherbedarf des Spring Boot-Speichers steigt über die Option -Xmx hinaus

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.

da Spring Boot für HTTP-Dienst (Tomcat oder Undertow, Jetty) standardmäßig rund 50 Threads startet und 1 MB pro Thread verwendet (64-Bit-Jvm-Standardeinstellung).

In 64-Bit-jvm beträgt die Speicherauslastung Heap (64M) + Permgen (max. 64M) + Threadstapel (1M x 50+) + native Handles.

verweise:

6
Hailong Li

Sie können -XX: + UseSerialGC als JVM-Argument verwenden, um den seriellen Garbage Collector anzugeben. Dies ist die beste Wahl, um den Speicherheap zu reduzieren.

1
Yassine Abainou