Nextcloud freezes over huge files

I’ve been using my nextcloud setup on RPi3(the latest DietPi distro, wifi connection, temperature controlled fan via pigpiod)+usb hdd (with direct power line to PSU)+2.5A power supply over a year with great success. The speed was around 1-2MB/s. Recently, I’ve switched my RPi’s wifi to the ethernet connection to my router. To test it, I’ve synced 26Gb over LAN and it got frozen during the sync. RPi Monitor still works, ssh works and htop shows that my CPU is not totally busy after I’ve got nextcloud service to stop syncing. This looks weird.

Then I’ve changed the ethernet speed to 100Mbits/s halfduplex and tried the same test again with 11Gb of files. The same thing happened, so it is not the bottleneck of RPi’s USB bus.

Please, help me investigate this case. What logs do you need?

Thanks for you report.

At first some more information would be helpful:

  • Which webserver are you using?
  • Are there other web sites active besides Nextcloud?
  • Did you recognize that sync stops after a specific time, or was it significantly different on your two tests?

To exclude hardware/kernel failures check out the latest kernel messages: dmesg

Check out the webservers error log, depending on which webserver you use/how you log:
cat /var/log/nginx|lighttpd/error.log
journalctl -t nginx|lighttpd

Then also check the PHP error log:
cat /var/log/php7.0-fpm.log
journalctl -t php7.0-fpm

Ah of course the Nextcloud log should also give some hint :wink:.

I’m using Lighttpd, as dietpi-software installed it with nextcloud automatically. I’ve used nginx on previous DietPi versions just fine(on wifi, haven’t try ethernet connection that time).

Apart from nextcloud I have only RPi-Monitor as you can see in the screenshot I posted before. And I have my own python script using pigpiod library to control the fan. Nothing else is installed here.

About the timing of the crashes - I didn’t measure it, but the nextcloud is having a hard time preparing for syncing big files, probably, it calculates the files hash sum.

In dmesg the only errors I’ve found are those lines:
[ 0.612588] mmc-bcm2835 3f300000.mmc: could not get clk, deferring probe
[ 0.614081] sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe
[ 0.615462] sdhci-pltfm: SDHCI platform and OF driver helper
[ 0.617884] ledtrig-cpu: registered to indicate activity on CPUs
[ 0.619294] hidraw: raw HID events driver (C) Jiri Kosina
[ 0.620677] usbcore: registered new interface driver usbhid
[ 0.621990] usbhid: USB HID core driver
[ 0.623637] vchiq: vchiq_init_state: slot_zero = bdd80000, is_master = 0
[ 0.625874] [vc_sm_connected_init]: start
[ 0.628613] vc_vchi_sm_init: failed to open VCHI service (-1)
[ 0.628617] [vc_sm_connected_init]: failed to initialize shared memory service
[ 0.631332] [vc_sm_connected_init]: end - returning -1
[ 139.553472] TCP: request_sock_TCP: Possible SYN flooding on port 8888. Sending cookies. Check SNMP counters.
Something wrong with RPi-monitor over here?

Which is known and harmless:

I’ve tried to replicate the problem and I’ve noticed:
Nextcloud gui on PC at the beginning of the 3.5Gb file transfer gets stuck for a while. Then it throws Connection timeout error. 1Gb-1.5Gb files gets stuck for a while but copies just fine after that.

/var/log/lighttpd/error.log is blank

/var/log/php7.0-fpm.log is also blank

Couldn’t find the nextcloud.log in /var/log/. Is there another place I should check?

My logging is setup by default to Ramlog #1, so it should be at /var/log/

I think it has something to do with formatting and the kernel…I think 32bit and ARM cannot do greater than 2GB files…the 64Bit OS’s can handle stupid huge file sizes
Found this…but was for owncloud…not nextcloud

Are you using the nextcloud client to sync to the nextcloud server?

Yes, I’m using windows GUI for it. Not the web page.

Is there an easy way to swap lighttpd to nginx without deleting the nextcloud? dietpi-software wants me to delete it first.

Previously, I was able to transfer files up to 10Gb without a problem.

You can check your Nextcloud error log within the web ui admin panel, using the log reader app, or within your Nextcloud data directory: /path/to/data/nextcloud.log

As you also tried it with 1,5 GB files, I guess kernel/fs size limitations should not be the issue here.

You can manually remove Lighttpd and install Nginx:
dietpi-software uninstall 84
dietpi-software install 85

Then reinstall Nextcloud to apply the Nginx configuration changes, better review/adjust your chosen Nextcloud data directory first as well:
sed -i ‘/SOFTWARE_NEXTCLOUD_DATADIR=/c\SOFTWARE_NEXTCLOUD_DATADIR=/path/to/my/data’ /DietPi/dietpi.txt
dietpi-software reinstall 114

Thanks for the info - I’ve moved to nginx and now I can sync 5,5 Gb file in 9 min 10 sec (10-11MB/s shown in Nextcloud GUI) :slight_smile:

Even RPI Monitor got faster and more responsive, still got the SYN flooding warning though:
[ 891.675430] TCP: request_sock_TCP: Possible SYN flooding on port 8888. Sending cookies. Check SNMP counters.
Shall I create another thread about it?

Great to here that it’s working now. Yeah a new thread about the port 8888 flooding is a good idea.

I will do some tests on VM about the Lighttpd performance. Needs investigation, if some settings tuning is needed.

Hmm, it looks like RPI monitor issue is gone, so I’m not going to open a new thread.

BTW, could you have a look at the nginx optimization, please? Even RPI monitor is faster with it, compared to lighttd.

Hmm just tested upload of >2 GB file on Lighttpd and Nginx on otherwise identical fresh VM and got exactly the same transfer rate on both webservers. Also I couldn’t recognize any significant difference in Nextcloud web ui responsiveness :thinking:.

Perhaps your Lighttpd configuration was somehow old, some improvements missing or something broken over time? Would need testing with a fresh Lighttpd installation again, but if Nginx is working fine now, better not change something again :wink:.

I will keep an eye on it and will check a bid transfer rates/responsiveness for the different webbrowsers, if testing anyway.