numers

src/content/results.tex

@@ -125,11 +125,11 @@ Sajnos a Kubeless esetében többször előfordult, hogy csak egy podot hozott l
 \label{fig:jmeter-kubeless-hello-hatodik-rps-chart}
 \end{figure}
 
-Erre a problémára több megoldási lehetőség létezik, viszont egyik sem tökéletes. Egy lehetőség a konténerek kézi (vagy akár automatizált) naplójainak rotációja. Ez azért nem jó megoldás, mert nem csak a függvény podok kerülnek Evicted állapotba, hanem akár a network plugin által használt pod is, hiszen a monitorozó rendszer minden podtól lekérdezi az adatait, valamint a Kubernetes minden podot Evicted állapotba tesz, ha túl sok ephemeral storage-ot használ. Ennél létezik egyszerűbb megoldás, ami jobb lehetőségnek tűnik. Ez a Docker logrendszerének átkonfigurálása, hogy ne a konténer fájljai között, JSON formátumban naplózzon, hanem például használja a gazdagép \textit{journald} rendszer szolgáltatását. Ez meg is oldotta ezt a problémát, viszont felvetett egy másikat. Bár a naplóbejegyzések már nem kerülnek a konténerek mellé, valahol a fájlrendszeren kerülnek tárolásra, ahol egy idő után ugyan tömörítésre kerülnek, de addig jelentős helyet foglalnak a mérésből és a monitorozásból adódó bejegyzések. Ennek eredményeként a Kubernetes Worker node-okon DiskPreassure állapot léphet fel, amely azt jelenti, hogy az adott node fájlrendszerén kevés a fennmaradt szabad hely. Ez a szabály vonatkozik a node root partíciójára, valamint a Docker konténereket tároló partícióra is. Ekkor a node-on lévő podok kerülhetnek Evicted állapotba. A Kubernetes megpróbálja azokat újraindítani, viszont ez már új konténer létrehozását jelenti. Erre két megoldási lehetőség létezik. Vagy a problémás Node kubelet konfigurációját átállítjuk, hogy a DiskPreassure állapot később lépjen fel, ezzel viszont csak elnapoltuk a problémát. Másik lehetőség a naplófájlok gyorsabb rotációja, illetve a Docker konténerek külön partíción tárolása, de ez esetben csak lelassítottuk a problémát. Az igazi megoldás a kettő módszer ötvözése. Naplóbejegyzések mindenképpen generálódni fognak, ezt megakadályozni nem tudjuk és nem is érdekünk, hiszen bármi probléma adódik, a naplóbejegyzések jelentős segítséget nyújtanak a diagnózisban, valamint akár a probléma megoldásában is segíthetnek.
+Erre a problémára több megoldási lehetőség létezik, viszont egyik sem tökéletes. Egy lehetőség a konténerek kézi (vagy akár automatizált) naplójainak rotációja. Ez azért nem jó megoldás, mert nem csak a függvény podok kerülnek Evicted állapotba, hanem akár a network plugin által használt pod is, hiszen a monitorozó rendszer minden podtól lekérdezi az adatait, valamint a Kubernetes minden podot Evicted állapotba tesz, ha túl sok ephemeral storage-ot használ. Ennél létezik egyszerűbb megoldás, ami jobb lehetőségnek tűnik. Ez a Docker logrendszerének átkonfigurálása, hogy ne a konténer fájljai között, JSON formátumban naplózzon, hanem például használja a gazdagép \textit{journald} rendszer szolgáltatását. Ez meg is oldotta ezt a problémát, viszont felvetett egy másikat. Bár a naplóbejegyzések már nem kerülnek a konténerek mellé, valahol a fájlrendszeren kerülnek tárolásra, ahol egy idő után ugyan tömörítésre kerülnek, de addig jelentős helyet foglalnak a mérésből és a monitorozásból adódó bejegyzések. Ennek eredményeként a Kubernetes Worker node-okon DiskPreassure állapot léphet fel, amely azt jelenti, hogy az adott node fájlrendszerén kevés a fennmaradt szabad hely. Ez a szabály vonatkozik a node root partíciójára, valamint a Docker konténereket tároló partícióra is. Ekkor a node-on lévő podok kerülhetnek Evicted állapotba. A Kubernetes megpróbálja azokat újraindítani, viszont ez már új konténer létrehozását jelenti. Erre két megoldási lehetőség létezik. Vagy a problémás node kubelet konfigurációját átállítjuk, hogy a DiskPreassure állapot később lépjen fel, ezzel viszont csak elnapoltuk a problémát. Másik lehetőség a naplófájlok gyorsabb rotációja, illetve a Docker konténerek külön partíción tárolása, de ez esetben csak lelassítottuk a problémát. Az igazi megoldás a kettő módszer ötvözése. Naplóbejegyzések mindenképpen generálódni fognak, ezt megakadályozni nem tudjuk és nem is érdekünk, hiszen bármi probléma adódik, a naplóbejegyzések jelentős segítséget nyújtanak a diagnózisban, valamint akár a probléma megoldásában is segíthetnek.
 
-Annak érdekében, hogy a Knative-ba telepített függvények skálázódása az általuk nyújtott teljesítményben is meglátszódjon, szerettem volna limitálni egy-egy pod teljesítményét. Erre viszont a Knative által létrehozott objektum típusok esetében nincs lehetőség. Emiatt úgy döntöttem, hogy a Knative által létrehozott Kubernetes Deployment objektumot módosítom, ott hozom létre a limiteket. Ez sikerült, a függvény működött tovább, a megadott korlátozások érvénybe léptek. Viszont az elvárások nem teljesültek, a podok létrejöttével nem emelkedett meg a függvény teljesítménye. A lenti diagrammon látszik, hogy a függvény végig ezer kérést volt képes kiszolgálni másodpercenként. 
+Annak érdekében, hogy a Knative-ba telepített függvények skálázódása az általuk nyújtott teljesítményben is meglátszódjon, szerettem volna limitálni egy-egy pod teljesítményét. Erre viszont a Knative által létrehozott objektum típusok esetében nincs lehetőség. Emiatt úgy döntöttem, hogy a Knative által létrehozott Kubernetes Deployment objektumot módosítom, ott hozom létre a limiteket. Ez sikerült, a függvény működött tovább, a megadott korlátozások érvénybe léptek. Viszont az elvárások nem teljesültek, a podok létrejöttével nem emelkedett meg a függvény teljesítménye. A lenti diagrammon látszik, hogy a függvény végig k\"or\"ulbel\"ul 1000 kérést volt képes kiszolgálni másodpercenként. 
 
-Korábbi mérések során a prímszámoló függvény egy Python folyamatot használva nyolcszáz kérést szolgált ki másodpercenként. Tehát a mérés során létrejött öt pod nagyjából négyezer kérést kellene kiszolgálnia másodpercenként az elvárásaink alapján. Ezzel szemben, ahogy \aref{fig:jmeter-pillanat-junky-chart} \'abr\'an l\'atszik, az egész mérés során olyan teljesítményt nyújt a függvény, melyet két pod is ki tudna szolgálni. Emellett a ny\'ujtott teljes\'itm\'eny a szok\'asosn\'al instabilabb volt.
+Korábbi mérések során a prímszámoló függvény egy Python folyamatot használva nagyj\'ab\'ol 800 kérést szolgált ki másodpercenként. Tehát a mérés során létrejött 5 pod nagyjából 4000 kérést kellene kiszolgálnia másodpercenként az elvárásaink alapján. Ezzel szemben, ahogy \aref{fig:jmeter-pillanat-junky-chart} \'abr\'an l\'atszik, az egész mérés során olyan teljesítményt nyújt a függvény, melyet két pod is ki tudna szolgálni. Emellett a ny\'ujtott teljes\'itm\'eny a szok\'asosn\'al instabilabb volt.
 
 \begin{figure}[!ht]
 \centering