Zhiqiang::He

--
[Simon White. vim/mutt. simon@mtds.com. GIMPS:1.930% see www.mersenne.org]
If it dies, it's biology. If it blows up, it's chemistry, and if it
doesn't work, it's physics.
[Linux user #170823 http://counter.li.org. Home cooked signature rotator.]
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 2 in thread
寄件者：Brian Wizard (brian@xtnd.net)
主旨：Postfix Choking?

View this article only
新闻群组：mailing.postfix.users
日期：2002-10-07 04:20:25 PST

Greetings,

From what I have heard, postfix is supposedly a robust and scalable MTA.
In the past 24 hours I have loaded postfix on a server running FreeBSD
4.7-RC with dual 2 gig Xeon procs with 1 gig of RAM and an SMP kernel.
However, Postfix seems to be running out of resources as time goes on. I
am very new to Postfix and the only tuning options I have set in main.cf
are the following:

qmgr_message_active_limit = 7000
local_destination_concurrency_limit = 600
default_destination_concurrency_limit = 600
default_process_limit=600
process_limit=600

When I raise the process_limits/concurrency_limits to more than 600 the
server starts swapping for memory? And outputs the following message in
/var/log/messages:

Oct 7 08:38:39 server1 postfix/trivial-rewrite⁴⁸⁸¹⁰: fatal: accept
connection: Too many open files

If I leave the settings the way they are, postfix takes a long
time to respond on port 25 (more than 1 minute) after it has been running
for a few hours.

I have played with many kernel settings and nothing seems to help, could
this just be a limitation on Postfix? This server is processing close to 2
million emails/day.

I don't think postfix should need more than this...

root@server1:~# su - postfix
postfix@server1:~% ulimit -n
39218

I have maxfiles set to the maximum amount in the kernel as well.

root@server1:~# sysctl kern.maxfiles
kern.maxfiles: 65536

Has anyone run into a situation such as this before? Or can anyone make a
suggestions as far what optimization settings should be incorporated into
postfix for email systems with high loads? BTW, I have been running qmail
with no problems, but I would really like to switch to postfix if at all
possible. Thanks for your help.

Brian Wizard

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 3 in thread
寄件者：Ralf Hildebrandt (Ralf.Hildebrandt@charite.de)
主旨：Re: Postfix Choking?

View this article only
新闻群组：mailing.postfix.users
日期：2002-10-07 04:26:03 PST

On Mon, Oct 07, 2002 at 12:54:49AM -1000, Brian Wizard wrote:

> When I raise the process_limits/concurrency_limits to more than 600 the
> server starts swapping for memory?

Shit happens. I guess you can never have enough RAM, can you?

> Oct 7 08:38:39 server1 postfix/trivial-rewrite⁴⁸⁸¹⁰: fatal: accept
> connection: Too many open files

The kernel cannot handle that many open files.

--
Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt@charite.de
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
Why you can't find your system administrators:
(S)he's out buying some caffeine.

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users

寄件者：Chris Laco (claco@summitracing.com)
主旨：RE: Postfix Choking?

View this article only
新闻群组：mailing.postfix.users
日期：2002-10-07 06:36:16 PST

Have you done this stuff yet?
http://www.daemonnews.org/200108/benchmark.html

寄件者：lst_hoe (lst_hoe@kwsoft.de)
主旨：Re: Postfix Choking?

View this article only
新闻群组：mailing.postfix.users
日期：2002-10-07 07:34:01 PST

At 10:10 07.10.2002 -0400, Victor.Duchovni@morganstanley.com wrote:
>Two million messages a day is a high load: average of 23 messages per
>second, with presumably much higher peaks during the day. How high are
>the peaks? Are you sure your I/O subsystem is up to the task. What maps
>are you using for your transport table? Figure out the expected query rate
>(at least 3 per recipient, more if you are using the snapshot release) and
>query latency. Make sure that queries against the transport table can be
>completed in ~5ms (1000/23/10) perhaps less if the intra business day mail
>flow is substantially higher than 23 msgs/sec.
>
>Consider mjt's CDB patch for as many maps as possible. Show output of
>"postconf -n".

May i raise some questions :

Where do this mails go to?
Who has that great volume in the pacific provider area (xtnd.net)?
What kind of people who don′t even read the FAQ try to process 2 million
mails a day?
Strange sender-name, maybe related to this one http://www.brianwizard.com/ :-)

Regards

--

Andreas H?dle

Kühn & Weyh Software GmbH

WWW.KWSOFT.DE

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 6 in thread
寄件者：Victor.Duchovni@morganstanley.com (Victor.Duchovni@morganstanley.com)
主旨：Re: Postfix Choking?

View this article only
新闻群组：mailing.postfix.users
日期：2002-10-07 07:52:03 PST

On Mon, 7 Oct 2002, Brian Wizard wrote:

> qmgr_message_active_limit = 7000

Don't lower this. If your machine has enough memory raise it to 20000 or
more, but not to solve this problem. It is unrelated to throughput.

> local_destination_concurrency_limit = 600
> default_destination_concurrency_limit = 600

Don't raise these.

> default_process_limit=600

Try 200-400.

> process_limit=600
>

This is not a postfix configuration parameter.

>
> When I raise the process_limits/concurrency_limits to more than 600 the
> server starts swapping for memory? And outputs the following message in
> /var/log/messages:
>
> Oct 7 08:38:39 server1 postfix/trivial-rewrite⁴⁸⁸¹⁰: fatal: accept
> connection: Too many open files
>

The trivial-rewrite daemon cannot handle that many concurrent connections.
You must be using very slow maps. Is LDAP or MySQL used for the transport
table by any chance? Keep the transport table fast, don't use slow
transport maps.

> If I leave the settings the way they are, postfix takes a long
> time to respond on port 25 (more than 1 minute) after it has been running
> for a few hours.

See above.

>
> I have played with many kernel settings and nothing seems to help, could
> this just be a limitation on Postfix? This server is processing close to 2
> million emails/day.
>

Two million messages a day is a high load: average of 23 messages per
second, with presumably much higher peaks during the day. How high are
the peaks? Are you sure your I/O subsystem is up to the task. What maps
are you using for your transport table? Figure out the expected query rate
(at least 3 per recipient, more if you are using the snapshot release) and
query latency. Make sure that queries against the transport table can be
completed in ~5ms (1000/23/10) perhaps less if the intra business day mail
flow is substantially higher than 23 msgs/sec.

Consider mjt's CDB patch for as many maps as possible. Show output of
"postconf -n".

--
Viktor.

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
Message 7 in thread
寄件者：Victor.Duchovni@morganstanley.com (Victor.Duchovni@morganstanley.com)
主旨：Re: Postfix Choking?

View this article only
新闻群组：mailing.postfix.users
日期：2002-10-07 11:50:03 PST

On Mon, 7 Oct 2002, Brian Wizard wrote:

>
>
> Hi Victor,
>
> Thanks for the helpful response. What you said sounds right, we have over
> 10,000 entries in a flat shadow file and trivial rewrite is probably
> choking there. So hashing the passwd file into a CDB should help you
> think? Thanks

No. Trivial rewrite does not consult the password file. It uses
"transport_maps" if set, but you do not set up transport_maps, so
trivial-rewrite is being starved for other reasons, see below, but do you
have enough disk I/O to handle the load? What is the nature of the
traffic, why are you processing 2 million messages a day. Are they inbound
or outbound?

> default_destination_concurrency_limit = 600

Lose this, leave set to default.

> default_process_limit = 600

Lower this (Try 400 or 200).

> local_destination_concurrency_limit = 600

Defitely don't do this! This is 600 concurrent connections to a
single mailbox! Leave at the default value of 2.

> local_recipient_maps = $alias_maps unix:passwd.byname

If your password file is not hashed (nsswitch.conf) and has 10,000
entries, this may cost you a lot here by substantially increasing
"smtpd" concurrency. Make sure to configure a fast random access path to
your user database. If you can't do this system-wide, create a separate
hashed database for use by Postfix and replace unix:passwd.byname with
hash:... (or CDB for even better performance).

> maps_rbl_domains = relays.visi.com

Is this providing timely responses? If not dump it and use someone who
does.

> qmgr_message_active_limit = 7000

Raise this to 20000 or leave the default alone at 10000

> smtpd_banner = $myhostname postfix

Why not leave the default alone. Putting "ESMTP" in the banner increases
the probability that the sender will use ESMTP and hence
predeclared size limits with pipelining.

--
Viktor.

Wietse关于Postfix优化的看法

寄件者：Wietse Venema (wietse@porcupine.org)
主旨：Re: 1.000.000 email posted in a single delivery process
View: Complete Thread （共有 46 条留言）
Original Format
新闻群组：mailing.postfix.users
日期：2001-09-26 14:14:54 PST

If you want to deliver 1000000 queue files in 3 hours, that is 10
milliseconds per file. That seems a bit optimistic to me, considering
the latencies of real disks (every file needs to be read from disk,
the cache is cold) and of real networks (having a local DNS server
should really make a difference).

Neither qmail nor Postfix currently has connection caching, which
can make a difference sending mail to sites that have slow servers.

0 - In the /etc/syslog.conf file, put a - in front of the maillog
filename, so that the stupid syslogd does not hammer the disk
after writing each logfile record.

1 - The default settings of two levels of directory hashing in the
queue should suffice. If you disagree, change this with:

postconf -e hash_queue_depth=3
postfix reload

2 - Configure an adequate number of delivery agents in the master.cf
file: 500+. On your typical Linux box, this will run the kernel
out of resources and Postfix will slam on the brakes until you
fix it.

3 - Test the setup with the smtp-source and smtp-sink programs.
For the test, specify a relayhost name that points to the
smtp-sink program, and send messages with thousands of recipients
into Postfix, and have Postfix perform one-recipient deliveries.

On the Postfix host:

postconf -e relayhost=smtp-sink.host:9999 \
smtp_destination_recipient_limit=1

On the mail sink host (can be same as postfix host, if you have
enough memory and process slots and space for open files):

./smtp-sink -c :9999 1000

On the smtp-source host (can be same as postfix host):

./smtp-source -c -m 1000 -s 10 -r 10000 -t foo@postfix.host postfix.host

Postfix breaks up the deliveries into transactions of 1 recipient
each, so one message with 10000 recipients will keep lots of
delivery agents busy.

4 - Before submitting the real mail:

postconf -e defer_transports=smtp relayhost= \
smtp_destination_recipient_limit=\$default_destination_recipient_limit
postfix reload

(and don't let anyone execute a "sendmail -q" command).

5 - SUBMIT THE MAIL VIA SMTP, not via /usr/sbin/sendmail. Otherwise
you are throwing away all the performance.

6 - On Doomsday,

postconf -e defer_transports=
postfix reload
sendmail -q

7 - From here on, do not touch the box. Each time you stop or reload
Postfix, or do a sendmail -q, it slows down dramatically.

Wietse

Alexander:
> (I've posted this message in QMAIL and EXIM mailing list.
> Many people say me that POSTFIX can do a good work)
>
> This is a case study and it's NOT for create a spamming system or other
> terrible mail bombing system.
> I HATE them !
>
> Title: the best mode to deliver 1.000.000 email messages (recipient are ALL
> different and email are ALL different) in few hours during a single delivery
> session.
>
> You suppose to have a SMP Linux server (i.e. dual P-III 800 Mhz, 512 MB Ram,
> SCSI Raid 5, kernel 2.4.9 and RaiserFS) and a good internet connection (4
> Mbit/sec full bandwidth) and a fast DNS server near me.
>
> During the night a program running on the same server creates 1 million of
> email (getting user data and infos data from a SQL DB).
> This process need about 3 hours. Meanwhile email are created, they are
> "injected" in MTA queue (i.e. using qmail-inject or
> exim -odq -t) and they are NOT delivered: they stay in queue.
> The email are all different but short: about 800-1000 bytes each and the
> recipients are all different and are all remote.
> Yes, we can have a vary big number of different recipient domain but
> statistically we also have a large number of email directed on mass email
> system (Hotmail, Yahoo...)
>
> So 1.000.000 × 1.000 bytes = 1 GBytes data. Yes, like a technical
> information email system with personalized info for each recipient.
>
> Then every day at 8.00 AM the remote delivery needs to start (exim -q ,
> qmail-remote) and delivery is done once per day.
>
> Target: send 1 million of email in a very short time, shortest as possibile,
> it must end as soon as possibile. Bandwidth occupation is not a problem: we
> can use all 4 Mbit/sec (about 1 GB / 500 Kbytes/sec = about 2000 seconds , 1
> hour and few minutes. 2 or 3 hours are ok anyway).
>
> And now the questions:
>
> 1) QMAIL vs EXIM vs POSTFIX: which is the best MTA to manage 1.000.000 email
> in queue ?
> (EXIM with option "split_spool_directory" and QMAIL patched to have a more
> "deep" in queue tree, POSTIFIX ??)
>
> 2) EXIM can deliver all messages during a single SMTP session to the same
> email system (useful for mass system like HOTMAIL,YAHOO, ....), QMAIL no.
> Is it faster to have either for example 300 (more or less) qmail-remote
> process running and sending 1 messages each or for example 20 (more or
> less) "exim -q" process running sending more messages in a single SMTP
> connection ? Remember: the target is to use less time than possible.
>
> Thanks for any suggestion about.
> POSTFIX ,I've never used it, can be an alternative ?
>
>
>

另外一个人的性能调整建议，不过是产品化的建议。不错！虽然有些我不同意。

寄件者：Liviu Daia (Liviu.Daia@imar.ro)
主旨：Re: 1.000.000 email posted in a single delivery process

View this article only
新闻群组：mailing.postfix.users
日期：2001-09-27 02:11:08 PST

On 27 September 2001, Liviu Daia wrote:
[...]
> For a today's PC, something like 40-50 messages / second would still
> be an optimistic estimate;

That is, over a LAN. Expect a much lower rate over Intermet,
because of dead or slow destinations.

> that's about 6 times slower that what you want.

Regards,

Liviu Daia

--
Dr. Liviu Daia e-mail: Liviu.Daia@imar.ro
Institute of Mathematics web page: http://www.imar.ro/~daia
of the Romanian Academy PGP key: http://www.imar.ro/~daia/daia.asc
-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users
第 9 条留言
寄件者：Liviu Daia (Liviu.Daia@imar.ro)
主旨：Re: 1.000.000 email posted in a single delivery process

View this article only
新闻群组：mailing.postfix.users
日期：2001-09-27 02:11:20 PST

On 26 September 2001, Alexander wrote:
[...]
> Title: the best mode to deliver 1.000.000 email messages (recipient
> are ALL different and email are ALL different) in few hours during a
> single delivery session.
>
> You suppose to have a SMP Linux server (i.e. dual P-III 800 Mhz, 512
> MB Ram, SCSI Raid 5, kernel 2.4.9 and RaiserFS) and a good internet
> connection (4 Mbit/sec full bandwidth) and a fast DNS server near me.

Wietse already explained how to setup Postfix for best performance.
Here's an additional checklist, mainly for the rest of the system:

- if possible, use OpenBSD or FreeBSD with softupdates rather than
Linux;
- if you insist on using Linux, use a 2.2.x kernel, not a 2.4.x one, and
turn OFF the swap; buy more RAM if you feel you're running out of it;
- use RAID 0+1, not 5, and (if you have that choice) mirror the stripes
instead of striping the mirrors;
- use ext2; Xfs and Jfs are not yet ready for prime time, and everything
else is slower than ext2 for mail handling;
- install a caching DNS on the SAME machine as the mail server, a nearby
one is not good enough; use djbdns for that instead of bind; turn off
logging for lookups, and give it plenty of memory to keep the cache;
- if you trust your UPS, turn off sync writes to the queue
("chattr -R -S /var/spool/postfix")
- if possible, send the logs to another machine instead of writing them
to a local file, or at least put the logs on different disk spindles
than the queue;
- apply Michael Tokarev's patch for CDB maps, and use CDB maps instead
of hash.

(I'm sure I forgot a few things too.)

[...]
> Target: send 1 million of email in a very short time, shortest as
> possibile, it must end as soon as possibile. Bandwidth occupation is
> not a problem: we can use all 4 Mbit/sec (about 1 GB / 500 Kbytes/sec
> = about 2000 seconds , 1 hour and few minutes. 2 or 3 hours are ok
> anyway).
[...]

As Wietse said, that's overly optimistic. With careful tuning,
Postfix would perform better than Exim and Qmail, but IMHO, no MTA would
be able to send 1 million messages in an hour, even over a LAN. No
offense intended, but people who set themselves such a target have never
managed a mail systems in the real world. For a today's PC, something
like 40-50 messages / second would still be an optimistic estimate;
that's about 6 times slower that what you want.

Regards,

Liviu Daia

寄件者：Wietse Venema (wietse@porcupine.org)
主旨：Re: 1.000.000 email posted in a single delivery process

View this article only
新闻群组：mailing.postfix.users
日期：2001-09-27 06:45:59 PST

Matthias Andree:
> Well, in a LAN, it might actually be possible to get half a million
> mails through per hour without extensive tuning - however, that's
> without VERP and it assumes your destination machines are FAST.

To give you a data point: running smtp-source against smtp-sink
on a 750MHz pentium FreeBSD 4.3 machine without going over a LAN,
with 100 parallel connections:

tail% /usr/bin/time ./smtp-source -d -m 1000 -s 100 tail:9999
1.21 real 0.06 user 0.50 sys

That's 1 million messages in 20 minutes.

Same email load, two hosts connected by a 100BaseT ethernet switch,
target is P550 FreeBSD 4.1, with 100 parallel connections:

tail% /usr/bin/time ./smtp-source -d -m 1000 -s 100 spike:9999
1.05 real 0.06 user 0.23 sys

The times are pretty much comparable.

Do not expect anything near this performance with a queue on rotating
disk drives, though.

Wietse

使用内存RAM来提高Postfix的性能

如何使用TRAM提高你计算机的速度？英文的哦。不过太恐怖了。用ram。。
TRAM

以下是邮件列表的一个人说的话，确实是“化整为零”将负载分布到廉价的*nix box
============
寄件者：Craig Sanders (cas@taz.net.au)
主旨：Re: Making postfix faster?

View this article only
新闻群组：mailing.postfix.users
日期：2001-07-05 21:54:15 PST

On Thu, Jul 05, 2001 at 08:08:28PM -0400, Myke Olson wrote:
> Does anyone have any suggestions on making Postfix faster at sending mail?
> [...]
> We're running the latest version on a Sun Ultra1/140 and are only able
> to send about 160 emails/minute.

for this application, you may be better of with lots of cheap little
linux or freebsd boxes running postfix than one big Sun box.

one of the best ways is to have multiple cheap boxes rather than one big
expensive box.

this may require modifying your mailing list software so that it sends
part of each list to different machines. e.g. if you have 5 postfix smtp
sender boxes, then split the list in 5.

if you send individual messages to each subscriber rather than one message
bcc-ed to everyone then you could use a load balancer to spread the mail
load across multiple machine. e.g. linux virtual server (LVS) makes an
excellent load balancer - http://www.linuxvirtualserver.org/

alternatively, use a large RAID array of as many disks as you can
afford. the more drives in the array, the better. e.g. if you want 72GB
of total space, it is much faster to have 8 × 9GB drives than 2 × 36GB,
or 4 × 18GB.

a solid-state disk (SSD) will be even faster than a raid array.

the way to scale up a disk I/O-bound application (such as sending to
enormous mailing lists) is to speed up the disk by adding more physical
disks and/or more machines or by using faster disks (e.g. SSDs).

combining the alternatives above will get even better results - e.g. an
array of 5 linux + postfix boxes, each with a 1GB SSD queue drive.

> Some ideas that I had were to somehow make it give up on the first
> try if the DNS record for a particular host didn't exist (i.e. a user
> signed up with jdflkl@kjdjdflk.com as their email address) or somehow
> moving the spool directory into a RAM disk. But I couldn't figure out
> how to do that....

you could do that if you didn't care whether the messages got lost if
the system crashed or lost power.

a safer alternative is to use a non-volatile solid-state disk for the
postfix queue. in essence, they're a RAM disk with a battery backup
and a SCSI interface, in a standard disk form factor. they cost a
fortune, though, for any reasonable size....several thousand dollars per
gigabyte, last time i looked into them.

if 1 or 2 GB is enough for your postfix queue, then an SSD may be your
best option.

craig

第 5 条留言
寄件者：Len Conrad (LConrad@Go2France.com)
主旨：Re: Multiple frontend Postfix - One RAID5 storage

View this article only
新闻群组：mailing.postfix.users
日期：2003-01-14 06:47:20 PST

>mailserver-front--│
>mailserver-front--│--> store spool on 1 raid5 dev, seperate spools
>mailserver-front--│

It sounds like your are getting ready for very high volumes, so why have
you chosen the RAID that is slowest for writing? RAID1 has faster writing.

And of course going across a network to the spool dir is horribly slower
than local disk i/o.

RAID5 is fine for database work where read:write it 90:10, but mail is
closer to 50:50.

构筑高可靠的app，这个东西可以做个随时监测smtp 机器的mon。。不错不错。
Wackamole