search

codyopel / collide

Automatically exported from code.google.com/p/collide
Apache License 2.0
0 stars 0 forks source link

Analyze memory #17

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
All we know is "it seems to use a lot of memory".

It will take some diving with jhat to figure out who's using so much.  This 
might involve fixes to vert.x, GC on our FileEditSessions, etc.

Original issue reported on code.google.com by dragonsinth on 5 Jul 2012 at 5:00

GoogleCodeExporter commented 9 years ago 
Jaime sez:

Well... we actually know why its running out of memory :). We didn't have time 
to implement garbage collection of file edit sessions.

I also suspect a leak in vertx itself (or our usage of the event bus).

I would actually posit that the proper fix should be to plug the memory leaks. 
It has enough memory by default.

Original comment by dragonsinth on 5 Jul 2012 at 5:16

GoogleCodeExporter commented 9 years ago 
When I received OOM errors in amazon, it was using a free tier app when there 
were many users hitting the site across many open files.

I've had it running in the background now all day, with only one user editing 
at a time.

It's been up for ~24 hours, and currently has 860M virtual memory, 97m 
reserved, and 13M shared.  Wherever the leak, it only seems to crash the app 
under heavy load.  

Perhaps a LinkedHashMap used as an LRU cache could be a good option for caching 
file edit sessions?  That way, a global maximum of say, 64 sessions could be 
left open.

It might be wise to have a config file, so users can specify the amount of 
memory to use in the jvm, and the number of edit sessions to cache?

Original comment by Ja...@wetheinter.net on 6 Jul 2012 at 9:45

GoogleCodeExporter commented 9 years ago 
A smart cache could even use a combination of SoftReferences and heuristics
to manage the set of open sessions without configuration.

Original comment by dragonsinth on 6 Jul 2012 at 11:15