neo4jタイムツリーがフリーズする理由は何ですか？

Question

Neo4jに奇妙な問題があります。私は最近GraphAware TimeTreeで作業していて、昨日までうまくいっていた。私が作ったエラーのためにツリーを再構築しなければならなかったので、スクリプトを一晩中実行しました（nohup）。

今日、私のスクリプトは3分間しか実行されませんでした。

$ ps aux | grep timetreepop 
root  21840 0.0 0.0 195952 2816 ?  S Jul28 0:00 sudo nohup python timetreepop.py 
root  21841 0.0 0.2 381416 75016 ?  S Jul28 0:03 python timetreepop.py 

私が働いていた間、私はこの動作に気づいたが、私は助けになり、アクティブではないんだしながら、一晩、それを残して考え出しました。私はまた、可能性のある競合の場合には、私の他のJavaサーバープロセスをオフにしました。この時点で、私のサーバーは非常に重くなく、多くのトラフィック（カップルヒット1日）を取得しないバックグラウンドでは、Pythonのトルネードサーバーを実行していただけです。

私のシステムには十分なRAMがあり、CPUは他の場所では利用されておらず、マシンに重いIOを実行している他のプロセスはありません。 top/atopを使用すると、利用可能なリソースがある正常なシステムが表示されます。ここで

は私のスクリプトが何をしているかのハイレベルです：

neo = neopop.handler() 
for i, meta_id in enumerate(meta_gen(ship='KAOU')): 
    neo.populate_timetree(record=meta_id) 

私のハンドラは__init__コンストラクタでドライバーとのセッションを作成します。

self.driver = graphdb.driver(config.NEO4J_HTTP_LINK) 
self.session = self.driver.session() 

私の発電機がユニークであるmeta_id値を提供します私のグラフのノードのプロパティ値。

populate_timetree()機能は、次のステートメントを作成します。

MATCH (r:record {meta:"KAQP_20120101v20001_0001"}) WITH r 
CALL ga.timetree.events.attach({node: r, time: r.time, relationshipType: "observedOn", resolution:"Minute"}) 
YIELD node RETURN node.meta; 

すべてが回る私の最初の罰金働いていました。私の時間値を台無しにした後、私はデータベースを削除し、再起動して再試行しました。私は、セッションを閉じるために電話をかけるときのみ、この時間は、私のプログラムがフリーズ：

neo.session.close() 

注：私は実際に、私の__del__デコンストラクタでこれを呼び出す（私はおそらく悪い習慣と考えられている知っているが、それはのために働いてきました私のニーズに合っています）。

不正なreadline文/それが一時停止する可能性があるものについては、自分のコードをすべてダブルチェックしました。また、このコードをすべて含んだパッケージを再コンパイルしました。私はこのsession.close()のステートメントで立ち往生しているという事実を知っています。

私はNeo4j-shellツールを使って試してみました。 最初に迅速な応答性チェック：

$ neoc 'schema' 
Indexes 
    ON :record(meta) ONLINE (for uniqueness constraint) 

Constraints 
    ON (record:record) ASSERT record.meta IS UNIQUE 

オクラホマすべてが良いです。今私は単一の値のタイムツリー呼び出しを試してみます：

$ ./neo4j-shell -c ' 
> MATCH (r:record {meta:"KAOU_20110613v20001_0000"}) WITH r 
> CALL ga.timetree.events.attach({node: r, time: r.time, relationshipType: "observedOn", resolution:"Minute"}) 
> YIELD node RETURN node.meta; 
> ' 

BOOM Neo4jが詰まっています！明らかにするために、MATCHステートメントはここで永遠に取っていないことを知っています。なぜなら、今回はdbに約200万のノードを入れているだけなので、matchステートメントだけを呼び出しても大丈夫です。私はこの一意のプロパティ用にインデックスを設定しています（上記のスキーマ呼び出しを参照）。

ここでは何が起こっていますか？私は、ツリーの最初の作成は、単一のノードを挿入するだけではあまり問題にならないはずです。私の最初の試みは完璧に動作するようです。私が持っていた5,800万件のレコードのうち200万件をデータベースに取り込むことを除いて、私が今までとは違ったことをしているかどうかはわかりません。 （だからそれは速くなければならない）。

私は実際にこのコマンドを数時間実行したままにしていましたが、私のシステムでも数分間しか実行していませんでした。私はここで何が起こっているのかとても混乱しています。誰にもアイデアはありますか？とにかくneo4jがこのコマンドについて積極的に何をしているのか分かりますか？ （コミュニティ版を使用していることを覚えておいてください）

私はneo4j 3.0.3.39 timetree/graphaware onとCentOS 7 serverを実行しています。

私が持っている唯一のアイデアは、Pythonやcmdラインシェルツールであろうと、何度もコミットする前にサイファーステートメントを呼び出してキャンセルしていることです。取引が完了する前に大きな取引を取り消すことによって、トランザクションマネージャーをあまりにも煩わせることができますか？例えば

：それは仕上げなしで約2時間の実行後、次に

/neo4j-shell -c 'MATCH (r:record) CALL ga.timetree.events.attach(....) ....' 

とはcontrol-Cを打ちます。

---

UPDATE：

[OK]をので、私は私のログファイルを調査し、いくつかの問題を発見しました。メモリが足りないためスレッドがブロックされているようです。私の最大ヒープサイズは、人工的に制限されていて、私のマシン上で利用可能なリソースを使用していないと思います。 （多分？？）。だから手動でdbms.memory.heap.max_size=16000を設定します。

今問題は解決していないようです。進歩しているかのようにアイドリングするのではなく、neo4j-shellツールの応答にJava OOMが現れることを期待しているので、私は混乱していたと思います。

Answer 1

$ ./neo4j-shell -c ' 
> MATCH (r:record {meta:"KAOU_20110613v20001_0000"}) WITH r 
> CALL ga.timetree.events.attach({node: r, time: r.time, relationshipType: "observedOn", resolution:"Minute"}) 
> YIELD node RETURN node.meta; 
> ' 

このクエリーがタイムツリーに添付されると予想されるノードはいくつありますか？

この手順ではバッチ処理を使用しないため、1回のトランザクションでメモリが行うことができるものに限定されています（これは現在のバックログにあります）。言っ

、それは一般的にツリーに手動でイベントを添付しても意味がありません、この手順では、利便性のためにそこにあるが、我々は、自動イベントの添付ファイルを使用することをお勧めします。

そのようにし

https://github.com/graphaware/neo4j-timetree#automatic-event-attachment

完全なdb（または添付ファイル用に構成されたノードのみ）を再接続することはデータベースの再起動の問題となり、このプロセスはバッチ処理で実行されるため、処理時間が大幅に短縮されます。