2011-07-28 5 views
1

は、私は次の面白いメモリ使用量の結果が見つかりました:アーラン:私は私のWebSocketのテストを実行するとメモリ使用量の数値の不一致

Serverは、何も接続

[{total,573263528}, 
{processes,17375688}, 
{processes_used,17360240}, 
{system,555887840}, 
{atom,472297}, 
{atom_used,451576}, 
{binary,28944}, 
{code,3774097}, 
{ets,271016}] 
44 processes, 
System:705M, 
Erlang Residence:519M 

100K接続

[{total,762564512}, 
{processes,130105104}, 
{processes_used,130089656}, 
{system,632459408}, 
{atom,476337}, 
{atom_used,456484}, 
{binary,50160}, 
{code,3925064}, 
{ets,7589160}] 
100044 processes, 
System: 1814M, 
Erlang Residence: 950M 
を述べていません

200K接続

(サーバーを再起動し、0の接続から作成します.c )ケース2からontinue

[{total,952040232}, 
{processes,243161192}, 
{processes_used,243139984}, 
{system,708879040}, 
{atom,476337}, 
{atom_used,456484}, 
{binary,70856}, 
{code,3925064}, 
{ets,14904760}] 
200044 processes, 
System:3383M, 
Erlang: 1837M 

「システム」と数字と「アーラン:」ホテルトップに設けられているが、他のものは、Erlangのシェルからメモリ()呼び出しの出力です。合計とエルランの住居の記憶を見てください。接続がない場合、これらの2つはほぼ同じですが、100K接続では、レジデンスメモリは合計よりも少し大きく、200K接続では、レジデンスメモリはほぼ2倍です。

誰でも説明できますか?

+0

メモリはVMによって追跡されず、代わりにシステムハンドルで接続されていますか? –

+0

私たちはより多くの情報が必要です。両方のVMとシステムからerlang。 OS側でpmapを実行し、erlang側でプロセスの要約(トップキューホルダーなど)を実行します。 – user425720

答えて

4

あなたが気づいている可能性が最も高いのは、メモリの断片化です。

OSメモリの割り当てにはコストがかかるため、Erlangはメモリを管理します。 Erlangがメモリを割り当てると、 "carrier"というエンティティが作成されます。このエンティティは多くの "ブロック"で構成されています。 Erlangメモリ(合計)は、すべてのブロックサイズ(実際に使用されたメモリ)の合計をレポートします。 OSは、すべてのキャリアサイズの合計(使用されたメモリと事前に割り当てられたメモリの合計)をレポートします。ブロックサイズとキャリアサイズの合計はErlang VMから読み取ることができます。 (ブロックサイズ)/(キャリアサイズ)が< <の場合、VMはキャリアを解放するのに苦労します。いくつかのブロックだけが使用されている多くの大型キャリアがあるかもしれません。 erlang:system_info({allocator、Type})で読むことができます。より簡単な方法があります。あなたは偵察ライブラリを使用して、それをチェックすることができます。

http://ferd.github.io/recon/recon_alloc.html

まずチェック:

recon_alloc:fragmentation(current). 

と次:

recon_alloc:fragmentation(max). 

これは、ErlangのVMによって報告された総メモリの違いを説明しなければならないし、 OS。あなたはWebSocketを介して多くの小さなメッセージを送信する場合は、2つのオプションでアーランを実行して、断片化を減らすことができます。

erl +MBas aobf +MBlmbcs 512 

最初のオプションは、スクイズを助ける可能性がある、順序最高のフィット感に対処するためのベストフィットからブロック割り当て戦略を変更します第1のキャリアへのブロックの数が増え、第2のキャリアの最大のマルチブロックキャリアサイズが小さくなり、キャリアが小さくなります(これにより、より簡単に解放できます)。

関連する問題