Zitat von Andre Nathan [EMAIL PROTECTED]:
Hello
We have a cyrus server that runs under heavy load, and a few days ago it
started to show a behaviour where its lmtpd processes take a long time
to deliver messages sent from postfix. Below is an example of a postfix
log message. with the email
Hello,
I'm using Cyrus replication. After several tests, it seems that the
single instance store facility is not replicated. I mean, the same
message sent to several recipient is stored once on the master, but
stored several times on the slave.
Is there a special thing to do to activate
On Thu, 2007-03-01 at 09:25 +0100, [EMAIL PROTECTED] wrote:
A few thousand lmtpd would be *way* too much because they all use the
same I/O bottleneck (if you don't have partitions on different I/O
paths). For a single I/O path i would recommend not more than some 10
.. 20 concurrent lmtpd
On Wed, 2007-02-28 at 16:22 -0600, Blake Hudson wrote:
I would suggest starting by reviewing your memory usage (esp. swap) with
top and disk usage with iostat -x 3 (part of the sysstat package)
More than likely you are running into problems in one of these areas.
Thanks, I'll have a look at
On Wed, 2007-02-28 at 17:26 -0300, Andre Nathan wrote:
The last field in the delays field shows that the time out occurred
after 600s trying to send the message to cyrus. Even when a timeout does
not occur, the time for the message to be sent is around 100-300s.
A more complete log (this is an
On Thu, 1 Mar 2007, Jerome Nenert wrote:
I'm using Cyrus replication. After several tests, it seems that the
single instance store facility is not replicated. I mean, the same
message sent to several recipient is stored once on the master, but
stored several times on the slave. Is there a
On Thu, 2007-03-01 at 10:38 -0300, Andre Nathan wrote:
After postfix sends the ., it takes lmtpd more than 5 minutes to send
the 250 2.1.5 Ok back (everything else on the lmtp conversation
happens in the same second). Is this the time when lmtpd writes the
message to disk? I'm trying to find
ls -l /proc/15999/fd/6
lrwx-- 1 cyrus mail 64 Mar 1 11:15 /proc/15999/fd/6
- /var/lib/imap/deliver.db
I disabled duplicate suppression in imapd.conf for now and the
situation
has improved greatly since. Does anyone have this kind of problem with
lock contention in heavily loaded
Does someone can help me with it?
It seems replication is rely hard to get working?
Thanks!
I remove the line
syncserver cmd=/usr/cyrus/bin/sync_server listen=csync
from my cyrus.conf then i try to sync manually, it doesn't
sync anything.
If i make as cyrus a sync_client -u -v i will see
On Thu, 2007-03-01 at 11:19 -0500, John Madden wrote:
FWIW, I turned off duplicatesuppression to no avail -- lmtpd still locks
and writes to /var/imap/deliver.db. ...So are you sure it's really
turned off?
Well, it's funny, I still see the duplicate_check lines in the log,
but watching the
On Thu, 2007-03-01 at 14:00 -0300, Andre Nathan wrote:
Well, it's funny, I still see the duplicate_check lines in the log,
but watching the processes with strace I can't see the blocking
behaviour anymore. I still do have heavy contention on some users'
cyrus.header files though, not sure what
Fabio Silva wrote:
Hi all, is there any tool to migrate from mbox format to cyrus-imap ???
could you tell me any tool to do it???
im using sles10, and i need to migrate my user to our new cyrus server
Regards,
--
Fabio S. Silva
What format is your deliver.db file?
I've had success changing mine to skiplist on more heavily utilized servers.
-Blake
Andre Nathan wrote:
On Thu, 2007-03-01 at 14:00 -0300, Andre Nathan wrote:
Well, it's funny, I still see the duplicate_check lines in the log,
but watching the
On Thu, 2007-03-01 at 16:41 -0600, Blake Hudson wrote:
What format is your deliver.db file?
I've had success changing mine to skiplist on more heavily utilized servers.
Skiplist too. I've moved away from berkeleydb long ago after all the
issues I had...
Andre
Cyrus Home Page:
14 matches
Mail list logo
