Question about RAM usage in VPS linux

[tufanv]

Hello,

I am currently having a problem with my vps provider. They claim that my server dies sometimes according to oom killer , high ram usage. I had to upgrade to a higher plan now but i still cant understand what the reality is .

Foe example htop shows ram usage of 1400 mb / 8192

but when i asked the support , they say that i have to use free -m which shows around 5.5 gb of ram usage but isnt it with buffers & isnt buffers can be considered as free ram ?

So what is the real need of my server ? is it 1400 or 5500 mb ?

Please help me understand so my vps provider cant make me upgrade without any need

Thanks

 

[sorex]

even if it's 5.5 where is the rest (2.5Gb) if they claim that all gets used ?

 

[lemonisdead]

I have no clear reply about but you should find which was consuming :

grep oom-killer /var/log/messages

Another thing to take in count is the amount of swap available (if I do recall correctly, oom won't kill till the swap isn't full or reached the reserved memory). Perhaps the swappiness is to low (vm.swappiness=). Perhaps they are too much files links opened too (vm.vfs_cache_pressure=) ?

 

[tufanv]

even if it's 5.5 where is the rest (2.5Gb) if they claim that all gets used ?

It is after the update Sorex. I had 4 gb ram before update when oom kill was happening. I needed to upgrade to 8 gb ram.

 

[tufanv]

I have no clear reply about but you should find which was consuming :

grep oom-killer /var/log/messages

Another thing to take in count is the amount of swap available (if I do recall correctly, oom won't kill till the swap isn't full or reached the reserved memory). Perhaps the swappiness is to low (vm.swappiness=). Perhaps they are too much files links opened too (vm.vfs_cache_pressure=) ?

command did not return anything.

 

[lemonisdead]

command did not return anything

I have to apologize because, if the provider did warn you about oom on his side, of course, the logs were on his part... Stupid me.
So, I think they are only two solutions there :
- or trying to ulimit your process to the amount of RAM you think it was consuming and check if the process gets killed on your side, or not (ulimit -a provides all the information about the limits of the current user)
- or trust the provider and accept to have increased the plan, without any regret

 

[tufanv]

I have to apologize because, if the provider did warn you about oom on his side, of course, the logs were on his part... Stupid me.
So, I think they are only two solutions there :
- or trying to ulimit your process to the amount of RAM you think it was consuming and check if the process gets killed on your side, or not (ulimit -a provides all the information about the limits of the current user)
- or trust the provider and accept to have increased the plan, without any regret

That's what i did : trust them

 

[Roycefer]

If it's of any use to you, the jAWTRobot library offers you programmatic access to lots of memory and cpu usage statistics.