Ocs/v2.php/apps/serverinfo/api/v1/info takes 30-50 seconds to execute

Nextcloud version: 18.0.4
Operating system and version: debian 10 (buster)
Apache or nginx version: nginx 1.14.2-2+deb10u1
PHP version: 7.3

The issue you are facing:

as per the subject, the serverinfo api endpoint takes 30-50 seconds to execute, it took ~7 when I first started using it, here it took 30:

$ time curl --user netdata http://localhost/nc/ocs/v2.php/apps/serverinfo/api/v1/info?format=json
Enter host password for user 'netdata':
{"ocs":{"meta":{"status":"ok","statuscode":200,"message":"OK"},"data":{"nextcloud":{"system":{"version":"","theme":"","enable_avatars":"yes","enable_previews":"yes","memcache.local":"\\OC\\Memcache\\Redis","memcache.distributed":"\\OC\\Memcache\\Redis","filelocking.enabled":"yes","memcache.locking":"\\OC\\Memcache\\Redis","debug":"no","freespace":286568873984,"cpuload":[0.67,0.59,0.5],"mem_total":8169572,"mem_free":5268740,"swap_total":0,"swap_free":0,"apps":{"num_installed":50,"num_updates_available":0,"app_updates":[]}},"storage":{"num_users":75,"num_files":21194502,"num_storages":699,"num_storages_local":1,"num_storages_home":631,"num_storages_other":67},"shares":{"num_shares":156,"num_shares_user":39,"num_shares_groups":0,"num_shares_link":87,"num_shares_mail":2,"num_shares_room":13,"num_shares_link_no_password":87,"num_fed_shares_sent":0,"num_fed_shares_received":0,"permissions_10_19":12,"permissions_10_31":1,"permissions_3_4":2,"permissions_0_15":3,"permissions_0_31":28,"permissions_3_31":1,"permissions_0_19":5,"permissions_0_1":3,"permissions_4_1":2,"permissions_3_1":64,"permissions_11_0":15,"permissions_3_15":6,"permissions_3_3":14}},"server":{"webserver":"nginx\/1.14.2","php":{"version":"7.3.14","memory_limit":536870912,"max_execution_time":3600,"upload_max_filesize":1048576000},"database":{"type":"pgsql","version":"PostgreSQL 11.7 (Debian 11.7-0+deb10u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit","size":18460082847}},"activeUsers":{"last5minutes":6,"last1hour":28,"last24hours":45}}}}
real    0m30,890s
user    0m0,018s
sys     0m0,000s

The server seems to be otherwise responsive.
Note that the huge number of files is due to 3 external smb storages, I think that’s what caused the problem, but now I removed those storages and the number of files didn’t change.

If I look at the netdata metrics, I see that postgresql is returning more than 10000000 (ten millions) tuples at the time of that query (btw, I saw spikes of 100 millions tuples at other times).

Note that those external storages have around 3 millions files, so I don’t know where those 21 millions come from.
Maybe nextcloud is indexing the same file for each user?
Also I don’t understand why it reports num_storages:699, num_storages_home:631 and num_storages_other:67, I only had 3 external storages (all of them removed at the time of the query).

The serverinfo api is back to its normal 5 seconds response time, but it still reports 21 million files and 699 storages.

I think you can refer to Files amount after moving of data directory is wrong (much bigger) have had similar issue and need to delete unused externals and internals.

1 Like

Thank you , it’s definitely that but it’s not clear to me how to recover. In my case I have just one local storage, a bunch of “home” storage and the same “smb” storages repeated for each user. I’m tempted to file a bug report since I did nothing outside nextcloud to cause this issue.
Edit a funny (or not so funny) detail: all the smb storages have a “1” in the “available” field, in spite of having deleted them from the nextcloud interface.

Recover is in a few steps.

Step 1. Find out what is wrong in DB by listening all shares, data folders etc. You should execute command in shell to your DB, e.g. mysql/mariaDB:

You will see a table and should identify what are wrong storage’s there.

Step 2.

Step 3.

the ID is in a second raw in table from Step 1.

Step 4. Do some DB cleanup:

Step 5. Run FS rescan, for this use command:
sudo -u www-data php occ files:cleanup

You can see on my graphs in older treat that this operation will take a while…

I’m doing the occ files:cleanup now, but I had to exit maintenance mode, otherwise occ would tell me that there’s no files namespace.

That’s for sure, sorry forgot to mentioned that.

My bet would be on overloaded apps.nextcloud.com when checking for app updates.