0

私は Neo4j 1.9.4 を 24 コア 24Gb RAM (centos) マシンにインストールしており、ほとんどのクエリで CPU 使用率のスパイクが 200% になり、同時リクエストはほとんどありません。

ドメイン：

3 ～ 30 個のテキスト/配列プロパティを持ついくつかのタイプのノード (プロファイル) と、少なくとも 3 つのプロパティを持つ 36 の関係タイプがある、ある種のソーシャル アプリケーション。現在、ほとんどのノードには 300 ～ 500 の関係があります。

現在のデータセットのフットプリント (コンソールから):

LogicalLogSize=4294907 (32MB)
ArrayStoreSize=1675520 (12MB)
NodeStoreSize=1342170 (10MB)
PropertyStoreSize=1739548 (13MB)
RelationshipStoreSize=6395202 (48MB)
StringStoreSize=1478400 (11MB)

私見は本当に小さいです。ほとんどのクエリは次のようになります (多かれ少なかれ WITH .. MATCH .. ステートメントがあり、可変長の関係を持つクエリはほとんどありませんが、多くの場合高速です):

START
    targetUser=node({id}),
    currentUser=node({current})
MATCH
    targetUser-[contact:InContactsRelation]->n,
    n-[:InLocationRelation]->l,
    n-[:InCategoryRelation]->c
WITH
    currentUser, targetUser,n, l,c, contact.fav is not null as inFavorites
MATCH
    n<-[followers?:InContactsRelation]-()
WITH
    currentUser, targetUser,n, l,c,inFavorites, COUNT(followers) as numFollowers
RETURN
    id(n) as id,
    n.name? as name,
    n.title? as title,
    n._class as _class,
    n.avatar? as avatar,
    n.avatar_type? as avatar_type,
    l.name as location__name,
    c.name as category__name,
    true as isInContacts,
    inFavorites as isInFavorites,
    numFollowers

1 秒から 3 秒 (最初の実行の場合) および 1 秒から 70 ミリ秒 (連続実行の場合、クエリによって異なります) で実行され、インプレッションごとに約 5 ～ 10 のクエリが実行されます。もう1つの興味深い動作は、ローカルマシンでコンソール（neo4j）からクエリを何度も連続して実行しようとすると（Ctrl + Enterを数秒間押すだけです）、実行時間はほぼ一定ですが、サーバーで実行すると指数関数的に遅くなり、どういうわけか私の問題に関連していると思います。

問題：

したがって、私の問題は、neo4jが非常にCPU貪欲であることです（24コアマシンの場合、問題ではないかもしれませんが、小さなプロジェクトでは明らかにやり過ぎです）。初めて AWS EC2 m1.large インスタンスを使用しましたが、全体的にパフォーマンスが悪く、テスト中、CPU は常に 100% を超えていました。

設定の関連部分:

neostore.nodestore.db.mapped_memory=1280M
wrapper.java.maxmemory=8192

注：すべてのメモリ関連のパラメーターがHIGHで機能しない構成を既に試しました（まったく変更はありません）。

質問：

どこを掘る？構成？図式？クエリ？私は何を間違っていますか？

詳細情報（ログ、構成）が必要な場合は、お問い合わせください;）

4

1 に答える 1

0

同じクエリの後続の呼び出しがはるかに高速である理由は、キャッシュの使用によって簡単に説明できます。一般的な戦略は、起動時にキャッシュ ウォームアップ クエリを実行することです。

start n=node(*) match n--m return count(n)

24 コアで 200% の CPU 使用率は、2 つのコアのみがビジーであるため、マシンがかなり怠惰であることを意味します。クエリが進行中の場合、実行中に CPU が 100% になるのは正常です。

上記の Cypher ステートメントでは、オプションの match (2 番目の match 句) を使用しています。これらのオプションの一致は、潜在的に遅いことが知られています。これを非オプションの一致にすると、ランタイムが変わるかどうかを確認してください。

より大きな結果セットを返す場合は、応答の転送がネットワーク速度によって駆動されることを考慮してください。この場合、ストリーミングの使用を検討してください。 http://docs.neo4j.org/chunked/milestone/rest-api-streaming.htmlを参照してください。

wrapper.java.minmemoryまた、 と同じ値に設定する必要がありますwrapper.java.maxmemory。

かなり小さいグラフの別のアプローチは、MMIO キャッシュをオフcache_type=strongにして、完全なデータセットをオブジェクト キャッシュに保持するために使用することです。この場合、 と を増やす必要があるかもしれませwrapper.java.minmemoryんwrapper.java.maxmemory。

于 2013-11-09T09:49:54.537 に答える