Wydajność maszyny spada z czasem do ponownego uruchomienia


2

Mam trochę dziwny problem z moimi maszynami:

Z czasem wydajność stale spada.

Używam TensorFlow do trenowania sieci neuronowej za pomocą GPU. Moje dane to skompresowane xz tablice float32, które znajdują się na dysku wirującym na jednym komputerze i na dysku SSD na innym komputerze. Istnieje około 400 000 plików danych. Pliki danych są odczytywane w sposób ciągły w wątkach w tle i umieszczane w kolejce, która może mieć maksymalnie 1000 pozycji.

W wątku szkoleniowym przedmioty są wyskakujące z przodu kolejki i przekazywane do treningu partiami po 200.

Po ponownym uruchomieniu wydajność zaczyna się od około 4 sekund na partię. Po kilku godzinach treningu wydajność spada do zaledwie 16 sekund na partię.

Treningi przeprowadziłem nieco szczegółowo, a na początku jest coś takiego:

  • 0,05 s czeka na odczyt danych treningowych
  • 3.8s dla przetwarzania partii na GPU
  • 0,3 s do zapisu danych podsumowujących.

Po treningu czasy są bardzo zmienne:

  • 0,5 i 4 s do odczytu danych
  • 9 do 20 s na przetworzenie partii
  • 0,3 s do zapisu danych podsumowujących

Należy zauważyć, że podczas przetwarzania wsadowego monitorowałem wyjście nvidia-smi z dość wysokim interwałem i wydaje się, że wykorzystanie GPU trwa najwyżej 1 sekundę.

Ta zła wydajność utrzymuje się podczas wielokrotnych wywołań procesu szkolenia oraz po wylogowaniu i zalogowaniu się. Ponowne uruchomienie komputera przywraca pierwotne czasy.

Od tego pytania nabyłem inny procesor graficzny (GTX 1080) i skonfigurowałem prawie identyczny system. Spowolnienie ma miejsce również na nowej maszynie.

Rzeczy, których próbowałem

Sprawdziłem użycie procesora i co najwyżej 1 procesor jest wykorzystywany, i zawsze jest używany na 100%, przez większość czasu jest to wykorzystanie wątku jądra.

Sprawdziłem użycie pamięci i jest to 10 GB (z 11 GB). Jest to trochę ciasne, ale system nie rozpoczyna wymiany (swap pozostaje na poziomie 30 MB).

Sprawdziłem użycie dysku i poza kodem odczytującym dane wydaje się, że nie dzieje się nic dziwnego.

Sprawdziłem temperaturę GPU za pomocą nvidia-smi i zawsze utrzymuje się poniżej 60 ° C.

Sprawdziłem temperaturę procesora i płyty głównej i zawsze pozostają one poniżej 65 ° C.

Skończyły mi się pomysły na problem. Jakieś pomysły?

Okular

System 1:

  • Intel (R) Core (TM) i7 930 @ 2.80GHz, 4 rdzenie z Hyperthreading
  • 11 GB pamięci RAM
  • NVIDIA GeForce GTX 960 z 4 GB pamięci VRAM
  • Ubuntu 16.04.1 LTS Server, architektura amd64
  • Zastrzeżony sterownik NVIDIA, wersja 361.42
  • Wersja jądra 4.4.0-31-generic
  • Python 3.5.2
  • TensorFlow 0.9.0

System 2:

  • Intel (R) Core (TM) i7 930 @ 2.80GHz, 4 rdzenie z Hyperthreading
  • 11 GB pamięci RAM
  • NVIDIA GeForce GTX 1080 z 8 GB VRAM
  • Ubuntu 16.04.1 LTS Server, architektura amd64
  • Zastrzeżony sterownik NVIDIA, wersja 367.35
  • Wersja jądra 4.4.0-31-generic
  • Python 3.5.2
  • TensorFlow 0.9.0

Aktualizacja

Po kilku dalszych testach wydaje się, że powolność jest niestabilna. Czasami partie są przetwarzane 10 razy wolniej niż w najlepszym przypadku, ale potem wraca do normy.

I performed an strace on the process. The summary is this:
strace: Process 7351 attached
strace: Process 7351 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 95.40    0.674470         437      1545       126 futex
  4.37    0.030860        2572        12           munmap
  0.23    0.001627         814         2           madvise
  0.00    0.000000           0        13           write
  0.00    0.000000           0        10           mmap
  0.00    0.000000           0         1           access
------ ----------- ----------- --------- --------- ----------------
100.00    0.706957                  1583       126 total

Wygląda to jednak bardzo podobnie, gdy wszystko wydaje się działać normalnie. Szczegółowo przesłałem tutaj plik śledzenia:

https://drive.google.com/open?id=0B8TdHRNT7E-0X3F4eF9xWlRsb2s

O ile wiem, prawie wszystkie te wywołania systemowe są wywołaniami futex. Nie jestem pewien, czego się z tego nauczyć.


Myślę, że powinieneś strace / profil, znaleźć funkcję wąskiego gardła i wrócić tutaj z wynikami. Inna opcja - restartuj usługi jeden po drugim, ponownie


Degradacja w czasie przypomina wyciek pamięci. Jedenaście gigabajtów pamięci RAM wydaje się dziwną konfiguracją sprzętową. Warto przetestować bardziej typową kombinację kart pamięci. Ale z zastrzeżeniem, które po prostu czuję.
ben rudgers

@benrudgers: Układ pamięci to 6 razy 2048 MB pamięci, które w jakiś sposób sumują się do 11 GB w Linuksie. Nie sądzę, że jest to wyciek pamięci, ponieważ użycie pamięci systemowej pozostaje niskie. Ponadto, dlaczego wycieki pamięci utrzymywałyby się po śmierci wszystkich procesów?
fat-lobyte

Przepływają i wyłączają dane z GPU, które są kontrolowane na poziomie jądra. Błąd w sterowniku może to wyjaśnić. W każdym razie warto uruchomić, sudo dmidecode --type memoryaby sprawdzić, czy w pamięci RAM jest coś dziwnego. Prawdopodobnie warto wypróbować także inny sterownik GPU, tj. Przejście z oprogramowania typu open source na własny lub odwrotnie lub uruchomienie najnowszego, największego ze startera. Zawsze można zgłosić błąd na Github.
ben rudgers

Odpowiedzi:


1

Na razie mój problem wydaje się złagodzony.

Zrobiłem to, instalując libgoogle-perftools-devpakiet i rozpoczynając każde uruchomienie od:

LD_PRELOAD="/usr/lib/libmalloc.so"

To gwarantuje znacznie bardziej stabilny występ i od tego czasu nie miałem spowolnienia.

Najwyraźniej więc przydzielającemu GLIBC trudno jest zbierać śmieci przez dłuższy czas.

Co do tego, dlaczego mój problem zdawał się utrzymywać wśród wywołań: nie wiem. Istnieje pewna szansa, że ​​źle zinterpretowałem moje wyniki i że procesy zwolniły niezależnie od siebie.

Tak czy inaczej, uruchamiając mój kod przez ponad tydzień z nowym alokatorem i nie mając ani jednego spowolnienia, nazwałbym ten problem rozwiązany.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.