Eltartott egy ideig, amíg rájöttünk, hogy az eredeti javaslatunk, hogy ezt vm.overcommit_memory-ről 2-ra állítsuk, nem minden helyzetben jó.
Úgy tűnik, hogy néhány környezettel probléma van az ArangoDB csomagban található jemalloc memórialefoglalójával.
A vm.overcommit_memory kernelbeállítások 2 értékénél az allokátornak problémája volt a meglévő memórialeképezések felosztásával, ami miatt egy arangod folyamat memórialeképezéseinek száma nőtt az idő múlásával. Ez oda vezethetett, hogy a kernel nem hajlandó több memóriát átadni az arangod folyamatnak, még akkor is, ha a fizikai memória még mindig rendelkezésre áll. A kernel legfeljebb vm.max_map_count memória-leképezést ad minden folyamathoz, amely sok Linux-környezetben alapértelmezés szerint 65530.
Egy másik probléma a jemalloc futtatásakor, ha a vm.overcommit_memory értéke 2, hogy bizonyos munkaterheléseknél a Linux kernel által lekötött memóriaként követett memória mennyisége is növekszik az idő múlásával, és nem csökken. Így végül előfordulhat, hogy az ArangoDB démonfolyamat (arangod) nem kap több memóriát egyszerűen azért, mert eléri a beállított túllépési korlátot (fizikai RAM * overcommit_ratio + csereterület).
A megoldás tehát az, hogy a vm.overcommit_memory értékét 2-ről 1-re vagy 0-re módosítjuk. Ez mindkét problémát megoldja. Továbbra is folyamatosan növekvő virtuális memóriafelhasználást figyelünk meg, amikor a jemalloc-ot bármilyen túllépési beállítással használjuk, de a gyakorlatban ez nem okozhat problémát. Tehát ha a vm.overcommit_memory értékét 2-ről 0-re vagy 1-ra állítja (a 0 a Linux rendszermag alapértelmezett beállítása), ennek javítania kell a helyzeten.
A probléma megoldásának másik módja, amelyhez azonban az ArangoDB forrásból való fordítása szükséges, az, hogy egy buildet jemalloc nélkül fordítunk (-DUSE_JEMALLOC=Off cmakingkor). Ezt csak alternatívaként sorolom ide a teljesség kedvéért. A rendszer libc allokátorával elég stabil memóriahasználatot kell látnia. Kipróbáltunk egy másik allokátort is, pontosan a libmusl-ből, és ez is elég stabil memóriahasználatot mutat az idő múlásával. A fő probléma, ami miatt az allokátor cseréje nem triviális probléma, az az, hogy a jemalloc egyébként nagyon jó teljesítményjellemzőkkel rendelkezik.
(idézve Jan Steemannt, ahogy az megtalálható a githubon)
A rocksdb tárolómotorhoz időközben számos új kiegészítést készítettek. Bemutatjuk, hogyan működik a memóriakezelés a rocksdb-ben.
A rocksdb tárolómotor számos opciója az opciókon keresztül kívülről is elérhető.
Egy felhasználó megbeszélései és kutatása két további beállítási lehetőséget eredményezett ArangoDB 3.7:
- --rocksdb.cache-index-and-filter-blocks-with-high-priority
- --rocksdb.pin-l0-filter-and-index-blocks-in-cache
- --rocksdb.pin-top-level-index-and-filter
25.02.2019
