Kass prestanda med bcache och ssd+hdd, hur felsöka? Ubuntu 21.04

Permalänk
Medlem

Kass prestanda med bcache och ssd+hdd, hur felsöka? Ubuntu 21.04

Hej! Jag har försökt skapa en cachad enhet med hjälp av en intern SSD (sda) i min laptop-server och en partition av en extern hårddisk (sdc2), har följt nedanstående guide och kan se enheten i både Disks och Files. Så långt allt väl. Prestandan ser dock inte ut att ha ökat?

https://wiki.ubuntu.com/ServerTeam/Bcache

Hur kan jag verifiera att SSDn används? Jag använde flaggan --writeback med make-bcache.

Prestanda Bcache:

Prestanda för en identisk SSD:

Läsprestanda HDD i windows.

skärmdumpar från Disks

Är tacksam för all hjälp. PS. Jag är medveten om att hårddisken är extremt långsam, den firade nyss tio år.

Permalänk
Medlem

Det finns många röda varningar på archwikin så verkar utvecklas flitigt så lär finnas en och annan bug.

Har du kontrollerat att writeback-mode:et har blivit satt korrekt? Tror du ska kunna kontrollera det genom `cat /sys/block/bcacheX/bcache/cache_mode`. Det nog det jag kom att tänka på spontant.

Permalänk
Medlem
Skrivet av orp:

Det finns många röda varningar på archwikin så verkar utvecklas flitigt så lär finnas en och annan bug.

Har du kontrollerat att writeback-mode:et har blivit satt korrekt? Tror du ska kunna kontrollera det genom `cat /sys/block/bcacheX/bcache/cache_mode`. Det nog det jag kom att tänka på spontant.

Tack, om du har ett tips på en annan metod för att snabba upp min server provar jag gärna det istället. Mitt mål är att använda diskarna med Nextcloud (redan installerat med apache2 osv). Hade gärna lagrat största mappen med bilder på HDDn och övrigt på SSDn, men man verkar inte kunna göra sådana indelningar i Nextcloud.

Filen cache_mode indikerar att writeback är aktiverat.

writethrough [writeback] writearound none

Jag får nu bättre prestanda, 35 mb/s men den stora förbättringen är 0,18 ms lästider. Jag tror det som gjorde skillnad var en omstart. Utöver det skedde några misstag när jag valde katalog att montera enheten i, och vid skrivandet till fstab. Jag kunde inte heller skriva till enheten men det löstes genom att ge alla användare rwx-rättigheter. Kanske suboptimalt för en server.

Jag är dock inte nöjd med nuvarande prestandan, hade förväntat mig åtminstone 200 mb/s. Har erfarit liknande prestandahöjningar i Windows med PrimoCache. Känns spontant som att 60 GB på SSDn vaskas om den endast förbättrar accesstiden, kunde lika gärna avvarat en mindre partition på några enstaka gigabyte.

Permalänk
Medlem

Bcache jobbar inte som du tror - den kollektar bara småskrivningar där söktiden skulle bli dominerande gentemot transfern av datan medans stora filer (typ över 4 MB - det går att ställa in) går rakt igenom och då lagras med disken hastighet.

Test med 'disk' i ubuntu ger helt fel resultat då det är stora sekvensiella block som skrivs, likaså många andra disktestprogram. - sedan att det bara går med 30 MB/s tyder på andra problem också med dina bakomliggande diskar

En sak till med Write-back - är din SSD mogen för det, jag menar verkligen mogen för det och inte får trimtabelltrassel med allt komplexare allokeringar så att disken svarar långsammare och långsammare för att till slut sparkas ut av kärnan ?? - ha inga viktiga filer som inte har backup när du använder denna mode - lägger den SSD:n av så kan du säga adjöss till din filsystem och då menar jag att den är trasig ordentligt på riktigt. Kör du writethrough och writearound så är skrivningarna i alla fall datasäker när SSD:n ger upp.

Det är nämligen så att Bcache synkar inte datat mot surrdiskarna regelbundet defaultmässigt och tex metadata för filsystemet som hela tiden ändras i små block åker aldrig ut på snurrdisken utan stannar kvar bara i SSD-cachen.

Vill du verkligen plåga SSD för att se att den håller så lägger du en BTRFS ovanpå din Bcache - skapar en subvolym som är komprimerande (skrivna och lästa sektorer är då i 128 kB-block för komprimerad data) - fyller volymen med diskavbilder med små ändringar mellan avbilderna - i nödfall kan det vara samma avbilder.

Sedan kompilerar du upp dedupliceringsprogrammet 'bees' och kör igång den på bcache-volymens BTRFS-filsystem och då lämpligtvis bcache i writethrough - du har volymen kvar efteråt när OS har sparkat ut SSD för att den inte längre svarar i OS inom tid (du följer det i 'dmesg' där det först börja meddela att SSD-enheterna har längre svarstid och till slut sparkas ut av kärnan typ tidigt på morronen) av den tunga skrivlasten och testet brukar inte överleva natten (har provat på 3 SSD, liteon, Adata och samsung 830 - ingen överlevde natten och samsungen är fortfarande konstig trots zeroing och verkar vara brickad).

När man analyzerar SSD som har hängt sig i Bcache användning så är samtliga 3 SSD symtom att det går skitlångsamt när man skriver sekventiellt med slumpad data från disken sektor 0 och vidare och somliga stannar helt efter ett tag och det går inte att skriva till slut utan en power reset/omstart. zeroing (skriva disken med '0' från början till slut) brukar kunna genomföras helt igenom men skrivfarten är bedrövlig även här med SSD-diskar mått (typ 50 MB/s när man förväntar sig +250 MB/s) tills man kört 'zero' ett par vändor och SSD:n börjar närma sig sina datablads-hastigheter)

När man sett detta så skulle jag _aldrig_ spara viktig data genom SSD-cache mot backend-diskar och det är i läge Writeback för SSD-cachen, utan nöja sig med writethrough även om prestanda är betydligt sämre (dvs. disken meddelar 'OK' först när datat är skrivet fysiskt av den fysiska disken - medans vid writeback så är det SSD:n som ger kvitto fast datat inte garanterat nått den fysiska disken (och i bcache kan data bli kvar i SSD väldigt länge innan det trängs ut på fysisk disk pga. att den inte accessats på lång tid och plats behövs))

Skall man ha writecache aktivt på en RAID så pratar vi om de dyra, professionella SSD typ 10-dubbla priset gentemot en konsument-SSD - och det först efter omfattande småsektorskrivtester med bcache som tex 'bees' gör enligt ovan (dvs kan köra i många dagar med dedupliceringsuppdrag med bees och hela tiden ladda in nya diskimages på filsystemet allt eftersom de som finns smälter ned till nästan inget alls i diskförbrukning, utan att SSD visar tecken på längre svarstider)

Problemen för mig har inte varit bcache när det havererar - utan på SSD och dess trimtabell-hantering inte håller måttet med väldigt många små block som skrivs - och skall jag vara ärlig så har tilltron på SSD/NVMe fått sig en törn vid användning utanför 'konsument bruk'

Och man skall komma ihåg att SSD/NVMe-Cache i en NAS/server så är det inte 'konsumentanvändning' längre i skrivmönster och då kan bubblan spricka om det är för enkla/billiga SSD/NVMe som används - be då att det inte är satt som 'writeback' den dagen när det händer!!

Permalänk
Medlem

Jag misstänker att det man försöker efterlikna är hybriddiskarna. Det jag tänker borde snabbas upp vid skrivningar. Om målet är att lagringen ska ske på HDD så kommer läsningarna troligen bara gå förbi SSD och därför begränsas av HDD så länge det inte är en sekvens som hålls cache:ad för en repetitiv uppgift. För skrivningar är det logiskt att man kan dumpa datan på SSD och att det sedan sker en schemaläggning för synken med HDD. Jag noterade att i din första graf så saknas skrivprestandan vilket får mig att ifrågasätta hur den bedömer läsprestandan.

Skrivet av xxargs:

Bcache jobbar inte som du tror - den kollektar bara småskrivningar där söktiden skulle bli dominerande gentemot transfern av datan medans stora filer (typ över 4 MB - det går att ställa in) går rakt igenom och då lagras med disken hastighet.

Det borde ju vara i proportion till hur stora bcache-partitionerna. Har du referens till detta, är nyfiken på implementationsdetaljer?

Skrivet av xxargs:

En sak till med Write-back - är din SSD mogen för det, jag menar verkligen mogen för det och inte får trimtabelltrassel med allt komplexare allokeringar så att disken svarar långsammare och långsammare för att till slut sparkas ut av kärnan ?? - ha inga viktiga filer som inte har backup när du använder denna mode - lägger den SSD:n av så kan du säga adjöss till din filsystem och då menar jag att den är trasig ordentligt på riktigt. Kör du writethrough och writearound så är skrivningarna i alla fall datasäker när SSD:n ger upp.

Detta är en bra poäng men om din SSD skulle sakna det så finns det manuell trimning som går att schemalägga mha systemd. Du kan läsa mer om det här https://wiki.archlinux.org/title/Solid_state_drive .

Skrivet av xxargs:

Det är nämligen så att Bcache synkar inte datat mot surrdiskarna regelbundet defaultmässigt och tex metadata för filsystemet som hela tiden ändras i små block åker aldrig ut på snurrdisken utan stannar kvar bara i SSD-cachen.

Detta låter ju oroväckande så hela uppsättningen fallerar ifall SSDn kraskar för att FS-indexet går förlorat?