>> About 30% of all I/O is to mailboxes.db, most of which is read. I
> Solaris 10 does this in my case. Via dtrace you'll see that open() on the
> mailboxes.db and read-calls do not exceed microsecond ranges. mailboxes.db
> is not the problem here. It is entirely cached and rarely written
> (
On Thu, Nov 15, 2007 at 01:29:54PM -0500, Wesley Craig wrote:
> On 14 Nov 2007, at 23:15, Vincent Fox wrote:
> > We have all Cyrus lumped in one ZFS pool, with separate filesystems
> > for
> > imap, mail, sieve, etc. However, I do have an unused disk in each
> > array
> > such that I could set
> About 30% of all I/O is to mailboxes.db, most of which is read. I
> haven't personally deployed a split-meta configuration, but I
> understand the meta files are similarly heavy I/O concentrators.
That sounds odd.
Given the size and "hotness" of mailboxes.db, and in most cases the size of
ma
I finally succeeded in starting it again. I kill -9'd the ctl_cyrusdb
process.
On shutdown it wrote this in the syslog:
Nov 15 22:30:20 doohan cyrus/master[12843]: process 12844 exited, signaled to
death by 9
Nov 15 22:30:21 doohan cyrus/master[12980]: about to exec /usr/sbin/ctl_deliver
Nov
Platform: Intel Pentium II,
debian etch,
cyrus21-imapd 2.1.18-5.1
When starting up cyrus with
/etc/init.d/cyrus21 start
the only cyrus process running is
/usr/sbin/ctl_cyrusdb -r
and it's running using ~99% CPU, but with little memory and disk use
What's printed in /var/log/
Hi Ian,
> Cyrus Mailstore does handle final delivery, but there's plenty of
> opportunity to handle messages before that point. For example, we now
> use Exim and Cyrus Mailstore, and we have plenty of processing going on in
> Exim before hand off to Cyrus (with LMTP) including spamassassin, clama
Hi Olaf,
> Thats an interesting information. I have always thought that in
> Exchange-Outlook world the processing was on the server side and the
> messages were sitting on the server.
> Or the client side processing is limited to Toltec/Bynari solution?
With Exchange-Outlook the Outlook message
I've been running this in production:
mkdir /var/imap-proc
chown cyrusd /var/imap-proc
ln -s /var/imap-proc /var/cyrus/imap/proc
Setup vfstab entry for /var/imap-proc as TMPFS , and
that's about all there is to it. But yeah it would be an
improvement to see it configurable.
Ian G Batten wrote:
> --On 15. November 2007 18:14:05 +0100 Alain Spineux <[EMAIL PROTECTED]>
> wrote:
>
>>> # strace -p 25038
>>> Process 25038 attached - interrupt to quit
>>> read(0,
>>
>> Do you know what is 0, if it was a socket it should timeout, isn't it ?
>
> It should, I guess, but it doesn't.
>
>># ls -l /
On 14 Nov 2007, at 23:15, Vincent Fox wrote:
> We have all Cyrus lumped in one ZFS pool, with separate filesystems
> for
> imap, mail, sieve, etc. However, I do have an unused disk in each
> array
> such that I could setup a simple ZFS mirror pair for /var/cyrus/
> imap so
> that the database
>
> /etc/system:
>
> set zfs:zfs_nocacheflush=1
Yep already doing that, under Solaris 10u4. Have dual array controllers in
active-active mode. Write-back cache is enabled. Just poking in the 3510FC
menu shows cache is ~50% utilized so it does appear to be doing some work.
Cyrus Home Pag
--On 15. November 2007 18:14:05 +0100 Alain Spineux <[EMAIL PROTECTED]>
wrote:
# strace -p 25038
Process 25038 attached - interrupt to quit
read(0,
Do you know what is 0, if it was a socket it should timeout, isn't it ?
It should, I guess, but it doesn't.
# ls -l /proc/25038/fd
should
On Nov 15, 2007 4:54 PM, Sebastian Hagedorn <[EMAIL PROTECTED]> wrote:
> --On 15. November 2007 08:32:18 -0500 Ken Murchison <[EMAIL PROTECTED]>
> wrote:
>
> >>> Since it looks like things are hanging when a process is being used, I'd
> >>> like to see if the problem goes away if we don't reuse the
On Nov 15, 2007 3:55 PM, Olaf Fraczyk <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-11-15 at 15:50 +0200, Joon Radley wrote:
> > Hi Ian,
> >
> > > What I don't understand is that you seem to think that there's a
> > > possibility that email could be stored in some place that it can't be
> > > transport
Sebastian Hagedorn wrote:
> --On 15. November 2007 08:32:18 -0500 Ken Murchison
> <[EMAIL PROTECTED]> wrote:
>
Since it looks like things are hanging when a process is being used,
I'd
like to see if the problem goes away if we don't reuse the processes.
I'm just trying to do
--On 15. November 2007 11:00:39 -0500 Ken Murchison <[EMAIL PROTECTED]>
wrote:
(gdb) bt
# 0 0x0079f41e in __read_nocancel () from /lib/tls/libc.so.6
# 1 0x00d0b2f7 in BIO_new_socket () from /lib/libcrypto.so.4
# 2 0x00d092b2 in BIO_read () from /lib/libcrypto.so.4
# 3 0x005dae13 in ssl23_re
--On 15 November 2007 15:55:32 +0100 Olaf Fraczyk <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-11-15 at 15:50 +0200, Joon Radley wrote:
>> Hi Ian,
>>
>> > What I don't understand is that you seem to think that there's a
>> > possibility that email could be stored in some place that it can't be
>> >
Sebastian Hagedorn wrote:
> --On 15. November 2007 08:21:48 -0500 Ken Murchison
> <[EMAIL PROTECTED]> wrote:
>
>>> No. Since this potentially affects all IMAP and POP processes I would
>>> have to do it for all entries. Do you recommend that I try that?
>>
>> Since it looks like things are hangin
Interesting thought. We haven't gone to ZFS yet, although I like the idea
a lot. My hunch is it's an enormous win for the mailbox partitions, but
perhaps it's not a good thing for the meta partition. I'll have to let
someone else who knows more about ZFS and write speeds vs. read speeds
chim
Michael Bacon <[EMAIL PROTECTED]> wrote:
> I have heard tell of funny behavior that ZFS does if you've got
> battery-backed write caches on your arrays.
/etc/system:
set zfs:zfs_nocacheflush=1
is your friend. Without that, ZFS' performance on hardware arrays with
large RAM caches is abysmal.
--On 15. November 2007 08:32:18 -0500 Ken Murchison <[EMAIL PROTECTED]>
wrote:
Since it looks like things are hanging when a process is being used, I'd
like to see if the problem goes away if we don't reuse the processes.
I'm just trying to do a bsearch() on the problem.
OK. I've made the cha
On Thu, 2007-11-15 at 15:50 +0200, Joon Radley wrote:
> Hi Ian,
>
> > What I don't understand is that you seem to think that there's a
> > possibility that email could be stored in some place that it can't be
> > transported to. Where would that be?
>
> Please read the mails before this one. This
Zitat von Davin Flatten <[EMAIL PROTECTED]>:
> Hello-
>
> We are using Horde/Ingo against a Cyrus murder with three backend
> servers. When a user redirects there email the system generates the
> following script:
>
> ##INGO
> # sieve filter generated by Ingo (November 13, 2007, 10:08 am)
>
> req
Hi Ian,
> What I don't understand is that you seem to think that there's a
> possibility that email could be stored in some place that it can't be
> transported to. Where would that be?
Please read the mails before this one. This discussion is about what Outlook
needs in order to process special
--On 15 November 2007 14:05:43 +0200 Joon Radley <[EMAIL PROTECTED]> wrote:
> Hi Ian,
>
>> > In IMAP this gets a bit blurred as the INBOX is also
>> > the mechanism for receiving new mail.
>>
>> No, an INBOX is simply a mailbox. It's a place that you can deliver email
>> to, and read email from.
--On 15. November 2007 08:21:48 -0500 Ken Murchison <[EMAIL PROTECTED]>
wrote:
No. Since this potentially affects all IMAP and POP processes I would
have to do it for all entries. Do you recommend that I try that?
Since it looks like things are hanging when a process is being used, I'd
like t
Sebastian Hagedorn wrote:
> No. Since this potentially affects all IMAP and POP processes I would
> have to do it for all entries. Do you recommend that I try that?
Since it looks like things are hanging when a process is being used, I'd
like to see if the problem goes away if we don't reuse th
--On 14. November 2007 16:39:44 -0500 Ken Murchison <[EMAIL PROTECTED]>
wrote:
It looks to me like we are timing out the client while the client is
IDLEing, but we get a signal from idled in the middle of shutdown(). Try
this patch.
--- imapd.c.~1.535.~2007-11-14 16:16:21.0 -0500
+
--On 15. November 2007 06:55:44 -0500 Ken Murchison <[EMAIL PROTECTED]>
wrote:
OK. What version of OpenSSL?
cyradm says:
Built w/OpenSSL 0.9.7a Feb 19 2003
Running w/OpenSSL 0.9.7a Feb 19 2003
rpm says:
openssl-0.9.7a-33.23
This is RHEL 3.
Are they imaps/pop3s p
Sebastian Hagedorn wrote:
> Thanks. I will try this patch as soon as I can, but it's clearly not the
> only issue, because the same thing happens with POP processes. Here's an
> example for one:
>
> (gdb) bt
> #0 0x0096441e in __read_nocancel () from /lib/tls/libc.so.6
> #1 0x00ac02f7 in BIO_
>> I didn't test but doesn't a symlink work?
>
> Yes, it does (just tried it on a development system).
Definitely, we use it on all our machines.
lrwxrwxrwx 1 root root 23 Oct 26 10:50 proc ->
/tmpfs/imapproc-slot101
Rob
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FA
Hi Ian,
> > In IMAP this gets a bit blurred as the INBOX is also
> > the mechanism for receiving new mail.
>
> No, an INBOX is simply a mailbox. It's a place that you can deliver email
> to, and read email from. With the right delivery agent, it's possible to
> deliver email to any mailbox, so th
> I was interested to see someone suggesting putting proc into tmpfs.
> That's slightly painful if /var/imap is in ZFS: the order in which
> mounts take place means you can't just put /var/imap/proc tmpfs into /
> etc/vfstab if /var/imap is coming in through ZFS. A glance at the
> source code says
On Thu, 15 Nov 2007, Ian G Batten wrote:
; I was interested to see someone suggesting putting proc into tmpfs.
; That's slightly painful if /var/imap is in ZFS: the order in which
; mounts take place means you can't just put /var/imap/proc tmpfs into /
; etc/vfstab if /var/imap is coming in throu
--On 14 November 2007 13:26:22 +0200 Joon Radley <[EMAIL PROTECTED]> wrote:
> In IMAP this gets a bit blurred as the INBOX is also
> the mechanism for receiving new mail.
No, an INBOX is simply a mailbox. It's a place that you can deliver email
to, and read email from. With the right delivery
On 15 Nov 07, at 1045, Simon Matter wrote:
>> I was interested to see someone suggesting putting proc into tmpfs.
>> That's slightly painful if /var/imap is in ZFS: the order in which
>> mounts take place means you can't just put /var/imap/proc tmpfs
>> into /
>> etc/vfstab if /var/imap is comi
I was interested to see someone suggesting putting proc into tmpfs.
That's slightly painful if /var/imap is in ZFS: the order in which
mounts take place means you can't just put /var/imap/proc tmpfs into /
etc/vfstab if /var/imap is coming in through ZFS. A glance at the
source code says t
Nikola Milutinovic <[EMAIL PROTECTED]> wrote:
> > We use OpenGroupware - http://www.opengroupware.org
> >
> > Server is entirely Open Source; Outlook plugin (MAPI provider) is
> > commercial.
> >
> > Works very well with Cyrus; which is its intended IMAP server.
>
>
> Speaking of calendars,...
38 matches
Mail list logo
