설정:
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의 버그 수정을 기반으로 합니다.
"사용자가 X11 클립보드 모니터링을 비활성화할 수 있습니다."
이 질문을 바탕으로:
"RStudio 1.1.419가 주기적으로 중단됩니다."
우리가 찾은 곳:
원인은 RStudio가 클립보드 변경 사항을 너무 적극적으로 듣고 있는 것 같습니다. 바라보다:
#9 0x00000000005a2745 in rstudio::desktop::GwtCallback::onClipboardChanged(QClipboard::Mode) ()
전역 마우스 선택을 지원하기 위해 이 작업을 수행하지만 너무 공격적이거나 무시해야 하는 클립보드 알림을 처리하고 있을 수 있습니다.
위의 작업을 수행하면 응답 시간은 향상되지만 복사-붙여넣기 안정성은 향상되지 않습니다.