On Fri, Jan 28, 2000 at 11:25:51AM -0500, Jonathan Herbert wrote:
> > > 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.
>
> I've implemented qmail in a number of environments, including small to
> medium sized ISPs, research groups, and private companies as well. One of
> the main complaints has always been the amorphous "problem with large
> attachments".
>
> I can't imagine that this could be entirely the OS's fault, considering this
> tends to be a consistent problem regardless of architecture or OS.
Which problem in particular? qmail has no clue as to whether it is really
running on a 486 with 8MB or memory and a 2400bps link or a 64x CPU E10000
with a couple gig of memory and an OC48 connection to the Internet.
The only person with the possibility of having such a clue is the person who
admins the system.
Based on this, my suggestion is that resource consumption by anything that runs
on a system is something that should be controlled by the admin. That qmail lets
you utilize the system resource controls to *gracefully* control just about every
resource type on a system means that you can tune it fairly precisely to your needs.
In additional qmail has numerous concurrency and resource control mechanisms above
and beyond that offered by a typical Unix.
That a default qmail install might consume too many resources in some situations
is entirely to be expected. That a default qmail install doesn't consume enough
resources in other situations is just as expected.
Regards.
