Rejtélyes tárhelyproblémák – avagy a disk és a kernel viszonya

Az utóbbi néhány napban a szerverem lévő root partíción – ami egy 60G ssd – hirtelen a foglalt terület felkúszott átlag 55%-ról fokozatosan 100%-ig, 0b szabad, a rendszer megáll és nem értem mi történt.

Az első kör

du -sh * / --exclude <azon könyvtárak, melyekbe a diskek vannak felcsatolva>

Nem találtam semmi érdekeset. De szabad hely fokozatosan elfogyott és megszűnt.

Akkor újraindítjuk a rendszert hátha egyszerűen nincs szinkronban a disk foglalt területe a rendszer által “tudottakkal”. Tehát feltételeztem azt, hogy a rendszer valamit csinált (lehet frissítés vagy programhiba), televerte a disk-et, majd leállt, a hely felszabadult (tehát nem megszámlálható, nem látható), csak erről a kernel maga már/még nem tud.

Szóval újraindítottam. Hely ugyanúgy nincs, a szolgáltatások bő fele már el sem indult.

Töröltem a logokat, még mindig ugyanaz a helyzet. Letiltottam néhány service-t amire gyanakodtam, hogy problémázhatnak, majd újraindítottam ismét a gépet. Lett hely ismét, hurrá! Nem világos miért, de hurrá. Amúgy itt követtem el már a második bakimat.

Eltelt egy nap, majd figyelem a muninon, hogy az elmúlt napokban folyamatosan egy fűrészfog mintát sikerült rajzolni a >szépen lassan megtelik a tárhely, majd törlök valamit és újra lesz hely< alapon. És meglátom, hogy ismét ugyanabban a mértékben foly a hely.

Hogy kiderítsem mi okozza a balhét kicsit utánnakutattam és láttam példát, hogy du-t hogyan lehet hatékonyabban használni – konkrétan sorbarendezés, total számítás.

Ebből megszületett ez, amit a / helyen futtatok:

 du -sch * --exclude home --exclude disks | sort -h

És itt szembesültem vele, hogy az apache2 egy nap alatt kb 11G-nyi error.log-ot termel. Botok rátévedtek a szerveremre ahol folyamatosan olyan hívást csinálnak ami php hibát okoz ezért a hibajelentés oda bekerül.

Mit rontottam el?

Először is nem sorrendeztem így elsiklott a szemem felett a du által számolt terület kb/GB eloszlása és nem vettem elsőre észre, hogy az apache2 okozza a balhét.

Második. Ha töröltem a /var/log-ot korábban miért nem szabadult fel a hely? Az alkalmazás az access.log-ot és az error.log-ot nyitva tartja. Valami rejtélyes oknál fogva engedi az OS, hogy töröljem az appendelt fájl-t, de ennek ellenére továbbra is írja azt a kernel, tehát nincs felszabadult terület. Szerinte. Mert hogy még a fájl valószínűleg nyitva marad.

Egy egyszerű

systemctl restart apache2

után újra megjelent 55% foglalt terület és mindenki boldog.

Most már csak a php hibát kell kiküszöbölni, hogy ne legyen tele az apache error log ezekkel. 🙂

DJI + Huawei P20 Pro + Sony vegas – fix

Egy ideje felfigyeltem rá, hogy a DJI go app – ami egy elég jól sikerült darab, pacsi a fejlesztőknek, elég jól lehet használni, ha van egy osmo mobile-od – hajlamos elrontani a felvételt.

Ez abban nyilvánul meg, hogy visszanézve google photos-ra felszinkronizálva minden rendben, VLC, wmplayer is rendben játsza ellenben a Sony Vegas 15 importáláskor a fájlt elrontja/rosszul olvassa be/whatever. Ekkor a kép vagy akadozik vagy hiányzik eleje vagy vége, vagy – és ami a leggyakoribb – a kép a hangtól el-el csúszik.

Ami valljuk be rendkívül bosszantó.

Viszont ahelyett, hogy tovább hőbörögnénk és követelnénk vissza a pénzünket járjunk utána, hogy mit lehet e jelenség ellen tenni.

Lényeg, hogy kell egy ffmpeg és mondjuk egy linuxos bash és az alábbi script-et a fájlok helyén lefuttatjuk:

mkdir fixed;
for i in *.mp4 ; do
    ffmpeg -i $i -preset slow -strict experimental -c:a aac -b:a 192k -codec:v libx264 -pix_fmt yuv420p -b:v 11000k -minrate 11000k -maxrate 14000k -bufsize 14000k -vf scale=-1:1080 fixed/$i.mp4
done

Ez 1080p30 esetén – 4K vagy 1080p60 esetén valszeg magasabb bitrátát kell beállítanod – a fájl tulajdonságai között megtalálod a megfelelő értékeket!

Ekkor készül egy fixed nevezetű mappa és feldolgozás után ott fognak sorakozni a tökéletesen használható nyersanyagok 🙂

Btw ha nincs bash-ed windowson varázsolj egyet rá, vagy írd meg ennek a Windowsos változatát (ami végigiterál a mappa mp4-es elemein) és küldd el nekem és update-elem a postot 🙂

HDD to SSD linuxon

A hétvégén rákényszerültem, hogy a nagyobb méretű, de már régi HDD-ről a linuxos gépemet átköltöztessem egy kisebb méretű SSD-re. A clonezilla nem segített így kézzel kellett átmigrálnom a teljes fájlrendszert.

Halál egyszerű, csak oda kell minden lépésre figyelni.

Teendők:

Rakd be a hdd-t és az ssd-t is egy számítógépbe, lehetőleg sata csatlakozóra kösd, usb-n sokáig fog másolni.

Bootolj be egy live ubuntut a számítógépen.

Ezután nyiss egy konzolt, formázd le a cél ssd-t,

fdisk /dev/sdb #sdb az SSD!
> o
> n
> enter, enter, enter...
> p (ha egy partíció látszik szuper)
> w

mkfs.ext4 /dev/sdb1 #feltéve, hogy ext4-et szeretnél

Készítsük elő a műveleteket

mkdir /mnt/{ssd,hdd}
mount /dev/sda1 /mnt/hdd #sda a HDD!

majd rsync-el másold át, illetve hozd létre a szükséges mappákat

rsync --exclude="mnt" --exclude="lost+found" --exclude="sys" --exclude="proc" --exclude="cdrom" --exclude="media" --exclude="swapfile" -aP /mnt/hdd/ /mnt/ssd/
mkdir /mnt/ssd/{mnt,proc,sys}

Majd telepíts grub-ot

mount -o bind /dev /mnt/ssd/dev
mount -o bind /sys /mnt/ssd/sys
mount -t proc /proc /mnt/ssd/proc
cp /proc/mounts /mnt/ssd/etc/mtab
chroot /mnt/ssd /bin/bash
grub-install /dev/sdb
grub-install --recheck /dev/sdb
update-grub

Majd írd át a bootolandó meghajtó uuid-ját az fstab-ban

blkid /dev/sdb1

Az itt található uuid-t vidd fel az fstab-ba

nano /mnt/ssd/etc/fstab

Ha nem kaptál sehol hibát

init 0

A gép leáll, vedd ki a hdd-t, kapcsold vissza, biosban csekkold le, hogy az ssd-ről fog-e bootolni.

Enjoy!

SSD cache linux rendszeren

Képzeld el – van egy méretes HDD-d, melyen adatbázist tárolsz, torrentezel, vagy oprendszert futtatsz. Végülis mindegy, a lényeg az, hogy néha marha lassú a rendszer, IOwait a plafonban.

Tudod jól, hogy kéne ssd-re váltani, de nincs az a pénz, hogy marha nagy HDD-k helyett SSD-kre cseréljél.

Szóval a probléma adott, HDD kéne megközelítőleg SSD tempóban – vajon mi lehet a megoldás?

Mintapélda, teljesítményben egy idális világot képez :)
Mintapélda, teljesítményben egy idális világot képez 🙂

Egy korábbi részben ecseteltem egy lehetséges megoldást erre vonatkozóan Windows rendszeren, de most nálam linux szerveren adódott a probléma és a dolog megoldásért kiáltott és végül találtam valamit.

bcache

Az elv itt is azon alapul, hogy a merevlemez írási és olvasási gyorsítótárát kiegészíti a rendszerhez illesztett plusz SSD.

Nekem egy 3T-os disk-em van és úgy alakult, hogy egy 60G SSD felhasználható a célra. Mindkét meghajtót a leggyorsabb sata portokra csatlakoztattam és az alábbiakat műveltem.

Törölnöm kellett a teljes ssd-t és a gyorsítani kívánt partíciót (sde = SSD, sdc = HDD):

wipefs -a /dev/sde

wipefs -a /dev/sdc1

Létrehoztam egy bcache partíciót:

make-bcache -C /dev/sde -B /dev/sdc1 --block 4k --discard --writeback

Írási gyorsítótártól ha tartasz ne használd a writeback paramétert, ha pedig az ssd-d nem támogatja a TRIM módot vedd ki a discard paramétert.

Ezután már csak létrehoztam az új tömbön egy fájlrendszert:

mkfs.ext4 /dev/bcache0

Majd /etc/fstab-ba felvettem a /dev/bcache0 virtuális meghajtót és voila.

Statisztikákért pedig ezekhez nyúlok:

cat /sys/block/bcache0/bcache/dirty_data

tail /sys/block/bcache0/bcache/stats_total/*

Vagy akár folyamatosan:

watch -n 5 tail /sys/block/bcache0/bcache/stats_total/*

 

Jó kísérletezést! 🙂

Ezért érdemes sshfs-t -C kapcsolóval használni

1445465012_Database-CloudVan ugye az a protokoll – remélem ismerős -, hogy “sftp”. Tegyük fel, hogy van egy linuxos adattároló szervered és egy linuxos géped. Közvetlen fel tudod csatolni sshfs-el a távoli gép valamely mappáját, ha van rajta unix felhasználói fiókod és hozzáférésed.
Namost az sshfs-nek van egy -C, mint compression kapcsolója, ami a két gép közötti átviteli sebesség növelésében játszhat szerepet, mivel a két gép közötti adatfolyamot képes tömöríteni. Ehhez persze némi processzor kell mindkét oldalon, de egy HP microservernek sem konnyan meg a dolog (nálam az érintett adattároló gép).
Tehát ha linuxot használsz az alábbi paranccsal felcsatolhatod a távoli gép könyvtárát a helyi gépedre:

 sshfs -o allow_other,default_permissions -o IdentityFile=/helyi_szerver/publikus_kulcs winben@szerverem.hu:/tavoli_szerver/csatolasi_pont /helyi_szerver/csatolasi_pont -C -o reconnect;

 

Mi az eset akkor, ha Windows használok?

Igen, sokan vagyunk így, kipróbálhatunk egy csomó sshfs-t megvalósító alkalmazást. Ilyen a fizetős expandrive, vagy az ingyenes win-sshfs.

Részemről egyik sem nyerte el a tetszésemet többek között azért, mert instabilak voltak, suttyomban a program files-ba cache-eltek és nem is a valós állapotot mutatták sokszor…és legfőbb problémám volt, hogy láthatólag egyik sem szolgált a tömörítős megoldással, ami miatt (vagy még mellett) dög lassú volt az adatátvitel.

Nos, ha van egy kis memóriád fölösen a gépben akkor van egy szuper jó hírem – a probléma baromi jól orvosolható.

  1. Készíts egy linuxos virtuális gépet localhoston, ami NATolva csatlakozik a hálózatra, tehát a te géped oszt neki IP címet.
  2. Ha megvan a telepítés csatold fel a távoli mappát a virtuális géped egy helyi mappájába.
  3. Ezután telepíts sambát a virtuális gépre és oszd meg a felcsatolt mappa tartalmát.
  4. Tallózd be Windows Intézőben a sambán megosztott tartalmat és örülj. Az adatátvitel gördülékeny lesz és megfelelő tartalom esetében gyors.

Ha olyan kontentről van szó, ami jól tömöríthető akkor sokszoros sebességet érhetsz el “logikailag”, mint egyébként “fizikailag”, tehát a fizikai vonalon.

 

Bizonyításként hadd mutassam a feladatkezelőmet:

aa99259e10b2a668d37f45b32ea9d906

Itt éppen egy lemezképfájlt másoltam. A képen az látható, hogy a Total Commander 176 Mb/s-al tölti felfelé az adatot, a VMware NAT Service pedig a virtuális gépet jelképezi és látszik, hogy 47,5 Mb/s a “fizikai” adatfolyam. Tudni kell azt is, hogy a mérés idején a laptopom céges wifi routerre volt csatlakozva vezetéknélküli hálózaton és nem egy irodában lévő másik gépre, hanem az otthoni szerveremre tolta át az adatot – ennek köszönhető, hogy csak ~50 Mbit környékén történt az adatátvitel. A másolás idején 50-70% között volt a 1.5 GHz-es HP microserverem cpu terheltsége (mivel kétmagos így 200%-ból), és 0,93-as volt a 15 perces átlag load.

 

Akik kicsi internetsebességgel rendelkeznek (100 Mbit alatt) és távoli szerverre dolgoznak bőven megfelel és tűrhetően is működik az ExpanDrive. Ha viszont helyi 100 megás hálón (vagy azzal egyenértékű neten) szeretnénk Windows-on sshfs kapcsolódást érdemesebb efféle perverzióhoz folyamodnunk.