Serwer hostingowy duża liczba wierszy pobranych z bazy


(Janusz67890) #1

Witam

 

Nazwa grozi mi zawieszeniem usługi bo mam przekroczony limit liczby wierszy pobranych z bazy danych. Pytanie jest co gdzie mogę szukać przyczyny jakie skrypty itd. mogą za to odpowiadać. Bo od nazwy nie mogę się dowiedzieć nic, twierdzą że nie prowadzą takich logów. Na serwerze mam sklep internetowy i staram się wyłączać już różne aktualizacje produktów itd, ale liczba nadal jest przekraczana.

 

 


(ziggurad) #2

Ciężko wróżyć z fusów, Twój kod pewnie jest gdzieś nieoptymalny i pobiera za dużo danych. Nikt CI nie powie w jakim miejscu :wink: Możesz spróbować lokalnie testować kiedy baza jest najbardziej obciążona, przy jakim zachowaniu na stronie :wink:


(Fizyda) #3

Zmień hosting, na ograniczenia nazwy każdy w końcu narzeka bo są zwyczajnie z dupy.

 

Co do samego problemu to warto się nim mimo wszystko zainteresować, być może faktycznie pobierasz zbyt duża liczbę wierszy i to zupełnie niepotrzebnie. Niestety bez informacji co to za skrypt nikt nawet nie powie Ci czego mniej więcej szukać.

Uważam że do tego typu zadań, jeśli się człowiek sam nie zna lepiej kogoś wynająć, bo zapytania do bazy danych nie zawsze są wysyłane bezpośrednio, czasami są tworzone przez jakieś warstwy abstrakcyjne służące do komunikacji z bazą danych. Jeśli byłbyś zainteresowany napisz na priv.


(lukasssz) #4

Nie wiem z czego korzystać, sklep, framework, technologia, ani jakie masz umiejętności, ale można by było podpiąć jakiś profiler do testu, jeśli nie masz zaimplementowanego.


(Janusz67890) #5

to jest sklep internetowy na silniku shopgold


(Fizyda) #6

Nie znam skryptu więc bez zagłębiania się w niego nie jestem w stanie podrzucić żadnego pomysłu. Statystyki które podesłałeś na priv, ewidentnie wskazują na jakiś problem i to dość spory, ba baaardzo spory.

 

Jakieś modyfikacje były wykonywane na skrypcie? Coś doinstalowywane, jakieś pluginy itp.?

Kolejna sprawa co to za sklep (jak duży/popularny), ile danych jest w bazie, jaki jest ruch na stronie sklepu (statystyki).


(Janusz67890) #7

Miesięcznie jest około 300 tyś odsłon, produktów w sklepie jest 22 tysiące. Różne modyfikacje prowadzone są przez twórców oprogramowania którzy uważają że nazwa powinna określić co jest przyczyną takich przekroczeń bo niby w debugowaniu nic nie wychodzi. Jest zintegrowany program ze sklepem co łączy sklep internetowy i Subiekt tyle że on wykonuje aktualizacje raz dziennie, a ostatnio i tak go mocno ograniczyłem. Pobiera jedynie zamówienia co jakiś czas.


(Fizyda) #8

Jak mam obstawiać to subiekta, a konkretnie pobieranie zamówień. Podaj jeszcze zrzut z widoku bazy danych, tak aby były widoczne tabele i ich rozmiar.


(Janusz67890) #9

Zamówienia pobierają się co 5 minut 

 

817_tabela_bazy_tn.jpg


(Fizyda) #10

To są na pewno wszystkie tabele? Bo to jest prawie niemożliwe by zamówienia pobierać tyle czasu, nawet gdyby za każdym razem pobierał wszystko co wydaje się zamówieniami zajmuje ~130mB, a subiekt nie powinien pobierać za każdym razem wszystkiego tylko aktualizować dane.

 

Z tego co zauważyłem to shopgold ma integracje z subiektem i obstawiam że jest ona źle zrobiona. Niestety silnik jest zamknięty i nie widzę nigdzie dokumentacji  do niego, więc bardziej bez dostępu do dokumentacji/kodu nie jestem w stanie pomóc. Jedynie mogę zgadywać że to wina integracji z subiektem.

 

Przy tym co podałeś nie powinno być sytuacji że baza danych ma takie statystyki jakie mi wysłałeś to jest prawie niemożliwe jeśli wszystko jest dobrze zrobione.


(Janusz67890) #11

Nie, tabel jest 170 tyle że trudno by zrobić tyle zrzutów ekranu. Program do integracji nazywa się s2s


(Fizyda) #12

W takim razie to co wyżej napisałem nie jest aktualne.

 

Na moje to shopgold powinni znaleźć problem, bo to ich skrypt i to oni sobie mogą wygenerować logi, hosting takiej możliwości nie ma. Firma hostingowa dałaby rade jedynie mniej więcej wskazać problem, ale przy rekonfiguracji serwera zapewne i włączeniu jakiś opcji debugujących, ale oni udostępniają miejsce na serwery produkcyjne i nie zrobią serwera testowego dla jednego klienta. Takie rzeczy powinni załatwić programiści.

 

Na własną rękę możesz w trakcie aktualizacji subiekta zobaczyć statystyki w bazie danych dla jego połączenia, jak pobiera tony danych, ale to zależ od Twoich uprawnień na serwerze. Teoretycznie firma hostingowa mogłaby przechwycić i zapisać zapytania do bazy danych w celu ich analizy, ale w praktyce wątpię by to zrobili ponieważ obciąża to serwer, developerzy po stronie kodu mogą zrobić to samo, a jedyny efekt uboczny będzie obciążenie tylko na jednej stronie, a nie dla wszystkich klientów firmy hostingowej.


(Wirrus) #13

Trzeba się dowiedzieć co to za aplikacja lub usługa pobiera tyle danych. Mogą to być statystyki lub nawet uszkodzenie takowej aplikacji.

W pierwszej kolejności spróbowałbym wyłączyć pewne aplikacje/moduły, które pobierają dane w celu sprawdzenia GDZIE występuje dany problem.

Druga sprawa: może być tak, że dane jakimś cudem pobiera ktoś całkiem inny. Może jest zainstalowany skrypt, który pobiera a następnie wysyła dane do osoby niepowołanej? Na sklepach internetowych jest konkurencja. A to może powodować takie typu akcje. Warto na wszelki wypadek zmienić hasła dostępowe.

 

Pozdrawiam.

 

 


(Janusz67890) #14

Dziękuje za wartościowe odpowiedzi. Dodam że w error logu dziennie było kilka tysięcy błędów z kilku adresów IP. Obecnie nie jest aż tak dużo bo zablokowałem 2 adresy poprzez z htaccess ale załączam wycinek loga i zastanawiam się czy dalej blokować.

 

[Thu Jul 21 13:27:48.642750 2016] [proxy_fcgi:error] [pid 27:tid 140605678085888] [client 137.59.60.11:52997] AH01071: Got error ‘Primary script unknown\n’

[Thu Jul 21 13:14:19.291836 2016] [proxy_fcgi:error] [pid 27:tid 140605778798336] [client 66.249.66.157:50116] AH01071: Got error ‘Primary script unknown\n’

[Thu Jul 21 12:57:57.431109 2016] [access_compat:error] [pid 8886:tid 139651356501760] [client 37.59.14.75:55834] AH01797: client denied by server configuration: /home/ftp/sklep/blad.php

[Thu Jul 21 12:57:57.430520 2016] [access_compat:error] [pid 8886:tid 139651356501760] [client 37.59.14.75:55834] AH01797: client denied by server configuration: /home/ftp/sklep/www.mojsklep.com.pl

[Thu Jul 21 12:47:57.543279 2016] [core:error] [pid 8776:tid 139651280967424] [client 94.152.156.111:59303] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use ‘LimitInternalRecursion’ to increase the limit if necessary. Use ‘LogLevel debug’ to get a backtrace.

[Thu Jul 21 12:38:24.522393 2016] [proxy_fcgi:error] [pid 8810:tid 139651356501760] [client 220.158.141.210:65418] AH01071: Got error ‘Primary script unknown\n’

[Thu Jul 21 12:06:29.743703 2016] [cgi:error] [pid 8594:tid 139651457214208] [client 150.254.156.65:49406] AH02811: script not found or unable to stat: /home/ftp/sklep/www.mojsklep.com.pl

[Thu Jul 21 12:06:26.169556 2016] [cgi:error] [pid 8594:tid 139651390072576] [client 150.254.156.65:49406] AH02811: script not found or unable to stat: /home/ftp/sklep/www.mojsklep.com.pl

[Thu Jul 21 12:02:26.982663 2016] [cgi:error] [pid 8594:tid 139651465606912] [client 91.198.179.117:13498] AH02811: script not found or unable to stat: /home/ftp/sklep/www.mojsklep.com.pl

[Thu Jul 21 12:02:26.262099 2016] [cgi:error] [pid 8594:tid 139651415250688] [client 91.198.179.117:13498] AH02811: script not found or unable to stat: /home/ftp/sklep/www.mojsklep.com.pl

[Thu Jul 21 11:40:15.491018 2016] [proxy_fcgi:error] [pid 8428:tid 139651432036096] [client 202.166.130.167:10380] AH01071: Got error ‘Primary script unknown\n’


(YoJoe) #15

 

Zobacz czy to nie są adresy IP wyszukiwarkowych botów.

 

A co do hostingu w nazwa, to mają opcję migracji kont na maszyny obsługiwane przez 64-bitowe linuksy. To rzecz pierwsza, której nawet nie warto komentować w 2016r.

Rzecz druga, to spróbuj zmienić wersję parsera php na 7 i zobacz czy przyspieszy to nieco działanie samego skryptu.

 

Nie ma opcji cache’owania danych w shopgold ? Przy takim rzezaniu bazy nie tylko gruchoty w nazwie dostawałyby zadyszki.


(zypolit) #16

U mnie to wynikało w każdym przypadku z ataku spamerskiego. Po prostu nagle pojawiało się tyle pozycji w bazie, że strona nie wyrabiała. Spamerzy potrafili dodawać tysiące wpisów dziennie. Takie akcje miałem np. przy Jportal czy WP. Śledź obciążenie.