What does this error means ?
- Thread starter Dani
- Start date
Good day.
The memory in Java heap is allocating by application request until there's no space to allocate the requested size. In this case, GC stops JVM, removes all the objects which are not used any more, to free memory occupied, then starts JVM again and allocates the requested memory amount.
Please also read this article about garbage collection in Java.
This is not an error, it's a normal garbage collector (GC) behaviour.
The memory in Java heap is allocating by application request until there's no space to allocate the requested size. In this case, GC stops JVM, removes all the objects which are not used any more, to free memory occupied, then starts JVM again and allocates the requested memory amount.
Please also read this article about garbage collection in Java.
Dani
Member
But if I get this every 1s - it means my sever settings are not optimized ?
I've 32 GB ram, only 16GB are used.
Here is my settings:
### SERVER OPTIONS ###
# Set this property to false to disable session debug
-DsessionDebugEnabled=false
# Disable SSLv3
-Djdk.tls.client.protocols="TLSv1,TLSv1.1,TLSv1.2"
### JVM OPTIONS ###
-Xmx16G
-Xms16G
#-Xcheck:jni
# Can be a better GC setting to avoid long pauses
-XX:+UseConcMarkSweepGC -XX:NewSize=1024m
#-XX:+CMSIncrementalMode
#-XX:+UseParNewGC"
#Disable heuristic rules
-XX:+UseCMSInitiatingOccupancyOnly
#Reduce Old Gen threshold
-XX:CMSInitiatingOccupancyFraction=70
# Uncomment to fix multicast crosstalk problem when streams share multicast port
-Djava.net.preferIPv4Stack=true
# Default monitoring port is 50999. Make sure the port is closed on firewall. Use ssh tunel for the monitoring.
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.local.only=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.port=50999
-Djava.rmi.server.hostname=localhost
-XX:ErrorFile=/usr/local/FlashphonerWebCallServer/logs/error%p.log
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-Xloggc:/usr/local/FlashphonerWebCallServer/logs/gc-core-
# Use System.gc() concurrently in CMS
-XX:+ExplicitGCInvokesConcurrent
# Disable System.gc() for RMI, for 10000 hours
-Dsun.rmi.dgc.client.gcInterval=36000000000
-Dsun.rmi.dgc.server.gcInterval=36000000000
I've 32 GB ram, only 16GB are used.
Here is my settings:
### SERVER OPTIONS ###
# Set this property to false to disable session debug
-DsessionDebugEnabled=false
# Disable SSLv3
-Djdk.tls.client.protocols="TLSv1,TLSv1.1,TLSv1.2"
### JVM OPTIONS ###
-Xmx16G
-Xms16G
#-Xcheck:jni
# Can be a better GC setting to avoid long pauses
-XX:+UseConcMarkSweepGC -XX:NewSize=1024m
#-XX:+CMSIncrementalMode
#-XX:+UseParNewGC"
#Disable heuristic rules
-XX:+UseCMSInitiatingOccupancyOnly
#Reduce Old Gen threshold
-XX:CMSInitiatingOccupancyFraction=70
# Uncomment to fix multicast crosstalk problem when streams share multicast port
-Djava.net.preferIPv4Stack=true
# Default monitoring port is 50999. Make sure the port is closed on firewall. Use ssh tunel for the monitoring.
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.local.only=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.port=50999
-Djava.rmi.server.hostname=localhost
-XX:ErrorFile=/usr/local/FlashphonerWebCallServer/logs/error%p.log
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-Xloggc:/usr/local/FlashphonerWebCallServer/logs/gc-core-
# Use System.gc() concurrently in CMS
-XX:+ExplicitGCInvokesConcurrent
# Disable System.gc() for RMI, for 10000 hours
-Dsun.rmi.dgc.client.gcInterval=36000000000
-Dsun.rmi.dgc.server.gcInterval=36000000000
Your server is not optimized because old CMS collector is used. See the difference between CMS and ZGC.
docs.flashphoner.com
ZGC is latest collector recommended for production (low latency, low GC pauses).
So as an optimization, you can:
1. Install Java 14.
2. Configure ZGC.
docs.flashphoner.com
Please note. If you did something wrong, server may do not start properly.
So you have to test on a different server or be ready to a downtime.
Expected results:
1. java -version
should return java 14
2. wcs-core.properties should be formed according docs
3. GC Logs should look like ZGC logs.
Please note. ZGC ensures low pauses by higher CPU load. Therefore if you have not enough CPU, you have to stay on CMS.
Message "Allocation Failure" is normal work of CMS. Frequent messages "Concurrent Mark" and "Final Remark" say that CMS collector is overload and may need an optimization updating to ZGC.
Memory management in Java - Web Call Server 5.2 - EN - Flashphoner Documentation
ZGC is latest collector recommended for production (low latency, low GC pauses).
So as an optimization, you can:
1. Install Java 14.
2. Configure ZGC.
Memory management in Java - Web Call Server 5.2 - EN - Flashphoner Documentation
Please note. If you did something wrong, server may do not start properly.
So you have to test on a different server or be ready to a downtime.
Expected results:
1. java -version
should return java 14
2. wcs-core.properties should be formed according docs
3. GC Logs should look like ZGC logs.
Please note. ZGC ensures low pauses by higher CPU load. Therefore if you have not enough CPU, you have to stay on CMS.
Message "Allocation Failure" is normal work of CMS. Frequent messages "Concurrent Mark" and "Final Remark" say that CMS collector is overload and may need an optimization updating to ZGC.