RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 948054 - replace PR_GetFileInfo with PR_GetFileInfo64
Summary: replace PR_GetFileInfo with PR_GetFileInfo64
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-03 21:03 UTC by Nathan Kinder
Modified: 2020-09-13 20:27 UTC (History)
4 users (show)

Fixed In Version: 389-ds-base-1.3.1.2-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 11:37:02 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 649 0 None None None 2020-09-13 20:27:19 UTC

Description Nathan Kinder 2013-04-03 21:03:05 UTC 
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47312

This is with the latest code, on a RHEL 6.4 64-bit machine.

[02/Apr/2013:17:26:38 -0400] - 389-Directory/1.3.1.pre.a1.git0472b98 B2013.092.2034 starting up
[02/Apr/2013:17:26:38 -0400] - WARNING: two: entry cache size 3897032704B is less than db size 2736742400B; We recommend to increase the entry cache size nsslapd-cachememsize.
[02/Apr/2013:17:26:38 -0400] - WARNING: one: entry cache size 3897032704B is less than db size 2736742400B; We recommend to increase the entry cache size nsslapd-cachememsize.

3897032704B is _greater_ than 2736742400B
Comment 2 Rich Megginson 2013-10-01 23:25:51 UTC 
moving all ON_QA bugs to MODIFIED in order to add them to the errata (can't add bugs in the ON_QA state to an errata).  When the errata is created, the bugs should be automatically moved back to ON_QA.
Comment 6 Amita Sharma 2014-01-17 11:34:38 UTC 
Test Case 1
***************
Under 2gb i.e. 1.9gb
====================
[root@cloud-qe-18 export]# ldapmodify -h localhost -p 389 -D "cn=directory manager" -w Secret123 <<EOF
dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 2111111111
EOF
modifying entry "cn=userRoot,cn=ldbm database,cn=plugins,cn=config"

[root@cloud-qe-18 export]# /usr/lib64/dirsrv/slapd-cloud-qe-18/stop-slapd

[root@cloud-qe-18 export]# ls -alh
total 2.2G
drwxr-xr-x.  2 root root   23 Jan 17 05:52 .
drwxr-xr-x. 18 root root 4.0K Jan 17 00:32 ..
-rw-r--r--.  1 root root 2.2G Jan 17 05:53 users.ldif


[root@cloud-qe-18 export]# ldif2db -Z slapd-cloud-qe-18 -n userRoot -i /export/users.ldif

[root@cloud-qe-18 export]# /usr/lib64/dirsrv/slapd-cloud-qe-18/start-slapd 
[root@cloud-qe-18 export]# 

error logs
===========
[17/Jan/2014:06:00:41 -0500] - import userRoot: Import complete.  Processed 1500006 entries in 331 seconds. (4531.74 entries/sec)
[17/Jan/2014:06:10:46 -0500] - 389-Directory/1.3.1.6 B2014.08.2017 starting up
[17/Jan/2014:06:10:46 -0500] - WARNING: userRoot: entry cache size 2111111111B is less than db size 4105109504B; We recommend to increase the entry cache size nsslapd-cachememsize.
[17/Jan/2014:06:10:46 -0500] - I'm resizing my cache now...cache was 2377965568 and is now 8000000
[17/Jan/2014:06:10:46 -0500] - slapd started.  Listening on All Interfaces port 389 for LDAP requests


Test Case 2
***************
Above 2gb i.e. 2.3gb
====================
ldapmodify -h localhost -p 389 -D "cn=directory manager" -w Secret123 <<EOF
> dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-cachememsize
> nsslapd-cachememsize: 2555555555
> EOF
modifying entry "cn=userRoot,cn=ldbm database,cn=plugins,cn=config"

stopped slapd and imported 2gb data, started slapd

error logs
===============
[17/Jan/2014:06:19:47 -0500] - All database threads now stopped
[17/Jan/2014:06:19:47 -0500] - import userRoot: Import complete.  Processed 1500006 entries in 315 seconds. (4761.92 entries/sec)
[17/Jan/2014:06:20:54 -0500] - 389-Directory/1.3.1.6 B2014.08.2017 starting up
[17/Jan/2014:06:20:54 -0500] - WARNING: userRoot: entry cache size 2555555555B is less than db size 4105109504B; We recommend to increase the entry cache size nsslapd-cachememsize.
[17/Jan/2014:06:20:54 -0500] - I'm resizing my cache now...cache was 2377965568 and is now 8000000
[17/Jan/2014:06:20:54 -0500] - slapd started.  Listening on All Interfaces port 389 for LDAP requests

Test Case 3
***************
Around 5gb
===============
[root@cloud-qe-18 export]# ldapmodify -h localhost -p 389 -D "cn=directory manager" -w Secret123 <<EOF
dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 6000000000
> EOF

stopped slapd and imported 2gb data, started slapd

logs
===
[17/Jan/2014:06:25:06 -0500] - slapd stopped.
[17/Jan/2014:06:25:17 -0500] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database
[17/Jan/2014:06:25:17 -0500] - check_and_set_import_cache: pagesize: 4096, pages: 4072837, procpages: 98457
[17/Jan/2014:06:25:17 -0500] - Import allocates 6516536KB import cache.
[17/Jan/2014:06:25:17 -0500] - Setting ncache to: 2 to keep each chunk below 4Gbytes
[17/Jan/2014:06:25:17 -0500] - import userRoot: Beginning import job...
[17/Jan/2014:06:25:17 -0500] - import userRoot: Index buffering enabled with bucket size 100
[17/Jan/2014:06:25:17 -0500] - import userRoot: Processing file "/export/users.ldif"
[17/Jan/2014:06:25:37 -0500] - import userRoot: Processed 144260 entries -- average rate 7200.4/sec, recent rate 7200.4/sec, hit ratio 0%
[17/Jan/2014:06:25:57 -0500] - import userRoot: Processed 281238 entries -- average rate 7027.2/sec, recent rate 7027.2/sec, hit ratio 100%
[17/Jan/2014:06:26:18 -0500] - import userRoot: Processed 415305 entries -- average rate 6808.1/sec, recent rate 6616.7/sec, hit ratio 100%
[17/Jan/2014:06:26:38 -0500] - import userRoot: Processed 547742 entries -- average rate 6762.2/sec, recent rate 6503.8/sec, hit ratio 100%
[17/Jan/2014:06:26:58 -0500] - import userRoot: Processed 679213 entries -- average rate 6724.9/sec, recent rate 6598.0/sec, hit ratio 100%
[17/Jan/2014:06:27:18 -0500] - import userRoot: Processed 809604 entries -- average rate 6690.1/sec, recent rate 6543.9/sec, hit ratio 100%
[17/Jan/2014:06:27:38 -0500] - import userRoot: Processed 939721 entries -- average rate 6664.4/sec, recent rate 6511.5/sec, hit ratio 100%
[17/Jan/2014:06:27:58 -0500] - import userRoot: Processed 1068731 entries -- average rate 6636.1/sec, recent rate 6472.8/sec, hit ratio 100%
[17/Jan/2014:06:28:19 -0500] - import userRoot: Processed 1196194 entries -- average rate 6571.4/sec, recent rate 6251.6/sec, hit ratio 100%
[17/Jan/2014:06:28:39 -0500] - import userRoot: Processed 1324513 entries -- average rate 6556.0/sec, recent rate 6241.7/sec, hit ratio 100%
[17/Jan/2014:06:28:59 -0500] - import userRoot: Processed 1452041 entries -- average rate 6540.7/sec, recent rate 6401.3/sec, hit ratio 100%
[17/Jan/2014:06:29:07 -0500] - import userRoot: Finished scanning file "/export/users.ldif" (1500006 entries)
[17/Jan/2014:06:29:07 -0500] - import userRoot: Workers finished; cleaning up...
[17/Jan/2014:06:29:08 -0500] - import userRoot: Workers cleaned up.
[17/Jan/2014:06:29:08 -0500] - import userRoot: Cleaning up producer thread...
[17/Jan/2014:06:29:08 -0500] - import userRoot: Indexing complete.  Post-processing...
[17/Jan/2014:06:29:08 -0500] - import userRoot: Generating numSubordinates complete.
[17/Jan/2014:06:29:13 -0500] - import userRoot: Flushing caches...
[17/Jan/2014:06:29:13 -0500] - import userRoot: Closing files...
[17/Jan/2014:06:30:35 -0500] - All database threads now stopped
[17/Jan/2014:06:30:35 -0500] - import userRoot: Import complete.  Processed 1500006 entries in 318 seconds. (4717.00 entries/sec)
[17/Jan/2014:06:30:50 -0500] - 389-Directory/1.3.1.6 B2014.08.2017 starting up
[17/Jan/2014:06:30:50 -0500] - I'm resizing my cache now...cache was 2377965568 and is now 8000000
[17/Jan/2014:06:30:50 -0500] - slapd started.  Listening on All Interfaces port 389 for LDAP requests

NOTE :: Warning messages in test case 1 and 2, which I guess are correct.
Rich please verify once, thanks.
Comment 7 Rich Megginson 2014-01-20 15:49:01 UTC 
Yes, this is correct.  Note that the size of the ldif file is not the same as the size of the database (the id2entry.db file).

You will still see this message:

[17/Jan/2014:06:20:54 -0500] - WARNING: userRoot: entry cache size 2555555555B is less than db size 4105109504B; We recommend to increase the entry cache size nsslapd-cachememsize.

when the nsslapd-cachememsize is less than the size of the id2entry.db file.  This is ok.  You should make sure that you do not see this message when the size of nsslapd-cachememsize is greater than the size of id2entry.db.   You should also make sure that when the sizes (of anything) are greater than 4GB, the sizes are reported correctly.
Comment 8 Amita Sharma 2014-01-21 09:13:38 UTC 
(In reply to Rich Megginson from comment #7)
> Yes, this is correct.  Note that the size of the ldif file is not the same
> as the size of the database (the id2entry.db file).
> 
> You will still see this message:
> 
> [17/Jan/2014:06:20:54 -0500] - WARNING: userRoot: entry cache size
> 2555555555B is less than db size 4105109504B; We recommend to increase the
> entry cache size nsslapd-cachememsize.
> 
> when the nsslapd-cachememsize is less than the size of the id2entry.db file.
> This is ok.  You should make sure that you do not see this message when the
> size of nsslapd-cachememsize is greater than the size of id2entry.db.   You
> should also make sure that when the sizes (of anything) are greater than
> 4GB, the sizes are reported correctly.

All the stated test cases are tested and VERIFIED correctly.
Hence marking the bug as VERIFIED
Comment 9 Ludek Smid 2014-06-13 11:37:02 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.
Note You need to log in before you can comment on or make changes to this bug.