Uruchomienie polecenia du DROGA trwa zbyt długo

Korzystam du -shz różnych katalogów, aby znaleźć wieprze dyskowe. Mam dwa identyczne serwery (Dell PE2850), oba z RHEL5 i znacznie dłużej będzie działać duna jednym serwerze na drugim.

Na przykład wykonanie du -sh /opt/foobartego zajmie 5 minut na serwerze A (który ma około 25 GB), a na serwerze B to samo polecenie z taką samą ilością danych zgłosi się do mnie niemal natychmiast. Nie widzę nic rażąco oczywistego podczas biegania na górze itp.

Wszelkie porady są mile widziane.

— Jon Weinraub
źródło

Szybkość du -snie zależy od wielkości danych, ale raczej od liczby plików. Czy oba drzewa katalogów mają podobną liczbę plików?

— Ladadadada,

Ponadto, dubędzie działać znacznie szybciej, jeśli wszystkie dane meta katalog (jak rozmiary plików) jest aktualnie buforowane. Jeśli tak jest z jakiegokolwiek powodu na jednym serwerze, a nie na drugim, spowoduje to duże różnice.

— Sven

@Ladadada Powiedziałbym, że tak, jest mniej więcej taka sama liczba plików. Nawet po dodaniu gwiazdki, aby uzyskać osobną listę rozmiarów plików, przewijanie zajmuje dużo czasu. Ale nie jestem całkowicie pewien, jak sprawdzić, czy metadane są buforowane, czy nie.

— Jon Weinraub,

Odpowiedzi:

Jeśli w tym katalogu znajduje się ogromna liczba plików, a zawartość katalogu ciągle się zmienia, sam wpis katalogu ulega z czasem fragmentacji. Następnie, gdy system operacyjny odczytuje zawartość katalogu, będzie wiele niepotrzebnych operacji na dysku. Dzieje się tak zwłaszcza w przypadku systemów plików ext * (ext4 może być lepszy) i starych systemów plików ReiserFS v3.x (jeśli zostały one wypełnione w około 85%).

Rozwiązanie jest dość łatwe:

cp -pr origdir newdir
mv origdir origdir.bak
mv newdir origdir

Oczywiście, jeśli wszystko jest buforowane w pamięci RAM, nie ma to większego znaczenia; zwykle Linux buforuje często używane pliki i katalogi dość agresywnie. Jeśli naprawdę chcesz zachować zawartość tych katalogów w pamięci RAM, możesz umieścić coś podobnego ls -lah /your/dir 2>&1 >/dev/nulldo swojego crona.

EDYCJA: Och, jedna rzecz przyszła mi do głowy. Jeśli na serwerze znajduje się kontroler RAID z podtrzymaniem bateryjnym i pamięcią podręczną, sprawdź, czy bateria jest w porządku. Widziałem sytuacje, w których bateria jest wyczerpana, a kontroler całkowicie wyłącza pamięć podręczną, co bardzo psuje wydajność. Na przykład serwery HP mogą powiedzieć w dziennikach iLO coś o baterii kontrolera; w panelu kontrolnym aktualnego stanu serwera wszystko wydaje się być w porządku i zielone, ale tylko wpis dziennika powie ci o tym.

— Janne Pikkarainen
źródło

To prawdopodobnie zajmie mi trochę czasu, jest na serwerze produkcyjnym, więc będę musiał to zrobić przez noc, a cały katalog zawiera kilkaset gigabajtów danych, więc nie chcę tego robić ... pierwsza rzecz jutro rano. Dzięki za pomysł.

— Jon Weinraub,

Nadal uruchamiam to polecenie i nie wiem, ile to zajmie. Nawet go ponownie przygotowałem i procesor wciąż działa, około 1 godziny 15 minut od uruchomienia. Nawet uruchomienie du w tym folderze w innej powłoce zajęło dużo czasu, ale myślisz, że powinienem tylko umountdysk i fsckto?

— Jon Weinraub,

Po prostu pozwól mu działać, chyba że w jakiś sposób przeszkadza twojej produkcji. Za pomocą RHEL5 i jego domyślnego harmonogramu we / wy CFQ możesz umieścić komendę cp w klasie bezczynności, aby nie nękać innych procesów: ionice -c3 -p $(pidof cp)i tak dalej.

— Janne Pikkarainen,

Przeczytaj także moją najnowszą edycję.

— Janne Pikkarainen,

Wiem, że minęło trochę czasu, ale w końcu udało mi się wykonać polecenie cp, o którym wspominałeś. Dwie dwie godziny na skopiowanie 25 GB. Po wykonaniu ruchu, kolejny du -sh był równie powolny. W rzeczywistości nawet usuwanie katalogu kopii zapasowej jest również powolne!

— Jon Weinraub,

Proponuję wypróbować proste polecenie du bez żadnych przełączników. W końcu zobaczysz, który katalog spowalnia proces. Może to być wadliwy dysk lub inny powód ...

— Király István
źródło