Petr Novotny wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 28 Jan 00, at 11:29, Henrik �hman wrote:
> > A user just sent 2 subsequent mails to a mailing list, both including quite
> > large attachments (looking in ~user/list/archive, the files are 1,2Mb and
> > 730kb respectively) to 21 users. This is quite heavy on a 128kbit line, esp.
> > since concurrencyremote is 20, so I expect that each qmail-remote takes its
> > share of the bandwidth, leaving 128/20 kbit per delivery.
>
> Well, TCP/IP doesn't work this way. Each connection is trying to
> steal as much as possible - only if the replies from the opposite
> sides have (roughly) identical delays, the bandwidth is shared
> evenly; otherwise, the more responsive hosts get larger share of
> bandwidth. But anyway...
>
Ok, yeah, I was being a little brief there, but anyway. ;)
> > So, naturally, I'll get a few defferals due to dead connections, but
> > eventually all the mail should get sent, so I don't worry about that. What I
> > do worry about is that I can't login because bash can't fork (due to lack of
> > memory,) that the load peaks around 2.40 and averages at 1.20
>
> Which processes are running (ie. actively working)?
>
The curious thing is, when I started top, the CPU was 98% idle, so the heavy load
must have come during a very short peak. Also, memory usage had sunk to more normal
levels after just a few seconds (next time I tried to log into a virtual console, I
did not recieve an error message about memory shortage.) As I ran top, all the 20
qmail-remotes were S, as were all other processes (except for top.)
The only difference from normal behaviour was that I could not establish any
TCP/IP-connection whatsoever.
> Unstable kernel. What you describe looks like memory leak
> somewhere in kernel (network part probably).
Ok, an upgrade is due anyway. Too bad the kernel didn't say anything about it.
> Simply, by calling normal functions, you CAN'T crash anything in
> the kernel. qmail is a userspace program, not a kernel program.
> End of story.
Okay, then it should definitely be a kernel level error.
> > 3Com 3c905B (Running in 100Mbit to the router)
>
> Do you use Becker's driver, or 3Com's one?
>
Becker's. Any differences? Is 3Com's better?
Oh, and sorry if I seemed to unrighteously accuse qmail of something. ;)
Thanks, Henrik.
