[wirtualny] Prohost.pl - wadliwe zliczanie punktów CPU

[ritchey 91]

Witajcie,

Mam taki problem w prohost.pl

Od prawie 2 lat mam na hostingu shared - system osTicket (system ticketów open-source).

Głównym elementem tego systemu jest skrypt PHP który pobiera nowe wiadomości z serwera POP3 i zamienia je na rekordy w bazie danych (nowe tickety).

Skrypt ten jest uruchamiany regularnie w CRON-ie co parę minut.

Działał on sobie tak miesiącami, aż tu nagle w pewnym m-cu otrzymałem informację (15 kwietnia 2015r.). że mam użyte 80% CPU. Trochę wydało mi się to dziwne, ponieważ skrypt ten powinien generować bardzo REGULARNE obciążenie (harmonogram CRON). W marcu (który ma 31 dni) wszystko było ok, a tu po 15 dniach kwietnia już CPU zużyty, No nic - dokupiłem grzecznie punkty. Pod koniec kwietnia znowu CPU się kończy (dzienne zużycie po 20-30 punktów). Zdenerwowałem się i podjąłem decyzję o zmianie planu z MEDIUM na PLATINIUM.

Stała się wtedy rzecz dziwna. Pomimo że był ten sam skrypt - ten sam CRON (ta sama ilość wywołań tego samego skryptu) - to nagle dzienne zużycie CPU spadło do ok. 2 pkt. (słownie dwóch, a poprzednio 20-30 pkt. dziennie). 10-krotny spadek zużycia CPU !!!

Ok, płacę rocznie 100 zł więcej - ale kłopoty ze zliczaniem punktów CPU wydały się być zażegnane. Minął prawie rok.

Mamy koniec marca 2016 i nagle powraca jak bumerang problem CPU. Pomimo że dalej jest ten sam skrypt, ten sam CRON to właśnie otrzymałem alert o zużyciu 80% CPU. Loguje się do panelu i widzę że znowu dzienne zużycie jest na poziomie 20 pkt. CPU.

Jestem na 99.99% pewny - że system zliczania punktów CPU jest wadliwy.

A teraz najlepsze: CRON jest ustawiony w taki sposób - że w dni robocze działa dość często (co 2 minuty), natomiast w weekendy (sob.-niedz.) co 10 minut (5 razy rzadziej).

Ale według wykresu statystyk prohostu w niedzielę (20 i 27 marca) zużycie było po 22 pkt CPU, a w czwartek (24 marca) - tylko 13 punktów:

http://static.pokazywarka.pl/i/6459326/306367/cpu-2016-03.jpg

Czy ktoś miał u nich takie problemy ?

Prohost upiera się oczywiście że u nich wszystko jest OK.

Edytowano Marzec 28, 2016 przez ritchey (zobacz historię edycji)

[admin@prohost.pl 74]

Użycie cpu jest liczone tak samo - nic się nie zmienia.

Nie jest stałe bo zwykle ilość uruchamianych procesów, dane które są przetwarzane, czy same skrypty/programy się zmieniają.

W tym przypadku może być np spam na skrzynce w jednym dniu albo maile same większe albo jeszcze coś innego i wynik się zmienia. Jest różnie to nie znaczy, że źle. Punkty są używane też przez inne procesy na koncie - nie tylko cron. Ftp, email itd. też.

[kori 29]

nie przepłacaj, zmień hosting

[Artix 34]

Dokładnie. Lepiej poszukać nowej klitki dla siebie niż na siłę dusić się w swojej. Może któraś z firm przygotuje dla Ciebie indywidualną ofertę.

[mmat 0]

Użycie cpu jest liczone tak samo - nic się nie zmienia.

Nie jest stałe bo zwykle ilość uruchamianych procesów, dane które są przetwarzane, czy same skrypty/programy się zmieniają.

W tym przypadku może być np spam na skrzynce w jednym dniu albo maile same większe albo jeszcze coś innego i wynik się zmienia. Jest różnie to nie znaczy, że źle. Punkty są używane też przez inne procesy na koncie - nie tylko cron. Ftp, email itd. też.

 

Ad 1. "Użycie CPU jest liczone tak samo - nic się nie zmienia."

To jak możemy wytłumaczyć że jedynie zmiana planu z medium na platinium spowodowała zmniejszenie ok. 10-krotne zużywanych punktów ? Ruch pozostał taki sam - podobna ilość odwiedzin, maili, etc.

Teraz już niestety nie mamy dostępu do statystyk historycznych - gdyż prohost umożliwia dostęp tylko do ost. m-ca.

 

Ad 2. "Nie jest stałe bo zwykle ilość uruchamianych procesów..."

W panelu możemy sprawdzić "Statystyki PHP" i tam dokładnie widać który skrypt ma jaki udział w całym użyciu CPU. Skrypt w CRON-ie o którym mówię zajmuje 70-80% całości.

 

Ad 3. "dane które są przetwarzane, "

W zasadzie jedynym czynnikiem decydującym o obciążeniu jest ilość przychodzących maili.

Codziennie jest ona podobna - od kilku-kilkunastu w weekendy do kilkudziestu w dni robocze.

Niestety ale Pana argument jest nietrafiony - gdyż jak widać na załączonym wykresie 27. marca w niedziele Wielkanocną - zużycie CPU osiągnęło maksymalny peak (22 pkt.). Paradoksalnie był to dzień wolny i świąteczny - w którym przyszło jedynie kilka maili. Był to dzień o rekordowo niskim przetwarzaniu danych - ale w prohoscie ma on rekordowo wysokie zużycie CPU.

 

Ad 4. "same skrypty/programy się zmieniają"

Od początku używamy tej SAMEJ wersji osTicketa - nie aktualizujemy jej - gdyż została ona lekko zcustomizowana pod nas i gdybyśmy ją aktualizowali - to utracilibyśmy naszą customizację.

[kori 29]

wybrałeś hosting o dziwnych metodach rozliczeń teraz za to dopłacasz,
wybierz normalny hosting, np. linuxpl, też po nich czasami jeździłem, ale wszędzie gdzie próbowałem się przenieść nie było nic lepiej progreso, a często bywało jeszcze gorzej, np sixwishlist

[admin@prohost.pl 74]

 

Ad 1. "Użycie CPU jest liczone tak samo - nic się nie zmienia."

To jak możemy wytłumaczyć że jedynie zmiana planu z medium na platinium spowodowała zmniejszenie ok. 10-krotne zużywanych punktów ? Ruch pozostał taki sam - podobna ilość odwiedzin, maili, etc.

Teraz już niestety nie mamy dostępu do statystyk historycznych - gdyż prohost umożliwia dostęp tylko do ost. m-ca.

 

Ad 2. "Nie jest stałe bo zwykle ilość uruchamianych procesów..."

W panelu możemy sprawdzić "Statystyki PHP" i tam dokładnie widać który skrypt ma jaki udział w całym użyciu CPU. Skrypt w CRON-ie o którym mówię zajmuje 70-80% całości.

 

Ad 3. "dane które są przetwarzane, "

W zasadzie jedynym czynnikiem decydującym o obciążeniu jest ilość przychodzących maili.

Codziennie jest ona podobna - od kilku-kilkunastu w weekendy do kilkudziestu w dni robocze.

Niestety ale Pana argument jest nietrafiony - gdyż jak widać na załączonym wykresie 27. marca w niedziele Wielkanocną - zużycie CPU osiągnęło maksymalny peak (22 pkt.). Paradoksalnie był to dzień wolny i świąteczny - w którym przyszło jedynie kilka maili. Był to dzień o rekordowo niskim przetwarzaniu danych - ale w prohoscie ma on rekordowo wysokie zużycie CPU.

 

Ad 4. "same skrypty/programy się zmieniają"

Od początku używamy tej SAMEJ wersji osTicketa - nie aktualizujemy jej - gdyż została ona lekko zcustomizowana pod nas i gdybyśmy ją aktualizowali - to utracilibyśmy naszą customizację.

 

1. Zmiana planu nie zmienia absolutnie nic poza ilością dostępnych punktów jesli chodzi o limit cpu - nie ma żadnego wpływu na wydajność konta.

 

2. Statystyki php w cpanelu podają użycie cpu przez skrypty odpalane przez www. Nie ma tam całości bo skrypty php nie są jedynymi procesami uruchamianymi na koncie.

 

3. Każdy email pewnie jest inny, zawiera załączniki albo i nie, jest inaczej kodowany, więc dlaczego zawsze miałoby tak samo używać cpu? Ilość nie równa się pracy wykonanej. Może być jedno zadanie wymagające większych zasobów albo więcej zadań wygających mniej zasobów.

 

4. Pisałem ogólnie o możliwościach, nie o konkretnym przypadku. Jeśli potrzebna Panu konkretna pomoc proszę skontaktować się z Biurem Obsługi Klienta.

[Gość Adam Szendzielorz]

Od prawie 2 lat mam na hostingu shared - system osTicket (system ticketów open-source).

Głównym elementem tego systemu jest skrypt PHP który pobiera nowe wiadomości z serwera POP3 i zamienia je na rekordy w bazie danych (nowe tickety).

 

Podepnę się pod temat, bo znam sprawę od drugiej strony (administracyjnej) - czy działa Ci tam tylko i wyłącznie ten system, czy obsługujesz też inne strony? Przeanalizuj access_logi serwera WWW, czy nie masz tam np. prób brute-force logowania się do systemu. A jeżeli masz tam jakiegoś WordPressa to sprawdź szczególnie wywołania POSTowe (do wp-login.php i xmlrpc.php) - "ddos"y na te skrypty to coś całkowicie w ostatnim czasie naturalnego

[ritchey 91]

 

1. Zmiana planu nie zmienia absolutnie nic poza ilością dostępnych punktów jesli chodzi o limit cpu - nie ma żadnego wpływu na wydajność konta.

 

2. Statystyki php w cpanelu podają użycie cpu przez skrypty odpalane przez www. Nie ma tam całości bo skrypty php nie są jedynymi procesami uruchamianymi na koncie.

 

3. Każdy email pewnie jest inny, zawiera załączniki albo i nie, jest inaczej kodowany, więc dlaczego zawsze miałoby tak samo używać cpu? Ilość nie równa się pracy wykonanej. Może być jedno zadanie wymagające większych zasobów albo więcej zadań wygających mniej zasobów.

 

4. Pisałem ogólnie o możliwościach, nie o konkretnym przypadku. Jeśli potrzebna Panu konkretna pomoc proszę skontaktować się z Biurem Obsługi Klienta.

 

Ad 1. Tak właśnie powinno być - ale fakty wskazują że jest inaczej.

 

Ad 2. Zgadza się, ale spośród wszystkich wyszczególnionych procesów w statystykach - to właśnie mój CRON jest liderem (zajmuje ok 3/4 punktów). Wiem że mogą być inne procesy nie wyszczególnione - ale jeżeli tak jest to także chciałbym je zobaczyć w statystykach CPU.

Jeżeli jutro dostaniesz rachunek za telefon na 500 zł a na billingu będą wyszczególnione tylko rozmowy na 40 zł - to oczywiste że chciałbyś zobaczyć za co naliczyli ci te dodatkowe 460 zł. Chciałbym w prohoście mieć możliwość zobaczenia statystyk z % udziałem zużycia CPU - WSZELKICH procesów które są uwzględniane przy liczeniu punktów. Inaczej te statystyki są bezwartościowe - skoro jest na nich pokazana tylko część procesów, a nie wszystkie.

Tak czy inaczej z dużą pewnością mogę stwierdzić że to nasz CRON jest odpowiedzialny za zużycie CPU, ponieważ jak go zmienię z cyklu 2 minutowego na 8 minutowy to widać wyraźny spadek zużycia CPU (widać to na wykresie oraz w statystykach PHP).

 

Ad 3. Emaile są bardzo zbliżone. Większość (95%) to proste e-maile tekstowe zawierające zazwyczaj parę zdań. Załączniki są sporadyczne - a jeżeli już to jakieś niewielkie PDF. Paradoksalnie w niedzielę 27 marca - kiedy to zużycie CPU było rekordowo wysokie - przyszło raptem kilka krótkich maili tekstowych bez załącznika

 

Ad 4. Kontaktowałem się już wcześniej i poruszałem ten temat - ale obsługa się upierała że zliczanie jest prawidłowe (ticket nr #16787, wiadomość z 5 maja 2015r.) - więc tym razem stwierdziłem że nie ma sensu się kłócić dalej i zapytałem się tutaj.

 

Podepnę się pod temat, bo znam sprawę od drugiej strony (administracyjnej) - czy działa Ci tam tylko i wyłącznie ten system, czy obsługujesz też inne strony? Przeanalizuj access_logi serwera WWW, czy nie masz tam np. prób brute-force logowania się do systemu. A jeżeli masz tam jakiegoś WordPressa to sprawdź szczególnie wywołania POSTowe (do wp-login.php i xmlrpc.php) - "ddos"y na te skrypty to coś całkowicie w ostatnim czasie naturalnego

 

Dzięki za sugestie, ale nie mam WP. Tak - jest tam jeszcze kilka stron, ale to nie one stanowią problem. Gdyby one były powodem obciążenia to były by odnotowane w statystykach. Są co prawda wyszczególnione - ale ich zużycie CPU jest dużo niższe niż mój CRON.

[admin@prohost.pl 74]

Jeśli jest potrzeba sprawdzenia innych procesów to BOK w tym pomoże.

[kori 29]

@admin@prohost.pl, co tu sprawdzać, wasz licznik jak mówicie działa prawidłowo

@ritchey, skoro musisz ciągle dopłacać poprostu zmień hosting, większość firm przeniesie ci stronę za darmo

opisz wymagania, napewno kilk firm podejmie się hostowania twojej strony

 

[ritchey 91]

Właśnie zastanawiam się nad zmianą hostingu.

W prohost.pl jestem od 8 lat. Głównym kryterium jakim się kierowałem wybierając tę firmę to doskonały support.

Czas reakcji na zapytanie był wręcz natychmiastowy bez względu na porę dnia, dzień roboczy czy wolny.

Niestety od jakiegoś czasu (mniemam że od przejęcia przez IQ) - błyskawiczna obsługa klienta - stała się już tylko historią.

Teraz nawet na prostą odpowiedź czeka się godzinę lub więcej.

 

Czy może ktoś polecić firmę która ma tak błyskawiczny support taki jak miał dawny prohost ?

[kori 29]

linuxpl.com ma rowniez blyskawiczny support w dodatku wieloma kanałami: mail, gg, chat na stronie, telefon

jestem u nich od 6 lat

Edytowano Marzec 30, 2016 przez kori (zobacz historię edycji)