| Summary: | nscd cannot extend memory heap sizes | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Nick Burrett <nick> |
| Component: | nscd | Assignee: | Ulrich Drepper <drepper.fsp> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | glibc-bugs |
| Priority: | P2 | Flags: | fweimer:
security-
|
| Version: | 2.3.5 | ||
| Target Milestone: | --- | ||
| Host: | i686-pc-linux-gnu | Target: | i686-pc-linux-gnu |
| Build: | i686-pc-linux-gnu | Last reconfirmed: | |
> Can we not use malloc and realloc instead ?
You don't understand the code *at all*. Using malloc et al is of course
completely out of question since it would neither allow persistence nor sharing.
There was a problem with the mremap handling. This is fixed in the current code.
Note that this bug still appears to exist 8 months later in RHEL 4.2 with 'nscd' 2.3.4. |
The change in nscd to use mmap for memory allocation of caches presents a problem in that once the cache is full, mempool_alloc cannot extend the size of the cache because 'mremap' will always fail. 4279: no more memory for database 'group' $ nscd -g shows: 216064 total data pool size 214664 used data pool size 7 memory allocations failed The problem is that for a system with large group memberships (i.e. several thousand users), which are held in LDAP databases, as pool sizes cannot increase, the result is poor performance, with commands such as a simple 'ls' taking 10-20 seconds to complete. The group lookup cannot be cached because there is no further space to hold the data. Certainly it is possible to work around this problem by increasing 'suggested-size' from say 211 to 10007, but clearly the 'mremap' is going to fail in any case. Can we not use malloc and realloc instead ?