13

私はあまり多くのメモリ (256Mb) を持たない VPS を持っています。これを SBCL + Hunchentoot を使用した Common Lisp 開発に使用して、いくつかの単純な Web アプリケーションを作成しようとしています。特に複雑なことをしなくても、大量のメモリが使用されているように見えます。ページを提供してしばらくすると、メモリが不足し、すべてのスワップを使用して狂ってしまうか、(スワップがない場合は)単に死んでしまいます。

だから私は助けが必要です：

  • すべてのメモリを使用しているものを見つけます（特にライブラリまたは私である場合）
  • 大量のスワッピングを避けるために、SBCL が使用できるメモリの量を制限します。
  • クラッシュするのではなく、メモリが不足したときに物事をきれいに処理します（Webアプリであるため、続行してクリーンアップを試みます）。

最初の 2 つはかなり簡単だと思いますが、3 番目は可能なのでしょうか? Lispでメモリ不足または制約されたメモリ条件をどのように処理しますか?

(また、64 ビット SBCL は文字通り 32 ビットの 2 倍のメモリを使用しているように見えることに注意してください。これは予想されることですか? 大量のメモリを節約できるのであれば、32 ビット バージョンを実行できます)

4

4 に答える 4

15

SBCL のメモリ使用量を制限するには、 --dynamic-space-size オプションを使用します (たとえば、sbcl --dynamic-space-size 128メモリ使用量を 128M に制限します)。

誰がメモリを使用して(room)いるかを調べるには、起動時、すべてのライブラリがロードされた後、および作業中に (もちろん、メモリ(sb-ext:gc :full t)を測定しないために余裕を持って呼び出す前に呼び出します)、さまざまな時点で (メモリが使用されていることを示す関数) を呼び出すことができます。まだ収集されていないゴミ）。

また、SBCL Profiler を使用してメモリ割り当てを測定することもできます。

于 2009-04-02T09:53:16.110 に答える
5

すべてのメモリを使用しているものを見つけます（特にライブラリまたは私である場合）

Attila Lendvai は、割り当てられたオブジェクトがどこから来るのかを調べるための SBCL 固有のコードをいくつか持っています。http://article.gmane.org/gmane.lisp.steel-bank.devel/12903を参照し、必要に応じて個人的なメールを書いてください。

実装固有のリークでないことを確認するために、できれば正確な GC (Clozure CL など) を使用して、別の実装を試してください。

大量のスワッピングを避けるために、SBCL が使用できるメモリの量を制限します。

すでに他の人が答えています。

クラッシュするのではなく、メモリが不足したときに物事をきれいに処理します（Webアプリであるため、続行してクリーンアップを試みます）。

256MB はきついですが、とにかく: 残りの空き容量をチェックする繰り返し (おそらく 1 秒) の時間指定スレッドをスケジュールします。空き容量が X 未満の場合は、exec() を使用して、現在の SBCL プロセス イメージを新しいものに置き換えます。

于 2009-04-03T15:31:57.137 に答える
3

型宣言がない場合、64ビットのLispは32ビットのLispの2倍のスペースを取ると思います。プレーンな（小さい）intでさえ、64ビットのメモリチャンクを使用します。あなたがそれを宣言しない限り、私はそれが機械語より少なく使われるとは思わない。

＃2と＃3は手伝うことはできませんが、＃1を理解すれば、問題はないと思います。私はSBCL/Hunchentootインスタンスが何年もの間実行されているのを見てきました。法外な量のメモリを使用している場合、それは通常、私自身の責任です。:-)

于 2009-04-02T20:21:11.553 に答える
1

I would not be surprised by a 64-bit SBCL using twice the meory, as it will probably use a 64-bit cell rather than a 32-bit one, but couldn't say for sure without actually checking.

Typical things that keep memory hanging around for longer than expected are no-longer-useful references that still have a path to the root allocation set (hash tables are, I find, a good way of letting these things linger). You could try interspersing explicit calls to GC in your code and make sure to (as far as possible) not store things in global variables.

于 2009-04-02T09:47:17.217 に答える