Kategoria: Boinc

1. GG@h NCI : pracuje dobrze
2. GG@h CPU : idzie w porządku. W tej chwili przygotowuje projekt na wyścigi drużynowe of 15 marca do 20 marca. Pulę zadań gotowych do wysłania przestawiłem na 10kk i uruchomiłem 8 generatorów zadań. Teraz muszę czekać 48 godzin aż ilość tasków na serwerze.

1. GG@h CPU : wszystko na bieżąco, pracuję nad dwu etapowym generowaniem zadań tak jak przy NCI
2. GG@h NCI: nareszcie wszystko jest na bieżąco

1. GG@h CPU: dzięki ostatniej optymalizacji  analiza wyników v.1.0.6 została skończona, inaczej trwałą by jeszcze 3-4 dni, z kolei sprawdzanie plików z wersji v.2.0.0 odbywa się na bieżąco co mnie baardzo cieszy
2. GG@h NCI: no i tu jest niezła jazda. Po przeprowadzeniu „śledztwa” czyli przeglądnięciu logów projektu i systemu doszedłem do wniosku, że problemem są dotychczasowe analizatory wyników z małp a dokładniej mówiąc sama kwestia tworzenia tabeli tymczasowej, która blokowała wszystkie inne tabele przez co pozostałe demony wywalały się. Analizatory wyłączyłem na chwilę obecną.
3. GG@h NCI: ze względu na rosnące „backlog transmiter” uruchomiłem 4 transmitery zamiast jednego, dzięki temu zaległości demona zeszły do zera. Dopiero teraz widzę jaki bałagan był w plikach projektu i w bazie danych. W tej chwili trwa czyszczenie bazy danych z 3kk zbędnych wpisów w tabeli workunit i results oraz na dysku z 2kk zbędnych plików zadań i wyników.

1. GG@h CPU: dzięki kolejnej optymalizacji analizatora czasy przerobu jednego pliku spadły ze średnio 2,5 sekundy do 0,5 sekundy.  Zamiast tworzyć i korzystać z tabeli tymczasowej z nazwą usera i wyniku, trzymam potrzebne dane a tablicy w pamięci przez co wszystko jest szybsze i odciąża sieć oraz bazę danych <- dane z projektu spływają na bieżąco, a ze starego v1.0.6 pozostało mi już tylko 1kk tasków do wrzucenia do bazy
2. GG@h NCI: zaległości w zasadzie odrobione bo w sumie razem z bieżącymi zostało tylko 250k wyników do sprawdzenia co jest niczym. W przyszłym tygodniu muszę wprowadzić podobne rozwiązanie do analizatorów jak w GG@h CPU czyli dane trzymać w tablicy a nie w tabeli w bazie
3. GG@h NCI: Pojawił się oczywiście inny problem… projekt nie nadąża z dodawaniem zadań z serwera dysków do bazy co jest cholernie dziwne. Możliwe, że to przez analizowanie plików z htest_64bits ze starej wersji 1.0.6 <- zobaczymy czy sytuacja się unormuje po wszystkim

1. Zawsze kurwa coś musi się zjebać… no bo po mam mieć cisze i spokój. GG@h NCI miał spore załamanie i sporo konsekwencje ponieważ musiałem anulować wszystkie aktualne zadania w bazie danych czyli ok.3kk pozycji oraz do kasacji poszło także 5kk zapasowych zadań ze stacji dysków bo zrypała się templatka XML
2. Na NAS’ie rozpocząłem generowanie nowych serii zadań dla monkeys’ów
3. Po zmianach w analizatorze htest_64bits v2000 prace posuwają się o wiele szybciej, a dla v1060 pozostało już tylko 1,5kk zadań do wrzucenia do bazy
4. Zaległości na GG@h NCI też zaczynają ładnie schodzić… ale to zapewne przez załamanie serwera i brak nowych wyników przez ostatnie 36 godzin, a nie przez to, że skrypty działają lepiej

 

Ogólnie mam porządnego wkórwa…. nie lubię jeśli coś się wypierdziela nie z mojej winy

1. Serwer GG@h NCI ruszył, na razie na zwolnionych obrotach z powodu testów jakie działają w tle. Trochę stress testów itp na szczęście wystarczyło podpiąć dysk z projektem i wszystko ruszyło w miarę dobrze.
2. Z zaległości z małpek zaczynam się powoli odkopywać <- w zasadzie skrypty zliczające ilość plików jakie są w kolejce dały poważnie ciała i w zasadzie żaden nie podawał prawidłowych ilości… w jednej z funkcji był mały błąd, który  nie miał znaczenia jeśli w katalogu było mniej niż 500k plików, a tyle zazwyczaj było. Linuksowe polecenia z linii komend wykazują 6kk wyników do analizy, a nie 1kk jak mówiły mi moje skrypty
3. Przybywa w kolejce wyników do analizy z htest_64bits <- dzięki zrobionym logom wiem dokładnie co zajmuje najwięcej czasu i przez co te opóźnienia, dlatego jutro postaram się coś na to zaradzić

1. Kolejki wyników powoli się zmniejszają się  co jest dobrą wiadomością
2. Serwer GG@h NCI umarł… padła płyta główna, ramy i procesor, właśnie biorę się za rozwiązanie tego problemu <- i to jest ta zła wiadomość

1. GG@h CPU : analizatory (1x V2000 + 4x V1060 ) zaczynają dawać rady. W tej chwili kolejka plików do sprawdzenia spadła do 2,2kk <- wyników w sumie ze starych z wersji 1.0.6 jak i nowych z wersji 2.0.0
2. GG@h NCI: 4 analizatory (puszczone osobno dla każdej z aplikacji ) robią co mogą i jeszcze dobre3-4 dni będę się pocić. Po nocnych zmianach i rezygnacji z tymczasowego bufora plików na dysku lokalnym wszystko przyśpieszyło, co oznacza, że dysk umiera…. ale z drugiej strony diodka od aktualności sieci w laptopie nie przestaje gasnąć <- coś za coś
3. Macierz dyskowa pracuje 6 skryptami sortując katalogi z plikami wynikowymi z GG@h NCI tak, aby w katalogach nie było 5kk plików tylko 1kk co przyśpieszyło pracę na komputerze sprawdzającym
4. Zarówno dla NCI jak i CPU pozbyłem się kolejek lokalnych zarówno dla plików do analizy jak i tych czekających na archiwizację <- co w razie śmierci dysku jest bardzo dobrą wiadomością

 

1. Komputer  analizujący dostał spooorej zadyszki…  po wyłączeniu wszelkich skryptów działających w tle i odpaleniu SMART’a mogę uznać, że ten dysk jest w zasadzie martwy <- nie wspominając o odgłosach jakie zaczął wydawać
2. W nawiązaniu do pkt.1 zmieniłem skrypty wszystkie analizujące aby pobierały pliki do sprawdzenia bezpośrednio z macierzy dyskowej i od razu wrzucały je z powrotem na macierz <- etap tymczasowego przechowywania danych na dysku w kompie pomocniczym wyleciał… jest za duże ryzyko utraty danych.
3. Jutro rozglądnie się za możliwością podpięcia pod ten sprzęt dysku SSD, a podobno można to zrobić za pomocą specjalnego konektora… tylko czy opłacać sią kupować dysk SSD skoro notabene dysk i tab będzie podpięty pod ATA. Drugim pomysłem do sprawdzenia jest podpięcie nowego dysku (w sensie jakiegoś z zapasowych leżących na półce) w kieszeni pod USB tak jak to mam w drugiej testowej maszynie. Teoretycznie wydajność byłaby trochę marna, ale skoro dysk nie będzie przechowywał i obracał gigami danych na godzinę to może być nawet dobre rozwiązanie.
4. Aktualne kolejki do analizy to: (oczywiście przez te zaległości obrywa się bazie danych z wynikami… ok.75% plików pozostawia swój wpis w bazie)
   1. GG@h NCI : 12kk plików <- w sensie 12 milionów plików na macierzy i 2 miliony do wysłania na nią
   2. GG@h CPU: 1 milion (1kk) plików do analizy i 10k do przesłania do archiwum na macierzy

1. GG@h NCI ma się dobrze, choć zaległości nie zmniejszają się, a wręcz rosną <- wychodzi, ze teraz jest tego ok.10kk plików.. dramat.
2. GG@h CPU już ma się dobrze <- zapomniałem, ze na stacji dysków przenosiłem katalogi NFS z jednego wolumenu na drugi przez co nei przepiąłem katalogów na komputerach, które ich używają. W tej chwili sytuacja opanowana, zaległość wynosi  375k plików do analizy, ale do rana powinno zejść.
3. GG@h CPOU, ze względu na ilość spływających wyników musiałem uruchomić drugi walidator, żeby nie robić zbyt dużych kolejek. Ciekawe co będzie przy kilku tysiącach hostów, albo co lepsze przy okazji projektów miesiąca lub wyścigów… nawet nie chce o tym myśleć
4. Z przykrością stwierdzam, że mój komputer analizujący dane, generujący zadania itp/itd doszedł do granic swojej wydajności <- jak w większości takich przypadków uchem igielnym jest… tadam… dysk <- nie dość, że na interfejsie ATA (który jest już tylko w muzeach) to jeszcze ma 5400obr i w zasadzie zachowuje się jakby miał zaraz umrzeć.  Muszę sprawdzić czy mogę tam wrzucić dysk SSD na SATA zamiast DVD