Unhappy Nextcloud box

Hi,

I have very recently purchased a Nextcloud Box to hopefully replace dropbox.

It has installed OK and I have transferred a large amount of photos to it. Unfortunately I can no longer connect the android app-The server took too long to respond.
If I connect via SSH using putty it takes 50s after entering the password to get a command prompt. Is this normal?

I ran Sudo snap list via ssh and got core 16-2 rev 2314 and nextcloud 11.0.3snap6 rev 1983

How can I get this working?

Thanks,

Robin

Hello Robin,

More competent persons will complete my post, however as goat feeling about a network problem where for some reason it takes long to resolv your box.

However when log in ssh, launch top command to see the cpu load and ram.

I think its safe to say that you should not normally get those kind of delays, but as slapps suggests I would check your CPU and memory usage with the top command, and let us know how that looks.

Long SSH login times can sometimes be caused by a delay in dns resolution but the cpu and ram would be the first thing to check.

Let’s assume you have CPU and/or memory performance issue. Have you enabled the preview-generator app and the reffering cron job? This might be to early to propose a root cause, but could give a hint were to take a look in the next step.

I’ve run Top, but I don’t know what I’m looking at.

Does this make sense. I’m new to the Raspberry Pi.

On the DNS front, I’ve only been able to connect with the IP address. Could this suggest a problem?

Thanks,

Robin

This is a fresh install of nextcloud using the SD card supplied with the Nextcloud box. I haven’t changed the configuration ( I wouldn’t know how). How would I check what apps are enabled?
The system is currently using a Pi2 v1.1. I do have a v1.2 but I think I would have to use the image for the Pi 3. Would this be a good idea?
I also have an 8GB SD card I could use if that would also help.

Thanks for your help.

Your problem is the 72,7% io-wait, the processes have to wait until the data is written into your file system. You can check the processes who access your hard disk with iotop. In many cases, a bit of database tuning (reasonable cache settings reduce io-load enormously). You should also use redis for caching.

The CPU is not overworked at all. How many clients are connected at the same time? Perhaps you can optimize the number of php-fpm instances running at the same time.

edit: scripts like tuning-primer.sh can help you with that. Some time ago I tried to optimize the upload speed of my RPi 2. It’s just to give you an idea, e.g. I activated slow query logging for debugging. The innodb_* stuff is interesting, but check out in the documentation what is behind each setting (e.g. innodb_flush_log_at_trx_commit = 2 can lead to data loss if your system crashes). I used it on a test system.

[client]
port            = 3306
socket          = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket          = /var/run/mysqld/mysqld.sock
nice            = 0

[mysqld]
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
bind-address            = 127.0.0.1
key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
myisam-recover         = BACKUP
max_connections        = 10
query_cache_limit       = 3M
query_cache_size        = 10M
log_error = /var/log/mysql/error.log
slow_query_log_file = /var/log/mysql/mysql-slow.log
slow_query_log      = 1
long_query_time = 2
expire_logs_days        = 10
max_binlog_size         = 100M
innodb_buffer_pool_size = 150M
innodb_buffer_pool_instance = 1
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 15M
innodb_max_dirty_pages_pct = 90
innodb_io_capacity = 30
innodb_thread_concurrency = 2
[mysqldump]
quick
quote-names
max_allowed_packet      = 16M
[mysql]
[isamchk]
key_buffer              = 16M
!includedir /etc/mysql/conf.d/

Hi,

This looks very daunting. I have no experience with Raspberry PI or Linux.

I would have thought I shouldn’t have problems like this as I’ve just installed it and as far as I know made no changes to Nextcloud.

Could replacing the supplied SD card with a larger one help? I could shutdown and copy the existing card contents over.

No probably not. Just as I think about it, the snappy stuff doesn’t allow changes in the configuration at all, perhaps some tuning which should be considered in the source @oparoz @kyrofa

Not a performance problem, just one of convenience, you might find and one of many dynamic DNS providers on the net can resolve that for you.

Yes you would and… Depends. Personally I prefer the older image as it’s a full Ubuntu server system ported to ARM. The new image is snappy core and offers nothing for anyone who wants to tinker and tweak a system (and gaining SSH Access is a pain).

Snappy install mind, can’t really do anything with it.

I know your feeling. However consider what the pi is - a very small, underpowered compute card. Nextcloud by comparison can be a bit resource hungry especially with media files. How much data would you say you’ve copied over?

I’d say this will fix itself in due course given it’s just queueing io currently. How does it look now? Providing you don’t rinse it with data (which is always what we tend to do with a new box I know) it should chug away OK. Apps like preview generator will help but I don’t recall how the cron would be configured with the snap.

I’ve just run Top again

It all looks a lot happier.
I uploaded 14GB of pictures in one go. I guess it got indigestion for a few days while it processed it all. Hopefully I can now get it to settle down and get on with using it.

Thanks all for your input.

Where would be a good place to start trying to understand Nextcloud and rPi administration?

1 Like

hello Robin

i got also the nextcloudbox
for me it works also too slow.
for me the bug is in the hardware WD.
the WD has a lot of internal problem. more than one time i made fsck.ext4, “e2fsck -p” and there found bad blocks every time
but Robin i have no solution to fix it, i am sorry
the iostat looks well but not only the file transfere is very slow. so it is not practicable for me

The problem is the Gallery App. I guess it renders previews in different sizes and this takes a lot of CPU and memory. When you do not rely on the ability to view pictures in the browser but just want to sync pictures across different systems, disable the App. I run a Nextcloud instance on a vServer which is a little weak on the chest and had to disable that app as well. Especially when uploading “large” images, my Nextcloud could not digest the data. I couldn’t log in, etc. Same symptoms as your RPi3

1 Like

The same here. After I’ve installed a heatsink and a fan, I managed to view a folder with ~600 photos in the web app
The server crashes when I do the same using android and iOS app though