ubuntu 12.04 64ビットマシンで重い作業を行うphp（バージョン5.3.10）cliアプリケーションがあります。このスクリプトは、受け取るデータセットによっては長時間実行される場合があります。これらのデータセットは、多数の XML、画像、および MS doc ファイルを含む zip ファイルです。
以前は、このスクリプトはいくつかのシステム コマンド (shell、perl、java) を使用してタスクを完了していました。その時は問題はありませんでした。最近、複数の同時呼び出しに RabbitMQ を使用するようにこれらのスクリプトをアップグレードし、cron ベースの作業から自動回復と監視のために Supervisord に移行し、シェルの呼び出しを回避するために php のコア ライブラリと関数を可能な限り使用しました。
現在、本番環境にデプロイした後、ZipArchive を使用してアーカイブを作成した行で、スクリプトが致命的にクラッシュすることがわかりました。具体的には、そのメソッド「open」と「addFile」のみ。問題のあるデータセットでこれを何度もテストしたところ、実際の問題はここにあることがわかりました。
スローされたエラーは、「致命的なエラー: 最大実行時間が 300 秒を超えました」でした。私たちはphpの実行時間の制限について知っており、php.iniと「/etc/php5/conf.d」フォルダーの下のすべての設定を再確認し、「max_execution_time」が0に設定されているすべての場所を確認しました。スクリプトのsapiも確認しましたモードは「php_sapi_name()」を使用した「cli」でした。ini_get("max_execution_time") も 0 を返します。
スクリプトがsupervisordで管理されている場合でも、上記のモードと実行制限は同じです。この「max_execution_time」の 300 秒の制限がどこからトリガーされているかを特定できませんでした。
もう 1 つ、このメッセージでクラッシュしたとき、スクリプトは実際には 600 秒以上実行されていました。また、ZipArchive だけで 300 秒以上かかる場合にのみ、これが発生すると考えています。しかし、よくわかりません。また、これが発生したときに作成される部分的な zip アーカイブは、280 MB から 290 MB の間です。そこで、レポジトリから php ソースをダウンロードし、簡単な grep を実行して、ZipArchive のコード ベースにそのような制限があるかどうかを確認しました。何も見つかりませんでした。
現在、回避策として ZipArchive php コードをシェル コマンドに置き換えようとしています。まだテストしていません。私たちの調査結果をすぐにここに投稿します。
以前にそのような問題に直面した人はいますか? これは ZipArchive に関連するものですか? 巨大なアーカイブを作成するために ZipArchive を使用することは推奨されますか? クラッシュする前に作成された部分的な zip ファイルは、280 MB から 290 MB の間でした。