Re: [Dovecot] load increase after upgrade to 2.0.8

* Timo Sirainen : > So with Ralf's previous statistics for one hour: > > v2.0: > 6887 imap logouts (processes) > 26672928 voluntary context switches (3872 / process) > 1313631 involuntary context switches (190 / process) > > v1.2: > 6832 imap logouts (processes) > 1003200 voluntary context switc

Re: [Dovecot] load increase after upgrade to 2.0.8

* Cor Bosman : > login_process_per_connection = yes > > So seems like we did have that set in 1.2. We didn't use that (in both 1.2 and 2.0) -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-1

Re: [Dovecot] load increase after upgrade to 2.0.8

* Cor Bosman : > > > > I see you're using userdb passwd. Do your users have unique UIDs? If they > > have, maybe it has to do with that.. > > Yes, we have about 1 million unique UIDs in the passwd file (actually > NIS). And we have about 15.000 unique UIDs in the passwd file (no NIS!) > I did

Re: [Dovecot] load increase after upgrade to 2.0.8

* Mark Moseley : > On Wed, Dec 8, 2010 at 3:03 PM, Timo Sirainen wrote: > > On 8.12.2010, at 22.52, Cor Bosman wrote: > > > >> 1 server with service_count = 0, and src/imap/main.c patch > > > > By this you mean service_count=0 for both service imap-login and service > > imap blocks, right? > > >

Re: [Dovecot] load increase after upgrade to 2.0.8

Just for thoroughness ive started 2 servers with the logging patch. One with service_count=0 and one with service_count=1

Re: [Dovecot] load increase after upgrade to 2.0.8

> lcs values for v1.2 and v2.0. Wonder if you get different values? > > If you don't mind some huge logs, you could also try the attached patch that > logs the voluntary context switch count for every executed IMAP command. > Maybe some command shows up that generates them much more than others.

Re: [Dovecot] load increase after upgrade to 2.0.8

>> >> 1 server with service_count = 0, and src/imap/main.c patch >> >> Is that ok? > > Looks good! > I had to revert this patch because it's causes permission errors on our filesystem. Directories are being created for user X with the euid of user Y (which fails, so at least i didnt get corr

Re: [Dovecot] load increase after upgrade to 2.0.8

On 9.12.2010, at 2.24, Timo Sirainen wrote: > Like the answer to question: Is the number of voluntary context switches by > imap processes close to the number of called syscalls? Oh, right, no. Syscalls don't increase context switch counts. So the voluntary context switch basically seems to mea

Re: [Dovecot] load increase after upgrade to 2.0.8

On 9.12.2010, at 1.52, Timo Sirainen wrote: > trace looks like an interesting new tool: http://lwn.net/Articles/415728/ > > Wonder if that would tell something about this problem. Like the answer to question: Is the number of voluntary context switches by imap processes close to the number of c

Re: [Dovecot] load increase after upgrade to 2.0.8

trace looks like an interesting new tool: http://lwn.net/Articles/415728/ Wonder if that would tell something about this problem.

Re: [Dovecot] load increase after upgrade to 2.0.8

On Wed, 2010-12-08 at 23:37 +0100, Cor Bosman wrote: > We're running on bare metal, no VM involved. > > Cor > Missed most of this list due to some noise levels and my lack of time to sit through hundreds messages on every list I'm on, so apologies if this was already suggested, due to errors i

Re: [Dovecot] load increase after upgrade to 2.0.8

On Wed, Dec 8, 2010 at 3:03 PM, Timo Sirainen wrote: > On 8.12.2010, at 22.52, Cor Bosman wrote: > >> 1 server with service_count = 0, and src/imap/main.c patch > > By this you mean service_count=0 for both service imap-login and service imap > blocks, right? > > Speaking from my own experience,

Re: [Dovecot] [PATCH] dovecot-lda segfault

On 8.12.2010, at 11.23, Florian Forster wrote: > The interesting part of the backtrace is the following: > > -- 8< -- > #0 acl_object_deinit (_aclobj=0x30) at acl-api.c:23 >aclobj = > #1 0x7f4673f35e84 in acl_backend_deinit (_backend=) > at acl-backend.c:95 >backend = (str

Re: [Dovecot] load increase after upgrade to 2.0.8

> >> 1 server with service_count = 0, and src/imap/main.c patch > > By this you mean service_count=0 for both service imap-login and service imap > blocks, right? > > Yes, on both imap-login and imap, The 2 servers without the patch only have it on imap-login. Cor

Re: [Dovecot] load increase after upgrade to 2.0.8

On 8.12.2010, at 22.52, Cor Bosman wrote: > 1 server with service_count = 0, and src/imap/main.c patch By this you mean service_count=0 for both service imap-login and service imap blocks, right?

Re: [Dovecot] load increase after upgrade to 2.0.8

On 8.12.2010, at 22.52, Cor Bosman wrote: > Right now I have running: > > 3 servers with just a new kernel, no other changes > 2 servers with service_count = 0, no other changes > 1 server with service_count = 0, and src/imap/main.c patch > > Is that ok? Looks good! > I wont be seeing much imp

Re: [Dovecot] load increase after upgrade to 2.0.8

Hope im doing what you want :) Getting kinda confusing. Right now I have running: 3 servers with just a new kernel, no other changes 2 servers with service_count = 0, no other changes 1 server with service_count = 0, and src/imap/main.c patch Is that ok? I wont be seeing much impact until tomo

Re: [Dovecot] load increase after upgrade to 2.0.8

Cor Bosman put forth on 12/8/2010 4:37 PM: > We're running on bare metal, no VM involved. Ok, that's good to know--should eliminate some potential complexity in troubleshooting this. -- Stan

Re: [Dovecot] load increase after upgrade to 2.0.8

We're running on bare metal, no VM involved. Cor

Re: [Dovecot] load increase after upgrade to 2.0.8

Cor Bosman put forth on 12/8/2010 9:45 AM: >>> >> >> It could be that you both are running a different Kernel from the Standard >> Lenny Kernel 2.6.26. (this could be a clue ..) > > > It would be interesting to hear from people that aren't seeing a big load > increase. My initial guess wa

Re: [Dovecot] load increase after upgrade to 2.0.8

It would be useful to know if the problem is with the imap process startup or after that. If you apply the attached patch, you can set: service imap { service_count = 0 } This causes the imap processes to be reused for future connections. With the patch enabled the processes keep the ability

Re: [Dovecot] load increase after upgrade to 2.0.8

login_process_per_connection = yes So seems like we did have that set in 1.2. Cor

Re: [Dovecot] load increase after upgrade to 2.0.8

On 8.12.2010, at 22.19, Cor Bosman wrote: > Oh, and I dont know if we did in 1.2. I think so, but cant be positive. I > tried making the config the same. I have the config still around if you want > to see it. In v1.2 it was called login_process_per_connection

Re: [Dovecot] load increase after upgrade to 2.0.8

Oh, and I dont know if we did in 1.2. I think so, but cant be positive. I tried making the config the same. I have the config still around if you want to see it. Cor

Re: [Dovecot] load increase after upgrade to 2.0.8

> So you have tons of imap-login processes. Did you have that in v1.2 too? Try > setting service_count=0 (and same for pop3-login) > > http://wiki2.dovecot.org/LoginProcess Yes, we have tons of imap-login processes. I'll set service_count=0 for imap (we dont do pop with dovecot) on a few server

Re: [Dovecot] load increase after upgrade to 2.0.8

> service imap-login { > service_count = 1 > } So you have tons of imap-login processes. Did you have that in v1.2 too? Try setting service_count=0 (and same for pop3-login) http://wiki2.dovecot.org/LoginProcess

Re: [Dovecot] load increase after upgrade to 2.0.8

> > I see you're using userdb passwd. Do your users have unique UIDs? If they > have, maybe it has to do with that.. Yes, we have about 1 million unique UIDs in the passwd file (actually NIS). I did upgrade 4 machines to the latest kernel, but it's hard to tell if that changed much as our us

Re: [Dovecot] Connection queue full on 2.0.8

On 8.12.2010, at 15.10, Patrick McLean wrote: >> Dec 8 09:46:52 orford dovecot: imap-login: Disconnected: Connection queue >> full (no auth attempts): rip=x.x.x.x, lip=x.x.x.x, TLS .. >> service imap-login { >> process_min_avail = 5 >> } You reached the default limits of imap-login processes.

Re: [Dovecot] load increase after upgrade to 2.0.8

On 8.12.2010, at 20.30, Timo Sirainen wrote: > So same problem as with Ralf. What kernel version are you using? Maybe try a > newer one to see if that happens to fix it? I see you're using userdb passwd. Do your users have unique UIDs? If they have, maybe it has to do with that..

Re: [Dovecot] load increase after upgrade to 2.0.8

On 8.12.2010, at 17.56, Cor Bosman wrote: >> Timo and I found excessive numbers of context switches, factor 20-30. >> But it's unclear why the IMAP process would do/cause this. > > Im seeing this as well...http://grab.by/7Nni So same problem as with Ralf. What kernel version are you using? M

Re: [Dovecot] mail.err

On 2010-12-08 1:39 PM, Jamie Paul Griffin wrote: >> I understand. I will make sure I don't remove that information in >> future. Thank you for making me aware of that Marcus. > oops, sorry not Marcus - Charles. I do apologise. lol - no worries, I've been called *much* worse ;) And thank *you* fo

[Dovecot] Dovecot as IMAP proxy to Exchange

Hello list, I'm looking into the possibility to setup dovecot to act as an IMAP proxy to an Exchange server. Things i know beforehand: - I will not be able to use the ldap (Active Directory) user DN for auth binds (but i discovered that i could could use the user userPrincipalName attribute a

Re: [Dovecot] Released Pigeonhole v0.2.2 for Dovecot v2.0.8

On 12/6/2010 6:18 PM, Stephan Bosch wrote: The new Dovecot v2.0.8 release has a few changes that prompted changes in Pigeonhole as well. This means that a new release of Pigeonhole is also necessary, because otherwise things will not compile anymore. Thanks! It builds and runs well for me, but

Re: [Dovecot] Dovecot 1.2/2.0 coexistence guide?

On 12/5/2010 2:25 PM, Timo Sirainen wrote: On 5.12.2010, at 16.40, Tom Talpey wrote: I am running Dovecot 1.2.16 and considering moving up to 2.0.8. I have found but there's not a lot about deploying a 2.0 server alongside an existing 1.2. Any hints on a

Re: [Dovecot] load increase after upgrade to 2.0.8

* Jose Celestino : > It ended up being due to a slight increase in memory usage by the imap > processes that made the servers start using swap and the load to spike. My machine is not swapping; it doesn't even HAVE swap, it still has lots of free memory -- Ralf Hildebrandt Geschäftsbereich IT

Re: [Dovecot] load increase after upgrade to 2.0.8

* David Ford : > what's your task switch HZ compiled at? CONFIG_HZ_1000? you would > probably be better at 300 or 250. have you tried tickless? # fgrep HZ /boot/config-2.6.32-25-generic-pae CONFIG_NO_HZ=y CONFIG_HZ_250=y CONFIG_HZ=250 > is your kernel compiled for precisely your cpu type and s

Re: [Dovecot] mail.err

> I understand. I will make sure I don't remove that information in future. > Thank you for making me aware of that Marcus. oops, sorry not Marcus - Charles. I do apologise.

Re: [Dovecot] mail.err

On Wed, Dec 08, 2010 at 12:23:18PM -0500, Charles Marcus wrote: > This is irrelevant though. People should always be encouraged to do > things the right way, and cross-posting the same Off-Topic question to > multiple support lists - especially high volume lists like the postfix > (and sometimes th

Re: [Dovecot] load increase after upgrade to 2.0.8

> > Timo and I found excessive numbers of context switches, factor 20-30. > But it's unclear why the IMAP process would do/cause this. Im seeing this as well...http://grab.by/7Nni Cor

Re: [Dovecot] mail.err

On 2010-12-08 9:01 AM, Paul Cartwright wrote: > On 12/08/2010 07:35 AM, Charles Marcus wrote: >> The point is if you continue using the shotgun approach, you will >> quickly wear out your welcome and any good will others may be >> predisposed to provide. > I try to lurk & read as much as I can bef

Re: [Dovecot] mail.err

On 2010-12-08 8:54 AM, Jamie Paul Griffin wrote: >> The point is if you continue using the shotgun approach, you will >> quickly wear out your welcome and any good will others may be >> predisposed to provide. > I'm well aware of what the point is - i think it's ok to give people > the benefit of

Re: [Dovecot] load increase after upgrade to 2.0.8

On Qua, 2010-12-08 at 15:39 +0100, Cor Bosman wrote: > I upgraded most of our servers from 1.2.x to 2.0.8 and am noticing a really > big increase in server load. This is across the board, not any specific > server. Check this screenshot of a load graph: http://grab.by/7N8V > > Is there anything

Re: [Dovecot] load increase after upgrade to 2.0.8

On Dec 8, 2010, at 5:11 PM, David Ford wrote: > what's your task switch HZ compiled at? CONFIG_HZ_1000? you would probably > be better at 300 or 250. have you tried tickless? is your kernel compiled > for precisely your cpu type and smp/hyper options set correctly? what about > CONFIG_PREE

Re: [Dovecot] load increase after upgrade to 2.0.8

On 08-12-10 17:11, David Ford wrote: what's your task switch HZ compiled at? CONFIG_HZ_1000? you would probably be better at 300 or 250. have you tried tickless? is your kernel compiled for precisely your cpu type and smp/hyper options set correctly? what about CONFIG_PREEMPT? definitely d

Re: [Dovecot] load increase after upgrade to 2.0.8

what's your task switch HZ compiled at? CONFIG_HZ_1000? you would probably be better at 300 or 250. have you tried tickless? is your kernel compiled for precisely your cpu type and smp/hyper options set correctly? what about CONFIG_PREEMPT? definitely don't use realtime, server is appropri

Re: [Dovecot] load increase after upgrade to 2.0.8

* David Ford : > gprof for detail, and even with simple strace timing. i.e. strace > -c. if load is going up significantly, there should be one or more > functions significantly fatter than the rest. you can pick either to > run it on the whole group, or just attach to certain processes. > (mas

Re: [Dovecot] load increase after upgrade to 2.0.8

gprof for detail, and even with simple strace timing. i.e. strace -c. if load is going up significantly, there should be one or more functions significantly fatter than the rest. you can pick either to run it on the whole group, or just attach to certain processes. (master, imap, lda, etc)

Re: [Dovecot] load increase after upgrade to 2.0.8

* David Ford : > Ralf, did you do the profiling yet? With gprof or what exactly is on your mind? > On 12/08/10 09:50, Ralf Hildebrandt wrote: > >[...] > >Yes, this looks like my graphs. Same increase. Factor 5. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universit

Re: [Dovecot] load increase after upgrade to 2.0.8

* Cor Bosman : > It would be interesting to hear from people that aren't seeing a big > load increase. Indeed. Tomi was mentioning some big company; what kind of setup were the using, Timo? > My initial guess was some kind of NFS problem, but since Ralf isn't > doing NFS, that's probably not it.

Re: [Dovecot] load increase after upgrade to 2.0.8

* Cor Bosman : > Here's the doveconf -n output: http://wa.ter.net/download/doveconf-n.txt Except for your storage being on NFS, it looks fairly identical! masteruser, passdb pam, userdb passwd. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berli

Re: [Dovecot] load increase after upgrade to 2.0.8

>> > > It could be that you both are running a different Kernel from the Standard > Lenny Kernel 2.6.26. (this could be a clue ..) It would be interesting to hear from people that aren't seeing a big load increase. My initial guess was some kind of NFS problem, but since Ralf isn't doi

[Dovecot] Connection queue full on 2.0.8

Hi, I can't find any references to this problem on 2.x. I upgraded to 2.0.8 last night, and now I am getting these errors in the logs (along with the server refusing new connections): > Dec 8 09:46:52 orford dovecot: imap-login: Disconnected: Connection queue > full (no auth attempts): rip=x.x.

Re: [Dovecot] load increase after upgrade to 2.0.8

Ralf, did you do the profiling yet? On 12/08/10 09:50, Ralf Hildebrandt wrote: [...] Yes, this looks like my graphs. Same increase. Factor 5.

Re: [Dovecot] load increase after upgrade to 2.0.8

On 12/8/2010 9:55 AM, Cor Bosman wrote: Here's the doveconf -n output: http://wa.ter.net/download/doveconf-n.txt Cor It could be that you both are running a different Kernel from the Standard Lenny Kernel 2.6.26. (this could be a clue ..) M.A.

Re: [Dovecot] load increase after upgrade to 2.0.8

Here's the doveconf -n output: http://wa.ter.net/download/doveconf-n.txt Cor

Re: [Dovecot] load increase after upgrade to 2.0.8

* Ralf Hildebrandt : > > http://wa.ter.net/download/doveconf.txt > > We need to find out WHAT is common in our two config files! My config is attached -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgda

Re: [Dovecot] load increase after upgrade to 2.0.8

* Cor Bosman : > I upgraded most of our servers from 1.2.x to 2.0.8 and am noticing a > really big increase in server load. This is across the board, not any > specific server. Check this screenshot of a load graph: > http://grab.by/7N8V Yes, this looks like my graphs. Same increase. Factor 5.

[Dovecot] load increase after upgrade to 2.0.8

I upgraded most of our servers from 1.2.x to 2.0.8 and am noticing a really big increase in server load. This is across the board, not any specific server. Check this screenshot of a load graph: http://grab.by/7N8V Is there anything i should be looking at that could cause such a drastic load i

Re: [Dovecot] mail.err

On 12/08/2010 07:35 AM, Charles Marcus wrote: > The point is if you continue using the shotgun approach, you will > quickly wear out your welcome and any good will others may be > predisposed to provide. I try to lurk & read as much as I can before asking for help. > > Also - please do not delet

Re: [Dovecot] mail.err

On 12/07/2010 07:32 PM, Karsten Bräckelmann wrote: > True. And as one probably could gather from my first response, I prefer > to just solve the issue, even if the choice of list was misguided. Guess > I mostly got annoyed by the repeated claim of not using IPv6, despite > the clear evidence. but I

Re: [Dovecot] mail.err

> The point is if you continue using the shotgun approach, you will > quickly wear out your welcome and any good will others may be > predisposed to provide. I'm well aware of what the point is - i think it's ok to give people the benefit of the doubt when they are new and trying to work things.

Re: [Dovecot] mail.err

On 2010-12-07 7:02 PM, Jamie Paul Griffin wrote: >> Thanks for the note. Although I'm not happy to see the OP used the >> shotgun approach to get help... > indeed but it's not then end of the world. good job there are nice > folk on this list to help out. The point is if you continue using the sh

Re: [Dovecot] passdb pam and userdb passwd "Authentication failure" errors

On Tue, 07 Dec 2010 23:41:24 +, Timo Sirainen wrote: > > QUESTION 1: To avoid those Authentication failure errors should I > > also comment out the passdb pam {...} and userdb passwd {...} > > blocks in the main /etc/dovecot/dovecot.conf? > > Yes. > > > I was thinking in something like:

Re: [Dovecot] [PATCH] dovecot-lda segfault

Hi, On Tue, Dec 07, 2010 at 11:32:20PM +, Timo Sirainen wrote: > Could you get gdb backtrace? Something like: I'm a colleague of Michael's and helped him debug this issue. The interesting part of the backtrace is the following: -- 8< -- #0 acl_object_deinit (_aclobj=0x30) at acl-api.c:23

Re: [Dovecot] How to handle "Waiting for authentication process..."

On 08.12.2010 10:07, Timo Sirainen wrote: > I don't see an actual problem here. Just ignore all untagged replies until > the client gets the tagged reply to the command it sent. It seems more like > an IMAP client is freaking out when it sees an untagged reply that it\s not > expecting. Arghhh

Re: [Dovecot] How to handle "Waiting for authentication process..."

On 8.12.2010, at 8.59, A.L.E.C wrote: > Sometimes, when dovecot authentication processes are busy, dovecot write > reply "Waiting for authentication process to respond.." to client. > Roundcube webmail do not understand it and invalidate user session. That's an untagged reply. What kind of an aut

[Dovecot] How to handle "Waiting for authentication process..."

Sometimes, when dovecot authentication processes are busy, dovecot write reply "Waiting for authentication process to respond.." to client. Roundcube webmail do not understand it and invalidate user session. My question is what is a good practise to handle this situation by client software? One Ro