[racket] racket http server, major GC: -216 bytes collected
From: Stefan Schmiedl (s at xss.de)
Date: Mon Jan 10 12:00:35 EST 2011 |
|
On Mon, 10 Jan 2011 06:53:36 -0700
Matthew Flatt <mflatt at cs.utah.edu> wrote:
> At Sun, 9 Jan 2011 20:19:23 +0100, Stefan Schmiedl wrote:
> > Well, that was about two hours ago. The reference GC instance is
> > still idling away at 18330232 bytes, just as before, but the web server
> > instance has "grown" from 47923392 (first GC of -672 bytes) to 47957512
> > (first GC of -672 bytes after last "real" GC), that's about 32kB.
> >
> > Somebody's snacking on my RAM here.
>
> There are many reasons that small amounts of memory may accumulate in
> the short run --- especially caches and data structures that
> periodically compact themselves.
What I find interesting is that there are no such complex structures
in the reference session I ran, but crop up in the web server session,
even while it is not doing anything...
>
> Meanwhile, I'm not sure why you're seeing GCs at all when the server is
> idle. The GCs unexpected, right? But if you're using the LRU manager,
> it seems to call `collect-garbage' along with its collection routine.
>
... except having around the LRU manager. Good point. I'll try using
another manager and see if it makes a difference. But right now it looks
as if the act of GC is causing a tiny leak.
> For example, if I start Racket and just run `(collect-garbage)' in the
> REPL, then after a while, I see a cycle of about 20 numbers around
> -1000 and then one number around 15000. That effect seems to be from
> the REPL allocating parameters that create weak boxes that are
> referenced by a chain of records that are periodically compacted into a
> hash table. The negative numbers don't quite balance the positive
> numbers for the first many iterations of the cycle, because there's
> another effect relate to rehashing (that will eventually compact a hash
> table of weak boxes); I expect I'd see a larger positive number if I
> had enough patience to go hundreds of times.
Heh, that's why I asked earlier how to speed things up. If you look back
at my (loop), you'll see that I'm calling collect-garbage every 10 s.
>
> It's always possible that you're seeing a real leak, but I think it's
> at least as likely that you're just seeing the effects of complex data
> structures in the run-time system.
>
It looks like it might be a while before I can spare some time for further
investigations, but I'll keep in on top of my list.
Thanks for the LRU idea.
s.