CASTER, JANFROG: Uvědomil jsem si, že testovací case je nyní jiný než minule. Před x léty, kdy paměť pod stress testem nerostla jsem v testu otevřel socket a v něm v nekonečné smyčce jsem zadával requesty. Nyní otevřu socket, provedu request a socket opět zavřu. Možná proto rostla VIRT (ale valgrind byl OK). Když jsem test přehodil na původní verzi, htop hodnoty byly konstantní.

Přepsal část toho tcp/ip serveru tak, že se sockety ukládají do fronty, kterou procesuje N working threadů. Pustil jsem testy a po asi třech hodinách běhu htop ukazovalo konstantní čísla u RES, LIB a DATA. Jednou došlo ke zvýšení u SHR au VIRT. Valgrind byl také OK.

Když jsem hledal, co znamená VIRT - https://stackoverflow.com/questions/23187228/what-is-virt-column-in-htop-memory-overhead --> I would stop worrying about the VIRT thing. [...] I suspect the top page is allocated for vsyscall purposes. [...] Go by the RES entry.

Ještě to nechám několik dní bežet a uvidím. BTW asi dvou denní běh té předchozí verze serveru způsobil zamrznutí VM (ubuntu server) - nešlo na něj ssh, kurzor na login neblikal. Místo na virt. disku nedošlo.

JANFROG: ne, nepoužívá. Resp. volá jednu knihovnu a do té nevidím.
CASTER: přesně o tom jsem také přemýšlel, že by si dělal cache, ale pokud si dobře pamatuji, není k tomu důvod. A po ukončení zátěže paměťové nároky zůstanou stejné. Ještě si projdu kód a zkusím počkat, jestli se paměť nezmění.
JANFROG: stoupají i ostatní, co jsou v htop vidět.

Díky za reakce.

Dělám teď nový instal a přemýšlím nad dělením disku na /; /home; /data s tím že hudbu,dokumenty, fotky atd si budu házet do /data, kdybych dělal pak nějaký reinstal,tak udělám jen formát / a /home s /data mi zůstanou, jen připojím. No a kdybych chtěl čistý reinstal, tak zformátuju / a /home - dokumenty obrázky mi zůstanou v /data , je ta úvaha špatná?

HOWKING: tak se neboj a zkus tu experimentální větev, nebo se zbav nvidie...

B3TL: Mám stable až na grafárnu.

HOWKING: Mas stable větev, nebo experimental?

Pred casem jsem se tu ptal na zalohovani, popripade verzovani a synchronizaci dotfiles a configu ruzne po systemu. Par tydnu jsem se v tom vrtal a hledal asi dokonale reseni bez prace nebo tak neco a pak se rozhodl to udelat rucne z git repa pomoci symlinku a scriptu co je po systemu bezpecne rozdistribuuje. Nakonec jsem s tim celkem spokojeny https://github.com/manihindrich/dotfiles/ casem to prepisu do pythonu, ted jsem takhle spoko. Treba se nekomu bude hodit

MA747: VIRT ukazuje i "non-commited" memory, takze to muze znamenat jen ze si program tu pamet rezervuje ale nepouziva.

MA747: Pouziva ten program mmap + MAP_ANON?

MA747: valgrind apod pozna, kdyz program nikdy neuvolni alokovanou pamet, protoze k ni ztrati pointer atd. Kdyz ji pri korektnim ukonceni vsechnu uvolni, tak to znamena, ze pointery zjevne neztratil a leak nebyl. Ale nemuze ophalit treba pripady, kdy si program cachuje nejaka data a ma tu cache prubezne uvolnovat / drzet na nejakem mnozstvi cachovanych dat, a tohle z nejakeho duvodu nefunguje.
Nesouvisi to s tou zatezi, kdyz je to server? Kdyz se zatez vypne, nespadne taky vyuziti pameti serverem?
Dalsi co me napada, je, ze se to po letech kompiluje/spousti na novejsi glibc, kde muze byt zmena v implementaci malloc/new aby to lip skalovalo (per-thread areny atd) coz ale znamena vetsi vyuziti pameti v porovnani se starou glibc.

HOWKING: Tak po skoro měsíci se v MacOS nekousl. Udělal jsem experiment. Jednak jsem nainstaloval celý Debian od nuly znova, abych vyloučil nějaký můj renonc a pak jsem NMVe zakázal v biosu a provozoval jsem to jen na SATA disku. A kousl se po jednom dni znova. Diskem to nebude. Sere mě, že ostatní distra tak plýtvají výkonem. Debian je na stejném železe o 10% na CPU rychlejší jak jakékoli jiné distro (a už jsem zkoušel i Fedoru). Možná je chyba v tom, že do Debianu strkám ty aktuální ovladače grafiky.

SUK:
==39487==
==39487== HEAP SUMMARY:
==39487== in use at exit: 0 bytes in 0 blocks
==39487== total heap usage: 9,794,483 allocs, 9,794,483 frees, 264,131,598 bytes allocated
==39487==
==39487== All heap blocks were freed -- no leaks are possible
==39487==
==39487== For lists of detected and suppressed errors, rerun with: -s
==39487== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Tak jsem z toho poněkud zmatený. Proč tedy roste VIRT, RES?

BTW kompilace s -g; valgrind --leak-check=yes ./a.out

MA747: valgrind byl?

Poradil by mi někdo prosím, jak detekovat memory leaks? Mám napsaný program v C++, TCP/IP server, threads, několik let starý, tenkrát mi běžel v pohodě bez memory leaks, ladil jsem jej přes electric fence, běžel mnoho dnů v masivním zatížení. V noci jsem jej zkompiloval, přes noc pustil zátěž a ráno jsem v htop viděl, jak narostla virt mem. Zkoušel jsem znovu electric fence (kompilace -lefence a potom gdb a.out) a nic, teď jsem zkoušel memleax a po ukončení programu hláška: "no expired memory blocks". Díky.

DANIELSOFT: ještě bych přidal do pléna, může to být problém s SQLite.

je to pracovní stanice Dell a šlapal jak švýcarský hodinky, jen poslední dobou ten FF: dvakrát se stalo, že zmizely ikonky u bookmarků a teď tohle

možná čas na novou mašinu

jinak mám to z debu, který je v oficiálním mintovém repozitáři a FF byl už nainstalovaný hned při instalaci OS

taky ten počítač je z roku 2016 a možná už blbne disk (scan zkusím) díky efektivitě Linuxu jsem nebyl nucen upgradovat HW :)

ZBYNEK: vždycky to zatím bylo když jsem ho pustil po startu PC

zkusím lsof, díky