Nextcloud Webinterface langsam

G-Red

Commander
Registriert
Jan. 2016
Beiträge
2.404
Hi Leute,
ich hoffe jemand kann mich auf eine Idee bringen wo ich suchen könnte, bei folgendem Problem.

Ich hab eine selbstgehostete Nextcloud Instanz auf einem VPS laufen.
Gerade läd ein Benutzer, der an einem anderen Standort lebt, einige seine Daten hoch.
Dabei ist die Antwortzeit der Webseite sagen wir mal so, recht bescheiden. Die einzelnen Ordner oder Bereiche laden sehr langsam.
Auch über Mobilfunk habe ich es probiert, um eiegene Verbindungsproblemme auszuschließen, mit demselben Ergebnis.

Mein VPS ist bei Netcup und hat 2 vCPU und 4GB RAM.
Laut htop, langweilt sich die CPU und es werden knapp 900MB RAM gerade verbraucht.

Wo könnte man da bei der Suche nach der Ursache ansetzen?

Danke euch schon mal für eure Antworten!
 
Könnte auch an php liegen. Welche php Version läuft auf dem Server? Wird php-fpm genutzt? Kannst du in den php Einstellungen das memory Limit erhöhen?
 
@Mordenkainen
Nicht viele ua. OnlyOffice, wenn jetzt von was swergewichtigem die Rede ist. Hast du was konkretes in Verdacht?

Das Ding ist, das gegenwärtige Verhalten hat angefangen, nach dem der Mensch seine Daten anfing hoch zu laden. Zvor war alles gut.
Ergänzung ()

Ikebana schrieb:
Könnte auch an php liegen. Welche php Version läuft auf dem Server? Wird php-fpm genutzt? Kannst du in den php Einstellungen das memory Limit erhöhen?
ja, es wird php-fpm benutzt und ich könnte es erhöhen. Gibts einen Vorschlag zu dem Wert der da rein soll?
Ach so und es wird PHP7.3-FPM benutzt.

Das derzeitige memory_limit ist bei 1024M
 
Zuletzt bearbeitet:
Ich hab das hier in meiner php-fpm config:
Code:
;
; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time = 30

; Maximum amount of time each script may spend parsing request data. It's a good
; idea to limit this time on productions servers in order to eliminate unexpectedly
; long running scripts.
; Note: This directive is hardcoded to -1 for the CLI SAPI
; Default Value: -1 (Unlimited)
; Development Value: 60 (60 seconds)
; Production Value: 60 (60 seconds)
; http://php.net/max-input-time
max_input_time = 60

; Maximum input variable nesting level
; http://php.net/max-input-nesting-level
;max_input_nesting_level = 64

; How many GET/POST/COOKIE input variables may be accepted
;max_input_vars = 1000

; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit = 1024M
Hier gibts auch noch Tipps: Nextcloud Server Tuning
 
Ikebana schrieb:
Ich hab das hier in meiner php-fpm config:
Code:
; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit = 1024M
Hier gibts auch noch Tipps: Nextcloud Server Tuning
Ist bei mir ebenfalls.
 
php-fpm 7.3 klingt nach Debian 10. Würde ich mal grundsätzlich nicht ausschließen aber könnte auch am Webserver liegen. Was nutzt du? apache2, nginx, lighttpd?
 
Generell langsam ist Ajax. Da du deinen eigenen Server hast, kannst du stattdessen cron aktivieren, falls noch nicht geschehen.
 
Ikebana schrieb:
php-fpm 7.3 klingt nach Debian 10. Würde ich mal grundsätzlich nicht ausschließen aber könnte auch am Webserver liegen. Was nutzt du? apache2, nginx, lighttpd?
Ist Debian 9, mit nginx als webserver.

Welche Maschiene nutzt du?
Ergänzung ()

Iapetos schrieb:
Generell langsam ist Ajax. Da du deinen eigenen Server hast, kannst du stattdessen cron aktivieren, falls noch nicht geschehen.
Ist bereits der Fall. Habe sogar die ausführung der cron.php als Service eingerichtet, weil cron manchmal nicht angelaufen war. Aber wie gesagt, das Problem besteht zumindest derzeit, während ein anderer Nutzer Daten hochlädt.
 
Habe Debian 10 mit nginx und ebenfalls php-fpm7.3.
Hier mal meine nginx config:
Code:
upstream php-handler {
    #server 127.0.0.1:9000;
    server unix:/run/php/php7.3-fpm.sock;
}

server {
    listen 80;
    server_name XXXXX;
    # enforce https
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name XXXXXX;
    ssl_certificate /etc/letsencrypt/live/XXXXX/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/XXXX/privkey.pem;


    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA512:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:ECDH+AESGCM:ECDH+AES256:DH+AESGCM:DH+AES256:!aNULL:!eNULL:!LOW:!RC4:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS;
    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/nginx/dhparam.pem;

    ssl_session_timeout 5m;
    ssl_session_cache shared:SSL:5m;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
    add_header X-Frame-Options SAMEORIGIN;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    add_header X-Download-Options noopen;
    add_header X-Permitted-Cross-Domain-Policies none;
    add_header Referrer-Policy no-referrer;

    # Remove X-Powered-By, which is an information leak
    fastcgi_hide_header X-Powered-By;

    # Path to the root of your installation
    root /var/www/nextcloud;

    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    # The following 2 rules are only needed for the user_webfinger app.
    # Uncomment it if you're planning to use this app.
    #rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
    #rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

    # The following rule is only needed for the Social app.
    # Uncomment it if you're planning to use this app.
    # rewrite ^/.well-known/webfinger /public.php?service=webfinger last;

    location = /.well-known/carddav {
      return 301 $scheme://$host/remote.php/dav;
    }
    location = /.well-known/caldav {
      return 301 $scheme://$host/remote.php/dav;
    }

    # set max upload size
    client_max_body_size 512M;
    fastcgi_buffers 64 4K;

    # Enable gzip but do not remove ETag headers
    gzip on;
    gzip_vary on;
    gzip_comp_level 4;
    gzip_min_length 256;
    gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
    gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

    # Uncomment if your server is build with the ngx_pagespeed module
    # This module is currently not supported.
    #pagespeed off;

    location / {
        rewrite ^ /index.php;
    }

    location ~ ^\/(?:build|tests|config|lib|3rdparty|templates|data)\/ {
        deny all;
    }
    location ~ ^\/(?:\.|autotest|occ|issue|indie|db_|console) {
        deny all;
    }

    location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+)\.php(?:$|\/) {
        fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;
        try_files $fastcgi_script_name =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param HTTPS on;
        #Avoid sending the security headers twice
        fastcgi_param modHeadersAvailable true;
        fastcgi_param front_controller_active true;
        fastcgi_pass php-handler;
        fastcgi_intercept_errors on;
        fastcgi_request_buffering off;
    }

    location ~ ^\/(?:updater|oc[ms]-provider)(?:$|\/) {
        try_files $uri/ =404;
        index index.php;
    }

    # Adding the cache control header for js and css files
    # Make sure it is BELOW the PHP block
    location ~ \.(?:css|js|woff2?|svg|gif)$ {
        try_files $uri /index.php$request_uri;
        add_header Cache-Control "public, max-age=15778463";
        # Add headers to serve security related headers (It is intended to
        # have those duplicated to the ones above)
        # Before enabling Strict-Transport-Security headers please read into
        # this topic first.
        # add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
        #
        # WARNING: Only add the preload option once you read about
        # the consequences in https://hstspreload.org/. This option
        # will add the domain to a hardcoded list that is shipped
        # in all major browsers and getting removed from this list
        # could take several months.
        add_header X-Content-Type-Options nosniff;
        add_header X-XSS-Protection "1; mode=block";
        add_header X-Robots-Tag none;
        add_header X-Download-Options noopen;
        add_header X-Permitted-Cross-Domain-Policies none;
        add_header Referrer-Policy no-referrer;

        # Optional: Don't log access to assets
        access_log off;
    }

    location ~ \.(?:png|html|ttf|ico|jpg|jpeg)$ {
        try_files $uri /index.php$request_uri;
        # Optional: Don't log access to other assets
        access_log off;
    }
}
Ich nutze nginx 1.14.2, der müsste in den backports für Debian 9 eigentlich drinnen sein.

Edit: Läuft als KVM VM auf nem i5 3470 mit 4GB RAM bei mir im Keller
 
@Ikebana
im vergleich zu deiner Konfig, habe ich
max_execution_time = 3600
max_input_time = 3600

Den ersten Wert habe ich so abgeändert, weil es Probleme gab beim Installieren des CommunityDokumentServer. Der File war zu groß und daher wurde die Installation abgebrochen.

Beim zweiten Wert weiß ich nicht mehr warum der so ist. Eventuell auch so eingestellt nach der Anleitung vom Kollegen CRieger, falls bekannt.
 
Mal ganz stumpf kannst du mal ein
systemctl restart php7.3-fpm
systemctl restart nginx
systemctl restart mariadb
probieren.
Neustarts helfen auch wunder hin und wieder.
Wobei ich nichts installiert habe neben den Basis-Plugins.
 
Ja, das könnte ich mal machen, aber derzeit schlecht weil der Nutzer die Daten noch hochschiebt.. sind um die 13GB.. wäre unschön Ihn dabei zu unterbrechen :).

"Reboot tut gut" ist eine Möglichekeit, die ich aber erst morgen dann probiere.

Danke dir schon mal für die Betreiligung und auch den Anderen für die Ideen. Falls jemandem noch etwas einfallen sollte wo ich suchen kann immer her damit.
 
1. Das Webinterface von Nextcloud zum Dateiupload zu benutzen ist die denkbar schlechteste Möglichkeit. Es lässt sich schon viel gewinnen, wenn der Netcloud Client genutzt wird oder Laufwerke über WebDav eingebunden werden.

2. Wenn du schreibst "die CPU langweilt sich". Wie hast du das ermittelt?
2.1. Die schaut es denn mit der Auslastung des Festspeichers aus? Also nicht nur Füllgrad sondern die Auslastung vom Datenträger. Selbst die SSDs auf denen die VPS bei Netcup laufen sind ja nicht sonderlich schnell.

3. Welche Plugins sind alle installiert?
 
hast du mal auf dedicated cpus migriert?
die sahred vcpus bei netcup sind eher stark überbucht
vor allem aktuell. Langeweile der cpu laesst sich nicht gut ermitteln
ansonsten: ioload? SSD?
 
Wieviele worker process hast du für php-fpm konfiguriert versuch mal die ob mehr Prozesse etwas bringen.

pm.start_servers = 10 z. B
 
Piktogramm schrieb:
1. Das Webinterface von Nextcloud zum Dateiupload zu benutzen ist die denkbar schlechteste Möglichkeit. Es lässt sich schon viel gewinnen, wenn der Netcloud Client genutzt wird oder Laufwerke über WebDav eingebunden werden.
Der gestrige Upload hat nicht über die Weboberfläche stattgefunden, sondern über ein Drittanbieter Programm auf OSX. Sowas ähnliches wie Filezilla.

Piktogramm schrieb:
2. Wenn du schreibst "die CPU langweilt sich". Wie hast du das ermittelt?

2.1. Wie schaut es denn mit der Auslastung des Festspeichers aus? Also nicht nur Füllgrad sondern die Auslastung vom Datenträger. Selbst die SSDs auf denen die VPS bei Netcup laufen sind ja nicht sonderlich schnell.
Ich habe mir während des Uploadprozesses die Auslastung mit htop und top sowie iotop anzeigen lassen. Die CPU dümpelte die ganze zeit bei irgendwo 8 bis 10% Auslastung mit gelegentlichen Peaks von 50%.

Piktogramm schrieb:
3. Welche Plugins sind alle installiert?
- accessibility: 1.4.0
- activity: 2.11.0
- admin_audit: 1.8.0
- calendar: 2.0.3
- cloud_federation_api: 1.1.0
- dav: 1.14.0
- documentserver_community: 0.1.5
- external: 3.5.0
- extract: 1.2.4
- federatedfilesharing: 1.8.0
- federation: 1.8.0
- files: 1.13.1
- files_accesscontrol: 1.8.1
- files_external: 1.9.0
- files_pdfviewer: 1.7.0
- files_rightclick: 0.15.2
- files_sharing: 1.10.1
- files_trashbin: 1.8.0
- files_versions: 1.11.0
- files_videoplayer: 1.7.0
- logreader: 2.3.0
- lookup_server_connector: 1.6.0
- notifications: 2.6.0
- oauth2: 1.6.0
- onlyoffice: 4.1.4
- password_policy: 1.8.0
- photos: 1.0.0
- provisioning_api: 1.8.0
- serverinfo: 1.8.0
- settings: 1.0.0
- sharebymail: 1.8.0
- support: 1.1.0
- systemtags: 1.8.0
- text: 2.0.0
Ergänzung ()

madmax2010 schrieb:
hast du mal auf dedicated cpus migriert?
die sahred vcpus bei netcup sind eher stark überbucht
vor allem aktuell. Langeweile der cpu laesst sich nicht gut ermitteln
Kann ich das innerhalb des VPS Vertrages ohne Kostenänderung realisieren, oder ist das dann ein Dedicated Server den ich mieten muss?

Du scheinst dich mit Netcup auszukennen. Wie ist den deine Erfahrung mit den und lohnt es sich woanders hinzuzihen?

madmax2010 schrieb:
ansonsten: ioload? SSD?
ioload hab ich nicht versucht nur iotop und es ist laut meinem vertrag eine SSD.
 
Zuletzt bearbeitet:
Die Frage nach der Auslastung vom I/O hast du geschickt ignoriert wa? :)

Und mal ehrlich, wieso nennst du nicht einfach das Drittanbieter Programm? Du willst Hilfe, gibt doch bitte einfach Informationen vollständig anstatt mit jeder 2. Aussage weitere Nachfragen zu provozieren.

Nunja weiter im Programm, über welche Schwere von "langsam" reden wir eigentlich? Es wäre mal interessant, wenn du misst wie lang das laden einer Seite normalerweise dauert und wie lang, wenn Uploads anderer Nutzer laufen. Also Entwicklertools vom Browser auf und los geht es.
Wenn du das tust wäre gleich noch zu kontrollieren, ob du http/1.1 oder http/2 nutzt. HTTP/2 skaliert mit Nextcloud auf meiner Instanz ganz hervorragend.
 
cloudman schrieb:
Wieviele worker process hast du für php-fpm konfiguriert versuch mal die ob mehr Prozesse etwas bringen.

pm.start_servers = 10 z. B
In meiner nginx.conf habe ich
Code:
worker_processes 2;
stehen.
Bei dem Wert den du meinst, steht bei mir 20
Ergänzung ()

Piktogramm schrieb:
Die Frage nach der Auslastung vom I/O hast du geschickt ignoriert wa? :)
Eigentlich nicht. Ich hatte doch von iotop geschrieben und dass die Last gestern, nach meinem Verständniss, nicht groß war.

Piktogramm schrieb:
Und mal ehrlich, wieso nennst du nicht einfach das Drittanbieter Programm? Du willst Hilfe, gibt doch bitte einfach Informationen vollständig anstatt mit jeder 2. Aussage weitere Nachfragen zu provozieren.
Ich hoffe du füllst dich nicht provoziert und das so früh am Morgen :). Ich gebe die Infos weiter die ich habe. Den Namen des Programs, mit dem gestern Hochgeladen war wußte ich nicht, weil es meinem Verständniss nach eher irrelvant war, bis du danach gefragt hast. Habe jedoch nachgefragt, es heißt Transmit und wird unter OSX verwendet.

Piktogramm schrieb:
Nunja weiter im Programm, über welche Schwere von "langsam" reden wir eigentlich? Es wäre mal interessant, wenn du misst wie lang das laden einer Seite normalerweise dauert und wie lang, wenn Uploads anderer Nutzer laufen. Also Entwicklertools vom Browser auf und los geht es.
Wenn du das tust wäre gleich noch zu kontrollieren, ob du http/1.1 oder http/2 nutzt. HTTP/2 skaliert mit Nextcloud auf meiner Instanz ganz hervorragend.
Das könnte ich machen, müsste aber mal mich mit dem menschen Absprechen so dass ich das wieder beobachten und aufzeichnen kann.

Wegen der Schwere von "langsam" naja, es ist der gefüllte Vergleich mit dem was kurz zuvor noch sehr schnell ging, also Seitenaufbau und wechsel zwischen den Ordner, ging dann nach dem beginn des Uploads sehr träge. Man mkönnte nach dem Klicken auf ein Element denk ich langsam bis 5 zählen, bis die Seite da war.
 
Zuletzt bearbeitet:
Zurück
Oben