Hogyan működik a page-csere, és mi okozza a thrashinget?

Question

IT Interview Practice · Accepted Answer

Amikor a fizikai RAM megtelik, de a processeknek több page kell, az OS-nek **ki kell dobnia (evict)** egy bent lévő page-et, hogy helyet csináljon — a **swap**-ra (lemezre) írva, ha az piszkos (dirty). Az, hogy melyik page-et dobja ki, a **page replacement** döntése, és ha elrontod, tönkreteszi a teljesítményt.

## Cserestratégiák

Az elméleti optimum a legtávolabbi jövőben használt page kidobása (**Bélády OPT-ja**) — lehetetlen, mivel nem látod a jövőt. Ezért közelítjük az **LRU-t (least recently used)**: dobd ki a legrégebben nem használt page-et. A valódi LRU minden hozzáféréshez időbélyeget igényel (túl költséges), ezért a valódi kernelek a **clock (second-chance) algoritmust** használják:

```text
Frames arranged in a ring; each has a REFERENCE bit the hardware sets on access.
A "hand" sweeps around the ring:
   ref bit = 1 → clear it, give the page a second chance, move on
   ref bit = 0 → evict THIS page (approximates "least recently used")

[1]→[1]→[0] ← evict here   (the sweep clears 1s until it finds a 0)
         ▲___________|
```

A clock LRU-szerű eredményt ad O(1) költséggel. A Linux tovább finomítja **active/inactive LRU-listákkal**.

## Working set és thrashing

Egy process **working set**-je azoknak a page-eknek a halmaza, amelyeket egy időablakon belül aktívan használ. A paging jól működik, *amíg az összesített working set-ek beleférnek a RAM-ba*. Amikor nem:

```text
working set > RAM → evict a page that's about to be needed → immediate page fault →
evict another needed page → ... → the CPU spends ~all its time paging to disk, ~0% on real work
                            = THRASHING
```

A thrashing egy szikla, nem lejtő: menj egy kicsit a határ fölé, és a throughput összeomlik, mert szinte minden hozzáférés miss. Tünetek: a CPU szinte tétlen, de a lemez-I/O telített, és a latency robban.

## Javítás / elkerülés

- **Adj hozzá RAM-ot** vagy **csökkentsd a terhelést** (kevesebb egyidejű process), hogy a working set-ek beférjenek.
- A scheduler **felfüggeszthet és kiswappelhet** egész processeket az igény csökkentésére (medium-term scheduling).
- A Linux **OOM killer**-e a végső megoldás — inkább öl meg egy processt, mint hogy örökké thrasheljen.
- Javítsd a **localityt**, hogy maga a working set kisebb legyen.

## Miért fontos

Ez összeköti az egész memóriatörténetet, és kedvelt senior kérdés, mert a thrashing valódi éles hibamód: egy szolgáltatás, amely N felhasználónál rendben van, N+1-nél leesik a szikláról, ahogy a working set-je meghaladja a RAM-ot. Felismerni a jellemzőket (nehéz paging, telített lemez, megrekedt CPU) és ismerni a karokat (RAM, terheléscsökkentés, locality — és hogy a swap egy memóriahiányt latency-katasztrófává változtat) a különbség aközött, hogy percek alatt diagnosztizálod, vagy egy rejtélyesen befagyott gépet bámulsz.

Cserestratégiák

Working set és thrashing

Javítás / elkerülés

Miért fontos

Kapcsolódó kérdések