Witryna na żywo jest pusta w interfejsie lub trwa ładowanie i nigdy nie ładuje się

Stoję w obliczu najdziwniejszego problemu w historii Magento. korzystamy z wersji 1.9.0.

z ostatnich 2 miesięcy nasza działająca witryna jest „pusta” lub „ładuje się” dla używanych przeglądarek. Oznacza to, że w tej przeglądarce odwiedzaliśmy stronę wiele razy.

w niektórych przeglądarkach działa dobrze. w niektórych pokazuje puste.

ale backend działa poprawnie we wszystkich przeglądarkach.

mamy problem z Chrome, Mozillą, Operą i wszystkimi innymi przeglądarkami.

1) Jeśli wyczyścimy historię przeglądarki [pamięć podręczną i pliki cookie], niż działa.

2) Jeśli otworzymy tę samą stronę w oknie prywatnym, działa.

3) Jeśli otworzymy stronę w świeżo zainstalowanych przeglądarkach, będzie działać przez pewien czas. ponownie puste po skorzystaniu z witryny.

4) Jeśli wyczyścimy folder var / session, zacznie on działać przez pewien czas dla wszystkich przeglądarek. znowu strona pusta.

5) czasami strona będzie się ładować i nigdy się nie ładuje ....

Sprawdziłem system.log i wyjątek.log . ale wygląda na to, że nie ma z tym żadnych błędów. używamy https dla bezpiecznych stron. nawet my mamy na żywo aplikację Andriod dla tej strony. czasami otrzymujemy błędy krytyczne:

**Fatal error**: Allowed memory size of 536870912 bytes exhausted (tried to allocate 85 bytes) in /lib/Zend/Db/Statement/Pdo.php or lib/Varien/Object.php or /lib/Varien/Db/Select.php or app/code/core/Mage/Core/Model/Config.php

ustawiamy memory_limit = 1512 Mb w php.ini

w .htaccess mamy następujące pliki.

php_value memory_limit 1512M php_value max_execution_time 18000

odkomentowaliśmy to:

ini_set('display_errors', 1);

ale nie wyświetla się błąd w interfejsie użytkownika. To jest dziennik błędów Apache :

child pid 23845 sygnał wyjścia Błąd segmentacji (11), możliwa zrzutka w / etc / apache2

Naprawdę staram się rozwiązać ten problem. Czy ten problem jest związany z naszym kodem, czy ten problem dotyczy strony serwera?

czy plik cookie przeglądarki jest głównym problemem? Jeśli tak, co należy zrobić, aby rozwiązać problem z plikami cookie dla wszystkich przeglądarek. dlaczego zaczął działać po wyczyszczeniu folderu sesji?

napotykamy te problemy podczas przeglądania naszej witryny.

Najpierw włącz tryb programisty w swoim .htaccesspliku, dodaj następujące na końcu pliku:

SetEnv MAGE_IS_DEVELOPER_MODE "true"

Następnie edytuj index.phpi odkomentuj wiersz:

#ini_set('display_errors', 1);

Linia odniesienia:

• https://github.com/OpenMage/magento-mirror/blob/magento-1.9/index.php#L73

Następnie zaloguj się przez SSH i poszukaj pliku zrzutu pamięci /tmpjako wspomnianego błędu błędu segmentu. Czasami może to być również w katalogu /lub w katalogu głównym witryny sama na przykład: /var/www/html/videomergerapp/.

Jeśli nie możesz zlokalizować żadnych plików zrzutu pamięci, możesz chcieć dodać dodatkowe dyrektywy do PHP / Apache.

Spójrz tutaj:

• /server/470407/how-to-get-a-core-dump-from-apache-when-segfaulting
• http://www.cyberciti.biz/tips/configure-apache-web-server-for-core-dump.html

Gdy masz już plik (i) zrzutu pamięci, możesz użyć gdb(jeśli --enable-debug) był używany podczas konfiguracji PHP. Możesz dokonać tego ustalenia, wydając następujące polecenie z wiersza polecenia:

php -i | grep debuglub po prostu tworząc plik skryptu php w katalogu głównym serwera za pomocą: <?php phpinfo(); ?>w jego zawartości i przeglądaj plik za pomocą przeglądarki internetowej, aby zobaczyć wartości konfiguracyjne PHP.

• https://bugs.php.net/bugs-generating-backtrace.php

Jeśli nie został włączony, nie będziesz w stanie uzyskać pełnego śledzenia do samego PHP, ale tylko wywołania systemowe wyższego poziomu i / lub śledzenie apache:

Jeśli masz dostęp do pliku zrzutu pamięci, wydając coś takiego, otrzymasz ślad, który pomoże znaleźć punkt awarii:

gdb /usr/local/apache2/bin/httpd /tmp/core.2027

Jeśli występują tylko przypadkowe problemy z interfejsem użytkownika, a nie z interfejsem użytkownika, większość znaków wskazuje na możliwy problem z kodowaniem szablonu. Po pojawieniu się pustych stron (i / lub wyświetla się komunikat o błędzie, jeśli włączono tryb programisty i wyświetlanie błędu). Zaloguj się do administratora i wyłącz wszystkie pamięci podręczne oraz opróżnij wszystkie pamięci podręczne i magazyny pamięci podręcznej.

Następnie przejdź do app/etc/local.xmli ustaw wartość „wyłącz lokalne moduły” na „prawda”.

<disable_local_modules>true</disable_local_modules>

Spowoduje to wyłączenie ładowania modułu automatycznego przez moduł ładujący app/code/local.

Aby wyłączyć moduły społecznościowe, najłatwiej jest przejść przez każdy z plików definicji modułów znalezionych app/etc/modulesi wyłączając, ustawiając dla aktywnego węzła wartość false:

<active>false</active>

W ten sposób możesz wykluczyć, że moduł zewnętrzny powoduje źródło problemu w procesie eliminacji. UWAGA: Nie możesz disable_local_modulesi po prostu przechodzisz przez wszystkie swoje moduły NON-CORE (wszystko, co Mag_ * zignoruje!).

Jeśli nadal występują problemy, spróbowałbym tymczasowo spróbować pakietu szablonów domyślnych, przechodząc do opcji System> Projekt i definiując nowy projekt czegoś takiego jak domyślny lub podstawowy. Jeśli standardowe pakiety szablonów działają, będziesz wiedzieć, że przyczyną błędu jest występowanie w plikach projektu szablonu (.phtml).

Wiele szablonów, z którymi się zetknąłem, źle wykorzystuje się Mage::getModel()->load()w pętlach foreach, ponieważ jest to zła praktyka i może ostatecznie pochłonąć dużą ilość pamięci serwera i zasobów.

Magento ma narzędzie do analizy kodu, które może pomóc w skanowaniu plików szablonów w celu ustalenia, czy któreś z tych złych fragmentów kodu:

• https://github.com/magento-ecg/magniffer

Dalsza lektura:

• Podstawy debugowania sklepu Magento

Ponadto może być pomocne dla wszystkich, w której pamięci podręcznej i sesjach używasz, które są zdefiniowane app/etc/local.xml.

Mam nadzieję że to pomoże!

Domyślam się, że w twoim kodzie jest rekurencja. Edycja pliku lib/Varien/Db/Adapter/Pdo/Mysql.phpi zestaw $_debugi $_logCallStacktrue. Powinno to zarejestrować stos wywołań w var/debug/pdo_mysql.logpliku, co powinno dać ci wyobrażenie, czy w kodzie jest rekurencja, gdy ładowanie trwa wieczność. Pamiętaj, że ten plik będzie się bardzo szybko powiększał, więc najlepiej go włącz, gdy myślisz, że problem zaczął się na stronie.

Innym sposobem jest wyłączenie błędnych modułów / rozszerzeń, które Twoim zdaniem mogą to powodować. Może to być również twoje proste, konfigurowalne rozszerzenie cen, spróbuj je tymczasowo wyłączyć i sprawdź, czy to pomoże w rozwiązaniu problemu.

Miałem ten sam problem na stronie klienta. Sprawdź swoje Magento pod kątem złośliwego oprogramowania.

Jest to dobrze znany scenariusz, zwykle jest to walware przekierowujący treść postu użytkownika na zewnętrzną stronę internetową.

Zacznij sprawdzać index.php, zwykle go zhakują. Przewiń kod do końca, sprawdź także w prawo i między komentarzami w nagłówku licencji. Hakerzy służą do ukrywania kodu w ten sposób.

Masz „wieczne ładowanie”, ponieważ próbuje skontaktować się ze stronami internetowymi zablokowanymi przez Twojego dostawcę usług internetowych.

Znalezienie złośliwego oprogramowania, wyszukiwanie ciągów „base64”, „eval”, „mcrypt” powinno być dość łatwe.

Doświadczyłem podobnego zachowania na Magento, który miał dwie strony internetowe. Witryna ładowała się dobrze przez kilka stron, a następnie ładowała się na zawsze.

Konfiguracja podstawowych adresów URL była nieprawidłowa. Ustawienie Bezpiecznego podstawowego adresu URL zostało ustawione na niewłaściwą stronę internetową, a Niepoprawny podstawowy adres URL został ustawiony poprawnie.

Aby to naprawić, jeśli administrator nawet nie działa poprawnie, należy zmienić wartości w tabeli core_config_data dla właściwej strony internetowej, tj. Ustawić właściwy adres URL za pomocą „http: //” i ukośnik w polu wartości odpowiadającym ścieżka „web / unsecure / base_url” i „web / secure / base_url” dla właściwego scope_id reprezentującego identyfikator strony.

Pamiętaj, że bezpieczny adres URL to http tylko dlatego, że była to witryna demonstracyjna.