Would you post this again as a patch against apr/STATUS? Great observations - explains some wierdness we've been observing lately with SSL on Solaris.
Bill At 01:27 AM 3/27/2003, you wrote: >I would like to close the following issue with a README addition. > >Excerpt from STATUS: >==================== > * fcntl() oddness on Solaris. Under high loads, fcntl() decides to > return error code 46 (ENOLCK). > > httpd (prefork MPM) error log says (predictably): > > (46)No record locks available: couldn't grab the accept mutex > > All of the children report this and subsequently exits. httpd is >now > hosed. AFAICT, this does not look to be an out-of-fds error. > > Solaris's man page says: > ENOLCK > The cmd argument is F_SETLK, F_SETLK64, F_SETLKW, or > F_SETLKW64 and satisfying the lock or unlock request > would result in the number of locked regions in the > system exceeding a system-imposed limit. > > Justin says: What is this system-imposed limit and how do we >change it? > This gives me more rationale for switching the >default > interprocess lock mechanism to pthread (if >available). >============ > > >Explanation: >============ > The system imposed default limit of outstanding lock requests is 512. >You can verify this by, in a contemporary version of Solaris: > > # mdb -k > > tune_t_flckrec/D > tune_t_flckrec: > tune_t_flckrec: 512 > > This can be increased by adding the following to /etc/system: > > set tune_t_flckrec=1024 > > and rebooting. > > Of course "1024" can be any reasonable limit, although I do not know >what "reasonable" should be, so be conservative, only increase this as >necessary. >============ > > >Notes: >====== > If someone would please test this on a system known to break that >would be great. In addition it is mentioned that *all* of the children >report this, is it actually all of them, or all of them after a certain >threshold? > > > /kristofer
