Re: About session disconnect and an slow response some time later

Hi! 

I have been looking deeply at this, at reap_child() and process_msg()
and this seems to be fine... so my suspect is just noise.... sorry for
it... 

I'll go on trying to reproduce it.... or try enabling debug to 1 in
imapd.conf with a HUP signal when I have the problem.... if the suspect
I had that ready_works was not totally right decremented I suppose
(should look more deeply) that enabling debug in that moment would allow
me (to see ready_workers value because I see are logged with debug in
master.c in some place...)... 

Thanks anyway, 

Cheers!

El 2022-06-22 12:58, [email protected] escribió:

> Good morning, 
> 
> I wrote to the list some time ago due to this topic. I have noted that when a user asks to disconnect his/her sessions (imap sessions normally the disconnected ones) after some time like an hour or a half an hour passes I start having some slow responses to new connections. I have monitored them and it's slightly intermittent, KO and OK of server responding alert in less than 3 seconds. This intermittency lasts like 10 minutes and later the response delays increase. Obviously for avoid bigger service outages I stop and start Cyrus and all works fine later. 
> 
> I have been trying to figure why it could be happening because I have seen it only happens when I launch TERM for a disconnection to several imap proccesses (the user that requested proccesses). It doesn't happen at the moment. As said for instance yesterday happened when an hour passed of the disconnection. 
> 
> I don't have prefork param set in cyrus.conf, so... Cyrus spawns on demand. After doing some examinations my theory is that perhaps Cyrus is not calling spawn_service() every time gets needed. I would say it should happen in master.c : 
> 
> 2610               if (!in_shutdown && Services[i].exec &&
> 2611                    Services[i].nactive < Services[i].max_workers &&
> 2612                    Services[i].ready_workers == 0 &&
> 2613                    y >= 0 && FD_ISSET(y, &rfds))
> 2614                {
> 2615                    /* huh, someone wants to talk to us */
> 2616                    spawn_service(i);
> 2617                } 
> 
> I think that perhaps ready_workers is not properly decremented when I launch this TERM and perhaps this causes Cyrus not to spawn any new more services of the kind of the terminated service. As yesterday happened in a more or less peak accesses hour it needed to have more services spawned but... as it seen ready_workers not to be 0 for that service... it didn't spawn new more services and as consequence, connections started becoming queued in being accepeted awaiting that happened when a proccess gets idle because it's client has disconnected or idled timeout or imap timeout happened.... 
> 
> So, I was wondering if in reap_child() for the states SERVICE_STATE_UNKNOWN and SERVICE_STATE_BUSY shouldn't be decremented the ready_workers in the service struct... Concretely in master.c in : 
> 
> 1121                case SERVICE_STATE_BUSY:
> 1122                    s->nactive--;
> 1123                   if (!in_shutdown && failed) {
> 1124                       syslog(LOG_DEBUG,
> 1125                               "service %s/%s pid %d in BUSY state: "
> 1126                               "terminated abnormally",
> 1127                               SERVICEPARAM(s->name),
> 1128                               SERVICEPARAM(s->familyname), pid);
> 1129                    }
> 1130                    break;
> 1131
> 1132                case SERVICE_STATE_UNKNOWN:
> 1133                    s->nactive--;
> 1134                   syslog(LOG_WARNING,
> 1135                           "service %s/%s pid %d in UNKNOWN state: exited",
> 1136                           SERVICEPARAM(s->name),
> 1137                           SERVICEPARAM(s->familyname), pid); 
> 
> Obviously, another possible solution is to specify prefork in cyrus.conf but I'd rather avoid wasting memory when it's not needed... 
> 
> What's your opinion mates?. Or what do you think Ellie, Bron :) . Have you ever seen something like it?. 
> 
> Cheers!
------------------------------------------
Cyrus: Info
Permalink: https://cyrus.topicbox.com/groups/info/Td155a4c12885169a-M30352657fddac1fe7efc4299
Delivery options: https://cyrus.topicbox.com/groups/info/subscription