Konserwacja gg@h cpu

Tutaj jest dłuższa historia.

Wczoraj chciałem przenieść GG@H CPU na fizyczną maszynę z dyskiem SSD, ale jako maniak robienia kopii… tak, tak robiłem backUp i umarła maszyna VPS na której był serwer/projekt. Musiałem na szybko przenieść dysk maszyny do siebie na komputer, odpalić maszynę VirtualBox z tym dyskiem, naprawić dysk i odpalić projekt na wspomnianym VirtualBoxie.

Wszystko chodziło bez problemu i dalej pewnie by tak było, ale nie taki był cel całej operacji… jednak komputer roboczy czasami się wiesza i jest restartowany. Dlatego po wysłaniu wszystkich zadań w kolejce i odebraniu ponad 95% z nich zatrzymałem serwer celem podjęcia odpowiednich kroków:

  1. przeniesienia maszyny z VirtualBoxa na fizyczny sprzęt
  2. dopasowanie rozmiaru partycji do wielkości dysku
  3. małe podrasowanie mysql i apache2
  4. uruchomienie pamięci tymczasowej
  5. uruchomienie projektu boinc GG@h CPU
  6. wygenerowanie zadąń do stress testu: jedna seria 25,000 zadań i druga się generuje w ilości 1,000,000 tasków

Całość przeszła w miarę bez stresu i oby tak pozostało, bo mam co robić oprócz użerania się z serwerami 🙂

Konserwacja gg@h 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

Apache2 + php-mpm

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 🙂

 

Gateway Timeout na gg@H nci

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…

GG@h CPU

Po rozmowach z kolegą rysiem odpaliłem na czysto GoofyxGrid@home NCI celem wrzucenia do projektu jego aplikacji.  Najprawdopodobniej projekt z apką ruszy początkiem przyszłego tygodnia z próbną seria zadań do wykonania.

Kosmetyki strony c.d.

  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