2

I've seen the opposite of this, but this is puzzling.

In short, I have a process where %MEM claims to use 74% of memory when using 'ps' and 'top'. However, 'free' shows that I'm only using 32% of the available memory.

Here is this output of 'top':

top - 18:25:49 up 203 days, 14 min,  1 user,  load average: 3.48, 3.75, 3.79
Tasks: 349 total,   1 running, 347 sleeping,   1 stopped,   0 zombie
Cpu(s): 10.3%us,  4.7%sy,  0.0%ni, 75.1%id,  6.5%wa,  0.0%hi,  3.4%si,0.0%st
Mem:   189.054G total,  188.280G used,  793.473M free,  253.570M buffers
Swap: 4095.996M total,  967.234M used, 3128.762M free,  126.370G cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
14416 root      20   0  165g 139g  81g S 250.3 74.0 764266:39 asd
30660 root      20   0 15164 1328  836 R  2.0  0.0   0:00.01 top

You will notice that the 'asd' process claims to use 74% (139g) of the available RAM. If you look at the total memory used - the cached memory (188-126), it looks like the entire system is only using 62G. That is obviously much lower that the one process 'asd' claims to use.

'free' is just as confusing. It shows 61G free:

# free -g
         total       used       free     shared    buffers     cached
Mem:           189        188          0         81          0        126
-/+ buffers/cache:         61        127
Swap:            3          0          3

'ps' seems to agree with the process listing in 'top':

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     14416  261 74.0 173381464 146791980 ? Ssl  Jan25 764310:00 /usr/bin/asd

I understand why 'free' would claim there is less memory available than 'top', but I don't see how a process can claim to use more RAM than the overall system reports as 'used'.

UPDATE: I don't think this is the same as the posts you pointed me to Tim. Those appear to reference the opposite issue where people either mis-read the 'free' output and don't take into account the cache and buffers. Consequently, they can't find processes that are using the memory they think 'free' is claiming to use. In my case, I have a process that is claiming to use a lot of memory, but 'free' seems to think that memory is still available.

  • 2
    Possible duplicate of [Why is Linux reporting "free" memory strangely?](https://serverfault.com/questions/449296/why-is-linux-reporting-free-memory-strangely) – Tim Aug 16 '17 at 19:20
  • You may want to consider updating the title of your question. While your update is asking something that isn't a dup the title makes your question seem like it is. Your question would be better if the title and body make it clear that you want to know why a process seems to be using more memory then is currently 'used'. – Zoredache Aug 16 '17 at 20:02

1 Answers1

2

I think there is simple explanation, difference between free and top with ps. If you check top output, you'll see 126.370G cached memory, that memory free show as a available memory. How it count. You have 189.054G total memory, your process use 139G resident memory, so you should have 50G memory for buffers and etc. If you check your process shared memory, you'll see that it have 81G shared memory, it could count in your resident memory. So, if your process work with files, they could be located in buffers and share with your process(it only assumption, i don't know how shared memory count with files). So that's only one reason to have so much free space.

Alexander Tolkachev
  • 4,513
  • 3
  • 14
  • 23
  • Are you saying that shared memory looks like free memory to 'free'? That memory wouldn't actually be free would it? It's only available to other processes with the same key, so it's not really available to unrelated processes, right? It seems like it should count against the total available memory? That said, it looks like your math works out even though I'm still a little confused why shared memory is reported in resident AND free memory. – Joel Griffiths Aug 17 '17 at 18:34
  • @JoelGriffiths You could try to flush buffers and check how many memory you see free. – Alexander Tolkachev Aug 17 '17 at 19:34