質問 > 管理機能 > 受注管理 》 受注登録で「Out of memory」が発生しています。 |
管理機能
スレッド表示 | 古いものから | 前のトピック | 次のトピック | 下へ |
投稿者 | スレッド |
---|---|
Coinpad |
投稿日時: 2017/5/22 23:08
対応状況: 解決済
|
半人前 登録日: 2011/9/18 居住地: 投稿: 27 |
Re: 受注管理 》 受注登録で「Out of memory」が発生しています。 GMOさんから連絡がありましたので、ご報告します。
1. メモリ使用上限値「160MB」について。 これはApacheのメモリ使用上限値だそうです。 GMOさんでは問題発生後、解決方法として上記値に設定したらしいです。 尚、Apacheの設定値変更のため使用者側では何も変更ができません。 これは今後独自でクラウド環境にてApacheを建てる方のために説明します。恐らく以下の設定値を変更したと思われます。
上記設定値の各々は以下のURLにて調べてみてください。
2. PHPのmemory_limitについて これはPHPがメモリを使用する際の設定であるため、レンタルサーバー最大限のメモリ設定をお勧めします。何もしないと「128MB」になっていると思います。 弊社は「memory_limit=512M」にしました。 ※ 処理速度が少しアップされます。 尚、php.iniの設置方法は、PHPモジュールが存在する全てのフォルダーに同一のphp.iniを設置するらしいです。
以上になります。 レンタルサーバーは定額で利用できるメリットはありますが、システム関連の詳細な情報は殆どオープンされていません。 従って、今までの説明であったようにレンタルサーバー毎の使用できるシステムの範囲(Apacheメモリの使用上限値、PHPのmemory_limit)を事前に調べて活用すると、より効果的にレンタルサーバーが活用できるかと思います。 では、皆さん方の作業に幸運を~ |
Coinpad |
投稿日時: 2017/5/17 22:54
対応状況: −−−
|
半人前 登録日: 2011/9/18 居住地: 投稿: 27 |
Re: 受注管理 》 受注登録で「Out of memory」が発生しています。 kaendaikoさん
情報、ありがとうございます。 弊社は標準モジュールをそのまま利用しています。 うまく使える範囲内での前提で。修正を加えてもよいのですが時間とコストが掛かるので辞めました。 ただ、一部の拡張モジュールは使用しています。(決済モジュールとか、その他) メモリ使用上限値「160MB」についてはGMOさんに宿題として出しています。その他にもいくつか情報提示を宿題として出していますので、 何か連絡があったらご報告します。GMOさんによれば時間が掛かるらしいです。 |
kaendaiko |
投稿日時: 2017/5/17 0:35
対応状況: −−−
|
半人前 登録日: 2017/5/11 居住地: 投稿: 20 |
Re: 受注管理 》 受注登録で「Out of memory」が発生しています。 Coinpad さん
なるほど、では、Coinpadさんの環境でも上限はサーバで160MBになっていそうですね。Coinpadさんのビジネス量ですと確かに256MBくらいは欲しいところですね。 同じ契約プランであれば、GMOさんとしては、同じ上限にするかと思いますが、そのあたりの上限を何MBにするかなどを、今、GMOさんで協議中なのだと思います。GMOさんの協議の内容は教えていただいていませんが、協議の結果は後日ご案内しますとのことでしたので、そこではっきりするかと思います。 256MBとかにしていただけるとよいですね。 ---- ちなみに、Coinpadさんの環境でも、160MBになって当初問題の受注登録画面の方は表示できるようになりましたでしょうか。 私どもの受注登録画面のカスタマイズコード行数は、 ・テンプレートedit.tpl:100行追加(半分程度はJavaScript) ・クラスLC_Page_Admin_Order_Edit_Ex.php:1000行追加 ・その他使用クラスSC系_Ex.php+Helper系_Ex.php:数百行追加 です。このレベルでは、160MBで正常動作しています。 ここでテンプレートに比べてクラスの方が不自然に肥大化していますのは、フロント側からボタン押下で注文キャンセルできるようにしたため(また、複数画面で受注登録編集を利用する可能性もあり)、注文や在庫に排他制御なども組み込んだためです・・ |
Coinpad |
投稿日時: 2017/5/17 0:29
対応状況: −−−
|
半人前 登録日: 2011/9/18 居住地: 投稿: 27 |
Re: 受注管理 》 受注登録で「Out of memory」が発生しています。 kaendaikoさん
確認方法は同じですが、以下のように作ってみました。 結果は「160MBで Out of memory」になりますね。
上記テスト内容を踏まえてGMO側に再度確認してみます。 |
kaendaiko |
投稿日時: 2017/5/17 0:10
対応状況: −−−
|
半人前 登録日: 2017/5/11 居住地: 投稿: 20 |
Re: 受注管理 》 受注登録で「Out of memory」が発生しています。 Coinpad さん
ありがとうございます。試してみたところ256MBになりますが、これはPHPとしての設定ですので、512MBにも-1(無制限)にも設定可能です(phpinfo()で確認できます)。 この256MBのときでも、先の簡単なプログラム(php.iniファイルと同じドメイン直下に配置)で確認しますと、160MBで Out of memory エラーになりますので、サーバとしてはPHPプロセスに対し、私の環境では160MBで制限されているのだと思います。 Coinpadさんの環境で以下のファイルを設置して、 http://設置ディレクトリ/memory_test.php?max_num=100000000 などとして、アクセスすると256MBのOut of memoryになりますでしょうか。もし、256MBのエラーになるようでしたら、Coinpadさんの環境では上限が256MBにしていただけたものと思います。 -----memory_test.phpの中身---- <?php $MAX_NUM = $_GET['max_num']; $a = []; for($i=0;$i<$MAX_NUM;$i++){ $a[] = $i; } echo memory_get_usage() ."\n"; ?> --- 追記:あ、申し訳ありません、元々、どんなふうにPHPでメモリ使用量が増えていくのか、何MBくらいでメモリ不足になるかを調べるためのコードでしたので、短縮して以下でもよいかと思います。100000000は適当な大きな値なら何でもよいです。 <?php $a = []; for($i=0;$i<100000000;$i++){ $a[] = $i; } ?> |
Coinpad |
投稿日時: 2017/5/16 23:52
対応状況: −−−
|
半人前 登録日: 2011/9/18 居住地: 投稿: 27 |
Re: 受注管理 》 受注登録で「Out of memory」が発生しています。 kaendaikoさん
情報、ありがとうございます。 「memory_limit = -1」この内容は分かりますが、以下の方法を試してください。
上記の「memory_limit」が設定値になっていれば、その分メモリ使用上限値を伸ばすことが出来るかと思います。 では、試してみて結果を教えてください。 |
kaendaiko |
投稿日時: 2017/5/16 23:15
対応状況: −−−
|
半人前 登録日: 2017/5/11 居住地: 投稿: 20 |
Re: 受注管理 》 受注登録で「Out of memory」が発生しています。 Coinpad さん
ちょうど同時頃に投稿したようですね。以前も128MBでしたか。以前は128MBでも2000件処理できていらしたのでしょうか。もしできていらしたのであれば、メンテ後も2000件処理できるメモリ使用上限にして欲しいところですね。 先の投稿の通り、私の2つのサーバの環境では、160MBまで上限を上げていただけたようです。 おっしゃる通り、php.iniにてメモリ使用上限を設定できますが、memory_limit = -1 にすると上限なしになります。その場合でも、先の簡単なプログラムで確認しても160MBでOut of memoryエラーになりますので、現在のところ、私の環境では、memory_limitで設定できる値は最大で160MBのようです。 ---- 2000件の処理についてですが、バッチ処理化して画面表示処理部分だけでも無くしてメモリ節約するのはいかがでしょう。またしても思い付きレベルで申し訳ございませんが・・私どもでは、管理画面のバックアップ管理画面の部分を流用して、毎日定時に自動的にバックアップをするバッチ処理を作りましたので、同じような方式でできるかもしれません。お使いのプラグインが既にバッチ処理的な方式でしたらごめんなさい。 |
Coinpad |
投稿日時: 2017/5/16 22:52
対応状況: 解決済
|
半人前 登録日: 2011/9/18 居住地: 投稿: 27 |
Re: 受注管理 》 受注登録で「Out of memory」が発生しています。 kaendaikoさん
情報、ありがとうございます。 デフォルトは「memory_limit=128M」です。 管理者画面 》システム設定 》システム情報 にて確認すると上記内容は確認できます。しかし、これはインストール時の初期設定値のまま何も意識せず使用(システム運用)するのが殆どだと思われます。 EC-CUBEでは登録データが少し増えていくと、管理者機能で使用する各種機能(モジュールに)メモリが足りないことに気が付きません。今回弊社のようなケースが発生すると思われますが、問題が発生してからは何が原因で(問題で)さっぱりの状況になるかと思います。今回は偶々GMOさんが「64Bit化する作業」で弊社は問題が発見され、より詳細を確認したところ「使用メモリの設定」をしていないことに気が付きました。 GMOさんの今回レンタルサーバーにおいては「使用メモリ制限値」があります。何も設定しない限り「128M」になります。 しかし、EC-CUBE側に登録データが増えると管理者側で使用しているモジュールにおいてはメモリが足りなくなり、今回のようなエラーが発生したり、画面が白くなったままになったりします。 これらを改善するためには「メモリ使用上限値」を再設定する必要があります。弊社はメモリ使用上限値を最大に変更しました。 結果、先日の連絡での2,000件は1,000件までは処理可能になりました。 レンタルサーバーにおいて、この「メモリ使用上限値」は異なるらしいので、お客様サービスセンターを通して、このメモリ使用上限値を先にご確認いただき、その上限値に設定しなおすことで、レンタルサーバー最大限のメモリリソースが活用できるかと思います。 メモリ使用上限値の設定方法については、レンタルサーバーの「php.ini」作成ルールをご確認ください。 その他にも調べてますので、新たな情報が入ったら再度ご報告します。 |
kaendaiko |
投稿日時: 2017/5/16 22:40
対応状況: −−−
|
半人前 登録日: 2017/5/11 居住地: 投稿: 20 |
Re: 受注管理 》 受注登録で「Out of memory」が発生しています。 その後、2つ目のサーバの方もメモリ使用上限を上げていただき、こちらの方もEC-CUBEが正常動作するようになりました。今後は、現在の一時的な対応をどうするのかをGMOさんの担当部署で協議中のようで、契約としてどうするのかというサービスレベルのお話しになりそうです。
技術的には、振り返ってみますと、結局のところ、OSとPHPの64bit化によりOSとミドルウェアでメモリ使用量が増えたことで、EC-CUBEでメモリ不足エラーになったということになります。一般的にも、32bit ⇒ 64bit でメモリ使用量が20~30%くらいは増えるようです。 具体的には、32bit時には128MBで足りていても、64bit時でもメモリ使用上限が128MBのままですと、32bit時にぎりぎり128MB使っていたEC-CUBE部分等は64bit時には166MB(=128MB×130%)を使用するので、128MBをオーバーしてしまっていたのだと考えられます。 先の簡単なプログラムの結果でも、現在、まさに160MBくらいでOut of memoryでエラーになりますので、GMOさんでもメモリ使用上限を128MBから160MBくらいに30%増しにしたのだと思われます。 今後は、GMOさんとの契約的なお話しになると思いますが、PaaS型のOS+ミドルウェア+αのレンタルサーバで、ユーザはOS+ミドルウェア部分のコントロールはあまりできませんので、今回だけでなく今後もOSやミドルウェア部分のメモリ使用増大分はメモリ使用上限に含まない契約になることを期待しております。もし含むのであれば、今回の場合は、32bitにするか64bitにするかはユーザに選択させて欲しいかなと思います。 以上が今回の顛末でありました。 |
kaendaiko |
投稿日時: 2017/5/16 7:54
対応状況: −−−
|
半人前 登録日: 2017/5/11 居住地: 投稿: 20 |
Re: 受注管理 》 受注登録で「Out of memory」が発生しています。 Coinpad さん
64bit化メンテ以前は、PHPのmemory_limitは128MBに設定されていましたか?私どもはmemory_limitは未指定でしたので、たぶんデフォルトのMasterValueの128MBだったのだろうと思います。上記の簡単なプログラムで確認したところ、メンテ後は最大110MB程度のメモリ上限になっていました(110MBでOut of memory)。ということは、私どものEC-CUBEもメモリ使用のピークは110~128MBで、ほぼギリギリで正常動作していたのかもしれません。ただ、私どもはまだ本番稼働しておりませんので、これまでは128MBでも動作していたのかもしれませんが、本番稼働後は128MBだと厳しいのかもしれませんね。スモールスタートなため、処理件数を気にしていませんでしたが・・情報ありがとうございます。 今回のGMOさんへの調査協力時、試しにmemory_limitを128MBにして、上記の簡単なプログラムで確認すると、確かに128MBでOut of memoryエラーになりますし、256MB等にすると160MBでエラーになります。ということは、GMOさんは、160MBまでPHPプロセスに対するメモリ上限を一時的に上げたものと思われます(160MBまでならmemory_limitの設定も有効)。160MBであれば、私どもは当面は大丈夫そうですが、Coinpadさんの状況ではいかがでしょうか。もし必要あれば、上記の簡単なプログラムを使ってみて、PHPの設定ではなくサーバの設定による実際のメモリ上限をご確認ください。 もしメモリ上限がCoinpadさんの状況で不足するような設定しか許されない場合は、送り状番号登録は使っておりませんので詳しくはわからないので、思い付きレベルで申し訳ございませんが・・・件数の問題であれば、 ・一回でのCSVダウンロード件数を条件を絞って減らし、複数回ダウンロードする運用にする ・決済モジュールで特に2000件等のループ処理をする辺りでメモリ消費が多いコードやメモリ強制解放できるようコードを見直す(上記プログラムにもあるmemory_get_usage() を使うとその時点のメモリ使用量がわかります) ・一回のPHPプロセスでCSVを全件出力処理しないで、複数回のPHPプロセスでCSVを段階出力処理するようカスタマイズする(複雑な処理になりそうですが・・) などの、業務運用かカスタマイズをすることで、対応できるのかもしれません。本当に思い付きレベルで申し訳ございません。 [追伸] よいですね、東京での機会がございましたら、メールいたします。 |
(1) 2 » |
スレッド表示 | 古いものから | 前のトピック | 次のトピック | トップ |