We have developed a Groovy application. Under development for starting it we use the following command line
C:\myapp>mvn grails:run-app
Without sending any request to the server one can see how the memory used by the java process in increasing and increasing. When it starts at about 100M are allocated and a couple of hours later -without doind anything- the memory goes up to 300M.
When I start the application directly
C:\myapp> grails run-app
the memory consume is somehow different, without sending any request it is somehow stabilized at 110M. Sometimes goes up, sometimes comes down.
Although 300M is not critical I would like to know if this is a memory leak or not.
Is anybody having similar behaviours?
Thanks!
This could be a memory leak in Maven, but more likely a leak in the grails:run-app command. I would suggest posting this on the Grails development mailing list.
Why does this concern you? You should only be using these commands for development, not production as you'd be deploying a war file in production. If you're simply concerned, the Grails development mailing list is definitely the place for something like this.
I doubt there's a memory leak here.
It's perfectly normal for the JVM to wait on doing a full GC until it has to. That means if you allocate more memory, your java/groovy process will happily consume it.
Most likely you have different default memory settings for Maven vs Grails. I'm not sure exactly how these properties are set in windows, but they look something like:
GRAILS_OPTS="-Xms100m -Xmx110m"
MAVEN_OPTS="-Xms100m -Xmx300m"
Related
I've read here that attaching .jar files to domino agents causes a memory leak and the solution is to add them to jvm/lib/ext and restart the jvm. However I understand that putting them in the /ext folder can cause some security issues (see comments).
Is the memory leak problem still the case in Domino 12.0?
Would using the OpenNTF Domino API solve this issue?
Are there any long-term memory leak issues in just using .jars in the /ext folder?
Thanks all.
Yes, the memory leak problem is still an issue in Domino 12.
BUT: There's a workaround. Set the following notes.ini to cache the agentloader objects and reuse them:
EnableJavaAgentCache=2
From SPR # BHUY8PRMKK:
“The Product Development Team had developed a possible fix that
mitigates the issue but the fix was of medium risk and it was decided
not to submit the fix. As an alternative they have come up with a
workaround. Set the following notes.ini, this will cache the
agentloader objects and reuse them.“
Source: https://www.eknori.de/2021-03-20/java-agents-with-imported-jar-files/
We're developing a solution which uses Ektron. As part of our solution we all have local IIS instances (localhost) and deploy to this local instance as part of the development life cycle.
The problem is that after a deployment and once dll's are replaced IIS restarts and the app pool is recycled, this means that Ektron dll's need to reload themselves.
This process takes an extended amount of time.
Is there anyway to improve the loading time of "Ektron"
To some extent, this is the nature of a large app running as a website rather than a web application. Removing the workarea from your local environment is one way to get this compile time down, though this will naturally not work depending on your workflow, for example if you are not using a separate dev DB or if you are storing the workarea in source control.
I have seen some attempts to pre-complile the workarea and keep the working code in a separate project (http://dev.ektron.com/forum.aspx?g=posts&t=10996) but this approach will only speed up your builds, not the recompilation of individual pages that will occur after a build as a result of running as a web site.
The last (and least best-practice) solution is to simply avoid making code changes that cause a recompile, like modifying app_code. Apps running as websites are perfectly happy to recompile a single page's codebehind without regenerating DLLs, which is advantageous for productivity but ultimately discourages good practices like reusing code in libraries. Keep in mind that this is terrible advice, but if you have a deadline and are staring at an ektron page loading every 30 minutes it can be useful to know.
Same problem here. I found this: http://brianpereras.blogspot.com/2013/06/ektron-85-86-workarea-is-slow-compared.html
That says that the help documentation was moved to be retrieved from an online source (documentation.ektron.com). We're running Ektron 9, and I just made this change and it seems much faster on first load (after iisreset).
The solution is to set documentation.ektron.com to 127.0.0.1 in your hosts file.
There is not, this is just how IIS works. Instead of running a local instance of Ektron it's a good idea just to point your web.config file to the database of your test database and copy the /workarea folder to your local PC. You can't edit ektron locally but you can change the data on your test server and it will show up locally.
My problem is, that I am running a webapp on Tomcat7 on a 2GB 2Core VPS and when the app crashes with heapoverflow exception Tomcat doesn't start or stop. When I try to access it via the browser it just hangs.
If I try to stop it looks like it stops but if I do it repeatedly it is supposed to throw an exception because it's already stopped, but this is not the case. Only after 15 minutes am I able to start it up again.
I know that I should solve the heapoverflow problem, but the thing is I am simply not able as the framework I am using turned out to be nod thread safe and I have to create a new instance of a memory heavy object for every request :( I tried to come round the problem by adding some basic controller which only allows certain amount of objects to be created and the rest of the request are redirected to a Sorry-page. Since it is for a UNI project and the main goal is not being able to serve hundreds of users it's not important to make the framework thread safe.
Still I need to know why Tomcat does it after it crashes. Also it would help if you would have a better idea how to limit the number of these objects being in the memory at the same time.
++++++++++
At the moment the only solution I can see is to get say 2GB of more RAM so I will be able to serve some 15-20 users at a time.
Generally after tomcat crashes with out of memory error it is in unusable state and the process has to be killed either manually or by using
catalina.sh stop -force
For a discussion on how to prevent those out of memory errors see
Dealing with "java.lang.OutOfMemoryError: PermGen space" error
Though ultimately you may need to throw more hardware at the problem.
This might also come handy:
Can I auto restart tomcat jvm on out of memory exception
What exactly happens when we do IISreset? What resources get released? We have an ASP.Net website (.net 1.1) which use Crystal reports 11. Lately, running reports are throwing several crystal report specific exceptions and then the users can't run reports anymore. Resetting IIS lets the users log back in and run the reports until it fails the next time. Knowing exactly what resources are released when IIS is reset will help us dig deeper to find the root cause. Any help?
Pretty much everything. All thread pools, asp, asp.net, shared memory, etc... will all be purged. Doing in IISReset is basically the same as going to Services->WWW Service->Restart. Also, it will affect SMTP and FTP if you are running these services as well.
To narrow your problem down slightly ( and to reduce impact ), you should try putting your website in its own App Pool. Then when it next hangs, see if restarting the app pool fixes the problem. Then you are limiting things to just one running web application, not completely taking down iis. If the problem persists and still requires an IISReset, you at least have one more datapoint to work with.
EDIT: In response to your additional comment, I would suggest you do as much logging as possible and see if the problem becomes obvious. http://learn.iis.net/page.aspx/579/advanced-logging-for-iis-70---custom-logging/
Obviously, a quick run through Event Viewer is probably a good idea.
I've read several stablity issues with modmono under high load. The root of the problem is GC and the solution is restarting modmono every n hours, and n should be decreased based on error frequency.
I'm planning to develop a heavy load site with mono (I've .net experience and a little java), and I've fears based on this issues like session interruption, http errors ...
At this starting stage of the project, should I switch to Java/tomcat or trust to mod_mono ?
Regards
Depending on how long developing your site (http://www.mono-project.com/Compacting_GC) might be ready for production. While, googleing found some complaints about stability, many were from 2006. Push comes to shove, if mono/mod_mono fail to live up to stability, you could always deploy from windows/iss.
It's a bit of a calculated risk at this point, but if you run into any issues, I'm sure the mod_mono mailing list would help sort out any issues.