Link to home
Start Free TrialLog in
Avatar of rstaveley
rstaveleyFlag for United Kingdom of Great Britain and Northern Ireland

asked on

VmallocTotal

I have a server with 1G of physical RAM which shows the following procinfo:

[rob@seseiaa2 ~]$ cat /proc/meminfo                                            
MemTotal:      1025248 kB
MemFree:         84956 kB
Buffers:         88364 kB
Cached:         639300 kB
SwapCached:          0 kB
Active:         582188 kB
Inactive:       254848 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      1025248 kB
LowFree:         84956 kB
SwapTotal:     4008120 kB
SwapFree:      4003872 kB
Dirty:             284 kB
Writeback:           0 kB
Mapped:         177004 kB
Slab:            77724 kB
CommitLimit:   4520744 kB
Committed_AS:   316980 kB
PageTables:       6420 kB
VmallocTotal: 34359738367 kB

i.e. VmallocTotal is currently 7FFFFFFFF kB. Should I be alarmed?
Avatar of ravenpl
ravenpl
Flag of Poland image

Having 34TB vsize - it must ba a kernel bug...
Or many applications that uses only virtual memory(allocates, but never writes to it)
But in general it's acceptable to have vmalloctotal greater than physical RAM.
Avatar of rstaveley

ASKER

What applications would be likely to write to /proc/meminfo (assuming there's nothing malicious)?
No, it's not writing to /proc/meminfo.
Assume application does nothing more than malloc(2G memory), then sleeps forever. For each such application vmallocsize has to be bumped by another 2G. Hence real memory is not allocated as long, as the application does not write to the allocated memory.
If there is many such applications (eg. somebody forked it many times before malloc()) - Your kernel vsize will grow to fantastic value.
What more - vsize never shrinks, so the process may be gone already!

Again, in my opinion: either a bug or someone did it for (malicious) purpose.
I missed VmallocChunk from the bottom of that file...

VmallocTotal: 34359738367 kB
VmallocUsed:    264532 kB
VmallocChunk: 34359473359 kB

It is a 64-bit server, which means that malloc(34359473359) could have compiled.

What shouls I do to rectify the file? Does it self-correct on a reboot?
It will shrink on reboot - as I pointed above - vsize never shrinks.

> malloc(34359473359)
I would assume that this size is computed in runtime - and some overflow occured :(
Yuck, on reboot it is straight up there again.

VmallocTotal: 34359738367 kB
VmallocUsed:    264532 kB
VmallocChunk: 34359473359 kB

I guess I need to start removing services to find the offender.

What's the impact of having it as it is?
ASKER CERTIFIED SOLUTION
Avatar of ravenpl
ravenpl
Flag of Poland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
> init=/bin/bash

Unfortunately I only have remote access to the box. I've just upgraded the kernel and vmalloc the same.

I'll ignore it :-)