ENS Over SSL Connection Startup Slower, Causes Imapd Startup To Fail (Doc ID 2820733.1)

Last updated on FEBRUARY 21, 2023

Applies to:

Symptoms

ENS over SSL connection startup is slower and causes imapd startup to fail.

ENS has been running over SSL (in a test environment). A typical setup consists of:

So that one was a connection which the client had given up and closed before enpd got around to doing the accept() call.

After that one failed, the rest all happened within about 1 second and succeeded.
On the system where the truss was collected:

$ psrinfo |wc -l
100

Sar shows that around that time, Idle CPU went from 100% to 99%.

So while starting 30 imapd processes is non-trivial work, is that really enough to saturate all the CPU and therefore enpd accepting connections took long enough to cause this problem?

Also, how much of a problem is it really?
Imapd will retry creating the connection to ENS when it needs it, correct?

Looking at the data further, all 30 imapd processes currently have 2 ENS connections.
So it seems to have recovered and done that about 10 seconds after startup.

The imapd processes seem to have a minimum of 6 threads:

* LWP#1, the main/dispatch thread
* 2 ENS threads
* 2 threads in accept()
* and 1 worker thread, idle, waiting for work

on a system which nominally has 100 (virtual) CPUs, starting 30 imapd processes could create 90 threads all trying to run at the same time, for a very brief time.
As each of those creates its 2 connections to enpd, enpd starts creating threads which need to run at the same time too.

So is this just "normal" considering this configuration with so many imapd processes?

Changes

Cause