Linux 3.9 (diskuse)

[hermelin]

Slava za SSD cache - konecne se dohnal velky renonc.

[Xerces]

No nevím, nikdy jsem necítil potřebu to použít. Buďto se mi vše vešlo na SSD a nebo jsem se holt smířil s pomalejšími IO.

[lertimir]

Před časem jsem z SSD cache byl nadšený, byla na nějakém motherboardu s SLC SSD od intelu, ale pak po havarii systému dalo dost práce restaurovat informace. Takže když to funguje je to skvělé, ale je třeba aby při havárii nenapáchal více škody než užitku. Více se mi libí rozšiřující podpora btrfs.

[Tom K]

Nejásej předčasně. Prozatím je stav velmi experimentální a po několika pokusech to u mě skončilo dost něpěkně poničeným filesystémem. bcache je o něco lepší. S SSD které je o kousek větší než běžný working-set se to znatelně urychlilo, ale čas od času si to taky postavilo hlavu.

[hermelin]

Ja jsem na to koukal spis z pohledu ze premyslim o novem notebooku. A dost me zarazilo ze redmontsky system (diky intelu) to bez problemu zvlada a u linuxu je to velka neznama. Jedine co bylo jakztakz pouzitelne bylo bcache (patchovani jadra). Takze spis z pohledu ze doslo k pokryti diry kdy na trhu se stava bezny notebook se ssd cache 16-32GB. Jinak u me to asi stejne skonci takze ze bude jenom SSD 256GB - na praci mi to bohate staci

[lertimir]

Právě, že redmontský systém to nezvládá. už jsem psal výše, že jsem řešil pád widlí se použitou intelí SMARTCache. Ve windowsech to nešlo nijak spravit. V linuxu jsem byl vidět HDD jako RAID disk (pomocí mdadm jsem vytvořil degradované RAID 1 pole a data přečetl, pak vše zrušil a už pracoval bez cache.) Domnívám se (ale je to jen domněnka), že ta intelí Cache vytvoří něco jako falešný RAID 1 s tím, že když se čte, tak jako první dodá data SSD, protože nemá seek a když se píše tak se zapíše do SSD. A mají odloženou (zpožděnou) synchronizaci, kterou si vždy cache uvolní, aby mohli chytnout zápis. Problém je, že když se to zhroutí. (I když je možné, že majitel tam udělal i nějakou destruktnivní konfigurační akci po zhroucení po níž už to nešlo spravit.)

[David Watzke]

Hurá! Konečně zas jednou verze, která mi udělala opravdu radost - socket flagem SO_REUSEPORT.

[Michal]

connections that come in on this port will be evenly distributed across the sockets by the kernel [...] can help avoid bottlenecks that appear in certain situations when only one thread accepts new connections and then distributes them across other threads

Můžu se zeptat co provozuješ za nasazení kde ti tohle pomůže? Chápu to v případě Googlu a dalších obrovských webových, mailových nebo DNS farem, ale jak můžu narazit na tenhle bottleneck v "normálním" provozu?

[citanus]

+1 nemuzu konkretne rict, ale taky mam vyuziti.

[David Watzke]

To je vcelku jednoduchý. Představ si, že máš třeba UDP server, který obsluhuje klienty v jedné smyčce událostí (v jednom procesu a v něm v jednom vlákně). Doprogramovat do něj multithreading by bylo poměrně pracné. S touto funkcí to jednak není potřeba a jádro to samo spravedlivě rozdělí mezi jednotlivé procesy. Takže využiješ všechna jádra procesoru i s takto napsaným serverem To mi přijde naprosto skvělý.

[Michal Kubeček]

Tedy aspoň do chvíle, kdy jednotlivé instance nepotřebují sdílet data. Ale pak zase není problém přepsat ho na multithreading (pokud není napsaný opravdu hodně prasácky).

[David Watzke]

Souhlas, že to není problém, ale proč to dělat, když to vyřeší jádro za mě?

[Tomáš Bžatek]

Abys nemusel mit requirement na novem jadru

[David Watzke]

Stačí tam dát ifdef a místo requirementu to bude jen motivace mít aktuální jádro

[pavlix]

S myšlenkou ifdefu na verzi jádra jsem si hrál kvůli NetworkManageru. A něco mi pořád říká, že to vůbec není dobrý nápad.

[David Watzke]

V tomhle případě to podle mě není tak hrozný. V ifdefu je jediný řádek kódu a je to naprosto ospravedlnitelný.

[pavlix]

Počet řádků je irelevantní. Spíš jde o to, že je to zranitelné vůči provozu na jiné verzi jádra.

[Bubak]

To by mohlo byt dost hnusny, kdyz si spustim system s jinym jadrem. To uz bych to radsi testnul za behu, jestli ta moznost je, a podle toho socket otviral.

[Michal Kubeček]

IMHO by bylo vhodnější orientovat se podle návratové hodnoty toho setsockopt()

[David Watzke]

Ale konstanta SO_REUSEPORT nebude se starším jádrem definovaná, ne?

[Michal Kubeček]

To nebude, ale v distribuci se obvykle nepoužívají hlavičky od jádra, ale od glibc. Takže by bylo dobré zkontrolovat oboje - jak existenci SO_REUSEPORT, tak (pokud to první prjde) úspěšnost toho syscallu. Co chci říct, je, že by se mělo kontrolovat, zda lze socket option nastavit, ne jaká je verze jádra.

[David Watzke]

Ano, s tím rozhodně souhlasím, ale právě kvůli té možnosti nedefinované konstanty bych ten ifdef nevypouštěl. Ale je lepší ho udělat na SO_REUSEPORT než na verzi jádra -- v tom máš pravdu. Dík za připomínku.

[smazáno]

Take by mohlo byt zajimave pouzit na sdileni dat mezi instancemi treba ZeroMQ.

[luky]

To je vcelku jednoduchý. Představ si, že máš třeba UDP server, který obsluhuje klienty v jedné smyčce událostí (v jednom procesu a v něm v jednom vlákně). Doprogramovat do něj multithreading by bylo poměrně pracné. S touto funkcí to jednak není potřeba a jádro to samo spravedlivě rozdělí mezi jednotlivé procesy. Takže využiješ všechna jádra procesoru i s takto napsaným serverem To mi přijde naprosto skvělý.

Zrovna v tomdle pripade uplne staci REUSEADDR.

[David Watzke]

To tedy nevím, já měl vždycky za to, že SO_REUSEADDR ti neumožní bindnout víc procesů na jednu adresu+port, ale že to je vhodný použít když chceš umožnit okamžitý respawn + bind na stejnou adresu+port např. po pádu serveru.

Jak by to tedy fungovalo?

[luky]

To tedy nevím, já měl vždycky za to, že SO_REUSEADDR ti neumožní bindnout víc procesů na jednu adresu+port

Na Linuxu jo, na BSD ne.

[David Watzke]

Ale co si tak pamatuju z jaderných novin, tak o tom SO_REUSEPORT se mluvilo tak, že se jádro navíc postará o spravedlivé rozložení zátěže a o to, aby klient komunikoval vždy s tím stejným serverem, dokud ta instance běží...

[luky]

Spravedlive rozlozeni zateze je dulezite pro TCP spojeni, protoze pak mate v kazdem procesu priblizne stejny pocet spojeni. U datagramovych spojeni je vam vetsinou jedno, ze jeden proces zpracuje vic pozadavku, protoze tam nejsou zadna spojeni, ktera by se v tom procesu drzela.

[little.owl]

Here.

[luky]

Jenze takhle se to na linuxu nechova. Zkuste si to.

[little.owl]

Nemam ted kernel 3.9; tam spise pujde o to jak se to chova, pokud je TCP socket v TIME_WAIT stavu.

[luky]

Hlavni rozdil je v tom, ze v Linuxu muzete nabindovat stejnou adresu/port nekolikrat uz velmi dlouho s REUSEADDR. Na BSD je k tomu potreba REUSEPORT. Zkuste si to na stavajicim kernelu.

[luky]

Todle jsem Vam vygooglil: http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t

[little.owl]

OK, jak koukam jsem mel falesnou predstavu, ze SO_REUSEADDR je tam jen proto, ze se mohu pripojit k adrese:portu, ktery je v TIME_WAIT, bez nutnosti si hrat s Linger Time, tam kde mam jistotu, ze nemohu ztratit data; pripadne pro vice UDP socketu pripojenych ke stejne adrese:portu.