Portál AbcLinuxu, 2. května 2025 22:26
nazory prosteho klikaceNázor prostého čtenáře: textu chybí jakékoli členění do celků, zvýraznění nadpisů, odrážek a diakritika. Strašně špatně se to čte
Kdyby to bylo napsané trochu čitelněji a k jednotlivým distribucím (kterých by klidně mohlo být mnohem méně) bylo trochu víc postřehů, mohl by takový přehled mít docela dobrý smysl. Pro zkušeného uživatele je řada věcí natolik samozřejmá, že se nedokáže vžít do role začátečníka a představit si, jak instalátor působí na něj.
Bohužel i drtivá většina článků na téma "recenze distribuce D verze X.Y" vypadá tak, že se projde instalace (se screenshoty), spustí defaultní desktopové prostředí, udělá dalších pár screenshotů, napíšou verze pár vybraných balíčků a je vymalováno. Nevzpomínám si, jestli jsem vůbec někdy viděl recenzi distribuce napsanou třeba po půl roce (nebo aspoň měsíci) každodenního používání.
Bohužel i drtivá většina článků na téma "recenze distribuce D verze X.Y" vypadá tak, že se projde instalace (se screenshoty), spustí defaultní desktopové prostředí, udělá dalších pár screenshotů, napíšou verze pár vybraných balíčků a je vymalováno.Což do značné míry vyplývá z toho, že, zvláště z pohledu začíátečníka a BFU, se distribuce od sebe liší především instalátorem, základním grafickým prostředím a verzí programů.
mx mepis antix – rozchodil jsem, ale radeji bych bral debianMepis umrel, na jeho základoch vznikol antiX a MX je viac komunitná záležitosť založená na antiXe, kde prejde skoro všetko do upstreamu. Samotný antiX je Debian rovnaký aký kedy pred tým, bez vymožeností ako systemd a podobne, ale je moderný a drží krok s Debianom. Sám udržujem svoju odnož antiXu LegacyIce, pretože časom všetko prebublalo do upstreamu (až na maličkosti), ide už len o grafickú a ergonometrickú úpravu distra.
Zdravim
Tak to jste opravdu velky nadsenec. Videt ze mate spoustu volneho casu. Ja zustal u dister zalozenych na Debianu. Nemam uz cas ani sil poznavat dalsi i kdyz me laka zkusit i jina distra. A do virtualu no teda spis kontejneru LXC taky neco na Debianu. U LXC me nadchla rychlost operaci a ze vsechno funguje hned. Z virtualizace na desktopu vyuzivam dnes uz jen Virtualbox.
Nastesti. BSD zacina byt paradni alternativa na servery. Tim myslim na servery, ne hracky (a ne, Linux tam neni vhodny).O aké štúdie sa opieraš. Čo v Linuxe nejde naškálovať?
BSD systems, in particular FreeBSD, can have notably higher performance than Linux. But this is not across the board. In many cases, there is little or no difference in performance. In some cases, Linux may perform better than FreeBSD.Linux je škálovateľný masakrálne a strávil som s tým pár mesiacov testov, takže by sa dalo pochybovať, či by vôbec v nejakej úlohe BSD podal lepší výkon.
Nejde mi o porovnání Linuxu a FreeBSD, ale o to, že reagujete na tradiční flamebait člověka, který se sem chodí bavit tím, že v diskusi utrousí nějaké podobné "moudro" a když se někdo nachytá a zeptá se, zda to může něčím podložit, důležitě sdělí, že všechny zajímavé technologie v Linuxu jsou vlastně jen nepovedené pokusy o napodobeninu skvělých a nedostižných technologií Solarisu. Na dotaz, proč ho tedy Google, Facebook, SAP, banky, automobilky a další používají pro své hodně velké a hodně kritické systémy, nám pak vysvětlí, že je to jen a pouze kvůli ceně, rozhodně ne kvůli technickým měřítkům, protože tam Linux zoufale zaostává.
Tenhle scénář už se tu zopakoval tolikrát, že zbývá jen jediná rada: nekrmit.
Co ti povim, jsem z toho zoufaly. Ano, zatim jedeme na Linuxu. Ale co je dneska tak, zitra muze byt jinak, protoze se landscape kontejneru zmenil s politikou firmy, co ty kontejnery pro linux vyviji a to pro nas vubec ne k lepsimu. Dopadlo to tak, ze si budeme muset delat nejaky jaderny vyvoj - a kdyz jsme dosli do tohohle bodu, mame jeste rok na migraci na dalsi reseni a na platforme, kde nesmrdi CPU scheduler, memory alokator, performance monitoring a on-disk data management subsystem, se zacina dat provozovat nativne binarky pro Linux, tak to nema ten Linux u nas vubec jisty.
Ja nevim, co po mne mistr Kubecek chce, ale nevidel jsem, ze by s tim neco delal, let alone ze by vubec pochopil, o cem tocim. A jasne, ze si kopnu, protoze si musim delat srandu ze systemu, kde se radsi nez na funkcnost bude dupat na GPL modlu a budeme se bit do prsou, jak mame uzasny vyvojovy model, ale uz si neprizname, ze ma poradne mezery.
V realu se pobavme o Linuxove masine, kde si pustim upstreamovy kernel bez pridavku se "smradlavou" licenci, pobezi tam 100 kontejneru kazdy s prumernou Rss okolo 1 GB a cca 1k procesy, s nejruznejsim typem zateze. Dejme pristup do tech kontejneru 100 lidem a rekneme jim, ze muzou verit tomu jadru. Nainstalujme to na stroj s 2 sockety, 20 jadry s HT a 256 GB RAM per socket, tj. 512 GB RAM. Pouzijme 2 SSD disky a dejme tomu 16 rotacnich 2.5" SASu.
Takze. Jak nakonfigurujete storage pro tech 100 kontejneru? Ma tam byt treba, rekneme 30 MySQL instanci a zadna z nich se nebude flakat. Do toho kazdych par hodin 15 kontejneru dela divoky rsync pres 2 TB dat. Do toho bezi 5 instanci bittorrentu.
Otazka pro fajnsmekry: jaky maximalni uptime mi dovoli upstream kernel, pokud pouziju user namespace jako jedinou izolaci, protoze vic dostupneho neni? Ano, tim myslim potrebu rebootu kvuli update jadra. Kez by fungovalo CRIU na vsechny a ne jenom polovinu z tech 100 kontejneru.
Bonusova otazka: jak dlouho to vydrzi bezet, nez se to slozi? Nez se ta masina zakucka, ve smyslu prestane fungovat NFS, naroste latence na siti, zadusi se disky, nebo se objevi kswapd na 100% jadra a cely system se zaseka?
Neverím, fakt vôbec neverím, že by si nejaké FreeBSD zapol a vetko by šlo out of the box. Môžeš po dlhej práci na migrácií naraziť na ďaleko väčšie problémy a určite aj narazíš.Tak to mi vkladas do ust neco, co jsem ani nerekl.
One typical mechanism that triggers slab defragmentation on my systems is the daily run of updatedbOh parada. Takze tohle se resi v upstreamu - a nam tam takovych userspaces bezi klidne 120.
Fakt neverím tomu, že keby bolo viac ľudí ktorí si na to sťažujú, že sa to riešiť nebude.I want whatever drugs you are having!
Linuxu (a jinem open-source softu) jsou zavazne bugy 10+ letI v kernelu? Jaké :-O.
Možno mám väčší potenciál niekoho ukecať, alebo sa s niekym spriateliť, ale proste tá cesta funguje.
S vývojármi sa treba snažiť skontaktovať "osobne", proste hodenie problému do "bugzilly" sa nemusí nikto chytiť, pretože ho problém nezaujme.
U jádra to nefunguje téměř nikdy (aspoň v případě bugzilla.kernel.org
), to už má větší šanci na úspěch poslat dotaz na příslušný mailing list (a tím nemyslím (jen) LKML).
Kde jsi vzal, ze bych nekdy argumentoval cenou?
Po chvíli hledání se musím omluvit, tuhle konkrétní věc napsal někdo jiný. V tom případě se ale musím zeptat, jak byste v tom případě vysvětlil vy, že i když je Linux (podle vás) od základu navržen úplně špatně a pro enterprise nasazení se vůbec nehodí, stejně ho Google, Facebook, NYSE, LSE, prakticky všechny větší banky, většina větších automobilek a spousty dalších firem přesně pro takové účely používají a dokonce preferují.
Treba nejvetsi box v Red Hatu ma presne 1 aktivniho uzivatele a 1 proces se spoustou threadu.
Nerozumím, proč by tohle měl být argument. Za prvé, naše největší stroje jsou podstatně menší než největší stroje našich zákazníků. Vzhledem k tomu, že mám trochu představu, na čem někteří naši zákazníci SLES provozují, připadá mi téměř vyloučené, že by tomu u RH bylo jinak. Za druhé, pro konkrétní účel může být jeden uživatel a jeden proces se spoustou threadů optimální implementace, takže bez nějaké bližší informace, co ten stroj má dělat a proč je to implementované zrovna takhle, to vaše tvrzení nemá žádnou vypovídací hodnotu.
Vetsinou se konci na 128 GB RAM, protoze Linux dal neskaluje.
Takže když nám přišel bug report, že po upgradu ze 4 TB paměti na 6 TB (asi tak před dvěma lety, dnes jsou IIRC na osmi) jim konkrétní zátěž funguje pomaleji a mají problémy s kdumpem, bylo to celé od základu nesmysl, protože vy přeci víte, že Linux neškáluje už od 128 GB. A SAP asi taky prohlásil SLES za preferovanou platformu pro SAP HANA z čiré neznalosti.
mlit hovna
Úžasný "argument".
Kdyz ti rikam, ze linux jako system na uchozeni kontejneru jako time sharing operacni system dneska neobstoji
Za prvé: s touhle verzí jste přišel až teď. Původně to bylo (přesná citace)
Tim myslim na servery, ne hracky (a ne, Linux tam neni vhodny).
a teď najednou přijdete s tím, že to mělo znamenat jen jeden velmi specifický use case? Za druhé: i pro tyhle účely se Linux dnes běžně využívá - a i v daleko větším měřítku.
davas za priklad systemy, kde se provozuje jedna podelana aplikace, ktera pouziva vsechny dostupny moznosti, aby si ten hw naschedulovala/zmonopolizovala sama, pac se na linux pod sebou spolehnout nemuze
Ani tohle není ani zdaleka pravda, některé z aplikací takhle z praktických důvodů vypadají, ale to je spíš výjimka.
Ale Mistra Kubecka ja presvedcit nepotrebuju.
Ani já necítím potřebu vás o něčem přesvědčit. Jen konfrontuji vaše výkřiky s realitou pro případ, že by je snad někdo chtěl brát vážně.
Je smutné, že jste se odpovědi na jasně položenou otázku vyhnul osobním útokem, ale i tím koneckonců poskytujete hodnotnou informaci.
Není to tak, že bych byl proti tykání, jen mám ve zvyku v diskusích tykat jen těm lidem, které znám osobně a se kterými si tykám i v reálném světě.
Pivu se v principu nebráním, jenom praktická realizace bude trochu komplikovanější tím, že nebydlím v Praze a dojíždím autem (s tím, že v pozdně večerních hodinách by to jinak nešlo ani teoreticky). Ale nepřekonatelný problém to taky není.
NFS server pod linuxem jsi zkousel pouzivat? Jakoze, vazneji pouzivat? Treba, 1500+ exportu?
Osobně ne, ale vím, že někteří naši zákazníci ano.
Videl jsi nekdy system, kde kdyz zvedas pocet otevrenych fd jednomu userovi na stotisicinasobek defaultu, zdaleka nejsi ani prvni, ani desaty, co to tam dela? Videl jsi nekdy, co to dela s kernelem?
Opět ne osobně, ale i tady vím o lidech, kteří takové systémy (s Linuxem) provozují. Navíc si vzpomínám na diskusi, kde se člověk s mailem s doménou oracle.com
(přesněji řečeno: dva takoví) dožadoval změny chování (aby odpovídalo jeho interpretaci poněkud nejasné formulace v POSIX standardu), ale která by si v důsledku vynutila výrazné snížení výkonu právě v situacích, kdy má tabulka file descriptorů procesu desítky milionů položek.
Netroufám si kvalifikovaně posuzovat implementace scheduleru, memory managementu, VFS, page cache nebo filesystémů, protože to prostě nejsou oblasti, kterými se zabývám (a nevěřím, že existuje člověk, který by tomu všemu rozuměl dost na to, aby to kvalifikovaně posoudit uměl). Dělám core networking, jestli si chcete popovídat o něm, jsem vám k dispozici. Co ale vím s jistotou, je to, že existují velké firmy, které Linux používají právě pro virtualizační servery, pro kontejnery, pro cloud hosting. A při vší úctě k vpsfree, některé i v o dost větším měřítku. Takže si nutně musím položit otázku, jak je možné, že oni nenarážejí na ty neřešitelné problémy prakticky v každém subsystému linuxového jádra, o kterých píšete, a proč oni neupřednostní ty jiné systémy, které jsou pro ten use case ve všech ohledech o tolik lepší.
Nekde uprednostnili ;) Samsung kvuli tomu koupil cely Joyent, protoze se jim ten jejich SmartOS proste libil a sedi jim to na to, kolik jim to usetrilo racku. Da se to dohledat nekde v tom oznameni, kdyz je kupovali Problem toho ekosystemu je, ze je maly. Ale to neznamena, ze tam nejsou lepsi technologie - minimalne dokud nebudou predehnany necim jinym - a prave mne stve, ze smer je jinudy.
Je tam nahodou spousta veci, co neskalujou, na nekterych vecech se dela, ale nektere veci jsou proste prilis velky sousto - napr. ta defragmentace SLABu by byla potreba jak sul, ale nikdo si nechce vzit na triko to mergovani, i kdyz patchset uz se objevoval v nekolika revizich kdy uz v podstate nesmrdel nikomu.
Neschopnost hnout jakymkoliv smerem s pagecache taky zabiji vykon Linuxu na velkych boxech. Proto si velke aplikace radsi cachuji samy - ale aby to nekdo vyresil primo v Linuxu, to taky nic.
File deskriptory byl asi ten nejdementnejsi a nejvic obvious priklad - kdyz se vezme, ze se nad jednim jadrem udela 100x uplne jinak nastaveny a pouzivany user-space, vznikaji na nej proste tlaky ve smerech, odkud se s tim nepocitalo. Lepsi priklad je vyrabeni interfacu, prace s vecma v ramci net namespace; napr. ladovani iptables pravidel na sdilenym jadru je lahudka.
Bridge dokonce pri masivnim pridavani tapu nekdy ztraci packety..
Memory management je tuneny pro HPC+embedded use-cases, ne pro rich server preplneny cachemi na kazdem kroku. Je rozdil pristupovat k navrhu systemu, kde se budou spravovat absurdni pocty vsech resourcu a je neco uplne jineho, pak dat takove jadro na embedded system s 8 MB RAM. To proste nemuze dlouhodobe vychazet dobre na vsechny strany
I Seznam, Facebook a vsichni, o kterych nejak kousek vim, jak maji infru delanou, tem jadrum nedavaji pocoudit tolik. Na hosta daji 30 kontejneru a ty kontejnery jsou vsechny proste zatizene. A kde to tak neni, tam se to jadro dost tezce tuni, aby se dalo treba turbo rychle spawnovat novy kopie kontejneru, apod.
Muzou mit klidne pul tera ramky per box i vic, ale nepobezi tam typove nic moc, co by se mohlo proti sobe mlatit a nebude tam takovy overcommit, co mame na boxech my.
No, tak se uvidime nekdy na nejblizsi konfere, prinejhorsim, i kdyz bych radeji driv, protoze mne par lidi otravuje, ze by chteli delat kernel-related diplomky (nebo otravuju ja je, ze to chteji delat) ;)
File deskriptory byl asi ten nejdementnejsi a nejvic obvious priklad
Když ono je to všechno pořád hrozně mlhavé, bez konkrétních příkladů, co nefunguje dobře, takže je těžké se k tomu nějak vyjádřit. Ale když Eric Dumazet tvrdí, že 10M a víc file descriptorů na jeden listening proces je pro ně běžná záležitost, nemám důvod mu to nevěřit. A jsem si jistý, že kdyby s tím měl výkonový problém, něco by s tím udělal. (Ostatně, už nejméně jednou udělal.)
Lepsi priklad je vyrabeni interfacu, prace s vecma v ramci net namespace
Nějaký příklad? Někde se pořád najdou příklady toho, že se jednotlivé netns navzájem zbytečně blokují, ale obvykle je to spíš proto, že to zatím nikomu nevadilo natolik, aby si stěžoval. Nedávno jsem jeden takový příklad řešil - ale až na základě toho, že se někdo ozval. Při způsobu vývoje linuxového jádra holt nešlo vyhlásit: "Dejte si všichni půl roku pohov, my to zatím celé přepíšeme na netns."
napr. ladovani iptables pravidel na sdilenym jadru je lahudka
Tam jsem na nějaký globální zámek narazil, ale IIRC se to týkalo jen "compat" modu, tj. např. situace, kdy 32-bitový příkaz iptables běží na 64-bitovém jádru. Možná jsou tam i nějaké další, to z hlavy nevím. Ono je celé to rozhraní x_tables, umožňující jen výměnu celé sady pravidel, dost nešťastné, ale to byl koneckonců jeden z hlavních důvodů vzniku nftables.
Bridge dokonce pri masivnim pridavani tapu nekdy ztraci packety.
Tady si nejsem moc jistý, jak to chápat: jestli se během přidávání nového portu ztratí pakety, které by měl bridge forwardovat už existujícím, nebo jestli už to, že má bridge příliš mnoho (kolik?) portů může způsobit, že se začnou ztrácet pakety.
"Dejte si všichni půl roku pohov, my to zatím celé přepíšeme na netns."This. To jste vystih a z toho prameni nejvic bolesti. Jinde to prave kvuli nejakemu zasadnimu paradigm shiftu v pouzivani (jako nastup kontejnerizace je) klidne i dyl, nez toho pul roku, predelavaji. Ne, ze by se zastavil vyvoj jinde, ale holt je pak potreba zamergovat neco vetsiho, jak jinak chcete zasadneji preryt treba takovou hnilobu, jako je napriklad okolo pagecache?
jak byste v tom případě vysvětlil vy, že i když je Linux (podle vás) od základu navržen úplně špatně a pro enterprise nasazení se vůbec nehodí, stejně ho Google, Facebook, NYSE, LSE, prakticky všechny větší banky, většina větších automobilek a spousty dalších firem přesně pro takové účely používají a dokonce preferují.Protoze je levnejsi.
rikal jsem si ze to zbytecne vyprovokuje diehard javistyTak bych se neoznacil. Netajim se tim, ze mam Javu rad, ale muj pristup k ni je ryze pragmaticky. Tj. o ruznych bolestech Javy bych mohl sepsat poradne tlustou knihu, ale presto lepsi alternativy moc neznam. To neznamena, ze Java ma tak blizko k idealu, jako to spis vypovida neco nepekneho o vyvoji ostatnich jazyku, kdy lze casto videt znovuvynalezani kola, ale uz ne tak casto skutecny vyvoj ve vedeckem, nebo alespon pseudovedeckem, vyznamu.
pobavilo me jak predpokladas, ze muj problem s javou je strong typingPravda. To jsem tak nejak vychazel z jednoho z nejcastejsich argumentu.
optional typing ftw :)Souhlasim. Proto jsem se zacal zajimat o jazyk Groovy.
problem s javou je celkove zaseknuti v osumdesatkach (dobre, mozna zacatku devadesatek).To by bylo potreba dal rozvest. Osobne spis problemy v Jave vidim jinde. Namatkove bych zminil type erasure u generik, primitivni typy a autoboxing a prinejmensim sporne jsou rovnez checked vyjimky (ve stavajici podobe). C# je v techto 3 bodech dal a vice ci mene uspesne je resi, ale bohuzel (k moji znalosti) zatim neni tak vyspely ekosystem okolo nej, tj. zejmena podpora jinych platform nez MS Windows, konkurence na poli IDE apod.
Je to krasny priklad one setrvacnosti, dokonce vylozene extremni. Takto nas to ucili, takto to budeme delat, a budeme to ucit dal, jinak to nejde.Ona je totiz otazka, jak (co) delat jinak. Neni nutne neustale prichazet s novymi trendy a bourat stavajici principy, ackoliv to nic noveho neprinasi. Vyvoj obecne znamena, ze zachovam to, co se osvedcilo, a pokusim se napravit to, co se naopak neosvedcilo. To bohuzel vidim malo casto. Treba Python prinasi mnoho dobreho (yield, array slicing), ale pro zmenu v nem zcela chybi staticke typovani. Existuje sice PEP 484, ale ten se vztahuje jen na argumenty a navratove typy funkci a runtime validace lze delat jedine pomoci externi knihovny, ktera vyzaduje, aby byl kod dale anotovany. Pak jsou tu jazyky jako Scala (se kterou jsem se zatim jen velmi zbezne seznamil), ale jsou pro zmenu natolik slozite, ze kazdy tym bude muset sepisovat, udrzovat a dodrzovat striktni guidelines, jinak by v trochu vetsi code-base driv nebo pozdeji byl totalni gulas, kde by kazdy programator pouzival naprosto odlisny pristup k reseni problemu.
Protoze je levnejsi.Asi žiješ v nejak inom "Enterprise", cena je posledné čo sa rieši. Teda áno ona sa rieši v excelovskej tabuľke s parametrami vycucanými z prsta a zrovna ten MS to robí aj tak najlepšie, pretože sa vie z manažérmi vždy podeliť. Vo finále to je vždy drahšie. Nehovorím o ničom čo by som nezažil. Rozmýšľal som aj nad blogom, ale ako sa pozerám okolo, bola by to úplne zbytočne vynaložená energia a to už proste nerobím.
Ja jsem z toho rozcarovany, protoze jsem to zjistil vicemene az v ostrem provozu, kdy se za boha nemuzeme dostat pres 99.9% a nekdy s nekterymi stroji je uspech udrzet 99.8% dostupnost.Jestli ono to náhodou nemá souvislost s použitými technologiemi. Vezmeme Linux, dopatchneme do něj out-of-tree filesystém, do toho dopatchneme out-of-tree popelnicovou, pardon, kontejnerovou virtualizaci a voila, ono to nefunguje. Stěžujete si tady na Linux, ale argumentujete problémem, který se vyskytuje ve vaší upravené verzi.
S KVM/QEMU a nejakym velkym storage polem mimo se dosahnout da, ale zase vykon bude jindeJenom pro srovnání jsem si teď vytáhl z Nagiosu několik strojů - všechno 2 socket Xeon, 256GB RAM, z toho využito 100-150GB se zapnutým KSM, běží na tom Qemu z lokálních disků. Používá se lehce překonfigurované distribuční jádro z Jessie a dostupnost těch strojů za poslední rok je ve většině případů více než 99.99%. A jsou to plánované noční odstávky, ne výpadky přes den. Výkon? Stroj, který spadl přes den, žádný výkon nemá.
sdileni prostredku (co se tyce RAM minimalne) bude v podstate nemozne.25% redukce využité paměti je málo?
Protoze technologie v upstream kernelu se pouzit neda - kontejnery maji slabou izolaci a celkove dost dementni navrh, na ktery se odmitam spolejhat + v Linuxu chybi poradny storage subsystem.
25% redukce využité paměti je málo?Jo, dost malo. Vem si, ze my v tech 256GB mame 100 kontejneru, kazdy ma nastaveny 4 GB RAM strop, v ZFS ARC je okolo 60-100G a zbytek drzi kontejnery, kde nejaka mean hodnota toho, co zabira jeden kontejner v pameti, vychazi na 1 GB. Tim, ze se starame o cachovani cele node najednou, si takovyhle overcommit muzeme v pohode dovolit a nikdy nenarazime na OOM - maximalne na situaci, kdy ZFS musi odcouvat a uvolnit kus pameti. A v takovych situacich ma zrovna prave Linux problem.
Protoze technologie v upstream kernelu se pouzit neda - kontejnery maji slabou izolaci a celkove dost dementni navrh, na ktery se odmitam spolejhat + v Linuxu chybi poradny storage subsystemJo, souhlas, taky je nepoužívám. Ale pokud chci lepší kontejnery a lepší storage a do Linuxu si to dopatchuju z out-of-tree zdrojů, není chyba Linuxu, když to potom není stabilní. A rozhodně je nesmysl z toho a z chybějící podpory kontejnerů odvozovat, že Linux je systém pro hračky. Zejména s ohledem na reálná nasazení.
Tim, ze se starame o cachovani cele node najednou, si takovyhle overcommit muzeme v pohode dovolit a nikdy nenarazime na OOMTakže když si všech těch 100 kontejnerů nastaví innodb_buffer_pool_size v MySQL na 3GB, tak to ta mašina utáhne? Dost o tom pochybuju. Neříkám, že cache přes celý node je k ničemu, ale v nadšení tomu přisuzujete až moc zázračné vlastnosti.
maximalne na situaci, kdy ZFS musi odcouvat a uvolnit kus pameti. A v takovych situacich ma zrovna prave Linux problem.Linux nebo Linux+ZoL? Protože s Linuxem se mi ještě nestalo, že by uvolňování cache způsobilo pád jádra.
není chyba Linuxu, když to potom není stabilní.
To teda je, a krom toho v posledni dobe to neni jenom ZFS, ale je tu taky BTRFS a Ceph, oba dva zatezujou pametovej subsystem vic, nez se pocitalo. A do uzkych se muzes dostat i na mensich systemech s ext4, ani se clovek nemusi moc snazit. Resi se to v tech diskuzich na LKML znova a znova a nikdo nema koule prijit s nejakym radikalnejsim resenim, natoz ho zamergovat.
Linux je systém pro hračky. Zejména s ohledem na reálná nasazení.
Ja mam rad dramatickou nadsazku, jestli jste si tu este nevsimli
Linux je systém pro hračky. Zejména s ohledem na reálná nasazení.
No, kontejnery bezime uz od zacatku roku 2009 a kdyz uz se obtezuju s prezentovanim nejakych konkretnejsich cisel a ne jenom trolovanim (napr. ten 1 GB viz. vys), tak si je necucam z prstu. Kdyby ten pomer byl jinde, nez jak je, zaridili bychom se podle toho. Jenze naprosta vetsina lidi ma tu MySQL smutne v defaultu. Tady musim priznat, ze jdeme kousek proti sobe tim, ze nechavame ZFS cachovat, co se da - protoze spousta lidi si ani nikdy nevsimne, ze by MySQL meli nejak nastavit jinak, ze ten default je dost bida na maly systemecky... Pak se az divi, kdyz to presouvaji jinam/na svuj HW, co ze to najednou dre o disky
by uvolňování cache způsobilo pád jádra.
Pad jadra ne, to se opravdu nedeje. Ale ze se system zasekne v nekonecnym cyklu memory reclaimu, to se teda deje - a jak pisu, nemusis mit zrovna ZoL, ale tam je to nejvic evidentni.
No, kontejnery bezime uz od zacatku roku 2009 a kdyz uz se obtezuju s prezentovanim nejakych konkretnejsich cisel a ne jenom trolovanim (napr. ten 1 GB viz. vys), tak si je necucam z prstu.To samozřejmě netvrdím. A jo, je mi jasné, že kdyby to využití paměti vypadalo jinak, tak se podle toho jinak nadimenzují nebo zatíží servery. To důležité, co jsem chtěl ukázat, je, že ten overcommit si můžete dovolit díky reálným poměrům na tom serveru a ne díky cache přes celý stroj.
Pad jadra ne, to se opravdu nedeje. Ale ze se system zasekne v nekonecnym cyklu memory reclaimu, to se teda dejeJo, jasně, to jsem měl na mysli - a jak říkám, s "vanilla" (Debian) jádrem se s tím nepotkávám.
Manjaro – dokazal jsem nainstalovat, smutek ze neni AUR jen vlastni repo manjara kde je toho oproti AURu hodne malo, pry AUR se da manulane zapnout jak a kde ?$ yaourt -Ss balíček #najde balíček v AURu $ yaourt -S balíček # nainstaluje balík z AURu Případně: nainstaluj #pacman -S --needed base-devel stáhni si balíček (tarbal) na webu AUR archlinuxu rozbal balíček $ tar xvzf balicek.tar.gz presuň se do adresáře kde je balíček $makepkg -s (jako root to nejde) Po provedení #pacman -U /cesta/pkg.tar.xz (balíček tar.xz byl vytvořen příkazem $makepkg) A soubor je nainstalovaný. Pro odstranění #pacman -R nazev_baliku
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.