Forum Debian Users Gang

morfik · 2013-10-31 01:16:08

Ostatnio dużo kopiuje na pena (pliki powyżej 1GiB) i mam straszne dziwne zjawiska podczas operacji kopiowania. Było już to poruszane w tym wątku: http://forum.dug.net.pl/viewtopic.php?id=23982 ale nie ma tam rozwiązania tego problemu. Przewaliłem trochę wątków na sieci, głównie te:
https://bbs.archlinux.org/viewtopic.php?id=112846
http://askubuntu.com/questions/122113/copy-to-usb-m … k-really-slow

Posprawdzałem porady i niby u większości ludzi działa to:

Kod:

echo never >/sys/kernel/mm/transparent_hugepage/defrag
echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag

albo to:

Kod:

echo madvise > /sys/kernel/mm/transparent_hugepage/defrag

U mnie żadne z powyższych nie wpływa na cięcie się systemu przy kopiowaniu czegoś na pena.

W conkym nie widać by procek czy ram/swap się jakoś różniły przed i po rozpoczęciu procesu kopiowania, odpaliłem jeszcze dodatkowo vmstat, free i iostat, przed i w trakcie kopiowania:

Przed:

Kod:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 2  0     40 109328  21536 378704    0    0  1314   929  389 1168  8  7 58 27

Kod:

             total       used       free     shared    buffers     cached
Mem:       1033892     768648     265244          0      27680     195732
-/+ buffers/cache:     545236     488656
Swap:      2097148         40    2097108

Kod:

Linux 3.11-6.slh.1-aptosid-686 (morfikownia)     30.10.2013     _i686_    (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.85    0.44    6.95   23.08    0.00   60.68

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              35.13      2398.23        75.48    6910600     217512
dm-0             30.67       690.95        75.31    1990999     217008
dm-1              2.95         0.49        11.32       1424      32632
dm-2              0.47         0.84         1.04       2433       2992
dm-3              3.87        21.81        29.67      62833      85496
dm-4             23.18       667.71        33.28    1924025      95888
dm-5              0.10         0.40         0.00       1157          4
dm-6              3.44       411.98         0.03    1187145         96
dm-7              0.07         0.28         0.00        813          4
dm-8              0.07         0.27         0.00        785          4
sdb              13.75        10.01      1456.81      28856    4197861

w trakcie kopiowania, przy lagach:

Kod:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 2  5     40  53644  23436 393372    0    0  1343   923  389 1167  8  7 58 27

Kod:

             total       used       free     shared    buffers     cached
Mem:       1033892     981032      52860          0      23984     370060
-/+ buffers/cache:     586988     446904
Swap:      2097148         40    2097108

Kod:

Linux 3.11-6.slh.1-aptosid-686 (morfikownia)     30.10.2013     _i686_    (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.84    0.44    6.98   23.36    0.00   60.38

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              35.83      2469.64        75.89    7200072     221244
dm-0             30.65       692.56        75.71    2019107     220740
dm-1              2.92         0.49        11.19       1424      32632
dm-2              0.47         0.83         1.06       2433       3100
dm-3              3.86        21.61        30.06      63009      87652
dm-4             23.20       669.53        33.39    1951957      97356
dm-5              0.10         0.40         0.00       1157          4
dm-6              3.40       407.19         0.03    1187145         96
dm-7              0.07         0.28         0.00        813          4
dm-8              0.07         0.27         0.00        785          4
sdb              14.01         9.90      1487.83      28856    4337660

I jeśli dobrze to czytam to wychodzi na to, że wykorzystanie ramu wzrosło o 200 MiB i praktycznie cały ram jest zajęty. To dziwne, bo normlanie przy 85-92% już powinien zrzucić coś do swapa. To by tłumaczyło czemu się tnie podczas tej operacji.

Przetestowałem też to kopiowanie na kernelu z debiana -- 3.10-3-686-pae i tutaj już inaczej się zachowuje. Freezów jest znacznie mniej, 2-5 podczas całego procesu kopiowania ale samo kopiowanie pozostawia wiele do życzenia.

Transfer z poczatku jest na poziomie 70-80mb, po przeslaniu kolo 400-450 mb pliku, spada do 20kb i tak sie trzyma. Po 2min, transfer rosnie na 300kb, po 3 min jest ponad 1-1,5mb, po czym przyjmuje randomowe wartosci z przedzialu 20kb, 1,5mb. Po 4min wskakuje na 4mb, transfer utrzymuje się przez chwile, po czym spadam znowu na 20-100kb. Przez nastepne minuty tak sobie skacze miedzy 20kb a 1,5mb. Po 9,5min transfer leci na chwile na 6mb, utrzymuje się parenaście sekund i spada do 300k-600b i tak się juz utrzymuje do końca. Czasem wejdzie na 1mb, ale zwykle jest w granicach 0,5.

Przez 15min się kopiowal 1,1gb, srednia na poziomie, 1,1mb -- lampka na penie migala jeszcze 1,5-2min po odmontowaniu. Jeśli by porównać to z freezami na aptosidzie, to ten sam plik na idzie w 2,5 min ze średnia prędkościa 7,5 mb/s, tyle że się ostro przycina.

Sprawdziłem też sposoby montowania, bo ja używam głównie udevila, info o zamontowanej partycji przy pomocy udevila:

Kod:

DEVICE
/dev/sdb1 removable mounted
 on /media/morfik/DEBIAN_LIVE type vfat (rw,nosuid,nodev,noexec,noatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,utf8,errors=remount-ro)

USAGE
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sdb1      vfat  3.0G  1.2G  1.9G  38% /media/morfik/DEBIAN_LIVE

FSTAB
( not found )

INFO
UUID=23CD-4DC5
Showing information for /dev/sdb1
  native-path:                 /sys/devices/pci0000:00/0000:00:1d.7/usb5/5-7/5-7:1.0/host2/target2:0:0/2:0:0:0/block/sdb/sdb1
  device:                      8:17
  device-file:                 /dev/sdb1
    presentation:              /dev/sdb1
    by-id:                     /dev/disk/by-id/usb-Kingston_DT_101_G2_001CC0EC34A2BB318709004B-0:0-part1
  system internal:             0
  removable:                   1
  has media:                   1
  is read only:                0
  is mounted:                  1
  mount paths:                 /media/morfik/DEBIAN_LIVE
  presentation hide:           0
  presentation nopolicy:       0
  presentation name:           
  presentation icon:           
  automount hint:              
  size:                        3221225472
  block size:                  512
  usage:                       filesystem
  type:                        vfat
  version:                     FAT32
  uuid:                        23CD-4DC5
  label:                       DEBIAN_LIVE
  partition:
    scheme:                    mbr
    number:                    1
    type:                      0x0b
    flags:                     boot
    offset:                    1048576
    alignment offset:          0
    size:                      3221225472
    label:                     
    uuid:                      

PROCESSES

Po czym odmontowałem ją i zamontowałem ręcznie z roota przy pomocy:

Kod:

root:~# mount -t vfat /dev/sdb1 /mnt

Próbowałem do tego też dodać opcje -o sync ale wtedy kopiowanie pliku 1,1gib trwałoby prawie 2 godziny -- transfer 160kb/s. W każdym razie spróbowałem skopiować plik przez mc. Transfer na poziomie 5-6 mb ale tez się przycina, szczególnie gdy się zmienia okienka, wtedy są takie lagi jakby się grało w wiedźmina na 512mb ramu :] gdy zostawię aktywne okno mc i nic nie ruszam, wtedy wszystko jest ok ale wystarczy zmienić okno na geany i zacząć coś pisać albo na ff i scrollować stronę, wtedy wiedźmin powraca.

Takie info mi jeszcze wyrzuca przy wsadzaniu pena:

Kod:

2013-10-31T00:01:55.463782+01:00 morfikownia kernel: [   77.458854] usb-storage 5-7:1.0: USB Mass Storage device detected 
2013-10-31T00:01:55.464774+01:00 morfikownia kernel: [   77.459747] scsi2 : usb-storage 5-7:1.0 
2013-10-31T00:01:55.465774+01:00 morfikownia kernel: [   77.460443] usbcore: registered new interface driver usb-storage 
2013-10-31T00:01:56.558809+01:00 morfikownia kernel: [   78.553228] scsi 2:0:0:0: Direct-Access     Kingston DT 101 G2        PMAP PQ: 0 ANSI: 0 CCS
2013-10-31T00:01:56.558836+01:00 morfikownia kernel: [   78.553739] sd 2:0:0:0: Attached scsi generic sg1 type 0 
2013-10-31T00:01:57.163779+01:00 morfikownia kernel: [   79.158205] sd 2:0:0:0: [sdb] 30299520 512-byte logical blocks: (15.5 GB/14.4 GiB) 
2013-10-31T00:01:57.163803+01:00 morfikownia kernel: [   79.158817] sd 2:0:0:0: [sdb] Write Protect is off 
2013-10-31T00:01:57.163807+01:00 morfikownia kernel: [   79.158825] sd 2:0:0:0: [sdb] Mode Sense: 23 00 00 00 
2013-10-31T00:01:57.165778+01:00 morfikownia kernel: [   79.160061] sd 2:0:0:0: [sdb] No Caching mode page found 
2013-10-31T00:01:57.165803+01:00 morfikownia kernel: [   79.160070] sd 2:0:0:0: [sdb] Assuming drive cache: write through 
2013-10-31T00:01:57.171784+01:00 morfikownia kernel: [   79.166939] sd 2:0:0:0: [sdb] No Caching mode page found 
2013-10-31T00:01:57.171799+01:00 morfikownia kernel: [   79.166947] sd 2:0:0:0: [sdb] Assuming drive cache: write through 
2013-10-31T00:01:57.185775+01:00 morfikownia kernel: [   79.180864]  sdb: sdb1 sdb2 sdb3 
2013-10-31T00:01:57.959788+01:00 morfikownia kernel: [   79.954952] sd 2:0:0:0: [sdb] No Caching mode page found 
2013-10-31T00:01:57.959811+01:00 morfikownia kernel: [   79.954961] sd 2:0:0:0: [sdb] Assuming drive cache: write through 
2013-10-31T00:01:57.959815+01:00 morfikownia kernel: [   79.954969] sd 2:0:0:0: [sdb] Attached SCSI removable disk

Kod:

# lsusb
Bus 005 Device 005: ID 0951:1642 Kingston Technology DT101 G2
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 046d:c30f Logitech, Inc. Logicool HID-Compliant Keyboard (106 key)
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 09da:000a A4 Tech Co., Ltd Optical Mouse Opto 510D
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hu

Testowałem to na różnych portach usb w kompie, i na tych z przodu i na tych z tyłu, nie ma znaczenia. System plików na penie też wydaje się być bez znaczenia, mam na innej partycji ext4 i też się przycina. Co ciekawe, odczyt danych z pena jest jak najbardziej w porządku, transfer na poziomie 15-17mb, cały czas, bez freezów i innych ficzerów, tylko coś zapis szwankuje.

Jakieś pomysły?

Ostatnio edytowany przez morfik (2014-01-03 20:12:31)

dominbik · 2013-10-31 13:33:20

morfik, ale w jakim sensie freezuje? Montujesz z opcją "sync"? Ile masz RAMu? To normalne, że podczas kopiowania wszystko wolniej działa - dysk jest wykorzystywany i zwłaszcza gdy robisz coś co wymaga odczytu danych z dysku (np. uruchamiasz nową aplikację, której wcześniej nie uruchamiałeś i nic nie jest scacheowane w RAMie) może się troszkę przycinać. U mnie na Core i7 i 8GB RAMu to widać jak bardzo wąskim gardłem jest standardowy dysk HDD. Skopiuj sobie ten plik do ramu (np. /tmp) i z /tmp kopiuj do pendrive to zobaczysz różnicę (o ile wystarczy Ci pamięci RAM). Dodatkowo ja gdy coś kopiuję dużego albo np. Windows w QEMU zaczyna gwiazdorzyć i te mielenie dyskiem utrudnia mi pracę (bo wtedy cała reszta zwalnia) traktuję taki proces poleceniem;

Kod:

ionice -c 3 -t -p $PID_PROCESU

wtedy mniej to przeszkadza.

morfik · 2013-10-31 15:38:15

Np. jedziesz sobie myszką po ekranie, to nie masz płynnego ruchu tylko ci mysza staje w miejscu na 2-3s, po czym dalej jedzie płynnie przez jakąś 1sek, po czym znowu zatrzymuje się martwa na kolejne 2-3 sek i tak cały czas podczas kopiowania czegoś na pendrive.

Bez opcji sync, bo z nią mam transfer 160kb/s, ramu 1GiB

Potrafię odróżnić standardowe mielenie dyskiem od totalnego freezowania się sprzętu. Jeśli nawet sobie na logikę to weźmiemy, Mój dysk w odczycie ma załóżmy te 50MiB/s, zapis na penie jest około 5-7MiB, to jak mogłoby mi to zjeść cały transfer dysku doprowadzając do cięcia się sprzętu jak przy grach? Ale to nic, bo 5-7MiB transferu na pena to jest to co powinno być, a jest, jak pokazuje iotop, 100kb i przy tym się tnie, o dziwo przy opcji sync z 160kb/s się nie tnie. :]

Co dziwniejsze, wydaje się, że teraz jest wszystko w porządku. istne archiwum X, przez ostanie 2 tygodnie mi się tak działo, a teraz wkładam pena by przetestować parę rzeczy, np. wyciągnięcie danych ze swap do ramu, albo czysty start zamiast hibernacji i nic, działa jak powinien 7MiB transfer, bez cięcia, tzn czasem raz przytnie się lekko dźwięk albo mysza ale od razu puszcza, to normalne u mnie.

Jedyne co zrobiłem w porównaniu do wczoraj, to chciałem wyczyścić kompletnie pena i sprawdzić czy może to jest wina tego co z nim robie, i zrobiłem pierw sobie obraz całego pena i wrzuciłem na dysk i chciałem już zerować go, gdy zobaczyłem "ale w jakim sensie freezuje? " i chciałem dokładnie opisać co się dzieje, no i nic się nie działo. xD Możliwe, że jeszcze poprzednia aktualizacja systemu wpłynęła na to zachowanie, choć nie było tam kernela.

Na dobrą sprawę nie wiem co o tym myśleć, spróbuję jeszcze coś porobić z tym penem, tak by zreprodukować to zachowanie, bo raczej wątpię by surowy odczyt pena uzdrowił go.

Ok, znów się przycina. xD

Mam winnego, kto by pomyślał, toż to firefox. Jeśli nie mam odpalonego, wszystko działa gładko, tylko go odpalę i zaczynam coś kopiować, zaczynają się freezy... To dopiero dziwne.

Ostatnio edytowany przez morfik (2013-10-31 15:57:12)

dominbik · 2013-10-31 16:25:14

a zawal RAM jakimiś innymi aplikacjami i sproboj (tylko nie firefoxem)

morfik · 2013-10-31 16:34:35

Odpaliłem parędziesiąt appsów, tak, że wypełniły ram prawie do 800mb, w swapie było koło 300. Normalnie się kopiuje, czasem przytnie ale jest normlanie, nic podejrzanego nie zauważyłem.

Posprawdzałem przeglądarki:
Problem występuje w najnowsza wersja ff -- 25.0
Na iceweaselu 17.0.9esr-1~deb7u1 i 25.0~b9-1 to samo
Na chrome (31.0.1650.34-1) wszystko w porządku
na operze 12.16.1860 są lekkie przycięcia ale i tak wygląda to dużo lepiej niż na ff.

Może to przycinanie ma coś wspólnego z innym problemem ff, w którym to się on tnie niesamowicie po otworzeniu zakładek i próbie scrollowania stron www.

uzytkownikubunt · 2013-10-31 19:14:49

246

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:40:37)

morfik · 2013-10-31 19:33:13

My rozmawiamy o frEEzowaniu a nie frEzowaniu, jedno E ale jaka różnica. xD

ArnVaker · 2013-10-31 19:34:58

Jakbyś pisał normalnie po polsku, to by się z Ciebie nie nabijali. :)

morfik · 2013-10-31 19:38:37

Dla mnie i większości ludzi zrozumiałe jest freezowanie, lagowanie -- cza się uczyć obcych słówek, w końcu to inglish ma ich 650k, a polacy mają ile, 30-40k? xD

yossarian · 2013-10-31 19:52:25

Chyba najpierw wypada poznać swoje słowa, a dopiero potem się brać za obce, gdy tych pierwszych brakuje ;)

morfik · 2013-10-31 19:59:50

Pomyślę o tym gdy ludzie zaprzestaną używać słowa "pendrive". xD

yossarian · 2013-10-31 20:09:17

Czasem brakuje polskiego odpowiednika i lepiej brzmi wersja zapożyczona.

Ciekawy przykład: interfejs — międzymordzie ;)

morfik · 2013-10-31 20:20:21

Nie tyle brakuje polskiego odpowiednika, co po prostu nikt go nie stworzył bo nie zdążył. Pendrive dla jednych brzmi lepiej dla innych gorzej, podobnie "freezowanie", fakt jest faktem, że pendrive przyjęło się i jest powszechnie używane i próba zmiany tego już nie przejdzie, przecie ludzie próbowali, np pamięć usb, albo inne, mniej udane, pamięć flash, nie wiem czy była pamięć flasz. W każdym razie np. polacy mają taką skłonność do polskośći i nawet sex przerobią na seks byle by było inaczej niż za granica, to dlatego polski język ma 30-40k słów, bo się nie rozija, ludzie tkwią w tym swoim prehistorycznym słownictwie i próbują wyśmiewać tych, którzy tworzą nowe wyrazy i nadają nowy sens starym (slang). Powód takiego zachowania? Bo nie rozumieją tych słów, bo się boją, tak jak to ktoś powiedział "najpierw się śmiejecie, potem przemilczacie, wreszcie walczycie i przegrywacie".

międzymordzie - I like it xD

Pavlo950 · 2013-10-31 20:31:30

@morfik

Dla nas (dla Ciebie i dla mnie) 'freezowanie' jest okay. Ale jak ja chciałem umieścić "PC freezes, when Windows started" w pracy domowej z angielskiego, to baran który to przepisał, dostał jedynkę. I jeśli już, to 'frizowanie' lepiej wygląda (a słychać to samo).

morfik · 2013-11-14 04:57:47

Tak mnie zastanawia ten problem i zauważyłem coś takiego:

Kod:

# free
             total       used       free     shared    buffers     cached
Mem:       1026420     931656      94764          0       8900     115872
-/+ buffers/cache:     806884     219536
Swap:      2097148          0    2097148

Zajętego ramu było prawie 800MiB. Po skopiowaniu około 200MiB z 4 GiB pliku, zaczynają się dziać cuda. Raz zrzuca dane do swap, a raz nie. Jak już zacznie zrzucać zrzuca dużo, większość tego co było. No i oczywiście się tnie.

Kod:

# free
             total       used       free     shared    buffers     cached
Mem:       1026420     533004     493416          0       3404      87560
-/+ buffers/cache:     442040     584380
Swap:      2097148     431676    1665472

Zrzucił ponad 400MiB

Jak to się dzieje, że kopiowanie czegoś zapycha cache i usuwa dane z ram by zrobić miejsce pod cache... Przecie to nie tak ma działać chyba.

Drugie podejście bez swap. Kopiuje normalnie. Choć też czasem się dziwnie zachowuje. Ale jak to jest, że w drugim przypadku się mieści bez problemu na 200 MiB wolnego ramu, a w przypadku swapa musi zrzucić ponad 400MiB, żeby mógł kopiować?

Inna sprawa, wyczyściłem ram ze zbędnych rzeczy i wyłączyłem swap. Zajętych nieco ponad 200MiB. Wszystko działa jak należy ale transfer na pena z początku ma prawie 70-80MiB/s. To się utrzymuje parę sekund, bo to się kopiuje do ramu. :] To z tego powodu transfer dostaje takiego kopa, a jak skopiuje 400-500MiB, to pokazuje, że 30% przeszło, po czym transfer spada gwałtownie, bo w ramie już nie ma miejsca, a na pena nie przeszło jeszcze to co tam było. :] I zaczyna działać normalnie, czyli brać 8MiB i pakuje je na pena.

Przy czym ten cache chyba powoduje, że ciężko jest zreprodukować cokolwiek. Bo raz działa a raz nie, zrobiłem dwa razy dokładnie to samo i wyniki były inne...

Pytanie jest proste, da radę jakoś wyłączyć ten cache przy kopiowaniu plików? Albo chociaż ograniczyć cp do 30MiB max, tak by tego cache nie generował? Wtedy sobie weźmie 30MiB bufor do ramu i będzie spokój i przestanie zjadać całą dostępną przestrzeń i robić z tego cache, któremu rzeczywiste dane w ram muszą ustąpić miejsca....

dominbik · 2013-11-14 11:01:57

morfik napisał(-a):
Inna sprawa, wyczyściłem ram ze zbędnych rzeczy i wyłączyłem swap. Zajętych nieco ponad 200MiB. Wszystko działa jak należy ale transfer na pena z początku ma prawie 70-80MiB/s. To się utrzymuje parę sekund, bo to się kopiuje do ramu. :] To z tego powodu transfer dostaje takiego kopa, a jak skopiuje 400-500MiB, to pokazuje, że 30% przeszło, po czym transfer spada gwałtownie, bo w ramie już nie ma miejsca, a na pena nie przeszło jeszcze to co tam było. :] I zaczyna działać normalnie, czyli brać 8MiB i pakuje je na pena.

Morfik tak działa Linux. Sam też to kiedyś zaobserwowałem - przy zamontowanym pendrive/dysk bez opcji 'sync' (zawsze tak montuje ze względu na wydajność). Gdy kopiuję większy plik to nawet pokazuje, że już skopiował a lampka na pendrive/dysku usb nadal miga, że kopiuje. Jądro po prostu przenosi to do RAMu, redukuje I/O dysku z którego kopiujesz. Wtedy można wgl usunąć plik który kopiowaliśmy kiedy fizycznie jeszcze nie skończył się on zapisywać na urządzenie na które go kopiowaliśmy - ale wszystko gra, bo jądro już bierze go z RAMu olewając tamten dysk. Tylko, że u mnie nie powoduje to żadnych problemów.

Musi być jakaś opcja trzeba byłoby mocno poszukać/zapytać na zagranicznych forach;
https://github.com/Feh/nocache

morfik · 2013-11-14 14:47:23

Ja wiem, że tak działa i wszyscy mówią, że to rozwiązanie nie ma żadnych minusów i tak powinno być, ja jednak wolałbym, żeby mi to nie kopiowało pliku do ramu. xD Przynajmniej nie tyle ile jest wolnego miejsca.

Testuje ten nocache.

Plik przed kopiowaniem:

Kod:

pages in cache: 0/1037366 (0.0%)  [filesize=4149462.6K, pagesize=4K]

Plik w trakcie kopiowania:

Kod:

pages in cache: 2109/1037366 (0.2%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 47003/1037366 (4.5%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 26286/1037366 (2.5%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 5232/1037366 (0.5%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 2387/1037366 (0.2%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 3136/1037366 (0.3%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 1410/1037366 (0.1%)  [filesize=4149462.6K, pagesize=4K]
.....

I tak sobie chodzi dalej na 0,1-0,3%

Ale cache dalej robi swoje:

Kod:

morfik:~$ free
             total       used       free     shared    buffers     cached
Mem:       1026420     946004      80416          0      20768     289760
-/+ buffers/cache:     635476     390944
Swap:      2097148      18692    2078456
morfik:~$ free
             total       used       free     shared    buffers     cached
Mem:       1026420     951652      74768          0       9852     561172
-/+ buffers/cache:     380628     645792
Swap:      2097148     361520    1735628

Wywalił 300MiB do swapa :]

Dałem cachestats przy zwykłym kopiowaniu przez cp (bez nocache), dokładnie tak samo się zachowuje. Czyli coś nie działa ten nocache.

Co ciekawe, wyłączyłem swap i przy próbie kopiowania się przycina, wczoraj się nie przycinał, teraz się tnie. Wywaliłem ff, by zwolnić 200M i przestało się ciąć. Ale staty pliku przy kopiowaniu (bez nocache) pokazują:

Kod:

pages in cache: 31047/1037366 (3.0%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 31623/1037366 (3.0%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 30240/1037366 (2.9%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 30306/1037366 (2.9%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 30306/1037366 (2.9%)  [filesize=4149462.6K, pagesize=4K]

Czyli jak widać jest na stałym poziomie. Zaś z nocache:

Kod:

pages in cache: 424/1037366 (0.0%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 23744/1037366 (2.3%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 23832/1037366 (2.3%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 15925/1037366 (1.5%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 11885/1037366 (1.1%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 13026/1037366 (1.3%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 10990/1037366 (1.1%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 9698/1037366 (0.9%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 7721/1037366 (0.7%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 8782/1037366 (0.8%)  [filesize=4149462.6K, pagesize=4K]

I tak sobie trzyma w okolicach 0,9%.

Wywaliłem plik z cache i pomieliłem trochę przeglądarką (ciągle bez swap), wolnych jest obecnie 250M. Dałem zwykle kopiowanie:

Kod:

pages in cache: 3202/1037366 (0.3%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 2959/1037366 (0.3%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 2363/1037366 (0.2%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 3273/1037366 (0.3%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 2294/1037366 (0.2%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 1187/1037366 (0.1%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 2275/1037366 (0.2%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 1050/1037366 (0.1%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 1754/1037366 (0.2%)  [filesize=4149462.6K, pagesize=4K]

Czemu teraz szczyt był w 0,3 przy starcie kopiowania i spadł do 0,1-0,2 i się utrzymuje? I przy odpalonym ff, nic się nie tnie.

A teraz mała sztuczka, włączam swap:

Kod:

pages in cache: 322/1037366 (0.0%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 13451/1037366 (1.3%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 11819/1037366 (1.1%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 1147/1037366 (0.1%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 130/1037366 (0.0%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 258/1037366 (0.0%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 8339/1037366 (0.8%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 8211/1037366 (0.8%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 1753/1037366 (0.2%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 322/1037366 (0.0%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 3522/1037366 (0.3%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 4994/1037366 (0.5%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 20184/1037366 (1.9%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 20522/1037366 (2.0%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 21038/1037366 (2.0%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 21338/1037366 (2.1%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 19421/1037366 (1.9%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 16465/1037366 (1.6%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 12432/1037366 (1.2%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 13889/1037366 (1.3%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 12963/1037366 (1.2%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 11353/1037366 (1.1%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 9140/1037366 (0.9%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 9425/1037366 (0.9%)  [filesize=4149462.6K, pagesize=4K]

Oczywiście z początku dostałem freeza, próbowałem spamić tym poleceniem. Zrzucił mi 450M do swap chwilę po rozpoczęciu kopiowania (zwykle cp). Potem się ustabilizowało na około 1% i wszystko było ok. Bez cięcia się.

Ale po wyłączeniu sawp i próbie kopiowania (z nocache), znów się przycina, wartości ramu są ciągle zbliżone, a tak wyglądają staty

Kod:

pages in cache: 5440/1037366 (0.5%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 3078/1037366 (0.3%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 2920/1037366 (0.3%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 4097/1037366 (0.4%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 4032/1037366 (0.4%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 4941/1037366 (0.5%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 2375/1037366 (0.2%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 2379/1037366 (0.2%)  [filesize=4149462.6K, pagesize=4K]

Czemu tak się dzieje? Nie mam zielonego pojęcia, ale założe się, że jak teraz wyłącze ff i włącze go ponownie, trochę pomiele kartami i zaczne kopiować, wszystko jedno jak, to się ciąć nie będzie.

210M wolnego bez swap, wyłączony i włączony ff + załadowane 10 kart. I miałem rację :]

Kod:

pages in cache: 265/1037366 (0.0%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 5290/1037366 (0.5%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 3089/1037366 (0.3%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 2356/1037366 (0.2%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 1013/1037366 (0.1%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 1540/1037366 (0.1%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 2280/1037366 (0.2%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 1854/1037366 (0.2%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 1534/1037366 (0.1%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 2494/1037366 (0.2%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 1313/1037366 (0.1%)  [filesize=4149462.6K, pagesize=4K]
pages in cache: 2209/1037366 (0.2%)  [filesize=4149462.6K, pagesize=4K]

Coś z tymi danymi w ram jest nie tak, ale to nie jest wina ramu, bo wtedy by się za każdym razem działo.

ArnVaker · 2013-11-14 15:49:47

morfik napisał(-a):
Ja wiem, że tak działa i wszyscy mówią, że to rozwiązanie nie ma żadnych minusów i tak powinno być

U siebie nigdy tego nie zauważyłem. :)

morfik · 2013-11-14 16:02:53

To czemu u mnie takie cuda się dzieją? Czemu po przeniesieniu danych ze swap do ram powoduje, że przy kopiowaniu mam ochotę wywalić kompa przez okno? xD

Jeszcze później sprawdzę czy to tylko ff tak ma, bo akurat mi działa wielki zasobnożerca i jak po przeniesieniu danych ze swap do ram przy zgaszonym ff wszystko będzie ok, to mi to rozwali teorię. :]

azhag · 2013-11-14 16:49:32

morfik napisał(-a):
Ja wiem, że tak działa i wszyscy mówią, że to rozwiązanie nie ma żadnych minusów i tak powinno być, ja jednak wolałbym, żeby mi to nie kopiowało pliku do ramu.

To po prostu montuj nośniki w trybie synchronicznym. [Solved]. Kurtyna. Oklaski.

Nikt też nie mówi, że nie ma żadnych minusów (bo pewne ma, i bynajmniej nie te, o których Ty piszesz). Przynajmniej ja nie zauważyłem takich opinii.

Ostatnio edytowany przez azhag (2013-11-14 16:52:05)

dominbik · 2013-11-14 18:57:13

No właśnie morfik próbowałeś sync? Tylko z tego co wiem wtedy wolniej to wszystko kopiuje niż normalnie.

Ostatnio edytowany przez dominbik (2013-11-14 18:57:25)

morfik · 2013-11-14 19:24:34

Problem w tym, że mi ten sync nie działa, jak dam opcje sync do mounta i zacznę coś kopiować to transfer spada do 90-200KiB i tak się utrzymuje przez cały czas kopiowania i tak np. 1 GiB chce kopiować w 1h, po 5min se dałem spokój. xD Ciekawe jest jeszcze to, że może i podczas tego procesu się nic nie tnie ale chyba bardzo powoli jest zrzucany ram do swap, bo po rozpoczęciu kopiowania było 0M w swap, 2 min było 700KiB, po 3 już 1,5MiB, choć możliwe, że to jakieś inne procesy wrzucają. W każdym razie te 90KiB transferu, to chyba nie powinno tak działać?

Poza tym przeprowadziłem trochę inny experyment bo katowałem przez 1h swojego pc tak, że w wyniku tego miał w ramie 330M a w swapie 291 (początkowe wartości były sporo wyższe). Mam na penie partycje fat32 i ext4, testowy plik 1GiB.

SWAP 291M | RAM 330M
Kopiowanie na pena -- fat32 -- czas: 11:20s, speed: 1,5M/s , czas na umount: 2:10s
Kopiowanie na pena -- ext4 -- czas: 1:30s speed: 12M/s , czas na umount: 59s
Nie tnie się w żadnym przypadku

SWAP OFF, RAM 480M
Kopiowanie na pena -- fat32 -- podobnie
Kopiowanie na pena -- ext4 -- podobnie
Nie tnie się w żadnym przypadku

SWAP OFF, RAM 790M
Kopiowanie na pena -- fat32 -- czas: 3:46s, speed: 4,5M/s , czas na umount: natychmiast
Kopiowanie na pena -- ext4 -- czas: 2:15s speed: 7,8M/s , czas na umount: natychmiast
I tu już różnie bywa. Czasami się przycina ale obecnie mam 820M w ramie i kopiuje bez cięcia

Odczyt z obu partycji jest taki sam na poziomie 18/19M/s, bez rwania i umount natychmiastowy.

Ciekawa sprawa jest gdy się włączy swap, start przy 796M ram + 0M swap

Odczyt Fat32 -- 17M/s, czas 1:02s
Podczas kopiowania ścina na parę sek. Staty ramu po zakończeniu kopiowania:
667M + 377M swap = 1044M ??? -- swapoff -- RAM: 791M, skąd się wzięło te extra 350M i co ono robi w pamięci? :]

Odczyt Ext4: -- 17M/s, czas 1:01s
Podczas kopiowania ścina na parę sek. Staty ramu po zakończeniu kopiowania:
678M + 232M swap = 910M ??? -- swapoff -- RAM 794M, znów 114M extra, skąd to się bierze?

Odczyt z pendrive nie powoduje większych niedogodnieµ, poza tą ściną na początku, zachowuje się dokładnie tak jak z dysku na dysk albo partycji na partycje.

Chciałem przetestować również zapis z włączonym swap przy większej ilości zajętego ramu, ale mi się X-y powiesiły, od tego cięcia. Co ciekawe po przełączeniu na tty miałem tylko czarny ekran. Ale ctrl+alt+printscr+k na tty7, ubiło w końcu X-y, ale nie szło ich potem odpalić, tzn lightdm się odpalił, ale nie mogłem się zalogować, 0 błędów w Xorgu, kompletna cisza, po reboocie pc, zalogowanie poszło gładko. Ktoś spotkał się z takim zachowaniem?

W każdym razie środowisko mi się rozjechało ale zachowanie było z grubsza podobne do tego z poprzedniego postu. Jeśli w ramie sporo zajętego miejsca, to wywala połowę do swap. Z tym, że na fat32 robi to powoli, wraz z postępem kopiowania więcej danych wywala z ram i rośnie swap. A przy ext4, wywala od razu połowę do swap. No i oczywiście podczas całego procesu kopiowania się tnie.

Myślałem, że może coś ten pendrive jest montowany nie tak jak trzeba ale przy kopiowaniu tego samego pliku między partycjami dysku, też dostaje lekkiej zwiechy i zrzuca połowę ramu do swap ale po chwili wszystko wraca do normy, nic nie przycina się podczas procesu kopiowania tylko większość odpalonych appsów ma efekt spowolnienia, bo je do swap zrzucił cache ramu. :]

W każdym razie, to są wpisy z mtab:

Kod:

/dev/sdb1 /media/morfik/DEBIAN_LIVE vfat rw,nosuid,nodev,noexec,noatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/sdb3 /media/morfik/linux ext4 rw,nosuid,nodev,noexec,noatime,data=ordered 0 0

Ja bym najchętniej ten cache zablokował, żeby mi przestał wywalać dane z ramu, bo to jest śmieszne :]

dominbik · 2013-11-14 19:54:18

morfik może spróbuj z jakiegoś LiveCD jak to tam wygląda. pozatym próbowałeś kiedyś kopiować z

Kod:

ionice -c 3 -t -p $PID_PROCESU

?

morfik · 2013-11-14 20:45:15

Sprawdzę zaraz na live, na lapku i na winie. xD

A co do tej linijki, to co ja miałbym z nią zrobić?

dominbik · 2013-11-14 20:55:03

No podczas kopiowania, wchodzisz sobie w htop i zamiast $PID_PROCESU podajesz PID procesu który najbardziej obciąża dysk. w htop możesz mieć operacje IO;
w htop trzeba F2 i dodać IO_RATE. i możesz sobie sortować wdg obciążenia I/O.

to dba o to żeby podczas kopiowania gdy jakaś aplikacja zażąda dostępu do dysku te kopiowanie w tle nie przeszkadzało. idealne na desktop. sam używam przy dużych plikach już raz Ci podsyłałem to polecenie.

Ostatnio edytowany przez dominbik (2013-11-14 20:58:10)

Forum Debian Users Gang

Ogłoszenie

#1 2013-10-31 01:16:08

morfik - Cenzor wirtualnego świata

[SOLVED] Freezowanie przy kopiowaniu danych na pendrive

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

#2 2013-10-31 13:33:20

dominbik - Członek DUG

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

Kod:

#3 2013-10-31 15:38:15

morfik - Cenzor wirtualnego świata

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

#4 2013-10-31 16:25:14

dominbik - Członek DUG

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

#5 2013-10-31 16:34:35

morfik - Cenzor wirtualnego świata

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

#6 2013-10-31 19:14:49

uzytkownikubunt - Zbanowany

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

#7 2013-10-31 19:33:13

morfik - Cenzor wirtualnego świata

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

#8 2013-10-31 19:34:58

ArnVaker - Kapelusznik

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

#9 2013-10-31 19:38:37

morfik - Cenzor wirtualnego świata

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

#10 2013-10-31 19:52:25

yossarian - Szczawiożerca

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

#11 2013-10-31 19:59:50

morfik - Cenzor wirtualnego świata

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

#12 2013-10-31 20:09:17

yossarian - Szczawiożerca

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

#13 2013-10-31 20:20:21

morfik - Cenzor wirtualnego świata

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

#14 2013-10-31 20:31:30

Pavlo950 - człowiek pasjonat :D

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

#15 2013-11-14 04:57:47

morfik - Cenzor wirtualnego świata

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

Kod:

Kod:

#16 2013-11-14 11:01:57

dominbik - Członek DUG

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

morfik napisał(-a):

#17 2013-11-14 14:47:23

morfik - Cenzor wirtualnego świata

Re: [SOLVED] Freezowanie przy kopiowaniu danych na pendrive

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

#18 2013-11-14 15:49:47

ArnVaker - Kapelusznik