2018年
平成30年 昭和93年
141日経過 残り224日
21
営業日
05月 月曜日
May 皐月 Mon 仏滅
May Monday
今月営業日
008 / 019 日
今月休業日
002 / 012 日
今年営業日
137 / 241 日
お知らせNo.339. SSLはじめました。 2017/12/18
お知らせNo.305. ユーザー様整理いたします 2017/09/28
お知らせNo.223. Firefoxのパスワード記憶について 2017/03/23
お知らせNo.218. プラグイン機能の説明を作成しました。 2017/03/22
お知らせNo.211. LINEを公開しました。 2017/03/17




USER:
PASS:
新規登録
  • BBSみしお より
  • BBSみしお より
  • BBSみしお より
1人の会員

8
Unique
Visitors
Powered By Google Analytics
インフォトップ公告表示プラグインの実演です。

Webサーバーのめもりえらーについて

担当@みしお 開始日:2017年10月20日 更新日:2017年10月20日

ウェブサーバーでファイルのやりとりをしたりとかするとときどきメモリエラーがでてきたりすることがあります。
簡単にちぇっくしたいところは次の通りです。

どうしてたりなくなるの?
いまつかってるめもりは?
どれくらいいるの?

どうしてたりなくなるの?
ファイルとかデータを一時的にメモリがうけとったりしたとき大きさがすぎるとエラーになります。
メモリにのらなくなるからです。

いまつかってるめもりは?
PHPのコマンドなんかで確認できます。

//memory_limit メモリみる サーバー内部の演算容量
//post_max_size 転送総量 POSTプロトコルであたまうちにする量 これでひっかかると移行のレセプト動作がNullります
//upload_max_filesize 到着したファイルが受け入れ可能な上限 これ以上だと演算せずに返しますがPOST通過していればここまではきます(tmpには入りません)

//いまのメモリ量をみる
ini_get('memory_limit');
//以降の当該プロセスにおけるメモリ量を変える
//(注 このプロセス動作内だけです
$newLimit = 64;
ini_set('memory_limit', $newLimit.'M');
//ほか 設定の雰囲気はこんなかんじ
$max_filesize = ini_get('post_max_size')*1024;
ini_set("memory_limit" ,round($max_filesize/1024)."M");
ini_set("post_max_size" ,round($max_filesize/1024)."M");
ini_set("upload_max_filesize" ,round($max_filesize/1024)."M");

どれくらいいるの?
ふつうにWebサーバーをうごかしていると20メガくらいでなんとかなります。
人気がでていっぱい閲覧されてもテキストのチャージにそんなにつかわれません。
画像を描画させたり、ファイルや一塊のデータをあつかうと、そのデータがそろうまでメモリを占領するのでたりなくなったりします。
PHPのプログラムで大きさを確認したりその分だけ準備したりもできるので常にがばーっとあけておかなくても、転送ファイルごとにサイズを調整して確保してあげることもできます。

きになるサイズは
転送の最大受付量
ファイルの最大受付量
展開のの最大受付量
とありまして、これらを設定した上限を超えた分がくるとエラーになるほか、データ展開の上限をこえるとエラーがでます。

プログラムは複合的に動くのでどの部分で引っかかるのかは精査が必要です。

まあだいたいあげとけば大丈夫です。

かるく、設定したものが反映されているかをみて、他のプログラムで抑制されていないことが確認されたら設定どおりだと思います。
なにか設定したものと数値がちがっていれば、必要なものが動作しているか確認する必要があります。

ファイルの書き込み損じとかそういうのが多いかと思いますがGDI+を使っていると画像の大きさオーバーででたりもします。
うけとったファイルごとに容量確保するというのも対応策です。

もともとファイルの大きさは受け取る上限の設定だけでとくにPOST、FILESIZEはメモリエラーと関係ありませんが、一旦内部でうけたファイルを操作する、読み込むなどの場合にメモリに乗せることがあります。
このタイミングでうけとったファイルがオーバーしていたら、メモリエラーが内部で出ます。
受け取りサイズを抑制することで防げたりもします。
また物理的なエラーででたり、読み込みすぎて停止してしまうこともあります。

こまかい話をすると転送されたデータはサーバーのWebプログラム動作ユーザーのtmpフォルダに受け付けられます。
くっきーとかセッションもここにハッシュがファイル名になった実データとして保存されます。
ストリーミングデータ転送だとメモリにキャッシュすることなく書き込んだりすると、メモリはたります。
それを書き込むとか読み込むとか加工するとか変数にまるごと代入してみたりとかになって、メモリに転送すると大きさオーバーのときはエラーがでます。
この動作に至る前にでかいデータの移動やチェックがあるので、その段階ではじくとよかったり、容量を確保したりするとよいです。

プログラムを作成していてこれに直面した場合はだいたいなにが原因か気づくものだと思いますが、ほかの人のヘルプではわかりにくいこともあります。
なにがどおなったときの検証が十分伝達されるかどうかによるなどの場合からです。

そもそも内部で動く部分なので、そうなった経緯と目的がわかればよいのですが、そのヒントの出どころが謎なことがあります。

設定したはずが、反映されていない = 反映されれば治るのか
設定はされているが改善しない = 動作の設定や条件に問題はないか
ほかの条件では動くのだが起こるはずがない予定のものでエラーがおこる = ファイル・データに問題はないか

のような確認ができればと思います。

ひとつひとつ確実なテストコードを準備していればいいのですが、都度どうですかと聞くことが、私は多いです。
この一文で解決ですが、ちゃんとテストコードとロードマップを用意しとけって話ですよね。
チェックシートと具体的な症例を書き込んどけって話ですよね。

post_max_size = 256M

って例文かいてたから それ反映してるかみてみようねってだけじゃあ意味不明ですよね。
反映してませんでしたね、って確認にもならなかったですよね。

反省します。ほんとに。
自分がおぼれない準備がある人だけが、飛び込んで助けろってことですよね。
私何回死んでるんだか。


このページはログインするとコメントを記入できます。
先頭に戻る