RE: orion 1.3.8 on linux - and Memory leaks in general
3)Leaks,leaks,leaks. Yes there are leaks in Orion. We've run into a very nasty one that no one seems to know why it happens. It's got to do with JMS. For some reason Property objects don't get cleaned up. As such, memory usage will keep on going. We are trying one way of dealing with this: usrin the -Incgc option with the JVM (incremental garbage collector). passing on some personal experiences and thoughts I've had with \ leaks in what appears to be correct java; The nature of heap managers has always allowed for perfect and correct java to fragment the heap and cause memory growth. No amount of GC will fix some dynamics if the timing of the new this() is is interleaved with that.finalize() and gc() doesn't create enough contiguous space for the next new somemore(). Java 2's smarter gc() did go along way to reducing the heap fragmentation potential, I believe and have observed. For some applications that experience intermittant leaks were the factors are load and use case interactions, the only fix is to re-think your object creation and gc()'ing. The solutions that worked for me (last hope and desparation) was the general strategy of object pooling (re-use and not destruction). I.E. most objects have a MyClass.clear() and it's ready for re-use. By reducing the amount of load on the heap, I've fixed or reduced leakage to tolerable levels... Yes it does make sense that more frequent increamental gc()ing might reduce the orion/JMS problem from my obervations too... As the previous poster said; good luck! A thought on Linux VM threading and process creation; The Linux kernel does not have the concept of a light weight thread/process (LWP) as does Solaris and win32. This means that all VM threads are mapped to Linux processes which are more effort for the Linux kernel to manage due to larger kernel data structures and scheduler effort to task switch a full task as apposed to a LWP in Solaris or win32. Until Linux addes this more efficient structure into the kernel we'll see somewhat lower perfs for java apps on Linux vs Solaris x86 or win32 on the same HW. The design of the Linux VM in no way causes the runaway tasks or task memory growth as was observed. A java Thread spinning or new yetMoreObjects() is likely caused by java program issues and not the Linux VM or linux kernel... IMHO. :) curt J2EE / EJB Architect Curt Smith [EMAIL PROTECTED] (w) 404-463-0973 (h) 404-294-6686 winmail.dat
AW: Memory leaks
We do not have any production site, yet, but from my experience with orion and EJB, the most important thing is to provide an orion-ejb-jar.xml with your application, where you specify maximum instance limits for each entity bean. Otherwise there will be only a timeout to destroy cached instances, which under heavy load may not be sufficient. This looks like: ?xml version=1.0? !DOCTYPE orion-ejb-jar PUBLIC -//Evermind//DTD Enterprise JavaBeans 1.1 runtime//EN http://www.orionserver.com/dtds/orion-ejb-jar.dtd; orion-ejb-jar enterprise-beans entity-deployment name=BeanName location=BeanName max-instances=[Number of Instances] validity-timeout=360 / /enterprise-beans /orion-ejb-jar Best performance (together with exclusive-write-access) you get with high timeouts and a sufficient number of instances to fill your RAM without swapping - only that you must set it for each bean and play around a bit to find the best values (especially when you have a lot of entity beans). Lowest memory usage you get with both low timeouts and max-instances, of course. This is no memory leak issue, but may seem as such if you don't limit the number of beans and put your system under heavy load. Other problems with memory (except for our own code ;-) did not show up yet. Good luck, Jens Stutte -Ursprüngliche Nachricht- Von: Nusairat, Joseph F. [mailto:[EMAIL PROTECTED]] Gesendet am: Donnerstag, 28. Juni 2001 21:17 An: Orion-Interest Betreff: Memory leaks I was curious ... i am about to put orion into a production enviroment within the next week. I have been writing some EJB's with it ... and some testing and configuring I was wondering how bad or good it is at memory leaks? Do u all have to restart your servers often??? Or??? any suggestions It will be on win2k boxes
RE: Memory leaks
There are issues with memory leaks and some jdbc drivers. Search the list on postgresql, for example. This is not necessarily orion, but if you are using a database with orion, the driver will be in the orion vm. If the driver chews up memory, so will orion. the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jens Stutte Sent: Friday, June 29, 2001 12:31 AM To: Orion-Interest Subject: AW: Memory leaks We do not have any production site, yet, but from my experience with orion and EJB, the most important thing is to provide an orion-ejb-jar.xml with your application, where you specify maximum instance limits for each entity bean. Otherwise there will be only a timeout to destroy cached instances, which under heavy load may not be sufficient. This looks like: ?xml version=1.0? !DOCTYPE orion-ejb-jar PUBLIC -//Evermind//DTD Enterprise JavaBeans 1.1 runtime//EN http://www.orionserver.com/dtds/orion-ejb-jar.dtd; orion-ejb-jar enterprise-beans entity-deployment name=BeanName location=BeanName max-instances=[Number of Instances] validity-timeout=360 / /enterprise-beans /orion-ejb-jar Best performance (together with exclusive-write-access) you get with high timeouts and a sufficient number of instances to fill your RAM without swapping - only that you must set it for each bean and play around a bit to find the best values (especially when you have a lot of entity beans). Lowest memory usage you get with both low timeouts and max-instances, of course. This is no memory leak issue, but may seem as such if you don't limit the number of beans and put your system under heavy load. Other problems with memory (except for our own code ;-) did not show up yet. Good luck, Jens Stutte -Ursprüngliche Nachricht- Von: Nusairat, Joseph F. [mailto:[EMAIL PROTECTED]] Gesendet am: Donnerstag, 28. Juni 2001 21:17 An: Orion-Interest Betreff: Memory leaks I was curious ... i am about to put orion into a production enviroment within the next week. I have been writing some EJB's with it ... and some testing and configuring I was wondering how bad or good it is at memory leaks? Do u all have to restart your servers often??? Or??? any suggestions It will be on win2k boxes
Memory leaks
Title: Memory leaks I was curious ... i am about to put orion into a production enviroment within the next week. I have been writing some EJB's with it ... and some testing and configuring I was wondering how bad or good it is at memory leaks? Do u all have to restart your servers often??? Or??? any suggestions It will be on win2k boxes
RE: Memory leaks
I can speak from a production machine we have running on NT4 SP5 with Orion 1.3.8. We only use servlets, but we've been running since September 25, 2000. And we only rebooted once, and that was because of a ISP network outage and I thought I'd take the oppertunity to reboot NT. Of course your milage may vary depending on too many varibles to mention. -Original Message- From: Nusairat, Joseph F. [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 28, 2001 3:17 PM To: Orion-Interest Subject: Memory leaks I was curious ... i am about to put orion into a production enviroment within the next week. I have been writing some EJB's with it ... and some testing and configuring I was wondering how bad or good it is at memory leaks? Do u all have to restart your servers often??? Or??? any suggestions It will be on win2k boxes
