Emptying the buffers cache
If you ever want to empty it you can use this chain of commands.
# free && sync && echo 3 > /proc/sys/vm/drop_caches && free
total used free shared buffers cached
Mem: 1018916 980832 38084 0 46924 355764
-/+ buffers/cache: 578144 ...
NOTE: I'm going to assume that your machine has a memory mapping unit (MMU). There is a Linux version (µClinux) that doesn't require an MMU, and this answer doesn't apply there.
What is an MMU? It's hardware—part of the processor and/or memory controller. Understanding shared library linking doesn't require you to understand exactly how an MMU works, just ...
The time(1) command (you may need to install it -perhaps as the time package-, it should be in /usr/bin/time) accepts many arguments, including a format string (with -f or --format) which understands (among others)
%M Maximum resident set size of the process during its lifetime,
%K Average total (data+stack+text) memory use ...
What might be happening if a process is "killed due to low RAM"?
It's sometimes said that linux by default never denies requests for more memory from application code -- e.g. malloc().1 This is not in fact true; the default uses a heuristic whereby
Obvious overcommits of address space are refused. Used
for a typical system. It ...
Kernel is a bit of a misnomer. The Linux kernel is comprised of several proceses/threads + the modules (lsmod) so to get a complete picture you'd need to look at the whole ball and not just a single component.
Incidentally mine shows slabtop:
Active / Total Size (% used) : 173428.30K / 204497.61K (84.8%)
The man page for slabtop also had this to ...
There is no need to do this, the kernel manages RAM efficiently by using it for caches and buffers if it is not needed by processes. If processes request more RAM the kernel will deallocate caches and buffers if necessary to satisfy the request.
This ServerFault answer explains how to interpret the memory usage reported by free.
There is this tutorial titled: Bad Memory HowTo which discusses disabling memory via the kernel using the memmap argument to the kernel. According to the howto you have 2 options when it comes to memmap:
Turn off everything after the bad memory - (mem=###M option)
Turn off just the memory around the bad memory - (memmap=#M$###M option)
With the ...
What this is telling you is that you have 16GB of virtual memory.
Virtual memory is the total of physical RAM and swap space added up.
It's a way of letting your system run more programs than it physically has the space for.
How much swap should be allocated to a machine is a complicated and opinionated question; ask 2 people and get 3 answers :-)
Check out this How do I detect the RAM memory chip specification from within a Linux machine question.
This tool might help:
$ sudo dmidecode --type 17 | more
# dmidecode 2.9
SMBIOS 2.4 present.
Handle 0x0018, DMI type 17, 27 bytes
Array Handle: 0x0017
decode-dimms is probably what you're looking for, but apparently you need to have the correct i2c module loaded before it works. Follow this tutorial:
I got it working after these steps:
sudo aptitude install i2c-tools
sudo modprobe eeprom
sudo modprobe i2c-i801
If you care only about the sizes, try lscpu from util-linux.
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
On-line CPU(s) list: 0-3
Thread(s) per core: 2
Core(s) per socket: 2
NUMA node(s): 1
Vendor ID: ...
Run dmidecode. The "Interleaved Data Depth" gives the number of channels.
Dual-channel memory has an interleaved depth of 2.
Handle 0x0041, DMI type 20, 35 bytes
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x001FFFFFFFF
Range Size: 8 GB
Physical Device Handle: 0x0040
Memory Array Mapped Address Handle: 0x0049
Partition Row ...
You don't have to do all that, you can just mount /tmp as tmpfs by using a line like the following in /etc/fstab:
tmpfs /tmp tmpfs mode=1777,nosuid,nodev 0 0
You can also do it live (but bear in mind stuff that is currently in /tmp on your current filesystem will not be able to be accessed except through the inode and currently open file descriptors, so ...
Unused RAM is wasted RAM. The Linux kernel has advanced memory management features and tries to avoid putting a burden on the bottleneck in your system, your hard drive/SSD. It tries to cache files in memory.
The memory management system works in complex ways, better performance is the goal.
You can see what it is doing by inspecting /proc/meminfo.
/etc/default/tmpfs is for sysvinit, for systemd (Debian default since jessie) you only need to do:
systemctl enable tmp.mount
and on Debian Stretch
cp /usr/share/systemd/tmp.mount /etc/systemd/system/
systemctl enable tmp.mount
see changelog on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787542#74
You can also use the legendary valgrind, although you may need to install it from your package manager.
$ valgrind c-projects/objtest/bin/objtest
==6543== Memcheck, a memory error detector
==6543== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==6543== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
This won't happen to you if you only ever load 1G of data into memory. What if you load much much more? For example, I often work with huge files containing millions of probabilities which need to be loaded into R. This takes about 16GB of RAM.
Running the above process on my laptop will cause it to start swapping like crazy as soon as my 8GB of RAM have ...
First, if your BIOS/UEFI does not detect correctly your RAM, then your OS won't do any better. There's no need to go any further if your BIOS display incorrect information about your setup.
=> You probably have at least an hardware problem.
EDIT: From your dmesg | grep memory, it seems that you have in fact an hardware problem, located in your embedded ...
Memtest86+ (I used 4.20) can output a badram format directly.
Press 'c' to reach the configuration dialogue
Then '4' for "Error Report Mode"
Then '3' for "BadRAM Patterns"
The output will change from a list of individual test failures to a series of badram= lines, each containing one more new bad sector. Because the lines append and coalesce adjacent ...
Since you don't seem to accept neither our opinions not the various pages we have linked to as 'official', perhaps the official Red Hat documentation will convince you:
In this example the total amount of available memory is 4040360 KB.
264224 KB are used by processes and 3776136 KB are free for other
applications. Do not get confused by the first ...
It appears that there is no surefire way to tell, however various approaches can get you some sort of answer. Apparently you pretty much have to try the different ones until you find one that tells you ECC is working.
In my case memtest86+ 4.20 couldn't be coaxed into realizing it was dealing with ECC RAM; even if I configured it for ECC On, it still ...
man free command solve my problem.
free displays the total amount of free and used physical and swap mem‐
ory in the system, as well as the buffers and caches used by the ker‐
nel. The information is gathered by parsing /proc/meminfo. The dis‐
played columns are:
total Total installed memory (MemTotal ...
New answer (2015-03-22)
(Note: This answer is simpler than previous, but not more secure. My first answer is stronger because you could keep files read-only by fs mount options before permission flags. So forcing to write a files without permission to write won't work at all.)
Yes, under Debian, there is a package: fsprotect (homepage).
It use aufs (by ...
A complete re-write of my previous post. Got a bit curious and checked out further.
In short: the reason for the difference is that openSUSE uses a patched version of top and free that adds some extra values to `cached'.
A) Standard version
top, free, htop, ...:
Usage is calculated by reading data from /proc/meminfo:
Row Column | ...
OpenVZ & Memory
The failcnt is going up on privvmpages, so your container is unable to allocate any more virtual memory space from the host:
root@server: ~ # cat /proc/user_beancounters
uid resource held maxheld barrier limit failcnt
What you're experiencing is an Error Detection and Correction event. Given the error includes this bit: MC0 you're experiencing a memory error. This message is telling you where specifically you're experiencing the error. MC0 means the RAM in the first socket (#0). The rest of that message is telling you specifically within that RAM DIMM the error occurred.
You don't need to do so.
There are two possiblities, if there is something in the cache:
it is needed again
it is not needed again
In the first case, it is better if it remains in RAM as long as possible, which means: another process needs the RAM. Then it is discarded automatically without your intervention.
In the second case, it doesn't disturb. It'...