2016-10-31 16:15:31

How to replace deprecated platform.distro()

The Python method platform.distro() have been deprecated since Python 3.5. And it will be removed in Python 3.7. So it is about time to really replace it in your (and my) code.

Fortunately there is a new python module "distro". I packaged it for Fedora and EPEL so it should be available in main repository now. It is available as python2-distro and python3-distro.

The replacement is quite easy. Instead of:

import platform
platform.dist()

you just put there:

import distro
distro.linux_distribution(full_distribution_name=False)

and that's all.


Posted by Miroslav Suchý | Permanent link
Comments

2016-10-31 16:14:09

Dům na baterku

Před půl rokem jsme se rozhodli si pořídit soláry. A nyní už je to více než měsíc co nám plně fungují. Jelikož se mě hodně lidí na to ptá, tak to hodím i sem.

Tak předně si ujasněme termíny, protože není solár jako solár. Existují soláry na ohřev teplé vody (odborně kolektory). Těmi proudí kapalina a s elektřinou nemají nic společného. Ty sice máme taky (už čtyři roky) a jsou výhodnější než elektrika, ale o těch teď nechci psát. Pak jsou soláry, které vyrábějí elektriku - fotovoltalická elektrárna (FE). Ty pak mohou být dvojího druhu. Buď se vyrobená elektřina prodává distribučním firmám za regulovanou (rozuměj dotovanou) cenu - to jsou ty elektrárny na které se tak nadává. Nebo se vyrobená elektřina ukládá do baterek a z baterek se potom čerpá večer a v noci, když slunce nesvítí. Tomu se říká "Ostrovní systém" nebo "Hybridní fotovoltalická elektrárna (HFVE)". A přesně takovou máme. Tj. do sítě nic nedodáváme, takže nijak nebohatneme, ale neprojídáme žádné dotace. Přes den elektřinu ukládáme do velké baterky a v noci jede celý dům z baterky.

Nejčastější dotaz: kolik ta sranda stála? Stála 459 tisíc Kč. Ale tady platí víc než u jiného zboží, že se vyplatí zjistit: co kupujete, proč to kupujete a k čemu to bude. Měl jse i nabídku na HFVE za 271 tis. Kč. Ale když jsem to parametrově porovnával, tak jsem zjistil že tam je méně panelů, menší kapacity baterek, měniče. Takže ta levná nabídka je vlastně docela drahá.

Máme na střeše 18 panelů Solet 280Wp. Každý panel má 1,6 m2, takže dohromady pokrývají cca 29 m2. Panely samotné ale nejsou nejvýraznější položkou. A to ani cenovou ani co se týče problémů. Nám se panely vešly na střechu od garáže (kde už byly dva kolektory na ohřev teplé vody). A stále nám zbýva místo na střeše domu, kdybychom někdy chtěli zvýšit kapacitu. Větším oříškem je baterka.

Baterky mají tří základní parametry: cenu, velikost, kapacitu. Vybrat si můžete dva parametry. Ten třetí pak vždy hodně ustřelí. Já jsem nakonec zvolil variantu olověných akumulátorů. Mají příznivou cenu a kapacitu, ale jsou velké. Celá baterka váží tunu a měří 1219 x 352 x 782 mm (dělají se i více krychlovité, ale já potřeboval úzkou baterku). Naše baterka se skládá z 24 článků (ne nepodobné autobaterii), které jsou v jedné velké vaně a zapojené do série, takže dohromady vytváří napětí 48V a kapacitu 625 Ah. Kdybych chtěl Li-Fe baterky, tak ta stojí 1500 Euro a má kapacitu jenom 250 Ah. Obdobná cena a kapacita platí i pro slavnou Tesla Powerwall, ale o té se navíc jenom mluví a do dneška se reálně nedá koupit. Největší nevýhodou naší olověné baterky je, že se musí každý týden dolévat destilka (asi tak 0.5l týdně) do elektrolytu (pokud nechci aby klesla životnost). A že se z baterky při dobíjení odpařuje kyselina sírová a vodík. Ne moc, ale příjemné to není a místnost by měla být odvětrávaná. Pokud jste teď vystrašení (vodík přece vybuchuje!), tak vodík vybuchuje při koncentraci 4%. A v našem malém kumbálu (2x3 metry) by to znamenalo že bych ho musel hermeticky uzavřít na celý týden aby tam takové množství vodíku vzniklo. Což rozhodně nehrozí. Vývoj baterií se ovšem dere rychle ku předu a za rok budou parametry a ceny baterek zase jinde. Takže počítám s tím, že o tuto baterku budu pečovat a až ji skončí životnost (tak za 6 let), tak si pořídím nějakou jinou co nebude potřebovat takovou údržbu. O životnosti baterie a co na ni má vliv se můžete dočíst např. zde.

Když jsme elektrárnu zprovoznili, tak jsem si myslel, že přes den nebudeme spotřebovávat žádný proud z distribuční sítě. K mému překvapení tomu tak nebylo. Celý systém si neustále bere tak 10 % elektřiny ze sítě! Proč? Elektřina z panelů jde přes měnič který je převádí z DC na AC. My máme měnič XTM 4000-48. Ten zvládne dodávat 4kVA po dobu 30 minut. Nebo 3,5kVA trvale. Jakmile bych tedy zapnul počítač, myčku a vysavač - tak jsem přes kapacitu tohoto měniče. On si sice umí inteligentně dobrat elektřinu ze sítě, ale na to potřebuje být synchroní s distribuční sítí a proto neustále odebírá trochu proudu ze sítě. Pokud bych chtěl odebírát nulu z distribuční sítě, tak bych si nemohl užívat luxus neomezené elektřiny. A buď musel myslet na to, že nesmím zapnout příliš mnoho spořebičů nebo koupit další měnič.

Co mě naopak velmi příjemně překvapilo - že se celý systém chová jako velká UPSka. Pokud vypadne distribuční síť (což se u nás na venkově děje více než je mi milé), tak HFVE okamžitě přepne na baterky. A to tak rychle že se počítače doma neresetují.

Jak je to s třífázovým rozvodem? Naše HFVE je jednofázová. V domě jsou sice třífázové rozvody. Ale funguje na ně jenom trouba a sporák. A 3fázová zásuvka v garáži, která za 4 roky nebyla použita ani jednou. HFVE sice zásobuje všechny fázové rozvody, ale není mezi nimi fázový posun. Což třeba troubě nevadí. Ale vadilo by to třeba míchačce - a obecně rotačním motorům, které by to asi zavařilo. Takže pokud někdy budu chtít připojit míchačku, tak musím otočit jedním knoflíkem, který přepne dům na distribuční síť (a odstaví HFVE). Pokud by někdo potřeboval nutně tři fáze, tak to lze spravit dokoupením dvou dalších měničů. Ale v mém případě by to byli vyhozené peníze.

Jak dlouho vydrží jet dům na baterku? Naše baterka má 625 Ah. Při normálním provozu její kapacita přes noc klesne maximálně na 80 %. Přes den se stihne krásně dobit a ještě hodně proudu zbývá a pouštíme ho do zdi. Včera večer jsme měli zapnuto hodně spotřebičů (trouba, myčka, počítač, půl baráku svítilo a možná ještě něco) a displej ukazoval že spotřeba je 15 A a že tímto tempem by to vydrželo ještě 50 hodin. Takže v případě nouze bycho m na baterce vydrželi skoro měsíc. Ale v normálním provozu (např. v zimě) to nechcete huntovat až na nulu, protože to razantně snižuje životnost baterky.

Návratnost? Já momentálně platím cca 2 tisíce měsíčně za elektřinu (protože mám hodně počitačů, holt jsem IT exot). Takže za 20 let ušetřím cca 430 tisíc. Což je plus mínus cena celé sestavy. Samozřejmě je potřeba započíst obnovu ba terky. Ale řekněme, že se to nyní tak tak zaplatí. Takže taková záporná nula. Trochu nejistá. Ale počítám, že během pár let si pořídím čistý elektromobil, a pak by to mohlo být i zajímavější. Na elektrárnu naší velikosti se dá i sehnat jednorázová dotace 100 tisíc. Což momentálně zkouším (je to stále v procesu). Uvidím jak to dopadne.

Proč to dělám? Když pominu ty zřejmé důvody (nezávislost, ekologie) tak pro zkušenost. Před pár lety byl HFVE ekonomický nesmysl. Dneska to je na hraně. A za pár let to bude jasně ekonomicky výhodnější. Ale stále je tu dost lidí, kteří si myslí, že to nikdy nebude fungovat a že to je celý nesmysl (ahoj tati). A druhý zbytek lidí je zdravě skeptický, protože o tom nic neví (ještě před rokem i já). Takže chci nabrat zkušenosti a pak skeptikům vyvracet jejich názory. Ale už podložené daty a zkušenostmi z provozu. Například tím, že dnes už existuje technologie MPPT, která docela dost zvyšuje učínost.

A nakonec nějaké fotky.


Posted by Miroslav Suchý | Permanent link
Comments

2016-10-31 16:09:05

Flock 2016 Report

I spent previous week in Kraków at Flock. It is a conference of Fedora developers and users. I really liked it - hmm this is not enough - It was awesome!

For me the best part was those social events. Every single event there was prepared some social event and I met a lots of people I never met before and learn about interesting things they are doing. I was at FUDcon in Zürich, Flock in Prague, but Kraków done really best job so far. And the town is sooo beautiful. I have to admit that I had a lot of prejudice about Poland and Polish cities, but I was really overhelmed. And I do plan to return there with my family for some holidays.

City bus full of Flock

Probably the best talk for me was by Radosław Krowiak about Akademia Programowania. It is a company in Poland and they are trying to learn programming 5+ years old kids. Exactly the same what I am doing in Czech! The presentation itself was nothing new to me, but the follow up discussion in lobby was very informative. For example I was surprised that they are successful with programming in pairs.

The most surprising talk for me was "I contributed! but, what now?" by Bee Padalkar. She done some data mining and shown us that we are loosing a lots of people as contributors. That means they join, do some contributions, but within 3 months they are gone. Most of them. We - the senior contributors - should definitely do better to mentor the newcomers. I took this talk very personally and I will try to focus on this area in near future.

"Fedora's MirrorManager - now and the future" by Adrian Reber. I learn some background of MirrorManager. I was taken by surprise that in background there is lots of crawler which pro-actively monitor health of the mirrors.

Definitely the most important talk was "Modularity: Why, where we are, and how to get involved", because that may be the future of Fedora. Langdon was able to do (live) demo of modules installation. The idea is that you will have some core modules (think about it as stripped down Cloud/Server/Workstation spin) and you will install modules. Modules are group of packages which works together. Something like comps, but each of them has own repository and there is some more logic behind. This will allow you to have e.g. newest Fedora and some old stable httpd. Or vice versa - old Fedora (or maybe RHEL in future) and newest PHP.

On Thursday I attended "Fedora Badges Workshop". I expected that I will just watch others as I have no talent for drawing and painting. But ... at the end I draw a brand new badge!

I voted badge

And yes - I had two talk. One was together with Clime about state of Copr (slides and the other was about Fedora Sponsors (slides. We had very nice discussion there and there was great ideas how to improve the process. You can follow up it on devel mailing list.

Was there some drawback? Unfortunaly yes. I participated in one morning run, which Vít arranged and I ran bare foot and ripped off one nail.


Posted by Miroslav Suchý | Permanent link
Comments

2016-04-21 12:31:39

WIP: rebuilding all PyPi modules as RPM packages

For some time, Copr can build RPM package directly from PyPi (see previous blogpost), which means that you can build some modules on your own very easily. But are we able to build all modules in PyPi? "All" is equal to number 79 000 right now. Will Copr be able to cope with that? These days, the largest Copr repositories had have hundreds of packages. One experimental repository had 2000 packages. But 79 000?! No one tried that so far. What problems can we experience? Lets try it!

I have created quick'n'dirty script, which gets names of all modules from PyPi and submit them to Copr. Only submitting the builds into Copr takes almost whole day (21 hours). And importing into dist-git would take about 4 days (average time to import one module is 4 seconds). Our dist-git import is single threaded (because it is so fast and no one ever will be able to submit task so fast - haha). So if I would do that on production server, no one will be able to submit package into Copr for 4 days(!), because they would be blocked by importing queue. So I've throttled it by sleep(4) and the importing queue is short now.

Importing was quite fast - 4 seconds per module and 4 days in total. What about actual builds? Each package takes approximately 1-2 minutes to builds. That means 55-110 days in total. Each user can run max. 4 tasks in parallel, which means that it would take about 14-28 days to build all packages. Just for one chroot. On the development server, where there are no other users but me and my colleagues, I temporary raised the limit to 12 tasks in parallel per one user (so I'm blocking my collegues now). And the batch should be finished in 5-10 days.

But there is one problem. We want to build python2 and python3 subpackage. But some packages fails to build with python2 and some fails to build with python3. Such packages need to be build with only one subpackage. But which one? There is only one reliable method - trial and error. So we are going to create Copr project PyPi-2, where we will build all the packages only for python2 only. And another project PyPi-3, where we will build all packages only for python3. Then, we'll gather the statistics and try to build all packages in a final PyPi repository. Packages which succeed in both PyPi-2 and PyPi-3 projects will be build with both submodules enabled. Packages which succeed with only one, will be build with only one subpackage enabled. So that means it will take 28-56 days just to gather those statistics.

Is Copr WebUI able to handle such big number of records in one project? Sort of. The tab "Builds" loads quite long. But it will finish in reasonable time. And the Javascript code is able to sort and search the results in real time (at least on my workstation). However the tabs "Packages" and "Monitor" times out. We are working right now on the performance improvements.

In the time I'm writing this, Copr have finished 38k builds. From which 33.4k failed and 4.7k succeeded. That gives us 12 % chance to successfully build package. This is not a big number. BTW, when we did this experiment with only those PyPi modules, which are already packaged in Fedora, the success ratio was more than 50 %. We use Pyp2rpm for conversion of python modules to RPM package. We started our experiment with version 1.x and we provided lots of feedback to Michal Cyprian (upstream of pyp2rpm). We moved to version 2 recently and soon we will move to version 3. So I hope that success to fail ratio will be much higher in future. And on our TODO list is parsing build requirements and building packages in correct order, which may improve the number a lot.

BTW: while we build these python modules, Copr will automatically creates package definitions and when there is new release in PyPi, then Copr will automatically build updated rpm package within a day!

To sum it up: in 2-3 months we may have a repository with at least ten thousand python package for python2 and/or python3.


Posted by Miroslav Suchý | Permanent link
Comments

2016-03-29 15:56:48

New features in Copr

Jakub just released new version of Copr. What's new there?

There is new feature "forking". More about it on Jakub's blog. We created it so you can have projects for nightly builds and at one point you can fork your project to "yourproject-stable" and all successfull builds will be copied there. When you find some issue there during release testing, you can rebuild your package just in that forked projects and any new builds in your nightly projects will not affect your stable projects.

Another big feature is build directly from PyPi. Just fill in name of the module and we will create RPM for you automatically. And if you create record on Release-Monitoring.org for that module, then we will automatically rebuild that package once there is new release!

You can submit from command line using:

copr-cli buildpypi --packagename PYPINAME --packageversion PACKAGEVERSION msuchy/myproject

or from webUI. Hopefully this screenshot is self-explanatory:

Building PyPi from Copr webUI

Internally we use Pyp2Rpm to create SRPM. Right now we still use 1.x version. But we will soon deploy pyp2rpm-3.0 version. Which contains big enhancement from Michael Mráka and Michal Cyprian. It contains better parser of setup.py so the success to fail will be much much higher. If your build from PyPi fails, then please report it to authors of Pyp2RPM.

There is pending pull-request for Anitya so it can emit messages even if you previously did not register the module. The PR is currently stuck, so any help is welcome.

And there is some bugfixes and internal changes, which you probably do not find so interesting as we do :).

What will be next?

We will try to rebuild whole PyPi repository! Once we are done, we plan to do the same with CPAN, Rubygems and others.


Posted by Miroslav Suchý | Permanent link
Comments

2016-02-06 13:31:29

Brief history of DevConf.cz

I am this weekend at DevConf.cz and I met here several friends who do not work in Red Hat. They are able to speak about some interesting technical topics, but are afraid to give their speech here, because "This is something else then Red Hat is doing.". This is false assumption. We are interested in all open source projects. No matter if Red Hat is using it or not. Let me tell you brief history of DevConf.cz and you will understand better.

Long time ago, Red Hat Czech was just 60 people. And few hundreds Red Hat world-wide. We knew each other personally. But as we grow every year we are way over Dunbar number. So we had an idea that during our team-building activity we present something interested to each other. Usually something we work on and what can be interested for others. So the first event happen at hotel loungue.

Next year we decided to invite our US colleagues and we moved to University (much better then hotel lounge). And since there is nothing secret we decided to open it to students and anybody interested in. Because sharing is better. First year (2009) only few of them came and most of attendees were from Red Hat and conference was mostly in Czech language. And then the conference grew and grew. Most of the topic were in English. And now all session are in English. Every year there was lots of interesting topics. And this year is huge! With lots of people outside of Red Hat. Which is great!

Red Hat still organize this event, because we will do something like this anyway. And the in the term of cost, it really does not matter too much if you have 500 attendees or 1200 attendees.

So for historical reasons most of the talks are from Red Hat employees. But this is open conference. And we will love to hear what new open source technology you develop or use in your company. So during October there should be call for papers for DevConf.cz 2017 and you should not hesitate to submit your topic. Even if you are not from Red Hat or it is about technology not used by Red Hat. We would really love to attend your presentation too.


Posted by Miroslav Suchý | Permanent link
Comments

2015-09-09 17:16:37

Performance of RAID1 with mix of HDD and SSD

I have several computers where I have discs in RAID1 configuration (aka mirroring). All of them are magnetics HDD. I am thinking about replacing them with SSD. However to replace all of them, would cost a lot of money.Hmm - what if I only replace one (of two) disc in that array. What will be the performance. Do I get the best from HDD and SSD? Or the worst? There is a lot of benchmarks of HDD alone, a lot of benchmarks of SSD alone. But the mix in RAID is unknow.

Recently I got one spare SSD and some HDD so I was able to do some benchmarks.

First reading tests (write benchmarking is in second part of this blogpost). I used iops test.

The throughput of my SSD is between 61.6 Mbit/s and 2.4 Gbit/s. Raw data:

# python iops-2011-02-11  /dev/sdb
/dev/sdb, 120.03 GB, 32 threads:
 512   B blocks: 15033.9 IO/s,   7.3 MiB/s ( 61.6 Mbit/s)
   1 KiB blocks: 14838.3 IO/s,  14.5 MiB/s (121.6 Mbit/s)
   2 KiB blocks: 13785.3 IO/s,  26.9 MiB/s (225.9 Mbit/s)
   4 KiB blocks: 11490.4 IO/s,  44.9 MiB/s (376.5 Mbit/s)
   8 KiB blocks: 11273.0 IO/s,  88.1 MiB/s (738.8 Mbit/s)
  16 KiB blocks: 7147.7 IO/s, 111.7 MiB/s (936.9 Mbit/s)
  32 KiB blocks: 4037.1 IO/s, 126.2 MiB/s (  1.1 Gbit/s)
  64 KiB blocks: 2177.5 IO/s, 136.1 MiB/s (  1.1 Gbit/s)
 128 KiB blocks: 1139.4 IO/s, 142.4 MiB/s (  1.2 Gbit/s)
 256 KiB blocks:  712.4 IO/s, 178.1 MiB/s (  1.5 Gbit/s)
 512 KiB blocks:  434.5 IO/s, 217.3 MiB/s (  1.8 Gbit/s)
   1 MiB blocks:  241.6 IO/s, 241.6 MiB/s (  2.0 Gbit/s)
   2 MiB blocks:  129.5 IO/s, 259.0 MiB/s (  2.2 Gbit/s)
   4 MiB blocks:   66.5 IO/s, 266.0 MiB/s (  2.2 Gbit/s)
   8 MiB blocks:   34.1 IO/s, 272.9 MiB/s (  2.3 Gbit/s)
  16 MiB blocks:   17.5 IO/s, 280.6 MiB/s (  2.4 Gbit/s)

The throughput of HDD is between 518.1 kbit/s and 850.9 Mbit/s. Raw data:

# python iops-2011-02-11 /dev/sda
/dev/sda,   1.00 TB, 32 threads:
 512   B blocks:  126.5 IO/s,  63.2 KiB/s (518.1 kbit/s)
   1 KiB blocks:  115.4 IO/s, 115.4 KiB/s (945.2 kbit/s)
   2 KiB blocks:  104.6 IO/s, 209.2 KiB/s (  1.7 Mbit/s)
   4 KiB blocks:  100.0 IO/s, 399.8 KiB/s (  3.3 Mbit/s)
   8 KiB blocks:   97.2 IO/s, 777.7 KiB/s (  6.4 Mbit/s)
  16 KiB blocks:   93.3 IO/s,   1.5 MiB/s ( 12.2 Mbit/s)
  32 KiB blocks:   85.9 IO/s,   2.7 MiB/s ( 22.5 Mbit/s)
  64 KiB blocks:   78.0 IO/s,   4.9 MiB/s ( 40.9 Mbit/s)
 128 KiB blocks:   64.0 IO/s,   8.0 MiB/s ( 67.1 Mbit/s)
 256 KiB blocks:   46.1 IO/s,  11.5 MiB/s ( 96.6 Mbit/s)
 512 KiB blocks:   35.7 IO/s,  17.9 MiB/s (149.8 Mbit/s)
   1 MiB blocks:   30.2 IO/s,  30.2 MiB/s (253.5 Mbit/s)

# python iops-2011-02-11 -n 8  /dev/sda
/dev/sda,   1.00 TB, 8 threads:
 512   B blocks:  112.7 IO/s,  56.3 KiB/s (461.4 kbit/s)
   1 KiB blocks:  108.8 IO/s, 108.8 KiB/s (891.1 kbit/s)
   2 KiB blocks:  101.6 IO/s, 203.2 KiB/s (  1.7 Mbit/s)
   4 KiB blocks:   97.8 IO/s, 391.1 KiB/s (  3.2 Mbit/s)
   8 KiB blocks:   96.1 IO/s, 768.8 KiB/s (  6.3 Mbit/s)
  16 KiB blocks:   90.0 IO/s,   1.4 MiB/s ( 11.8 Mbit/s)
  32 KiB blocks:   85.0 IO/s,   2.7 MiB/s ( 22.3 Mbit/s)
  64 KiB blocks:   81.2 IO/s,   5.1 MiB/s ( 42.6 Mbit/s)
 128 KiB blocks:   78.4 IO/s,   9.8 MiB/s ( 82.3 Mbit/s)
 256 KiB blocks:   52.1 IO/s,  13.0 MiB/s (109.2 Mbit/s)
 512 KiB blocks:   36.2 IO/s,  18.1 MiB/s (151.8 Mbit/s)
   1 MiB blocks:   36.4 IO/s,  36.4 MiB/s (305.3 Mbit/s)
   2 MiB blocks:   28.3 IO/s,  56.6 MiB/s (474.4 Mbit/s)
   4 MiB blocks:   18.5 IO/s,  74.0 MiB/s (621.2 Mbit/s)
   8 MiB blocks:   11.4 IO/s,  91.2 MiB/s (765.3 Mbit/s)
  16 MiB blocks:    6.3 IO/s, 101.4 MiB/s (850.9 Mbit/s)

In the second run I lowered number of concurent process, which let the test run with bigger blocks. Those big blocks are close to sequential reading and you can see that HDD is quite close to SSD here. Or at least the gap is not as big as with smaller blocks where the difference is by order of magnitude.

Now I created 40GB partitions on both disc and created software raid1 using both disc (using mdadm). The throughput is between 57.8 Mbit/s and 2.5 Gbit/s. This is very very close to pure SSD performance. Mind that I do not care about absolute numbers, but about the relative change. Relative to pure SSD and HDD performance. Raw data:

# python iops-2011-02-11  /dev/md0
/dev/md0,  42.92 GB, 32 threads:
 512   B blocks: 14104.5 IO/s,   6.9 MiB/s ( 57.8 Mbit/s)
   1 KiB blocks: 13733.6 IO/s,  13.4 MiB/s (112.5 Mbit/s)
   2 KiB blocks: 13097.5 IO/s,  25.6 MiB/s (214.6 Mbit/s)
   4 KiB blocks: 11847.7 IO/s,  46.3 MiB/s (388.2 Mbit/s)
   8 KiB blocks: 11534.3 IO/s,  90.1 MiB/s (755.9 Mbit/s)
  16 KiB blocks: 7303.0 IO/s, 114.1 MiB/s (957.2 Mbit/s)
  32 KiB blocks: 4129.3 IO/s, 129.0 MiB/s (  1.1 Gbit/s)
  64 KiB blocks: 2250.5 IO/s, 140.7 MiB/s (  1.2 Gbit/s)
 128 KiB blocks: 1198.1 IO/s, 149.8 MiB/s (  1.3 Gbit/s)
 256 KiB blocks:  759.2 IO/s, 189.8 MiB/s (  1.6 Gbit/s)
 512 KiB blocks:  457.2 IO/s, 228.6 MiB/s (  1.9 Gbit/s)
   1 MiB blocks:  255.7 IO/s, 255.7 MiB/s (  2.1 Gbit/s)
   2 MiB blocks:  136.3 IO/s, 272.6 MiB/s (  2.3 Gbit/s)
   4 MiB blocks:   71.3 IO/s, 285.3 MiB/s (  2.4 Gbit/s)
   8 MiB blocks:   36.4 IO/s, 291.5 MiB/s (  2.4 Gbit/s)
  16 MiB blocks:   18.9 IO/s, 303.0 MiB/s (  2.5 Gbit/s)

Just for the record I bechmarked how change the performance of the MD raid1 on the two HDD.

#  python iops-2011-02-11 /dev/sdb3
/dev/sdb3,   2.00 TB, 32 threads:
 512   B blocks:   38.3 IO/s,  19.1 KiB/s (156.8 kbit/s)
   1 KiB blocks:   37.2 IO/s,  37.2 KiB/s (304.6 kbit/s)
   2 KiB blocks:   48.9 IO/s,  97.7 KiB/s (800.7 kbit/s)
   4 KiB blocks:   44.9 IO/s, 179.6 KiB/s (  1.5 Mbit/s)
   8 KiB blocks:   37.4 IO/s, 299.1 KiB/s (  2.5 Mbit/s)
  16 KiB blocks:   38.2 IO/s, 611.5 KiB/s (  5.0 Mbit/s)
  32 KiB blocks:   32.0 IO/s,   1.0 MiB/s (  8.4 Mbit/s)
  64 KiB blocks:   23.4 IO/s,   1.5 MiB/s ( 12.3 Mbit/s)
# python iops-2011-02-11 /dev/sda3
/dev/sda3,   2.00 TB, 32 threads:
 512   B blocks:   41.8 IO/s,  20.9 KiB/s (171.1 kbit/s)
   1 KiB blocks:   41.6 IO/s,  41.6 KiB/s (340.5 kbit/s)
   2 KiB blocks:   42.1 IO/s,  84.3 KiB/s (690.4 kbit/s)
   4 KiB blocks:   42.3 IO/s, 169.3 KiB/s (  1.4 Mbit/s)
   8 KiB blocks:   34.5 IO/s, 276.3 KiB/s (  2.3 Mbit/s)
  16 KiB blocks:   43.1 IO/s, 689.8 KiB/s (  5.7 Mbit/s)
  32 KiB blocks:   36.0 IO/s,   1.1 MiB/s (  9.4 Mbit/s)
  64 KiB blocks:   34.6 IO/s,   2.2 MiB/s ( 18.1 Mbit/s)
# python iops-2011-02-11 /dev/md2
/dev/md2,   2.00 TB, 32 threads:
 512   B blocks:   63.6 IO/s,  31.8 KiB/s (260.6 kbit/s)
   1 KiB blocks:   48.1 IO/s,  48.1 KiB/s (394.0 kbit/s)
   2 KiB blocks:   57.8 IO/s, 115.6 KiB/s (947.2 kbit/s)
   4 KiB blocks:   37.7 IO/s, 150.6 KiB/s (  1.2 Mbit/s)
   8 KiB blocks:   54.4 IO/s, 435.1 KiB/s (  3.6 Mbit/s)
  16 KiB blocks:   48.1 IO/s, 768.8 KiB/s (  6.3 Mbit/s)
  32 KiB blocks:   40.6 IO/s,   1.3 MiB/s ( 10.6 Mbit/s)
  64 KiB blocks:   44.5 IO/s,   2.8 MiB/s ( 23.3 Mbit/s)

Conclusion of reading test

MD RAID1 of two HDD gives you nearly twice as big perfomance of each individual disc. When you combine SSD and HDD, then the resulting raid will have the same performance as single SSD. The additional HDD will give you redundancy, and will not help you in performance, but on the other hand it will not be bottleneck neither.

Write test

For write tests I used FIO.

Here are raw data:

HDD
]# ./fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/mnt/new/test.block --bs=4k --iodepth=64 --size=4G --readwrite=randwrite
test: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.0.9
Starting 1 process
test: Laying out IO file(s) (1 file(s) / 4096MB)
Jobs: 1 (f=1): [w] [100.0% done] [0K/923K /s] [0 /230  iops] [eta 00m:02s]
test: (groupid=0, jobs=1): err= 0: pid=21855: Thu Aug 27 06:55:32 2015
  write: io=4096.0MB, bw=306738 B/s, iops=74 , runt=14002034msec
  cpu          : usr=0.10%, sys=0.66%, ctx=873849, majf=0, minf=4
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=0/w=1048576/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=4096.0MB, aggrb=299KB/s, minb=299KB/s, maxb=299KB/s, mint=14002034msec, maxt=14002034msec

Disk stats (read/write):
  sda: ios=1459/1425151, merge=1013/1295320, ticks=13140546/1152434770, in_queue=1166246234, util=100.00%


SSD
# ./fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/tmp/a/test.block --bs=4k --iodepth=64 --size=4G --readwrite=randwrite
test: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.0.9
Starting 1 process
test: Laying out IO file(s) (1 file(s) / 4096MB)
Jobs: 1 (f=1): [w] [100.0% done] [0K/71460K /s] [0 /17.9K iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=25103: Thu Aug 27 09:41:47 2015
  write: io=4096.0MB, bw=68711KB/s, iops=17177 , runt= 61043msec
  cpu          : usr=8.94%, sys=88.57%, ctx=5348, majf=0, minf=4
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=0/w=1048576/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=4096.0MB, aggrb=68710KB/s, minb=68710KB/s, maxb=68710KB/s, mint=61043msec, maxt=61043msec

Disk stats (read/write):
  sdb: ios=0/1047843, merge=0/35459, ticks=0/135364, in_queue=133722, util=97.71%

So for HDD I got iops=74 and for SSD iops=17177. Which is again huge difference. Now I run the test suite on MD RAID1, which I created in fist part of this blogpost. Raw data:

# ./fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/tmp/b/test.block --bs=4k --iodepth=64 --size=4G --readwrite=randwrite
test: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.0.9
Starting 1 process
Jobs: 1 (f=1): [w] [99.9% done] [0K/12859K /s] [0 /3214  iops] [eta 00m:06s]
test: (groupid=0, jobs=1): err= 0: pid=25535: Thu Aug 27 11:20:56 2015
  write: io=4096.0MB, bw=858435 B/s, iops=209 , runt=5003250msec
  cpu          : usr=0.12%, sys=1.42%, ctx=158288, majf=0, minf=4
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=0/w=1048576/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=4096.0MB, aggrb=838KB/s, minb=838KB/s, maxb=838KB/s, mint=5003250msec, maxt=5003250msec

Disk stats (read/write):
    md0: ios=14/1158475, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=7/1105716, aggrmerge=0/54041, aggrticks=10/210009015, aggrin_queue=210007845, aggrutil=99.28%
  sdb: ios=3/1061184, merge=0/98573, ticks=1/225035, in_queue=222790, util=1.47%
  loop0: ios=11/1150248, merge=0/9509, ticks=19/419792995, in_queue=419792900, util=99.28%

The result for RAID1 is iops=209. This is close to HDD performance (74 iops) .

Conclusion for writing

Performance in writing sucks. Still 3 times better then just HDD alone, but still order of magnitude slower than SSD alone.

Conclusion

The result is definitelly not black and white. If I replace one HDD in RAID1 with SSD, then I will get between 3 and 100 times better performance in reading. If I replace the second HDD with SDD then I will get additional 2 times increase of performance. So here replacing one disk is huge benefit. I will keep rendunance and the boost of performance is huge. For the writes the boost is "only" three times bigger. So it really matter what your usage is. If you write a lot then it can make sense to replace both disk with SSD disks. This is not my case, I usually just read a lot and write only few data. Therefore I will replace one of my disks in array with SSD now. And the second sometime later.


Posted by Miroslav Suchý | Permanent link
Comments

2015-06-26 22:32:35

Stavba domu s odstupem

Přišel mi tento dotaz:

Dobrý den pane Suchý,
dostal jsem se na internetu k vašemu blogu a článku Stavíme s Haas Fertigbau. musím říct, že to bylo velice poučné a inspirativní čtení, jelikož právě taky zvažujeme dřevostavbu a možno právě od Haase. chtěl bych vás tímto poprosit jestli by jste mi aspoň stručně nenapsal, jak jste s odstupem času spokojeni, jak s kvalitou provedení od Haase, tak s dřevostavbou obecně, mám na mysli zejména ty klasiky, jako hlučnost, slabá tepelná akumulace atd. , případně kdyby jste stavěl znovu, co by jste udělal jinak.

Není první - a nebude asi poslední. Tak ho zkusím shrnout tady na blogu. Jen pro úplnost shrnu, že je to více než 4 roky co jsme se nastěhovali.

Jak jsme spokojeni s dřevostabou? Já jsem spokojen moc. Vlaďka by sice raději měla nějaký slaměný dům s hliněnou omítkou. Ale to je na mě už moc. Já bych šel do dřevostavby znovu.

Hlučnost - tohle mi přijde jako mýtus. Rozhodně pokud jsou podlahy z betonu. Ano pokud děti nahoře v patře skočí z patrové postele dolů, tak to v kuchyni, která je hned po nimi, slyším. Pokud jsou otevřené dveře, tak v ložnici slyším co se děje v obyváku - ale to protože jsou hned naproti sobě. Jakmile dveře zavřu nebo je tam nějaká příčka, tak nic neslyším. Teda pokud děti zrovna nezkouší překonat svůj rekord, který drží na -110 dB.

Tepelná akumulace - ano, dřevostaba nemá tepelnou akumulaci. Klasický argument je "jak přestaneš topit, tak to rychle vychladne". To si lidé pletou akumulaci s izolací. Dřevostavba má nízkou akumulaci a vysokou izolaci. Takže pokud přestanu topit, tak dům tu teplotu v pohodě udrží ještě dva dny. Ano když otevřu venkovní dveře dokořán na půl hodiny tak teplo uteče, ale to v cihlovém domě taky. Ale naopak, pokud se vrátíme z dovolené a v domě je vypnuté topení (resp. jenom temperuje na 15°), tak po zapnutí topení je dům vytopen do pár hodin. Pokud si pomůžu i kamnama tak do 20 minut. U cihlového domu toho nikdy nedocílíte právě kvuli jeho akumulaci. Protože akumuleje nejenom teplo ale i chlad. Ale i v našem domě máme prvek, který akumuluje - podlahu. Ta je z betonu. Což je dobré kvuli te hlučnosti, ale na pytel kvuli té akumulaci. Pokud se v zimě vrátíme z dovolené tak v celém domě je velmi brzo teplo. Až na tu podlahu. Ta ještě dlouho zůstává studená.

Rekuperace - To je asi nejlepší věc, pro kterou jsem se rozhodli. Ten drobný průvan není vůbec cítit. Zato čerstvý vzduch ano. V zimě si připadám jako ve vyhřátém letním kině - na vzduchu a přitom v teple. Příjemný vedlejší efekt je že pokud se něco rozlije na zem, tak ty zbytky vody po utření uschnou výrazně rychleji než v jiných domech. Zemní registr mi vůbec nechybí. Resp. tak 4 dny v roce ano. Ale za ty prachy si raději v tropických dnech pustím větrák. Rekuperace obvykle jede na 50m3 za hodinu a to žere cca 30W. Co mě na rekuperaci štve je ten ovládací panel. Každý den v týdnu se musí nastavovat zvlášt a nastevní je poměrně zdlouhavé (furt kroutit tlačítkem doleva a doprava). No a když vypadne elektřina, tak to můžete nastavovat znovu. Což se u nás na vesnici děje tak jednou za čtvrtletí. Opruz.

Kvalita provedení Haasu - až na ten renonc s vodou (který Haas bez keců opravil) nebyl se stavbou dosud žádný problém. Všechno drží. Rohy jsou pravé. Nic se nemuselo předělávat. Mám akorát tři výhrady. 1) živí mě počítače, takže jsem chtěl skoro do každé místnosti natáhnout minimálně jeden ethernetový kabel a chtěl jsem Cat6. Kabely jsou sice Cat6, ale sockety tam daly Cat5e. Navíc dvě koncovky jsou špatně nacvaknuté - u jedné je to nepužitý vodič a u druhé - v pracovně - mám více socketů - takže jsem to zatím neřešil (a přišel jsem na to samozřejmě po záruce). Navíc kabely jsem chtěl vyvést na půdě (mám tam malý rack se switchem). Kabely tam jsou sice vyvedené, ale i když jsem rack postavil přesně doprostřed mezi vývody tak dva kabely tam nedosáhnou a budu je muset jednou nastavit (zatím je nevyužívám). 2) Na záchodě a v koupelně na některých místech trochu poklesla podlaha (necelý 1 mm), takže bude potřeba předělat spáru mezi kachličkami. 3) Po naší akci s dřevěnými schody, kterou jsem zmiňoval v přechozím zápisu, museli Haasovci říznout beton v patře a po uložení schodů dobetonovali navazující kousek (pás asi 30 cm). Občas když na něj došlápnu a nestojím jinde tak jde cítit, že se trochu hne. Je prostě poznat že ta podlaha není z jednoho kusu betonu. Ale pochybuji že někdo jiný než já si toho všimnul.

Co bychom udělali jinak

  • Telefonicu a kabelovku bych řešil dříve. Už u základů. Aby se kabely protáhli dříve než se postaví barák. Některé věci by to zjednodušilo.
  • A zvonek bych nechal dělat Haasovce. Zbytečně jsem musel dodatečně odkrývat kus stěny v předsíni (20*10 cm). A doteď jsem se nedokopal to zakrýt (netřeba mi to každýho půl roku připomínat).
  • Tu datovou kabeláž jsem si měl důkladněji převzít - ale fakt toho bylo hodně.
  • Elektrických zásuvek opravdu mohlo být více.
  • Ovládání světel bych dneska řešil elektronicky. Tj. vypínaš přímo neovládá světlo, ale je vyveden na datovou sběrnici a programovatelný čip pak určí co se zapne/vypne. Takže třeba světlo v předsíni může zhasínat celý dům. Schodišťák se může udělat čtyřcestný. A kdykoliv se to může předělat - softwarově. Ano měl bych u nás jednoho kandidáta, kterého bych u nás předělal. Ale to by se muselo lízt do omítky a předělávat dráty, takže nic.
  • Krbová kamna bych napojil na topný okruh. Kamna jsem měl primárně jako záložní zdroj tepla, když by nejela elektřina několik dní (což se tuhle zimu opravdu stalo) a bylo mi řečeno že pokud by byly napojeny na topný okruh, tak při nefungující elektříně bych v nich nemohl vůbec topit. Tak jsem od tepelného výměníku ustoupil. Později mi jiný člověk říkal že to jde. Že se prostě akorát ten topný okruh uzavře. No nic. Teď už kvuli tomu betony v podlaze rozbíjet nebudu.
  • No a samozřejmě bidetovou spršku bych napojil na teplou vodu. Ha ha.
  • Se založením zahrady jsme měli taky začít dřív. Stromy jsme měli zasadit hned jak se dělala základovka.
  • Udělal bych přípravu na solární panely. Když jsme stavěli tak se pro domácnost tak moc nevyplatili. To se teď mění. A počítám že do pár let je na střechu dáme hned vedle tech kolektorů.
  • Udělal bych vývod teplé vody ven. Na omýtku. To mě Haas nabízel, že vetšina domů si nechá vyvést studenou vodu na kohout ven. Řikal jsem "Na co, když na zahradě mám studnu a tam je kohout - Pravda." A opravdu studenou vodu bych nevyužil. Ale využil bych teplou. V létě nám vodu zdarma ohřejí kolektory a máme 250 litrů velmi horké vody. Ovšem pokud chci dětem napustit nafukovací bazének teplou vodou, tak ji musím nosit v kýblech. Nebo ji nechat ohřát sluníčkem, což v tom bazénku trvá více jak den a to už abych tu vodu měnil. Venkovní kohout na teplou vodu by se hodil.
  • Keramické tašky - já jsem zvolil betonové tašky. Jsou super. Za celou tu dobu praskla jenom jedna a jinak nic. Ale betonem moc neprojde wifi signál. Vlastně jakýkoliv signál. A jelikož mám AP na půdě, tak wifi signál je jenom pod ním (tj. v baráku) a na zahradě už ne, protože neprojde přes tašky. Řeším to repeaterem v jednom pokoji, ale je to zbytečný bazmek navíc. Keramikou prostoupí signál lépe.

Co jsem rád že jsme udělali

  • Pochozí půda - je tam hafo odkládacího prostoru. Pokud nemáte sklep, tak byste měli určitě chtít pochozí půdu.
  • Kumbál za garáží na zahradní věci a na kola.
  • Rekuperace - už se opakuji, ale je to fakt super.
  • Kachlová kamna - v zimě je to lepší než televize. Navíc ty kachle hezky akumulují, takže když večer v zimě zatopím, tak ráno ještě krásně hřejí.
  • Stupáky u komína - jak jsem zjistil tak to vůbec není obvyklé. A dodá to člověku mnohem větší jistotu.
  • Solární ohřev vody - v březnu se vypne kotel a v listopadu zase naskočí. To je 7 měsíců kdy kotel vůbec nesepne a teplá voda je téměř zadarmo. V zimě to navíc velmi slušně předehřívá vodu.
  • Studna - stojí sice dost, ale při kropení zahrady ušetří cca 10 tis. ročně.

Posted by Miroslav Suchý | Permanent link
Comments

2015-06-09 10:45:48

[SOLVED] Thunderbird freeze for a moment

I have for long time a trouble with Thunderbird. Very often when I changed view to another folder, then Thunderbird freeze for a moment. Sometimes just few seconds. Sometimes nearly for one minute. This was really PITA. And I even considered other MTA, but none was good enough for me. Therefore everytime I was really pissed by this bug I gave $50 as bounty for this bug.

I tried a lot of suggestions (deleting some emails, disabling extension, repair the folders...) and yesterday I found the correct solution (provided by Wayne Mery). So if you experience the same issue, the solution is: Preferences -> Advanced -> Config Editor and set option mail.db.max_open to 1000 - it should be definitelly higher than number of your folders.

This is example of power of Open Source - when you are unable to fix the issue yourself, then there is always somebody who can do that.


Posted by Miroslav Suchý | Permanent link
Comments

2015-05-28 15:15:09

Increase Mock performance - build packages in memory

In Copr we use Mock as underlying tool for building packages. After recent changes in Copr I discovered that Mock is quite slow. In fact the whole VM was quite slow. I quickly discovered that the issue is disk read/write bandwidth.

Copr spin up a new VM for every task. Right now we have more that 20 VM running in parallel. That is approximately 4-5 VM per one hypervisor. And building package is mostly disk intensive task. Those days when you have to compile everything are gone. Usually it is installing build requirements, unpacking tar file, moving packages to build roots, creating rpm package itself... I discovered that Mock can easily generate disk bandwidth more than 20 MB/s. Times five VM and you have 100 MB/s which too much for the RAID disks in a Compute node.

Our VM are created with 2 VCPU, 50 GB root disk and 5 GB RAM. The root disk is technically created on Compute node in /var/lib/nova/instances as QCOW2 image.

I realized that Mock have TmpFS plugin and we could build package in memory. Our OpenStack instance is quite beefy and have 690 GB RAM in total. However if I want to keep 50 GB for package maintainer, that would give space just for 13 machines. But then I realized that TmpFS can be larger than available memory. When you store there more than is available, it will be just swapped to swap disk. So I can keep 5 GB RAM, just have big big swap disk.

Swap disks are just ephemeral storage, which are treated similar as RootFS. They are stored in /var/lib/nova/instances as QCOW2 instances, but OpenStack will automatically format and mount them for you. So when I create VM with 20 GB root disk, 5 GB RAM and 30 GB swap disk, enable TmpFS plugin, then I am consuming exactly the same resources as previously. However the build task will be done in RAM and off-load the disk. Lets do the some tests with this setup.

Building of mock.src.rpm takes 3 minutes and 2 seconds. When I enable TmpFS it takes 28 seconds. And swap was not used at all. This task was completely done in a memory. Now something more heavy - kernel.src.rpm. It takes 231 minutes and 46 seconds in our VM to build kernel. And when I enable TmpFS it take just 161 minutes and 49 seconds to finish. At some point the TmpFS of mock's chroot grew to 15 GB so some data was writen to swap (I can imagine /usr/share/doc files landed there) however most tasks were still done in memory.

For small packages the improvement is huge (reduced to 16 % of original time), less for huge packages but still significant (reduced to 70 % of original time).

Because we have plenty of space in /var/lib/nova mount point in our Compute nodes (3TB on each node) I decided to use 5 GB RAM, 20 GB RootFS and 50 GB swap. Therefore you will have even more space if needed and the build will be still faster. I already prepared instance images and next week I will put this setup in Copr production.

For the record this is the settings I am using (in /etc/mock/site-defaults.cfg):

config_opts['plugin_conf']['tmpfs_enable'] = True
config_opts['plugin_conf']['tmpfs_opts'] = {}
config_opts['plugin_conf']['tmpfs_opts']['required_ram_mb'] = 1024
config_opts['plugin_conf']['tmpfs_opts']['max_fs_size'] = '50g'
config_opts['plugin_conf']['tmpfs_opts']['mode'] = '0755'
config_opts['plugin_conf']['tmpfs_opts']['keep_mounted'] = False

Posted by Miroslav Suchý | Permanent link
Comments