Strategia masowego przechowywania małych plików

Question

Jaka jest dobra strategia dla pamięci masowej dla milionów małych plików (średnio około 50 KB) z funkcją automatycznego przycinania plików starszych niż 20 minut? Muszę pisać i uzyskiwać do nich dostęp z serwera WWW.

Obecnie używam ext4, a podczas usuwania (zaplanowany w cron) wzrost użycia dysku HDD do 100% z [flush-8: 0] pokazujący się jako proces, który tworzy ładunek. Obciążenie to koliduje z innymi aplikacjami na serwerze. Gdy nie ma żadnych usunięć, maksymalne wykorzystanie HDD wynosi 0-5%. Sytuacja jest taka sama w przypadku zagnieżdżonych i nie zagnieżdżonych struktur katalogów. Najgorsze jest to, że wydaje się, że usuwanie masy podczas obciążenia szczytowego jest wolniejsze niż tempo wstawiania, więc ilość plików, które trzeba usunąć, rośnie i rośnie.

Próbowałem zmienić harmonogramy (deadline, cfq, noop), to nie pomogło. Próbowałem też ustawić jonice do usuwania skryptu, ale to też nie pomogło.

Próbowałem GridFS z MongoDB 2.4.3 i działa ładnie, ale strasznie podczas masowego usuwania starych plików. Próbowałem uruchomić MongoDB z wyłączonym księgowaniem (nojournal) i bez potwierdzenia zapisu dla usunięcia i wstawienia (w = 0) i to nie pomogło. Działa tylko szybko i gładko, gdy nie ma żadnych operacji usuwania.

Próbowałem również przechowywanie danych w MySQL 5.5, w kolumnie BLOB w tabeli InnoDB, z zestawem silnika InnoDB użyć innodb_buffer_pool = 2GB, innodb_log_file_size = 1GB, innodb_flush_log_on_trx_commit = 2, ale perfomance było gorsze, obciążenie HDD był zawsze na 80% -100% (oczekiwano, ale musiałem spróbować). Tabela wykorzystywała tylko kolumnę BLOB, kolumnę DATETIME i CHAR (32) latin__bin UUID, z indeksami na kolumnach UUID i DATETIME, więc nie było miejsca na optymalizację, a wszystkie zapytania używały indeksów.

Zajrzałem do ustawień pdflush (proces płukania Linuksa, który tworzy ładunek podczas usuwania masy), ale zmiana wartości nic nie pomogła, więc przywróciłem ustawienia domyślne.

Nie ma znaczenia, jak często uruchamiam skrypt automatycznego przycinania, co 1 sekundę, co 1 minutę, co 5 minut, co 30 minut, zakłóca to znacząco serwer w obu kierunkach.

Próbowałem przechowywać wartość i-węzła, a podczas usuwania, usuwać stare pliki sekwencyjnie, najpierw sortując je z numerami i-węzłów, ale to nie pomogło.

Korzystanie CentOS 6. HDD jest SSD RAID 1.

Co byłoby dobre i rozsądne rozwiązanie dla mojego zadania, które rozwiąże automatycznego przycinania problem z wydajnością?

Answer 1

Usunięcia są nieprzyjemne, ponieważ zarówno dane, jak i metadane muszą zostać zniszczone na dysku.

Czy naprawdę muszą być oddzielnymi plikami? Czy stare pliki naprawdę muszą zostać usunięte, czy jest to w porządku, jeśli zostaną nadpisane?

Jeśli odpowiedź brzmi „nie” do drugiego z tych pytań, spróbuj tego:

• przechowywać listę plików, które z grubsza posortowanych według wieku. Może poróżnić go według rozmiaru pliku.
• Jeśli chcesz napisać do nowego pliku, znajdź stary plik, który jest lepszy niż ten, który zastępujesz. Zamiast wysuwać stary plik, należy go ustawić na odpowiednią długość, a następnie nadpisać jego zawartość. Upewnij się, że aktualizujesz listę starych plików.
• Porządkuj naprawdę stare rzeczy, które nie zostały zastąpione jawnie od czasu do czasu.
• Może być korzystne posiadanie indeksu do tych plików. Spróbuj użyć tmpfs pełnego dowiązań symbolicznych do rzeczywistego systemu plików.

Użytkownik może uzyskać lub nie uzyskać przewagę wydajności w tym schemacie, dzieląc pliki na podfoldery o odpowiednich rozmiarach.

Jeśli jesteś OK z wielu rzeczy są w tym samym pliku:

• przechowywać plików o podobnych rozmiarach wraz przechowując każdy jako przesunięcie na tablicę podobnie wielkości plików. Jeśli każdy plik ma 32k lub 64k, zachowaj plik pełen 32k porcji i plik pełen 64k porcji. Jeśli pliki mają arbitralne rozmiary, zaokrąglaj do następnej potęgi dwóch.
• Lazy można usuwać tutaj, śledząc, jak nieaktualny jest każdy plik. Jeśli próbujesz pisać i coś jest nieaktualne, zastąp go, zamiast dołączać na końcu pliku.

Inna myśl: Czy masz przewagę wydajności przez truncate() ing wszystkich plików do długości 0 w celu węzła, a następnie unlink() je ing? Ignorancja powstrzymuje mnie przed stwierdzeniem, czy to może pomóc, ale wydaje się, że zachowałoby zerowanie danych i metadane pisane podobnie.

Jeszcze jedna myśl: XFS ma słabszy model zamawiania zapisu niż ext4 z data=ordered. Czy jest wystarczająco szybki na XFS?

Answer 2

Jeśli masowe usuwanie milionów plików powoduje problem z wydajnością, możesz rozwiązać ten problem przez "usunięcie" wszystkich plików naraz. Zamiast używać dowolnej operacji na systemie plików (jak "usuń" lub "skróć") możesz po prostu stworzyć nowy (pusty) system plików zamiast starego.

Aby zaimplementować tę koncepcję, musisz podzielić dysk na dwie (lub więcej) partycje. Po zapełnieniu jednej partycji (lub po 20 minutach) zaczynasz pisać na drugiej partycji, używając pierwszej partycji tylko do odczytu. Po kolejnych 20 minutach odmontujesz pierwszą partycję, utworzysz pusty system plików, zamontujesz ją ponownie, a następnie zaczniesz pisać do pierwszej partycji, a drugą do czytania.

Najprostszym rozwiązaniem jest użycie tylko dwóch partycji. Ale w ten sposób nie wykorzystujesz bardzo wydajnie miejsca na dysku: możesz przechowywać dwa razy mniej plików na tym samym dysku. Dzięki większej liczbie partycji możesz zwiększyć wydajność przestrzeni.

Jeśli z jakiegoś powodu potrzebujesz wszystkich plików w jednym miejscu, użyj tmpfs, aby przechowywać linki do plików na każdej partycji. Wymaga to masowego usuwania milionów linków z tmpfs, ale to zmniejsza problem z wydajnością, ponieważ tylko łącza powinny zostać usunięte, a nie zawartość plików; również te linki mają być usunięte tylko z pamięci RAM, a nie z SSD.