Stub it out with LD_PRELOAD and I'll bet that you still have the same
performance problem.
Anything that feels the need to log 4000 times/sec is going to be
causing the performance problem with the log writing code, not the
getpid. I expect that your system could call getpid more than a
million times a second per CPU.
truss -cf on the process might give you a good hint on where the time
is going, don't worry about simple lightweight system calls like
getpid, you probably have writes going on....
Adrian
On 10/18/06, Dan Price <[EMAIL PROTECTED]> wrote:
On Wed 18 Oct 2006 at 08:01PM, Jason King wrote:
> We have a third party library (which we do not have the source for),
> that calls getpid() everytime it logs something. Unfortunately, in
> the application where the library is being used, this results in over
> 4000 getpid calls/sec (accounting for over half the total system
> calls/sec being made by all the threads in the application), causing
> performance issues under high load.
>
> While we are working with the vendor to see if they can deliver a fix,
> I'd like to have a plan B. Since the application itself forks very
> infrequently, I was thinking of interposing getpid() and caching the
> results upon first invocation.
>
> I was curious if anyone has any comments about potential pitfalls of
> doing this. The only things I can think of is possibly needing to
> also interpose fork(), fork1(), and forkall() to essentially reset the
> cached pid value so on next invocation (in either child or parent to
> hopefully make it easier) it'll just regrab the pid value and cache
> it. The only other thing is potential thread safety -- I'm not sure
> if assignment to pid_t or a pointer is atomic or not (or if I'd need
> to utilize the atomic_ops instructions). Any thoughts?
You might wish to have a look at pthread_atfork()...
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
