[vpsFree.cz: community-list] Vypadky a problemy - checklist

[Pavel Snajdr]

-----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 at 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 at snajpa.net 
>>> <mailto:snajpa at 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 at 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-----