I have an issue with a Lucee 5 server repeatedly crashing - it’s got to the
stage now where it’s going down after 2 to 3 hours.
The setup is this:
DigitalOcean droplet, 2GB RAM, 2CPUs
CentOS 7
Only running Apache and Lucee 5 (5.0.0.252), via mod_CFML
Database is hosted on a separate droplet
The server serves:
2 MuraCMS instances (each with 2 sites)
2 other low-traffic CFML (FW1) sites
Tomcat memory options:
CATALINA_OPTS=“-Xms1536m -Xmx1536m -XX:+UseConcMarkSweepGC”;
If I look at the Lucee admin, I can see the heap memory usage climbing
steadily over time. This screenshot was taken about 5 minutes before the
server crashed:
When it crashes (I’m assuming when the heap and non-heap combine to reach
100%), I see the following message in the browser:
Service Unavailable
The server is temporarily unable to service your request due to maintenance
downtime or capacity problems. Please try again later.
If I check on the server, I can see that the Lucee/Tomcat service is no
longer running. And a look at the Catalina logs shows:
Java HotSpot™ 64-Bit Server VM warning: INFO: os::commit_memory(
0x00007fbc562b0000, 65536, 1) failed; error=‘Cannot allocate memory’ (errno=
12)#
There is insufficient memory for the Java Runtime Environment to continue.
Native memory allocation (mmap) failed to map 65536 bytes for committing
reserved memory.
An error report file with more information is saved as:
/opt/lucee/tomcat/hs_err_pid27367.log
The error report file reads:
There is insufficient memory for the Java Runtime Environment to continue.
Native memory allocation (mmap) failed to map 65536 bytes for committing
reserved memory.
Possible reasons:
The system is out of physical RAM or swap space
In 32 bit mode, the process size limit was hit
Possible solutions:
Reduce memory load on the system
Increase physical memory or swap space
Check if swap backing store is full
Use 64 bit Java on a 64 bit OS
Decrease Java heap size (-Xmx/-Xms)
Decrease number of Java threads
Decrease Java thread stack sizes (-Xss)
Set larger code cache with -XX:ReservedCodeCacheSize=
This output file may be truncated or incomplete.
Out of Memory Error (os_linux.cpp:2627), pid=27367, tid=140446781527808
JRE version: Java™ SE Runtime Environment (8.0_74-b02) (build
1.8.0_74-b02)
Java VM: Java HotSpot™ 64-Bit Server VM (25.74-b02 mixed mode
linux-amd64 compressed oops)
Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try “ulimit -c unlimited” before starting Java again
--------------- T H R E A D ---------------
Current thread (0x00007fbc60108000): JavaThread “C2 CompilerThread0”
daemon [_thread_in_vm, id=27378, stack(0x00007fbc5075d000,0x00007fbc5085e000
)]
Stack: [0x00007fbc5075d000,0x00007fbc5085e000], sp=0x00007fbc5085a850,
free space=1014k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
V [libjvm.so+0xaba7ea]
I’ve installed The FusionReactor trial to try to get more insight into
what’s going on; it shows that there were approx. 135 active sessions when
it fell over - not sure what else to be looking for.
Does anyone have any ideas what might be going on here? I have other
droplets with the same basic setup which seem perfectly stable…
- Seb
