The catalog service (and each Impala daemon) starts a JVM via JNI. They host the JVM, not the other way around. You should be able to use normal Java tooling, in my experience.
On 28 August 2017 at 17:39, Chan Chor Pang <[email protected]> wrote: > I got an java out of memory error from the catalogd log > after restarted, i though i will able to use jmap to take a look on whats > going on > but the catalogd process doesnt seems like it is a java process > if catalogd is not a java process, why would a java OOM option kills the > catalogd process > > > $ tail -1 catalogd.h002.impala.log.ERROR.20170530-140731.65543 > > Picked up JAVA_TOOL_OPTIONS: -Xms34359738368 -Xmx34359738368 > -XX:OnOutOfMemoryError=/usr/lib64/cmf/service/common/../impa > la/catalogd_killparent.sh > > > $ ps -ef | grep catalogd > > impala 33469 121918 79 Aug27 ? 1-12:36:55 > /opt/cloudera/parcels/CDH-5.10.1-1.cdh5.10.1.p0.10/lib/impala/sbin-retail/catalogd > --flagfile=/var/run/cloudera-scm-agent/process/30113-impala- > CATALOGSERVER/impala-conf/catalogserver_flags > > > $ file /opt/cloudera/parcels/CDH-5.10.1-1.cdh5.10.1.p0.10/lib/impal > a/sbin-retail/catalogd > > > /opt/cloudera/parcels/CDH-5.10.1-1.cdh5.10.1.p0.10/lib/impala/sbin-retail/catalogd: > symbolic link to `impalad' > > > $ file impalad > > impalad: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), > dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped >
