Hi Dennis, thanks for your suggestions.
Currently, I don't dispose of editing contexts explicitly. I had EOF errors a few years ago when I used to have dispose() calls after the final saveChanges(), so I stopped doing dispose(). (I don't recall the details.) I do however create editing contexts frequently and do only limited stuff in each one. I don't use the session editing context. So in theory, any editing context should become unreachable once the component is no longer in the page cache, and then the garbage collector should take care of it. Are you suggesting something different? And you also suggest that when I dispose() of editing contexts, the corresponding snapshots are purged from the snapshot cache? That would be new to me. Currently I don't know of a method to do that other than invalidateAllObjects() or invalidateObjectsWithGlobalIDs(). Maik > Am 27.01.2016 um 10:39 schrieb Dennis Bliefernicht > <dennis.blieferni...@xyrality.com>: > > Hi, > >> On 26.01.2016, at 14:28, Musall Maik <m...@selbstdenker.ag >> <mailto:m...@selbstdenker.ag>> wrote: >> >> Anyway, heap sizes of up to 60 GByte are apparently not so common, at least >> not with WebObjects. I found a helpful article [1] about very large JVM >> heaps, including the hint to the Zing Azul JVM, which features a stopless >> garbage collector [3], but costs $8000 per server and year. In the end, we >> may actually be trying that if other options fail, but first I need to >> understand more about what's in memory. I'm currently approaching that >> question via JProfiler, especially to find out if that's all snapshot cache >> (how would I limit that in size?) or some other homemade memory leak. > > Just a shot in the dark (especially the regular timing makes this weird), but > we have had some issues with the snapshot cache accumulating a lot of data > when some editing contexts weren't disposed early on (and the referred > objects thus were carried on until session timeouts may finally remove them). > With the number of objects growing we observed (if I remember correctly) > quadratic runtime growth when retrieving objects form the snapshot cache. As > we handle a large amount of small objects, this escalated rather suddenly > when the cache exceeded a certain size. In this case JProfiler should show > you larger amounts of time spent retrieving objects from the snapshot cache > in the Hotspots list. In our case we were able to dispose editing contexts as > soon as possible, flushing the objects out of the cache and keeping retrieval > time speedy. Restarting instances would in this case also keep the > accumulated cruft down, this scenario would probably only match though, if a > significant amount of objects come into the system shortly before or at the > waiting times. > > Greetings > Dennis > > -- > > > > > > ----------------------------------------------------- > Dennis Bliefernicht • Backend Development > T +49 40 357 3001 62 > dennis.blieferni...@xyrality.com <mailto:dennis.blieferni...@xyrality.com> > > XYRALITY GmbH • Friedensallee 290 • 22763 Hamburg > www.xyrality.com <http://www.xyrality.com/> > Registergericht: Hamburg HRB 115332 > Geschäftsführer: Sven Ossenbrüggen > ----------------------------------------------------- >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
