king:
4 Start_Stop_Count 0x0032 100 100 020Old_age Always - 115
12 Power_Cycle_Count 0x0032 100 100 020Old_age Always - 117
193 Load_Cycle_Count 0x0032 100 100 000Old_age Always - 117
--
Konrad Rzepecki
W dniu 20.01.2012 01:39, Stan Hoeppner pisze:
On 1/19/2012 5:07 AM, Konrad Rzepecki wrote:
Yes, you have right. But I found recently, that disk mounted on my
server are slow 5.9K. My tests on in shows that they do fsync 1.5x-2x
slower than 7.2K with quite often 5x-10x slower peak. Together with
ows that they do fsync 1.5x-2x
slower than 7.2K with quite often 5x-10x slower peak. Together with
raid10, lvm, ext4, and much heavier load during delivery it may give
effect I'm observing.
--
Konrad Rzepecki
W dniu 18.01.2012 13:03, Wietse Venema pisze:
Konrad Rzepecki:
I have similar problem, and I suspect you may also hit it. In my case I
send ~10k-20k mails through sendmail wrapper. My problem is caused by
fsync done on EVERY queued mail. It take on my servers (4 core AMD @
ext4 @ LVM @ RAID10
ient? That really
sucks performance even without a broken Linux fsync.
Every recipient get little different mail (customized links, etc). And,
but this is not so important, mails are directly addressed by "To:" not
by Bcc: with ugly "To: undisclosed-recipients".
--
Konrad Rzepecki
W dniu 18.01.2012 12:03, Ralf Hildebrandt pisze:
* Konrad Rzepecki:
I've already tried SMTP. This make no change since it also create
queue file, which must be fsynced before client is notified about
successfully queuing...
sendmail submission writes two files (maildrop queue).
W dniu 18.01.2012 11:50, Ralf Hildebrandt pisze:
* Konrad Rzepecki:
I have similar problem, and I suspect you may also hit it. In my case
I send ~10k-20k mails through sendmail wrapper. My problem is caused
by fsync done on EVERY queued mail. It take on my servers (4 core AMD
@ ext4 @ LVM
fashion.
I found only one very ugly workaround, but it is useful only when you
accept possibility to lost ALL queued mails. This is creating queue dir
in tempfs (ramdisk should also works).
--
Konrad Rzepecki
nning...
>
> And what is it doing?
You have right - this was problem with defer. I have invastigate it . The
bounce process hangs in flock() on unix.defer file. It was permamently locked
or something like that.
After deleting and recreating it, everything seems runs OK.
Thanks for hint.
en't working.
If you mean this one:
postfix 29426 0.0 0.1 6472 1740 ?S14:24 0:00 bounce -z -n
defer -t unix -u
it seems running...
--
Konrad Rzepecki - Wydawnictwo Bestom DENTOnet.pl Sp.z o.o.
ver.c:722
#20 0x0804b07b in main (argc=4, argv=0xafb17314) at smtp.c:1066
Please note that read_wait call has file descriptor equal to -4 - it looks
very _strange_ to me, especially that source code indicates that this value
should by equal to timed_read parameter ('13').
lsof te
11 matches
Mail list logo
