Byla vydána nová major verze 28.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.
Český telekomunikační úřad zveřejnil Výroční zprávu za rok 2024 (pdf), kde shrnuje své aktivity v loňském roce a přináší i základní popis situace na trhu. Celkový objem přenesených mobilních dat za rok 2024 dosáhl dle odhadu hodnoty přibližně 1,73 tis. PB a jeho meziroční nárůst činí zhruba 30 %. Průměrná měsíční spotřeba dat na datovou SIM kartu odhadem dosáhla 12,5 GB – v předchozím roce šlo o 9,8 GB.
Z novinek představených na Google I/O 2025: Přehledy od AI (AI Overviews) se rozšiřují do dalších zemí. Užitečné, syntetizované přehledy od generativní AI jsou nově k dispozici i českým uživatelům Vyhledávače.
Šestice firem označovaných jako „MAMAAN“ – tedy Meta (Facebook, Instagram), Alphabet (Google), Microsoft, Apple, Amazon a Netflix – je zodpovědná za více než padesát procent světového internetového provozu. Dalšími velkými hráči jsou TikTok a Disney+. Společně tak zásadně určují podobu digitálního prostředí, spotřebitelského chování i budoucích trendů v oblasti technologií. I přesto, že se podíl těchto gigantů od roku 2023 o něco snížil, jejich dominantní postavení zvyšuje volání po regulaci.
Evropská komise (EK) navrhuje zavést plošný poplatek ve výši dvou eur (zhruba 50 Kč) za každý malý balík vstupující do Evropské unie. Poplatek se má týkat balíků v hodnotě do 150 eur (zhruba 3700 Kč), které v EU nepodléhají clu. V loňském roce bylo do EU doručeno kolem 4,6 miliardy takovýchto balíků. Poplatek má krýt náklady na kontroly rostoucího počtu zásilek levného zboží, které pochází především z Číny.
Dnes a zítra probíhá vývojářská konference Google I/O 2025. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).
V Bostonu probíhá konference Red Hat Summit 2025. Vybrané přednášky lze sledovat na YouTube. Dění lze sledovat na síti 𝕏 (#RHSummit).
Společnost Red Hat oficiálně oznámila vydání Red Hat Enterprise Linuxu 10. Vedle nových vlastností přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.
Tuto sobotu 24. května se koná historicky první komunitní den projektu Home Assistant. Zváni jsou všichni příznivci, nadšenci a uživatelé tohoto projektu. Pro účast je potřebná registrace. Odkazy na akce v Praze a v Bratislavě.
Troy Hunt představil Have I Been Pwned 2.0, tj. nový vylepšený web služby, kde si uživatelé mohou zkontrolovat, zda se jejich hesla a osobní údaje neobjevily v únicích dat a případně se nechat na další úniky upozorňovat.
18.2.2015 23:35
Max | skóre: 72
| blog: Max_Devaine
Jen bych měl dotaz ohledně Keria Connect, proč jej provozuješ na windows serveru?Protože požadavkem bylo, aby v KOFF fungovalo SSO a nemuselo se explicitně zadávat heslo. A to Kerio na Linuxu neumí - anebo alespoň ještě na podzim neumělo a v changelogu jsem si změny nevšiml.
Mno, jinak u mně by takové uptime neprošly :-/Já mám konkrétně tady (děláme víc firem) v noci naštěstí celkem klid, dělají jen přes den a pokud jim v jednu v noci otočím server, nevšimnou si toho ani notebookáři. V tomhle případě k tomu přispělo, že byl víkend, svátek a navíc téměř všichni jsou outlookáři a KOFF stahuje jen nové nebo změněné zprávy. A ty čitelné byly, deduplikace se aplikuje na soubory, na které pár dní nikdo nesáhl. O to problematičtější byla obnova z backupu, musel jsem promíchat soubory z toho dne s tím, co jsem vytáhl z databáze. Viditelně ten server nejel "jen" asi od pěti večer do dvou do rána. A jak jsem psal: víkend mezi svátky. Pár lidí si toho všimlo, ale nedělalo jim problém pochopit, že jsme měli havárii a že na tom pracujem. Je fakt, že ve všední den nebo když mají víkendovou zakázku, to by mě asi sežrali... Ostatní virtuály, které tam běží jsou duplikované (doménový řadič, DNS/DHCP...) nebo se využívají jen ve všední den.
co jsem vytáhl z databáze.... pardon, ze zálohy, samozřejmě.
19.2.2015 13:01
Max | skóre: 72
| blog: Max_Devaine
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czlvcreate --type raid1'. Při náhodném přístupu mi LVM dával asi tak poloviční IOPS, což mi oproti MD přijde docela bída. Možná jsem dělal něco špatně.
Jádro 3.17, 2x WDC WD40EFRX v RAID1.
Mimochodem, zkoušeli jste někdo RAID co je přímo v LVM?Nikdy jsem neměl tu potřebu. Pokud si pamatuju, tak podpora RAID v DM se dodělávala až v době, když MD už existovalo a běžně se používalo - když si můžu vybrat, preferuju kód, který používá víc lidí (protože je lépe otestovaný)
Jak se zdá, nejsem sám.No, tam zrovna u dm-cache ukazuje docela dobré výsledky... ale možná to trochu vysvětluje ty moje
Když na filesystemu vypnul discard, tak mu šel výkon rapidně dolůCož to jasně, když jsou ty přístupy náhodné, tak se nedá moc čekat, že kód dm-cache dobře odhadne, co si má nechat a co ne. Vypnutý discard způsobil jenom to, že ta cache musela pracovat s backing device a projevilo se to.
No dává, ale jen do zaplnění cache určené pro zápis dat.Zase, s náhodnými přístupy, což úplně neodpovídá reálnému provozu, kde se přece jenom k některým datům přistupuje více než k jiným.
Troufám si tvrdit, že v běžném provozu se data hned po zápisu na disk mazat nebudou, takže je důležité, aby se cache byla schopna ve writeback režimu nezapsaných dat zbavit dřív, než bude požadavek na další zapisování. Bcache má v tomhle směru docela hezkou samoregulaci rychlosti vyprazdňování; pokud je u dm-cache, tak jsem ji nenašel.No, tady bych řekl, že už výkon s tím discardem nesouvisí. Pokud dobře chápu, tak jediné, o co mu šlo s tím vypnutým/zapnutým discard, je jaktože mají náhodné zápisy tak dobrý výkon. A závěr - protože se při formátování udělal discard, takže není potřeba při zápisu číst z backing device. Což jinak potřeba je - když se zapíší data menší než je velikost bloku v cache, musí se z backing device vytáhnout zbývající data, aby se do cache zapsal celý blok. A tak to v tom jeho testu bylo, bs=4k, nejmenší možná velikost chunksize je 32k (AFAIK) Naopak když se data nesmažou, tak by výkon měl být jenom lepší - když se je něco pokusí číst, tak jsou k dispozici. Na co jsme možná oba narazili, je fakt, že dm-cache se nesnaží fungovat jako cache pro všechno - v tom blogu je to dobře vysvětlené, že má zrychlovat přístup k místům, se kterými se intenzivně pracuje. Proto taky jeden zápis na nějaké místo na backing device nevyvolá zápis do cache, data jdou přímo na backing device a teprve když se na jedno místo zapisuje víckrát, dm-cache se rozhodne daný blok cachovat. Plus sekvenční zápisy úplně ignoruje. Nějaká štelovátka tam jsou. Teď zkouším, jak se u toho sql benchmarku projeví menší bloky pro cache. Zatím to vypadá, že menší blok = (v tomhle případě) větší výkon. Doběhně to až zítra, tak můžu zkusit vynutit, aby přes dm-cache šly všechny zápisy, co to udělá. I když je samozřejmě otázka, jestli v reálném provozu je takové nastavení lepší - přece jenom to sice urychlí zápisy, ale taky to agresivněji vytěsňuje data, což zpomaluje čtení. I když... čtení zas není takový problém, od toho jsou diskové cache v RAM...
Na co jsme možná oba narazili, je fakt, že dm-cache se nesnaží fungovat jako cache pro všechno - v tom blogu je to dobře vysvětlené, že má zrychlovat přístup k místům, se kterými se intenzivně pracuje. Proto taky jeden zápis na nějaké místo na backing device nevyvolá zápis do cache, data jdou přímo na backing device a teprve když se na jedno místo zapisuje víckrát, dm-cache se rozhodne daný blok cachovat. Plus sekvenční zápisy úplně ignoruje.Tak tohle by mě zajímalo - v jaké situaci může nastat stav, kdy se opakovaně mnohokrát zapisuje na stejné místo? Disky hodně vytěžují třeba databáze, ale např. u multigeneračních systémů (jako třeba Postgres nebo Firebird) se i při přepisu zapisuje na nové místo a původní se jen označí jako uvolněné. Což koneckonců bude nejspíš i případ jakékoli činnosti na COW filesystemech. Co jinak? Podle mě se tímhle přístupem musí dost zužovat pole využití, ne?
Disky hodně vytěžují třeba databáze, ale např. u multigeneračních systémů (jako třeba Postgres nebo Firebird) se i při přepisu zapisuje na nové místo a původní se jen označí jako uvolněné.Možná to nové místo není (z pohledu polohy na disku) úplně nové? Co mi běží ten benchmark, tak zrovna dělá insert into do innodb tabulky a poměr bloků zapsaných do cache a na disk je cca 10:1 (s write_promote_adjustment 2, tj. - jestli dobře chápu - do cache se ukládají bloky, kam se zapisovalo 2 a víckrát)
20.2.2015 08:23
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
se i při přepisu zapisuje na nové místo a původní se jen označí jako uvolněné
To není úplně celá pravda. PG může provést zápis na řádek, který byl uvolněn, aniž by mezitím musel provést vacuum. Takže v případě, že dělám update jednoho záznamu pořád dokola, tak ten update může přepisovat jen dva řádky v datovém souboru na disku a může se stát, že oba budu v jedné 8kiB stránce. Takže pro disk se budou měnit jen dva 4kiB sektory (+ samozřejmě transakční log).
Takže ssd cache to vůbec nemusí po každém zapisu commitovat až na hdd, ale jednou za čas tam stačí poslat ty dva 4kiB bloky (které se mezitím na tu cache poslaly nesčetně krát).
Což koneckonců bude nejspíš i případ jakékoli činnosti na COW filesystemech
Netudoval jsem nijak detailně vnitřnosti BTRFS, ale divil bych se, kdyby ten alokátor opravdu po každé změně na COW zvolil úplně jiný blok. Naopak bych čekal, že pokud může (pokud na ten starý blok nevede odkaz odjinud), tak bude stejně jako ta DB prohazovat nějaké dva.
Já si to předtím interpretoval tak, že blbne detekce sekvenčních zápisůTo mě napadlo taky, že se do toho motá - tak jsem zvedl sequential_threshold (počet spojitých I/O potřebných pro to, aby se přenos považoval za sekvenční) z původních 512 na 65536, což by se jen tak stát nemělo. Žádná změna.
Hlavně by mě zajímalo, jestli to je bug, nebo nějaká sofistikovaná vlastnost.Jo, to je nás víc, ale koho se zeptat... U device mapperu je to vždycky stejné - ať už se člověk pokusí využít cokoliv, začne si velice brzo připadat, že je to nějaká obskurní vlastnost, kterou na webu popisuje akorát Red Hat a jeden blogger s Ubuntu.
Ještě bych časem chtěl otestovat novější cache policy 'smq', kterou jádro 4.1.15-gentoo-r1, co mám na testovacím stroji, zatím neumí. Smq by měla být efektivnější, třeba se trošku zlepší i ten zápis. Takže až bude novější stabilní distribuční jádro...
/sys/block/bcacheX/bcache/writeback_percent.
Mám pocit, že u dm-cache taky nějaké takovéhle rozdělení fungovalo.
My jsme driv @vpsFree pouzivali Flashcache, ale oproti ZFS a jeho schopnostem pouzivat SSD (L2ARC, ZIL) to stejne moc k nicemu nebylo. On totiz nejvetsim zabijakem u nas byl random write, ktery Flashcache, bcache i dm-cache akorat odkladaji, tomu seekovani se stejne neda vyhnout. Oproti tomu se ZFS se na SSD odplivava jenom neco jako "zurnal" a vsechny ostatni write - diky CoW designu ZFS - jsou linearni asynchronni zapisy.
I kdyz pouziti Flashcache znatelne bylo, porad to nestacilo - obzvlast, kdyz nad tim jede nekolik (desitek) databazi, ktere syncuji jak o zivot.
Flashcache, bcache i dm-cache akorat odkladaji, tomu seekovani se stejne neda vyhnout.Tady by mě zajímalo, jak moc ty implementace cache umí sesbírat jednotlivé malé zápisy a dělat z nich větší. Tím by se seekování dost omezilo.
Tiskni
Sdílej:
