Thank you Rainer,
yes the current memory status seems o.k.
But what I find strange or maybe simple bad coding, is the fact, that
especially the
OES processes like ndsd, novell-xsrvd etc. are
allocating memory, that they are apparently not using in any way, in
such an excessive way that the total available memory is overcommitted
by more than 4 GB.
I do not find it sane to allocate memory, which is not available at all
and thereby maybe blocking resources for processes, which need them
really.
I tested further and found, that it is impossible to fully boot an
OES
server with a swap partition of 2 GB (which is the standard
recommendation for SLES) if overcommit_memory is set to 2. Because of
this excessive memory allocations it seems to be necessary to use swap
space of at least 8 GB to accommodate the total memory allocations of
the
OES processes.
This is all on OES2 SP1 32 bit.
--
W. Prindl
brunold wrote:
>
>W. Prindl,
>
>> MemTotal: 2076836 kB
>> MemFree: 63192 kB
>> Buffers: 69056 kB
>> Cached: 1181820 kB
>
>Just a short summary on this ... The server has 2 GB and shows about
>63MB free. Buffers and Cache are allocated together with 1250MB. This
>both values can decrease in case another program wants to allocate new
>memory. So in combination something like 1313MB are available for
>applications. SO that is fine.
>
>The VIRT output from top is explained in the man page as the
>following:
>
>
>Code:
>--------------------
> o: VIRT -- Virtual Image (kb)
> The total amount of virtual memory used by the task. It includes
> all code, data and shared libraries plus pages that have been
> swapped out.
>--------------------
>
>
>
>So it also contains the all code, data and shared libraries. So you
>would need to start with the value of RES (physical used memory) and
>add all libraries, all the binaries that are used and so on. In case
>you have set the preallocation option for edirectory, you need to
>count that as well. That is not all loaded into the memory. It is
>just counted all together in that column.
>
>Rainer