Bug 136416 (IT#37016) - libdb-4.1 sleeps too often in memory pool allocation; regression from 4.0 fixed in 4.2
Summary: libdb-4.1 sleeps too often in memory pool allocation; regression from 4.0 fix...
Alias: IT#37016
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: db4 (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: All Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
: 138818 (view as bug list)
Depends On:
Blocks: 132991
TreeView+ depends on / blocked
Reported: 2004-10-19 21:07 UTC by Alexandre Oliva
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-14 06:22:01 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Back-port of the sleep-avoidance patch from 4.2. (7.53 KB, patch)
2004-10-19 21:13 UTC, Alexandre Oliva
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:279 normal SHIPPED_LIVE db4 bug fix update 2005-05-19 04:00:00 UTC

Description Alexandre Oliva 2004-10-19 21:07:56 UTC
A customer got a severe performance regression while running
newaliases on a very big aliases file.  The problem was eventually
tracked down to calls to select(0, NULL, NULL, NULL, { 1, 0 }) from
within the memory pool allocator (through __os_sleep(1, 0)), that
intends to give other threads some time to free up memory.  The code
in 4.2 was slightly reworked so as to avoid calling __os_sleep() as
often as it did in 4.1, so I've backported a patch and verified that
it removes all of the extraneous select calls.  The ABI apparently
doesn't change, in spite of adding a field to a struct; AFAICT, it's
an internal struct, whose size doesn't matter to external users. 
Double-checking is advised.  I've grepped for all uses of the new
field in 4.2, and found only one hit outside mp_alloc.c.

Comment 1 Alexandre Oliva 2004-10-19 21:13:21 UTC
Created attachment 105466 [details]
Back-port of the sleep-avoidance patch from 4.2.

Comment 3 Jeff Johnson 2004-10-20 04:32:16 UTC

There was a simple perl reproducer with 5000 records
that ran an order of magnitude more slowly with db-4.1.25
than with db-4.0.14 or db-4.2.52. The bug is probably
reassigned to perl.

Comment 5 Florian La Roche 2004-11-11 12:40:23 UTC
*** Bug 138818 has been marked as a duplicate of this bug. ***

Comment 7 Jindrich Novy 2004-11-11 12:49:57 UTC
Sure, I'll check it.

Comment 8 Jeff Johnson 2004-11-14 05:07:30 UTC
I've already verified, there is a slow down.

The test case is in bugzilla, assigned against perl.
A straightforward 5000 entry perl database is an order
of magnitude slower with db-4.1.25 than with either
db-4.0.14 or db-4.2.52.

I'm gonna grab this bug, since I'm rebuilding
Berkeley DB and resolving db4 bugs this weekend.

Comment 9 Jeff Johnson 2004-11-14 05:28:33 UTC
There is also patch. from sleepycat that appears
to address exactly the same issues that aoliva's patch does.

In fact the patches are nearly identical, one unified, the other not.

Comment 10 Jeff Johnson 2004-11-14 06:22:01 UTC
Should be fixed by adding patch. from sleepycat.

db4-4.1.25-9 headed for CVS and next RHEL3 update tomorrow,
currently staged at ftp://jbj.org/pub/fc4.

Comment 11 Tim Powers 2005-05-19 12:53:21 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.