Boinc update #11 – wyścigi na GG@h CPU za 12 godzin

  1. GG@h NCI <- chodzi na bieżąco i automatycznie
  2. GG@h CPU:
    1. odpaliłem 4 zamiast 2 walidatorów bo robiły się opóźnienia
    2. zamiast 10 generatorów zadań w tej chwili chodzi jeden zoptymalizowany dając średnio 10 WU/s
    3. Apache2 ma podkręconą konfigurację <- czekającą tylko na jego restart w razie w potrzeby
    4. Sporo problemów miałem przez awaryjny restart mojego komputera na którym miałem puszczone generowanie zadań oraz ftp do projektu CPU <- przez co część plików zadań została przekopiowana na serwer ale nie usunięta z Nas4 (stacja dysków) <- teraz rsync walczy z przenoszeniem 50kk zadań na serwer projektu przez co dużo czasu traci generator zadań omijając dublujące się pliki

Za niecałe 12 godzin przekonam się jak bardzo wyścig da mi popalić i jak dobrze projekt jest przygotowany pod większą ilość komputerów.

Boinc update #10 – wyścigi na GG@h CPU

  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.

Boinc update #9

  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

Boinc update #8

  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.

Czytnik temperatury

Zmieniłem skrypt PHP odczytujący temperaturę z kitu avt5330 i zapisujący dane do bazy danych.

Skrypt pracuje już bez przerw od 3 dni dając wpis do bazy co 2 sekundy czyli dając ok.43,200 wpisów na dobę.

Czeka mnie jeszcze trochę pracy przy nim, ale w zasadzie jest gotowy i sprawny <- będzie chodził do testów tak długo jak będzie trzeba.

Boinc update #7

  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

Boinc update #6

  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

Boinc update #5

  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ć

Boinc update #4

  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ść

Boinc update #3

  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ą