Re: Cyrus logging informational messages with too high priority?
On 30 Oct 2002, Erik Enge wrote: > Rob Siemborski <[EMAIL PROTECTED]> writes: > > > That depends on a number of things. mailboxes.db should be skiplist > > for performance reasons anyway. > > What is skiplist? Is the code included in Cyrus? It's a database format that we wrote to do fast enumarations, and uses a persistant skiplist as its data structure. It's included with cyrus. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Cyrus logging informational messages with too high priority?
Rob Siemborski <[EMAIL PROTECTED]> writes: > That depends on a number of things. mailboxes.db should be skiplist > for performance reasons anyway. What is skiplist? Is the code included in Cyrus? Thanks, Erik.
Re: Cyrus logging informational messages with too high priority?
Rob Siemborski <[EMAIL PROTECTED]> writes: > You can, it's just not a great idea performance-wise (skiplist is more > optimized towards enumeration operatons than random access). Keeping in mind that I will have about 50 users that access their mailboxes all day, would I notice any performance impact of doing skiplist? Erik.
Re: Cyrus logging informational messages with too high priority?
On 30 Oct 2002, Erik Enge wrote: > > You can, it's just not a great idea performance-wise (skiplist is more > > optimized towards enumeration operatons than random access). > > Keeping in mind that I will have about 50 users that access their > mailboxes all day, would I notice any performance impact of doing > skiplist? Probably not. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Cyrus logging informational messages with too high priority?
On 30 Oct 2002, Erik Enge wrote: > I'm not sure I understand. Does that mean I cannot use > --with-duplicate-db and --with-tls-db as skiplist? Will Berkley DB > still be used? You can, it's just not a great idea performance-wise (skiplist is more optimized towards enumeration operatons than random access). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Cyrus logging informational messages with too high priority?
Rob Siemborski <[EMAIL PROTECTED]> writes: > It's in imap/imapd.c, near the top of cmdloop(). Will this be fixed in the next release? > Keep in mind that this won't make them entirely go away, since > Berkeley is still the prefered database for duplicate.db and > tls_cache.db. And they *are* a normal part of berkley db operation. I'm not sure I understand. Does that mean I cannot use --with-duplicate-db and --with-tls-db as skiplist? Will Berkley DB still be used? Erik.
Re: Cyrus logging informational messages with too high priority?
Rob Siemborski <[EMAIL PROTECTED]> writes: > It could probably go to LOG_INFO. Is this a configuration option I can adujust? Or can I recompile Cyrus to use info instead? > If you're using Berkeley DB 4 there's a bug in the locker counting > code that causes this number to not be decremented, so it really isn't > something to worry about unless there are other problems (like severe > performance problems all the time). Ok. No, we're not having any other problems, as such, but the messages do show up in our centralized logging system (which makes all developers/sysadmins jump in their chairs) so I'd like for them to go away. I guess I'll do skiplist. > If other clients were working, I'm going to blame the client that > wasn't, but that's just me. I'm so inclined too. > If you could get protocol traces that'd be moure useful. Unfortunately I can not reproduce the situation now. I'll be on the lookout for it again, though. Erik.
Re: Cyrus logging informational messages with too high priority?
On 30 Oct 2002, Erik Enge wrote: > Rob Siemborski <[EMAIL PROTECTED]> writes: > > > It could probably go to LOG_INFO. > > Is this a configuration option I can adujust? Or can I recompile Cyrus > to use info instead? It's in imap/imapd.c, near the top of cmdloop(). > > If you're using Berkeley DB 4 there's a bug in the locker counting > > code that causes this number to not be decremented, so it really isn't > > something to worry about unless there are other problems (like severe > > performance problems all the time). > > Ok. No, we're not having any other problems, as such, but the messages > do show up in our centralized logging system (which makes all > developers/sysadmins jump in their chairs) so I'd like for them to go > away. I guess I'll do skiplist. Keep in mind that this won't make them entirely go away, since Berkeley is still the prefered database for duplicate.db and tls_cache.db. And they *are* a normal part of berkley db operation. (And I'd argue against not logging them, since they can indicate the problem when they are increasing quickly). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Cyrus logging informational messages with too high priority?
On 30 Oct 2002, Erik Enge wrote: > The following error message seem to be at warn (syslog priority) or > above: > > Oct 30 14:24:57 myhost imapd[12489]: idle for too long, closing connection > > Shouldn't this be only an info, or is it really a warning that something > is about to go wrong (which how I think of warnings)? It could probably go to LOG_INFO. > The other day, I got the following in the log: > > Oct 30 12:49:34 myhost lmtpd[12178]: DBERROR db3: 5 lockers > Oct 30 12:49:34 myhost lmtpd[12178]: DBERROR db3: 5 lockers > Oct 30 12:49:35 myhost lmtpd[12185]: DBERROR db3: 6 lockers > [more like these snipped] > > I did some searching in the archives and the preferred solution seems to > be to recompile cyrus with a different database (flat, for example). Is > this still the preferred solution? That depends on a number of things. mailboxes.db should be skiplist for performance reasons anyway. If you're using Berkeley DB 4 there's a bug in the locker counting code that causes this number to not be decremented, so it really isn't something to worry about unless there are other problems (like severe performance problems all the time). > As I said, I don't know if this is anything Cyrus is to blame for, but I > thought I'd mention it. Any pointers of any of these issues would be > greatly appreciated. If other clients were working, I'm going to blame the client that wasn't, but that's just me. If you could get protocol traces that'd be moure useful. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
