ライブサイトはフロントエンドで空白であるか、ロードし続けてロードしない

私は今までにMagentoで奇妙な問題に直面しています。1.9.0バージョンを使用しています。

過去2か月間、私たちのライブサイトは使用済みのブラウザに対して「空白」または「読み込みを維持」しています。このブラウザでは、何度もサイトにアクセスしました。

一部のブラウザでは、正常に動作します。いくつかの空白を示しています。

しかし、バックエンドはすべてのブラウザで正常に機能しています。

クロム、モジラ、オペラ、その他すべてのブラウザで問題に直面しています。

1）ブラウザの履歴[キャッシュとCookie]をクリアすると、動作しなくなります。

2）同じウィンドウをプライベートウィンドウで開くと、その機能が動作します。

3）新しくインストールしたブラウザでサイトを開くと、しばらく動作します。サイトを使用した後は再び空白になります。

4）var / sessionフォルダーをクリアすると、しばらくの間すべてのブラウザーで機能し始めます。再びサイトの空白。

5）時々、サイトはロードし続け、ロードされません。...

system.logとexception.logを確認しました。しかし、これに関連するエラーはないようです。安全なページにhttpsを使用しています。このサイト用のAndriodアプリもあります。時には致命的なエラーが発生します：

**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

php.iniでmemory_limit = 1512 Mbを設定します

.htaccess私たちは、ファイルを次のようしています。

php_value memory_limit 1512M php_value max_execution_time 18000

これのコメントを外しました：

ini_set('display_errors', 1);

ただし、フロントエンドにエラーは表示されません。これはApacheエラーログです：

子pid 23845終了信号セグメンテーションエラー（11）、/ etc / apache2にコアダンプの可能性あり

この問題の解決に本当に苦労しています。この問題はコードに関連するものですか、それともサーバー側に関連するものですか？

ブラウザのクッキーは主な問題ですか？その場合、すべてのブラウザーでこのCookieの問題を解決するために何をする必要がありますか。セッションフォルダーをクリアすると、なぜ機能し始めたのですか？

サイトを閲覧するときにこれらの問題に直面します。

最初に.htaccessファイルで開発者モードを有効にし、ファイルの最後に次を追加します。

SetEnv MAGE_IS_DEVELOPER_MODE "true"

次にindex.php、行を編集してコメント解除します。

#ini_set('display_errors', 1);

参照されている行：

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

次に、SSH経由でログインし/tmp、セグメントフォールトエラーの説明に従って、コアダンプファイルを探します。場合によっては、ルート/またはサイト自体のルートディレクトリにもある場合があります/var/www/html/videomergerapp/。

コアダンプファイルが見つからない場合は、PHP / Apacheにいくつかのディレクティブを追加することをお勧めします。

ここを見てください：

• /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

コアダンプファイルを取得しgdbたら--enable-debug、PHPの構成時に使用された（if ）を使用できます。コマンドラインから次を発行することにより、この決定を行うことができます。

php -i | grep debugまたは、次のコマンドを使用してWebサーバーのルートにphpスクリプトファイルを作成します。<?php phpinfo(); ?>その内容をWebブラウザーで表示して、PHP構成値を確認します。

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

有効になっていない場合、PHP自体に完全なバックトレースを取得することはできませんが、より高いレベルのシステムコールおよび/またはApacheバックトレースのみを取得できます。

コアダンプファイルにアクセスして、次のようなものを発行すると、障害箇所を見つけるのに役立つバックトレースが得られます。

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

フロントエンドでランダムな問題のみが発生し、バックエンドでは発生しない場合、ほとんどの兆候はテンプレートコーディングで発生する可能性のある問題を示しています。空白のページが表示されたら（および/または開発者モードとエラー表示を有効にしている場合はエラーが表示されます）。管理者にログインして、すべてのキャッシュを無効にし、すべてのキャッシュとキャッシュストレージをフラッシュします。

次にapp/etc/local.xml、ローカルモジュールの無効化をtrueに設定します。

<disable_local_modules>true</disable_local_modules>

これにより、オートローダーがのモジュールをロードできなくなりますapp/code/local。

コミュニティモジュールを無効にするにはapp/etc/modules、次のようにアクティブノードをfalseに設定して、無効になっている各モジュール定義ファイルを確認するのが最も簡単です。

<active>false</active>

このようにして、サードパーティのモジュールが消去プロセスによって問題の原因を引き起こしているかどうかを除外できます。注：disable_local_modulesすべてのNON-COREモジュールを実行することはできません（Mage_ *は無視してください）。

それでも問題がある場合は、[システム]> [設計]に進み、デフォルトまたはベースなどの新しいデザインを定義することにより、デフォルトのテンプレートパッケージを一時的に試行します。ストックテンプレートパッケージが機能する場合、エラーの原因がテンプレートデザインファイル（.phtml）にあることがわかります。

私が遭遇した多くのテンプレートは、Mage::getModel()->load()foreachループ内で使用するのは良くありません。これは悪い習慣であり、最終的に大量のサーバーメモリとリソースを消費する可能性があるからです。

Magentoには、テンプレートファイルをスキャンして、これらの不良コードの有無を判断するのに役立つコード分析ツールがあります。

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

参考文献：

• Magentoストアをデバッグするための基礎

また、使用しているキャッシュとセッションストレージがで定義されていることは、誰にとっても役立つかもしれませんapp/etc/local.xml。

お役に立てれば！

私の推測では、コードに再帰があります。編集したファイルlib/Varien/Db/Adapter/Pdo/Mysql.phpとセット$_debugと$_logCallStacktrueに。これにより、コールスタックがvar/debug/pdo_mysql.logファイルに記録され、ロードに永遠にかかるときにコードに再帰があるかどうかがわかります。このファイルは非常に急速に成長し続けるため、問題がサイトで始まったと思われる場合は理想的に有効にしてください。

他の方法は、これを引き起こす可能性があると思われるバグのあるモジュール/拡張機能を無効にすることです。これは単純な設定可能な価格拡張でもあります。一時的に無効にして、問題の防止に役立つかどうかを確認してください。

顧客のWebサイトでも同じ問題が発生しました。Magentoでマルウェアを確認してください。

これはよく知られたシナリオです。通常は、ユーザーの投稿のコンテンツを外部のWebサイトにリダイレクトするウォールウェアです。

index.phpのチェックを開始すると、通常はハッキングされます。コードを最後までスクロールし、ライセンスヘッダーの右側とコメント行の間を確認します。ハッカーは、この方法でコードを隠すために使用されます。

ISPがブロックしたWebサイトに接続しようとするため、「永久にロード」されます。

マルウェアの検索、「base64」、「eval」、「mcrypt」文字列の検索は非常に簡単です。

2つのWebサイトがあるMagentoで同様の動作を経験しました。このサイトは、数ページにわたって適切にロードされ、その後ずっとロードされていました。

ベースURLの構成が間違っていました。安全でないベースURLが正しく設定されている間に、安全なベースURL設定が間違ったWebサイトに設定されました。

管理者が適切に動作しない場合でもこれを修正するには、適切なWebサイトのcore_config_dataテーブルで値を変更する必要があります。つまり、「http：//」と値フィールドのWebサイトIDを表す正しいscope_idのパス「web / unsecure / base_url」および「web / secure / base_url」。

セキュアなURLは、デモWebサイトであるため、httpのみであることに注意してください。