openSUSE 15.6 alatt sok fájlt tartalmazó mappa lassú kezelése

Linux-haladó

Frissítettem openSUSE 15.6-ra, kernel:6.4.0-150600.21-default. Ezután egy laptopon SSD meghajtón jelentkezik az a probléma, hogy a sok fájlt(100e+) tartalmazó mappákat nagyon lassan kezeli a gép.

 - Ugyanazon a laptopon ugyanazt a partíciót másik régebbi Linuxok alá felcsatolva jól (gyorsan) kezelik.

 - Ugyanazt az openSUSE 15.6-ot, (kernel:6.4.0-150600.21-default) egy asztali PC-re is feltettem. Itt HDD van. A mappák másolatát teljesen jól (gyorsan) kezeli.

 - Próbaként csináltam a laptop/SSD-n EXT2, EXT3, EXT4, XFS, BTRFS partíciókat, de azokon is hasonlóan lassan megy a dolog.

------------------------------------------------------

A címet javítottam, mert mint később kiderült a problémának semmi köze a kernelhez:

https://hup.hu/comment/3066283#comment-3066283

(Eredetileg ez volt a címe:kernel 6.4 alatt sok fájlt tartalmazó mappa lassú kezelése)

  • 1016 megtekintés

( Raynes v | 2024. 05. 31., p – 11:18 )

Háttérben nézd top-pal, iotop-pal, hogy mi fogja a gépet, mikor lassulást észlelsz, proci, I/O vagy micsoda. Szabad hely mennyi a kérdéses meghajtón, partíción? Véletlen nincs valami szkennelő szolgáltatás engedélyezve? Folyamatos TRIM az fstab-ban csatolási opcióként felvéve?

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( SPYFF v | 2024. 05. 31., p – 12:24 )

Csak a kernel a különbség?

Én akkor tapasztaltam hasonlót mikor gnome-ban default lett a thumbnail generálás. Egy mappában ahol sok kép és videó van ez felpörgeti a CPU-t és rohadt lassú lesz minden.

Pedig ez egy jó kérdés, amit a kolléga felvetett, akkor is, ha nincs videó, kép a mappában. Milyen programmal „kezeled”? Úgy értve, hogy melyik fájlkezelő ez pontosan, próbáltad másikkal, hogy abban is lassú-e?

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Szerintem is jó kérdés, ez is és a többi is. Mindenkinek köszönöm.

Én általában a saját programomat (ng-xim) használom, de a probléma általános. A directory lista beolvasása a lassú. Az idő 10 és 35 sec között mozog. Külön érdekesség, hogy a második, harmadik beolvasás is hosszú (,néha hosszabb mint az előző). Az a gyanúm, hogy dir_index-et akar csinálni. (Pedig a dir_index formázáskor ki lett kapcsolva. A tune2fs -l azt mutatja, hogy nincs dir_index.)

Viszont van új fejlemény:

A jól működő rendszerből szépen egymás után lecseréltem könyvtárakat és megnéztem mikor javul meg.

1. /boot --- semmi változás

2. /lib --- semmi változás

3. /lib64 --- semmi változás

4. /usr/lib --- semmi változás

5. /usr/lib64 --- semmi változás

6. /etc (az fstab kivételével)  --- a probléma megszűnt !!!

Mi az ami az etc-ben előidézi ezt a problémát. (Nem az fstab, mert az ugyanaz.)

Nagy Gábor   https://sign-el-soft.hu

Melyik volt ez a kettő. Nem kötözködésből kérdezem, hanem valóban kíváncsi vagyok, mert én ilyennel még nem találkoztam. Nem is tudtam, hogy létezik egyáltalán ilyen malloc debug. Eleve nem is értem, hogy melyik alkalmazás gondolta, hogy ezt jó ötlet a felhasználó tudta nélkül bekapcsolgatni. Ezt az életben ki nem találtam volna, hogy ez okozza.

Azt se értem, ha az malloc debug a gond, akkor egyik kernellel miért volt jó, a másikkal miért lassú?

“The world runs on Excel spreadsheets.” (Dylan Beattie)

"Azt se értem, ha az malloc debug a gond, akkor egyik kernellel miért volt jó, a másikkal miért lassú?"

Ugyanaz a kernel mindkét esetben!!! Az egyiken jó volt a másikon nem. Csak mellesleg megemlítettem, hogy a régi kernellel is jó volt.

A különbség a két telepítés között az, hogy a "rossz" egy áprilisi ISO-ról lett telepítve, a "jó" pedig a május elején kiadott ISO-ról, majd ezt követően mindegyiket frissítettem, így a kernel már ugyanaz volt mindkettőben. A "jó" telepítésben ez a két fájl már nem volt benne, és természetesen a régebbi disztrókban  sem. Amikor a "rosszból" kitöröltem az is megjavult.

1- ------------------------------------------------------

etc-orig/profile.d # cat malloc-debug.csh  
# remove this file before shipment
setenv MALLOC_CHECK_ 3
setenv MALLOC_PERTURB_ 69

2- ------------------------------------------------------

etc-orig/profile.d # cat malloc-debug.sh  
# remove this file before shipment
export MALLOC_CHECK_=3
export MALLOC_PERTURB_=69

 

Nagy Gábor   https://sign-el-soft.hu

Nade várjál, a korábbi iso az snapshot verziós volt?

https://download.opensuse.org/distribution/leap/15.6/iso/

ja hogy még ezután fog kijönni a végleges kiadás belőle, jún 12-én.  Ettől persze még kellemetlen, hogy becsúszott a hiba, de ezek még nem végleges, csak próba kiadások.

Ezért kell CLI netinstall rolling disztrót használni. Most komolyan, ezek az iso-k gyorsan elavulnak, csak a gond van velük. A másik út egy fain kis immutable disztrót futtatni bare metal hypervisor-ön virtualizálva futtatva, AI NPU gyorsítás mellett, mert az most a hype.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( Fisher v | 2024. 05. 31., p – 12:52 )

Szóval akkor a két kernel ugyanaz, csak az egyik friss telepítés egy másik gépen, és azon nem lassú.

( azbest | 2024. 05. 31., p – 12:58 )

Szerkesztve: 2024. 06. 01., szo – 17:34

esetleg limiteket nézni? 

Ha másik környezetbe csatolod fel, akkor a beállítások is mások lehetnek, nem csak a kernel.

( _ventura_ v | 2024. 05. 31., p – 14:09 )

Mi van akkor ha a régi kernellel bootolod be az új distrót ?

Fedora 41, Thinkpad x280

( bucko | 2024. 06. 02., v – 18:38 )

sok fájlt(100e+)

Csak tanulságként: Hogyan sikerült idáig jutni?

Volt nekem olyanhoz szerencsém, hogy a find ctime atime fájlnévmita kisszék-hóember alapon takarító script nem bírt a könyvtárral, amiben ugyanígy k.sok fájl halmozódott fel... A sok stat/fstat hívás megártott neki, úgyhogy maradt az, hogy perl-ben directory fájl felolvas, az elemeken végiggyalogol, amelyik név illeszkedett a mintára na az kapott csak stat()-ot, és ha az időadatok olyanok voltak, akkor unlink, oszt' jónapot :-P

( zeller | 2024. 06. 03., h – 21:45 )

Szerkesztve: 2024. 06. 03., h – 21:46

Anno ext4 esetén volt már példa teljesítménybeli regresszióra - ott nekünk a régi kernelre való visszalépés volt a megoldás addig, amíg újabb kernellel a tesztek már elfogadható performanciát hoztak ismét.