Archiwum Blog2
Analizatory zapuszczone, statystyki są zapisywane do bazy danych z każde pliku wynikowego z projektu boinc. Tworzenie tego skryptu szło mi jak krew z nosa i zajęło chyba 3-4 wieczory.. większość polegała na tępym wpatrywaniu się w kod i kompletnej niemocy w zrozumieniu tego co trzeba zrobić. Dopiero w piątek doznałem olśnienia i skończyłem prace.
Jako, że aplikacja htest_64bits przekroczyła 100,000 zadań w toku i projekt zaczął mieć poważne kolejki przy walidacji zadań postawiłem uruchomić po 4 demony z każdego, który nie wydal <- na razie daje radę.
Jednym z najbliższych kroków jakie podejmiemy z Rysiem to wydłużenie czasu pracy 1 zadania z 1-2 minut do 10-15 minut <- to zdecydowanie odciąży ruch na serwerze.
Z obu laptopów odkręciłem panele z obudowy nad wiatrakami przy CPU i temperatury spadły średnio o 20 stopni… na początek świetny wynik, ale pasty na prockach definitywnie są do wymiany.
Tym razem sprzęt na którym stoi projekt GG@h CPU daje mi strasznie popalić…
Temperatura na procesorze według czujników cały czas oscyluje w granicach 95-100 stopni Celsjusza co jest kompletną bzdurą i masakrą <- przy założeniu że w zasadzie tylko 1 rdzeń/2 wątki są obciążone….
W zasadzie to na GG@h NCI temperatura wynosi ponąć 70-80 stopni. Jedyne co podejrzewam to wypalona pasta na procesorach <- w zasadzie jestem prawie pewien, że tej pasty już tam nie ma.
eh… nigdy nie ma tak, żeby wszystko grało jak należy <- no cóż wyzwania są potrzebne 🙂 muszę jak najszybciej kupić pastę na cpu i się z tym pobawić.
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:
Całość przeszła w miarę bez stresu i oby tak pozostało, bo mam co robić oprócz użerania się z serwerami 🙂
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…
Pierwsza aplikacja od kolegi Rysia jest już na GG@H CPU gotowa do testów.
Czeka nas jeszcze sporo pracy, ale już teraz zachęcam do testów.