Азат,
On 2/15/25 4:36 PM, Усманов Азат Анварович wrote:
Hi everyone! I'm not sure if this is an appropriate place to ask, but here is
my Problem
I have an old oracle 10g server with 2 schemas/sid, moon and moonutf8. tomcat
is also installed as a webserver on the same physical server .
1-st schema moon - has oldjava app and old tomcat 7.092 with practically 1-2
people using it.
2nd schema is a production schema of the much more modern version of the same
app . Modern version of the app is hosted on different ip address with
different tomcat 9.064
so the only java processes on that old server are related to old tomcat
on the server with old oracle( with ipaddress 192.168.1.8) I received the
following message in the logs
java invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Feb 15 11:49:20 moon kernel: java cpuset=/ mems_allowed=0
Feb 15 11:49:20 moon kernel: Pid: 37306, comm: java Not tainted
3.8.13-68.2.2.el6uek.x86_64 #2
Feb 15 11:49:20 moon kernel: Call Trace:
Am I correct to assume that whatever caused the java to ask for more memory,
and oracle to be killed was related only to an old app?
In case this was confusing here is a short summary of all the software versions
server 1 (ip address 192.168.1.8)
java version 8.333
tomcat version 7.0.92
App name: Pres
oracle schema: moon
server 2 (ip address 192.168.1.9)
java version 8.202
tomcat version 9.0.64
app name Education
oracle schema used: moonutf8
there is no oracle installed on server 2 and both tomcats use jdbc to connect
, both server have RHEL 6 installed
Marking off-topic because this is a Linux question and not really about
Tomcat.
Yes, it looks like the kernel killed your java process for memory usage.
Linux is especially prone to this behavior because the kernel will
give-out memory to processes even if it's not actually available. Only
when the process tries to use that memory does the kernel have to
make-good on those offers... and ends up having to kill a process.
There are a few ways to mitigate this, but the best way would be to
ensure that your heap is sized appropriately and you aren't leaking
either heap memory (unbounded caches, for example) or native memory
(e.g. leaky native library). The ZIP library leak comes to mind, here,
as a potential issue.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
