[389-users] 389 Memory issue

[Moisés Barba Pérez]

Hi,

   I'm having a memory issue with 389 Directory server. The problem "*cannot
allocate memory*" appears very often and don't find the source.

   The exactly log is this:

memory allocator - malloc of 4629376 bytes failed; OS error 12 (Cannot
> allocate memory)
> The server has probably allocated all available virtual memory. To solve
> this problem, make more virtual memory available to your server, or reduce
> one or more of the following server configuration settings:
>   nsslapd-cachesize        (Database Settings - Maximum entries in cache)
>   nsslapd-cachememsize     (Database Settings - Memory available for cache)
>   nsslapd-dbcachesize      (LDBM Plug-in Settings - Maximum cache size)
>   nsslapd-import-cachesize (LDBM Plug-in Settings - Import cache size).
> Can't recover; calling exit(1).
>


   - The server is a CentOS 5.5 32bits with
   2.6.18-194.3.1.el5.centos.plusPAE kernel. The server has 12G memory, I know
   that a 32bits kernel can't manage 12G but the kelnel is PAE so I can use
   about 4G and the server never rise this value of used memory before crash.
   5G of swap. 8 processors.



   - The directory server is 389-ds-base-1.2.5-1.el5, with 27 different db.
   I have about 40k users in the directory. I have been talking in irc channel
   with Rich about directory caches and y I have try with this configurations
   without a resolution for the problem:


dbcachesize = 2 * (SUM all .db4 size) | each cachememsize = 10M (default) ->
fails
dbcachesize = 10M (default) | db$i cachememsize = 2 * (db$i/id2entry.db4
size) -> fails
dbcachesize = 10M (default) | db$i cachememsize = 4 * (db$i/id2entry.db4
size) -> fails

Te SUM for all .db4 files size is about 800M.

I have monitor the db with *db_stat* comand and I get always a entry ratio
for id2entry db betwen 50 and 60% in all cases. The value for
max-file-descriptors in 389 is 65355. The size of the hugepagesize is 2M.
This is the ulimit -a results:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 208896
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 64000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 1024
cpu time               (seconds, -t) unlimited
max user processes              (-u) 208896
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited


I have read in Metalink an error for sun one directory server 5.2 that this
problem can be caused because of "multiple memory pool" but I couldn't find
where it is configured (I guess 389 split from sun one in this version). And
I don't know if it is important to my problem.

The OS error 12 is a default message from operating system for memory
allocation and I'm thinking in a linux scheduler problem, but I don't find
nothing.

If somebody have an idea, please tell me...

Regards,

Moses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20110318/a9dbb885/attachment.html>