-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 04/02/2014 01:15 PM, Petr Tesařík wrote:
On Wed, 02 Apr 2014 12:18:16 +0200 Pavel Snajdr snajpa@snajpa.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 04/02/2014 12:15 PM, Ján Stanček wrote:
2014-04-02 12:01 GMT+02:00 Pavel Snajdr <snajpa@snajpa.net mailto:snajpa@snajpa.net>:
-----BEGIN PGP SIGNED MESSAGE----- Abych udelal misto na 256GB blbosti lokalne na kazdym nodu, musel bych vyrazne zmensit cast SSD, ktera se pouziva pro level 2 read caching (a to se hodne pozna v momentech, kdy je na tom stroji min ramky, nez je idealni).
Delani mista na rotacnich diskach je blbost, protoze by to rozhodilo tvar celyho zpoolu.
RE: 256GB, Hovorime tu stale o kdump? Nemyslim, ze je nutne dumpovat komplet obsah RAM. makedumpfile (ktory je predpokladam pouzity) vie odfiltrovat user-space/zero/free stranky (parameter -d), takze vo vysledku by ten vmcore mal byt podstatne mensi.
Kdybych mel pocit, ze staci dumpovat jenom neco, tak bych to zminil :) For various reasons aby ty kdumpy k necemu byly, musi tam bejt vsechno. Nikdy nevis, co presne se podela a kdyz uz budu jednou takovouhle vec zprovoznovat, tak to musi fungovat poradne a ne ze mi kdump ve vetsine pripadu bude slouzit akorat jako ted podivani se na konzoli - "hmmm hezky podle stack trace to pada asi tak tady nekde, mozna"...
Kapis? :)
Nechápu.
Zabývám se analýzou crash dumpů už nějaký ten pátek (cca 7 let?) a ještě nikdy jsem nepotřeboval např. obsah pagecache (ne metadata, ale vlastní obsah stránek, které tam byly nakešované). Teoreticky se může přepsat memmap, takže se odfiltruje stránka, která odfiltrovaná být neměla (protože má špatné pageflags), ale v takových případech k analýze zatím vždy stačila informace z té příslušné struct page.
Tj. opravdu nechápu, k čemu je potřeba ukládat úplný obraz paměti. Sorry.
Podivej se na grafy vyuziti pameti @ https://prasiatko.vpsfree.cz/munin/ na nody node3.prg, node5.prg, node8.prg, node2.brq - tam uvidis, ze tech dat k dumpovani je obrovska hromada. Duvod je, ze ZFS nepouziva linuxovou cache, ale misto toho si alokuje svoji pamet a dela si cache samo. Ten algoritmus je uplne uzasnej, ma hitrate, o kterych se linux LRU dcache muze zdat a stalo by za to, abych se o nem rozepsal, nicmene to je OT.
Pointa je, ze na systemu, kde bezi ZFS, je diky ZFS samotnymu o hodne vic pameti, kterou potrebujeme mit v dumpu, nez na beznym linuxovym systemu. Z pohledu systemu jsou to vsechno slab cache, tezko rozeznat, ktera je na co pouzivana, to je totiz dany zpusobem, jakym bylo ZFS na Linux portovany - pres abstrakcni modul SPL (Solaris Porting Layer, par headeru a obalujicich funkci, nic vic). I tak, pokud se bavime o dumpovani uzitecnejch stranek, na vpsFree, pujde o 70GB dat (aplikace + a par dalsich drobnosti, to chces mit), a to jsou data narychlo z nodu, kde neni ZFS, tzn. ani tam neni tolik kontejneru (nebo jsou malinky), protoze by to nestihal filesystem. Data ZFS jsou potom dalsi desitky gigabajtu, jelikoz mezi tema slabama nejde moc rozlisit, co je struktura popisujici data a co data, dokud do nich nevidis.
Napad byl, ze bych nemusel resit dumpovani aplikaci v kontejnerech, ale kdyz to nejaka aplikace v kontejneru shodi v kontextu, ze pouziva napr. tun/tap nejak divne, tak to chci vedet... hypoteticky, kazdopadne userspace nema co shazovat jadro a ten userspace, co muze jadro shodit, je i v kontejnerech.
Nebo vis o necem, o cem ja ne?
/snajpa
Petr T _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list