3

毎日データをログに記録する、一見シンプルなmap/reduceジョブがあります。開発サーバーでは、このジョブを非常に多くのドキュメント（約100万）に対して実行でき、問題なく約1分かかります。ジョブをAmazonEC2サーバーである本番サーバーに移動します。ジョブは非常に高速で行の約50％をクランキングし、残りのデータをクロールします。予想される1〜2分ではなく、数十万のドキュメントを処理するのに数時間かかる場合があります。ですから、map/reduceジョブで明らかな間違いを犯したことを願っています。

入力ドキュメントのサンプルは次のとおりです。

{{
    "_id"：ObjectId（ "4f147a92d72b292c02000057"）、
    "cid"：25、
    "ip"： "123.45.67.89"、
    "b"： "Mozilla / 5.0（Macintosh; Intel Mac OS X 10_6_8）AppleWebKit / 535.7（KHTML、Geckoなど）Chrome / 16.0.912.63 Safari / 535.7"、
    "r"： ""、
    "l"： "en-US、en; q = 0.8"、
    "ts"：ISODate（ "2012-01-16T19：29：22Z"）、
    "s"：0、
    "cv"： "4f143a5fd72b292d7f000007"、
    "c"： ""
}

_idの範囲のみを照会します。

マップコードは次のとおりです。

働き（） {
    var browser = {}
    、referrer = {};
    browser [this.b] = {
        'カウント'：1
    };
    リファラー[this.r]={
        'カウント'：1
    };
    var objEmit = {
        'カウント'：1
        、「ブラウザ」：ブラウザ
        、'リファラー'：リファラー
    };
    var date = this._id.getTimestamp（）;
    date.setHours（0）;
    date.setMinutes（0）;
    date.setSeconds（0）;
    放出（{'cv'：this.cv、'date'：date、'cid'：this.cid}、objEmit）;
};

削減コードは次のとおりです。

関数（キー、放出）{
    var total = 0
    、ブラウザ= {}
    、referrers = {};
    for（var i in排出）{
        合計+=排出量[i].count;
        for（var key in Emmits [i] .browsers）{
            if（emits [i] .browsers.hasOwnProperty（key））{
                ！（browsers [key]）&&（browsers [key] = {count：0}）;
                browsers [key] .count+=はemits[i].browsers [key] .count;
            }
        }
        for（var key in Emmits [i] .referrers）{
            if（emits [i] .referrers.hasOwnProperty（key））{
                ！（referrers [key]）&&（referrers [key] = {count：0}）;
                referrers [key] .count+=はemits[i].referrers [key] .count;
            }
        }
    }
    return {'count'：合計、'ブラウザ'：ブラウザ、'リファラー'：リファラー}
};

ファイナライズせず、「merge」オプションをtrueに設定して、map/reduceジョブを既存のコレクションに出力します。

どんな助けでも大歓迎です。

4

1 に答える 1

0

これは開発環境と本番環境で実行されている同じコードであり、非常に大きなセットで開発環境で実行され、非常に迅速に返されるため、コードに問題があると思われる特定の理由はありますか?

マイクロ インスタンスで実行している可能性はありますか? ご存じないかもしれませんが、マイクロ インスタンスは平均 CPU 使用率に上限を設けており、処理を許可されずにデータの巨大なキューが蓄積されることにより、Map-Reduce アクティビティに損害を与えている可能性があります (I/O は制限されていません)。同じように、それが入ってくると、Linux カーネルはその管理にほとんどの時間を費やし、事態をさらに悪化させます)。

マイクロからスモールへの切り替えは、CPU 速度が遅くても、(通常のマシンが常にそうであるように) 動作する CPU サイクルの一定の「フロー」があり、MongoDB の内部スケジューリングがおそらくより適切に適応するため、役立つ場合があります。

通常のクエリの「スパイク」は、CPU 制限がオンになるほど長く続かないため、これは以前は問題にならなかった可能性があります。

于 2012-05-23T19:34:11.543 に答える