Virtual Memory — Deep Basics

We now move from processes into one of the most fundamental parts of operating-system science:

How does Linux give each process its own memory environment while all processes ultimately share physical RAM?

The answer is virtual memory.

---

1. Start With Physical RAM

Suppose your VPS has:

4 GB RAM

Physically, there is a finite amount of memory.

Conceptually:

Physical RAM
┌──────────────────────────────┐
│                              │
│          4 GB                │
│                              │
└──────────────────────────────┘

But Linux may have many processes:

Nginx
PHP-FPM
MySQL
SSH
systemd
WordPress
Cron
...

They all need memory.

---

2. The First Question

If there is only:

4 GB physical RAM

how can each process behave as though it has its own memory?

Linux creates a:

Virtual Address Space

for each process.

---

3. Virtual Memory

The simplified model is:

Process
   ↓
Virtual address space
   ↓
Linux memory management
   ↓
Physical RAM

The process normally works with virtual addresses, not raw physical RAM addresses.

---

4. Each Process Gets Its Own Address Space

Imagine:

Process A
┌─────────────────────┐
│ Virtual memory      │
└─────────────────────┘

Process B
┌─────────────────────┐
│ Virtual memory      │
└─────────────────────┘

Process C
┌─────────────────────┐
│ Virtual memory      │
└─────────────────────┘

These address spaces are normally isolated.

So one process cannot simply read another process’s memory.

This is a fundamental security mechanism.

---

5. Why Isolation Matters

Imagine:

PHP-FPM worker A

contains sensitive data.

Another process:

PHP-FPM worker B

should not simply be able to read it.

Virtual memory and hardware memory protection help enforce this isolation.

---

6. Virtual Address

A program may access an address such as:

0x7ffd12345678

This is a virtual address from the process’s perspective.

It isn’t necessarily the actual physical location in RAM.

The system translates it.

---

7. The Translation

Conceptually:

Virtual Address
      ↓
Memory Management Unit
      ↓
Physical Address
      ↓
RAM

The hardware component involved is commonly called:

MMU — Memory Management Unit

---

8. CPU + MMU

Modern CPUs contain hardware mechanisms for virtual-memory translation.

Conceptually:

CPU
 │
 │ virtual address
 ▼
MMU
 │
 │ physical address
 ▼
RAM

The operating system configures the translation structures.

---

9. Why Not Use Physical Addresses Directly?

If every application directly controlled physical RAM:

Application A
      ↓
RAM

Application B
      ↓
RAM

they could potentially overwrite each other’s memory.

That would be extremely dangerous.

Instead:

Application A
 ↓
Virtual address space
 ↓
controlled physical mappings

Application B
 ↓
different virtual address space
 ↓
different mappings

---

10. Memory Protection

Virtual memory allows the operating system to enforce properties such as:

Readable
Writable
Executable
User-accessible
Kernel-only

So memory isn’t just:

"available"

It also has access permissions.

---

11. Pages

Virtual memory is generally divided into fixed-size blocks called:

Pages

A common page size is:

4 KB

although systems can support other page sizes.

---

12. Physical Frames

Physical memory is similarly managed in units often called:

Page frames

Conceptually:

Virtual memory
┌──────┬──────┬──────┬──────┐
│Page  │Page  │Page  │Page  │
└──────┴──────┴──────┴──────┘

Physical RAM
┌──────┬──────┬──────┬──────┐
│Frame │Frame │Frame │Frame │
└──────┴──────┴──────┴──────┘

The operating system maps virtual pages to physical frames.

---

13. Page Mapping

For example:

Process virtual page 10
        ↓
Physical frame 500

Another process could have:

Process B virtual page 10
        ↓
Physical frame 900

Same virtual page number, completely different physical memory.

---

14. Virtual Memory Does Not Mean Fake Memory

Virtual memory is not simply “pretend RAM.”

It is a real address translation and memory-management system.

It provides:

Isolation
Protection
Flexible allocation
Shared memory
Memory mapping
Paging

and more.

---

15. Page Tables

How does the CPU know:

Which physical frame corresponds to this virtual page?

The operating system maintains:

Page tables

Conceptually:

Virtual Page
     ↓
Page Table
     ↓
Physical Frame

---

16. Simplified Page Table

Imagine:

Virtual Page    Physical Frame
────────────    ───────────────
0               50
1               83
2               17
3               91
4               42

The actual page tables used by modern CPUs are much more complex and hierarchical.

---

17. Page Table Hierarchy

Modern x86-64 systems use multi-level page tables.

Conceptually:

Virtual Address
      ↓
Level 4
      ↓
Level 3
      ↓
Level 2
      ↓
Level 1
      ↓
Page frame

This avoids maintaining one enormous flat table.

---

18. Virtual Address Structure

A virtual address can conceptually be divided into:

┌───────────────┬──────────────┐
│ Page number   │ Page offset  │
└───────────────┴──────────────┘

The page number identifies the page.

The offset identifies the exact byte inside that page.

---

19. Example

Suppose:

Page size = 4096 bytes

Then:

4096 = 2^12

So 12 address bits are needed to identify a byte within a 4 KB page.

Conceptually:

Virtual address
┌──────────────────┬────────────┐
│ page number      │ 12-bit     │
│                  │ offset     │
└──────────────────┴────────────┘

---

20. Page Fault

What happens if a process accesses a virtual page that isn’t currently mapped to usable physical memory?

A:

Page fault

occurs.

This doesn’t automatically mean an error.

There are several kinds of page faults.

---

21. Normal Page Fault

A page fault can occur because the memory page isn’t currently mapped in the required way.

The kernel may handle the situation and resume the process.

Therefore:

Page fault does not necessarily mean the program crashed.

---

22. Invalid Memory Access

But suppose a process tries to access an address it has no permission to access.

The kernel/hardware can reject it.

This can eventually result in a process receiving a signal such as:

SIGSEGV

which is commonly associated with:

Segmentation fault

---

23. Segmentation Fault

Conceptually:

Program
 ↓
invalid memory access
 ↓
CPU/MMU detects violation
 ↓
kernel
 ↓
SIGSEGV
 ↓
program may terminate

This is one reason badly written software can crash.

---

24. RAM Isn’t Always the Immediate Source

When a virtual page is not currently resident in RAM, Linux may be able to obtain it from:

Filesystem-backed data
or
swap

depending on the type of memory mapping.

---

25. Swap

Swap provides disk-backed space that can participate in virtual memory management.

Conceptually:

RAM
 ↓
memory pressure
 ↓
some pages moved/reclaimed
 ↓
swap

But:

RAM speed
≫
SSD speed

so heavy swapping can significantly hurt performance.

---

26. Swap Is Not Extra RAM

This distinction is important.

If you have:

4 GB RAM
+ 8 GB swap

you should not think:

12 GB fast RAM

Instead:

4 GB physical RAM
+
8 GB slower disk-backed swap space

---

27. Why Swap Exists

Swap can help prevent immediate failure when memory pressure occurs.

It can provide a buffer.

But if the server continuously moves memory between RAM and swap, performance can collapse.

This is sometimes called:

Thrashing

---

28. Thrashing

Conceptually:

RAM
 ↓
page out
 ↓
disk
 ↓
page in
 ↓
RAM
 ↓
page out
 ↓
disk
...

The system spends too much time moving memory pages instead of doing useful application work.

---

29. MySQL and Memory

MySQL uses memory for things such as:

Buffer pools
Caches
Connections
Temporary structures
Query execution
Internal data structures

Therefore MySQL configuration has a major effect on RAM consumption.

---

30. PHP-FPM and Memory

Each PHP-FPM worker can consume memory.

Suppose, purely as an example:

20 PHP workers

and average process memory usage is:

100 MB

A rough upper-order calculation would be:

20 × 100 MB
=
2000 MB

That is about:

2 GB

before accounting for the rest of the system and the fact that actual memory behavior is more complicated.

---

31. Why PHP-FPM Worker Count Matters

Suppose:

RAM = 4 GB

and you configure an excessively large number of PHP workers.

You could create:

RAM pressure
 ↓
swap
 ↓
slow requests
 ↓
timeouts

So:

More PHP workers does not automatically mean more performance.

---

32. Nginx Memory

Nginx workers also consume memory, but generally much less per connection than a full PHP application execution environment.

This is one reason Nginx can handle many concurrent connections efficiently.

---

33. MySQL + PHP + Nginx

Your VPS memory may roughly be consumed by:

RAM
├── Linux kernel
├── Nginx
├── PHP-FPM
├── MySQL
├── SSH
├── system services
├── filesystem cache
└── other processes

The Linux kernel also uses memory for caching and internal data structures.

---

34. Linux Uses RAM for Caching

This is important.

Linux doesn’t try to leave RAM unused.

It may use available memory for:

Filesystem cache
Page cache
Kernel data

Therefore seeing:

"used memory = high"

doesn’t automatically mean the server is unhealthy.

The available memory figure is often more useful than simply looking at free.

---

35. Page Cache

Suppose Nginx repeatedly reads:

logo.png

Linux may cache recently accessed filesystem data in RAM.

Then:

Nginx
 ↓
filesystem read
 ↓
Linux page cache
 ↓
RAM

can avoid repeatedly accessing storage.

---

36. Storage vs Page Cache

Without cache:

Nginx
 ↓
Storage
 ↓
Data

With cache:

Nginx
 ↓
Kernel
 ↓
RAM cache
 ↓
Data

This can dramatically improve repeated reads.

---

37. This Explains an Interesting Observation

You may run:

free -h

and see very little:

free

but substantial:

available

That isn’t necessarily a problem.

Linux may be using memory productively for caches that can be reclaimed when applications need it.

---

38. Shared Memory

Processes don’t always have completely independent physical copies of everything.

Linux can allow memory to be shared.

For example:

Process A
      │
      ├──── shared page
      │
Process B

This can reduce unnecessary duplication.

---

39. Shared Libraries

Many programs use shared libraries.

For example:

Program A
   ↓
libc

Program B
   ↓
libc

The same physical memory pages can sometimes be shared when appropriate.

This is much more efficient than loading a separate physical copy for every process.

---

40. Copy-on-Write

A very important concept is:

Copy-on-Write

Suppose two processes initially share a memory page.

Process A ──┐
            ├── Physical Page
Process B ──┘

If one process needs to modify the page:

Process A ──→ Copy
Process B ──→ Original

A private copy can be created.

This allows efficient process creation and memory sharing.

---

41. Why This Matters to Servers

Server software can use process creation and shared memory mechanisms.

Understanding:

shared pages
copy-on-write
private pages

helps explain why the sum of displayed process memory values is not always equal to the amount of physical RAM actually consumed.

---

42. Memory-Mapped Files

Linux can map a file into a process’s virtual address space.

Conceptually:

File
 ↓
memory mapping
 ↓
process virtual memory

The process can then access file contents through memory-like operations.

This is called:

mmap

Many sophisticated applications use memory mapping.

---

43. Virtual Memory Is More Than Swap

This is an important correction to a common misconception.

Virtual memory is not simply:

RAM + swap

It primarily means:

Virtual address spaces
+
address translation
+
memory protection
+
mapping
+
paging
+
physical memory management

Swap is only one part of the larger memory-management system.

---

44. Kernel Memory vs User Memory

A process typically operates in:

User space

while the kernel operates in:

Kernel space

Conceptually:

Process
┌──────────────────────────┐
│ User Space               │
│                          │
│ Application              │
├──────────────────────────┤
│ Kernel Space             │
└──────────────────────────┘

The exact virtual-address layout depends on architecture and kernel configuration.

---

45. Why User/Kernel Separation Matters

A normal application should not be able to directly modify arbitrary kernel memory.

Instead:

Application
 ↓
System call
 ↓
Kernel
 ↓
Hardware/resource

This protects the operating system.

---

46. System Calls

A system call is a controlled mechanism for requesting kernel services.

Examples include operations related to:

File access
Memory
Processes
Networking
Time
Signals

Conceptually:

Nginx
 ↓
system call
 ↓
Linux kernel
 ↓
network/file resource

---

47. Example: read()

When software wants to read from a file or descriptor, it can use a system-call interface such as:

read()

Conceptually:

Application
 ↓
read()
 ↓
Kernel
 ↓
File/socket
 ↓
Data

The actual path can involve libraries and kernel internals.

---

48. Example: Network Socket

Nginx needs to accept connections.

Conceptually:

Nginx
 ↓
socket-related system calls
 ↓
Linux networking stack
 ↓
Network interface

This connects our lessons:

HTTP
 ↓
Nginx
 ↓
Linux socket
 ↓
Kernel
 ↓
Network

---

49. Example: File Access

Nginx needs:

style.css

Conceptually:

Nginx
 ↓
open/read
 ↓
Kernel
 ↓
Filesystem
 ↓
Page cache / storage
 ↓
Nginx

---

50. Memory and Your Website

Now consider a WordPress request:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

Each stage consumes some combination of:

CPU
RAM
Network
Storage

The kernel coordinates all of them.

---

51. One Request in Memory

Simplified:

HTTP request
      ↓
Nginx memory
      ↓
PHP-FPM worker memory
      ↓
WordPress PHP objects
      ↓
MySQL client buffers
      ↓
MySQL server memory
      ↓
database result
      ↓
PHP memory
      ↓
HTML response

This is why server capacity is not just about disk space.

---

52. Disk Space vs RAM

These are different problems.

A server can have:

500 GB storage

but:

1 GB RAM

and still struggle to run WordPress.

Conversely:

32 GB RAM

with:

10 GB free disk

may run out of storage.

You must monitor both.

---

53. Memory Pressure

When applications require more memory than comfortably available:

Applications
 ↓
RAM pressure
 ↓
reclaim/cache reduction
 ↓
swap if configured/needed
 ↓
possible OOM

---

54. OOM

OOM means:

Out Of Memory

Linux has mechanisms to handle extreme memory pressure.

The kernel may invoke the:

OOM Killer

to terminate selected processes when the system cannot satisfy memory demands.

This is an emergency mechanism, not normal memory management.

---

55. Why OOM Is Dangerous for Hosting

Suppose the server becomes severely memory constrained.

The kernel could terminate an application process.

For example:

PHP-FPM worker

or another process, depending on the situation and configuration.

The result can be:

Failed requests
502 errors
Database problems
Service restarts

The exact outcome depends on which process is affected.

---

56. Monitor Before OOM

Useful commands:

free -h

top

ps aux --sort=-%mem | head

The last command can help identify processes with high reported memory usage.

Remember that per-process memory accounting is more complicated than simply adding the numbers.

---

57. Inspect Swap

Run:

swapon --show

You can also use:

free -h

to see swap totals and usage.

---

58. Inspect Memory Information

Run:

cat /proc/meminfo

This exposes detailed kernel memory statistics.

You’ll see fields such as:

MemTotal
MemFree
MemAvailable
Buffers
Cached
SwapTotal
SwapFree

There are many additional fields.

---

59. /proc

This introduces another important Linux concept:

/proc

It is a virtual filesystem exposing information about processes and the kernel.

For example:

/proc/1/

contains information about PID 1.

And:

/proc/<PID>/

contains information associated with a particular process.

---

60. /proc Is Not Ordinary Storage

Files under /proc are largely generated by the kernel.

For example:

cat /proc/cpuinfo

shows CPU information.

And:

cat /proc/meminfo

shows memory information.

These aren’t ordinary static files sitting on your SSD.

---

61. Process Information

For a process:

/proc/1234/

you may find information related to:

cmdline
status
fd/
maps
limits

This gives an advanced view of what the process is doing.

---

62. /proc/<PID>/maps

This can show memory mappings for a process.

Conceptually:

Process
 ↓
Virtual memory mappings
 ↓
code
libraries
heap
stack
mapped files

This is where virtual-memory theory becomes visible on a real Linux server.

---

63. Heap

A process may dynamically allocate memory from its:

Heap

Conceptually:

Process memory
├── Code
├── Data
├── Heap
├── Shared libraries
└── Stack

The heap is commonly used for dynamically allocated data.

---

64. Stack

The stack is used for things such as:

Function call information
Local variables
Execution state

A process/thread typically has a stack.

---

65. Code/Text Segment

The executable instructions reside in memory mappings associated with the program’s code/text.

Conceptually:

Process
├── Code
├── Data
├── Heap
└── Stack

This is a simplified process-memory model.

---

66. Process Memory Model

A simplified conceptual diagram:

High addresses
┌─────────────────────┐
│ Stack               │
├─────────────────────┤
│                     │
│ Memory mappings     │
│ Libraries           │
│                     │
├─────────────────────┤
│ Heap                │
├─────────────────────┤
│ Data                │
├─────────────────────┤
│ Code                │
└─────────────────────┘
Low addresses

Modern Linux address spaces are more complicated than this diagram.

---

67. Why This Matters to PHP

A PHP-FPM worker has its own process memory.

When WordPress loads:

WordPress
Plugins
Theme
Libraries
Variables
Objects

they consume memory inside that worker’s address space.

---

68. Multiple PHP Workers

Suppose:

PHP-FPM
├── Worker A
├── Worker B
├── Worker C
└── Worker D

Each worker has its own process address space.

But some underlying memory can be shared where appropriate.

---

69. MySQL Memory

MySQL has its own address space.

So:

PHP worker
      │
      │ database request
      ▼
MySQL process
      │
      ▼
MySQL memory

PHP and MySQL do not simply share all of their ordinary process memory.

They communicate through interfaces such as sockets/network connections and exchange data.

---

70. This Explains Server Sizing

When choosing VPS resources, you need to consider:

Number of websites
+
Traffic
+
PHP worker count
+
WordPress complexity
+
MySQL workload
+
Caching
+
Background jobs
+
Other services

not merely:

"How much disk space do I need?"

---

71. A 1 GB VPS

Conceptually:

1 GB RAM

may need to accommodate:

Kernel
Nginx
PHP-FPM
MySQL
WordPress
Monitoring
SSH
Other services

This leaves relatively little room for large concurrent PHP workloads.

---

72. A 4 GB VPS

With:

you have substantially more room, but the actual capacity still depends on workload and configuration.

There is no universal:

4 GB = X websites

formula.

---

73. The Real Resource Equation

A useful mental model is:

Total RAM
=
Kernel
+
Services
+
Application workers
+
Database
+
Caches
+
Other processes
+
Safety margin

The safety margin is important.

Don’t plan to operate continuously at the absolute memory limit.

---

74. Your Hosting Platform

This becomes particularly important if CresignSys Hosting Platform creates websites automatically.

If your platform creates:

20 WordPress sites

it should eventually understand:

CPU usage
RAM usage
PHP-FPM limits
Database usage
Storage
Traffic

Otherwise it can oversubscribe the VPS.

---

75. Virtual Memory Summary

The fundamental chain is:

Application
 ↓
Virtual address
 ↓
Page tables
 ↓
MMU
 ↓
Physical memory

With possible involvement of:

Page cache
Shared memory
Mapped files
Swap

---

76. The Most Important Distinctions

Memorize these:

Physical memory
=
actual RAM

Virtual memory
=
process-visible address space + memory mapping system

Page
=
unit of virtual memory

Page frame
=
unit of physical memory

Page table
=
maps virtual pages to physical frames

MMU
=
hardware mechanism performing address translation/protection

Swap
=
disk-backed memory-management mechanism

Page cache
=
RAM used to cache filesystem data

---

77. Your VPS Now Has a Deeper Structure

You can now see:

                  VPS
                   │
            ┌──────┴──────┐
            ▼             ▼
         Hardware       Kernel
        CPU/RAM/etc.      │
                          ▼
                      Processes
                          │
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
        Nginx          PHP-FPM          MySQL
          │               │               │
          ▼               ▼               ▼
       sockets        PHP memory      DB memory
                          │
                          ▼
                       WordPress

And all of those processes depend on the Linux kernel for:

CPU
Memory
Storage
Networking
Security
Process management

---

Lesson 033 Summary

The central idea is:

A process does not directly own a fixed piece of physical RAM. It operates inside a virtual address space that Linux and the CPU map onto physical memory.

The important chain:

Process
 ↓
Virtual Address Space
 ↓
Virtual Address
 ↓
Page Table
 ↓
MMU
 ↓
Physical Address
 ↓
RAM

And when memory pressure occurs:

RAM pressure
 ↓
memory reclaim
 ↓
possible swap
 ↓
possible severe pressure
 ↓
possible OOM

Practical commands for this lesson

free -h
swapon --show
cat /proc/meminfo
ps aux --sort=-%mem | head
top

Next Lesson — 034

Linux Filesystem — From / to Your WordPress public/ Directory

We will go deeper into:

/
├── boot
├── dev
├── etc
├── home
├── proc
├── run
├── sys
├── tmp
├── usr
├── var
└── storage

Then we will trace exactly how:

/storage/websites/templates.cresignsys.com/public/

relates to:

Linux filesystem
      ↓
mount
      ↓
directory
      ↓
permissions
      ↓
Nginx root
      ↓
WordPress files
      ↓
PHP-FPM

This will explain where your websites physically exist on the VPS and how Linux turns storage into the filesystem that Nginx and WordPress use.