Bill Anderson <[EMAIL PROTECTED]> wrote:
> Why not use "-type f" to tell find to only show files, which does not
> include directories? That is how I did it when I was using the brute
> force method. Nice advantage in that you can have any amount of
> hashing in a directory and still get an a
> Postfix hash_queue_names uses one-character (letter or digit)
> directory names. This is sufficient to implement a tree.
>
> Current queue file names are longer than 1, because they have two
> parts (inode number and time).
Thanks!
> A future queue implementation may use a different organizati
We track the number of messages in each postfix queue on our
mailservers using a program I've written. For most queues,
it simply does a readdir() and counts all files whose names don't
begin with ".", which is quick and efficient. For the deferred queue,
it does a find-style walk through the dir
Stephen Liu <[EMAIL PROTECTED]> wrote:
> reload postfix. Problem remains.
> # tail /var/log/mail.log
> Nov 3 17:06:13 xen03 postfix/postfix-script[1778]: refreshing the
> Postfix mail system
> Nov 3 17:06:13 xen03 postfix/master[1144]: reload configuration
> /etc/postfix
> Nov 3 17:07:03 xen03
I recently upgraded a couple of servers from postfix 2.2 to 2.5.
No configuration changes except those made by the upgrade scripts.
Now, during large mailings, the two new servers have frequent qmgr
crashes, while the ones running 2.2 do not. The problem is qmgr runs
up against the per-process op
Francis SOUYRI <[EMAIL PROTECTED]> wrote:
> I say "very idle" because I have 30/70% cpu idle and 10/30% cpu wait.
If you really have the CPU in wait 10% - 30%, then that's very likely
your problem. Is there something other than postfix running on this
box that is putting demand on the disk?
> -
Francis SOUYRI <[EMAIL PROTECTED]> wrote:
> Time to time we have lot of mail in the incoming queue, "no" mail in the
> active queue, the "qmgr "is very" slow and the server is very idle. We
> tested the antispam/virus to see if there is a problem but the response
> is very good.
When you say "v
Victor Duchovni <[EMAIL PROTECTED]> wrote:
> This is not difficult to solve. Write a progressive parser that saves
> state just for messages that are not yet done (still in the queue). For
[...]
That's sort of what I described in my second paragraph. It's a
workaround, but it's far from perfect,
Victor Duchovni <[EMAIL PROTECTED]> wrote:
> Incoming mail is logged by smtpd(8)/pickup(8) and cleanup(8). Mail
> (re)entering the active queue is logged by the queue manager, which
> logs the sender address. Deliveries to recipients are logged by delivery
... one thing I've sometimes wished for i
Wietse Venema <[EMAIL PROTECTED]> wrote:
> > see clearly in the logs that each one of them is still taking several
> > incoming messages per second at peak times, and cleanup is placing
> > them all in the incoming queue, and the incoming queue gets very big.
> > in_flow_delay is apparently not tri
Ahh, this is very very helpful, thank you.
The problem on the fallback relays is indeed that they're disk I/O
bound, so "incoming" grows too quickly and qmgr can't get messages
into active fast enough.
If I understand you correctly, in_flow_delay will limit the *growth
rate* of the incoming queue
On some fallback relay servers that receive legitimate incoming mail
(relayed from the first-pass MTAs) much faster than they can process
it at times, I tried slowing things down using in_flow_delay.
I set in_flow_delay = 10s, and decreased maxproc for smtpd in master.conf.
Changing maxproc did r
Victor Duchovni <[EMAIL PROTECTED]> wrote:
> > However, I'm puzzled - it defaults to 18000s but the watchdog timer
> > seems to kill qmgr during these incidents after about a half hour,
> > which is 1800 seconds.
>
> Wrong timer. The watchdog timeout is hard-coded to 1000s.
Ahhh. I was going on
Victor Duchovni <[EMAIL PROTECTED]> wrote:
> You can skip waiting for future occurences, the behaviour you describe
> (especially on fallback relays where dead destinations are to be expected)
> fits the known issue like a glove (and we are not at the OJ trial :-).
Regardless, I definitely sometim
Wietse Venema <[EMAIL PROTECTED]> wrote:
> > # strace -p 31741
> > Process 31741 attached - interrupt to quit
> > futex(0x2a96b46930, FUTEX_WAIT, 2, NULL ^C
>
> Postfix does not manipulate futexes. The word futex appears
> nowhere in Postfix source code.
>
> However, there's a mutex deadlock in t
Postfix 2.2, CentOS 4 (yes, I want to upgrade; can't for now).
Note: I have a course of action, but not completely confident I
understand the problem so seeking other eyes on it. See bottom.
On a fallback relay serving several first-pass postfix servers, qmgr
seems to sometimes stop and rest whi
Wietse Venema <[EMAIL PROTECTED]> wrote:
> Ofer Inbar:
> > Victor Duchovni <[EMAIL PROTECTED]> wrote:
> > > Your queue manager is crashing.
> > [...]
> > > Queue manager re-starts.
> >
> > Is that a bug? Should it handle this situation m
Victor Duchovni <[EMAIL PROTECTED]> wrote:
> Your queue manager is crashing.
[...]
> Queue manager re-starts.
Is that a bug? Should it handle this situation more gracefully?
Now, a more interesting question:
What is the incremental memory cost of each smtp process?
According to pmap -d, the s
We recently observed something strange: After doubling the number of
smtp processes in master.cf and restarting, the size of the active
queue started fluctuating over time in almost exact inverse of the
incoming queue. I'm using Ganglia to track the sizes of the queues on
a graph, and the queue gr
> In that case, you should post summary statistics from the
>
> delays=a/b/c/d
I don't have delays= in my logs, only delay=. I think this is because
the setup I'm administering now is running postfix-2.2 (yes, I want to
upgrade them, but this won't happen for at least a month).
However, i
Victor Duchovni <[EMAIL PROTECTED]> wrote:
> > So I wonder if any of you administer high volume postfix sites and
> > have run into the same problem, and if you've found any workarounds.
>
> The work-around is to get on the Yahoo whitelist.
I should've mentioned that all servers in question are w
I've run into this problem at more than one high volume postfix site,
on different versions of RHEL/CentOS/Fedora, and different versions of
postfix (all of them 2.2 or higher), and the one common factor is yahoo.
So I wonder if any of you administer high volume postfix sites and
have run into the
22 matches
Mail list logo
