Kategoria: GoofyxGrid@home NCI

1. wreszcie dopasowałem rozmiar partycji do wielkości dysku SSD <- partycje miały ok.23GB, dysk 500GB. Teraz mam 270GB wolnego, a nie 50GB
2. uruchomiłem swapa dla systemu
3. zrobiłem przy okazji kopię zapasową całego dysku

O ile przez lata przyzwyczaiłem się do tego jak tunningować apache2 pod kątem obsługi dużej ilości połączeń, to sprawa używania php-mpm pool’a, który właśnie dał mi dość ostro popalić… a właściwie to on od 3-4 miesięcy daje mi popalić a nie synology reverse proxy czy wydajność apache2. Sama zmiana konfiguracji serwera www nie wystarczała skoro uchem igielnym był domyślny konfig pooli php-mph. Po podciągnięciu podstawowych parametrów o jakieś 500% wszystko na razie wygląda dobrze 🙂

Eh, nigdy nie ma tak żeby wszystko po prostu działało, bo zawsze jakieś gówno się pojawi.

Znowu mam powrót do problemów z komunikacją pomiędzy nginx (reverse proxy) a serwerem apache2 na projekcie NCI… najprawdopodniej ten drugi znowu szwankuje…

1. server_status.php <- pokazuje także ile zapasowych zadań jest u mnie na serwerze domowym (tu oczywiście pracuje u mnie w tle skrypt zliczający)
2. index.php <- zaktualizowałem wreszcie  sekcje informacyjną o projekcie

Wraz ze wzrostem ilości podłączonych hostów miałem coraz większy problem z błędami „gateway time out”,  który zwalałem na serwer synology… bo to on służy mi jako reverse proxy i przekierowuje połączenia na serwer boinca.

Niestety przez moje zaślepienie straciłem ponad miesiąc bo zamiast zmienić perspektywę na błąd cały czas szukałem problemy na moim NAS’ie. Rozwiązanie było bardzo proste, a wręcz żenujące… po postawieniu projektu na nowym komputerze nie sprawdziłem standardowej konfiguracji Apache2 (a zawsze jest to jeden z pierwszych kroków jakie robię na nowym linux’ie)… i tak o to wystarczyło ustawić moje standardowe i sprawdzone w boju ustawienia serwera WWW:

 StartServers 15
 MinSpareThreads 50
 MaxSpareThreads 100
 ThreadLimit 64
 ThreadsPerChild 50
 MaxRequestWorkers 8192
 MaxConnectionsPerChild 10000

Zapewne można by coś jeszcze lepiej zrobić, ale taka konfiguracja radzi sobie z podłączami hostami na poziomie 250,000 <- a co dopiero przy moich 7,500-8,000

Niestety zauważyłem, że w momencie generowania zadań (szczególnie) dla wszystkich 4 aplikacji na raz, serwer nie wyrabia się z żądaniami dla podłączających się do niego komputerów…  zaś trzeba było siąść i wymyślić rozwiązanie…

Długo nie musiałem się męczyć, ponieważ zastosowałem wyjście awaryjne jakie od roku stosuje w DrugDiscovery@Home. Całość podejścia polega na tym, iż pliki zadań są generowane u mnie na serwerze i udostępnione dla serwera boincowego po NFS’ie.  Na DD@H nie ma problemu z wydajnością serwera za jest problem z wolnym miejscem na dysku <- jedna seria zadań dla sminy i viny to ok.750-800GB. Na GG@h NCI rozwiązanie sprawdziło się idealnie w ten sam sposób… pliki generuje na komputerze z analizatorami które po optymalizacji w zasadzie nie obciążają go, następnie serwer boinca NCI sprawdza co 15-30 minut czy ilość rezerwowych WU nie spadła poniżej 35,000 <- jeśli tak to pobiera 10,000 plików z serwera i robi z nich WU. Dzięki temu projekt działa szybciej i sprawniej. Kolejny mały sukces.

1. Z 8 skryptów, które potrafiły przy większej ilości wyników do analizy zabić komputer przerabiający dane, pozostały 4 uniwersalne skrypty z parametrami.  Drugim etapem było uruchamianie skryptów po kolei, zamiast wszystkie na raz.
2. Jednak najważniejszym krokiem, który planowałem od ponad 2 lat (a czego nie zrobiłem z braku chęci) było tworzenie przed każdym uruchamianiem analizatorów tabeli tymczasowej z informacją o użytkownikach i plikach wynikowych jakie zwrócili w GG@h NCI. Wprowadzenie tego rozwiązania było prawdziwym kamieniem milowym ponieważ czas jednego zapytania do bazy danych zmniejszył się z nawet 5 minut do 5 sekund <- dosłownie.  Teraz można sobie wyobrazić, że każdy analizator robi kilkaset (a czasami kilka tysięcy) takich zapytań. Teraz analizatory przerabiają w 5 minut to co poprzednio w 2 dni.Postęp widać… chyba 😉