Re: Problem with Qmail Queueing
On Tue, Jul 24, 2001 at 08:09:01PM -0400, Dahnke, Eric wrote: > > Sorry for my abrupt response previously. I recognize you as a long time > member of the list, and appreciated your help when I was first getting into > qmail. But on a server level you do need to do this no? That is, qmail can > be set to do 300 concurrent deliveries but in the tcp layer either inetd or > tcpserver needs to be upped from their default values as well. Nope. :-) Adjusting qmail-smtpd's tcpserver settings can allow you to handle more -incoming- smtp traffic, but doesn't have anything to do with -outgoing- smtp traffic. John White
Re: Problem with Qmail Queueing
On Tue, Jul 24, 2001 at 06:39:00PM -0400, Dahnke, Eric wrote: > > Wrong. Look at the last line of my post. "By default, tcpserver allows at > most 40 simultaneous qmail-smtpd processes. To raise this limit to 400, use > tcpserver -c 400. " I read that. That doesn't have anything to do with the number of concurrent remote deliveries that qmail will do. John White
Re: Problem with Qmail Queueing
On Tue, Jul 24, 2001 at 05:10:27PM -0400, Dahnke, Eric wrote: > tcpserver_smtpdFrom FAQ: How do I run qmail-smtpd under tcpserver? inetd is > barfing at high loads, cutting off service for ten-minute stretches. I'd > also like better connection logging. Unfortunately, this FAQ doesn't have anything to do with the stated problem of remoteconcurrency. You don't have to touch your qmail-smtpd configuration at all. You do need to stop and restart qmail-send. John White
Re: delivery causing trouble
On Thu, Jul 12, 2001 at 09:42:54AM +0200, Peter Klingeberg wrote: > How can I configure qmail to send the mail only once (per hop) with all > recipients in one Mail? You can't. John
Re: Mailing from One connection
On Mon, Jul 09, 2001 at 12:30:52PM -0600, Roger Walker wrote: > Test with stock qmail on a Solaris workstation, 10,000 copies sent > to the same email address (obviously the same domain) using qmail-inject: > 30 minutes. > > Test from same workstation with a script to generate 10,000 > "rcpt to:" lines and send via a single connection: 5 minutes. > > In the first example, 10,000 actual copies were delivered to the > mailbox but in the second, only a single copy was delivered. > > Presuming it should take the same amount of time to wait for a > "rcpt to:" response whether sending a separate message at a time or a > single message with multiple "rcpt to:" lines, I get the results that I > expected - to send to the same domain (ignoring VERP requirements), it is > faster to use a single connection for multiple messages than to use qmail. Amazing! I guess you're right. What is this MTA called? Where can I download it? Let me know, and I'll set it up on a test box to try to duplicate your test. What were the IP addresses of the two boxes you did this on? What kind of dns library does this server use for it's resolution? And what was the name again? What server did it use for the resolution, and what was the dns latency for that from the sending boxes? I'm going to try to duplicate your test as closely as possible. What was the ip of that dns server again? Wait, I'm reading your post a bit more closely and it doesn't look like you benchmarked qmail against your server, but against "a script to generate 10K rcpt to: lines". Is that right? Now I'm a bit confused. qmail is an MTA which handles many things like a safe queue. What are you comparing that to? The case where I have 10K recipients of one message at one domain which never needs queue management? How does your script handle new messages? How does your script handle a randomly mixed list of 10K recipients who are located at 10 different domains? How does your script handle a list of 50M recipients at one domain? Does your script accept message via the smtp protocol? If so, what happens after it replys ok to the 50M message case, and you power off the box 5 seconds later? Can you send me the source of this script? John
Lyris performance and article
SysAdmin has an article online by some of the top technical people at Lyris (remember Lyris?): Title: Which OS is Fastest for High-Performance Network Applications? http://www.sysadminmag.com/newsletters/feature/ They use their MTA as a comparison tool, and crank it up to the equvalent of a concurrencyremote of 3000, though they don't seem to get much of a performance boost past 1000 on the hardware they're using. One of their conclusions is that their asynch multi-threaded software model outperforms the process based model which qmail uses. Is their methodology convincing? Well... However, and interesting read. John White
Re: High Availability, High Volume and NFS
On Wed, May 23, 2001 at 01:40:13PM -0500, Duane Schaub wrote: > We have tried a Redhat6.1 backend on the NFS with Redhat 6.1 NFS clients. Others may point out that an observed weakness of the stock linux kernel from RH 6.1 has been shown to have weak NFS performance when compared to some of the BSD O/S family. If you feel comfortable recompiling your kernel, check out http://nfs.sourceforge.net/ > The result was that the qmail machines were BARELY able to keep up. If > there were any pauses on the NFS server, the POP sessions would build to > 50-60 very quickly with qmail crashing at about 300 sessions. Once qmail > exceeded about 70 sessions, it was beyond the point of return and would not > recover. Have you thought about the stopgap measure of throttling down on the number of concurrent pop3 sessions each machine is allowed? Say you want to cap it at 50 total. Just use 50/n, where n is the number of client machines, as the max concurrency for tcpserver (-c). You can increase the client backlog so all the clients see is a pause (-b). http://cr.yp.to/ucspi-tcp/tcpserver.html > The NFS server was nothing special (P350/IDE 256Mb RAM). We also tried a > Dell 2300 (Dual 400/RAID5) NT server running Intergraph NFS But the > performance was abysmal! Performing an ls in a user/new directory took 21 > seconds for a response. It will be tempting to throw more hardware at the problem. Depends on your budget. Right now, I like the the new DDR RAM chipsets for Athlon processors. I like the idea of 3ware hardware IDE RAID which looks like a SCSI controller to the system. Balance the bugetary requirements of upgrading your hardware (without knowing what the effect will be) vs. changing your O/S (with some benchmarking already in hand). Oh, check this out: http://innominate.org/%7Etgr/projects/tuning/ Check out slide 37 for relevant conclusions, but the entire presentation is interesting. > I think NFS would work, but I don't really want a Netapp F5 ($50,000). What > NFS experiences are out there? I've read repeated positive reviews with a netapp, but I still would explore FreeBSD performance first. John White
Re: RAID & Qmail.
On Fri, Jan 19, 2001 at 04:59:33PM -0500, Steve Fulton wrote: > I've searched the archives extensively, and I've learned quite a lot, but > I'd like advice on this question: > > Assuming RAID 1+0 is not an option (due to the expense), what level of > RAID is best for storing /Maildir's on a file server (that will be > accessible to the SMTP & POP servers via NFS). Redudancy is the big > issue, otherwise I'd go for RAID 1. The suits are pushing for RAID 5 > because they don't know better - and won't listen. Why is RAID 5 and option if RAID 1+0 isn't? The latter only requires 4 drives in the minimum configuration. You can even do it with IDE drives using 3ware's IDE RAID controllers. John
Re: qmails queue and disk io
On Sun, Sep 24, 2000 at 04:59:24PM -0700, John White wrote: > > 1) Make sure you're using cyclog instead of splogger. splogger >uses syslog, which can definitely slow down your system. Of course I meant multilog in the most recent daemontools package. John
Re: qmails queue and disk io
On Fri, Sep 22, 2000 at 06:48:51AM -0400, Michael Cunningham wrote: > I have a qmail server that is running on a Sun Netra T1 > (solaris 2.6). Its receiving about 300-500k emails per day. > > Unfortunatly it appears to be dieing a VERY quick death. > The IO loads on the disk are huge and I need up performance > quite a bit. The cpu and memory are fine but disk io is killing > me. I was think about a couple possible solutions and I wanted > your input (since you are qmail experts - at least compared to me:) > > 1. add a disk/filesystem for each queue subdirectory to reduce >io load > > 2. create a 1+0 raid of at least 5 drives per stripe, and place >the entire queue directory structure on this raid filesystem. >If possible I will veritasfs instead of ufs for the filesystem >and an a1000 to hold the drives (hardware raid). 1) Make sure you're using cyclog instead of splogger. splogger uses syslog, which can definitely slow down your system. 2) putting the queue on a 1+0 raid is a good thing. What you seem to be describing, two raid 0's mirrored, isn't 1+0 raid, it's 0+1, and isn't as fast or safe. What you want is to mirror pairs of disk drives, then create a stripe accross the mirrored pairs. The best way to do this is with hardware controllers, not a software solution like Veritas (I mention this because you mention Vxfs). A great thing about hardware controllers is that they generally come with battery backed write-back cache, which will cache all of qmail's fsyncs. With just a few mirrored pairs, you'll be writing information to disk in chunks much smaller than the individual drives write cache. 3) Someone mentioned using a solid state disk solution, like that from Seek Systems. I own a Seek array, and have this comment: I benchmarked the array's small block write performance with 128MB of write-back cache against a 128MB write-back cache RAID 1+0 array. The latter blew the former away. The reason is (as far as I can tell), that the Seek array ultimately uses a large RAID 5 for it's back-end storage. RAID 1+0 is much faster as a back-end which my benchmark showed. Perhaps Seek might benefit from the fact that it's read cache is supposed to use some advanced algorithmic methods to keep what you use in the cache. I didn't see that benefit. Buying an SSD disk from someone like Quantum is generally prohibitively expensive vs. a good 1+0 RAID, and nowhere near as safe. John
Re: qmail performance under Solaris8
On Wed, Sep 13, 2000 at 04:56:28PM -0400, Nathan J. Mehl wrote: > In the immortal words of John White ([EMAIL PROTECTED]): > > > > However, I question the decision to use Solaris x86. I'm not aware > > of any advantage there is over something like Linux or xBSD. > > Three words: journalling file system. > > Four more words: integrated logical volume manager. > > Solstice DiskSuite may not be a best-of-breed product in either of > those categories, but it's there, it's basically stable, it's > documented, and as of Solaris 7 it's part of the base distribution. Solaris 7 definitely doesn't come with DiskSuite as part of the base distribution. I know that I certainly don't have it. Solaris 7 does come with a FS that journals metadata, but no one's ever benchmarked it's performance with a large todo for the list. John
Re: qmail performance under Solaris8
Better OS gurus than I can comment on exactly how Solaris bloats network processes. All I'll say is that qmail still performs admirably on the Solaris latform. However, I question the decision to use Solaris x86. I'm not aware of any advantage there is over something like Linux or xBSD. John
Re: FW: qmail domain heiarchy
On Sat, Aug 19, 2000 at 01:52:35PM -0500, Barry Smoke wrote: > >Who is they? The remote schools? All connections? How "dedicated" > >is a connection which is often down? > > remote schools... Ok. > I would like to have some sort of system that catches mail to this server, > checks the headers against a list of local users(take one of our elementary > schools for examplea list of 20 teachers on stored on the proxy that the > mail is checked against) if mail matches a user, deliver it to said user via > a qmail process on local proxy. I really just don't understand what you mean here. > Basically I'm wondering if I can cluster the main bryant.k12.ar.us qmail > server out with processes on the proxy serversomehow. > > If one node is undetected...no prob...all other mail is delivered > normallyqueued mail is delivered when connection is back up It sounds like what you might want to do is put a qmail server on each of the servers at each of the location. Make the terminal delivery point for each teacher the qmail server at his location. It's pretty simple, then, to make a .qmail entry for each teacher at a remote location, forwarding mail the qmail server for that location. For example, if teacherA is at schoolN, this would be put in bryant.k12.ar.us's mx: ~teacherA/.qmail: &[EMAIL PROTECTED] > > >i would like to do this without running other domains Not quite sure what you mean by that. > >I'm not sure how you want each person at each school to receive mail. > ??? pop3, smtp Oh, in that case, just have the mail delivered by smtp. The teachers can then retrieve their mail via pop3. I'm asking whether you want teachers at remote locations to have their mail delivered to a local qmail server so mail can be retrieved during a network connection outage, or whether having the mail at a single qmail server which would require the network connection being up to check mail. In other words, you seem to have a specific path of delivery in mind. What the hell is it? Hint: smtp and pop3 are not valid answers. John White
Re: qmail domain heiarchy
On Sat, Aug 19, 2000 at 12:22:12PM -0500, Barry Smoke wrote: > I am the network administrator for a public school system in ARkansas. > We have just implemented a single qmail mail server for the > districtwhich consists of 8 schools, on 5 different site locations. our > 4 remote elementary schools have 384K dedicated internet connectionsand > our main campus has a t-1, that feeds 4 schools plus administration. > The new mail system was put on a single domain on an ip for the main campus. > The 4 remote elementaries have different ip numbers/subnet masks > > when their internet connection is outwhich happens often, I would like > for local e-mail delivery to still work, while all remote messages are put > in que. Who is they? The remote schools? All connections? How "dedicated" is a connection which is often down? > when the connection comes up, messages are senttransparently. Sent where? You only have a single qmail server, right? > i would like to do this without running other domains > Each remote site...(and the main campus for that matter) is connected to a > transparent masquerading proxy (firewall) serveris this possible...maybe > with port forwardingfirewall rules...runing a qmail server on each local > proxy? > I don't have a clue where to start with this. I'm not sure how you want each person at each school to receive mail. On top of that, I'm unsure about what failure scenario you're concerned about. Can you clear up those points? John White
network solutions spam
Anyone noticed a spike in the last month in spam from Network Solutions? I'm thinking about adding some of their domains to my badmailfrom as neither orbs nor maps seems to be blocking this spam. Anyone paying better attention than I to the source of this spam? John
Re: Maildir Creation
On Fri, Aug 11, 2000 at 01:42:21PM +0100, Slider wrote: > I am trying to create a small Sun Solaris 5.7 development server! I am > having trouble creating the Maildir for the user when I am adding him! > > Command thus #> useradd -s /bin/true -d /usr/home/user -m user > > Unfortunately this is not creating the Maildir I assume you mean that you're using Solaris 7. If you want Solaris useradd to create Maildir's in new user directories with the -m flag, you need to create a Maildir in /etc/skel. You do this by: /var/qmail/bin/maildirmake /etc/skel/Maildir/ After that, all new user directories created with useradd -m will have Maildir's created by default. That is to say, it's not retroactive. :) John White
Re: legit mail being blocked because of relay methods
On Thu, Aug 10, 2000 at 02:17:11PM -0500, Eric Long wrote: > 1. Mail list server has 500 identical e-mails to send. > > 2. It gives that list of addresses to the mailserver, along with the e-mail > message. > > 3. The mailserver then contacts teh first server on teh list, says "here's > an e-mail message", along with a list of addresses (usually 20 or so). > Sometimes all those addresses are on that server, somtimes not. > > 4. To stop spam, the receiver then checks the list for at least one valid > receiver. if one is local, it delivers it and any other local mails, then > relays the rest off to the first system in the list left over. So In step 3, you say "20 or so." What limits that to 20? Volunteerism? What stops me from relaying my entire 50K subscriber mailing list off of your server, as long as you have -one- subscriber to the list? John
Re: rcpt to|cc|bcc and To:|Cc:|Bcc: limitations
On Thu, Aug 10, 2000 at 11:49:56PM +0200, Einar Bordewich wrote: > Well, on a mailing list server where 1000+ mails is going out you will > occupy all remote resources (?) and keep the server bussy for a while. But > on a dedicated mailinglist server you don't have (well, at least not me) > single users sending out one mail at the time. My opinion is that candidates > for mailing list is low priority mail, and single users sending mail is high > priority (understand me right here, I want alle the mail delivered a.s.a.p). I'm getting the impression that you use separate hardware or queues for your mailing list server and non-mailing list mail server. Why not tell the customer to send his 1000+ recipient message to the mailing list server? Won't that solve your problem? John
Re: Configuring a "Store-and-Forward" backup qmail server
On Mon, Aug 07, 2000 at 02:53:36PM +0100, [EMAIL PROTECTED] wrote: > > Just put the domains in rcpthosts and either have a single all domains > entry or define the specific domains which must be forwarded in the > smtproutes file. This way, the qmail box becomes the main MX where all mail > goes first. In smtproutes put: > domain1.com:myexchangebox.mydom.com > domain2.com:myexchangebox.mydom.com No question about it: I would explicitly state which domains should be stored and forwarded in rcpthosts. The messages thus received will bounce after queuelifetime (man qmail-send). John
Re: smtproutes
On Tue, Aug 01, 2000 at 11:05:18AM -0700, Jacob Scott wrote: > I would like to bounce all mail incoming to my qmail machine (which is > qmail.domain.com) for domain.com to mail.domain.com while i set up my > server. What would this look like in smtproutes? I don't see this file in my > control files, and I didnt see it in the install docs. Can anyone point me > towards the answer/tell me which M to RTF? man qmail-control This man page tells you which man page each file in /var/qmail/control is referenced under. This is mentioned in the install, but is generally not absorbed during the initial learning curve. John
Re: qmail-1.03 on Solaris is broken
On Thu, Jul 27, 2000 at 09:35:36PM +0200, Toens Bueker wrote: > Reassured I installed the patched version with all the > nice features (conf-spawn=2045, conf-split=521) -> Success > - no error. On the Solaris 7 platforms, do you make setup check after you change conf-spawn and conf-split? John
Re: Want to know your potential multiple recipient savings?
On Sat, Jul 22, 2000 at 12:45:57PM -0700, [EMAIL PROTECTED] wrote: > o Aggregation is by FQDN, not MX target Again, why? I thought the whole argument was to trade speed for "network good-neighbor"-ness. John
Re: Want to know your potential multiple recipient savings?
On Sat, Jul 22, 2000 at 12:45:57PM -0700, [EMAIL PROTECTED] wrote: > o DNS overhead is not counted I'm still not clear why this isn't counted. I mean, it -is- part of the traffic, is it not? Is it your contention that there's no difference in the dns traffic between the two methods? John
Re: orbs.org accuses qmail of mailbomb relaying!
On Sat, Jul 22, 2000 at 08:07:11AM -0400, Michael T. Babcock wrote: > John White wrote: > > > To be blunt, I don't mind taking a look at the code changes you're > > proposing. Where are they? > > (Sarcasm:) What, you don't know how to code? No, but I'm skeptical about ideas that are so good that someone else should code them. John
Re: orbs.org accuses qmail of mailbomb relaying!
On Fri, Jul 21, 2000 at 11:23:45AM -0400, Mark Mentovai wrote: > >How is this accumulation supposed to occur? Per queue injection? > >Over a time period? How long of a time period? As long as we're > >being good neighbors, should the mta lookup the mx for each > >recipient and accumulate by mx? What should we do if the dns > >gives us a 0 ttl for the mx? > > None of the above. Let me give a loose description of what my idea of an > efficient and fast MTA can do: > > When an MTA receives a message that should be sent out remotely, it should > determine, in order of preference, which remote hosts are candidates for > relaying the message. It should then attempt delivery to the > best-preference host it can find, unless a certain number of active SMTP > sessions to that host are already open. (This number can be one, or it can > be something else small in the interests of allowing for parallel delivery. > It should not be unlimited.) If there are already too many active SMTP > sessions to the remote host, the message should wait until one of those > sessions has finished transferring a message. Instead of closing the SMTP > session, the sender would then transfer the new, waiting message. When a > new message hits the queue and a delivery is attempted, any other messages > in the queue waiting to be delivered to the same host should also be sent > across the same session, or set of sessions. > > An MTA should not split the same message up into multiple messages when > transferring them beyond reason. Although RFC 821 recommends that an SMTP > server implementation place no arbitrary limitation on the number of > recipients per message, it mandates that mail servers must be able to > process up to 100 recipients. If an MTA receives a message with 100 > recipients with the same MX, there is no reason to transfer the message to > the remote mail exchanger 100 times. That's nice. Where's your implementation? I don't mind testing your patches to qmail if you'll send them to me. John
Re: orbs.org accuses qmail of mailbomb relaying!
On Fri, Jul 21, 2000 at 11:20:00AM -0400, Michael T. Babcock wrote: > No, but if qmail is making the deliveries to another MTA, that MTA doesn't > have much choice about whether its going to accept deliveries from Qmail or > not, so why not make Qmail a nice neighbour while we're at it? What are you talking about? You make it sound like MTAs have no choice but to accept new smtp connections until they crash. I know of at least one MTA which doesn't act like this. I question whether any MTA which -does- act like this should be in use. > There's nothing wrong with using intelligent queuing to reorder messages and > reduce session #'s. Sure there is. It creates overhead. > If just getting the mail out FAST is all that matters, > fine. But that's NOT all that matters. To be blunt, I don't mind taking a look at the code changes you're proposing. Where are they? John
Re: orbs.org accuses qmail of mailbomb relaying!
On Fri, Jul 21, 2000 at 10:30:41AM -0400, Mark Mentovai wrote: > That's very easy on a host-by-host basis, and I use it for certain setups. > The problem is that there shouldn't be any "domain in question," an MTA > should make efficient use of a limited number of SMTP sessions when > transferring mail to any other MTA. Why? I'm not trying to be too much of a smartass here, but you're projecting your ideas about nice network usage onto the smtp protocol, which doesn't demand it. How is this accumulation supposed to occur? Per queue injection? Over a time period? How long of a time period? As long as we're being good neighbors, should the mta lookup the mx for each recipient and accumulate by mx? What should we do if the dns gives us a 0 ttl for the mx? While you ponder the answer to those questions, qmail will have delivered the mail. John
Re: orbs.org accuses qmail of mailbomb relaying!
On Fri, Jul 21, 2000 at 09:59:35AM -0400, Mark Mentovai wrote: > qmail-send's behavior for remote deliveries (which includes how it deals > with qmail-rspawn and qmail-remote) is something that's bothered me for a > while. The system really should manage remote deliveries better. At > present, we have one SMTP connection per remote address. This should at > least be modified to give one SMTP connection for each remote mail server > that needs to be contacted for any given message. The ideal case would > allow for a limited number of SMTP connections (to allow for parallel > delivery) to any remote host at any given time, and the capability to > transfer multiple messages in a single SMTP session. > > I understand that qmail's structure makes this difficult, but I don't think > that it should be impossible. qmail's structure make this exceedingly easy. Add the domain in question to rcpthosts. Add a loop-back entry for the domain to smtproutes. Add an entry for the domain to virtualhosts. Create a maildir for the domain. Create a .qmail-default entry for the domain pointing to the maildir. Use maildirsmtp to transfer all the mail stored in the maildir to the remote domain over a single smtp session. John
Re: orbs.org accuses qmail of mailbomb relaying!
On Fri, Jul 21, 2000 at 09:18:42AM -0400, Greg Owen wrote: > If I want to mailbomb foo.com, and bar.com is running qmail, then I > can connect to bar.com's mail and say: > > mail from: <[EMAIL PROTECTED]> (not me, my victim) > rcpt to: <[EMAIL PROTECTED]> (presumed not to exist, will bounce) > rcpt to: <[EMAIL PROTECTED]> (same) > ... (and so on) > rcpt to: <[EMAIL PROTECTED]> (same) > data > Subject: ha ha ha > > Enjoy this DOS > . > quit > > And qmail will send 26 individual bounce messages, one for each > nonexistent recipient at bar.com, back to our victim at foo.com. Upon what are you basing this conclusion? A real-life test? Or supposition? John
Re: tcpserver and NAT
On Fri, Jul 21, 2000 at 01:33:34PM +0200, Lars Brandi Jensen wrote: > I have tried to telnet to port 25 ( telnet 10.1.x.x 25 ) locally and it > works fine. I have send and recived mails locally and it works out fine. > I have send mails outside my net and it works fine. But to recieve mails > from outside isn't working. I have tried to telnet to port 25 from > outside and there was no response ( telnet www.my.dk 25 ). > > Any hint's www.my.dk doesn't resolve. If that's not your actual domain, how can we diagnose dns problems? However, you seem to have narrowed this problem down to a router configuration issue. Find an example of a port which is being successfully forwarded to an IP on your lan. Examine the difference between that configuration and your port 25 configuration. John
Re: qmail died again... 3x in 3 weeks
On Thu, Jul 20, 2000 at 02:16:21PM -0400, Paul Farber wrote: > Here is the ps output after the crash at 12:35 today: > > 339 ?S657:23 syslogd -m 0 [...] > 486 ?S 1:43 splogger qmail Have you thought about the resources used by syslogd during heavy qmail use? Have you thought about migrating to the latest version of daemontools and it's startup idiom? More importantly, using cyclog? John
Re: questions about performance and setup
On Mon, Jul 17, 2000 at 10:29:03AM -0500, Austad, Jay wrote: > With all of the emails I recieved, I get the impression that I'm going to > I/O bound instead of processor or memory bound. Ahhh... someone who gets it. > How much disk will be sufficient for the queue? 1GB? More? What if you did your entire queue injection with your network connection down? I'd budget for a significant portion of that plus growth and safety. > I'm just grasping here to figure out the best solution, so bear with me... > What if I only needed a 1GB queue, and what if that queue was a 1GB ramdisk > (I can put 2GB of ram in the box)? Linux has support for making a disk in > memory, putting a filesystem on it and mounting it. Wouldn't this take care > of I/O problems? I'd read up on ramdisks first. They aren't instant i/o. Alternatively, Quantum has a line of solid state disks which might do the trick for you. Pretty pricey, though. http://www.zdnet.com/etestinglabs/stories/main/0,8829,2352381,00.html John
Re: questions about performance and setup
On Fri, Jul 14, 2000 at 12:21:57PM -0700, Jason Murphy wrote: > The machine I built contains a DPT SmartRAID V SCSI RAID 0/1/5 controller > with 5 1RPM 9.1 gig drives. The thing I notice about RAID 5 in the > right configuration is that you can throw tons of IO at it and you will > see little decrease in performance. Our Database server (Ya, I know, its > not MAIL SERVER) gets tons of IO and its nothing to it; just eats it up > and continues on its way. A massive mail injection, especially if the content is unique to the user, can overwhelm a disk subsystem. This is reccomending the exact -wrong- kind of disk system. RAID 5 has a write penalty, as it has to calculate parity for each write, and write to multiple spindles. The best type of RAID for small block writes is RAID 10 or RAID 1+0 (not to be confused with RAID 0+1). Even better is to use a disk system with write-back cache. Ideally, you need at least seven spindles. I've seen great things with the Infortrend controller. A great setup would be 1U pc's connected to an external RAID. John
Re: Why no queues on NFS?
On Thu, Jun 29, 2000 at 12:55:56PM -0700, Ihnen, David wrote: > This prompted a bit of research. Why didn't it work? My boss wanted > to know too. I found a message on this list where a man states that > qmail queues cannot be located over NFS. > > My question is Why? they use maildir, so they don't need locking, > right? Be technical, I may have to explain this to my boss. You're confusing 1) user mail storage (Maildir), with 2) the qmail queue structure. Maildir is the storage format for final delivery, and is well suited to being on NFS. The qmail queue structure is not much like a Maildir, and is for intermediate storage of a message while waiting on final delivery. The qmail queue cannot be stored on NFS as it 1) requires exclusive access, 2) names files after disk inodes. A good document to read about would be INTERNALS. > And if I can't put the queues there, is there a way to stored > deferred messages there, so we can recover from a relay server > explosion without losing already deferred messages? Just put your entire queue on a RAID partition. Just give yourself enough of a budget to have good IO speed on that RAID partiiton. I'll say it again, RAID 10. John
Re: Draft Predictions
On Tue, Jun 27, 2000 at 01:30:14AM -0700, John White wrote: > Gold and Forum Blue. And mistaken addressing. John
Re: Draft Predictions
On Tue, Jun 27, 2000 at 12:54:08AM -0700, Peter Chi-Lung Yiu wrote: > > [EMAIL PROTECTED] wrote > > Subject: Draft Predictions > > Date: Monday, June 26, 2000 8:04 PM > > > > PGage writes... > > > or 1 would still be available, we should take him, but if the talent level is > > > roughly equal, I would like to see Madsen in blue and gold. >^ > Uh... Golden state? Indiana? Denver? Los Angeles. Gold and Forum Blue. John
Re: Any differences between virtual domains?
On Mon, Jun 26, 2000 at 11:55:30AM +1000, Brett Randall wrote: > Normally I'd just say 'man qmail-send' since you haven't done this but since > it isn't THAT explicit with examples for the virtualdomains file I will let > you off. However, I believe the FAQ is -quite- explicit in it's examples, covering this exact situation. John
Re: Qmail as a relay.
Set up aliases for the various selections, dropping them into local Maildir's. Then use serialmail's maildirsmtp to route the maildir to whatever smtp server you want. John
Re: New Qmail & Unix admin needs help
On Tue, Jun 20, 2000 at 06:01:11PM +0200, Abdul Rehman Gani wrote: > I have successfully installed qmail + vpopmail + qmailadmin on OpenBSD 2.6. > Everything works fine, but I have some questions related to tuning/managing > qmail:- > > 1. How do I restrict multiple simultaneous connections to a particular > server? Using Dan's software, you can do one of two things: 1) native qmail, which doesn't restrict the number of connections at all. 2) intercept outgoing messages to the domain in question, and store them in a Maildir. Then use the serialmail package to deliver them one at a time over a sing smtp connection. John
Re: Bouncing Mail ?
On Tue, Jun 20, 2000 at 10:10:35AM -0400, Dave Sill wrote: > Jonathan Maier <[EMAIL PROTECTED]> wrote: > > >How do I take bounced mail and redeliver it every 60 minutes for 4 hours? > >What file(s) are these variables created in? > > Huh? Bounced mail is returned to the sender as undeliverable. You want > to retry it after the MTA has already tried and failed? Why? It was obvious to me that he meant a soft fail. John
Stupid Sendmail tricks?
On a mailing list I administer, bounces from a subscriber go to the person in the From: header. The subscriber is from leisureworld.org, who's mx is mail.pajo.com bash-2.03$ telnet mail.pajo.com 25 Trying 216.116.96.4... Connected to mail.pajo.com. Escape character is '^]'. 220 mail.pajo.com ESMTP Sendmail 8.9.1a/8.9.0; Mon, 15 May 2000 20:35:17 -0700 Hello Is it really possible to configure Sendmail 8.9.x to bounce messages to someone other than the envelope sender?!?!?!?! John
Re: Share queue between servers and other questions.
On Mon, May 15, 2000 at 05:09:46PM +0800, Michael Boman wrote: > A server goes down that resolvs in global or local downtime (ok, the > box itself is down, but the mail should been taken care of by another > server without we need to plug the raid-set into another box). We > should be able to say: Hmm.. let's check that out after lunch.. or > if it is in the middle of the night: let's have a look at it tomorrow > morning. > > A single point of failure is not an option. Two points: 1) Having a backup qmail server as a backup MX will result in being able to continue delivery of new mail when the primary host goes down. 2) Having the queue of the primary qmail server on an external RAID will allow you to recover what few messages were in the queue at the time of failure at your liesure. A final suggestion: Since you already need a custom delivery agent to look up information from LDAP, or whatever you wanted to do, just have that delivery agent drop a copy of each message in an NFS mounted maildir. Then have another process from the primary server delete anything in the maildir older than queuelifetime. That way a primary server crash will leave a copy of every message which could be in the queue in a maildir. serialmail will allow the messages to be re-injected into another queue. Duplication is the price of recovery. John
Re: Share queue between servers and other questions.
On Sat, May 13, 2000 at 10:02:24PM +0800, Michael Boman wrote: > What I want is to be able to share the queue between n+2 servers on each > loocation as well as be able to split a single domain's mailstorage so each > users doesn't need to download his/hers email from the other end of the world. You again failed to tell us why you want to share the queue. For the second time, what failure modes are you trying to protect against? John
Re: QMail Performance Question & Miscellaneous Issues
On Fri, May 12, 2000 at 12:40:28AM -0600, Neil Schemenauer wrote: > On Thu, May 11, 2000 at 10:54:37PM -0700, John White wrote: > > If you're looking for queue speed, you want RAID 1+0 with a > > NVRAM cache to accellerate the small block writes. > > zeroseek would be even cooler. Don't use zeroseek! Any writes made to vaporware are automatically lost!!! :) John
Re: qmail-smtpd appears to work but doesn't
On Fri, May 12, 2000 at 01:17:19AM -0700, Bob Brown wrote: > Is there a tool to trace where it's getting lost? There should be. You're looking at the smtpd logs, which show that an smtp connection existed. That's a start. How are you doing your logging. do you have a /var/log/qmail/ or something which doesn't log smtpd? John
Re: Share queue between servers and other questions.
On Fri, May 12, 2000 at 03:43:39PM +0800, Michael Boman wrote: > Share queue between servers: It is _not_ acceptable that if one of the servers > dies (as in start burnin etc.. ie: a non-recoverble error) the mail that was in > that queue is gone forever. We _must_ be able to put the queue on a NAS/SAN > storage where several servers (atleast 4 servers) on different sites can process > the queue. You hint at the failure mode that you're trying to protect against, but it would be more helpful if you stated it explicitly: What is it that you want to protect against failing? Direct answer: Can't be done with stock qmail. I know of no attempts to patch qmail to do this. Alternate solution: Put the queue on an external RAID. Still need to connect to it by SCSI, but failure of the server hardware won't result in loss of the queue. Just hook up the backup server to the RAID, reboot, and fix the queue. Again, what it is that you're trying to protect against? Moving the queue to NAS implies that you want to continue operations independant of server hardware. Is that correct? Or is there some other failure mode that you're trying to protect against? John
Re: QMail Performance Question & Miscellaneous Issues
On Thu, May 11, 2000 at 09:01:27AM -0400, Steve Craft wrote: > To throw my $.02 at this issue, if this is looking like a "low level" speed > issue, why not tinker with the hardware? Taking the two disks that hold > /var and putting them on a RAID0 set should give you a serious speed boost > without touching your (otherwise working) qmail config. Definitely don't do that. :) With disk striping, any disk failure = total loss of the queue. If you're looking for queue speed, you want RAID 1+0 with a NVRAM cache to accellerate the small block writes. John
Re: My take on Phoenix
On Sun, May 07, 2000 at 06:08:08PM -0700, Derek Briggs wrote: > > The Lakers are very fortunate not to face a healthy SA. Duncan presents most > of the same problems as Webber offensively, plus he's better defensively. > Robinson is tougher than Vlade. And Avery Johnson isn't an idiot like > Williams. > I disagree with the premise (the Lakers are very -fortunate-). The Spurs championship deserves an asterisk, as it depended on Duncan playing virtually every single minute of the season. That's possible in a shortened season, but not in a full season. They sure tried, and he got injured. The End. John
Re: Open Today.
On Sat, May 06, 2000 at 04:30:54PM -0400, Len Budney wrote: > (BTW blocking DUL has not interfered with my own email in a couple of > years now. So despite the big talk of folks who use it, I continue to > send mail directly from my machine. DUL blocking only works because it > is a rarely-taken measure.) Amazing. In one year, our office ran across: aol.com webtv.net gte.net us.ntt.net nortelnetworks.com frii.com lextron-inc.com We had to smtproute them all to our dialup provider. John
Re: ETRN and QMail
On Thu, May 04, 2000 at 05:51:46PM -0700, Jon Rust wrote: > At 2:43 AM +0200 5/5/00, Peter van Dijk wrote: > >So much for security, eh? > > > > Hrmf. You have apoint there. :-/ Guess I should think before typing. > Of course, by limiting the range of IPs allowed to trigger the > download, you could decrease the exposure, but it would be far from > perfect. No, you're on the right track. Have tcpserver on the private port trigger authentication via the qmail-popup and checkpassword. tcpserver sets the incoming ip address in an environment variable, and you can trigger serial- mail from the tcpserver commandline. John
Re: Three questions...
On Tue, May 02, 2000 at 12:25:14PM -0500, Jeff Hayward wrote: > On Tue, 2 May 2000, Gareth Harper wrote: > > 1) His first requirement was to only allow relaying if the user had one > of his hosted domains as the From: line of an email. I've told him what > a bad idea this is but there's no persuading. So is there anyway to do > this but only when the mail has to be relayed? I'd guess we'd need a > patch to smtpd. Please don't tell me what a bad idea this is - I know. > But orders are orders. > > Warning: brain damage detected. You will instantly be listed in ORBS, and > will likely also be frequently abused by relay-rapers. Jeff, if you read into the statement just a bit, you'll realize that the boss is asking for something much worse: denying relaying from valid IPs which don't present the ISPs domain in the envelope sender. John
Lotus Notes and qmail
Anyone manage Lotus Notes on their Enterprise? I'm wondering if it's possible to use the groupware features (shared calendar, etc) of Notes while maintaining qmail as the smtp and pop server... John
Re: opinion on my proposed setup!
On Thu, Apr 20, 2000 at 10:41:43AM +0530, Madhav wrote: > hi all, > > i am planning to load balance my mail service using 2 servers. my proposed > set up is going to be something like the following, > > | --- Mach1 ---| > Mail clients ---> Router1 | |-/common/qmail > | --- Mach2 --- | > > i would install qmail in machine mach1 in the dir /common/qmail instead of > the default /var/qmail. Now i would share this directory with mach2 using > NFS or Coda file system. i would now start the qmail in both servers(mach1 > and mach2). in mach2, qmail will not be installed and only the qmail > startup script will be created (since it already has access to the qmail > utilities through the share). > [...] > does anyone foresee any problems with this setup? i am a newbie to qmail and > would like the experts' opinion on this setup :) You will, of course, have problems. The qmail queue is designed to be exclusively owned by a single system. Try searching the list on this exact topic. Maildir's are desgned to work over NFS. Tough to get good write performance over NFS, but it should work. John
Re: VERP RFC
On Wed, Apr 12, 2000 at 03:10:14AM -0700, John White wrote: > FROM: <[EMAIL PROTECTED]> > TO: <[EMAIL PROTECTED]> Of course that's MAIL FROM: <> and RCPT TO: <> John
Re: Machine Specs
On Wed, Apr 12, 2000 at 04:57:37AM +, Juan E Suris wrote: > > John White writes: > > > BTW, when you're ready to scale, check out cubix for their SBC based > > chassis. 8 machines in 7U! Add redundant power, a layer 4 switch, > > and a multi-host RAID 1+0 to act as the queue, and you're cooking. > > This sounds interesting to me. What would be a good example of a mutli-host > RAID 1+0 configuration? The Infortrend 3102U2G RAID controller with 9174 daughter card, at least 5 LVDSCSI drives (better with 7 or 9, of course), in a good RAID chassis. That provides up to 6 host connections. John
Re: VERP RFC
On Wed, Apr 12, 2000 at 12:07:09AM -0700, Russ Allbery wrote: > Manuel Lemos <[EMAIL PROTECTED]> writes: > > > Maybe I am missing here something that is simpler than I think but that > > still doesn't answer my basic question: what SMTP command sequence do I > > need to use to enable VERP on message relay delivery? > > None. By the time the message reaches the SMTP level, VERP has already > been done. VERP is not an SMTP feature. *cough* Actually, you can use the user-@domain-@[] format when talking to qmail-smtpd, and the VERP expansion will be handled. John
Re: VERP RFC
On Wed, Apr 12, 2000 at 01:26:07AM -0200, Manuel Lemos wrote: > Hello John, > > On 12-Apr-00 02:05:12, you wrote: > > >On Wed, Apr 12, 2000 at 12:50:41AM -0200, Manuel Lemos wrote: > >> Do you mean there is no way to determine wether the SMTP server supports > >> VERP? > > >Of course there is. You can tell an SMTP server can receive VERP > >encoded sender addresses by the fact that it's an SMTP server. > > I was not meaning receiving servers, but sending servers as I want to relay > messages to a local server using SMTP, not qmail-inject or some other > program. For reasons specific of my purposes I need to relay mail using > SMTP. Of course, if you're contacting an SMTP server to relay for you, then -IT- can receive VERP encoded sender addresses by the fact that it is an SMTP server. Are you requesting a method to avoid doing the verp expansion on your own? > Yes, but id does not contain any example of typical SMTP data interchange > to use VERP like most SMTP based RFC present. Your side would look like: HELO domain.com FROM: <[EMAIL PROTECTED]> TO: <[EMAIL PROTECTED]> DATA [message] . > Another thing, eGroups lists now send messages with headers like this: > > X-eGroups-Return: [EMAIL PROTECTED] > > I suppose this is enabled with VERP. Nope. "Variable Envelope Return Paths" That's not a return path. Thus, it's not a verp. It mimics the functionality by presumably using a parser to look for this header in all returns. > Anybody knows how they achieve this? Custom software. John
Re: Machine Specs
On Tue, Apr 11, 2000 at 04:29:23PM -0400, Jeff Commando Sherwin wrote: > > Right. I don't see much point in it then for inbound SMTP. Let the DNS and > > MX prefs do the job they were designed to do. IP address space isn't *that* > > expensive. > > > > its just that our current situation does not yeild me extra ip space. So I > dont have access to it. Therefore, Im useing an f5 like situation. Port forward the smtp traffic to a single qmail box. The point at which you need to multiplex qmail for incoming connections is the point at which incoming smtp traffic is overwhelming your queue. Even two external IP addresses would allow you to RR your smtp connections without layer 4 hardware, but that's a situation you're more in touch with than we are. However, you certainly don't need to RR physical boxes, just to multiple queue's on the same box by using tcpserver. > > What I'm saying is that your inbound is likely to require more attention > > focussed on you concurrency needs rather than your queue loads. Geez, I'm not sure that's true. The first problem run into by high volume incoming SMTP folks is the point at which qmail is unable to preprocess fast enough. That's a queue issue, not a concurrency one. A very good solution is to feed SMTP traffic to multiple queues on the same machine. > I agree. But given that I may want to have multiple queues, I'm looking > for a pointer on how to handle multiple queues, hopefully with the > benefits and drawbacks the setup. tcpserver lets you do this in a couple different ways. First off, you can set up your tcpserver to load balance qmail instances by originating IP address. This isn't that attractive unless you have specific stats in hand on originating IPs, and are willing to constantly monitor this. The other method is to have multiple IPs on the box, have each tcpserver bind to a specific IP, have each tcpserver feed to a specific qmail instance, and RR smtp traffic to the IPs via some external mechanism. DNS is very good for the last step, but you might have to use hardware, as you don't seem to have that option. > Im sorry for the confusion. Given boxes that are only for outbound > traffic, are there specific optimizations for qmail servers justy for > outbound traffic? When you say outbound, you mean out to the internet? But the volume is a small fraction of the incoming? The only thing to keep is mind is that the PC should be able to cache all it's RAM, and that RAM dictates quite a bit of your concurrency. These days, it's tough not to buy 128MB of ram. Does one need 256MB? Probably not, unless you plan multiple qmail instances with high concurrency, and you're not running into your OS's process limit. BTW, when you're ready to scale, check out cubix for their SBC based chassis. 8 machines in 7U! Add redundant power, a layer 4 switch, and a multi-host RAID 1+0 to act as the queue, and you're cooking. Hmmm... qmail inc. anyone? John
Re: Running qmail on a 4x Xeon 550MHz system
> I'm using ReiserFS (which, BTW, is working very well). My > mailsystem receives 70'000 mails a day and the throughput > is just about twice that. Average mails sent per second > varies around 70-170 mails. It's interesting that you're using ReiserFS. Are you doing that for /var/qmail/queue? At what rate are you able to inject messages into the queue without causing serialization of qmail-send? > I wonder if qmail understands that I'm running a quad- > processor system, as it doesn't seem to deliver messages > faster when the queue builds up. When I run single-threaded > programs which use 100% of one processor, qmail will not > deliver mail! Are you implying that it's qmail's job to manage what processes get scheduled for time on which CPU instead of the OS? John
Re: How can I operate two identical qmail servers?
On Thu, Mar 16, 2000 at 08:34:09PM -, Gabriel Ambuehl wrote: > I'm searching for an easy solution to operate two servers using qmail that > have both the exact same mails on them (so some kind of mirroring) to ensure > the mails don't get killed when one server fails. I understand, that this is > normally done with RAID 1 or 5 systems, but since we use just basic > webservers without RAID systems (but much of them) we'd prefer a system with > two machines much more as this would also help increase general reability. I > know that I can use one server as secondary which get's the mails if primary > isn't responding but I'm looking for two servers with the same mails on it > (eg. just like RAID 1, but with two different machines instead of just two > harddrives). Has anyone got some infos about such a task? http://www.resilience.com John
Re: advice on moving /var to RAID?
On Wed, Feb 16, 2000 at 03:27:14PM -0800, Matt Harrington wrote: > i want to move /var to RAID (software RAID with > FreeBSD's "vinum"). i'd like a sanity check on what i > plan to do: Not sure what RAID level you're using. However, unless it's RAID1+0, you're increasing the first bottleneck which people generally run into: queue disk IO. > - bring /var2 online. /var2 = RAID > - reboot into single user. don't start qmail & MySQL > since they use /var. > - copy /var to /var2 > - edit /etc/fstab to switch /var and /var2 > - reboot into multiuser mode > > will this result in an intact /var? is this what > people do when they want a more reliable qmail mail > spool? Queue file names are based on inode names, so you're going to corrupt your queue. However, there is a queue fixing util on qmail.org. One thing you might want to think about is starting a second qmail instance on a fresh /var2/qmail directory. Change your qmail-smtp startup path to /var2/qmail/bin, and restart it. Make sure you allow relaying from localhost, and smtproute your first qmail instance to localhost. Then flush the /var queue to the new queue. John
Re: dns
On Wed, Feb 09, 2000 at 11:22:20AM -0800, kevin olson wrote: > sorry to throw such primitive questions inbetween all > these expert posts, but > > a.does tinydns/dnscache run on solaris? if so does > anyone here use it on a sparc? I'm using the dnscache server on a sparc, but I compiled it with gcc-2.95.2. John
Re: Bandwidth
If I understand correctly, you don't need to plan bandwidth for web browsing, as that goes through the dial-in provider, but you do need to plan for smtp bandwidth, as that's in-house? I'm reading page 33 of the Jan 31, 2000 Netword World magazine, which has an article quoting stats from Ferris Research: User messaging will jump 81% to 34 messages -received- per user per day. Message size will jump 192% to 286KB per message. If you take that at face value, you need to be able to handle (286KB * 8) * 34 * 10,000 (or whatever you said), divided by 36000 seconds in 10 hours, gets you ... 21Kb/sec? Assuming every user also sends you that traffic as a smarthost in that same time period means you need... 63Kb/sec line? And you have a 2meg line spec'd currently? :) This all changes if you need bandwidth for web traffic, of course. John
Re: maildir delivery code in perl
On Wed, Jan 26, 2000 at 04:23:59PM -0500, Nathan J. Mehl wrote: > > Anybody got any sample maildir delivery code in perl lying about that > I could snarf? A quick scan of CPAN revealed nothing of any use. http://search.cpan.org/doc/KJOHNSON/MailFolder-0.07/Mail/Folder/Maildir.pm John White
qmail-pop3d: unable to write pipe
I'm running into a qmail-pop3d problem which I haven't seen before. I've just migrated to daemontools-0.61, and am having trouble getting qmail-pop3d fully operational under svscan. Symptoms: users can issue USER and PASS commands, but an immediate -ERR unable to write pipe is issued. contents of /service/qmail-pop3d/run: #!/bin/sh /usr/local/bin/tcpserver -v 0 pop3 /var/qmail/bin/qmail-popup \ triceratops.com /bin/checkpassword /var/qmail/bin/qmail-pop3d Maildir 2>&1 /service/qmail-pop3d/log/run: #!/bin/sh exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t /var/log/qmail-pop3d Any ideas? John White
Re: High-load servers...
> On Fri, Jan 21, 2000 at 10:33:04PM -0600, Bruce Guenter wrote: > > > > Could we see it? I am almost finished writing a simple qmail-queue > > wrapper that filters the body of the message through qmail-inject. This > > achieves the same header rewriting that the @fixme trick does, without > > double delivery. Once I finish it I'll post it. Bruce: Russ Allbery's mjinject contains perl code for exactly that operation (or easily modified for that). Hmmm... But you're not working in perl, are you? On Sat, Jan 22, 2000 at 12:48:11PM +0800, Michael Boman wrote: > Can any of this qmail-queue wrappers be done so the queue is stored on a > Network (shared) drive, so each server in a cluster of servers can take > any of the messages is the queue and send it? Michael, 1) qmail-queue is a program with the job of actually writing a message into the "qmaill queue" which is a directory and file structure for safely storing mail messages. They are two different things. The "queue" was designed in a way which necessitates the exclusive use of a single qmail system. Sorry. 2) It's not impossible to cluster servers to balance the "load." First you have to define whether it's the incoming or outgoing message load which you have to balance. Second, you have to realize that none of the solutions which will help you solve your problem will involve sharing a "queue" between multiple instanciations of qmail. Each instance will have its own queue. John White
Re: High-load servers...
On Fri, Jan 21, 2000 at 12:36:15PM +0800, Michael Boman wrote: > I've seen someone post a question like this but didnt get a decent answer. > > I am looking into hosting a mailservice that will handle around 1-3 > million SMTP transactions per day. What kind of hardware do I need to > manage that? > > I also wonder if there could be a change of the queue dir so it could > be shared, as then any of the mailservers in the mailcluster can take > the queued file and send it, and not only the one that recived it in > the first place. To deliver 1 million local inbound deliveries: I'd reccommend buying 72GB of RAID 1+0 storage. Slice off 2GB for each incoming smtp server's /var/qmail/ partition. You have a choice of sharing all the mailboxes from 1 NFS server, or splitting the storage into multiple servers, handling a fraction of the user mailboxes. Deciding which was the topic of a recent discussion. To deliver 3 million outgoing messages, I'd buy the smallest RAID 1+0 configuration I could, probably 6 9GB drives + hot spare, which gets you 27GB of storage. Create 2GB of storage for each instance of qmail you're going to create (start with one; you put the /var/qmail/ partitions here). A couple of things to try: ReiserFS on the queue partition. More than one qmail instance. Increasing the Write-Back cache on the raid controller (64MB is pretty standard). John
Re: Performance?!
On Fri, Dec 10, 1999 at 04:54:31PM +0100, Ekker, Heinz wrote: > When I first tested it, I used alias-expansion with the fastforward-package, > and to be honest, I was quite surprised to find that qmail could - on a > Pentium III 500 with 512 Megs RAM and a 19GB Level 1-RAID running RedHat, > 2.2.13 with fd-patch - deliver only about 2 messages per second. The Queue > kept filling up, and half of the messages were not preprocessed. Only when I > let go of fastforward, I reached ~200 messages per minute and 17-18 MB of > throughput, which still seems very little. At least the preprocessing seemed > to work now. The CPU idles with 70, 80 %, there's plenty of RAM left. The > local concurrency never ever rises above 5. Did you see a discussion in the last 30 days about RAID levels? Is your /var/qmail/queue on the RAID1? Big write I/O reduction if you are. John
multilog and Informix engine?
Has anyone familiar with the Informix database engine thought about using multilog to assist with the management of Informix physical and logical logs? Just curious... John White
Re: disk mirroring
On Mon, Nov 22, 1999 at 03:47:47PM -0800, Racer X wrote: > read the message again, specifically the part about "non-volatile." Oh right. How he spelled it. > hardware raid is a different beast entirely, particularly when you're > talking about stuff that has battery backed caches. i still don't know that > it would be a win for qmail unless you had a LARGE queue with lots of large > messages. HW RAID 1+0 is generally a win -because- you don't need a lot of the space. Lop off a 2GB LUN for the qmail queue. Oh, your external firewall needs a high-performance qmail-queue too? There goes another 2GB LUN. That's right: EXTERNAL HW RAID generally can be configured for multiple hosts. Use the rest as protected mailbox storage or generic "network attached storage". Enjoy the praise you get for the high i/o performance. John
Re: disk mirroring
On Tue, Nov 23, 1999 at 02:04:50AM +, Florian G. Pflug wrote: > > Or perhaps you don't know? HW RAID controllers can come with non-volitile > > RAM caches. When part of this cache is in "writeback" mode, scsi write > > commands are put in the cache, and the controller tells the OS that the > > command has been completed. Then the writes are committed to hard drive > > (which have their own caches). Thus, multiple small-block writes followed > > by fsync's should finish much quicker on a HW RAID with writeback cache. > > > > If you're relying on OS RAM to do the same thing for a filesystem, then > > the fsync will put an end to that. > > All this would make hw-cach *forbidden* for qmail queue dir, since then it > is *not* guaranteed, that what is synced is writted on disk and will > survive a power loss Not true. It's important to have a NVRAM cache; NV as in non-volitile to survive a power outage. > Anyway, what is noone mentioning raid 5? I just played with it under linux > (software raid) until now - but it seems quite fast. RAID 5 write performance is either as bad or worse than RAID 1. John
Re: disk mirroring
On Mon, Nov 22, 1999 at 09:45:52AM +, John P . Looney wrote: > On Fri, Nov 19, 1999 at 03:18:37PM -0800, John White mentioned: > > Slowing down the writes to the queue is a bad thing. The queue is > > constantly being sync'ed. > > But I thought that messages were all stored in separate files/directories. > With striping, we can get those spread over a load of disks. I know. That's why I reccomended RAID 1+0 with writeback cache for sites which need queue performance. > > > If he's using Disksuite, he's getting it free with Solaris. > > Actually, DS doesn't come "free" unless you buy the Server edition > > of Solaris, at a cost differential to the WS edition. > > And if he's running it as a mail server ... Sun are pretty lenient with > their workstation/server idea. It's supposed to be at odds with microsoft. > "Here is your $20,000 workstation. We'll be nice and let you use the Server > CD for free !" You don't understand. If you purchase a WS edition of Solaris, you don't get Disksuite. > > > Hmm. Tell that to Dell. We'ed a few Sun E1s, some with 4TB+ of disks > > > hanging off them, one domain alone with 1600 live users, all using software > > > RAID. Those babies had to have 100% availibility, and a new CPU cost > > > $16000, so if there were real gains from hardware RAID, we would have used > > > it. There wasn't any. It was cheaper and faster. > > For a RAID 1 qmail queue? Or some other RAID topology for some other > > function? > > All the Sun boxes they have run on software RAID - everything from the > massive pan-European sales & support databases to the little 12 CPU credit > card authorisation system. To clarify, my question was: "Were any of the boxes you mention using software RAID 1 for a qmail queue?" Not: "Please mention some applications which these boxes supported." Waxing nostalgic about software raid in the general case doesn't make software raid 1 a good choice for /var/qmail/queue. It's a terrible choice. >>> Hardware raid is only of >>> great benefit for PCs that run NT, or mainframes whose real cost is mips, >>> so they want to move all processing off the processor. Or people that think >>> RAID 5 is a good idea :) >> Not at all. HW RAID is a good way to cache writes, and maximize >> CPU cycles. > How does it cache the writes ? Is this CPU cache, or disk cache. With > software RAID, aren't you just caching anything you write to the disk array > anyway ? I don't really mean to be a hardass here, but you need to know about how the qmail queue works. You have the qmail source right? Included with that source is an "INTERNALS" document which describes how the queue works. With qmail's insistance on fsync'ing, you can see how a writeback cache on the HW RAID controller can help. Or perhaps you don't know? HW RAID controllers can come with non-volitile RAM caches. When part of this cache is in "writeback" mode, scsi write commands are put in the cache, and the controller tells the OS that the command has been completed. Then the writes are committed to hard drive (which have their own caches). Thus, multiple small-block writes followed by fsync's should finish much quicker on a HW RAID with writeback cache. If you're relying on OS RAM to do the same thing for a filesystem, then the fsync will put an end to that. > > It sounds to me like you're abstracting benefits you've seen on software > > RAID to the qmail queue in a RAID 1. That's not a good thing to do, as > > qmail has a pretty unique I/O signature. > > More than likely :) No, I was more talking about using RAID1+0, so he'd > get as much benefit from straight striping as possible. You mentioned that RAID 1+0 would give the max performance, but advocated software -mirroring- as ok for the qmail queue. It isn't. I agree that RAID 1+0 or 10 gives the best protected performance. John
Re: qmail remote delivery logic
On Mon, Nov 08, 1999 at 11:24:23PM +, David L. Nicol wrote: > John White flamed forth: > > > > man pages indicate ... that qmail-remote "sends the message > > > to one or more recipients at a remote host." Which means that > > > it still hasn't been split up when qmail-remote gets it, and that > > > qmail-remote is the only program that would need to be patched. > > > > No it doesn't. > > Yes, that's what the man page for qmail-remote says. No, you don't understand. Just because qmail-remote allows multiple recipients doesn't mean that a message in the qmail system hasn't been split at the time that qmail-remote is invoked. Nor would qmail-remote be the only program that needs to be patched to allow qmail to do multiple recpt-to's. > If a single > qmail-remote instance is handling each address, why does the man > page say that qmail-remote accepts multiple addresses? qmail uses a single qmail-remote to deliver one message to one recipient. qmail-remote is not limited to this. What's the problem? > Does > qmail-remote > have aspects of its interface which are not being used by the other > parts > of the system? Yes. > Did the great DJB allow an inconsistency to appear > between his coding and his documentation? Not that I see in this specific case. John
Re: qmail remote delivery logic
I understand the motivation David, I really do. But you don't seem to understand who qmail works. On Mon, Nov 08, 1999 at 09:12:48PM +, David L. Nicol wrote: > What the people with the problem are asking for appears to > be for qmail to not split up identical mails intended for > multiple recipients at identical hosts. These are real problems > and poo-pooing them as degenerate cases or something produces nothing. No. What people are asking for is that qmail not treat a message with multiple recipients as separate messages to those recipients if the recipients are to be routed through the same SMTP server. Unfortunately, they're unclear about what they mean. If I have a message to 1M different FQDN which all use the same MX, do I want to split, or don't I? > In terms of modifying, this might not be the "extensive > rewrite" that "life with qmail" claims it will be. I see two > parts to change: > > We want (1)the part that splits messages with multiple recipients > to group by mail-host-name and merely split by mail-host-name, > and also (2) that qmail-remote can issue multiple rcpt-to instructions > in these cases. That is all. Two patches. Three, with (3) > record-keeping > regarding who has received and who has errorred adjusted to work with > (2.) > > > People who are running mailing lists (which need VERPS) behind > low-bandwidth > links are not covered by this patch proporal: They need to form > cooperatives > and rent servers with good connections. Ok, you're vastly oversimplifying how complex those changes are, and mistaken in the need to patch qmail-remote. And you're excluding the people who "need" the the modification the most from the umbrella. > man pages indicate ... that qmail-remote "sends the message > to one or more recipients at a remote host." Which means that > it still hasn't been split up when qmail-remote gets it, and that > qmail-remote is the only program that would need to be patched. No it doesn't. > Is this accurate, that messages withmultiple recipients are > associated with a single queue entry until they are delivered > and cleaned up, and that all delivery multiplexing happens within > qmail-remote? No. > If so, qmail-remote is the only part of the system > which needs to be tweaked, and the groundwork is already there. And as such, you conclusion is incorrect. Take a look at INTERNALS. John
Re: disk mirroring
On Fri, Nov 19, 1999 at 03:25:43PM -0800, John White wrote: > > On the former point: why is such a huge proportion of the world doing their > > mirroring with software RAID (generally Veritas) including some HUGE solaris > > installations (Sun seems quite keen on Veritas). > > Probably because those installations are supporting a qmail queue > on their giant SW RAIDs. ^^^ AREN'T John
Re: disk mirroring
On Fri, Nov 19, 1999 at 09:57:44AM -0800, Matthew Brown wrote: > John White wrote: > > IMHO, no software mirroring scheme is going to do the trick. AND > > they're overwhelmingly expensive. > > As to the latter point, isn't DiskSuite included in your Solaris license > these days? No. One has to buy a special edition of the OS to get DS. > On the former point: why is such a huge proportion of the world doing their > mirroring with software RAID (generally Veritas) including some HUGE solaris > installations (Sun seems quite keen on Veritas). Probably because those installations are supporting a qmail queue on their giant SW RAIDs. > > Software RAID is, again IMHO, not suitable for making your queue > > redundant or quick. > > I've met many people who are of the opinion that software RAID is no slower > than most hardware RAID. Or is the 'most' the important word here? The phrase "writeback cache" is what's important. Disk i/o is a bottleneck. SW RAID 1 exacerbates that bottleneck. If redundancy is all you want, I'd reccomend a HW RAID 1 with a cache to smooth out the spikes in usage. If you needed continuous high performance, I'd go with a 1+0 configuration with more cache AND a journaled fs. John
Re: disk mirroring
On Thu, Nov 18, 1999 at 07:36:17PM -0800, Michael Boyiazis wrote: > We are thinking of using OpenDiskSuite to > mirror a disk which contains /var/qmail so that > if the disk dies we have (hopefully) not lost the > mail in the queue. Will this work? > > Would I then need to run the queue through the > queue recovery script or should it be okay without? > > Would it be better to use Veritas or something else? IMHO, no software mirroring scheme is going to do the trick. AND they're overwhelmingly expensive. If redundancy is your goal, then get an SCSI to SCSI raid controller and set up /var/qmail/queue on a RAID 1 partion. If you're looking for performance with redundancy, then make sure the controller can do RAID 1+0 with a write-back cache. Hot swap is a must in these cases. Any RAID built on the Infortrend controller will make you a happy guy. Software RAID is, again IMHO, not suitable for making your queue redundant or quick. John
