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

RStudio-server: slow file access on system with a lot of users #1763

Closed
hgsommer opened this issue Nov 17, 2017 · 2 comments
Closed

RStudio-server: slow file access on system with a lot of users #1763

hgsommer opened this issue Nov 17, 2017 · 2 comments
Labels
info needed Additional information requested—reprex, steps, open question, etc.

Comments

@hgsommer
Copy link

Hi,
I have an rstudio-server installation on a server running Scientific Linux 7 and R version 3.4.1. After the upgrade to version 1.1.383 the server showed the following behavior: When one tried to open a file from the web frontend, the "Opening file..." message was shown for a while and then most of the time an 502 Error was displayed. I had a look at the apache log files (used as a proxy configured like in the example) and it showed a lot of timeout messages.
Another thing I noticed was, that the rsession process showed the 'D' state in ps output, so was probably waiting for I/O. I run strace on the rsession process and it showed that stat() was called on every home directory on the system (every item in the parent directory of the current $HOME).
Since there are a lot of user file systems mounted on that server via NFS (about 70k, although only a handfull uses rstudio actively), this takes some time obviously.
Our previous version (1.0.143) did not show this behavior.

If you need additional info, please let me know.

@dfalty dfalty added the info needed Additional information requested—reprex, steps, open question, etc. label Nov 17, 2017
@jmcphers
Copy link
Member

We believe that this is the same issue described here: #1592.

We're working on putting out a patch release to 1.1 which has the candidate fix; it should be ready sometime next week.

@jmcphers
Copy link
Member

We have now released the aforementioned patch release; this issue should be taken care of.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
info needed Additional information requested—reprex, steps, open question, etc.
Projects
None yet
Development

No branches or pull requests

3 participants