Mam mnóstwo dziwnych problemów z Magento CE 1.7.0.2. Podczas normalnych operacji strona czasami wyświetla stronę błędu Magento ( wystąpił błąd podczas przetwarzania Twojego żądania ) zarówno na interfejsie użytkownika, jak i na serwerze zaplecza. Przeglądając powiązany raport, widzę następujący komunikat:
"SQLSTATE[HY000] [2006] MySQL server has gone away"
Czasami, ale rzadziej, komunikat raportu brzmi:
Connection reset by peer
Patrzyłem na var> log> system.log i MySQL has gone away
błędowi towarzyszy:
Warning: PDO::__construct(): MySQL server has gone away in /var/www/html/domain.com/live/lib/Zend/Db/Adapter/Pdo/Abstract.php on line 129
Error while reading greeting packet. PID=1863 in /var/www/html/domain.com/live/lib/Zend/Db/Adapter/Pdo/Abstract.php on line 129
Ponadto wydaje się, że przy każdym żądaniu występuje następujący błąd, a także MySQL has gone away
błędy:
Warning: include(File.php): failed to open stream: No such file or directory in /var/www/html/domain.com/live/lib/Varien/Autoload.php on line 93
Warning: include(): Failed opening 'File.php' for inclusion
Przeglądałem większość artykułów na ten temat i majstrowałem przy parametrach bazy danych, aż krowy wróciły do domu, ale błąd pozostał.
Po kolejnym QnA na temat kompilatora zauważam, że strona administratora System> Narzędzia> Kompilacja jest całkowicie pusta. Myślę, że są to wszystkie powiązane błędy, ale każdy wgląd w debugowanie lub przyczyny byłoby bardzo pomocne.
Przepraszam, jeśli jest to niespójne; Nie spałem około 42 godzin, więc proszę o wyjaśnienia. Dziękuję Ci.
-- aktualizacja --
Mój stos serwerów dla jasności:
PHP 5.5.4 (PHP-FPM)
Nginx 1.4.2
MySQL 5.5.33
-- aktualizacja --
Przychodzi mi do głowy (po pewnym czasie snu), że nigdy nie określiłem - baza kodu PHP i baza danych MySQL znajdują się na osobnych serwerach sprzętowych - bardzo ważne jest, aby wiedzieć, czy mi pomożecie !! Przepraszam.
źródło
Odpowiedzi:
Wynika to głównie z jednego z dwóch poniższych powodów
naprawa: spróbuj zwiększyć
wait_timeout
zmienną wmy.cnf/my.ini
pliku konfiguracyjnym mysqld .Poprawka: zwiększ maksymalny limit rozmiaru pakietu, zwiększając wartość
max_allowed_packet
wmy.cnf/my.ini
pliku.Proszę sprawdzić pliki, jeśli próbujesz uzyskać coś, co trwa zbyt długo lub nie nadaje się do zastosowania.
źródło
max_allowed_packet
na 2G iwait_timout
do 86400, jeszcze żadnej pomocy.Problem rozwiązany! Dziękuję wszystkim za pomoc. Był to problem zapory sprzętowej z hostem internetowym, nawet po ich wyłączeniu przez nas.
Jak potwierdził zespół serwerów 1 i 1 , sprzętowe zapory ogniowe zostały poprawnie skonfigurowane, ale niepoprawnie przechwytywały prawidłowy ruch między serwerem plików a serwerem db przez około 25% czasu.
Zamiast tego skonfigurowaliśmy iptables i całkowicie zamknęliśmy zapory sprzętowe. 100% dostępności teraz.
źródło
Ten sam problem wystąpił w przypadku Magento 2.1, a mój dziennik błędów mysql wielokrotnie pokazywał następujący błąd podczas procesu „MySQL odszedł”:
...[Warning] File Descriptor 1228 exceeded FD_SETSIZE=1024
Aby potencjalnie rozwiązać ten problem, najpierw sprawdź
open files
wartość$ ulimit -n
, która w moim przypadku była256
.Po drugie, dodaj
table_open_cache = {that ulimit -n value}
pod[mysqld]
sekcją w swoimmy.cnf
.Teraz uruchom ponownie MySQL i mam nadzieję, że wrócisz do akcji.
Uwaga: Używam Magento 2.1 lokalnie na systemie OS X El Capitan z PHP 7.1 i MySQL 5.7.15 z Homebrew. Ale założę się, że to rozwiązanie działałoby również w starszych lub różnych konfiguracjach.
źródło
Zmodyfikuj plik aplikacji / etc / local.xml w folderze Magento, zastępując wpis dla hosta „127.0.0.1” zamiast „localhost”.
źródło
Wystąpił ten sam błąd podczas migracji dużej bazy danych między 2 serwerami.
Tymczasowe dodanie następujących rzeczy w pliku konfiguracyjnym mysql (/etc/mysql/my.cnf) na moim lokalnym serwerze (docelowym) i ponowne uruchomienie mysql (restart usługi mysql) naprawiło problem:
źródło