Emanuel writes:
Can the files header/body_checks generate overload?
On 19.04.18 00:05, micah wrote:
Yes.
I recently tried to load the malware patrol header check list, which has
49349 lines as a regexp body check, and I quickly had to stop doing that
because the resource usage of the machine
On 19 April 2018 at 07:21, Peer Heinlein wrote:
>
> You can save a lot of cpu ressources if you use...
>
> ...pcre instead of regexp (mostly the syntax is the same, but the engine
> is better, just change the prefix!)
Check if supported with:
# postconf -m|grep pcre
pcre
If using the standard po
Am 18.04.2018 um 20:51 schrieb Emanuel:
> Can the files header/body_checks generate overload?
If you have many header/body_checks you'll see a higher usage of the
cleanup process in tools like "top".
You can save a lot of cpu ressources if you use...
...pcre instead of regexp (mostly the syntax
Emanuel writes:
> Can the files header/body_checks generate overload?
Yes.
I recently tried to load the malware patrol header check list, which has
49349 lines as a regexp body check, and I quickly had to stop doing that
because the resource usage of the machine quickly went into a state
where
> On Apr 18, 2018, at 2:51 PM, Emanuel wrote:
>
> smtpd_recipient_limit = 20
RFC5321 requires at least 100. Unnecessarily splitting the envelope does not
help performance.
--
Viktor.
Emanuel:
> Can the files header/body_checks generate overload?
I have not seen evidence that the cleanup daemon is responsible for
a performance issue. Absent meaningful info, no support.
Wietse
Can the files header/body_checks generate overload?
Postfix configuration:
default_process_limit = 300
smtpd_client_connection_count_limit = 2000
smtpd_recipient_limit = 20
Any information you give me is helpful.
El 18/04/18 a las 14:00, Wietse Venema escribió:
Limit the number of processe
Emanuel:
[ Charset windows-1252 converted... ]
> Hello everyone, I'm representing a performance problem on my server.
>
> I explain in detail the configuration of my server.
>
> I am using postfix with 46 IPs configured as a mta, with round-robin, in
> the master.cf file
>
> I think the "cleanu
El 18/04/18 a las 12:03, Matus UHLAR - fantomas escribió:
On 18.04.18 11:00, Emanuel wrote:
Hello everyone, I'm representing a performance problem on my server.
I explain in detail the configuration of my server.
I am using postfix with 46 IPs configured as a mta, with round-robin,
in the m
On 18.04.18 11:00, Emanuel wrote:
Hello everyone, I'm representing a performance problem on my server.
I explain in detail the configuration of my server.
I am using postfix with 46 IPs configured as a mta, with round-robin,
in the master.cf file
46 IPs? why?
I think the "cleanup" process
Hello everyone, I'm representing a performance problem on my server.
I explain in detail the configuration of my server.
I am using postfix with 46 IPs configured as a mta, with round-robin, in
the master.cf file
I think the "cleanup" process is responsible for the excessive use of cpu.
ps f
Jonathan K. Tullett:
> On 21 December 2014 at 13:56, Wietse Venema wrote:
> >
> > > Since the end of October, that number has dropped to 16 a second
> > > on a good day.
> >
> > What has changed? Obiously, Postfix didn't change, and replacing
> > Postfix isn't going to make a difference.
> >
>
>
On Sun, Dec 21, 2014 at 09:13:53AM +, Jonathan K. Tullett wrote:
> Have there been huge improvements to the efficiency of the code base
> between 2.6 and 2.9 (or 2.11)? Does anyone have suggestions on where else
> I can look for the cause?
>
> Thank you in advance for any help you can provid
On 12/21/2014 3:13 AM, Jonathan K. Tullett wrote:
> Greetings,
>
> I've been using Postfix for many years - since about 2002 - and I've
> finally come across a problem I've not been able to resolve by
> searching online, or from tapping into my personal network. So I
> have come to you all for hel
Christian R??ner:
> Prior to the last week of October using the distribution manager,
> it was possible on machine A to inject around 25 messages (full
> size - about 70k each) a second into the maildrop queue.
>
> Since the end of October, that number has dropped to 16 a second
> on a good day.
W
> Am 21.12.2014 um 10:13 schrieb Jonathan K. Tullett
> :
>
> Greetings,
>
> I've been using Postfix for many years - since about 2002 - and I've finally
> come across a problem I've not been able to resolve by searching online, or
> from tapping into my personal network. So I have come to you
Greetings,
I've been using Postfix for many years - since about 2002 - and I've
finally come across a problem I've not been able to resolve by searching
online, or from tapping into my personal network. So I have come to you all
for help.
I have two machines:
Machine A: My primary 8 core Xeon 2.2
On 26 Jul 2014, at 01:42, McKinnon Chris wrote:
> I’ve done some testing with swaks trying to track my performance issue. I
> don’t think this is a postfix issue. It is just the most apparent symptom.
> I’ve also noticed SSH to my server is quite laggy but if I use the command
> line with S
Hi,
I’ve done some testing with swaks trying to track my performance issue. I
don’t think this is a postfix issue. It is just the most apparent symptom.
I’ve also noticed SSH to my server is quite laggy but if I use the command line
with Screen Sharing it is responsive. Same with SFTP, some
On 24 Jul 2014, at 06:37, McKinnon Chris wrote:
> I checked for “connect from unknown” errors coming from the client IPs in
> mail.log and I’m not seeing any. The only warning I see for one client is:
>
> Jul 23 19:21:54 ravenviewhomes.com postfix/smtpd[61133]: warning:
> fqdn_hidden[ip_hidde
I checked for “connect from unknown” errors coming from the client IPs in
mail.log and I’m not seeing any. The only warning I see for one client is:
Jul 23 19:21:54 ravenviewhomes.com postfix/smtpd[61133]: warning:
fqdn_hidden[ip_hidden]: SASL PLAIN authentication failed:
Jul 23 19:22:39 raven
McKinnon Chris:
> Hi Wietse,
>
> Concerning #1, I checked the mail.log and I'm seeing the following
> warnings (many times):
>
> postfix/smtpd[71979]: warning: hostname static.vdc.vn does not resolve to
> address 113.160.154.177
> postfix/smtpd[72386]: warning: hostname bamovil-181-135-42-61.une
Hi Wietse,
Concerning #1, I checked the “mail.log” and I’m seeing the following warnings
(many times):
postfix/smtpd[71979]: warning: hostname static.vdc.vn does not resolve to
address 113.160.154.177
postfix/smtpd[72386]: warning: hostname bamovil-181-135-42-61.une.net.co does
not resolve to
McKinnon Chris:
> Hi,
>
> I'm experience performance issues with a Postfix installation I
> setup on a Mac OS X server. Originally it was OS 10.7.4 and Postfix
> 2.9.4, which worked very well. I was using a relatively stock
Simple questions:
(1) Have you looked at the system logfile for Postf
Hi,
I’m experience performance issues with a Postfix installation I setup on a Mac
OS X server. Originally it was OS 10.7.4 and Postfix 2.9.4, which worked very
well. I was using a relatively stock Postfix configuration with a MySQL
backend. There are only 2 serious users on the mail server
Le 25/03/2011 15:55, Steve Jenkins a écrit :
> On Fri, Mar 25, 2011 at 5:20 AM, Stan Hoeppner wrote:
>> You simply need a caching resolver on an MX/outbound, not a zone server.
>> A zone server is useless in this case.
>
> Yep - I know that now. :)
>
>> I use PowerDNS Recursor on my MX/outbound
> I installed both pdns-recursor and unbound (running without any zone
> data) on a test box and got very similar performance results from
> both. We happened to go with unbound, but based on your
> recommendation, maybe I'll give pdns-recursor another look (it's still
> running on our test box).
On Fri, Mar 25, 2011 at 5:20 AM, Stan Hoeppner wrote:
> You simply need a caching resolver on an MX/outbound, not a zone server.
> A zone server is useless in this case.
Yep - I know that now. :)
> I use PowerDNS Recursor on my MX/outbound and never had a problem.
> Under Debian it's a 3 minute
Steve Jenkins put forth on 3/23/2011 7:22 PM:
> On Wed, Mar 23, 2011 at 5:09 PM, Joe wrote:
>> IMNSHO it's standard practice to run a dns server on the MX host. If you
>> don't want a full blown bind server, at least run some sort of caching dns
>> server; the difference in the lookup times has a
Jeroen van Aart put forth on 3/23/2011 5:06 PM:
> I am curious if postfix would be able to send out 30 emails in one
> hour, to different recipients of course.
How are you injecting the 30k emails into Postfix? Mailing list manager
or other means? Via SMTP or the local sendmail command?
--
On Thu, Mar 24, 2011 at 12:07:06PM -0700, Steve Jenkins wrote:
> On Thu, Mar 24, 2011 at 10:34 AM, Victor Duchovni
> wrote:
> > If all you changed was adding a local DNS cache, unless your previous
> > cache was >100ms away, you'll not see much change.
>
> Actually, after doing some tests with d
On Thu, Mar 24, 2011 at 10:34 AM, Victor Duchovni
wrote:
> If all you changed was adding a local DNS cache, unless your previous
> cache was >100ms away, you'll not see much change.
Actually, after doing some tests with dig on our colo provider's DNS
servers we noticed that they were taking an av
On Thu, Mar 24, 2011 at 09:41:25AM -0700, Steve Jenkins wrote:
> On Thu, Mar 24, 2011 at 8:28 AM, Victor Duchovni
> wrote:
> > A LAN DNS server with a 2ms lookup delay is fine. Unbound, bind, ...
> > does not matter.
>
> Thanks for all the nudges in the right direction. We're now running
> Unbou
On Thu, Mar 24, 2011 at 8:28 AM, Victor Duchovni
wrote:
> A LAN DNS server with a 2ms lookup delay is fine. Unbound, bind, ...
> does not matter.
Thanks for all the nudges in the right direction. We're now running
Unbound on the same box as Postfix, getting cached responses in 0 msec
from the Pos
On Thu, Mar 24, 2011 at 09:28:21AM +0100, lst_ho...@kwsoft.de wrote:
>> Thx, Joe. Any advantage IYNSHO to running a full blown bind server as
>> opposed to something simpler like dnsmasq or nsd (or anything else
>> you're recommend)?
> Most of the time "simple" caching resolvers are faster at cor
Zitat von Steve Jenkins :
On Wed, Mar 23, 2011 at 5:09 PM, Joe wrote:
IMNSHO it's standard practice to run a dns server on the MX host. If you
don't want a full blown bind server, at least run some sort of caching dns
server; the difference in the lookup times has a big impact when you're
send
* Jeroen van Aart :
> I am curious if postfix would be able to send out 30 emails in
> one hour, to different recipients of course. Taking into account
> http://www.postfix.org/TUNING_README.html and other such performance
> tuning guides. This would only happen once a week or so. The
> importa
Jeroen van Aart:
> Victor Duchovni wrote:
> > - The destination networks are not throttling your output or
> > severely limiting your concurrency.
>
> > A lot depends on where the mail is going and the concurrency limits and
> > delivery latencies of those destinations.
>
> Thanks all f
Victor Duchovni wrote:
- The destination networks are not throttling your output or
severely limiting your concurrency.
A lot depends on where the mail is going and the concurrency limits and
delivery latencies of those destinations.
Thanks all for some helpful information.
I see
On Wed, Mar 23, 2011 at 05:22:49PM -0700, Steve Jenkins wrote:
> On Wed, Mar 23, 2011 at 5:09 PM, Joe wrote:
> > IMNSHO it's standard practice to run a dns server on the MX host.
> > If you don't want a full blown bind server, at least run some
> > sort of caching dns server; the difference in t
On 03/23/2011 05:22 PM, Steve Jenkins wrote:
On Wed, Mar 23, 2011 at 5:09 PM, Joe wrote:
IMNSHO it's standard practice to run a dns server on the MX host. If you
don't want a full blown bind server, at least run some sort of caching dns
server; the difference in the lookup times has a big impac
On Wed, Mar 23, 2011 at 5:09 PM, Joe wrote:
> IMNSHO it's standard practice to run a dns server on the MX host. If you
> don't want a full blown bind server, at least run some sort of caching dns
> server; the difference in the lookup times has a big impact when you're
> sending messages at a high
On 03/23/2011 04:49 PM, Steve Jenkins wrote:
On Wed, Mar 23, 2011 at 3:22 PM, Victor Duchovni
wrote:
All of this is overkill, but a local DNS resolver is a requirement.
With high volume outbound mail, any advantage to having a local DNS
resolver on the same machine as Postfix? We've got one t
On Wed, Mar 23, 2011 at 3:22 PM, Victor Duchovni
wrote:
> All of this is overkill, but a local DNS resolver is a requirement.
With high volume outbound mail, any advantage to having a local DNS
resolver on the same machine as Postfix? We've got one that's provided
by our colo provider, but it's n
On Wed, Mar 23, 2011 at 11:19:24PM +0100, Matthias Andree wrote:
> Consider server-class SLC SSD if needed
No need. Perfectly ordinary drives with a battery RAID controller will
do just fine. If the messages are 10kB or less, 100/sec gives 1MB/s which
is also not a problem for typical server netw
Am 23.03.2011 23:06, schrieb Jeroen van Aart:
> I am curious if postfix would be able to send out 30 emails in one
> hour, to different recipients of course. Taking into account
> http://www.postfix.org/TUNING_README.html and other such performance
> tuning guides. This would only happen once a
On Wed, Mar 23, 2011 at 03:06:04PM -0700, Jeroen van Aart wrote:
> I am curious if postfix would be able to send out 30 emails in one
> hour, to different recipients of course. Taking into account
> http://www.postfix.org/TUNING_README.html and other such performance tuning
> guides. This w
On 03/23/2011 03:06 PM, Jeroen van Aart wrote:
I am curious if postfix would be able to send out 30 emails in one
hour, to different recipients of course. Taking into account
http://www.postfix.org/TUNING_README.html and other such performance
tuning guides. This would only happen once a we
I am curious if postfix would be able to send out 30 emails in one
hour, to different recipients of course. Taking into account
http://www.postfix.org/TUNING_README.html and other such performance
tuning guides. This would only happen once a week or so. The important
part is the need to sen
Teh Kim Chooi:
> i test the command today, and found out that it only takes 1.5 secs, nothing
> change from the 5 secs result. I add the 192.168.1.10 to my /etc/hosts file,
> and it drop to 0.5 secs to inject 100 msgs.
No surprise.
> 1. Question here, if the sender IP is not in my /etc/hosts, wil
i test the command today, and found out that it only takes 1.5 secs, nothing
change from the 5 secs result. I add the 192.168.1.10 to my /etc/hosts file,
and it drop to 0.5 secs to inject 100 msgs.
1. Question here, if the sender IP is not in my /etc/hosts, will postfix do
a reverse lookup on the
Teh Kim Chooi:
> It sounds weird to me, the 192.168.1.10 is on server eth0 network interface,
> and it will be on my local etc host file, will postfix still do NSlookup ?
The Postfix SMTP server looks up the client hostname with the
getnameinfo() system library routine.
I have attached a test pro
It sounds weird to me, the 192.168.1.10 is on server eth0 network interface,
and it will be on my local etc host file, will postfix still do NSlookup ?
since i try inject 100 msgs, there is not time out 5 secs then only start
injecting for the 100 msgs, the 5 secs is the time for 100 msgs to injec
Teh Kim Chooi:
[ Charset ISO-8859-1 unsupported, converting... ]
> Hi guys,
>
> i recently just setup a high volume postfix server, still in testing mode
> before the server go for live, OS rhel 5.5 and postfix version 2.3.3
Which is no longer maintained. The last release was postfix-2.3.19
in Au
On 05/31/2010 08:50 PM, Teh Kim Chooi wrote:
Hi guys,
i recently just setup a high volume postfix server, still in testing
mode before the server go for live, OS rhel 5.5 and postfix version 2.3.3
server with 1 quad core, 8gb ram OS on mirror disk, /var/spool/postfix
in 1+0 6 disks, all is S
Hi guys,
i recently just setup a high volume postfix server, still in testing mode
before the server go for live, OS rhel 5.5 and postfix version 2.3.3
server with 1 quad core, 8gb ram OS on mirror disk, /var/spool/postfix in
1+0 6 disks, all is SAS 15k disk.
my postfix configuration file will b
I spoke too soon
Mark Johnson wrote:
> hopcount_limit = 500
>
This seems a bit unreasonable due to this exists to stop mail loops and
overload.
The default of 50 works in many, many situations.
> maximal_queue_lifetime = 5h
>
Why so short?
This can generate many, many bounces due to tr
u have a DNS caching server locally?
>
>
> --- On Mon, 8/17/09, Barney Desmond wrote:
>
>
>> From: Barney Desmond
>> Subject: Re: postfix performance
>> To: postfix-users@postfix.org
>> Date: Monday, August 17, 2009, 3:49 PM
>> 2009/8/18
/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
unknown_local_recipient_reject_code = 550
Thanks.
--- On Mon, 8/17/09, Barney Desmond wrote:
> From: Barney Desmond
> Subject: Re: postfix performance
> To: postfix-users@postfix.org
> Date: Monday, August
2009/8/18 Evan Platt :
> At 10:30 AM 8/17/2009, you wrote:
>> I just make the test and the performance was not good. Outgoing 1K email
>> was around 568 seconds.
>>
>> Any insight is appreciated.
>
> Although this will likely be out of my area of being able to help you,
> someone else here probably
At 10:30 AM 8/17/2009, you wrote:
All,
What do I need to do in order to have better performance on Postfix.
I have Centos5 with postfix installed. The mail server is only as a
relay mail server and has nothing else.
I just make the test and the performance was not good. Outgoing 1K
email was
All,
What do I need to do in order to have better performance on Postfix.
I have Centos5 with postfix installed. The mail server is only as a relay mail
server and has nothing else.
I just make the test and the performance was not good. Outgoing 1K email was
around 568 seconds.
Any insight is
Yu (Irvin) Fan:
> Hi Wietse,
>
> Thanks for the quick answer. Can I say that the postfix performance is
> affected by small file read/write speed of the disk?
Many email messages small. Therefore performance is dominated by
rotational and seek latencies (absent a large persistent bu
Hi Wietse,
Thanks for the quick answer. Can I say that the postfix performance is
affected by small file read/write speed of the disk?
Anyway, I have another related question. We have an after-queue content
filter written in Perl. The email is fed to the filter using pipe as
suggested in the
ce reason. I'm trying to understand
> > how exactly does the disk I/O affect the postfix performance? By speed
> > (bytes per second) or activities (# of read/write per second)?
>
> I have shocking information for you: it is none of the above.
>
> Postfix must write the
exactly does the disk I/O affect the postfix performance? By speed
> (bytes per second) or activities (# of read/write per second)?
I have shocking information for you: it is none of the above.
Postfix must write the message to stable storage, so that it
will not be lost after a system crash.
Hi,
We're building a box to run two postfix instances to receive and send high
volume of emails. According to the documentation it's better to run the two
instances on separate disks for performance reason. I'm trying to understand
how exactly does the disk I/O affect the postfix
67 matches
Mail list logo
