Ploneデッドロックの問題を解決する現代的な方法は何ですか？

Question

私は現在、Plone 4.3.8サイトを持っており、ポートレットを編集するとデッドロックが発生します。

私はこれを修正するためのツールを見つけようとしていますが、デッドロックツールの多くは機能しません。&少なくとも実行しているものからは良い情報（IMO）が得られません。

私が試してみた：

• z3c.deadlockdebugger =>スタックトレースを取得することはできません
• ZopeHealthWatcher =>
• Products.LongRequestLoggerコマンドライン（またはWebページ）の結果を見ることができません=>おそらく最高のは、これまでのところ、私にいくつかのログ出力を提供します - しかし、トレースがジアゾコードに焦点を当てスタックだが、ジアゾがスコープ内にないときに問題がまだ（127.0.0.1に対して実行されている）
• GDBが添付発生 - ちょうど上陸しました私のCコードで
• winpdb => gdbと同じ方法で実行中のプロセスにアタッチすることはできません（winpdbによってアタッチされるようになったプロセスのみ）
• Products.signalstack（OR Products.signalstacklogger）=> USR1シグナルは、ゾーププロセス！

注：z3c.deadlockdebugger（およびそれに依存するもの）は、source codeをチェックして、スレッドフレームの依存関係を削除する必要があります。

私の状況は、製品のアップグレード（おそらくplone.app.contenttypesまたはplone.app.multilingualのいずれかまたは両方）にリンクされているようですが、空のサイトにはこの問題はありませんが、 ！

私はこれを進めるために何をすべきか？

EDIT：

私はマウリッツが最も正しいものであることを答えると信じて、それは私の場合には動作しませんでした。私がやったことは、pdbを使って、コードがぶら下がっていたポイントを追跡することでした（plone.app.debugtoolbarで起こります）

Answer 1

USR1シグナルを使用すると、Products.signalstackを使用するときにZopeがシャットダウンすると言います。しかし特別なパッケージは必要ありませんので、signalstackを追加することでZopeをシャットダウンするという副作用があるのだろうかと思います。

は、少なくとも私にとっては、数週間前に、これはPloneの4.3.somethingサイトにうまく働いた：

kill -USR1 $(cat var/zeoclient.pid) 

Answer 2

を@maurits答えは右である（そして、最も単純なもの）が、時々私は見て問題がありましたkillコマンドのトレースバックがイベントログに記録されることもあります。

私もmonitor long running requests featureを設定し、haufe.requestmonitoringと増築の統合を好みます。 イベントログにデッドロックされたトレースバックが表示され、Ploneの低性能を監視するためのツールも有効になります。 threadframe依存性について