Slow (read/write) Nextcloud Update via WebUI on RPi4

ℹ️ Support
1

Hello everyone,

I am using a Raspberry Pi 4 4GB with this NAS Kit: https://shop.allnetchina.cn/collections/sata-hat/products/quad-sata-hat-case-for-raspberry-pi-4

I tried to run Nextcloud on various ways, but I often encountered some bugs that took too much effort to fix, or some functions didn’t work as expected. So I installed every service step by step. It’s now running but, I have the feeling that it’s slower than it should be.

When 20.0.1 was available, I tried to run this Update via the Web Interface. It worked, but it took all night. And I had to log in every hour to click continue update. And I asked myself if this is always taking that long for other RPi4 owners too? Steps that took nearly forever where, creating the backup and moving the new files to location.

I have my Data directory on my 4 - Raid 5 HDD drives. And Nextcloud is located on the SD Card - /var/www/nextcloud.

Any idea why this takes forever?

2

Are you running NextcloudPi? Nice kit.

3

No, because I had several issues. When I tried to update with nextcloudpi via Webinterface, I couldn’t go further than step 3 (make backup) It began backing up and stopped with error, but I dont remember what kind of, but it didn’t work well. I reinstalled nextcloud multiple times on Dietpi, rasbian, centos… always with different results. Turned out that doing a clean install with installing every service step by step was the best decision. It works well, but I encounter some bugs too. But these are some new bugs, which dozens of people encounter atm with 20.0.1.

1 Like
4

I see. Feel free to link those issues here from github. I’m definitely curious on the performance of that kit in general; I know it is a new product.

5

Well, I haven’t tried to transfer files via NFS or SMB so far. I wanted to test how this works by using the Desktop Client Application. Unfortunately this is really slow, but I think its because the Client App uploads files via https. When you run the client app via terminal, you can see messages like these:

2020-11-13 19:13:33:221 [ debug default ] [ OCC::PropagateUploadFileV1::startNextChunk ]: Trying to upload “/home/odin/Nextcloud/odin/.zshrc”
2020-11-13 19:13:34:446 [ debug default ] [ OCC::PropagateUploadFileCommon::startUploadFile ]: Running the compute checksum
2020-11-13 19:13:34:446 [ debug default ] [ OCC::PropagateUploadFileCommon::slotComputeContentChecksum ]: Trying to compute the checksum of the file
2020-11-13 19:13:34:446 [ debug default ] [ OCC::PropagateUploadFileCommon::slotComputeContentChecksum ]: Still trying to understand if this is the local file or the uploaded one
2020-11-13 19:13:34:449 [ debug default ] [ OCC::PropagateUploadFileV1::startNextChunk ]: Trying to upload “/home/odin/Nextcloud/odin/.zshrc.pre-oh-my-zsh”
2020-11-13 19:13:36:390 [ debug default ] [ OCC::PropagateUploadFileCommon::startUploadFile ]: Running the compute checksum

The client application itself shows from time to time “504 Gateway Timeouts”, or “Server replied 423 File locked” Even after setting the max_execution and max_ input_time to 3600
This takes forever and I dont think that it will ever finish…
So maybe I should prefer using NFS and rsync.
But it’s very unfortunate that this doesn’t work that well… Maybe there’s a trick to use the app and tell it to not use HTTPS and use rsync instead.

The other bugs I see in the log: