Kopiowanie plików w ZimaOS Files z szybkością około 600–650 MB/s nie dowodzi, że samo urządzenie NVMe jest ograniczone do szybkości SATA. Poradnik społeczności ze źródła prawidłowo rozróżnia przepustowość surowej pamięci masowej od przepustowości procesu kopiowania plików. Menedżer plików działający w przeglądarce może dodawać obsługę metadanych, śledzenie postępu, mechanizmy bezpieczeństwa, kopiowanie w przestrzeni użytkownika, narzut systemu plików i operacje na poszczególnych plikach, których nie mierzy bezpośredni benchmark.
Najbardziej użyteczne jest porównanie: przetestuj tę samą pamięć masową za pomocą dużego sekwencyjnego obciążenia z bezpośrednimi operacjami wejścia-wyjścia, a następnie skopiuj ten sam duży plik za pomocą interfejsu wiersza poleceń i aplikacji Pliki. Jeśli testy surowe lub bezpośrednie osiągają kilka GB/s, a kopiowanie w interfejsie graficznym nadal utrzymuje się w pobliżu 600 MB/s, wąskie gardło prawdopodobnie znajduje się powyżej urządzenia NVMe.
Pojedynczy wynik kopiowania pliku nie jest benchmarkiem NVMe
Wewnętrzna szybkość kopiowania zależy od:
- to, czy źródło i miejsce docelowe są tym samym urządzeniem, czy różnymi urządzeniami;
- typ systemu plików;
- zachowanie kopiowania przy zapisie;
- rozmiar i liczba plików;
- narzut procesora;
- pamięć podręczna stron;
- implementacja kopiowania.
Wynik 600 MB/s może być znakomity w jednym zastosowaniu i słaby w innym.
Zacznij od dużego sekwencyjnego pliku testowego
Duże pliki ograniczają narzut metadanych i ułatwiają interpretację stałej przepustowości. Źródło użyło pliku o rozmiarze 10 GB, aby obciążenie trwało wystarczająco długo i można było je zaobserwować.
Przed utworzeniem dużego pliku testowego sprawdź, czy docelowa pamięć masowa ma dużo wolnego miejsca. Benchmark, który zapełni dysk systemowy lub dysk z danymi, może spowodować inny rodzaj awarii.
Źródło używało dd z bezpośrednimi zapisami
Poradnik społeczności proponował:
dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progressoflag=direct ogranicza wpływ pamięci podręcznej stron na ścieżkę zapisu. Jest to przydatne do zgrubnego sprawdzenia sekwencyjnego zapisu.
Nie zakładaj, że każda kompilacja, urządzenie lub system plików obsługuje ten sam rozmiar bloku albo zachowanie bezpośrednich operacji wejścia-wyjścia.
Ostrożniej interpretuj test odczytu dd ze źródła
Następnie źródło odczytało plik, aby /dev/null. Bez opcji odczytu z bezpośrednimi operacjami wejścia-wyjścia lub kontroli pamięci podręcznej niedawno utworzony plik może być częściowo obsługiwany z pamięci podręcznej stron, zawyżając pozorną szybkość odczytu.
Aby wiarygodnie porównać pamięć masową, wybierz narzędzie lub konfigurację, która jawnie używa bezpośrednich operacji wejścia-wyjścia w obu kierunkach, albo upewnij się, że rozumiesz wpływ buforowania.
fio to lepszy kontrolowany benchmark pamięci masowej
W przykładzie ciągłego zapisu ze źródła użyto:
fio --name=nvme --filename=/DATA/fio.test --size=10G --rw=write --bs=1M --iodepth=32 --numjobs=1 --direct=1 --runtime=30 --group_reportingTo nadal wskazówka społeczności, ale ma wyraźniejszą strukturę testu: jawnie określony rozmiar testu, zapisy sekwencyjne, głębokość kolejki, bezpośrednie operacje wejścia-wyjścia, czas trwania i pogrupowane wyniki.
Nigdy nie kieruj destrukcyjnego zadania fio na urządzenie surowe zawierające rzeczywiste dane. Używaj przenośnego pliku testowego w systemie plików, chyba że w pełni rozumiesz konsekwencje.
Porównaj interfejs graficzny i CLI na tym samym zbiorze danych
Najważniejsza rada metodologiczna ze źródła to użycie tego samego dużego pliku w obu przypadkach:
- kopiowanie za pomocą CLI;
- kopiowanie w aplikacji Pliki w ZimaOS.
Jeśli zbiór danych, źródło, miejsce docelowe i system plików są identyczne, różnica dokładniej odzwierciedla proces kopiowania.
Małe pliki mogą działać znacznie wolniej
Tysiące zdjęć, plików projektowych, miniatur lub wpisów AppData wymagają wielokrotnego wykonywania operacji otwierania, tworzenia, obsługi metadanych i obliczania sum kontrolnych. Łączna szybkość transferu może spaść znacznie poniżej wartości uzyskiwanej dla pojedynczego dużego filmu lub obrazu ISO, nawet na bardzo szybkim dysku NVMe.
Mechanizm kopiowania przy zapisie Btrfs oraz obsługa metadanych mogą powodować dodatkowe obciążenie zależnie od dokładnej operacji.
Monitoruj procesor i operacje wejścia/wyjścia podczas wolnego kopiowania
Źródło zaleca jednoczesne obserwowanie wykorzystania dysku i procesora. Celem jest ustalenie, czy:
- dysk jest w pełni obciążony;
- wąskim gardłem jest jeden rdzeń procesora;
- inny proces konkuruje o operacje wejścia/wyjścia;
- proces kopiowania czeka, zamiast w pełni obciążać pamięć masową.
Jest to bardziej miarodajne niż podawanie wyłącznie wartości z paska postępu w aplikacji Pliki.
Prędkość NVMe zależy również od linii PCIe i urządzenia
Nawet sprawny dysk NVMe może działać poniżej deklarowanej przez producenta wartości, jeśli:
- gniazdo obsługuje PCIe x1/x2 zamiast x4;
- platforma korzysta z PCIe Gen 3 zamiast Gen 4;
- dysk SSD ulega ograniczaniu termicznemu;
- kontroler współdzieli linie;
- Pamięć podręczna SLC wyczerpuje się podczas długotrwałego zapisu.
Rzeczywisty test wydajności należy porównywać z topologią sprzętową, a nie z ogólnym oczekiwaniem „NVMe = 7 GB/s”.
Najnowsze przewodniki transferu IceWhale również rozdzielają ścieżki interfejsu i szybszego transferu
Przewodnik IceWhale dotyczący Thunderbolt w ZimaCube historycznie pokazywał, że ścieżka transferu przez interfejs ZimaOS działa wolniej niż bezpośrednia ścieżka Samba/Thunderbolt, co potwierdza ogólną zasadę, że interfejs plików nie jest tożsamy z surową przepustowością sieci lub pamięci masowej.
Skorzystaj z aktualnej listy kontrolnej rozwiązywania problemów z transferem w ZimaOS, aby przeprowadzić obsługiwane kontrole po stronie sieci.
Usuń pliki testowe po zakończeniu
Duży dd/fio Pliki mogą szybko zajmować dziesiątki gigabajtów. Po zapisaniu wyników usuń znane pliki testowe i sprawdź ponownie ilość wolnego miejsca.
Najczęstsze pytania dotyczące testów wydajności NVMe
Czy wynik 600 MB/s w aplikacji Pliki w ZimaOS dowodzi, że NVMe jest ograniczony do prędkości SATA?
Nie. Mierzy on ten proces kopiowania, a nie surowe możliwości dysku NVMe.
Dlaczego odczyt za pomocą dd może wydawać się nierealistycznie szybki?
Niedawno zapisany plik może być częściowo odczytywany z pamięci podręcznej stron, chyba że test odczytu wyraźnie omija buforowanie.
Jakie jest najlepsze porównanie dla procesu kopiowania w interfejsie graficznym?
Użyj tego samego źródła i miejsca docelowego oraz tego samego dużego zbioru danych zarówno w interfejsie CLI, jak i w aplikacji Pliki, a następnie porównaj wyniki, monitorując jednocześnie procesor i operacje wejścia/wyjścia pamięci masowej.
