* Steve Jenkins <stevejenk...@gmail.com>: > QSHAPE is one tool we were already using, and the good news is that > even during a send process (one of which is going on right now), the > active queue is generally very small. Like so:
The output looks very good. No room for optimization! > We do this one, because each message is unique (has to have an > individual unsub link and contains the subscriber's name) Good! > As far as parallel submissions, we're only doing three at a time > (three SwiftMail processes sending at a time). Our in_flow_delay > parameter is set to 0. We aren't receiving a lot of mail on this box, > so I'm not sure that delay would even kick in if it were set to the 1s > default. Beyond this, we're not sure how to check to see if the disk > is being "overwhelmed with mail submissions." Out iowait% is 0.23, so > the CPU isn't waiting for the disk. How else can we tell if we're > overwhelming the disk? When you're overwhelming the disk, all IO would be dedicated to accepting the mail from SwiftMail, not Sending the Mail out. > We're not really seeing problematic destinations. The mail is getting > delivered right away when we attempt to deliver. it's just that our > attempts don't seem to happen very quickly. Maybe your upstream network link is saturated? > Before we just blindly throw bigger hardware at the issue, we'd still > love some ideas to help research what else could be slowing us down. default_process_limit is set to what? -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
