[855] in Zephyr_Bugs
heath@ofb.net: Zephyr, server bloatage, 2.1.0 vs. 2.0.4...
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Apr 26 23:07:28 1997
To: zephyr-bugs@MIT.EDU
Date: Sat, 26 Apr 1997 23:07:25 EDT
From: Greg Hudson <ghudson@MIT.EDU>
------- Forwarded Message
Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po10.MIT.EDU (5.61/4.7) id AA06775; Sat, 26 Apr 97 19:53:03 EDT
Received: from [206.117.84.13] by MIT.EDU with SMTP
id AA06736; Sat, 26 Apr 97 18:52:32 EST
Received: (qmail 6480 invoked by uid 2912); 26 Apr 1997 23:53:00 -0000
Message-Id: <19970426235300.6478.qmail@ofb.net>
From: heath@ofb.net
Subject: Zephyr, server bloatage, 2.1.0 vs. 2.0.4...
To: ghudson@MIT.EDU
Date: Sat, 26 Apr 1997 16:53:00 -0700 (PDT)
Cc: egnor@ofb.net (Dan Egnor), mid@ugcs.caltech.edu,
blakej@ofb.net (Blake A. Jones)
Content-Type: text
Greg,
I'm mailing you because I see your username in the version control string
of the zephyr distribution I have. If you're not the right guy for this
question, please forward this.
The Caltech UGCS lab has been running zephyrd 2.0.2 under HP-UX 9.something
for about a year or so. During that time, we became used to the zephyrd
using increasing amounts of RSS and VM, until it usually choked our
server machine. We 'worked-around' this by just killing the thing every
12 hours or so - an automatic message told users to restart their zwgcs.
Non-ideal.
Recently, some of us Caltech alums have chipped in on our own little
net comunity, ofb.net. We got zephyr 2.0.4 (fixes the braindump bug
with setting client locations) and hooked up two servers. Fail-over
worked OK, so we no longer had to advise people to restart their clients
periodically. Still, killing the server on a regular basis was lame.
So, I linked the server with my personal malloc()-free() tracking
code. I fully expected to find some gargantuan memory leak that
would account for megs/day. No such luck. There was a small obvious
leak in subscr.c, line 174, where strings weren't freed. This didn't
really account for all the lost memory. (Patch below.)
Meanwhile, we could work the server into a state which allocated
50MB of RSS, while the heap was only 200k or so. This was a 49MB
discrepancy. As far as I can tell, it's all a result of heap
fragmentation. Yes, I know this is implausibly pathological
heap behavior. However, we saw the same growth in RSS on Linux
2.0.27 and HP-UX 9, and some other patches I have tested _seem_
to help the problem.
Basically, I have gone through the code and tried to minimize the
malloc()'s. In zstring.c, I avoid the strsave() for downcase until
the last possible minute (note that find_string can find a downcase
string...). In uloc.c, I reallocate locations array
O(log2(max_logins)) instead of O( logins + logouts ). This makes
a big difference in our startup RSS.
Most of all, in dispatch.c, I allocate the Unacked structure with
the packet that it points to. This requires changes to server.c
and dispatch.c, wherever they used to free these structures.
My question is: "Do you want these patches?" I know you're working
on 2.1.x - you may have abandoned a bunch of this code. Or, you
may have fixed these, anyway. Let me know if you want them.
Meanwhile, here is the 2.0.4 patch for subscr.c:
Later,
Heath
diff subscr.c ../dist/server/subscr.c
91d90
< static void free_subscription __P((Destlist *sub));
173a173
> free(subs);
175d174
< free_subscription(subs);
178c177
< free_subscriptions(subs);
- ---
> free_subscriptions(next);
379c378,381
< free_subscription( subs );
- ---
> free_string(subs->dest.classname);
> free_string(subs->dest.inst);
> free_string(subs->dest.recip);
> free(subs);
833,847d834
< * free the memory allocated for this subscription.
< */
<
< static void
< free_subscription(sub)
< Destlist *sub;
< {
< free_string(sub->dest.classname);
< free_string(sub->dest.inst);
< free_string(sub->dest.recip);
< free(sub);
< }
<
<
< /*
859c846,849
< free_subscription(subs);
- ---
> free_string(subs->dest.classname);
> free_string(subs->dest.inst);
> free_string(subs->dest.recip);
> free(subs);
------- End of Forwarded Message
