>I haven't reached a concurrency greater than 100 (*blush*) yet so
>I can't say what would exactly happen when the concurrency really
>hits a high number - above the real 1024 limit (or 509 in qmail).

I had both of my QMQP servers bouncing off of the 120 limit yesterday, and
they were pretty much idle (Dell 2450's with 2 striped 9GB 10k rpm drives).
I think even if I could get the concurrency up to 1024 or above, it still
wouldn't be enough to make a difference on the box.  I'll find out soon if I
can make it bounce off of the 509 limit.  Our Midday Market Report is due to
go out within the hour.   Hopefully when the next version of qmail comes
out, it will have the big-concurrency and big-todo patch already installed.


What happens if I start a second copy of qmail using /var/qmail2, different
uids, and bind to another IP on the same box?  Will I be able to do 509
concurrency out of each copy since they are running as different users?

Jay



-----Original Message-----
From: James T. Perry [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 19, 2000 11:41 AM
To: '[EMAIL PROTECTED]'
Subject: Re: concurrency remote patch



Hi Jay,

"Austad, Jay" wrote:
> 
> Here's what I did to rebuild the rpm:

[snip]
Thanks for the information!
I gotta get used to building RPMs...
(after all, I am using an RPM distro ;)

> As for the FD_SET problem, Dell sucks and ships a RAID card
> that requires a proprietary driver on their so-called "Linux
> approved" servers.  It's a pain to recompile the kernel with
> any modifications because that damn module they have might
> not work.  Everyone keeps pushing them to just release the
> source so it can be incorporated into the kernel, but they're
> being stupid about it.

I know _exactly_ what you mean.
(see RANT below)

I guess I wasn't clear on the info I had previously posted.
I didn't recompile the kernel...
I just modified the sources to "goose" the qmail compile process
and it somehow worked (call me kraziej :).

I haven't reached a concurrency greater than 100 (*blush*) yet so
I can't say what would exactly happen when the concurrency really
hits a high number - above the real 1024 limit (or 509 in qmail).

As for performance, my IDE ATA disk is slower than what qmail
can really handle so setting the concurrency below 500 may not
be a problem after all, now that I think of it...
And procmail + /var/spool/mail is another "wide-load" I have
which affects performance compared to Maildir.

If I were to have a RAID 0+1 spinning above 10000rpms, maybe
a different story ( read smokin' gun :)

cheers,
jamie

<RANT>
Recently, I am getting more annoyed with big corporations
leeching off on all of the efforts the open-source spirit
has built up in the past years, giving the community not
much good publicity nor credit in return either...
Steal everything and yet spitting all over us.
Sorry to mention it here folks - no flame please :)
</RANT>


#---------#---------#---------#---------#---------#---------#---------#
-- If somebody can help create a search engine for my room,
   I will call them a Saint...
   GUI == Graphical User Interference

Reply via email to