Slow Connection with LVS
We have a couple of Qmail servers in a cluster (LVS), co-existing with Sendmail. The qmail servers take half and one minute each for establishing the connection with client when connecting thru the LVS. The tcpserver option I am using is –R and –t 0 with which, direct connection happens with absolutely no delay. The LVS is fine I guess since the sendmail gets connected without any delay thru LVS. Could any one help me reducing this delay? Thanks, Mehul.
FW: Slow Connection with LVS
Why do I get this message? Any suggestions? Thanks. -Original Message- From: Mailer-Daemon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 19, 2001 9:28 AM To: [EMAIL PROTECTED] Subject: NDN: Slow Connection with LVS Importance: High Sorry. Your message could not be delivered to: test test (Mailbox or Conference is full.)
FW: Slow Connection with LVS
Any suggestions / further reading? Posting this again since our internet link was down this morning and in the mean time if some one has (hopefully ..!!) responded, might be bounced. Thanks, Mehul. -Original Message- From: Mehul Choksi [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 19, 2001 9:29 AM To: Qmail List (E-mail) Subject: Slow Connection with LVS We have a couple of Qmail servers in a cluster (LVS), co-existing with Sendmail. The qmail servers take half and one minute each for establishing the connection with client when connecting thru the LVS. The tcpserver option I am using is –R and –t 0 with which, direct connection happens with absolutely no delay. The LVS is fine I guess since the sendmail gets connected without any delay thru LVS. Could any one help me reducing this delay? Thanks, Mehul.
Connections Slow with LVS
Hi guys, any ideas why qmail with the Linux Virtual Server takes so long for the connection even with the tcpserver –R and –t 0?? Also, I have not yet applied the big-concurrency patch (I always run in to trouble with that patch..!!), and yet I have set the concurrencyremote to 254. So far it is doing good, but not sure if it is okay. Any suggestion? Thanks in advance, Mehul.
FW: Connections Slow with LVS
Many Thanks Charles, I used -H, -l localname with tcpserver and it works fine even with the LVS. For the remote concurrency, what I meant to ask was " is it okay to set the remote concurrency to 254 without the patch or will I run in to issues later on when it really needs those concurrencies?" Regards, Mehul Mehul Choksi <[EMAIL PROTECTED]> wrote: > any ideas why qmail with the Linux Virtual Server takes so long > for the connection even with the tcpserver -R and -t 0?? There are other data-gathering options to tcpserver. This is FAQ#1. > Also, I have not yet applied the big-concurrency patch (I always run in to > trouble with that patch..!!), and yet I have set the concurrencyremote to > 254. So far it is doing good, but not sure if it is okay. Any suggestion? Very, very few sites need concurrency > 255. Skip the patch until you determine you really do need it. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
RE: stop 'identing'
Thanks for responding. I have checked the tcpserver options (http://cr.yp.to/ucspi-tcp/tcpserver.html ) but none found to stop identing. Regards, Mehul. -Original Message- From: Frank Tegtmeyer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 18, 2001 3:15 PM To: [EMAIL PROTECTED] Subject: stop 'identing' "Mehul Choksi" <[EMAIL PROTECTED]> writes: > Hi, is it possible to stop qmail identing? Any help in this regard would be > greatly appreciated. I have been looking at various documents to stop qmail > to do ident, but so far don not have any luck. Please don't use followups when starting a new topic. Please use a different Subject: too in this case. To answer your question: if you run qmail-smtpd/-pop3d etc. under tcpserver (which is strongly recommended), have a look at the switches -l, -H and -R for the tcpserver program. Regards, Frank
RE: stop 'identing'
Thanks a lot. I used -R with tcpserver and it works. I greatly appreciate your help. Regards, Mehul. -Original Message- From: Charles Cazabon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 18, 2001 3:55 PM To: [EMAIL PROTECTED] Subject: Re: stop 'identing' Mehul Choksi <[EMAIL PROTECTED]> wrote: > I have checked the tcpserver options > (http://cr.yp.to/ucspi-tcp/tcpserver.html ) but none found to stop identing. Bzzt. TCPREMOTEINFO _is_ ident data. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Queue Building
We have set up the qmail server using Adam McKenna’s Qmail-HOWTO V2 and it is working fine in normal condition. The purpose is to introduce qmail as an SMTP server in outbound email distribution system – just to send a million mails daily to subscribed users. We tested the performance of the qmail by sending a few thousands mails to non-existent email-ids and to bounce back to another mail server. Strangely enough, qmail just built up a huge queue, without even preprocessing. Once the application stopped pumping to the Qmail server, it started processing and clearing queue, which took very long. Is it a normal behavior (since all the email addresses were non-existent) or are we missing something somewhere? Concurrency is set to 120 for local and remote. Any help/suggestions would be greatly appreciated. Regards, Mehul.
RE: Queue Building
Thanks a lot for the reply. The clarifications to your queries are embedded - Mehul Choksi <[EMAIL PROTECTED]> wrote: > The purpose is to introduce qmail as an SMTP server in outbound email > distribution system - just to send a million mails daily to subscribed > users. Do you mean send identical copies of one message to a million users, or send one million unique emails, each to one user? The difference is enormous. -> It depends, normally in batches of 100,000 to 300,000 identical mails prepared by an application to be sent to subscribers. Currently we use a pool of sendmail servers (ordinary PIII 500 with 128MB RAM and IDE). We are planning to migrate to QMAIL eventually if we find better performance. * We tested the performance of the qmail by sending a few thousands mails to > non-existent email-ids and to bounce back to another mail server. Strangely > enough, qmail just built up a huge queue, without even preprocessing. qmail doesn't start new deliveries if there are messages waiting to be preprocessed (in todo). If todo grows large, linear directory scan times can slow the system down significantly; Russell Nelson's big-todo patch might help here. Others have used various schemes, such as injecting X at a time, pausing a minute or two in between injections to allow qmail to catch up with the todo contents, or trying first delivery with qmail-remote and only queuing the mail if that delivery fails, saving queue disk bandwidth. * I will give big-todo a try and see if there is any improvement. * > Once the application stopped pumping to the Qmail server, it started > processing and clearing queue, which took very long. You may be running into a queue disk bandwidth limitation. What sort of hardware are you using? Is the queue on a disk by itself? Is that disk a 15kRPM SCSI disk, sitting on its own U160 controller? Is that filesystem mounted noatime? What filesystem are you using? What OS? How are you logging? What does the system load reach while running your injection? Have you read the section on large servers at www.qmail.org? Is /var/log on a separate disk? --> The server we are using is a very ordinary machine with PIII 500, 128MB and an IDE on Red Hat Linux 6.0 with upgraded kernel. Logging is done exactly the same way mentioned in the HOWTO. We will distribute the load of SMTP using the LVS. The same test we ran on sendmail with the very similar machine was acceptable - sendmail didn't build up a huge queue - it processed all the mails. However, It was rather slow in accepting the message though. > Is it a normal behavior (since all the email addresses were non-existent) or > are we missing something somewhere? Concurrency is set to 120 for local and > remote. It's not trivial, but a million unique mails a day can be handled by qmail if you set it up properly. We just need _way_ more information than you've provided to start guessing at what your limiting factor(s) is. --> Anyways, Thank you very much again for your time. I greatly appreciate your suggestions. Regards, Mehul. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
big-todo patch
Greetings, I am looking for instructions on applying big-todo patch. It’s just a test server so I don need to worry about the existing queue. Would appreciate if some could help me or send me the link, which points to the instructions. Thanks in Advance, Mehul.
RE: Queue Building
1. We use multilog with option t s250 to the /var/log/qmail/qmail-send and /var/log/qmail/qmail-smtp (same hard drive and partition) - exactly same as mentioned in Adam McKenna's qmail-HOWTO v2 2. The test setup was run exactly same as the production; the only difference was the email- ids were non-existent. 3. Well, I think I misunderstood "sending unique mails Vs sending same mail to different addresses". Well, the application sends unique mails to different addresses with the same contents (the header changes each time since the "rcpt to:" changes in each mail, the body remains same) 4. I have applied the big-todo patch and set the conf-split to 40, we will be running the test later today. (Well, I am not sure whether I have applied it correctly - though I can see the todo directory having 40 sub directories) The only thing I can see now is the disk bandwidth problem, I will have to test it with better disks. Many thanks again for replying. I greatly appreciate the same. Regards, Mehul. -Original Message- From: Charles Cazabon [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 19, 2001 12:26 PM To: Qmail (E-mail) Subject: Re: Queue Building Mehul Choksi <[EMAIL PROTECTED]> wrote: > Thanks a lot for the reply. You're welcome. However, in future, could you set your email client up to use standard quoting conventions? The way you quoted my message made it extremely difficult to read and determine which parts you had added. I've fixed the quoting for this reply. > > Do you mean send identical copies of one message to a million users, or send > > one million unique emails, each to one user? The difference is enormous. > It depends, normally in batches of 100,000 to 300,000 identical mails > prepared by an application to be sent to subscribers. Currently we use a > pool of sendmail servers (ordinary PIII 500 with 128MB RAM and IDE). We are > planning to migrate to QMAIL eventually if we find better performance. 100,000 recipients each for 10 unique emails a day is trivial to do with qmail. However, your testing didn't actually test this. You sent thousands of unique messages to one or more recipients each, which is a completely different (and more difficult) queue load. Change your testing methods, and you'll see the difference. > > You may be running into a queue disk bandwidth limitation. What sort of > > hardware are you using? Is the queue on a disk by itself? Is that disk a > > 15kRPM SCSI disk, sitting on its own U160 controller? Is that filesystem > > mounted noatime? What filesystem are you using? What OS? > > > > How are you logging? What does the system load reach while running your > > injection? Have you read the section on large servers at www.qmail.org? > > Is /var/log on a separate disk? > The server we are using is a very ordinary machine with PIII 500, 128MB > and an IDE on Red Hat Linux 6.0 with upgraded kernel. Logging is done > exactly the same way mentioned in the HOWTO. I'm not familiar with the HOWTO you speak of. Does it use splogger to send the logs through syslog? If that's the case, syslog could be eating 90% of your CPU and 90% of your queue disk bandwidth, if the /var/log is on the same filesystem as /var/qmail/queue. You didn't answer any of these questions; we can't help you if you refuse to answer them. Basically, you want to ensure you're logging through multilog, not splogger, and sending the logs to a separate disk than the queue is on, for maximum performance. > We will distribute the load of SMTP using the LVS. The same test we ran on > sendmail with the very similar machine was acceptable - sendmail didn't > build up a huge queue - it processed all the mails. However, It was rather > slow in accepting the message though. But sendmail can be configured to try delivering the mail before queuing it; this is unreliable and can result in lost mail. We know nothing of your sendmail configuration (and probably don't want to know). Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
RE: Queue Building
Hi Again, We put the QMAIL server in the production to see its behavior; quickly the queue grew to 24000 (with big-TODO, conf-split is set to 44), we had to switch back to sendmail, which did the job well. Well, how do we optimize the QMAIL server to handle 300,000 unique outbound mails in a day? Many thanks in advance. Regards, Mehul. -Original Message- From: Charles Cazabon [mailto:[EMAIL PROTECTED]] Sent: Monday, April 23, 2001 3:56 PM To: Qmail (E-mail) Subject: Re: Queue Building Mehul Choksi <[EMAIL PROTECTED]> wrote: > 2. The test setup was run exactly same as the production; the only > difference was the email- ids were non-existent. This makes a big difference; the system trying to deliver to non-existent local or remote accounts will spend a lot of additional time and queue disk I/O injecting and delivering bounce messages. > 3. Well, I think I misunderstood "sending unique mails Vs sending same mail > to different addresses". Well, the application sends unique mails to > different addresses with the same contents (the header changes each time > since the "rcpt to:" changes in each mail, the body remains same) Yes, you're sending unique messages to each recipient. This puts a large load on the queue disk. Sending a single message to multiple recipients only requires queuing it once, while your method queues it separately for each recipient. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
