-
Notifications
You must be signed in to change notification settings - Fork 34
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
Update taking a long time, if Datafolder is mounted via nfs #455
Comments
@joshtrichards Will do. Thanks a lot! |
Tested while upgrading from 25.0.3 to 25.0.8. More than 30min waiting, stil creating backup. Folder
An stracer on the updater.phar pid shows php working with folder Lots of lines like:
|
Almost 80% of the time calling to 'nefstatat'
We had a similar problem with PHP-FPM and NFS performance due to realpath_cache being disabled. In that case was due to open_basedir (more info here https://alan.ivey.dev/posts/2013/speed-up-php-on-nfs-with-turbo_realpath/). When running 'php -i' I can see that realpath_cache is enabled and that we are not using open_basedir. But perhaps realpath_cache is being disabled inside updater.phar ?? |
I don't know what your setup is; in our case, before #420 the upgrade step took 6 minutes, now it takes 45 seconds.
Try to update using And also |
First upgrade two days ago was from 25.0.3 to 25.0.8 and it spent almost one hour during the backup phase. Yesterday we upgraded from 25.0.8 to 26.0.3 and the backup took less than 15 minutes. Much better 😄 but far from you 45 seconds @solracsf 😞 I'll report again in our next update. And thanks for taking the time to review this! |
In our case, both |
We have /var/www/nextcloud in NFS not only the data folder. I suppose that in our case using 'updatedirectory' solves only half the problem :-( But as we have several php servers I don't want to assume the risk of having a local application folder for each one. |
Well this is expected then, read from NFS thousands of little files is very slow and will always be. So yes, this solves half the problem (but the only half that can be solved) because you only read from NFS to backup files, not write to. Not a bug here, and |
Just another comment. In our install the apps folder is by far the largest, with 29108 files and almost 1GB of space in disk. We tested the copy of /var/www/nextcloud/apps from NFS to local disk:
It's` slower than copying from local to local disk. But still far from the 15 minutes that took our second upgrade:
The updatedirectory option is very welcome, but NFS is not as slow by itself. It seems that there is another problem in how the files are being copied. |
Hi,
i have noted and read about, that many users (including me) have mounted the data folder via a nfs share into the server.
Therefore the updater takes a lot of time to complete, because the small files are backed up to the nfs share, then the update will be extracted to the mount and then copied over again.
Might it be possible, to improve this, to lets say:
Please let me know!
The text was updated successfully, but these errors were encountered: