• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3738
  • Last Modified:

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?
0
rstaveley
Asked:
rstaveley
  • 4
  • 4
1 Solution
 
ravenplCommented:
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.
0
 
rstaveleyAuthor Commented:
What applications would be likely to write to /proc/meminfo (assuming there's nothing malicious)?
0
 
ravenplCommented:
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.
0
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

 
rstaveleyAuthor Commented:
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?
0
 
ravenplCommented:
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 :(
0
 
rstaveleyAuthor Commented:
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?
0
 
ravenplCommented:
I think no need for that, finally I read doc which says:
VmallocTotal: total size of vmalloc memory area
VmallocUsed: amount of vmalloc area which is used
VmallocChunk: largest contigious block of vmalloc area which is free

I understand now, that it's the space available for kernel to grow the virtual mem size (not used).
It looks like Your kernel has some overcommiting turned on.
To verify, just run the system with "init=/bin/bash" option passed to the kernel. Mount the /proc and check those values.

Unfortunatelly currenty have no system with 64bit accessible - maybe other experts?
0
 
rstaveleyAuthor Commented:
> 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 :-)
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now