Kategoria: Boinc

Po dziesiątkach godzin spędzonych na testach, analizach logów itp….
Nowy serwer został przeinstalowany od zera jakoś 5 razy i udało mnie się uruchomić na nim zarówno GoofyxGrid@home NCI i CPU jednocześnie.

Ostatnie 3-4 dni oba projekty były w zasadzie martwe przez te całe przenosiny, ale może teraz znowu będzie spokojniejszy okres.
Na chwilę obecną po ostatnich konfigach oba projekty działają ponad 2 godziny bez przerw…
czyżby sukces? Czas pokaże.

1. GG@h NCI <- łazi ok
2. GG@h CPU <- po licznych testach serwera, czytaniu licznych forów i konsultacjach z ludźmi stwierdzam, że problemem jest fakt przeniesienia na żywca dysku z systemem ze starego kompa na nowy sprzęt. Wniosek jest jeden i to bolesny… muszę postawić serwer od zera…. dlaczego jest to bolesne? Bo nigdy nie wiadomo czy coś się nie porąbie na nowej wersji źródeł serwera boinc <- a niestety przechodzę tego typu niespodzianki za każdą przesiadką na nowszą wersję.

1. GG@h NCI – jest ok
2. GG@h CPU – już chyba 3 raz po kolejnych 2 dniach serwer po prostu zamarł. Logi nie wykazują kompletnie błędów… jednak dziwi mnie kilka komunikatów związanych z MySql.

1. GG@h NCI – chodzi dobrze
2. GG@h CPU – chodzi dobrze

 

Aż miło mieć tylko tyle do powiedzenia 🙂 <- to oznacza, że kolejnych przejściach mam czas na inne projekty.

1. GG@h NCI <- inode przywrócone po usunięciu 28kk zbędnych plików md5 z download za pomocą skryptu md5Deleter
2. GG@h CPU <-tu też odzyskałem inode 5kk z plików md5 po uruchomieniu tego samego skryptu php. Uruchomiłem 4x db_purge zamiast jednego, który nie wyrabiał z usuwaniem starych wpisów.

 

1. GG@h NCI <- zaliczył kilka zgonów ciągu ostatniej doby. Skończyły się Inody na dysku. Z tego co sprawdzałem, to powodem jest zbędne pozostawianie plików md5 dla zadań które zostały już skasowane z katalogu download <- muszę zrobić skrypt do ich automatycznego kasowania
2. GG@h CPU – wyścig ma się ku końcowi… jeszcze tylko ok.15-16 godzin. Po godzinach spędzonych na testach na rożnych sprzętach i środowiskach stwierdzam, ze powodem 75% problemów jest ilość operacji jakie projekt musi robić na bazie danych. Od tej pory wszelkie nowe zadania jakie będą w kolejce zapasowej będą 5-6 razy dłuższe czyli na ok.15-20 minut dla aplikacji 64bity a nie tak jak dotychczas na 2-3 minuty.

1. GG@h NCI <- bez zmian, ma się dobrze
2. GG@h CPU… jeden wielki DRAMAT. W skrócie mówiąc ze względu na fakt, że w zasadzie serwer więcej czasu leżał i umierał z powodu dużego obciążania musiałem kupić nowy sprzęt. W tej chwili cały serwer przystosowuje do nowego środowiska: cpu i7-7700 + chłodzenie spc145, 32gb ram, 2x SSD samsung 850 evo 500gb, mobo msi h110m pro-vd plus i zasilacz Vero L2 500W. Nienawidzę takich nieplanowanych zakupów, ale z drugiej strony miałem na niego odłożone od ponad roku i nie miałem motywacji aby zrobić wymianę… no cóż potrzeba jest matką motywacji. W tej chwili przenoszę katalog projektu na drugi dysk tak aby na jednym był system i baza danych, a na drugim on sam.

1. GG@h NCI – działa automatycznie
2. GG@h CPU – działa dobrze. W wyścigu bierze udział mniej hostów niż liczyłem, ale nie narzekam. O ile mam 25ogiga wolnego miejsca o tyle zużycie Inodów mam na poziomie 99-100% co nie jest dobre, ale przynajmniej sytuacja jest stabilna. Wyścigi potrwają do 20 marca do 24:00

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.