Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slowness when accessing shared drives from Windows IDE #1592

Closed
kevinushey opened this issue Oct 11, 2017 · 11 comments
Closed

Slowness when accessing shared drives from Windows IDE #1592

kevinushey opened this issue Oct 11, 2017 · 11 comments

Comments

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Oct 11, 2017

A number of Windows users have reported slowness (or freezes) when using RStudio on Windows with a shared drive / networked filesystem, especially when attempting to open new files:

https://community.rstudio.com/t/rstudio-1-1-383-issue-on-startup/1819

Some users have reported that resetting RStudio's state seems to help alleviate the issue, but it hasn't helped in all accounts.

See also:

https://support.rstudio.com/hc/en-us/community/posts/115000936767-Rstudio-freezing-possibly-due-to-git-issue

https://support.rstudio.com/hc/en-us/community/posts/115007277307-Extremely-SLOW-opening-files-on-network-file-server-STILL-

Marking this as a high priority bug as it seems to affect nearly all RStudio users interacting with shared drives.

@kevinushey
Copy link
Contributor Author

@kevinushey kevinushey commented Nov 2, 2017

Another report: https://support.rstudio.com/hc/en-us/community/posts/115009389608-RStudio-1-1-383-taking-up-to-120-seconds-to-respond-


We have discovered an issue with RStudio locking up/freezing, which we can reproduce. Our scenario is as follows:

R version 3.4.2

RStudio version 1.1.383

Windows 10, Active Directory environment with user profiles and an AD user logged in.

The Desktop and Documents folders are redirected to a network drive, e.g. in our case:

Desktop redirected to: H:\Desktop

\file-alpha\scsa_group2\scsa_fs_student6\student\0999037tT\Desktop (file://file-alpha/scsa_group2/scsa_fs_student6/student/0999037tT/Desktop)

Documents redirected to: H:\My Documents

\file-alpha\scsa_group2\scsa_fs_student6\student\0999037tT\My (file://file-alpha/scsa_group2/scsa_fs_student6/student/0999037tT/My) Documents

A simple R script saved on either the Desktop or Documents folder, containing the following:

2+2

3+3

4+4

5+5

6+6

… any changes to the script, such as adding an extra line, e.g. 7+7 or changing one of the existing lines, e.g. 6+6 to 6+6+6 and re-running the code without saving, causes the console to hang for anywhere up to 120 seconds, e.g.

5+5

[1] 10

6+6

[1] 12

7+7

[1] 14

6+6

[1] 12

7+7

*** hangs at this point ***

We can reproduce this, and it doesn’t happen if the file is opened from a network drive directly, e.g. H:, only when the script is opened from the “special” Desktop or Documents folder:

On starting RStudio we delete the RStudio user profile directory, e.g. "%userprofile%\AppData\Local\RStudio-Desktop" so its always starting in a clean state, but this issue is definitely reproducible for us.

Any help/advice appreciated.

@KaiserDominici
Copy link

@KaiserDominici KaiserDominici commented Nov 7, 2017

We had a similar issue in my organisation. We think it is because RStudio (actually, rsession.exe as called by RStudio) scans the whole drive when creating or modifying an R script (we used a third-party tool to monitor its activity). In fact, this is does not apply only to networked drives. Setting one's home folder to the local drive does not change this behaviour. Hope this helps.

@kevinushey
Copy link
Contributor Author

@kevinushey kevinushey commented Nov 8, 2017

This sounds plausible. What utility were you using to monitor the rsession process in this case?

@KaiserDominici
Copy link

@KaiserDominici KaiserDominici commented Nov 9, 2017

Process Monitor, one of Windows Sysinternal utilities. We saw that rsession.exe was scanning the drive.

@kevinushey
Copy link
Contributor Author

@kevinushey kevinushey commented Nov 15, 2017

@KaiserDominici: Thanks for following up! I think I have an idea as to what could be causing this; I'll attempt to investigate a bit more.

@jmcphers
Copy link
Member

@jmcphers jmcphers commented Nov 16, 2017

Backported to 1.1.

@dfalty
Copy link

@dfalty dfalty commented Dec 4, 2017

@KaiserDominici are you able to verify the fix on the latest 1.1 preview build? https://www.rstudio.com/products/rstudio/download/preview/

@dfalty
Copy link

@dfalty dfalty commented Dec 12, 2017

We have reports from the community that this is fixed in 1.1.393. Marking as verified.

@jrthompson54
Copy link

@jrthompson54 jrthompson54 commented Mar 29, 2018

I had similar problems not involving networked drives and that was not fixed by the most recent RStudio update. I found out .git folders, which are hidden by default, had become unhidden in the affected projects. Re-hiding the .git folder restores normal RStudio project operations. See my more detailed post on #1770

@moodymudskipper
Copy link

@moodymudskipper moodymudskipper commented Nov 7, 2018

@jmcphers is there anything that I can do with RStudio 1.0.153 to improve the situation ? I can't install a newer version now as it's part of a bigger process in my company but installing a patch should be negotiable.

Also as you identified the sources of the issue could you give some good practices to avoid the occurrence of these slowness issues in general ?

@moodymudskipper
Copy link

@moodymudskipper moodymudskipper commented Nov 7, 2018

I found this #1758 but it worries me a bit as it seems to fix things that were implemented from 1.1 so it means my issues might not be fixed even when I get the new version.

Maybe there are also some things I can discuss with my network administrators to make the configuration more RStudio friendly ? (if it makes sense, I don't know anything about networks).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants