Dostrajanie zachowania pamięci podręcznej dysku Linux w celu uzyskania maksymalnej przepustowości

Mam problem z maksymalną przepustowością i potrzebuję porady, w jaki sposób dostroić pokrętła. Korzystamy z serwera plików 10Gbit do dystrybucji kopii zapasowych. Jest to konfiguracja z dwoma dyskami S-ATA2 na kontrolerze LSI MegaRAID. Serwer otrzymał również 24 gigabajty pamięci.

Musimy wykonać kopię lustrzaną naszej ostatnio przesłanej kopii zapasowej z maksymalną przepustowością.

RAID0 dla naszych „gorących” kopii zapasowych daje nam około 260 MB / s zapisu i 275 MB / s odczytu. Testowane tmpfs o rozmiarze 20 GB daje nam około 1 GB / s. Tego rodzaju przepustowość jest nam potrzebna.

Teraz, jak dostroić podsystem pamięci wirtualnej systemu Linux, aby buforować ostatnio przesłane pliki tak długo, jak to możliwe w pamięci, bez zapisywania ich na dysku (a nawet lepiej: zapisywanie na dysku ORAZ przechowywanie ich w pamięci)?

Skonfigurowałem następujące sysctls, ale nie dają nam oczekiwanej przepustowości:

# VM pressure fixes
vm.swappiness = 20
vm.dirty_ratio = 70
vm.dirty_background_ratio = 30
vm.dirty_writeback_centisecs = 60000

To powinno teoretycznie daje nam 16GB do buforowania I / O i odczekać kilka minut, aż jego piśmie do dysku. Mimo to, gdy testuję serwer, nie widzę żadnego wpływu na pisanie, przepustowość nie wzrasta.

Potrzebna pomoc lub porada.

— Peter Meyer
źródło

Czy nie byłoby rozsądniej zacząć pisać tak szybko, jak to możliwe? W przeciwnym razie osiąga maksymalny rozmiar bufora i nagle się zatrzymuje. Jeśli pisał przez cały czas, daje ci to więcej czasu.

— Zan Lynx,

Mam 20 GB pamięci tylko na bufory, ponieważ moje aplikacje (podstawowy Linux + vsftpd) używają mniej niż 4 GB (łącznie 24 GB). Moje kopie zapasowe mają rozmiar poniżej 20 GB. Jeśli uda mi się je zapisać w buforze, a następnie na dysku sekwencyjnie po uruchomieniu kopii zapasowej, znacznie zmniejszy to przestoje mojego źródła kopii zapasowej (serwerów wirtualnych). PS: Serwer może się później zatrzymać, bez problemu. Na odzyskanie 30 minut :)

— Peter Meyer

Wygląda na to, że każda aplikacja, której używasz do przesyłania danych przez sieć, synchronizuje je z dyskiem. Będziesz chciał, aby tak się nie stało, aby dane mogły po prostu siedzieć w pamięci podręcznej, choć zastanawiam się, dlaczego chcesz móc tak szybko rozdzielić wiele danych, niż dyski mogą nadążyć. To gdzieś wskazuje na wadę projektową.

— psusi

To brzmi jak wada: twoje rozwiązanie do tworzenia kopii zapasowych nie powinno wymagać wyłączania serwera przez cały czas.

— psusi

@PeterMeyer: Nawet jeśli masz dużo pamięci RAM, błędem jest czekać na rozpoczęcie zapisu. Jedyny moment, który ma jakikolwiek sens, to zamiar edytowania lub usuwania plików (takich jak plik tymczasowy), zanim dotrze on na dysk. Kopia zapasowa tego nie robi. Chcesz rozpocząć zapisywanie w tle jak najszybciej. Ustaw wartość background_ratio na 1 lub 2.

— Zan Lynx

Odpowiedzi:

Patrząc na ustawione przez ciebie zmienne, wygląda na to, że zajmujesz się głównie wydajnością zapisu i nie przejmujesz się możliwymi stratami danych z powodu awarii zasilania.

Zawsze dostaniesz tylko opcję leniwego zapisu i użycie pamięci podręcznej zapisu z asynchronicznymi operacjami zapisu. Synchroniczne operacje zapisu wymagają zapisu na dysku i nigdy nie byłyby leniwe. Twój system plików może powodować częste opróżnianie stron i synchroniczne zapisy (zwykle z powodu dzienników, szczególnie z ext3 w trybie danych = dziennik). Ponadto nawet opróżnianie strony „w tle” będzie zakłócać niebuforowane odczyty i zapisy synchroniczne , spowalniając je.

Ogólnie rzecz biorąc, powinieneś wziąć kilka wskaźników, aby zobaczyć, co się dzieje - czy widzisz, że proces kopiowania przechodzi w stan „D” i czeka na wykonanie operacji we / wy przez pdflush? Czy widzisz intensywne synchroniczne operacje zapisu na dyskach?

Jeśli wszystko inne zawiedzie, możesz ustawić jawny system plików tmpfs, w którym kopiujesz kopie zapasowe i po prostu synchronizujesz dane z dyskami po fakcie - nawet automatycznie przy użyciu inotify

W przypadku buforowania odczytu rzeczy są znacznie prostsze - istnieje fadvisenarzędzie fcoretools , które ma --willneedparametr, który doradza jądru, aby załadowało zawartość pliku do bufora bufora.

Edytować:

vm.dirty_ratio = 70

Teoretycznie powinno nam to dać 16 GB pamięci podręcznej na buforowanie operacji we / wy i poczekaj kilka minut, aż zostaną zapisane na dysk.

Nie miałoby to większego wpływu na scenariusz testowania, ale w twoim rozumieniu istnieje nieporozumienie. Parametr dirty_ratio nie jest procentem całkowitej pamięci systemu, ale wolną pamięcią systemu.

Istnieje artykuł na temat dostrajania obciążeń o dużej sile zapisu z bardziej szczegółowymi informacjami.

— the-wabbit
źródło

Tak, jestem po wykonaniu zapisu. Czas, jaki zajmuje rozłożenie kopii zapasowej na pomocniczych urządzeniach podrzędnych, nie jest moim zmartwieniem. Mam również skrypt do retransmisji, jeśli podstawowy serwer zapasowy ulegnie awarii, a kopie zapasowe nie przejdą do urządzeń podrzędnych. PS Przeczytałem już link i odpowiednio dostroiłem. Przepraszam za pomyłkę dotyczącą darmowego vs buforowanego vs całkowitego.

— Peter Meyer,

Lub po prostu zdobądź więcej dysków ... Konfiguracja macierzy napędów nie obsługuje przez cały czas. Jest to przypadek, w którym rozwiązanie należy przeprojektować, aby spełnić Twoje rzeczywiste potrzeby. Rozumiem, że jest to tylko kopia zapasowa, ale warto unikać kłopotliwej poprawki.

— ewwhite
źródło

Zgoda. Nie ma możliwości, aby kilka dysków SATA ( SATA ? Poważnie?) Wytrzymało 275 MB / s, a nawet nie mówimy o beznadziejnych procesorach IOP, które od nich dostaniesz.

— adapttr

Widzę, dokąd zmierza - ponieważ jest to tylko miejsce docelowe kopii zapasowej danych, nie obchodzi go możliwość sporadycznej utraty danych z powodu awarii zasilania. I chce zminimalizować czas potrzebny do utworzenia kopii zapasowej, zapewniając maksymalną dostępną przepustowość - w ten sposób można zapisać 20 GB danych w mniej niż 30 sekund. Jeśli z jakiegoś powodu kopie zapasowe wiążą się z przestojami lub mają wpływ na obsługę, łatwiej jest uzyskać 30 sekund niż 30 sekund.

— the-wabbit

CAŁKOWICO w porządku. Synchronizuję obrazy maszyn wirtualnych (bardzo małe dla węzłów obliczeniowych), które są wyłączone podczas synchronizacji. Aplikacja działa jak tar | ssh ale przy użyciu ftp. Cóż, symulacje muszą zostać uruchomione ... :)

— Peter Meyer,

Nie ma znaczenia, jaką są rasą SATA. Dyski firmowe 7200RPM po prostu nie mogą zagwarantować przepustowości ani opóźnień.

— adapttr

@adaptr, kopia zapasowa będzie zapisywać sekwencyjnie.

— psusi

Korzystanie z pamięci podręcznej pamięci może oznaczać utratę danych, ponieważ jeśli coś pójdzie nie tak, dane znajdujące się w pamięci i nie zapisane na dyskach zostaną utracone.

To powiedziawszy, należy dokonać strojenia na poziomie systemu plików.

Na przykład, jeśli korzystasz z ext4, możesz wypróbować opcję montowania:

bariera = 0

To: „wyłącza stosowanie barier zapisu w kodzie jbd. Bariery zapisu wymuszają prawidłowe porządkowanie zapisów dziennika na dysku, czyniąc bezpiecznym korzystanie z pamięci podręcznych zapisywania na dyskach, z pewnym spadkiem wydajności. Jeśli dyski są zasilane bateryjnie w jeden sposób lub inny, wyłączenie barier może bezpiecznie poprawić wydajność. Opcje montowania „bariera” i „nobarrier” mogą być również używane do włączania lub wyłączania barier, aby zachować spójność z innymi opcjami montowania ext4 ”.

Więcej na: http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt

— Peter Senna
źródło

Używam mocno zestrojonego XFS. Więcej na temat tego, co zostało dostrojone w powyższym komentarzu :)

— Peter Meyer

System plików został utworzony za pomocą mkfs.xfs -l lazy-count = 1, version = 2, size = 256m -i attr = 2 -d sunit = 512, swidth = 1024 i jest zamontowany z: rw, noatime, logbufs = 8, logbsize = 256k, osyncisdsync, delaylog, attr2, nobarrier, allocsize = 256k

— Peter Meyer