Ocena wątku:
  • 0 głosów - średnia: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Tutorial Jak powiększyć przestrzeń wymiany
#29
0
Plik jest zakodowany w systemie plików jako osobne kawałki (widziane w kolumnie ext). Logicznie (nie "na logikę") mamy zakresy 0, 1, 2, itp. -- generalnie jest tyle tych kawałków ile widać w kolumnie ext. Jeśli kilka z tych logicznych kawałków znajduje się obok siebie, to mamy ciągły obszar danych na dysku. Co jest póki co logiczne (na logikę) i dlatego napisałem, że z perspektywy maszyny są to osobne kawałki, a dla człowieka takie fragmenty 128M jeden za drugim mogą być traktowane jako jeden. Niemniej jednak, nawet ciągły obszar jest czytany przez system w kawałkach, z racji budowy komputera i ogólnie systemu operacyjnego (wiele procesów próbuje zapisywać/odczytywać dysk w tym samym czasie, a tylko jeden proces w danym konkretnym momencie może to zrobić). Zatem nawet jeśli plik ma wiele ciągłych bloków danych na dysku, to mogą w systemie zajść zdarzenia (i to jest zwykle pewnik), które uniemożliwią czytanie tego pliku w pojedynczej operacji I/O. Zatem nawet jeśli plik będzie miał jedną ciągłą część, a zostanie odczytany na raty w 20 operacjach, to z perspektywy tej konkretnej operacji odczytu, plik można traktować tak jakby miał 20 części i w zasadzie to w ilu częściach figuruje na dysku nie ma w tym konkretnym przypadku żadnego znaczenia. Big Grin Generalnie chodzi o transfer danych pojedynczej operacji, który nie jest jakoś specjalnie duży przy operowaniu na plikach. Zatem jeśli nawet można by plik odczytać szybciej, to pewnie procesor się zagotuje i transfer danych z dysku zostanie wstrzymany i trzeba będzie kolejną operację I/O przeporwadzić i odczytać kolejną część pliku. To co z kolei jest ciekawe, to że ext4 ma cache wszystkich zakresów pliku, który sobie tworzy w pamięci RAM przed dokonywaniem faktycznych operacji I/O . Zatem teoretycznie możliwe jest nawet odczytanie całego pliku, np. 10G, w jednym podejściu (jedna operacja I/O) mniej więcej tak samo jak przy odczycie surowym np. przez dd if=/dev/sda , no bo lokalizacja wszystkich bloków jest już znana i nie trzeba wykonywać dodatkowych zapytań do dysku, by poznać lokalizację następnych bloków danych, przez co z kolei głowica dysku może przejść płynie do następnego zakresu (to był jeden błąd we wcześniejszej wypowiedzi Big Grin). Czyli sam system plików jako taki nie wywołuje dodatkowych opóźnień (tak jak myślałem wcześniej) w stosunku do surowego odczytu danych z nośnika, oczywiście jeśli mamy do odczytu kolejne ciągłe bloki danych.  I teraz wypadłoby zestawić tę wiedzę z ilościami zapytań do pliku wymiany. No jakby nie patrzeć, przy dość sporym wykorzystaniu SWAP, tych operacji będzie bardzo dużo ale zwykle jedynie małe porcje danych będą doczytywane/zapisywane -- nie będzie sytuacji w których system będzie próbował odczytać/zapisać naraz 1G danych. Dlatego też w tym przypadku (i w wielu innych) wpływ fragmentacji pliku SWAP na wydajność systemu nie powinien być w zasadzie nawet do zmierzenia. Big Grin
Odpowiedz


Wiadomości w tym wątku
Jak powiększyć przestrzeń wymiany - przez magnus - 15-03-2019, 22:03
RE: Jak powiększyć przestrzeń wymiany - przez morfik - 22-03-2019, 13:47

Skocz do:




Użytkownicy przeglądający ten wątek: 1 gości