How do you check disk space and memory usage on a Linux server?
Use df -h to see free space on each mounted file system, du -sh to see how much space a folder takes, and free -h to see RAM and swap. In free, look at the "available" column, not "free", because Linux uses spare RAM as disk cache and gives it back when programs need it.
Explain it simply
Think of your phone's storage screen. One view tells you "64 GB of 128 GB used" for the whole phone. Another view lists which apps take the most space. On Linux, df is the first view (each disk), and du is the second (each folder). free is like the RAM view in a task manager.
Example
df: free space per file system
df -hFilesystem Size Used Avail Use% Mounted on
/dev/sda2 98G 61G 32G 66% /
/dev/sdb1 492G 410G 57G 88% /data
tmpfs 3.9G 0 3.9G 0% /dev/shm-h means human-readable sizes. Size is often a little more than Used plus Avail because some space is reserved for the root user.
du: which folders are big
du -sh /var/log
du -h --max-depth=1 /var | sort -h4.0K /var/opt
1.2G /var/cache
3.8G /var/log
5.1G /var-s gives one total, and --max-depth=1 shows one level of subfolders. Sorting with sort -h puts the biggest at the bottom.
free: memory
free -h total used free shared buff/cache available
Mem: 7.7Gi 2.1Gi 3.2Gi 210Mi 2.4Gi 5.2Gi
Swap: 2.0Gi 0B 2.0GiHere programs use 2.1 GiB, and about 5.2 GiB is available for new programs. The 2.4 GiB in buff/cache is mostly file data Linux has kept in memory to speed up reads.
How it works
df asks each mounted file system how many blocks it has and how many are free. du walks through a folder and adds up the space used by each file it finds. Because they measure in different ways, their numbers can disagree.
For memory, Linux deliberately fills unused RAM with page cache. Empty RAM does no work, so the kernel keeps recently read files there. When a program needs memory, clean cache pages are dropped instantly. That is why the "free" column on a healthy server is often small and the "available" column is the one that matters. Steadily growing swap use with low "available" means the machine really is short of memory.
Other useful commands: top or htop for live per-process memory and CPU, vmstat 1 to watch swapping (si/so columns), and df -i to check inodes.
Real-world use
- A deployment fails with "No space left on device": run
df -h, thenduon the full mount to find the culprit, often old logs or Docker images. - A Java or Node service is slow: check
free -handtopto see if it is swapping. - Monitoring tools like Prometheus node exporter collect these same numbers.
Common mistakes
- Panicking because "free" memory is low. Check "available" first.
- Running
du -sh /without2>/dev/nulland drowning in permission errors, or withoutsudoand getting incomplete totals. - Ignoring inodes. A disk can show free space in
df -hbut still refuse new files becausedf -ishows 100% inode use, usually from millions of tiny files.
What to say in the interview
"For disk I use df -h to see usage per mounted file system and du -sh or du -h --max-depth=1 | sort -h to find which folders are taking the space. I also check df -i for inode exhaustion. For memory I use free -h and read the available column, because Linux uses spare RAM as page cache and frees it on demand, so low free memory alone is not a problem. If available is low and swap is growing, I look at top to find the process using the most memory."
Follow-up questions
dfshows the disk is full butducannot find the files. Why?- What is swap, and when is using it a problem?
- What is the OOM killer?
- How do you find the 10 largest files on a system?
Go deeper
Read these once the basics above feel easy.
df and du disagree. The usual cause is a deleted file that a running process still has open, very often a log file removed while the app keeps writing to it. The name is gone, so du does not count it, but the blocks are not freed until the process closes the file, so df still counts them. Find such files with lsof +L1 (open files with a link count below 1). Restarting the process, or truncating the file through /proc/<pid>/fd/<n>, releases the space. The safer habit is to empty a live log with > app.log (or truncate -s 0 app.log) rather than deleting it.