erik.malm - 2018-04-27 06:58 04s
Behöver göra mig av med ett gäng gamla hårddiskar. Vill gärna utplåna informationen på dem innan det är dags för tippen, om någon har en favorit-utility för sådant så mottages tips gärna.
oscarnylander - 2018-04-27 09:22 00s
DBAN är väl en klassiker
oscarnylander - 2018-04-27 09:51 33s
https://www.palletsprojects.com/blog/flask-1-0-released/
Flask har kommit ut med en 1.0-release! Intressant.
Flask 1.0 Released
daniel.winther - 2018-04-27 09:54 53s
woop woop! på tiden 😄 har ju funnits hur länge som helst
oscarnylander - 2018-04-27 09:56 01s
eller hur, märkvärdigt att de inte gått till 1.0 ännu
erik.malm - 2018-04-27 11:50 44s
Haha, Flask fanns till och med när jag skrev ordentligt med Python senast. Tur att jag väntade i ca 10 år så att jag inte lärt mig omogen teknik! ;) Även om jag mer tror att det här är ett fall av att hantera versioner som Linus. https://betanews.com/2018/04/16/linux-kernel-5-0/
Linus Torvalds says Linux kernel v5.0 'should be meaningless'
oscarnylander - 2018-04-27 11:55 44s
Troligen är det så 🙂
erik.malm - 2018-04-27 11:56 07s
DBAN verkar vara precis rätt verktyg @daniel.winther
oscarnylander - 2018-04-27 11:56 27s
*@oscarnylander 😞
teo.roijezon - 2018-04-27 11:58 09s
@erik.malm @oscarnylander använd inte DBAN för SSD:er
erik.malm - 2018-04-27 11:58 19s
Förr i världen har jag låtit bash skriva från /dev/random över hela disken ett par vändor men har inte energi för det den här gången.
teo.roijezon - 2018-04-27 11:58 46s
dom har mycket intern skrivbalansering osv vilket innebär att rester kommer finnas kvar använd https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase istället
erik.malm - 2018-04-27 11:59 54s
Mmm.. Den nivå på teknik jag gör mig av med är 5200rpms diskar så inte ett problem den här vändan. Men lär vara relevant nästa gång jag kör en utrensning.
teo.roijezon - 2018-04-27 12:00 04s
ahh okej
ja då borde det räcka
eller bara dd if=/dev/urandom of=/dev/sdXN bs=1M ett par ggr
oscarnylander - 2018-04-27 12:01 20s
dd: disk destroyer :parrot:
erik.malm - 2018-04-27 12:01 26s
Det är min vanliga. Men det är fem diskar som kommer behöva behandlas och då slår latmasken till
teo.roijezon - 2018-04-27 12:01 32s
ahh, iC
oscarnylander - 2018-04-27 12:01 43s
koppla in alla och kör parallellt!
erik.malm - 2018-04-27 12:02 50s
Om de bara vore thunderbolt så kunde jag daisy-chaina allt! Som en hårddisk konga-line!
teo.roijezon - 2018-04-27 12:05 24s
https://www.youtube.com/watch?v=deJ9lpNBZUA
That Mitchell and Webb Look - Posh Dancing
erik.malm - 2018-04-27 12:09 35s
Jag är nöjd med hur den här diskussionen slutade. P.S. are we the baddies?
teo.roijezon - 2018-04-27 12:10 58s
tror inte vi har dödskallehattar än? Johan får ta tag i det 😛
joakoles - 2018-04-28 17:47 28s
För ett tag sedan sa jag att jag skulle informera om resultatet av prestandatest-applikationen jag skrev som skulle mäta prestandan i azure event hub (vilket kan ses som ett kafka-alternativ). Applikationen jag skrev består av två delar: En del som skriver en massa events (med samma storlek som vi skickar i produktion) till event hub och en del som läser dessa events från event hub. Skriv-delen är ett azure webjob och läs-delen är en azure function. Båda dessa delar kan skalas upp och ut som man vill. Även själva event hub’en kan skalas genom att höja antalet throughput units (TPU) och antalet partitioner (i praktiken måste man radera och skapa en ny event hub då man inte kan ändra antalet partitioner i efterhand).
Både skriv- och läs-delen hanterar intervall. Man kan då ange att varje instans ska skicka tex. 100 meddelanden per sekund under tex. 1 minut och därefter höja till 500 och därefter till 1000 meddelanden per sekund.
Läs-delen beräknar lite enkla mätdata för att ta reda på prestandan. Mätdatan lagras inte i databasen för varje event då det skulle påverka resultatet mycket. Istället lagras bara mätdatan en gång per intervall, dvs. tex. en gång per minut.
Resultatet visade att throughput blir högt om man skalar upp/ut men att latensen för en del av eventen är förvånansvärt högt trots att man skalat upp/ut (åtminstone blev jag förvånad). De flesta events går igenom event hub’en snabbt men en liten andel tar över en sekund och ibland över 5 sekunder.
Microsoft har själva gjort ett liknande test fast för ett längre flöde och fler events per sekund. Även där ser man att en andel av eventen passerar genom flödet mycket långsammare än genomsnittet. Hälften av eventen passerar flödet på mindre än 1,1 sek medan en del tar mycket längre tid: https://blogs.msdn.microsoft.com/appserviceteam/2017/09/19/processing-100000-events-per-second-on-azure-functions/
Jag vill dock inte påstå att mina mätresultat är 100% tillförlitliga. Det kan vara så att något i applikationen jag skrev är suboptimalt. Dessutom kan klockan skilja sig mellan olika maskiner i azure vilket skulle ge stor effekt på mätresultaten. Jag hörde någon berätta att det är vanligt att klockan i azure-maskiner är “korrekt tid +/- 2 sekunder” vilket innebär ett intervall på 4 sekunder. Ett förslag på workaround är att förlita sig på databas-serverns klocka för att kompensera för detta. Vid uppstart skulle applikationen (både skriv- och läs-sidan) kunna hämta tiden från db-servern för att ta reda på hur den lokala klockan skiljer sig från “sanningen” om vi definerar db-serverns klocka som “sanningen” i prestandatestet. Applikationen får då ta hänsyn till differensen däremellan. Därmed kompenserar man för skillnad i klocka på olika maskiner. Då jag bytt team har jag inte implementerat denna workaround men jag har tipsat teamet om detta.