設定:
Fedora 30 には、Ubuntu 18.04.1 を実行する KVM/qemu 仮想マシンが付属しています。
(これはFedora 30でRStudioを実行したかったので、nouveauグラフィックサブシステムのどこかでクラッシュしてすぐに死んだために設定されましたが、Ubuntu VMでは正しく実行されました。)
質問:
RStudioの実行中にVMにコピーして貼り付けるのは本当のPITAです。
VMの起動後、ホストとVMの間のコピー/貼り付けは、VM内のコピー - 貼り付けと同じように機能します(たとえば、KWriteからKWriteへ)。
仮想マシンでRStudioを起動した後、最初はコピーと貼り付けが機能し続けますが(数回)、すぐに「ロック」が始まります。これはRStudioとKWrite、VM内、およびホストとVMのコピーと貼り付けで機能します。仮想マシンの受信プロセスが停止し、明らかに何かを待っています。ただし、仮想マシンは引き続き正常に実行されます(たとえば、シェル、実行top
などを使用できますiotop
)。
受信プロセスは10〜30秒後に再び起きます。この時点で貼り付けたテキストが受信されている可能性があります。最初の問題が発生した後に貼り付けが失敗することがよくあります。これには、仮想マシンからホストマシンにコピーして貼り付ける操作が含まれます。 KWriteに貼り付けるには、クリップボードの内容なしでカーソルが戻るまで常に10秒かかります。 RStudioの動作はより悲惨であり、時にはプロセスを終了することが唯一の解決策です。
しばらく仮想マシンを離れると、ロックが再開される前にいくつかの成功したコピーアンドペースト操作が発生する可能性があります。
spice-vdagent
ゲストコンピュータから再起動()すると(何もしないホストとは対照的に)ロックが解除さsystemctl start spice-vdagentd
れ、コピーして貼り付けを再実行する機会が提供されることがあります。ただし、この作業には多少のリスクがあります。ある時点で、GUI全体がハングしたからです。
それを処理する方法?
何を探すべきですか?
xclipboard
クリップボードで何が起こっているかを確認するためにコンソールでそれを使用しました。予期しないものは何も見ませんでした。
ポリスチレン
VMには大容量RAM(10GiB)が用意されています。これは、強度マップに関連する大きすぎないweaveファイルを作成するだけでpandoc
メモリ不足が発生する可能性があるため必要です。
RStudioは、私の作業中にシステム全体をロックしないで、数秒間それ自体で停止することがありました。スワッピングやガベージコレクションが始まるように感じますが、I / OまたはCPU側では何も起こりません。迷惑ですが生き残ることができます。
答え1
RStudio Community BBでは、次のアイデアが提供されました。
環境変数の設定
RSTUDIO_NO_CLIPBOARD_MONITORING=1
たとえば、
RSTUDIO_NO_CLIPBOARD_MONITORING=1 /usr/bin/rstudio
GitHubのバグ修正に基づいています。
この質問に基づいて:
私たちが見つけた場所:
原因はRStudioがクリップボードの変更を積極的に聞いているようです。望むより:
#9 0x00000000005a2745 in rstudio::desktop::GwtCallback::onClipboardChanged(QClipboard::Mode) ()
グローバルマウスの選択をサポートするためにこれを行いますが、あまりにも積極的または無視する必要があるクリップボード通知を処理している可能性があります。
上記の操作を実行すると応答時間は向上しますが、コピーアンドペーストの安定性は向上しません。