1

私は 32 ビットの実稼働システムで MongoDB を使用していますが、これはひどいものですが、今は制御できません。課題は、メモリ使用量を 2.5GB 未満に抑えることです。これを超えると 32 ビット システムがクラッシュするためです。

mongoDB チームによると、メモリ使用量を追跡する最善の方法は、オペレーティング システムのプロセス追跡システム (つまり、Unix システムでは ps または htop、Windows では Process Explorer) を仮想メモリ サイズに使用することです。

DB は主に、継続的にデータを循環する 1 つのテーブルで構成されます。つまり、センサーから定期的にデータを受信し、毎日 cron ジョブが過去 3 日前のすべてのデータを消去します。一定期間にわたって、メモリ使用量はゆっくりと増加します。以下のグラフに示すように、db.serverStats()、db.lectura.totalSize()、および ps を使用して、時間をかけてメモを取りました。問題のテーブルのサイズは先月減少しましたが、それでもメモリ使用量は増加していることに注意してください。

ここに画像の説明を入力

現在、保存するデータの日数には調整の余地があります。今日、基本的にデータの半分を削除してからmongodbを再起動しましたが、メモリ仮想/メモリマップと最も重要なpsによるメモリ使用量はほとんど変化していません! データを消去(および再起動)してもこれらが減少しないのはなぜですか? mongo が使用しているように見えるすべてのメモリを実際に使用しているわけではなく、キャッシュをクリアしたり、メモリの使用を制限したりすることはできないと人々が言っ​​た他の質問を読みました。しかし、どうすれば 2.5GB の制限を確実に下回れるでしょうか?

このデータセットのサイズに関係なくメモリ使用量が徐々に増加するのを食い止める方法がない限り、Mongo の 32 ビット バージョンは使用できないように思えます。注: 問題が解決されれば、パフォーマンスが多少低下してもかまいません。

4

3 に答える 3

3

マップされたメモリと仮想メモリの使用量が削除しても減少しない理由について答えるために、マップされた数はmmap()、データファイルのセット全体を実際に取得したときに得られるものです。これは、レコードを削除しても縮小されません。データ ファイル内のスペースは解放されますが、データ ファイル自体のサイズは縮小されないためです。後でファイルが空になるだけです。

仮想には、ジャーナル ファイル、接続、およびその他の非データ関連のメモリ使用量も含まれますが、同じ原則が適用されます。これについては、次のとおりです。

http://www.mongodb.org/display/DOCS/Checking+Server+Memory+Usage

そのため、32 ビットでの2GB のストレージ サイズ制限は、実際には、データが含まれているかどうかにかかわらず、データ ファイルに適用されます。削除されたスペースを再利用するには、修復を実行する必要があります。これはブロック操作であり、実行中はデータベースをオフラインにするか、使用できない状態にする必要があります。また、修復を実行するには、元のサイズの最大 2 倍の空きディスク容量が必要です。これは、基本的にファイルを最初から書き直すことを意味するためです。

この制限と、それが引き起こす問題が、32 ビット バージョンが実稼働環境で実行されるべきではない理由です。できるだけ早く 64 ビット版に移行することをお勧めします。

ところで、これらの数値 (マップまたは仮想) は、実際には常駐メモリの使用量を表していません。これは、実際に確認したいことです。時間をかけてこれを行う最善の方法は、10gen が提供する無料の監視サービスであるMMSを使用することです。これは、仮想メモリ、マップ済みメモリ、常駐メモリ、および他の多くの統計を経時的にグラフ化します。

すぐに表示したい場合は、mongostatを実行し、対応するメモリ列 (res、mapped、virtual) をチェックアウトします。

一般に、本質的に無制限のストレージで 64 ビット ビルドを使用する場合、通常、データは使用可能なメモリを大幅に超えます。したがって、mongod は、常駐メモリに関して使用可能なすべてのメモリを使用します (これが、OOM キラーが機能しないように常にスワップを構成する必要がある理由です)。

それが使用されると、OS はメモリの割り当てを停止しません。新しいデータ ( LRU ) 用のスペースを確保するために最も古いアイテムがページアウトされます。つまり、メモリのリサイクルは自動的に行われ、常駐メモリ レベルはかなり一定に保たれます。

于 2012-09-07T16:10:37.263 に答える
2

32 ビットを拡張するオプションは限られていますが、いくつか試すことができます。使い果たすのはアドレス空間であり、追加のデータベース ファイルのサイズの増加は、"n" 個のファイルから "n+1" 個のファイルへの境界を越えないようにしたいことを意味します。データを多かれ少なかれデータベースに構造化して、メモリに最大量の実際のデータを取得し、「デッド スペース」をできるだけ少なくすることをお勧めします。

たとえば、「mydatabase」という名前のデータベースが、16 MB の mydatabase.ns (名前空間ファイル)、64 MB の mydatabase.0、128 MB の mydatabase.1、および 256 MB の mydatabase.2 のファイルで構成されている場合、次のこのデータベース用に作成されたファイルは、512 MB の mydatabase.3 になります。mydatabase に追加する代わりに、追加のデータベース「mynewdatabase」を作成した場合、16 MB の mynewdatabase.ns と 64 MB の mynewdatabase.0 で開始されます...元のデータベースに追加する 512 MB よりもかなり小さいだろう。実際、元のデータベースに新しいファイルを追加することによって消費されるよりも少ないスペースで 4 つの新しいデータベースを作成できます。また、ファイルが小さいため、連続したメモリ ブロックに収まりやすくなります。

于 2012-09-10T13:16:43.350 に答える
-4

実動に 32 ビットを使用すべきではないというのはよく知られたメッセージです。

64 ビット システムを使用します。

点。

于 2012-09-07T14:04:01.347 に答える