Hi All,
We have deployed the ofbiz with tomcat on VPS server. It is creating too many dummy sessions and consuming loot of memory. Could you please help in this. What might be the reason? How can we customize the application to reduce memory consumption? -- With regards, S K Pradeep kumar |
Are these http sessions or database connections ?
If former, you could try to set lower timeouts. Look at web.xml per component. see session-timeout. Logout i believe ends session so not sure why your session would increase under standard use. Is this in a load test environment ? If latter, you could change entityengine.xml to configure database pool. Harmeet ----- Original Message ----- From: "S K Pradeep Kumar" <[hidden email]> To: [hidden email] Sent: Saturday, July 25, 2009 5:21:49 AM GMT -05:00 US/Canada Eastern Subject: Too many session are creating in the server. Hi All, We have deployed the ofbiz with tomcat on VPS server. It is creating too many dummy sessions and consuming loot of memory. Could you please help in this. What might be the reason? How can we customize the application to reduce memory consumption? -- With regards, S K Pradeep kumar |
In reply to this post by skpradeepkumar
Operating a Java Server on a VPS requires some tweaking. First of all
you should check the current memory consumption in your scenario using, for example, jconsole (which is part of the JDK since 1.5). In order to connect to a running jconsole instance, you should some JMX system properties, e.g. -Dcom.sun.management.config.file=management.properties and put a management.properties file in your ofbiz folder (next to startofbiz.sh) that looks like this: com.sun.management.jmxremote=true com.sun.management.jmxremote.port=7777 com.sun.management.jmxremote.ssl=false com.sun.management.jmxremote.authenticate=false (assuming you are using the SUN JDKs). Note: this should never be used in production as the JMX access is completely unsecured this way! With the config above, you can connect via jconsole localhost:7777 Now run your load test or simulate your scenario and check the memory data in jconsole. Trigger a few GC's. Check the various memory regions by going to the "Memory" tab or directly to MBeans --> java.lang --> MemoryPool. In my experience in particular the CodeCache pool is very much oversized and the SUN JVM allocates rather large chunks of memory here. Which is normally not a problem, but VPS's tend to have very tight virtual memory quotas (which seems really unnecessary). Anyway, in order to redruce memory consumption, you should limit heap, perm space, code cache, using the VM settings -Xms<heap>M -Xmx<heap>M -XX:ReservedCodeCacheSize=<cc>m -XX:MaxPermSize=<perm>m where <heap>,<cc>,<perm> are placeholders for your settings. While <perm> and <cc> should not change dramatically after your scenario has run (so add a little on top of your measurements), the heap size will also have to reflect user session memory (so add some more. No idea how big a session in ofbiz gets in the end). Good luck, Henning Am Samstag, den 25.07.2009, 14:51 +0530 schrieb S K Pradeep Kumar: > Hi All, > > We have deployed the ofbiz with tomcat on VPS server. > It is creating too many dummy sessions and consuming loot of memory. > Could you please help in this. > What might be the reason? > How can we customize the application to reduce memory consumption? > |
thanks <goog_1248689391523>Henning,
On Sun, Jul 26, 2009 at 9:15 PM, Henning <[hidden email]> wrote: > Operating a Java Server on a VPS requires some tweaking. First of all > you should check the current memory consumption in your scenario using, > for example, jconsole (which is part of the JDK since 1.5). In order to > connect to a running jconsole instance, you should some JMX system > properties, e.g. > > -Dcom.sun.management.config.file=management.properties > > and put a management.properties file in your ofbiz folder (next to > startofbiz.sh) that looks like this: > > com.sun.management.jmxremote=true > com.sun.management.jmxremote.port=7777 > com.sun.management.jmxremote.ssl=false > com.sun.management.jmxremote.authenticate=false > > (assuming you are using the SUN JDKs). > > Note: this should never be used in production as the JMX access is > completely unsecured this way! > > With the config above, you can connect via > > jconsole localhost:7777 > > Now run your load test or simulate your scenario and check the memory > data in jconsole. Trigger a few GC's. > > Check the various memory regions by going to the "Memory" tab or > directly to MBeans --> java.lang --> MemoryPool. > > In my experience in particular the CodeCache pool is very much oversized > and the SUN JVM allocates rather large chunks of memory here. Which is > normally not a problem, but VPS's tend to have very tight virtual memory > quotas (which seems really unnecessary). > > Anyway, in order to redruce memory consumption, you should limit heap, > perm space, code cache, using the VM settings > > -Xms<heap>M -Xmx<heap>M -XX:ReservedCodeCacheSize=<cc>m > -XX:MaxPermSize=<perm>m > > where <heap>,<cc>,<perm> are placeholders for your settings. > > While <perm> and <cc> should not change dramatically after your scenario > has run (so add a little on top of your measurements), the heap size > will also have > to reflect user session memory (so add some more. No idea how big a > session in ofbiz gets in the end). > > Good luck, > Henning > > > > Am Samstag, den 25.07.2009, 14:51 +0530 schrieb S K Pradeep Kumar: > > > Hi All, > > > > We have deployed the ofbiz with tomcat on VPS server. > > It is creating too many dummy sessions and consuming loot of memory. > > Could you please help in this. > > What might be the reason? > > How can we customize the application to reduce memory consumption? > > > -- With regards, S K Pradeep kumar |
In reply to this post by gnomie
Hi,
I have tested with the following instruction given by Henning, and compered the results with ofbiz release 4.0 and it seems that my application is working fine locally, But my problem persists online and in my online application i am having. Application is running on linux i836 With 2gb of ram And my java consumes 30 to 40 % of memory normally and mySQL consumes 7.9 % of memory. Some times the CPU usage goes upto 150 % and hangs up the server and java consumes more than 60% memory. Can anybody tell me what might be the reason.? i have compared with the same such kind of apps deployed on vps they consumes 2 to 4 % of memory for MySQL but this apps consumes 7.9% of memory. Might be it is the problem If yes please, guide so that i can work on this. Please... With regards, S K Pradeep kumar On Sun, Jul 26, 2009 at 9:15 PM, Henning <[hidden email]> wrote: > Operating a Java Server on a VPS requires some tweaking. First of all > you should check the current memory consumption in your scenario using, > for example, jconsole (which is part of the JDK since 1.5). In order to > connect to a running jconsole instance, you should some JMX system > properties, e.g. > > -Dcom.sun.management.config.file=management.properties > > and put a management.properties file in your ofbiz folder (next to > startofbiz.sh) that looks like this: > > com.sun.management.jmxremote=true > com.sun.management.jmxremote.port=7777 > com.sun.management.jmxremote.ssl=false > com.sun.management.jmxremote.authenticate=false > > (assuming you are using the SUN JDKs). > > Note: this should never be used in production as the JMX access is > completely unsecured this way! > > With the config above, you can connect via > > jconsole localhost:7777 > > Now run your load test or simulate your scenario and check the memory > data in jconsole. Trigger a few GC's. > > Check the various memory regions by going to the "Memory" tab or > directly to MBeans --> java.lang --> MemoryPool. > > In my experience in particular the CodeCache pool is very much oversized > and the SUN JVM allocates rather large chunks of memory here. Which is > normally not a problem, but VPS's tend to have very tight virtual memory > quotas (which seems really unnecessary). > > Anyway, in order to redruce memory consumption, you should limit heap, > perm space, code cache, using the VM settings > > -Xms<heap>M -Xmx<heap>M -XX:ReservedCodeCacheSize=<cc>m > -XX:MaxPermSize=<perm>m > > where <heap>,<cc>,<perm> are placeholders for your settings. > > While <perm> and <cc> should not change dramatically after your scenario > has run (so add a little on top of your measurements), the heap size > will also have > to reflect user session memory (so add some more. No idea how big a > session in ofbiz gets in the end). > > Good luck, > Henning > > > > Am Samstag, den 25.07.2009, 14:51 +0530 schrieb S K Pradeep Kumar: > > > Hi All, > > > > We have deployed the ofbiz with tomcat on VPS server. > > It is creating too many dummy sessions and consuming loot of memory. > > Could you please help in this. > > What might be the reason? > > How can we customize the application to reduce memory consumption? > > > -- With regards, S K Pradeep kumar |
The release4.0 branch has issues that have never been resolved. Please understand that each release branch represents a sub-community of the overall OFBiz community, or in other words there are more people involved with OFBiz in general than there are with a particular release branch. A lot of things, including low-level things, were improved in the two years between the release4.0 branch and the release09.04 branch. It's hard to say exactly what issue you are running into that at this point I don't think anyone involved with the development and maintenance of OFBiz would recommend using the release4.0 branch because of the issues it has (including significant connection pool problems with the old Minerva connection pool) and also because of the significant new features and better ways of doing things and more complete functionality in the release09.04 branch. -David On Jul 27, 2009, at 2:10 PM, S K Pradeep Kumar wrote: > Hi, > > I have tested with the following instruction given by Henning, and > compered the results with ofbiz release 4.0 and it seems that my > application > is working fine locally, > > But my problem persists online and in my online application i am > having. > > Application is running on linux i836 > With 2gb of ram > And > my java consumes 30 to 40 % of memory normally and mySQL consumes > 7.9 % of > memory. > Some times the CPU usage goes upto 150 % and hangs up the server and > java > consumes more than 60% memory. > > Can anybody tell me what might be the reason.? > > i have compared with the same such kind of apps deployed on vps they > consumes 2 to 4 % of memory for MySQL but this apps consumes 7.9% of > memory. > Might be it is the problem > If yes please, guide so that i can work on this. > Please... > > With regards, > S K Pradeep kumar > > > On Sun, Jul 26, 2009 at 9:15 PM, Henning <[hidden email]> > wrote: > >> Operating a Java Server on a VPS requires some tweaking. First of >> all >> you should check the current memory consumption in your scenario >> using, >> for example, jconsole (which is part of the JDK since 1.5). In >> order to >> connect to a running jconsole instance, you should some JMX system >> properties, e.g. >> >> -Dcom.sun.management.config.file=management.properties >> >> and put a management.properties file in your ofbiz folder (next to >> startofbiz.sh) that looks like this: >> >> com.sun.management.jmxremote=true >> com.sun.management.jmxremote.port=7777 >> com.sun.management.jmxremote.ssl=false >> com.sun.management.jmxremote.authenticate=false >> >> (assuming you are using the SUN JDKs). >> >> Note: this should never be used in production as the JMX access is >> completely unsecured this way! >> >> With the config above, you can connect via >> >> jconsole localhost:7777 >> >> Now run your load test or simulate your scenario and check the memory >> data in jconsole. Trigger a few GC's. >> >> Check the various memory regions by going to the "Memory" tab or >> directly to MBeans --> java.lang --> MemoryPool. >> >> In my experience in particular the CodeCache pool is very much >> oversized >> and the SUN JVM allocates rather large chunks of memory here. Which >> is >> normally not a problem, but VPS's tend to have very tight virtual >> memory >> quotas (which seems really unnecessary). >> >> Anyway, in order to redruce memory consumption, you should limit >> heap, >> perm space, code cache, using the VM settings >> >> -Xms<heap>M -Xmx<heap>M -XX:ReservedCodeCacheSize=<cc>m >> -XX:MaxPermSize=<perm>m >> >> where <heap>,<cc>,<perm> are placeholders for your settings. >> >> While <perm> and <cc> should not change dramatically after your >> scenario >> has run (so add a little on top of your measurements), the heap size >> will also have >> to reflect user session memory (so add some more. No idea how big a >> session in ofbiz gets in the end). >> >> Good luck, >> Henning >> >> >> >> Am Samstag, den 25.07.2009, 14:51 +0530 schrieb S K Pradeep Kumar: >> >>> Hi All, >>> >>> We have deployed the ofbiz with tomcat on VPS server. >>> It is creating too many dummy sessions and consuming loot of >>> memory. >>> Could you please help in this. >>> What might be the reason? >>> How can we customize the application to reduce memory consumption? >>> >> > > > > -- > With regards, > S K Pradeep kumar |
Hi,
But i have compered my application with the other similar applications runinng on the server having similar configuration but those apps are running fine the issue is only with this apps. i.e. www.tribu.co.uk With regards, S K Pradeep kumar On Tue, Jul 28, 2009 at 1:59 AM, David E Jones <[hidden email]> wrote: > > The release4.0 branch has issues that have never been resolved. Please > understand that each release branch represents a sub-community of the > overall OFBiz community, or in other words there are more people involved > with OFBiz in general than there are with a particular release branch. A lot > of things, including low-level things, were improved in the two years > between the release4.0 branch and the release09.04 branch. > > It's hard to say exactly what issue you are running into that at this point > I don't think anyone involved with the development and maintenance of OFBiz > would recommend using the release4.0 branch because of the issues it has > (including significant connection pool problems with the old Minerva > connection pool) and also because of the significant new features and better > ways of doing things and more complete functionality in the release09.04 > branch. > > -David > > > > On Jul 27, 2009, at 2:10 PM, S K Pradeep Kumar wrote: > > Hi, >> >> I have tested with the following instruction given by Henning, and >> compered the results with ofbiz release 4.0 and it seems that my >> application >> is working fine locally, >> >> But my problem persists online and in my online application i am having. >> >> Application is running on linux i836 >> With 2gb of ram >> And >> my java consumes 30 to 40 % of memory normally and mySQL consumes 7.9 % of >> memory. >> Some times the CPU usage goes upto 150 % and hangs up the server and java >> consumes more than 60% memory. >> >> Can anybody tell me what might be the reason.? >> >> i have compared with the same such kind of apps deployed on vps they >> consumes 2 to 4 % of memory for MySQL but this apps consumes 7.9% of >> memory. >> Might be it is the problem >> If yes please, guide so that i can work on this. >> Please... >> >> With regards, >> S K Pradeep kumar >> >> >> On Sun, Jul 26, 2009 at 9:15 PM, Henning <[hidden email]> wrote: >> >> Operating a Java Server on a VPS requires some tweaking. First of all >>> you should check the current memory consumption in your scenario using, >>> for example, jconsole (which is part of the JDK since 1.5). In order to >>> connect to a running jconsole instance, you should some JMX system >>> properties, e.g. >>> >>> -Dcom.sun.management.config.file=management.properties >>> >>> and put a management.properties file in your ofbiz folder (next to >>> startofbiz.sh) that looks like this: >>> >>> com.sun.management.jmxremote=true >>> com.sun.management.jmxremote.port=7777 >>> com.sun.management.jmxremote.ssl=false >>> com.sun.management.jmxremote.authenticate=false >>> >>> (assuming you are using the SUN JDKs). >>> >>> Note: this should never be used in production as the JMX access is >>> completely unsecured this way! >>> >>> With the config above, you can connect via >>> >>> jconsole localhost:7777 >>> >>> Now run your load test or simulate your scenario and check the memory >>> data in jconsole. Trigger a few GC's. >>> >>> Check the various memory regions by going to the "Memory" tab or >>> directly to MBeans --> java.lang --> MemoryPool. >>> >>> In my experience in particular the CodeCache pool is very much oversized >>> and the SUN JVM allocates rather large chunks of memory here. Which is >>> normally not a problem, but VPS's tend to have very tight virtual memory >>> quotas (which seems really unnecessary). >>> >>> Anyway, in order to redruce memory consumption, you should limit heap, >>> perm space, code cache, using the VM settings >>> >>> -Xms<heap>M -Xmx<heap>M -XX:ReservedCodeCacheSize=<cc>m >>> -XX:MaxPermSize=<perm>m >>> >>> where <heap>,<cc>,<perm> are placeholders for your settings. >>> >>> While <perm> and <cc> should not change dramatically after your scenario >>> has run (so add a little on top of your measurements), the heap size >>> will also have >>> to reflect user session memory (so add some more. No idea how big a >>> session in ofbiz gets in the end). >>> >>> Good luck, >>> Henning >>> >>> >>> >>> Am Samstag, den 25.07.2009, 14:51 +0530 schrieb S K Pradeep Kumar: >>> >>> Hi All, >>>> >>>> We have deployed the ofbiz with tomcat on VPS server. >>>> It is creating too many dummy sessions and consuming loot of memory. >>>> Could you please help in this. >>>> What might be the reason? >>>> How can we customize the application to reduce memory consumption? >>>> >>>> >>> >> >> >> -- >> With regards, >> S K Pradeep kumar >> > > -- With regards, S K Pradeep kumar |
Like I said in my other message, a lot more information would be necessary to find out exactly what is causing the problem that you mention. If it is related to the database connection pool one instance can vary a lot from another if they are running different code. You may have some custom code that does not handle transactions properly. With a more recent version of OFBiz the connection pool will recover bad connections pretty well, but the old one did not. What that means is that when the bad code runs it may put a connection in a bad state and the connection pool will never recover that connection, and eventually the connection pool will be full of bad connections, and that will bring down your server. Sometimes those bad connections, or the code related to them, are related to bad threads that consume a lot of processor time. Still, that is just a guess... -David On Jul 27, 2009, at 2:44 PM, S K Pradeep Kumar wrote: > Hi, > > But i have compered my application with the other similar > applications > runinng on the server having similar configuration but those apps are > running fine the issue is only with this apps. i.e. www.tribu.co.uk > > With regards, > S K Pradeep kumar > > On Tue, Jul 28, 2009 at 1:59 AM, David E Jones <[hidden email]> wrote: > >> >> The release4.0 branch has issues that have never been resolved. >> Please >> understand that each release branch represents a sub-community of the >> overall OFBiz community, or in other words there are more people >> involved >> with OFBiz in general than there are with a particular release >> branch. A lot >> of things, including low-level things, were improved in the two years >> between the release4.0 branch and the release09.04 branch. >> >> It's hard to say exactly what issue you are running into that at >> this point >> I don't think anyone involved with the development and maintenance >> of OFBiz >> would recommend using the release4.0 branch because of the issues >> it has >> (including significant connection pool problems with the old Minerva >> connection pool) and also because of the significant new features >> and better >> ways of doing things and more complete functionality in the >> release09.04 >> branch. >> >> -David >> >> >> >> On Jul 27, 2009, at 2:10 PM, S K Pradeep Kumar wrote: >> >> Hi, >>> >>> I have tested with the following instruction given by Henning, and >>> compered the results with ofbiz release 4.0 and it seems that my >>> application >>> is working fine locally, >>> >>> But my problem persists online and in my online application i am >>> having. >>> >>> Application is running on linux i836 >>> With 2gb of ram >>> And >>> my java consumes 30 to 40 % of memory normally and mySQL consumes >>> 7.9 % of >>> memory. >>> Some times the CPU usage goes upto 150 % and hangs up the server >>> and java >>> consumes more than 60% memory. >>> >>> Can anybody tell me what might be the reason.? >>> >>> i have compared with the same such kind of apps deployed on vps they >>> consumes 2 to 4 % of memory for MySQL but this apps consumes 7.9% of >>> memory. >>> Might be it is the problem >>> If yes please, guide so that i can work on this. >>> Please... >>> >>> With regards, >>> S K Pradeep kumar >>> >>> >>> On Sun, Jul 26, 2009 at 9:15 PM, Henning <[hidden email]> >>> wrote: >>> >>> Operating a Java Server on a VPS requires some tweaking. First of >>> all >>>> you should check the current memory consumption in your scenario >>>> using, >>>> for example, jconsole (which is part of the JDK since 1.5). In >>>> order to >>>> connect to a running jconsole instance, you should some JMX system >>>> properties, e.g. >>>> >>>> -Dcom.sun.management.config.file=management.properties >>>> >>>> and put a management.properties file in your ofbiz folder (next to >>>> startofbiz.sh) that looks like this: >>>> >>>> com.sun.management.jmxremote=true >>>> com.sun.management.jmxremote.port=7777 >>>> com.sun.management.jmxremote.ssl=false >>>> com.sun.management.jmxremote.authenticate=false >>>> >>>> (assuming you are using the SUN JDKs). >>>> >>>> Note: this should never be used in production as the JMX access is >>>> completely unsecured this way! >>>> >>>> With the config above, you can connect via >>>> >>>> jconsole localhost:7777 >>>> >>>> Now run your load test or simulate your scenario and check the >>>> memory >>>> data in jconsole. Trigger a few GC's. >>>> >>>> Check the various memory regions by going to the "Memory" tab or >>>> directly to MBeans --> java.lang --> MemoryPool. >>>> >>>> In my experience in particular the CodeCache pool is very much >>>> oversized >>>> and the SUN JVM allocates rather large chunks of memory here. >>>> Which is >>>> normally not a problem, but VPS's tend to have very tight virtual >>>> memory >>>> quotas (which seems really unnecessary). >>>> >>>> Anyway, in order to redruce memory consumption, you should limit >>>> heap, >>>> perm space, code cache, using the VM settings >>>> >>>> -Xms<heap>M -Xmx<heap>M -XX:ReservedCodeCacheSize=<cc>m >>>> -XX:MaxPermSize=<perm>m >>>> >>>> where <heap>,<cc>,<perm> are placeholders for your settings. >>>> >>>> While <perm> and <cc> should not change dramatically after your >>>> scenario >>>> has run (so add a little on top of your measurements), the heap >>>> size >>>> will also have >>>> to reflect user session memory (so add some more. No idea how big a >>>> session in ofbiz gets in the end). >>>> >>>> Good luck, >>>> Henning >>>> >>>> >>>> >>>> Am Samstag, den 25.07.2009, 14:51 +0530 schrieb S K Pradeep Kumar: >>>> >>>> Hi All, >>>>> >>>>> We have deployed the ofbiz with tomcat on VPS server. >>>>> It is creating too many dummy sessions and consuming loot of >>>>> memory. >>>>> Could you please help in this. >>>>> What might be the reason? >>>>> How can we customize the application to reduce memory consumption? >>>>> >>>>> >>>> >>> >>> >>> -- >>> With regards, >>> S K Pradeep kumar >>> >> >> > > > -- > With regards, > S K Pradeep kumar |
Hi David,
Thanks, Can you please tell me some better ways, how can i collect the information because i am working first time on the server issue. Here i am testing the apps on server by just killing and restarting and comparing with similar apps and using the stress tools to find memory consumption and the stress tools doesn't able to give upto 150% cpu usage... With regards, S K Pradeep kumar On Tue, Jul 28, 2009 at 2:19 AM, David E Jones <[hidden email]> wrote: > > Like I said in my other message, a lot more information would be necessary > to find out exactly what is causing the problem that you mention. > > If it is related to the database connection pool one instance can vary a > lot from another if they are running different code. You may have some > custom code that does not handle transactions properly. With a more recent > version of OFBiz the connection pool will recover bad connections pretty > well, but the old one did not. What that means is that when the bad code > runs it may put a connection in a bad state and the connection pool will > never recover that connection, and eventually the connection pool will be > full of bad connections, and that will bring down your server. Sometimes > those bad connections, or the code related to them, are related to bad > threads that consume a lot of processor time. > > Still, that is just a guess... > > -David > > > > On Jul 27, 2009, at 2:44 PM, S K Pradeep Kumar wrote: > > Hi, >> >> But i have compered my application with the other similar applications >> runinng on the server having similar configuration but those apps are >> running fine the issue is only with this apps. i.e. www.tribu.co.uk >> >> With regards, >> S K Pradeep kumar >> >> On Tue, Jul 28, 2009 at 1:59 AM, David E Jones <[hidden email]> wrote: >> >> >>> The release4.0 branch has issues that have never been resolved. Please >>> understand that each release branch represents a sub-community of the >>> overall OFBiz community, or in other words there are more people involved >>> with OFBiz in general than there are with a particular release branch. A >>> lot >>> of things, including low-level things, were improved in the two years >>> between the release4.0 branch and the release09.04 branch. >>> >>> It's hard to say exactly what issue you are running into that at this >>> point >>> I don't think anyone involved with the development and maintenance of >>> OFBiz >>> would recommend using the release4.0 branch because of the issues it has >>> (including significant connection pool problems with the old Minerva >>> connection pool) and also because of the significant new features and >>> better >>> ways of doing things and more complete functionality in the release09.04 >>> branch. >>> >>> -David >>> >>> >>> >>> On Jul 27, 2009, at 2:10 PM, S K Pradeep Kumar wrote: >>> >>> Hi, >>> >>>> >>>> I have tested with the following instruction given by Henning, and >>>> compered the results with ofbiz release 4.0 and it seems that my >>>> application >>>> is working fine locally, >>>> >>>> But my problem persists online and in my online application i am having. >>>> >>>> Application is running on linux i836 >>>> With 2gb of ram >>>> And >>>> my java consumes 30 to 40 % of memory normally and mySQL consumes 7.9 % >>>> of >>>> memory. >>>> Some times the CPU usage goes upto 150 % and hangs up the server and >>>> java >>>> consumes more than 60% memory. >>>> >>>> Can anybody tell me what might be the reason.? >>>> >>>> i have compared with the same such kind of apps deployed on vps they >>>> consumes 2 to 4 % of memory for MySQL but this apps consumes 7.9% of >>>> memory. >>>> Might be it is the problem >>>> If yes please, guide so that i can work on this. >>>> Please... >>>> >>>> With regards, >>>> S K Pradeep kumar >>>> >>>> >>>> On Sun, Jul 26, 2009 at 9:15 PM, Henning <[hidden email]> >>>> wrote: >>>> >>>> Operating a Java Server on a VPS requires some tweaking. First of all >>>> >>>>> you should check the current memory consumption in your scenario using, >>>>> for example, jconsole (which is part of the JDK since 1.5). In order to >>>>> connect to a running jconsole instance, you should some JMX system >>>>> properties, e.g. >>>>> >>>>> -Dcom.sun.management.config.file=management.properties >>>>> >>>>> and put a management.properties file in your ofbiz folder (next to >>>>> startofbiz.sh) that looks like this: >>>>> >>>>> com.sun.management.jmxremote=true >>>>> com.sun.management.jmxremote.port=7777 >>>>> com.sun.management.jmxremote.ssl=false >>>>> com.sun.management.jmxremote.authenticate=false >>>>> >>>>> (assuming you are using the SUN JDKs). >>>>> >>>>> Note: this should never be used in production as the JMX access is >>>>> completely unsecured this way! >>>>> >>>>> With the config above, you can connect via >>>>> >>>>> jconsole localhost:7777 >>>>> >>>>> Now run your load test or simulate your scenario and check the memory >>>>> data in jconsole. Trigger a few GC's. >>>>> >>>>> Check the various memory regions by going to the "Memory" tab or >>>>> directly to MBeans --> java.lang --> MemoryPool. >>>>> >>>>> In my experience in particular the CodeCache pool is very much >>>>> oversized >>>>> and the SUN JVM allocates rather large chunks of memory here. Which is >>>>> normally not a problem, but VPS's tend to have very tight virtual >>>>> memory >>>>> quotas (which seems really unnecessary). >>>>> >>>>> Anyway, in order to redruce memory consumption, you should limit heap, >>>>> perm space, code cache, using the VM settings >>>>> >>>>> -Xms<heap>M -Xmx<heap>M -XX:ReservedCodeCacheSize=<cc>m >>>>> -XX:MaxPermSize=<perm>m >>>>> >>>>> where <heap>,<cc>,<perm> are placeholders for your settings. >>>>> >>>>> While <perm> and <cc> should not change dramatically after your >>>>> scenario >>>>> has run (so add a little on top of your measurements), the heap size >>>>> will also have >>>>> to reflect user session memory (so add some more. No idea how big a >>>>> session in ofbiz gets in the end). >>>>> >>>>> Good luck, >>>>> Henning >>>>> >>>>> >>>>> >>>>> Am Samstag, den 25.07.2009, 14:51 +0530 schrieb S K Pradeep Kumar: >>>>> >>>>> Hi All, >>>>> >>>>>> >>>>>> We have deployed the ofbiz with tomcat on VPS server. >>>>>> It is creating too many dummy sessions and consuming loot of memory. >>>>>> Could you please help in this. >>>>>> What might be the reason? >>>>>> How can we customize the application to reduce memory consumption? >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> With regards, >>>> S K Pradeep kumar >>>> >>>> >>> >>> >> >> -- >> With regards, >> S K Pradeep kumar >> > > -- With regards, S K Pradeep kumar |
Free forum by Nabble | Edit this page |