Linux z 256 GB pamięci / 48 rdzeni - maszyna zaczyna bić / dusić się z resztkami pamięci

12

Maszyna: Dell r815, CentOS 5.4, 256 GB pamięci RAM, 4 x 12 rdzeni.

Mamy aplikację, która ma plik 275 GB. Wykonuje sortowanie na miejscu na 20 GB danych naraz, tzn. Zamienia bity i zamienia je w tym samym pliku. To wszystko działa dobrze.

Jest ostatnie przejście, które następnie odczytuje cały plik i sortuje scalanie dla różnych porcji 20 GB i wysyła je do całego nowego pliku.

Ten proces wydaje się działać przez pewien czas i kończy się wypłukaniem około 50 GB na dysk. Jakiś czas później CAŁA maszyna zaczyna wariować.

Proste polecenia, takie jak ps -ef, ls -alzawieszają się przez długi czas i pokazują się jako wymagające 100% procesora (co jest tylko jednym rdzeniem).

Patrząc na statystyki pamięci top, widzę, że zużywa około 120 GB pamięci RAM (więc 128 GB wolnego) i ma 120 GB w sekcji „buforowanej”.

Czy ktoś widział takie zachowanie wcześniej? Ten sam proces działa dobrze na komputerze z 64 GB pamięci - więc myślę, że ma to związek z mocowaniem pamięci RAM, którą mam na komputerze.

(jak mówimy, uruchamiam test na tym komputerze ze wszystkim oprócz 64 GB - aby wykluczyć problem ze sprzętem).

Czy może brakuje mi par vm /etc/sysctrl.conf?

Dzięki!

linux centos memory

— aspitzer
źródło

Co robią dyski .. Idziesz do piekła wymiany ????

— Arenstar,

64-bitowe jądro / aplikacja / etc? wspomniałeś 100% procesora, jaka jest średnia obciążeń, kiedy to się dzieje, jest to aplikacja wielowątkowa (nie użyje wszystkich procesorów, jeśli nie), co mówi ci vmstat 4 (konkretnie io / cpu)

— coredump

takie jak „ps” są w 100% cpu nie ma 4800% (bo 48 rdzeni) - więc najprawdopodobniej są blokowane przez io lub coś w tym rodzaju. średnia obciążenia na pudełku wynosi tylko 5. dyski, które są w stanie stałym, nie widzą dużo zapisów ... Wydaje się, że to bardziej problem z jądrem niż zasobami

— aspitzer,

maszyna w ogóle się nie zamienia.

— aspitzer,

1

tak .. teraz działa z 64 GB. powinien wiedzieć w ciągu godziny, czy ma to związek z całkowitą ilością pamięci w maszynie

— aspitzer,

12

Twoje pytanie przypomniało mi coś, co ostatnio przeczytałem:

http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/

Rozwiązuje to wpływ architektury NUMA (np. 48-rdzeniowego systemu AMD) na alokację i zamianę pamięci. Nie wiem, czy na to się natrafisz, ale brzmiało to na tyle podobnie, że warto je przeczytać.

Nawet jeśli nie jest to odpowiedź, która stanowi fascynującą lekturę.

— Larsks
źródło

1

To wydaje się godne ujęcia problemu tego pytania. I to jest fantastyczna lektura.

— coredump

1

To świetny odczyt i 4 gniazda, 256 GB pamięci RAM = 64 GB na węzeł, i wydaje się, że właśnie tam masz problemy, co dokładnie odwzorowuje sytuację w dokumencie.

— Mark Henderson

12

Wygląda to na błąd jądra w 64-bitowym Centos 5.4 i 64-bitowym Fedorze 14. Po zainstalowaniu Centos 5.5 problem zniknął.

Przepraszam, nie mam lepszej odpowiedzi dla wszystkich ...

— aspitzer
źródło

1

Hej, człowieku, jeśli to to naprawiło, właśnie to naprawiło. Daj sobie zaznaczenie, aby inni mogli uczyć się na twoich trudnościach :-)

— mfinni

0

Możesz spróbować dodać linię do /etc/sysctl.conf, aby określić, że zamiana ma być używana tylko wtedy, gdy jest to absolutnie konieczne.

zamiana = 0

Być może już wiesz, że ten plik określa ustawienia globalne, więc należy wziąć pod uwagę wpływ, jaki ta zmiana będzie miała na pozostałe aplikacje działające w środowisku.

— NginUS
źródło

to jest już ustawione ... ale jak wspomniałem, 128 GB jest za darmo - więc nie ma problemów z zamianą.

— aspitzer,

0

Gdzie jest twoja temp. Często jest to na tempfs. Tempfs pobiera to miejsce z pamięci utworzonej przez przestrzeń wymiany, więc jeśli skończy się zbyt wiele rzeczy w tempfs, uruchomi to we / wy wymiany.

Biorąc pod uwagę rozmiar danych, które scalasz, oczekiwałbym swapowości po ostatecznym scaleniu.

Rozłożenie magazynu wymiany na wiele dysków może pomóc.

— BillThor
źródło

0

Chociaż możesz nie uzyskiwać wymiany, nadal możesz być związany z operacjami we / wy. Informacja ls to sugeruje.

Chciałbym spojrzeć na dane wyjściowe, dstat -dfaby wyświetlić statystyki dysku, lub dstat -af(tak, będzie to bajillion szerokości kolumn; to dzieje się, gdy masz 48 rdzeni i pokazuje wykorzystanie procesora na wszystkich z nich), jeśli chcesz zobaczyć wszystko.

Byłbym zaskoczony, gdyby wszystkie procesory były zajęte (sortowanie korespondencji seryjnej nie jest zadaniem intensywnie obciążającym procesor), ale nic nie mówisz o swoim systemie I / O. Jeśli masz kilka dysków i kilka plików, możesz zepsuć dysk, szukając każdego pliku, aby mieć pewność, że sortowanie korespondencji seryjnej jest zasilane.

— Slartibartfast
źródło