Miesiąc: marzec 2018

Opublikowane w

Nasik4 update #1

Nasik4 to mój główny serwer dyskowy jakby się ktoś pytał 😉

Jako, że trochę minęło od ostatnich upgrejdów w dockerach postanowiłem uruchomić nowe wersje tych kontenerów których mogę.

  1. Redis z wersji 4.0.2 na 4.0.8
  2. Scm-manager z 1.38 na 1.57
  3. ownCloud z 10.0.0 na 10.0.7
  4. gitLab z 10.2.2 na 10.2.2 😀 <- chciałem zainstalować wersje 10.4.4 lub 10.5.1 ale nie przechodzi konwersja bazy danych. Na razie temat odstawiam, ponieważ dość się na stresowałem z przywracaniem wersji do działającej 10.2.2

została mi jeszcze MariaDB ale na chwilę obecną za dużo się na niej dzieje abym mógł ją wyłączyć.

Opublikowane w

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.

Opublikowane 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.
Opublikowane w

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
Opublikowane w

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.
Opublikowane 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.

Opublikowane w

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