Společnost Meta otevírá svůj operační systém Meta Horizon OS pro headsety pro virtuální a rozšířenou realitu. Vedle Meta Quest se bude používat i v připravovaných headsetech od Asusu a Lenova.
Společnost Espressif (ESP8266, ESP32, …) získala většinový podíl ve společnosti M5Stack, čímž posiluje ekosystém AIoT.
Byla vydána nová stabilní verze 3.5 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). Přehled novinek také na YouTube. Nově lze využívat cloud (audio.com). Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
50 let operačního systému CP/M, článek na webu Computer History Museum věnovaný operačnímu systému CP/M. Gary Kildall z Digital Research jej vytvořil v roce 1974.
Byl zveřejněn program a spuštěna registrace na letošní konferenci Prague PostgreSQL Developer Day, která se koná 4. a 5. června. Na programu jsou 4 workshopy a 8 přednášek na různá témata o PostgreSQL, od konfigurace a zálohování po využití pro AI a vector search. Stejně jako v předchozích letech se konference koná v prostorách FIT ČVUT v Praze.
Po 48 letech Zilog končí s výrobou 8bitového mikroprocesoru Zilog Z80 (Z84C00 Z80). Mikroprocesor byl uveden na trh v červenci 1976. Poslední objednávky jsou přijímány do 14. června [pdf].
Ještě letos vyjde Kingdom Come: Deliverance II (YouTube), pokračování počítačové hry Kingdom Come: Deliverance (Wikipedie, ProtonDB Gold).
Thunderbird 128, příští major verze naplánovaná na červenec, přijde s nativní podporou Exchange napsanou v Rustu.
Byly vyhlášeny výsledky letošní volby vedoucího projektu Debian (DPL, Wikipedie). Novým vedoucím je Andreas Tille.
Po osmi měsících vývoje byla vydána nová verze 0.12.0 programovacího jazyka Zig (GitHub, Wikipedie). Přispělo 268 vývojářů. Přehled novinek v poznámkách k vydání.
Tento blog obsahuje nebezpečnou symboliku.
Při pokusu o změření výkonu PostgreSQL na různých konfiguracích raidu jsem nečekaně narazil na podivné chování PGSQL na různých FS.
Keci přijdou příště (až se mi podaří naměřit to pole), teď rychle k věci:HW: Intel Core 2 Duo 6320, 8 GB RAM, SATA II disky (sda: ST3320620AS, sdd: SAMSUNG HD103SJ).
OS: CentOS 5.4 64b, kernel 2.6.18-164.6.1
SW: PostgreSQL 8.1.18, e2fsprogs 1.39, xfsprogs 2.9.4
Měření probíhalo programem pgbench
Výsledky (pro pgbench -c 1 -t 10000), počet transakcí za sekundu:
sda[ext3]: 334 sdd[ext3]: 602 sdd[xfs]: 35
Nastavení PostgreSQL jsem záměrně ponechal původní z balíčku.
Rozdíly mezi disky sda a sdd odpovídají rozdílu v HW. Na stejném disku je ext3 17x výkonnější než na xfs.
Prosím o komentáře, co je (případně na chyby v měření samotném) špatně. Lidé postgresql na xfs normálně používají a na fórech se hádají o jednotky procent výkonu, nikoliv o řád. Co se týče souborů, na daném serveru je xfs +/- stejně rychlý jako ext3 (prosím neflamujte na téma FS) a je nasazen kvůli velikosti pole. Pomůže novější PostgreSQL?
Vyřešeno. Na vině pomalé PGSQL DB bylo nastavení XFS, konkrétně barriér. Takže výsledky, počet transakcí za sekundu:
disk [xfs nobarrier]: 943 disk [xfs barrier]: 34 raid-5 [xfs nobarrier]: 67
Na mdadm a lvm bariéry nelze zapnout. Na samostatném disku je xfs při vypnutých bariérách řádově stejně rychlý jako ext3, při zapnutých rychlost db rapidně klesá.
Tiskni Sdílej:
barriers
nad LVM a nad SW RAID (mdraid
)? Četl jsem testy, kde se ext3 nad LVM po několika výpadcích napájení úplně rozpadl, a to při nastavení data=ordered
. Doporučeným řešením je HW RAID + write chache se zálohovací baterií.
Projevovalo se to jen, když byla zapnutá drive write cache na SATA discích. To je obvykle jejich výchozí nastavení, a při vypnutí drive write cache dokonce výrobce negarantuje živostnost disku. Zajímavé je, že třeba HP ve svých serverech dodává SATA disky s vypnutou chache.
Myslel jsem si, že na klasický setup MD RAID1 + LVM + EXT3 se dá spolehnout i při výpadku napájení (rozbije se třeba otevřený soubor, ale FS bude v pořádku). Pokud je teď výchozí data=writeback, měl bych strach ze ztráty dat ještě větší.
Každopádně vypnutí cache na SATA disku způsobí obrovský propad výkonu - u mě asi na 1/4 při sekvenčním zápisu, při provozu právě Postgresu na disku s vypnutou cache vylezl IOWAIT až na 80% z jednoho jádra, po zapnutí cache je to tak 10%.
Nebylo při testování na tom disku LVM? Právě XFS nad LVM prý někdy vypínal diskovou write cache, protože hrozila ztráta dat.
Před časem jsem zápolil s XFS taky. Problém se projevoval tím, že v okamžiku vypnutí virtuálního stroje pod VMware Worstation se program "zasekl" na dobu trvající třeba i 40-50 sekund, během nichž intenzivně pracoval disk. Zjistil jsem, že příčinou je pomalost operace zapsání veškeré cache na disk (tj. to, co dělá příkaz sync
). Problém se projevoval na několika různých počítačích, systém byl vždy 64-bitový a výraznější to bylo na víceprocesorových (nebo spíš vícejádrových). Částečně pomohlo (proti vší logice) mountování s parametrem nobarrier
, tím se doba trvání snížila asi na polovinu. Nakonec jsem to vyřešil přechodem na JFS.
Netvrdím, že jste narazil na stejný problém, ale dokázal bych si představi, že by pomalost databáze ve specifických případech byla způsobována právě pomalostí synchronního zápisu. Ale jestli máte ještě ten volný disk, zkuste na něm i JFS, podle mne je tento filesystém v Linuxu opomíjen do značné míry neprávem.
Na mdadm a lvm bariéry nelze zapnout.U 2.6.33 na mdadm už jo. http://kernelnewbies.org/LinuxChanges#head-713e14251e05151b9d48bf91c344ca4ff07c526a