[BugDB] open/146: consumes HUGE amounts of CPU after having served a request
I have the same problem on my solaris 2.5.1/apache 1.3.6/modssl 2.3.5/openssl 0.9.3a. any idea ? John PID USERNAME THR PRI NICE SIZE RES STATE TIMECPU COMMAND 19888 nobody 1 -150 3344K 2752K run20:17 97.78% httpd 20642 nobody 1 350 3200K 2416K sleep 0:00 1.32% httpd =>[1] _lseek(0x4400, 0x4400, 0x0, 0x0, 0x1, 0x1), at 0xef5b74fc [2] dbm_access(0x1c8960, 0x11, 0x1a, 0x30, 0x1f, 0x0), at 0xef5cf4ac [3] dbm_firsthash(0x1c8960, 0x11, 0x1c8988, 0x0, 0xefffecc8, 0x0), at 0xef5ceb54 [4] dbm_do_nextkey(0xc, 0x3c, 0x3c, 0x0, 0x1c8a4f, 0x11), at 0xef5cf2e4 [5] dbm_nextkey(0x1c8960, 0xef612f30, 0x0, 0x2, 0x0, 0xefffeddc), at 0xef5cecec [6] ssl_scache_dbm_expire(0x19d338, 0x37973457, 0x0, 0x0, 0x0, 0x0), at 0x45f60 [7] ssl_scache_expire(0x19d338, 0x37973457, 0x0, 0x7, 0x8001400, 0x0), at 0x451ec [8] ssl_scache_retrieve(0x19d338, 0x1c1a13, 0x20, 0x1aaf00, 0x9bc2c2a2, 0x0), at 0x44e84 [9] ssl_callback_GetSessionCacheEntry(0x1b2f00, 0x1c1a13, 0x20, 0xefffefc8, 0x3fcb8, 0xe014), at 0x3fd14 [10] ssl_get_prev_session(0x1b2f00, 0x1c1a13, 0x20, 0x0, 0x0, 0x1b9110), at 0xd5ea0 [11] 0xde428(0x5b, 0x1b2f00, 0x1c1a13, 0x20, 0x, 0xffae), at 0xde427 [12] ssl3_accept(0x1b2f00, 0x1b2f00, 0x2000, 0x3000, 0x2, 0x2190), at 0xddd40 [13] ssl23_get_client_hello(0x2000, 0x1b2f00, 0x0, 0x0, 0x0, 0x3), at 0xcfd00 [14] ssl23_accept(0x4000, 0x1b2f00, 0x2000, 0x2000, 0x1, 0x2210), at 0xcf420 [15] ssl_hook_NewConnection(0x1b6068, 0xef6fb6e4, 0x1, 0xe32c, 0x4, 0x1a2360), at 0x3bef8 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
[BugDB] open/146: consumes HUGE amounts of CPU after having served a request
I have the same problem on my solaris 2.5.1/apache 1.3.6/modssl 2.3.5/openssl 0.9.3a. any idea ? John PID USERNAME THR PRI NICE SIZE RES STATE TIMECPU COMMAND 19888 nobody 1 -150 3344K 2752K run20:17 97.78% httpd 20642 nobody 1 350 3200K 2416K sleep 0:00 1.32% httpd =>[1] _lseek(0x4400, 0x4400, 0x0, 0x0, 0x1, 0x1), at 0xef5b74fc [2] dbm_access(0x1c8960, 0x11, 0x1a, 0x30, 0x1f, 0x0), at 0xef5cf4ac [3] dbm_firsthash(0x1c8960, 0x11, 0x1c8988, 0x0, 0xefffecc8, 0x0), at 0xef5ceb54 [4] dbm_do_nextkey(0xc, 0x3c, 0x3c, 0x0, 0x1c8a4f, 0x11), at 0xef5cf2e4 [5] dbm_nextkey(0x1c8960, 0xef612f30, 0x0, 0x2, 0x0, 0xefffeddc), at 0xef5cecec [6] ssl_scache_dbm_expire(0x19d338, 0x37973457, 0x0, 0x0, 0x0, 0x0), at 0x45f60 [7] ssl_scache_expire(0x19d338, 0x37973457, 0x0, 0x7, 0x8001400, 0x0), at 0x451ec [8] ssl_scache_retrieve(0x19d338, 0x1c1a13, 0x20, 0x1aaf00, 0x9bc2c2a2, 0x0), at 0x44e84 [9] ssl_callback_GetSessionCacheEntry(0x1b2f00, 0x1c1a13, 0x20, 0xefffefc8, 0x3fcb8, 0xe014), at 0x3fd14 [10] ssl_get_prev_session(0x1b2f00, 0x1c1a13, 0x20, 0x0, 0x0, 0x1b9110), at 0xd5ea0 [11] 0xde428(0x5b, 0x1b2f00, 0x1c1a13, 0x20, 0x, 0xffae), at 0xde427 [12] ssl3_accept(0x1b2f00, 0x1b2f00, 0x2000, 0x3000, 0x2, 0x2190), at 0xddd40 [13] ssl23_get_client_hello(0x2000, 0x1b2f00, 0x0, 0x0, 0x0, 0x3), at 0xcfd00 [14] ssl23_accept(0x4000, 0x1b2f00, 0x2000, 0x2000, 0x1, 0x2210), at 0xcf420 [15] ssl_hook_NewConnection(0x1b6068, 0xef6fb6e4, 0x1, 0xe32c, 0x4, 0x1a2360), at 0x3bef8 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: [BugDB] open/146: consumes HUGE amounts of CPU after having served a request
On Fri, Jul 23, 1999, John Hynes wrote: > I have the same problem on my solaris 2.5.1/apache 1.3.6/modssl > 2.3.5/openssl 0.9.3a. > any idea ? I would try a different DBM library. For instance you can rebuild with --enable-rule=SSL_SDBM to get the built-in SDBM library instead. I buy a beer those guy who finds out why some vendor DBM libraries get crazy on the session cache expiring... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: [BugDB] open/146: consumes HUGE amounts of CPU after having served a request
On Fri, Jul 23, 1999, John Hynes wrote: > I have the same problem on my solaris 2.5.1/apache 1.3.6/modssl > 2.3.5/openssl 0.9.3a. > > PID USERNAME THR PRI NICE SIZE RES STATE TIMECPU COMMAND > 19888 nobody 1 -150 3344K 2752K run20:17 97.78% httpd > 20642 nobody 1 350 3200K 2416K sleep 0:00 1.32% httpd > > =>[1] _lseek(0x4400, 0x4400, 0x0, 0x0, 0x1, 0x1), at 0xef5b74fc > [2] dbm_access(0x1c8960, 0x11, 0x1a, 0x30, 0x1f, 0x0), at 0xef5cf4ac > [3] dbm_firsthash(0x1c8960, 0x11, 0x1c8988, 0x0, 0xefffecc8, 0x0), at > 0xef5ceb54 > [4] dbm_do_nextkey(0xc, 0x3c, 0x3c, 0x0, 0x1c8a4f, 0x11), at > 0xef5cf2e4 > [5] dbm_nextkey(0x1c8960, 0xef612f30, 0x0, 0x2, 0x0, 0xefffeddc), at > 0xef5cecec > [6] ssl_scache_dbm_expire(0x19d338, 0x37973457, 0x0, 0x0, 0x0, 0x0), For mod_ssl 2.3.7 I've now completely rewritten the ssl_scache_dbm_expire() function, because it seems that some DBM libraries get crazy when one iterates over the contents and deleting elements in parallel. The new function now uses a two pass approach where this should no longer happen (hopefully ;) When 2.3.7 is released, please upgrade. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]