Bug 136416 - (IT#37016) libdb-4.1 sleeps too often in memory pool allocation; regression from 4.0 fixed in 4.2
libdb-4.1 sleeps too often in memory pool allocation; regression from 4.0 fix...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: db4 (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
: 138818 (view as bug list)
Depends On:
Blocks: 132991
  Show dependency treegraph
 
Reported: 2004-10-19 17:07 EDT by Alexandre Oliva
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-14 01:22:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 17:13 EDT, Alexandre Oliva
no flags Details | Diff

  None (edit)
Description Alexandre Oliva 2004-10-19 17:07:56 EDT
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 17:13:21 EDT
Created attachment 105466 [details]
Back-port of the sleep-avoidance patch from 4.2.
Comment 3 Jeff Johnson 2004-10-20 00:32:16 EDT
Yup.

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 07:40:23 EST
*** Bug 138818 has been marked as a duplicate of this bug. ***
Comment 7 Jindrich Novy 2004-11-11 07:49:57 EST
Sure, I'll check it.
Comment 8 Jeff Johnson 2004-11-14 00:07:30 EST
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 00:28:33 EST
There is also patch.4.1.25.2 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 01:22:01 EST
Should be fixed by adding patch.4.1.25.2 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 08:53:21 EDT
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.

http://rhn.redhat.com/errata/RHBA-2005-279.html

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