← Natrag
AI

mmap vs read/write za vektorske indekse: pgvector, mlock i olujni swap

Damir Radulić· 5. listopada 2026.· 3 min čitanja· 3 pregleda
mmap vs read/write za vektorske indekse: pgvector, mlock i olujni swap
🎧 Poslušaj članak

U svijetu visokih performansi i velikih podataka, odabir načina pristupa memoriji može odlučiti o brzini i pouzdanosti cijelog sustava. Često se susrećemo s dva osnovna pristupa: read/write i memory-mapping (mmap). Ovaj članak razmatra prednosti i mane svakog pristupa u kontekstu vektorskih indeksa, s posebnim naglaskom na PostgreSQL‑ov pgvector ekstenziju, mlock i pojavu „swap storma”.

Kako funkcionira mmap?

mmap je sistemski poziv koji mapira datoteku ili uređaj u virtualni adresni prostor procesa. Nakon inicijalizacije, pristup podacima se odvija kao običan pristup memoriji – bez eksplicitnih read/write operacija. Kada proces čita ili piše u mapiranu regiju, kernel automatski učitava ili pohranjuje stranice u fizičku memoriju. Ako je tražena stranica nedostupna, generira se page fault, što uzrokuje da kernel učita stranicu iz diska.

Read/Write vs mmap: Latencija i kontrola

Ključna razlika leži u kontrole nad I/O‑om. U read/write pristupu, aplikacija izričito traži podatke, pa je moguće optimizirati raspored I/O‑a, predmemorirati ili paralelizirati operacije. S druge strane, mmap delegira te odluke kernelu; aplikacija samo čita ili piše, a kernel odlučuje kada i kako učitati stranice. To može rezultirati manjom latencijom pri čitanju, jer se ne mora čekati na eksplicitni read, ali također otvara mogućnost da kernel odluči da pohrani stranice u swap ako je memorija ograničena.

pgvector i mmap: Koja je razlika?

pgvector je ekstenzija za PostgreSQL koja omogućuje pohranu i pretraživanje vektora (npr. embeddings). Interno koristi mmap za pristup binarnim podacima, što znači da se cijeli vektorski indeks učitava u memoriju na zahtjev. To je efikasno za čitanje, ali može dovesti do velikog broja page faultova ako indeks nije dovoljno velik da stane u RAM. U takvim slučajevima, kernel može početi prebacivati stranice na disk (swap), što uzrokuje „swap storm” – masivnu količinu I/O‑a i drastično sporo izvođenje upita.

mlock: Zaključavanje memorije

mlock je sistemski poziv koji sprječava da kernel prebacuje određene stranice u swap. Kada se koristi s mmap‑om, mlock osigurava da će sve stranice indeksa ostati u fizičkoj memoriji. To može spriječiti swap storm, ali ima svoje troškove: fizička memorija se brzo popunjava, a sistem može postati nestabilan ako nema dovoljno RAM‑a. Osim toga, mlock je ograničen na određenu količinu memorije koju operativni sustav dozvoljava korisnicima.

Swap storm: Uzroci i posljedice

  • Veliki indeks – kada je indeks veći od dostupne RAM‑a, kernel počinje prebacivati stranice.
  • Neoptimalni pristup – čest pristup nasumičnim lokacijama uzrokuje puno page faultova.
  • Ograničenja mlocka – ako se ne koristi ili se koristi samo djelomično, kernel i dalje može swapati.

Posljedice swap storma su drastično spora upita, visok CPU‑i I/O opterećenje, pa čak i sistemski crash ako se memorija potpuno isprazni.

Kako izbjeći swap storm?

  • Procijenite veličinu indeksa – ako je indeks veći od 70‑80% RAM‑a, razmislite o fragmentaciji ili shardingu.
  • Koristite mlock s oprezom – ograničite količinu memorije koja se zaključava na one najčešće korištene stranice.
  • Optimizirajte pristup – grupirajte upite po sličnim vektorima kako biste smanjili broj page faultova.
  • Monitorirajte swap – koristite alate poput vmstat ili sar za praćenje swap aktivnosti.

Zaključak

mmap može značajno ubrzati pristup vektorskim indeksima, ali je ključno razumjeti kada i kako kernel upravlja memorijom. Swap storm je najčešći problem, a ne sporo pitanje. Pravilna kombinacija mlocka, optimizacije pristupa i pažljivog upravljanja memorijom može osigurati da vaš sistem ostane brz i pouzdan.

mmapswappgvectormlockvektorski indeks

Zanima vas ovakva AI tehnologija?

RiNET gradi sovereign AI rjesenja za javni sektor i poduzeca - od civic intelligence do automatizacije nabave.

Kontaktirajte nas →
0 komentara

Komentari