I have a java application running on Linux system. Currently we are facing some issues with the application and as per the initial investigation we observe that there are some memory leakage in java application.
The application is running with Java JRE
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
I have been suggested to use jmap for memory leak. My question is, I have to move application on JDK from jre or I can just install jdk and use jmap for investigation.
You can use jmap on a JRE - JRE and JDK share the same run-time environment, the difference is just the tools supplied (having said that, I always insist on the JDK being present on our production servers :-)).
Personally, I'd recommend taking a memory dump and perusing it off-line with Eclipse's awesomely rocking Memory Analyzer Tool, though.
http://www.eclipse.org/mat/
Related
In RAD WebSphere, I want to add the some arguments to the JVM, in order to display some information about the garbage collection. I notice that this action is in the Administration Console-->Server-->Application Server-->Server1-->Java and Process Management-->Process Definition-->Java Virtual Machine-->Generic JVM Argument.
Normally in Oracle JDK, there are arguments that we can add like: -Xms1000m -Xmx1000m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:MaxNewSize=500m -XX:NewSize=500m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/home/sherpa/Sherpa/Server/log/gc.log -XX:+HeapDumpOnOutOfMemoryError.
I tried to add these arguments in it, but it seems that it doesn't work with these arguments.
So is there some specific arguments that can only be used in RAD WebSphere? What arguments can we use in RAD?
I am looking forward to your opinions!
If you're running Websphere application server, you'll be using the IBM JVM.
You can get additional information about garbage collection using the -verbose:gc option.
You can find more information about the output produced by this option on this Knowledge Center page.
RAD is just your developing environment, an IDE. You can have WebSphere Application Server runtime as test environment installed together with RAD, but it is separate server, it just happens to be already integrated in the Servers View.
So in general all rules related to WebSphere apply. WebSphere runs IBM JVM, so if you want to enable verbose gc check the WebSphere infocenter, and do not provide Oracle JVM params as they simply dont work in IBM JVM :-)
So for WebSphere you should enable it via admin console in the JVM settings page, just call it via browser, but it is available to invoke it from RAD in servers view also.
For details check:
Java virtual machine settings
Garbage Collector options - to be specified via Generic JVM options
Hello All,
how to generate heap dump from jboss-eap-6.0 ?
below link talks about JBoss AS 6.x but i am looking for jboss-eap-6.0, seems jboss-eap-6.0 doesn't JMX bean support. i know Jmap command but i am more of looking how to trigger manually from jboss-eap-6.0
http://www.jochenhebbrecht.be/site/2012-12-12/java/creating-a-java-heapdump-in-jboss-6x
Try JVisualVM. It comes with the JDK, you should see it in your bin folder next to java/javac
It has options to profile and dump a running JVM. It can connect to remote JVMs, check here on how to enable JMX port, if JBOSS doesn't have that by default.
I am attempting to send a compressed JMS message to MQ.
The JMS body is compressed along with business specific Header (key<->value pairs).
The compression is done on Windows 64 bit machine.
IBM MQ and the consumer are running in a Mainframe machine.
I am seeing exceptions thrown when the JMS is decompressed at Mainframe (by consumer).
Exception - java.util.zip.ZipException
- java.util.zip.ZipException: unknown compression method
We use java.util.zip.DeflaterOutputStream for the compression/decompression.
and we set the encosing to UTF8 during compression
I am trying to understand - if this is a platform related issue?
Since When testing the compression/decompression in windows - there is no exception.
Also there is no exception thrown when the compression is done in 64 bit Solaris and decompressed at Mainframe.
Problem seems to occur only when compression is done at Windows.
Compare the 3 different JREs (Windows, Solaris & mainframe) that you are using - maybe the Windows JRE, by default, is using a newer compress method. Hence, you may need to force it to use a compression method that is supported by the mainframe JRE. Also, are you using an Oracle or IBM JRE on Windows? I would strongly suggest that you use an IBM JRE on Windows. Time to RTM.
I'm currently looking for a VPS to deploy a Yesod site on, I was wondering what the system requirements are for running Yesod? I will be using Nginx with Warp as the system configuration.
There are no hard-and-fast rules here, but I comfortably run about 5 Yesod-powered sites with Nginx and PostgreSQL and a micro EC2 instance (micro being the instance size, not a random adjective).
I had a VPS and I had trouble with the glibc version, mainly because a lot of hosting companies are quite conservative and don't offer the latest and greatest versions of the common Linux distributions. GHC won't work with older versions of glibc, although I haven't found anywhere an exact definition of how old is too old.
So one system requirement is: a recent Linux that doesn't have an ancient version of glibc.
I currently run one yesod app on Debian Lenny on VDS, with 500MHz CPU and 196Mb RAM. I do not compile app on the VDS, instead I upload compiled binary. It only needs recent libgmp, but I put one (libgmp*.so) from my desktop to the same directory as application and run
LD_LIBRARY_PATH=. ./my-yesod-app
Our production machines are running on debian etch. Now, they finally released lenny, the day will come we need to upgrade these systems. How can I do this with minimal risk? Are there any premises, preparations of fall-back scenarios and do I need a plan B in case something goes wrong? Besides the binary packages handled by the debian installer there are a couple of compiled applications running on the machines.
Personally I wouldn't upgrade any OS on an important server. OS upgrades always have the potential for subtle bugs, whether it's Windows, Linux or anything else. Debian has got better than it used to be in this regard; dist-upgrade doesn't hose the machine nearly as often as it used to back in the day. But for production machines there is no point in risking it.
Set up new servers with a fresh OS and application deployment and swap them in as needs arise. There is no need to hurry to replace Etch companywide in one go. It will be supported with security updates for a while yet.
Having just gone through that transition for some dev boxes, I wanted to point out that you'll probably want to recompile any custom libraries that you'll be linking against. Lenny uses GCC 4.3, whereas Etch uses 4.1. The output from either compiler isn't very compatible with the other. You may need to install the gcc-4.1 package to do things like compile custom kernel modules.
If you're using 3rd party tools that have a plugin interface, you may have challenges there. I've been having troubles getting Matlab plugins (mex files) to work.
I'd suggest starting with a test system. After hammering it for a while and verifying that everything's working, switch it to be a production box.
Most people don't update production servers for exactly this reason - if it's working correctly, you wouldn't update unless you had a compelling reason.
Assuming you have a dev box built similarly to the production machine, you can simulate the update on the dev box.