SG.hu
25 milliszekundum alatt be tud bootolni a FreeBSD
A FreeBSD kernelben egy rendezési algoritmus lecserélése legalább százszorosára javította a bootolási sebességet.
Több éve a kutatás-fejlesztés egyik legforróbb témája a kisméretű virtuális gép, a mikroVM. Ezt az IBM találta fel az 1960-as években, egy olyan operációs rendszer, amely vendégként fut egy másik operációs rendszer alatt. Szorosan hozzá kapcsolódik a hypervisor - vagy magyarul hiperfelügyelő -, ami egy olyan szoftver vagy hardver, ami virtuális számítógépek futtatását végzi. A működéshez az operációs rendszert kifejezetten úgy kell megépíteni, hogy az egy virtuális gépen belül futni tudjon, és az adott hipervizor által biztosított erőforrásokkal dolgozzon. Ez azt jelenti, hogy a vendég operációs rendszernek szinte egyáltalán nincs szüksége valódi hardvertámogatásra, csak virtualizált illesztőprogramokra, amelyek közvetlenül a hipervizor által biztosított eszközökkel beszélnek. Nem kell emulált PCI-busz, emulált energiagazdálkodás, emulált grafikus kártya vagy egyéb dolog, így maga a hipervizor sokkal kisebb és egyszerűbb lehet.
A hipervizor és a benne futó operációs rendszer kíméletlen lebutításának eredménye az, hogy mindkettő sokkal kisebb és egyszerűbb lehet. Ez azt jelenti, hogy a virtuális gépek sokkal kevesebb erőforrást használhatnak, és sokkal gyorsabban indulhatnak. Hogy mi értelme ennek? Számítási teljesítmény biztosítása szerver nélkül. Persze a "szerver nélküli" számítástechnika valójában marketinges kettős beszéd: természetesen valahol egy adatközpontban fizikailag valójában vannak szerverek. De ez az infrastruktúra mint szolgáltatás, a híres IaaS-modell helyett ez inkább Function as a Service (funkció mint szolgáltatás).
Az ötlet lényege, hogy a rendszernek semmit sem kell tudnia az infrastruktúráról: a programja meghív egy másik programot, a menedzsmenteszköz pedig annyi példányt hoz létre, amennyi szükséges az adott művelet futtatásához, visszaadja az eredményt, majd törli a számítások futtatásához használt virtuális gépeket. Soha nem kell tudnia, hogy ez hol és hogyan történt. Az ügyfél számára ez azért jó, mert gyors és egyszerű. A szolgáltatók számára azért jó, mert így az erőforrások sokkal gyorsabban szabadulnak fel újra, így azonnal újra felhasználhatók, ami azt jelenti, hogy több ügyfelet szolgálhatnak ki ugyanannyi hardverrel.
Az a képesség, hogy egy teljesen más operációs rendszer tetején futtathatunk egyetlen, egy operációs rendszerre készült programot anélkül, hogy állandóan egy teljes emulált környezetet kellene futtatnunk, nagyon hasznos lehet mindenféle helyzetben. Minél kisebb lehet ez a virtuális gép és minél kevesebb erőforrást használ, annál jobb az általános teljesítmény.
Az Amazon felhője a FaaS-t egy Lambda nevű szolgáltatáson keresztül kínálja. A Lambda az Amazon saját fejlesztésű Firecracker hipervizorán alapul, mely pedig a Linux kernel beépített KVM hipervizora alapján készült. Ez azt jelenti, hogy ez eredendően egy Linux-on-Linux ajánlat. A hosszú bevezető után itt jutunk el hírünk lényegéhez, mivel a FreeBSD kernelfejlesztője, Colin Percival úgy döntött, hogy a FreeBSD-t futtat a Firecracker-en. Mint általában a számítástechnika nagy részénél, az általános optimalizálási folyamat a következő: először is, működjön az adott dolog, majd utána hogy az gyorsan fusson. Colin Percival a Twitteren közölte, hogy lenyűgöző teljesítményoptimalizálást hajtott végre: egy rendezési algoritmus lecserélésével a FreeBSD kernel indítási folyamatának egy része körülbelül százszor gyorsabbá vált, így a kernel betöltési ideje mindössze 25 milliszekundumra csökkent. Ez negyed tizedmásodperc.
Ez a módosítás persze csak egy a sok közül, melyeket szintén részletesen ismertetett. Leírja az előzetes változtatásokat, amelyek ahhoz voltak szükségesek, hogy a FreeBSD egyáltalán elinduljon: több inicializálási lépés eltávolítása, amelyek azt feltételezték, hogy a Xen hipervizor alatt bootol, majd az ACPI konfigurációs interfész lekérdezése a processzorok típusáról és számáról. Ez nem sikerült, mivel a Firecracker nem biztosít ACPI-t. Ezután az egyetlen emulált hardver egyikének, a soros konzolnak az inicializálása is sikertelen volt.
Miután a kernel sikeresen elindult, a memóriahasználat vált problémává: a Firecracker alapértelmezés szerint mindössze 128 MB RAM-ot rendel a vendéghez, ezt meg kellett változtatni. Ami ezután következik, az optimalizációk hosszú listája, amelyek mindegyike hozzájárult egy kis időmegtakarításhoz. Érdekes olvasmány még a nem műszaki beállítottságúak számára is. A lépések némelyike olyan dolgokat változtat meg, amelyek dedikált hardveren történő indításkor teljesen ésszerű döntések voltak, és amelyeknek már nincs értelme egy olyan virtuális környezetben, ahol egy gép elindul, elvégez némi munkát, majd néhány másodpercen belül ismét törlődik.
"A Linux szerintem 75-80 ms alatt van ugyanabban a környezetben, ahol a FreeBSD 25 ms alatt bootol. Amikor elkezdtem dolgozni a bootolási folyamat felgyorsításán, a kernel betöltése körülbelül 10 másodpercig tartott, így most körülbelül 400-szor gyorsabban bootol a kernel, mint néhány évvel ezelőtt." - írja Colin Percival. Mindezt a FreeBSD 14-es x86-64-es kernelével csinálta meg, és mivel az Amazon felhője ARM-szervert használ, az egészet Arm64-re is át kell ültetni.
Több éve a kutatás-fejlesztés egyik legforróbb témája a kisméretű virtuális gép, a mikroVM. Ezt az IBM találta fel az 1960-as években, egy olyan operációs rendszer, amely vendégként fut egy másik operációs rendszer alatt. Szorosan hozzá kapcsolódik a hypervisor - vagy magyarul hiperfelügyelő -, ami egy olyan szoftver vagy hardver, ami virtuális számítógépek futtatását végzi. A működéshez az operációs rendszert kifejezetten úgy kell megépíteni, hogy az egy virtuális gépen belül futni tudjon, és az adott hipervizor által biztosított erőforrásokkal dolgozzon. Ez azt jelenti, hogy a vendég operációs rendszernek szinte egyáltalán nincs szüksége valódi hardvertámogatásra, csak virtualizált illesztőprogramokra, amelyek közvetlenül a hipervizor által biztosított eszközökkel beszélnek. Nem kell emulált PCI-busz, emulált energiagazdálkodás, emulált grafikus kártya vagy egyéb dolog, így maga a hipervizor sokkal kisebb és egyszerűbb lehet.
A hipervizor és a benne futó operációs rendszer kíméletlen lebutításának eredménye az, hogy mindkettő sokkal kisebb és egyszerűbb lehet. Ez azt jelenti, hogy a virtuális gépek sokkal kevesebb erőforrást használhatnak, és sokkal gyorsabban indulhatnak. Hogy mi értelme ennek? Számítási teljesítmény biztosítása szerver nélkül. Persze a "szerver nélküli" számítástechnika valójában marketinges kettős beszéd: természetesen valahol egy adatközpontban fizikailag valójában vannak szerverek. De ez az infrastruktúra mint szolgáltatás, a híres IaaS-modell helyett ez inkább Function as a Service (funkció mint szolgáltatás).
Az ötlet lényege, hogy a rendszernek semmit sem kell tudnia az infrastruktúráról: a programja meghív egy másik programot, a menedzsmenteszköz pedig annyi példányt hoz létre, amennyi szükséges az adott művelet futtatásához, visszaadja az eredményt, majd törli a számítások futtatásához használt virtuális gépeket. Soha nem kell tudnia, hogy ez hol és hogyan történt. Az ügyfél számára ez azért jó, mert gyors és egyszerű. A szolgáltatók számára azért jó, mert így az erőforrások sokkal gyorsabban szabadulnak fel újra, így azonnal újra felhasználhatók, ami azt jelenti, hogy több ügyfelet szolgálhatnak ki ugyanannyi hardverrel.
Az a képesség, hogy egy teljesen más operációs rendszer tetején futtathatunk egyetlen, egy operációs rendszerre készült programot anélkül, hogy állandóan egy teljes emulált környezetet kellene futtatnunk, nagyon hasznos lehet mindenféle helyzetben. Minél kisebb lehet ez a virtuális gép és minél kevesebb erőforrást használ, annál jobb az általános teljesítmény.
FreeBSD (HEAD) no longer spends time running a bubblesort on its SYSINITs. We're now running a mergesort which is ~100x faster: https://t.co/1F8Yodedh3 https://t.co/AvmVVwz9G5
— Colin Percival (@cperciva) August 20, 2023
Az Amazon felhője a FaaS-t egy Lambda nevű szolgáltatáson keresztül kínálja. A Lambda az Amazon saját fejlesztésű Firecracker hipervizorán alapul, mely pedig a Linux kernel beépített KVM hipervizora alapján készült. Ez azt jelenti, hogy ez eredendően egy Linux-on-Linux ajánlat. A hosszú bevezető után itt jutunk el hírünk lényegéhez, mivel a FreeBSD kernelfejlesztője, Colin Percival úgy döntött, hogy a FreeBSD-t futtat a Firecracker-en. Mint általában a számítástechnika nagy részénél, az általános optimalizálási folyamat a következő: először is, működjön az adott dolog, majd utána hogy az gyorsan fusson. Colin Percival a Twitteren közölte, hogy lenyűgöző teljesítményoptimalizálást hajtott végre: egy rendezési algoritmus lecserélésével a FreeBSD kernel indítási folyamatának egy része körülbelül százszor gyorsabbá vált, így a kernel betöltési ideje mindössze 25 milliszekundumra csökkent. Ez negyed tizedmásodperc.
Ez a módosítás persze csak egy a sok közül, melyeket szintén részletesen ismertetett. Leírja az előzetes változtatásokat, amelyek ahhoz voltak szükségesek, hogy a FreeBSD egyáltalán elinduljon: több inicializálási lépés eltávolítása, amelyek azt feltételezték, hogy a Xen hipervizor alatt bootol, majd az ACPI konfigurációs interfész lekérdezése a processzorok típusáról és számáról. Ez nem sikerült, mivel a Firecracker nem biztosít ACPI-t. Ezután az egyetlen emulált hardver egyikének, a soros konzolnak az inicializálása is sikertelen volt.
Miután a kernel sikeresen elindult, a memóriahasználat vált problémává: a Firecracker alapértelmezés szerint mindössze 128 MB RAM-ot rendel a vendéghez, ezt meg kellett változtatni. Ami ezután következik, az optimalizációk hosszú listája, amelyek mindegyike hozzájárult egy kis időmegtakarításhoz. Érdekes olvasmány még a nem műszaki beállítottságúak számára is. A lépések némelyike olyan dolgokat változtat meg, amelyek dedikált hardveren történő indításkor teljesen ésszerű döntések voltak, és amelyeknek már nincs értelme egy olyan virtuális környezetben, ahol egy gép elindul, elvégez némi munkát, majd néhány másodpercen belül ismét törlődik.
"A Linux szerintem 75-80 ms alatt van ugyanabban a környezetben, ahol a FreeBSD 25 ms alatt bootol. Amikor elkezdtem dolgozni a bootolási folyamat felgyorsításán, a kernel betöltése körülbelül 10 másodpercig tartott, így most körülbelül 400-szor gyorsabban bootol a kernel, mint néhány évvel ezelőtt." - írja Colin Percival. Mindezt a FreeBSD 14-es x86-64-es kernelével csinálta meg, és mivel az Amazon felhője ARM-szervert használ, az egészet Arm64-re is át kell ültetni.