WordPress をセットアップしているときに、この種のエラーが報告されていることがわかりました。オンラインの解決策はすべてコピペであり、この拡張機能をインストールしていないことに驚きました。ただし、APC 拡張機能をインストールしました。どちらの拡張機能も、基盤となるコードのサポートのためにサーバーを最適化し、キャッシュ共有を実現します。 APC をオフにすると、エラーは報告されなくなります。
通常、これは eaccelerator の問題が原因です
解決策は次のとおりです:
Windows の php のバグ
参考:
最初の可能性:
PHP の eaccelerator 拡張機能を削除します
これで問題は解決しますが、システムへの負担が増加する可能性があります
eaccelerator は主にシステム リソースを節約するためのものです
具体的な方法は php.ini を見つけることです
設定をお手伝いする場合、通常は c:/php/php.ini または c:/winnt/php.ini または c:/windows/php.ini にあります
削除
もちろん、マシンの問題が深刻でなければ、ea は非常に優れた Php キャッシュ + 高速化ソフトウェアです
zo と併用すると、システムの負荷が約 50% ~ 80% 軽減されます。 %、負荷容量、速度、効率が約 200% 向上します
2番目の可能性
session_save_path は実際の物理パスを設定する必要があり、ディレクトリには U ホストの 0777 と同様に全員のすべての権限が必要です
3 番目の可能性
c:/winnt/temp または c:/windows/temp
これも、U ホストの 0777 と同様に、全員のすべてのアクセス許可を必要とします
4 番目の可能性
メモリが著しく不足しています。問題がある場合は、メモリを 2 つずつ追加するのが最適です。たとえば、1G のメモリを追加するのが最適です。 2 つの同一の 512M メモリ。そうしないと、デュアルチャネルが有効にならず、効果が平凡になります
ZendOptimizer と php の組み合わせはあまり良くありません
別のバージョンを試してください
現時点でより安定している組み合わせは
php4.3.11+zo 2.5.10a
または php4.4.1+zo 3.0 beta2 です。
6番目の可能性
これは主に win2003 を使用するユーザーに属します
アプリケーション プールに制限が設定されていますたとえば、リサイクルする時間、使用される最大メモリ量など
これらの設定は必ずこの古典的な PHP エラーを引き起こす可能性があります
これは PHP のバージョンの問題だと言われていますが、実際にはそうではありません。
2、2003 を使用しましたか? プール内の制限などを設定しましたか? 調整して再試行してください。 php.ini 内の 2 つの場所は設定されておらず、一部のプログラムではこれらを使用する必要があります
。
A
この行が php.ini ドキュメントで機能するように、;upload_tmp_dir 行のコメント文字、つまりその前のセミコロン「;」を削除します。 Upload_tmp_dir は、アップロードされたファイルが保存される一時パスを定義するために使用されます。ここで、次のように絶対パスを定義することもできます。 もちろん、この時点では、d:upload ディレクトリには読み取りおよび書き込み権限が必要です。 。
upload_tmp_dir = "c:windowstemp" に設定します
B
このようなエラーステートメントは通常、php.ini の session.save_path 項目が適切に設定されていないために発生します。解決策は、session.save_path と session.cookie_path を
session に設定することです。 .cookie_path = "c:windowstemp"
(この設定が正しいかどうかはわかりません。試したことはありません。)
c: ディレクトリに一時ディレクトリを作成することもできます (eaccelerarot はたまたま以前に使用されていました) 、このようなフォルダーが作成されました)
PHP でアクセス違反が発生した場合の解決策の概要
この問題は対処が簡単ではなく、長い間多くの Web マスターを混乱させてきました
PHP の公式 Web サイト http://bugs.php.net/
では、2 ~ 3,000 ページのレポートが見つかります。11 の小さなバージョンを作成した後でも、まだ完全には解決されていません。それ
http://bugs .php.net/search.php?c ...ess&x=8&y=9
現時点では、過去数年間の私のメンテナンス経験と私のプライベートソリューションのいくつかを提供します
最初の可能性:
php の eaccelerator 拡張機能を削除します
これで問題は解決しますが、システムへの負担が増加する可能性があります
具体的な方法は、php.ini を見つけることです
設定をお手伝いする場合、通常は c:/php/php.ini または c:/winnt/php.ini または c:/windows/php.ini にあります
削除
コードをコピーします
もちろん、マシンの問題が深刻でなければ、ea は非常に優れた Php キャッシュ + 高速化ソフトウェアです
zo と併用すると、システムの負荷が約 50% ~ 80% 軽減されます。 %、負荷容量、速度が向上し、効率は約 200% になります。 引用:
2 番目の可能性
session_save_path には実際の物理パスを設定する必要があり、ディレクトリには U ホストの 0777 参照と同様に全員のすべてのアクセス許可が必要です。
3 番目の可能性
c:/winnt/temp または c:/windows/temp
も必要です全員 U ホストの 0777 参照に似たすべての権限:
4 番目の可能性
メモリが著しく不足しています。確認してください。問題がある場合は、メモリを追加してください。できれば一度に 2 つずつ
たとえば、1G を追加しますメモリ、できれば同一の 512M を 2 つ追加します。それ以外の場合、デュアル チャネルは有効にならず、効果は非常に平均的です。 引用:
5 番目の可能性
ZendOptimizer と php の組み合わせはあまり良くありません
別のバージョンを試してください
現在の安定した組み合わせは
php4.3.11+zo 2.5 です。 .10a
または php4 .4.1+zo 3.0 beta2 引用:
6 番目の可能性
これは主に win2003 を使用しているユーザーのものです
アプリケーション プールに制限が設定されています
たとえば、リサイクルする時間、使用するメモリの量など
これらの設定は、この古典的な PHP エラーを引き起こす可能性があります
木はなくなってしまいました何百回もテストしてみると、ここで問題が発生すると確信しています。引用:
7番目の解決策
2003ユーザーは、実行中のアプリケーションプールの「パフォーマンス」-「WEBパーク」と「最大作業プロセス数」を変更することで解決できます
かつて、この問題を10に追加したユーザーがいました。完全に解決されました。