0

同様のクエリを 374 回実行していますが、367 回目まではパフォーマンスは妥当ですが、結果を返すまでの時間が劇的に低下します。

私が照会するコレクションには、各投稿が一意の ID を持つ投稿が格納され、データベースには同じ投稿の複数のバージョンが存在します。タスクは、各投稿 ID の最新バージョンを取得することです。アプローチは、投稿 ID の個別のリストを取得し、次に各投稿 ID について最も高い ObjectID を持つ投稿 ID を取得することです。

これは集計フレームワークを介して行うこともできますが、次のエラーが発生しますexception: aggregation result exceeds maximum document size (16MB)

これはコードです：

for oi in obj_ids: #obj_ids is a list of strings containing unique post IDs
    t1 = time.time()
    o = col.find({'object_id':oi}).sort('_id', -1).limit(1)[0]
    t2 = time.time()

このcol.find関数には時間制限があり、時間の経過とともにこのクエリのパフォーマンスがどのように低下​​するかを次に示します。

364 of 374 in 0.00369000434875s
365 of 374 in 0.0037579536438s
366 of 374 in 0.00375485420227s
367 of 374 in 0.00367307662964s
368 of 374 in 0.735110998154s
369 of 374 in 3.09494900703s
370 of 374 in 5.16561698914s
371 of 374 in 7.14517307281s
372 of 374 in 8.3472340107s
373 of 374 in 8.61702394485s
374 of 374 in 8.07462406158s

何が起こっているのですか？

2012/11/01更新

Python cprofile を使用すると、ネットワークのボトルネックがあるように見えることがわかりました

時間順

編集：スペル

4

3 に答える 3

1

RAMが不足しているようです。Linuxでは、次の方法でRAMを確認できます。$ free -m

RAMが空いているかどうかを確認します。レイテンシーが急上昇する要因は、ディスクにヒットしているようです（スワップ操作）。

Pythonがメモリを大量に消費している場合は、gcモジュールを使用してください。

于 2013-01-10T16:03:38.200 に答える
0

問題はインデックスに関連していました。_id と object_id に複合インデックスを作成しましたが、実際には _id インデックスと object_id インデックスを別々に追加する必要がありました。これを行った後、約 380 のクエリが 5 分ではなく約 10 秒で実行されます。

于 2013-01-14T15:54:46.390 に答える