OsCommerce - 504 Gateway Timeout i 500 Internal Server Error

[Imperator]

Witam

Mam taki problem ze sklepem opartym na OsCommerce:

Strona działa jak burza wszystko super, ale czasami przy zmianie statusu zamówienia zaczyna mielić w nieskończoność i wyskakuje błąd:

500 Internal Server Error

Sytuacja wraca do normy zawsze po 15-20 minutach i znów działa wszysko rewelacyjnie, a zmiana statusu trwa ułamek sekundy. Chciałbym też zauważyć że strona dla użytkowników działa poprawnie wszystko się wczytuje, można oglądać produkty i zamawiać! Tylko w panelu Admina przy zmianach statusu zamówień się sypie.

Pan od serwerów stwierdził że strona rozrosła się od momentu instalacji 10-krotnie i trzeba ją przenieść na lepszy szybszy serwer i że to rozwiąże problem, bo skrypt jest przestarzały itp.

Tak więc strona została przeniesiona na ten lepszy i szybszy serwer. Strona działa fantastycznie, a składanie zamówień kilkukrotnie przyśpieszyło. Niestety dalej jest ten sam problem co wcześniej, czasami przy zmianie statusu zamówienia znowu zaczyna mulić w nieskończoność i wyskakuje błąd tylko inny:

504 Gateway Timeout

I tak jak wcześniej po kilku minutach sytuacja wraca do normy i wszystko działa super


Tak więc tutaj pojawia się moje pytanie. Co może być problemem? To wina Serwerów? Bo Pan od hostingu twierdzi że u niego wszystko jest ok. i serwery działają świetnie. Czy też może to być wina softu, ale to byłoby dziwne bo przez 99% czasu strona działa fantastycznie.

[SzlafRock]

Zmień soft.

Myślałem że już nikt nie używa oscommerce.

[mghost.pl]

A sprawdzałeś co mówią logi w momencie występowania błędu?

Bez tego, to jak wróżenie z fusów.

[piotr.k]

Nie pamiętam co się mieli przy zmianie statusów ale możesz przekraczać limity zapytań/połączeń do bazy lub limit czasu wykonywania - tak jak mówi kolega sprawdź logi (możesz też włączyć dodatkowe logowanie w osc) i porównaj z limitami serwera.

[Imperator]

A sprawdzałeś co mówią logi w momencie występowania błędu?

Logi poniżej (wycięta nazwa strony):

Script timed out before returning headers: php-cgi, referer: https://www.xxxxx.pl/admin/orders.php?oID=40490&action=editScript'>https://www.xxxxx.pl/admin/orders.php?oID=40490&action=editScript timed out before returning headers: php-cgi, referer: https://www.xxxxx.pl/admin/orders.php?oID=40476&action=editScript timed out before returning headers: php-cgi, referer: https://www.xxxxx.pl/admin/orders.php?oID=40490&action=editScript'>https://www.xxxxx.pl/admin/orders.php?oID=40490&action=editScript timed out before returning headers: php-cgi, referer: https://www.xxxxx.pl/admin/orders.php?oID=40490&action=editScript'>https://www.xxxxx.pl/admin/orders.php?oID=40490&action=editScript timed out before returning headers: php-cgi, referer: https://www.xxxxx.pl/admin/orders.php?status=15&page=1&oID=40476&action=editScript timed out before returning headers: php-cgi, referer: https://www.xxxxx.pl/admin/orders.php?oID=40490&action=edit

ale możesz przekraczać limity zapytań/połączeń do bazy lub limit czasu wykonywania

A co zrobić żeby nie przekraczać?

Edit: Logi z dzisiaj z godziny 13.00 do 13.15. A po 15 minutach wszystko wróciło do normy i działa bez problemów

[piotr.k]

Włącz logowanie w osc - o ile pamiętam to będzie tam info jakie zapytania wtedy robi i jakie ma czasy odpowiedzi.

Sprawdź jakie masz max_execution_time w php - ewentualnie można trochę zwiększyć jak jest 30s

Żeby nie przekraczać to albo zwiększyć te limity albo zoptymalizować skrypt (przynajmniej dla tej operacji)

BTW: Tak na oko, to ta podstrona jeśli nie była zmieniana to chyba nie powinna zarzynać serwera ani trwać zbyt długo - chyba, że masz setki dostępnych statusów albo przy okazji coś się mieli...

[Imperator]

Włącz logowanie w osc

Mam coś takiego jak Logi:

Przechowuj czas przetwarzania strony -> false

Pokazuj czas przetwarzania stron -> false

Przechowuj zapytania do bazy danych -> false

Pokaż ilość zapytań SQL i czas generowania -> true

Debuguj zapytaia SQL -> false

to o to chodzi?

masz max_execution_time

W informacjach o serwerze pokazuje że jest -> max_execution_time 30 Tylko nie bardzo rozumiem co zmieni zwiększenie tego parametru bo się nie znam. Przez 99,9% czasu zmiana statusu trwa ułamek sekundy.

chyba, że masz setki dostępnych statusów

Nie. To jest jeden czy dwa statusy zamówień zmieniane w jednym momencie

[piotr.k]

to o to chodzi?

Nie wiem która macie wersję i jak przerobioną

W którejś wersji oryginału to było pod adresem w stylu xxx.pl/admin/configuration.php?gID=10

oraz do ustawienia: Store Page Parse Time, Log Destination, Log Date Format, Store Database Queries.

Display The Page Parse Time ustaw na false, żeby nie waliło na stronie logami a tylko zapisywało do pliku...

max_execution_time spróbuj 60 - nie wiem czy możecie zmienić, czy musisz zgłosić się do hostingodawcy

w skrócie teraz skrypt php po 30s przerywa działanie a jeśli w tym czasie nie zdąży to pojawiają się np. te błędy typu timed out - zwiększając na 60 dasz skryptowi więcej czasu na wykonanie...

Odnośnie statusów to nie to miałem na myśli

[mghost.pl]

Masz tam dostęp do roota?

Być może potrzeba lekkiego tuningu konfiguracji.

Jeśli masz dostęp do php.ini, to tam możesz wydłużyć max_execution_time.

[Imperator]

zwiększając na 60 dasz skryptowi więcej czasu na wykonanie...

Jeśli masz dostęp do php.ini, to tam możesz wydłużyć max_execution_time.

Ogólnie pewnie można by zwiększyć nawet do 1h, tylko właśnie nie o to mi chodzi. Szukam przyczyny czemu tak się dzieje, że czasem zatyka się to na kilkanaście minut, a 99,9% czasu działa poprawnie.

W którejś wersji oryginału to było pod adresem w stylu xxx.pl/admin/configuration.php?gID=10

Właśnie pod tym adresem są te opcje co pisałem.

Przechowuj czas przetwarzania strony -> false

Pokazuj czas przetwarzania stron -> false

Przechowuj zapytania do bazy danych -> false

Pokaż ilość zapytań SQL i czas generowania -> true

Debuguj zapytaia SQL -> false

Już włączam to

[mghost.pl]

Być może przez dużą liczbę jednoczesnych połączeń, przekraczasz limit ilości otwartych plików na serwerze. Być może przekraczasz limity jednoczesnych połączeń do MySQLa i wtedy część skryptów nie wyrabia się w dopuszczalnym czasie wykonywania.

Ja zacząłbym od sprawdzenia właśnie ilości otwartych plików, wartości limitu jednocześnie otwartych plików, może mały tuning MySQLa i problem powinien ustąpić.

[piotr.k]

Szukam przyczyny czemu tak się dzieje,

To trzeba by analizować logi i sprawdzać na czym się wykłada

Już włączam to

Wyłącz pokazywanie, bo to chyba wyświetla info w stopce - reszta na true, żeby się zapisywało w pliku.

Na początek spróbuj zwiększyć max_execution_time do 60, choć dobrze zoptymalizowany oscommerce bez dziwnych przeróbek powinien się wyrobić się w 30s.

Jak się uda znowu wywołać błędy to trzeba przeanalizować logi, które włączyłeś i powinna się pojawić jakaś wskazówka co bruździ

[Imperator]

Jak się uda znowu wywołać błędy to trzeba przeanalizować logi, które włączyłeś i powinna się pojawić jakaś wskazówka co bruździ

Włączone i czekam aż wystąpi błąd

Być może przez dużą liczbę jednoczesnych połączeń, przekraczasz limit ilości otwartych plików na serwerze. Być może przekraczasz limity jednoczesnych połączeń do MySQLa i wtedy część skryptów nie wyrabia się w dopuszczalnym czasie wykonywania.

A jak to sprawdzić?

[mghost.pl]

Jak masz dostęp do roota, to wklej wynik polecenia:

lsof | wc -l

[Imperator]

Włącz logowanie w osc - o ile pamiętam to będzie tam info jakie zapytania wtedy robi i jakie ma czasy odpowiedzi.

Jest Lipa Po włączeniu Logowania niestety nic nie zapisuje do pliku. Coś nie działa ta opcja