Van egy videód amit meg szeretnél osztani a weboldaladon közvetlenül és ehhez nem akarod használni a youtube-ot? Ez a videó viszont sok helyet foglal?
Valószínűleg azzal lesz a probléma, hogy túlságosan jó képminőséggel dolgozol – főleg ha mondjuk azt standard beállítások mellett egy Vegas Pro-val exportáltad ki.
Megoldás egy kis bash script, mely lebutítja kb a youtube szinvonalára a videó kép és hangminőségét és kicseréli az előző fájllal. Íme a bash script:
Fissítés: azóta már megjelent hivatalos support, tehát a lenti leírásom már outdated. Használható, de az sd kártyák instabilitása miatt megfontolandó már nem annyira használni. 🙂
A helyzet a következő.
Raspberry Pi 4-en jelen pillanatban stable firmware-el még nem elérhető usb boot. Ez azt jelenti, hogy csak microSD kártyát bedugva képes üzemelni a bankkártya méretű kis számítógép.
Probléma lehet még továbbá az is, hogy ha kifogyunk a memóriából akkor a rendszer elkezd akadni, megállni és – mivel nem tud, nem lehet mindent kilőni – kb a használhatatlanságig lassul. Nyilván ezt a problémát lehet orvosolni azzal, hogy egy nagyobb memóriával rendelkező Raspi4-et veszel, de ha esetleg abból is kifogynál még mindig van cserehely (swap) ahova az oprendszer a memóriából a nem használt dolgokat ki tudja lapozni.
Igen ám, a probléma viszont ott kezdődik, hogy a kis gépecske alapesetben sd kártyáról üzemel ami nem a gyors/sok írás-olvasásra lett kitalálva, magyarán szólva a gépünk marhára lassú lesz az SD kártya miatt.
Ezért (és a nagyobb tárkapacitásért) érdemesebb venni egy SSD-t és egy usb 3.0-s sata átalakítót és a Raspbian-t átköltöztetni rá.
Jelen leírásomban nem azt mutatom be, hogy hogyan tud abszolút SD kártya nélkül üzemelni a bébi, hanem azt, hogy egy már meglévő alap, buta, lassú sd kártya mellé hogyan lehet ssd-re átköltöztetni és belakni a teljes alaprendszert.
Összetevők
minimum 8G-os sd kártya
sata csatolós SSD
sata-usb 3.0 átalakító, vagy beépítőkeret 2.5″-os meghajtóhoz nem szükséges külső táposat venni, az ssd-t és lényegében a legtöbb hdd-t is képes a rpi üzembiztosan a saját hivatalos tápegységével meghajtani
Alaprendszer telepítése
Töltsd le az aktuális legújabb Raspbian-t (ez egyébként a 10-es Debian-nal egyenértékű), írd ki az sd kártyára, dugd be a raspi-ba, hálózatot is adj neki, indítsd el, hagyd, hogy összeszedje magát.
Ha megvan
sudo su
raspi-config
paranccsal az Interfacing Options alatt engedélyezd az ssh-t. Ezek után már monitor nélkül egy másik számítógépről is rácsatlakozhatsz PuTTY-ot használva.
Előkészítés
Miután már él az ssh kapcsolat az összerakott usb-s ssd-t csatlakoztasd a raspi kék színű aljzatához. A kék színű aljzat a 3.0-s csatoló.
Konzolon (putty) csekkold le, hogy látja-e az ssd-t a raspi:
fdisk -l
/dev/sda-ként meg kellene jelenjen.
Ha nem egy lsusb paranccsal nézd meg biztosan megfelelő-e a csatlakozás, ellenőrizd a kábeleket, nézd meg pc-re dugva az ssd-t, hogy okés-e vagy sem.
Ha az fdisk-ben látható a /dev/sda akkor nyert ügyed van, mehetünk tovább.
A másolást megelőzően le kell formáznunk az ssd-t, figyelj oda, nehogy fontos adatokat tárolj rajta!
fdisk /dev/sda
> o
> n
> p
> enter, enter, enter
> p
(ezután kellene láss /dev/sda1-et)
> w
mkfs.ext4 /dev/sda1
Nyitottunk egy új partíciós táblát, létrehoztunk egy partíciót, majd ext4-re formáztuk.
Megtörtént az ssd felcsatolása, és a gyökér fájlrendszer tükrözése. Fontos, hogy e művelet közben semmi mást ne csináljon a raspi. Igazából élő rendszeren nem is egészséges ilyet csinálni, mert inkonzisztencia léphet fel a másolt/cél fájlrendszerben, de mivel egy zsír új rendszerről van szó nagy kár nem történhet, max újrakezdjük.
Ha sikeresen lefutott a másolás akkor rá kell vennünk a raspi-t, hogy a gyökér fájlrendszert ne az sd kártyán keresse hanem a csatlakoztatott usb meghajtón.
Kérdezzük le először is az ssd-n lévő partuuid-ját:
Ebből nekünk a PARTUUID fog kelleni, másoljuk ki az értékét valahova jegyzettömbbe.
Ezután jön az a rész, hogy megmondjuk a raspi-nak, hogy ez a partuuid lesz az ő root-ja a jövőben.
nano /etc/fstab
Illetve
nano /mnt/ssd/etc/fstab
helyeken keressük meg azt a sort ahol a második “oszlop” csak egy “/”
Itt a PARTUUID= utáni értéket módosítsuk az ssd partuuid-jára, majd
nano /boot/cmdline.txt
Itt egyetlen sort találsz, keresd meg benne a root=PARTUUID=… részt, itt is módosítsd az értéket az ssd-d id-jára. Ha ezzel is megvagyunk akkor kb végeztünk is, nézzük meg sikerrel jártunk-e:
df -h
Ha a “Mounted on” oszlopot figyeljük és megkeressük a /-t akkor az “Avail” oszlopban látható az sd kártyánk mérete. A rendszer ekkor még nem ssd-t használja.
Indítsuk újra a raspi-t:
reboot
Bejelentkezést követően ismét nézzük meg a csatolt lemezeket és tadam:
Ha az Avail oszlopban látható az ssd nagyobb kapacitása sikerrel jártunk.
Swap beállítása
Alapból 100Mb default cserehely/swap van egy raspbian-on beállítva, ez pont elég ahhoz, hogy az alkalmazások elinduljanak és közben ne egye meg az sd kártyát, de nekünk egy gyors ssd-nk lett, így már lehet nagyban gondolkozni.
Elkezdett bennem érlelődni a gondolat, hogy mivel a weboldalaim jelenleg kisebb látogatottságúak simán áttehetném az épp egyik használaton kívüli rpi4-esemre.
Igazából néhány wp oldalam fut, amin tulajdonképpen cache sincs, tehát a php-nak kell eleget dolgoznia. Fogtam tehát billentyűzetet és első körben leteszteltem, hogy processzorban mekkora a különbség egy 5 dolcsis alap 1 magos Digitalocean szerver és egy Raspberry pi 4 (1G ram+ssd) között az alábbi módon:
sysbench --num-threads=4 --test=cpu --cpu-max-prime=20000 run
A Digitalocean szerver így alakított:
Threads fairness: events (avg/stddev): 680.7500/0.83 execution time (avg/stddev): 9.9814/0.01
A kis bankkártya méretű számítógép:
Threads fairness:
events (avg/stddev): 2500.0000/41.70
execution time (avg/stddev): 65.5436/0.01
Nagyjából 6.5x az eltérés a Digitalocean javára.
Jelenleg a Digitalocean szerverem 5.8%-os átlag cpu terheltségével számolva a raspi-n ez az érték kb 40%-os átlagos cpu terhelésre emelkedne. A 40% körülbelül már az a határ amikor még éppen jók vagyunk, de azért belátható, hogy kevés tartalék marad. Viszont a WordPress oldalakat van még bőven hova optimalizálni, így a várható forgalomnövekedések során még mindig nem szalad ki a világba az rpi terheltsége.
Jelenleg a Digitalocean mellett szól a sebesség, az (elvileg) jó skálázhatóság és megbízható, stabil működés. Hátránya a magasabb üzemeltetési költség és drága/kis méretű tárhely.
A raspi mellett szól, hogy rádughatok egy 250G ssd-t usb3.0-n úgy, hogy erről bootol már eleve az alaprendszer is. Onnantól kezdve, hogy van stabil netem, helyem és megvalósításom az üzemeltetésre annyira keveset kér a raspi enni, hogy egy éven belül behozza a raspi a Do-al szemben az árát.
Tegyük fel, hogy szerver költöztetés volt és álmodban sem gondoltad volna, hogy ahhoz, hogy a nextcloud fájljaid látszódjanak az új gépen nem elég csak a data mappát másolni.
Nos, van egy jó hírem: ez nem így van.
Az adatok visszamásolása után ezt kell csak lefuttatnod:
