Fájl mozgatásnál rohamos lassulás

Fórum: 

Néhány napja olvastam, hogy az Ubuntu Mate vezető fejlesztője - Martin Wimpress - segítséget kért egy komoly rendszerhiba megoldására.

A hiba lényege, hogy 1GB körüli másolásnál a rendszer hihetetlenül belassul, ennél nagyobb fájlok mozgatása esetén pedig össze is tud omlani. Kiadtak egy javítást erre (Gnome Virtual File System hiba) és ennek a javításnak a tesztelésére kérték meg a felhasználókat egy weboldalon keresztül.

A kérdésem az, hogy a 18-as Mint-ben tapasztalt e valaki hasonlót, ugyanis nálam pontosan ugyanez történik másoláskor. Mind a 18.1, mint a 18.2 futtatása közben az 1GB-ot meghaladó fájlok másolása kínszenvedés, egy 10 GB-os file áthelyezése akár rendszeren belül, akár külső meghajtóra, lehetetlen, mert lefagy a rendszer.

Kellemetlen, de nagyobb fájlok másolásakor be kell kapcsolnom a Win10-et, mert a Mint-ről nem megoldható.

Jelenleg Linux Mint 18.2 Cinnamon 64-bit fut nálam, asztali környezetben. A kernelre is gondoltam, de a 4.8, 4.10 és a most futó 4.11 alatt is ugyanaz történik.

Tud valaki megoldást erre? Van olyan javító kulcs, amivel a Mint-ben is orvosolható ez a hiba? 

 Egy 1,6 Gb-os filmet külső

 Egy 1,6 Gb-os filmet külső meghajtóra 3 perc 10 másodperc alatt tett át.

A másolási sebesség 110 MB/s indult és a végére már csak 7,5 MB/s volt. Tehát az én másolásom jelentősen lassabb mint keraform tesztje.

Ahogy nő az átmásolandó anyag nagysága úgy romlik rohamosan a másolási sebesség, és ahogy írtam 10GB környékén össze is omlik a rendszer.

A rendszeremet korábban már írtam, de a gép paramétereit nem, így ezt most pótlom:

Linux Mint 18.2 Cinnamon 64-bit
Kernel: 4.11.0-14 generic
Desktop: Cinnamon 3.4.6 Sonya
CPU: Dual core Intel5 7400
Clock: 3GHz x 4
RAM: 8 GB

 

Még egy adalék. Miután átmásolta a filmet a külső meghajtóra, rákattintok a biztonságos eltávolítás-ra és itt kezdődik az igazi rémálom. 5-10 percig végez valamilyen ismeretlen feladatot és addig nem engedi eltávolítani a meghajtót.

Így egy 1,6GB -os film átmásolása 8-13 percet vesz igénybe...

Értékelés: 

0
Még nincs értékelve

Kipróbáltam GNOME Commander

Kipróbáltam Nemo és GNOME Commander alatt is. Sajnos az eredmény ugyanaz. Kb. 1GB-ig hasít, azután hirtelen belassul és onnantól csak vánszorog a másolás.

Értékelés: 

0
Még nincs értékelve
kimarite képe

RE: Fájl mozgatásnál rohamos lassulás

#1 A nagy fájlok másolása miatt lassul a rendszer, a molyolás a másolás végén a szinkronizálás.
Az rsync is megoldás lehet
https://serverfault.com/questions/43014/copying-a-large-directory-tree-l...
vagy más fájlrendszer (példa).
https://github.com/zfsonlinux/zfs/issues/687
Itt is írnak pár dologról:
https://www.zylk.net/en/web-2-0/blog/-/blogs/how-to-copy-files-in-linux-...

Összegezve a nagy fájlok másolásakor jelentkező lassulás
-- a biztonságos másolás megkövetelése miatt van így beállítva
-- a fájlrendszer egyes beállításai befolyásolják (alapvetően nem érdemes ezeket és főleg emiatt piszkálni)
-- lehetséges a dd vagy az rsysnc alkalmazásokra scriptet írni, ha ennyire fontos a sebesség .., mert nagyon nagy fájlokat másolására van igényed. És akkor a cp-t is ide veheted, tesztelve a három megoldás különbségét.
-- továbbá a lemezek sebessége is befolyásolja a másolást.

Érdemes lehet az alábbi parancsra rákeresni pl. a Google-lel (úgy látom, azt már ismered):
-- a kimenettel együtt közlöm

cat /proc/vmstat | egrep "dirty|writeback"
nr_dirty 12264
nr_writeback 5122
nr_writeback_temp 0
nr_dirty_threshold 19093
nr_dirty_background_threshold 9535

Tájékoztatás: bár a Windows talán gyorsabban másol
('mondják', de -úgy látom- nincsen így:
https://social.technet.microsoft.com/Forums/windows/en-US/62a1926b-12ea-...
https://answers.microsoft.com/en-us/windows/forum/windows_10-files/copy-...
https://www.tenforums.com/general-support/7009-file-explorer-extremely-s...)
talán nem annyira pontosan, mint a Linux (és fájl rendszerei). Én így tudom, persze, lehetséges más vélemény is.

-----

Úgy döntöttem, válaszolok. Kaptam egy tanácsot nemrég egy másik fórum összejövetelén ... *. Példa:
Hogyha azt kérdezem, linkelnéd Martin hozzászólását,
és erre kapok egy Google keresési találatot (sort) egyetlen URL helyett,
(https://www.google.com/search?q=Martin+Wimpress+Gnome+Virtual+File+System)
és ezek után még a keresési találatra is cikként hivatkozol (bár, nem hiszem, hogy összevesztünk volna valamikor is, tehát az én hibám biztos nem, hogy ilyen slendrián válaszokat adsz): „Mivel a cikkben 'cut-n-paste move files' szerepel, kipróbáltam, hogy mi van akkor, ha nem másolom, hanem a Kivágás/Beillesztés funkciót használom.
[*] Szóval azt a tanácsot kaptam, hogy ilyen 'stílusú' kérdezőknek egyáltalán ne válaszoljak semmit. És tudod, mit, ... valahol igazuk is van: Amilyen az adjon Isten, olyan a fogadj Isten. Nincs harag.

Értékelés: 

0
Még nincs értékelve
tonsur képe

Fájl mozgatásnál rohamos lassulás

Fájlok mozgatásával kapcsolatos tapasztalatomat osztom meg ubuntu 16.04.3-as rendszerrel:
Hálózaton belüli gépről-gépre másoláskor a folyamatjelző tökéletesen szinkronban mutatja a folyamatokat,ugyan ez a helyzet, ha pendrive-ról, vinyóról másolok a gépre,de ha a gépről másolok külső adathordozóra,akkor elöször a 8GB ramomba másol a fájlkezelő, ami villámgyors,majd a memoriából másol a külső adathordozóra,lassan,de a folyamatjelző csak a memóriába másolást mutatja helyesen,a külső adathordozóra másolás kezdetekor már 100%-elkészültséget mutat,holott,csak ekkor kezdi el kimásolni az adathordozóra az adatot.ami hosszú percekig tart.Tehát ha azt meglehetne oldani (úgy mint a windowson), hogy közvetlenül másoljon a-ból b-be,akkor a folyamatjelző végig helyesen mutatná a munkamenetet.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Helyreigazítás

@#10 Igen, mindenben igazad van, a két személy különbözőségére én is rájöttem, de már inkább rányomtam a Kilépés-re ;). Valójában tényleg az a helyzet, hogy az áthelyezés gyors (elvárt) és a másolás lassú. És erre az utánad szóló ad magyarázatot, tehát, hogy nem 'on the fly' történik a másolás, hanem a RAM-ba. A további félreértések elkerülése végett megpróbálok utána nézni megoldásoknak. De ... ha egyes számban hivatkozik a kérdező a cikkre (a kiemelés emiatt), akkor csak tudná linkelni. :-)

Értékelés: 

0
Még nincs értékelve
tonsur képe

Fájl mozgatásnál rohamos lassulás

Tovább kutatva a belassulási jelenséget másoláskor, az általam tapasztaltak egybeesnek a neten talált magyarázattal.
32 bites Linux Mint 18.2-es rendszeren 4.4-es kernelnél nem jelentkezik a probléma, 64 bites és újabb kernelekkel már igen.
Tehát kernel szintű a gond,átmeneti megoldásként a cache méret csökkentését javasolták a legtöbben,de ezzel én nem kisérleteztem,gondolom kimarite majd ezt is számba veszi.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Fájl mozgatásnál rohamos lassulás

#13 Akkor használd a 4.4-es kernelt. :-)

Csak javasolni tudom a 4.9.x-et, mert -igaz, Debian alatt- teszteltem:
-- 2-7GB másolása/áthelyezése egyaránt: 2-8 perc
-- 10-15GB másolása/áthelyezése egyaránt: 8-12 perc

Másik kernel telepítése innen kiindulva,
http://kernel.ubuntu.com/~kernel-ppa/mainline/
és folytatva pl. a legújabb 4.9.x verziójú kernellel.
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.46/
(a dpkg-val telepítve ez a kernel verzió verziójában tovább nem frissül!)

-- készítesz egy munkakönyvtárat
(ha még nem létezik ... a saját könyvtáradban)

mkdir tmp

-- belépsz a könyvtárba

cd tmp

-- letöltés
(alábbi három csomagot kell letölteni)

32 bit

wget -c http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.46/linux-image-4.9.46-040946-generic_4.9.46-040946.201708300532_i386.deb
wget -c http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.46/linux-headers-4.9.46-040946-generic_4.9.46-040946.201708300532_i386.deb
wget-c http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.46/linux-headers-4.9.46-040946_4.9.46-040946.201708300532_all.deb

64 bit

wget -c http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.46/linux-image-4.9.46-040946-generic_4.9.46-040946.201708300532_amd64.deb
wget -c http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.46/linux-headers-4.9.46-040946-generic_4.9.46-040946.201708300532_amd64.deb
wget -c http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.46/linux-headers-4.9.46-040946_4.9.46-040946.201708300532_all.deb

-- telepítésük
(a parancs minden .deb végű csomagot telepít a tmp könyvtárban: ugye, csak a három DEB van ott?!)

sudo dpkg --install *.deb

-- megnézed, javítani kell-e valamit

sudo apt-get -f install

-- ha nem, kilépsz a könyvtárból

cd

-- és bezárod a terminált

exit

-- majd a rendszer újraindítása után ezzel a kernellel indítasz.

-- dmesg kimeneteket nézegetsz (van-e valami új 'érdekesség'.
-- ha nem vált be a dolog, akkor érdemes lehet eltávolítani a kernelt.
-- mindezt saját felelősségre teszed.
-- a biztonság érdekében használhatsz Systemback visszaállítási pontot.

-----

Erre még mindig választ várok:
(biztosan mindenki érti, mire gondolok: mert már kezd érdekelni az a 'bizonyos' jelentés. Az egyszer már kért válasz megérkezése előtt nem töröm magam én sem túlzottan a válasz adással, ki hogy érti ..., úgy lesz.)

Néhány napja olvastam, hogy az Ubuntu Mate vezető fejlesztője - Martin Wimpress - segítséget kért egy komoly rendszerhiba megoldására.

A hiba lényege, hogy 1GB körüli másolásnál a rendszer hihetetlenül belassul, ennél nagyobb fájlok mozgatása esetén pedig össze is tud omlani. Kiadtak egy javítást erre (Gnome Virtual File System hiba) és ennek a javításnak a tesztelésére kérték meg a felhasználókat egy weboldalon keresztül.”

Értékelés: 

0
Még nincs értékelve
kimarite képe

Fájl mozgatásnál rohamos lassulás

@#15 Hm ... . Azt nem tudom, mit kérdezősködtök ennyit, ha ott a megoldás. :-)
Azaz a Main tárolóban levő Gvfs csomag bugja ez, és a Proposed (előzetes, néha nem egészen stabil) verzió megoldja, ... és gondolom, majd a Main tárolóban is javítva lesz.

Fel kell venni a Xenial Proposed tárolóját, majd -a leírás szerint- frissíteni a csomagot.

sudo apt update
sudo apt install gvfs/xenial-proposed

Majd újratölteni a Caja fájlkezelőt

caja -q

és kész.

Nálatok ez nem oldotta meg? Próbáltátok?
Mint említettem, nálam szintén MATE, szintén Caja, és sem a másolással, sem az áthelyezéssel semmi gondom. És ez egy Debian Stretch. Bugos az Ubuntu csomag, jelentsük ki. És ennyi. Köszi a linket. Van még kérdés?

Értékelés: 

0
Még nincs értékelve
kimarite képe

Re: Fájl mozgatásnál rohamos lassulás

@#2 Idézet, válaszokkal, tippekkel:

Egy -a Nemo szerint- 4.0 GB-os, és egy 6.0 GB-os filmet másoltam a merevlemezről egy USB-s külső meghajtóra.
A másoláskor a 10.1 GB-os adatmennyiség átmásolásához 5 perc 50 másodperc kellett.
-- előfordulhat az, hogy USB 3.0 csatlakozót használtál?

A mérkőzés állása:
1 percnél 2.0 GB 32 MB/s
2 percnél 3.6 GB 30 MB/s
3 percnél 5.4 GB 29 MB/s
4 percnél 7.0 GB 29 MB/s
5 percnél 8.7 GB 29 MB/s volt.

Ha átlagot számolok, akkor 1 perc alatt 1.8 GB, vagy másképpen 35 másodperc alatt másolt 1 GB-ot.

Ezután ugyanezt a két fájlt átmásoltam a /media/user/Adattár/JDownloads mappából a /home/user/Videók mappába, ekkor az alábbiakat kaptam:
Az átmásolásához 5 perc 55 másodperc kellett!
-- 5 másodperc szerintem nem nagy különbség 10GB másolásakor sem, a másolást a rendszer működése is befolyásolja, továbbá a merevlemez állapota, és gyárilag garantált sebessége.
-- az általam közölt értékeket IDE (P-ATA) HDD-nél mértem, tehát SATA nem volt sehol. Bár ..., bocs, mégsem. Egy külső meghajtóra másoltam a belső IDE-ról, de USB 3.0 csatlakozó ezen a gépen még sehol. Kis gondom, hogy vélhetően a külsó meghajtó tápja -mindeközben, valahol az időben (ma)- megadta magát, mert a LED villog, és nem ég folyamatosan. Van még egy ilyenem, de ez nem jó hír ... . Remélem, nem a lemez adta meg magát, nem túl régi ... .

1 percnél 2.4 GB 40 MB/s
2 percnél 5.0 GB 41 MB/s
3 percnél 8.0 GB 44 MB/s
4 percnél 8.5 GB 36 MB/s
5 percnél 9.0 GB 30 MB/s volt.

Bár a részeredmények itt sokkal jobbak, a másolási sebesség 4 percig sokkal nagyobb, de az utolsó percben nagyon lelassult a másolás, sőt néhány másodpercre többször le is állt a másolt mennyiség növekedése. (Természetesen nem a legvégére gondolok, mert akkor ugye mindig gondolkodik egy kicsi, hogy most mit is csináljon, mert elfogyott a másolni való)
-- nálam nem volt semmilyen gondolkodás.

Szerintem, a Nemo-n (Cinnamon) is segít a proposed gvfs csomag. A megoldást ennyire nehéz volt észrevenni ... vagy csak most néztél rá te is, ahogy rákerestél? Hisz' írtad, három találat volt összesen. Na mindegy.

A segítés nemcsak abban áll, hogy állít valamit a kérdező, és arra én veszettül rákeresek. Hanem, amit kérek, vagyis, amit ő talál, azt ossza meg, tehát a két dolog összefügg a fórum munkában. Igazából nem arról szól a történet sosem, hogy én vagy mi oldjuk meg, hanem arról, hogy közösen. De nem könnyű segíteni sem ... :-)

Értékelés: 

0
Még nincs értékelve
kimarite képe

Ha ezt nekem írtad:

@#18 Hogyan mondjam el neked, azt, amit nem lehet (ez egy dal szövege..). Szóval, akkor vélem, hogy:
A tegnap jött frissítést te telepítetted és megoldotta nálad a problémát. :-)
Részemről sincs harag.

Értékelés: 

0
Még nincs értékelve
tonsur képe

Fájl mozgatásnál rohamos lassulás

Ha valakinél a már emlitett gvfs frissítés nem oldotta meg a problémát (nálam nem oldotta meg),akkor ajánlom az ezen az oldalon leirtakat kipróbálni nálam működik: Transfer “freezes” when writing big files on USB drive
A puffer méretével lehet szabályozni, a másolás sebességét, ha túl kicsi akkor szakaszos lesz a másolás,ha túl nagy akkor az eredeti problémához közelitünk,nekem a 15-20 MB/sec tünik jó kompromisszumnak,ekkor a folyamatjelző végig helyes másolási értékeket, és időket mutat, és a folyamat végén ténylegesen befejeződik a másolás.
Csak az a baj, hogy az igy beállitott pufferméretet nem tudom véglegesiteni,annak ellenére,hogy a nano-ban rendben elmentem, a gép újrainditásakor visszaáll az alap 0 értékre mindkét érték. Ebben kérném a profik segitségét,amit előre megköszönök.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Fájl mozgatásnál rohamos lassulás

#21 Szia tonsur, a Proposed tárolós megoldásról olvastál?
A puffer méret fixálásával is foglalkozunk, csak ma eléggé elfáradtam.

Értékelés: 

0
Még nincs értékelve
tonsur képe

Fájl mozgatásnál rohamos lassulás

Nem hallottam róla,de kiváncsian várom az ismertetődet.
Viszont ezen az oldalon megtaláltam a pufferméret véglegesitésének a módját:
Low write performance on SLES 11 servers with large RAM
az oldal legalján van a lényeg,hogy a /etc/sysctl.conf fájlban lehet megadni a kivánt értéket,ami az első újrainditás után lép érvénybe.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Fájl mozgatásnál rohamos lassulás

#23 Igen, valami ilyesmit írtam volna én is, azaz ugyanott szerkesztgettem volna,

locate sysctl.conf
/etc/sysctl.conf
[..]

s a módszer is ugyanaz. Úgyhogy válasznak is elfogadható a linkelt megoldás, én sem keresem.

Egy embernél jelentkezett a hiba, mely egy bug lehet vagy műszaki ok.
A bug tekintetében írtam választ. Más embernél nincs ilyen jelenség, ráadásul a kérdező eltűnt.

A hatékonyság érdekében a a lemezre írnadó adatok a lemezre történő küldés előtt bekerülnek a gyorsítótárba. Az írás közben várakozó adatok gyorsítótárát "piszkos gyorsítótárnak" hívják. Vannak hangolható beállítások, amelyek befolyásolják, hogy a Linux kernel hogyan kezeli a piszkos gyorsítótárat. ... a túl nagy méretű (8GB méret felett) piszkos gyorsítótárat nehéz átöblíteni, ezért méretének csökkentése szükséges lehet.

Másoknak is érdemes elolvasni, egész jó a fordítása így:
https://translate.google.com/translate?sl=en&tl=hu&js=y&prev=_t&hl=hu&ie...

Értékelés: 

0
Még nincs értékelve
tonsur képe

Fájl mozgatásnál rohamos lassulás

Már csak azt kérdezném,hogy a cikkben az ajánlott értékek :
600 MB maximális piszkos gyorsítótár (vm.dirty_bytes = 629145600), és
300 MB háttérfájl (vm.dirty_background_bytes = 314572800)
amennyiben ezektől az értékektől lefelé,vagy felfelé eltérek, milyen következményei lesznek a rendszerre nézve?
Nekem pont a tizede, tehát 60mb piszkos gyorsitótár.és 30 MB háttérfájl értékeknél működik a legjobban a fájlmásolás külső lassú eszközre (pendrive).

Értékelés: 

0
Még nincs értékelve
kimarite képe

Fájl mozgatásnál rohamos lassulás

#25 Két módszer használható:
-- az arány és
-- bájt beállítás (az, amit te próbáltál).
„Ne feledje, hogy egyszerre csak egy módszer (bájt vagy arány) használható.”

Én ezt a leírást próbálnám először (arány módszer) :

vm.dirty_ratio
A piszkos rendszer memória maximális százaléka (alapértelmezett 40).
 
Amikor a memória százalékos aránya meg van téve, a folyamatoknak többet nem szabad írni, amíg a gyorsítótárazott adatok egy részét nem írják ki. Ez biztosítja, hogy az arány érvényesüljön. Önmagában, ami lelassíthatja, észrevehetően, de nem feltétlenül ír. Ha azonban egy alkalmazás olyan nagy mennyiségű adatot ír le, amely még mindig a piszkos gyorsítótárban van, majd kiad egy "szinkronizálási" parancsot, hogy mindent írjon a lemezre, akkor ez jelentős időt vehet igénybe. Ez alatt az idő alatt egyes alkalmazások beragadhatnak vagy lóghatnak. Egyes alkalmazások, amelyeknek időzítői figyelik ezeket a folyamatokat, még azt hiszik, hogy túl sok idő telt el, és meg kell szakítani a műveletet, vagyis "időtúllépésnek".

Ezért nagy memória szervereken ezt a beállítást csökkenteni kell ahhoz, hogy a piszkos gyorsítótár kisebb maradjon. Ez lehetővé teszi a teljes szinkronizálást (flush, vagy commit) hosszú késések nélkül. A 10% -os beállítás (40% helyett) néha megfelelő lehet a teszteléshez, de gyakran még ennél is alacsonyabbra van szükség. A kísérletezés számos megvilágosodhat.

vm.dirty_background_ratio
A piszkos rendszermemória százalékos aránya, amelyen a háttér visszaírása megkezdődik (alapértelmezett 10).
 
A "Háttér" írások elindulnak, hogy az írás még akkor is megtörténjen, amikor az alkalmazás nem kényszeríti a szinkronizálást, és még ha a dirty_ratio még nem érhető el. Ennek a beállításnak az a célja, hogy megóvja a piszkos gyorsítótár túlzott növekedését. Ha a piszkos_ratio-t 10-re csökkentjük, akkor gyakori lehet, hogy a piszkos_háttér-méretet 5-re vagy alacsonyabbra csökkentjük. Hüvelykujjszabály: dirty_background_ratio = a dirty_ratio 1/4 és 1/2 része.
 
Ezek a korlátok a sysctl segédprogrammal figyelhetők meg vagy módosíthatók (lásd a sysctl (8), sysctl.conf (5) man oldalakat). De egyszerűen megfogalmazva ezeket beállíthatjuk (a bootoláskor érvénybe lépve) az /etc/sysctl.conf fájlban, mivel:
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
 
Ha szükséges, a "sysctl.conf" paraméterek "állandó" beállítása helyett azonnal megváltoztathatók, de csak az újraindítás (vagy resetálás) után, a következő példamódszerrel:
echo 10 > /proc/sys/vm/dirty_ratio
echo 5 > /proc/sys/vm/dirty_background_ratio

*****

Szerintem, ha a bájlt módszernél választod, úgy a fizikai RAM méretének 5%-val érdemes kezdeni a dirty_ratio értékének megadásban, majd csökkenteni lefelé az értéket és e beállítás értékének fele legyen minden esetben a dirty_background-ratio értéke.

Nálad mennyi százaléka a RAM-nak a 60MB?

Értékelés: 

0
Még nincs értékelve
tonsur képe

Pufferméret optimalizálása

8GB ram van a gépben,ehhez az ajánlásod szerint 400/200MB lenne a kiindulási érték,de ezeknél az értékeknél még hasonlóan elhúzódik a pendrive-ra másolás mint az eredeti értékek (korlátlan puffer méret alapbeállitás) esetén.
Ha hagyom a 60/30MB-ot,az milyen hátrányokkal jár a rendszer működésében?
Gondolok itt pl egy videoszerkesztőre,ami eleve sok ramot használ,ennek a működését is befolyásolná a pufferméret csökkentése?

Értékelés: 

0
Még nincs értékelve
kimarite képe

Pufferméret optimalizálása

#27 A kernel a feladatokat sorba teszi, ha valamivel 'nem tud előre haladni', úgy az a feladatra szánt idő növekedésével jár.
A kernel cache-n kívül figyelembe kell venni a HDD saját gyorsítótárát is.

Rugalmas működéshez (tipp)
-- csak a vm.dirty_background_ratio értékét csökkentsd (mert ez a cache minimum értéke) és
-- a vm.dirty_ratio értéke maradjon az eredeti, (mert ez a cache maximum értéke, eddig növekedhet igény esetén)
esetleg növeld a RAM méretének 50%-ra,
https://sites.google.com/site/sumeetsingh993/home/experiments/dirty-rati...
netán -legfeljebb- 80%-ra,
https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performanc...
de a nagy értékek akkor jönnek jól, ha lassú adatátviteli sebességgel kényszerülsz írni, pl. SD kártyára

Ha a RAM cache nem elég az alkalmazás műveleteknek, akkor a lapozó terület ('swap') lesz használva, mely
-- nyilvánvalóan lassabb, mint a RAM, így lassulás lesz tapasztalható  RAM használathoz képest.

A RAM működési sebessége nyilvánvalóan és sokkal gyorsabb a HDD működési sebességénél, ezért használják a cache-lésre. (https://stackoverflow.com/questions/27900221/difference-between-vm-dirty...)

Összefoglalva:
-- túl kevés cache nem elég egyes alkalmazások nagyobb igényének, így idő túllépés esetén, akár azoknál akár működésbeli zavarok is észlelhetőek lehetnek
-- túl sok cache a már említett okból (a címben, az eredeti problémát nézve, és az általam említett öblítést) lassulást okozhat. Továbbá bármely műszaki probléma, pl. pillanatnyi áram kimaradás, vagy a RAM bármely esetei problémája a cache-ban várakozó adatok sérülését okozhatja, így azok sikeresen már nem írhatóak át a lemezre: és adatok áthelyezésekor probléma, mert másoláskor megmarad az eredeti. De nemcsak külső adatokat másolsz, hanem belsőket, melyeket az alkalmazások használnak a háttérben.

Kicsit mellébeszélek: gondolhatnál cache eldobásra
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6...
de, ha igen (non-destructive operation), akkor csak/esetleg így,
https://lacyc3.eu/memoria-gyorsitotar-uritese
másrészt ez 'egyáltalán' nem függ össze az eredeti kérdéssel.

Talán erre az alkalmazásra érdemes lehet ránézned:
https://launchpad.net/sysbench

Ki kell próbálni azt a videó szerkesztő alkalmazást, hogy mennyiben változik a viselkedése az új beállításokkal.

Értékelés: 

0
Még nincs értékelve
tonsur képe

Pufferméret optimalizálása

Köszönöm a részletes magyarázatot.
Végigpróbáltam az ajánlott beállitásokat kezdve a vm.dirty_ratio-s százalékos értékekkel,(20/10%,10/5%) amik érzékelhetően nem befolyásolták a rendszer működését,ezért a vm.dirty_bytes = 104857600, és
vm.dirty_background_bytes = 52428800 beállitásnál maradtam, (tehát 100/50MB értékek) ami már jelentős pendrive másolási sebesség gyorsulást eredményezett, és a videoszerkesztő programok is megfelelően működtek.
Hogy érzékeltetni tudjam a javulás mértékét az (usb2-es pendrive-ra másoláskor): eredeti beállitással (vm.dirty_ratio = 20,vm.dirty_background_ratio = 10) a fájlkezelő folyamatjelzője 100%-os elkészültség elérése után még 3 percig másolt a memoriából a pendrive-ra, a módositott értékek után pedig 10 másodpercig, vagyis eredeti beállitásokkal 2+3 percig tartott a másolás, a módositás után pedig 2perc+10másodpercig.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Pufferméret optimalizálása

#29 Szívesen. :-)
Konkrét beállításokat teszt által tudsz kivitelezni, mert a beállítás általában hardver függő.

Én fel szoktam írni a saját beállításokat, azaz szövegfájl(ok)ba jegyzetelek (*.txt). De lehet a 'súgó/kézikönyv' egy Libreoffice dokumentum is. Másrészt legtöbbször a szerkesztés előtt:

-- a konfigurációs fájl eredeti beállításait mentem (másolom), ha rendszerfájl, akkor 'sudo' val

cp /elérési_út/eredeti_fájl /elérési_út/eredeti_fájl.ORIG

azaz

sudo cp /etc/sysctl.conf /etc/sysctl.conf.ORIG

-- továbbá megjegyzést írok a változtatás fölé, a komment (#) használatával, hogy a rendszer ne vegye a megjegyzést beállításnak.

     -- megnyitom szerkesztésre a fájlt (most a nano szövegszerkesztővel)

sudo nano /etc/sysctl.conf

     -- és beleírom a megjegyzést a változtatáshoz - a végén lesz (angolul is lehet)

### Alacsony adat másolás/áthelyezés képesség javítása,
### a puffer méret optimalizálása
# Forrás: Low write performance on SLES 11 servers with large RAM
# https://www.novell.com/support/kb/doc.php?id=7010287
# (https://linuxmint.hu/forum/fajl-mozgatasnal-rohamos-lassulas)
vm.dirty_bytes = 104857600
vm.dirty_background_bytes = 52428800

     -- majd mentem a változtatást és bezárom a szerkesztőt

Ctrl + O és Enter
Ctrl + X

Megj.: A '/proc/sys/vm/dirty_bytes' és a '/proc/sys/vm/dirty_background_bytes' nem szerkeszthetők:
[ A(z) „/proc/sys/vm” könyvtár nem írható ]

Értékelés: 

0
Még nincs értékelve
tonsur képe

Fájl mozgatásnál rohamos lassulás összefoglaló

Azt hiszem a téma végéhez értünk, igy érdemes összefoglalni a jelenséget és annak orvoslási lehetőségét.
A 64 bites ubuntu alapu rendszerek a rendszermemóriát használják puffernek,ami általában előnyös, de nagyobb fájlok külső adathordozóra való átmásolásánál hátrányos,mert a biztonságos adatátvitel érdekében, miután nagy sebességgel egészben vagy részben (memória nagyságától függöen) bemásolta a memóriába a fájlokat,onnan lassan irja ki a külső adathordozóra, majd másolás végén a szinkronizálás, és ami igazán lassitja a folyamatot, hogy a memóriát meg kell tisztitani a bemásolt adatoktól ami nagyobb memória kapacitás esetén hosszadalmas.
Ezért ezt a kapacitást előre lecsökkentve (mértékét tesztek által az adott hardverhez igazitva) megszüntetjük a memória "piszkos fájlokkal" való telitődését,igy felgyorsitjuk a fájlok másolását.
(az ezt megelöző hozzászólásaimban ennek módját,és mértékét részletesen kitárgyaltam)
Az adott rendszerhez megállapitott adatokat érdemes valamilyen formában elmenteni,hogy esetleges újboli beállitás esetén rendelkezésre álljanak.
Ha valamit nem jól értelmeztem,akkor megkérem kimarite-t,hogy korrigálja.
Köszönöm.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Fájl mozgatásnál rohamos lassulás összefoglaló

#31 Igen, egyetértek.
Annyit még hozzátennék, mint korábban

Rugalmas működéshez (tipp)
-- csak a vm.dirty_background_ratio értékét csökkentsd (mert ez a cache minimum értéke) és
-- a vm.dirty_ratio értéke maradjon az eredeti, (mert ez a cache maximum értéke, eddig növekedhet igény esetén)

tehát, hogy a „vm.dirty_ratio” értéke maradhat az eredeti vagy akár növelhető is, ... mert a lassabb adatátvitelhez (pendrive, SD kártya) a nagyobb puffer lehet szükséges (a maximum érték).

Értékelés: 

0
Még nincs értékelve
kimarite képe

Fájl mozgatásnál rohamos lassulás - bug

#32 „Annyit még hozzátennék, mint korábban”
-- ez egy kísérletezgetés eredménye .. amit legjobb lenne blogba öntened, és mert
-- .. nem sok köze van ahhoz, hogy az eredeti problémát egy bug okozza.
Jót! :-)

 

Értékelés: 

0
Még nincs értékelve