cosign-discuss at umich.edu
general discussion of cosign development and deployment
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On 07 Feb 2005, at 18:28, Brett Lomas wrote:
I have been noticing an alarmingly high amount of time the application
(the cosign daemon) spends in the system. It can by up to 3 times the
Looking at one of our production servers, the ratio is even higher:
more like 1:10 to 1:20. This doesn't surprise me, particularly, as
cosignd doesn't really *do* very much. A typical cosignd transaction
is a network read, an open (in a big directory), a read, a close, a
network write. The most intense thing done in user space is crypto,
presuming the server doesn't have a crypto card.
This server that I'm looking at has 821 cosignd's running.
I am sure it is no the fork, because i have hacked at the daemon to
prefork a large number of children and handle the connections like
What was the performance like before doing preforks? What platform are
you running on?
When I do an strace of one of the daemons it give nothing which stands
out, except for the incredibly large number of getpid calls. I am to
understand this is the SSL Cyrpto multi-threaded support. I have gotten
ride of a lot of this because defining callbacks for these, and yet
still a high amount of system time is spent.
getpid() is pretty lightweight. I don't think it's OpenSSL's
multi-threaded support, but it *is* OpenSSL. Have you built cosignd
with profiling? I'd be interested to know what actions your profile