2 Apr
2014
2 Apr
'14
11:50 a.m.
-----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(a)snajpa.net> wrote:
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
-----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(a)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.
Petr T _______________________________________________
Community-list mailing list Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlM7+YgACgkQMBKdi9lkZ6p/hAEAlug4PS2nundd8lri06WV4VlM
nv3GprlfoJ500vaCF5gBAKPMjq5PWj/Av2O6IWkeN+SDP3Rx9KWo6AzkYgg/ec69
=7ONP
-----END PGP SIGNATURE-----