[an error occurred while processing the directive]
![]() |
cosign-discuss at umich.edu |
general discussion of cosign development and deployment | |
On Fri, 2005-02-11 at 09:44, Wesley D Craig wrote: > 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 > > user time. > > 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 > > that. > > What was the performance like before doing preforks? What platform are > you running on? > Well, the improvement was really noticable. We dont prefork at all here now, but I have changed the SIGCHLD to ingore so I dont get all of the signals (and the children dont go zombie). I noticed a BIG improvement when we put the daemon and ticket directories onto TMPFS (kinda like RAM disk). > > 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 > tool takes. > > :wes >