NextCloud lädt im Webinterface lange

- Bei welchen Anbieter? Was für ein Server?
Selbst gehostet auf einem DELL PowerEdge R660 als ESXi, virtualisiert mit vmWare. Das System hat 4 CPU-Kerne mit 16 GB RAM. Steht in der DMZ, geht direkt ohne Proxy oder sonstiges raus über unsere Firewall per 443.

- Betriebssystem sowie Version ALLER beteiligten Systeme: Ubuntu 20.04
- Nextcloud Version: 27.0.2
- PHP Version: 8.2.10 (fpm)
- Welche Datenbank? MariaDB 10.6.15
- Apache version: 2.4.57
- Netzwerk Aufgliederung: VM in der DMZ, Firewall (nur Port 443 erlaubt eingehend, ausgehend alles erlaubt), dann Internet

Hallo zusammen,

ich betreibe bei uns eine NextCloud Instanz. Wir haben ca. 300 registrierte Benutzer, die alle per LDAP angebunden sind. Es kommt jede Woche vor, dass die Leute sich beschweren, dass die Cloud im Browser langsam sei. Ich selbst kann das auch sporadisch immer wieder feststellen, dass die Übersicht der Dateien beim ersten Aufruf bis zu 10 Sekunden dauert, bevor man dann die Ordner sieht.
Ist die Übersicht einmal da, geht es danach sehr zügig, wenn man durch die einzelnen Unterordner switcht.

Im Admin-Bereich merke ich die Performance-Probleme leider auch regelmäßig, dass die Seite dann beim Klick auf einen Link (z.B. Grundeinstellungen, Sicherheit etc.) auf einmal super lange braucht zum Laden. Wenn die Seite geladen ist, dann ist danach meist wieder alles bestens, so dass man dann problemlos die anderen Seiten aufrufen kann.

Ich habe testweise mal eine Wordpress-Seite auf den selben Server gepackt, um zu prüfen, ob es da auch zu Performance-Problemen kommt. Hier kann man das nie nachstellen, die Seite lädt dort immer unter 200ms bei egal welcher Seite.

Es muss also an NextCloud selbst liegen. Ich habe alle Performance-Optimierungen die auf der Website bei NextCloud stehen gemacht, wie redis installiert, apcu und opcache, aktuelle Versionen installiert, Server Push aktiviert, http2 konfiguriert usw. aber es bessert sich kein bisschen, die Geschwindigkeit ist stellenweise unterirdisch, so dass die Leute das merken und sich regelmäßig dazu melden und versuchen Alternativen zu finden wie OneDrive und Co… :frowning:

Der Serverload sieht auch gut aus, da sind wir immer bei 0.1 bis maximal 1.0 bei 4 Kernen, der RAM ist ebenfalls in Ordnung. Speicherplatz auf dem Server ist auch genug frei (aktuell fast 100 GB). Aktuell sieht es beispielsweise so in htop:

Gehe ich nun mal zur Startseite bei den Dateien sieht man gut, dass die Seite gerade wieder über 8 Sekunden gebraucht hat, obwohl gerade keiner mit der Cloud arbeitet.

iotop liefert beim Laden der Seite folgende Werte:

Ich habe folgende Config in NextCloud definiert:

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "cloud.meinedomain.de",
            "cloud.domain.local", #interner Name
            "10.20.15.55", #interne IP
            "123.123.123.123" #externe IP
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "27.0.2.1",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "default_phone_region": "DE",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "sendmail",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "loglevel": 2,
        "ldapIgnoreNamingRules": false,
        "forcessl": true,
        "theme": "",
        "lost_password_link": "disabled",
        "auth.webauthn.enabled": false,
        "maintenance": false,
        "trashbin_retention_obligation": "auto,7",
        "ldapProviderFactory": "\\OCA\\User_LDAP\\LDAPProviderFactory",
        "overwriteprotocol": "https",
        "overwrite.cli.url": "https:\/\/cloud.meinedomain.de",
        "skeletondirectory": "",
        "force_language": "de_DE",
        "force_locale": "de_DE",
        "allow_user_to_change_display_name": false,
        "updater.release.channel": "stable",
        "encryption.key_storage_migrated": false,
        "app_install_overwrite": [
            "bruteforcesettings",
            "pdfdraw"
        ],
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "mail_sendmailmode": "pipe",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "25",
        "mail_smtpauth": 1,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0
        }
    }
}

Folgende Apps sind installiert:

Enabled:
  - activity: 2.19.0
  - bruteforcesettings: 2.7.0
  - calendar: 4.4.5
  - circles: 27.0.1
  - cloud_federation_api: 1.10.0
  - collectives: 2.7.1
  - comments: 1.17.0
  - contacts: 5.3.2
  - contactsinteraction: 1.8.0
  - dav: 1.27.0
  - deck: 1.10.0
  - federatedfilesharing: 1.17.0
  - federation: 1.17.0
  - files: 1.22.0
  - files_pdfviewer: 2.8.0
  - files_rightclick: 1.6.0
  - files_sharing: 1.19.0
  - files_trashbin: 1.17.0
  - files_versions: 1.20.0
  - firstrunwizard: 2.16.0
  - groupfolders: 15.2.0
  - logreader: 2.12.0
  - lookup_server_connector: 1.15.0
  - nextcloud_announcements: 1.16.0
  - notifications: 2.15.0
  - notify_push: 0.6.3
  - oauth2: 1.15.1
  - onlyoffice: 8.2.0
  - photos: 2.3.0
  - polls: 5.3.2
  - privacy: 1.11.0
  - provisioning_api: 1.17.0
  - related_resources: 1.2.0
  - serverinfo: 1.17.0
  - settings: 1.9.0
  - sharebymail: 1.17.0
  - spreed: 17.0.3
  - systemtags: 1.17.0
  - text: 3.8.0
  - theming: 2.2.0
  - twofactor_backupcodes: 1.16.0
  - updatenotification: 1.17.0
  - user_ldap: 1.17.0
  - viewer: 2.1.0
  - workflowengine: 2.9.0
Disabled:
  - admin_audit: 1.17.0
  - dashboard: 7.7.0 (installed 7.2.0)
  - encryption: 2.15.0 (installed 2.13.0)
  - files_external: 1.19.0 (installed 1.4.1)
  - password_policy: 1.17.0 (installed 1.3.0)
  - recommendations: 1.6.0 (installed 0.7.0)
  - support: 1.10.0 (installed 1.0.0)
  - survey_client: 1.15.0 (installed 1.1.0)
  - suspicious_login: 5.0.0
  - twofactor_totp: 9.0.0 (installed 2.1.2)
  - user_status: 1.7.0 (installed 1.0.1)
  - weather_status: 1.7.0 (installed 1.4.0)

Der Integrity-Status findet keine Fehler, da ist alles sauber.

Das Logfile hat nur 5 Einträge, wo es falsche Zugangsdaten von Benutzern gab, also nichts auffälliges.

Den PHP FPM Pool habe ich auch schon mal angepasst, um hier ggf. nach Fehlern zu suchen. Der ist aktuell wie folgt konfiguriert:

pm = dynamic
pm.max_children = 120
pm.start_servers = 12
pm.min_spare_servers = 6
pm.max_spare_servers = 18

Sonst habe ich schon mehrmals folgendes geprüft und umgesetzt:
Server tuning — Nextcloud latest Administration Manual latest documentation

Hat vielleicht irgendjemand einen Tipp, wo ich ansetzen könnte, um das Problem zu finden? :slight_smile:

Falls noch Infos benötigt werden, liefere ich die natürlich gerne.

DANKE!

Eine Ursache dürfte hier liegen:

Da geht ja noch einiges für VMWare ab und bei derart vielen Usern würde ich schon eher das drei- bis vierfache an RAM veranschlagen wollen.
Dazu kommt noch die Wahl des Massenspeichers. HDD ist recht langsam.

Ein Blick ins Nextcloud-Log könnte auch Informationen liefern (Weboberfläche - Einstellungen - Protokollierung oder auf OS-Ebene die nextcloud.log (entweder in /var/log oder im Nextcloud Programmverzeichnis)

Hey,

danke für deine Antwort.
Gleichzeitig sind immer nur so 10 Leute drauf, nicht alle 300 gleichzeitig. Da sollte das doch reichen oder?
Sonst könnte ich den RAM aber auch gerne erweitern, da habe ich einiges an Luft.

Das log ist wie oben geschrieben leer. Hatte vor wenigen Tagen das Update gemacht und das log geleert gehabt. Bis heute ist da kaum was aufgelaufen

Habe mal für ein paar Tage den RAM verdoppelt, das ändert leider rein gar nichts an der Performance :disappointed:

Jemand noch einen Tipp, wo ich ansetzen könnte?

Ideen:

  • Hast Du evtl. einen externen Storage angebunden der Zeit braucht?
  • Prüfe in der Entwicklerkonsole von FF, ob da sowas kommt: Firefox kann keine Verbindung zu dem Server unter wss://server-url//push/ws aufbauen. Dann musst Du im Apache oder NginX die websockets proxy Funktion richtig konfigurieren.

Hast Du mal die Datenbank geprüft bzw. Teste doch mal PostgreSQL…

Hey,

danke für eure Antworten!
Externe Speicher habe ich nicht eingebunden.
In den Entwicklertools ist alles gut, keine roten Meldungen oder Fehler.

Nutze MariaDB und habe die Datenbank die letzten Tage mit MySQL-Tuner etwas angepasst (in der NextCloud Doku werden übrigens Dinge vorgeschlagen, die nicht mehr existieren in MariaDB obwohl recommended). Man merkt ein klitze kleines bisschen mehr Schwung aber nicht so, dass man nun produktiver damit arbeitet.

Angebunden ist alles per Gigabit und auf SSD gelagert (SSD Storage).

Ich weiß nicht ob es hilft, aber ich lass dir mal meine Konfiguration hier, denn so wie du das schilderst würde es mir auch weniger Spaß machen damit zu arbeiten bzw. zu zäh anfühlen.

Ich habe hier drei Instanzen unter meinen Händen wovon jede ca. 7 Sekunden (bei deaktiviertem Cache) braucht für einen Login bis das Dashboard fert geladen ist (Widgets: Kalendar, Talk, Mail, Wetter)

~4.5 Sekunden mit Cache, der Wechsel in die Datei App oder Kalender liegt meistens so bei 2.3 Sekunden im Schnitt.


Das Endgerät spielt auch eine Rolle, das sind die Werte von meiner Arbeitsstation (Ein fester PC mit AMD Ryzen 5 1600X mit 64GB RAM - Windows 10 Pro und Firefox) mein Notebook ein älteres Yoga braucht für den Login bis zu 4 Sekunden länger, danach überall ca. 1-2 Sekunden.

Das hier ist die Hardware des Servers (Bare Metal):

  • Intel Core i5-12500
  • 2x RAM 32768 MB DDR4
  • 2x SSD M.2 NVMe 512 GB
  • 1x HDD SATA 12,0 TB Enterprise
  • Betriebsystem: Debian Bookworm

Die Nextcloud ist in einem LXC-Container installiert, daneben laufen noch ein Colabora, Moodle und zwei nicht wirklich nenenswerte Applikationen jewilig in einem eigenen LXC-Container.
Noch anzumerken, die MariaDB liegt derzeit mit im Nextcloud-Container, ich sah noch keinen Grund die einzeln zu wollen.

Sowohl im inneren als auch im äußeren kommt nginx (nginx/1.25.2) zum einsatz, als DB (10.11.5-MariaDB, for debian-linux-gnu (x86_64))

Das root des Containers liegt auf der SSD, die Daten liegen alle außer appdata_xxxxxxxxx (wo u.a. die ganzen Prieviews sind) auf der HDD, der besagte appdata Ordner hat seine eigene SSD.

Wie bei dir kommen meine User aus dem LDAP ~300, das LDAP liegt in einem anderen Netzwerk die Daten müssen also immer durch ein VPN auf Reisen gehen.
Die MariaDB hat eine Größe von 3.6GB, auf der Daten HDD liegen ca. 4TB an Daten.
In appdata_xxxxxxxxx sind ca. 180GB in an Prieview-Images.

Für Die Cloud nutze ich APCu und Redis

'memcache.local' => '\\OC\\Memcache\\APCu',
'memcache.distributed' => '\\OC\\Memcache\\Redis',
'memcache.locking' => '\\OC\\Memcache\\Redis',

Auch für die PHP Sessions nutze ich Redis:

sed -i 's/^session.save_handler = files/;session.save_handler = files/g' /etc/php/8.2/fpm/php.ini
sed -i '/^;session.save_handler =.*/a session.save_handler = redis' /etc/php/8.2/fpm/php.ini
sed -i 's/;session.save_path =.*/session.save_path = "unix:\/\/\/var\/run\/redis\/redis-server.sock"/g' /etc/php/8.2/fpm/php.ini
sed -i '/^session.save_path =.*/a redis.session.lock_wait_time = 10000' /etc/php/8.2/fpm/php.ini
sed -i '/^session.save_path =.*/a redis.session.lock_retries = -1' /etc/php/8.2/fpm/php.ini
sed -i '/^session.save_path =.*/a redis.session.locking_enabled = 1' /etc/php/8.2/fpm/php.ini

DB-Index 0 für die PHP Sessions und DB-Index 1 für die Nextcloud

Meine MariaDB sieht so aus:

cat > /etc/mysql/mariadb.cnf << EOF
[client]
default-character-set = utf8mb4
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld_safe]
log_error=/var/log/mysql/mysql_error.log
nice = 0
socket = /var/run/mysqld/mysqld.sock

[mysqld]
basedir = /usr
bind-address = 127.0.0.1
binlog_format = ROW
bulk_insert_buffer_size = 16M
character-set-server = utf8mb4
collation-server = utf8mb4_general_ci
concurrent_insert = 2
connect_timeout = 5
datadir = /var/lib/mysql
default_storage_engine = InnoDB
expire_logs_days = 2
general_log_file = /var/log/mysql/mysql.log
general_log = 0
innodb_buffer_pool_size = 2G
# 1/4 up to 1/2 of innodb_buffer_pool_size
innodb_log_file_size = 512MB
# increased from 32 to 64
innodb_log_buffer_size = 64M
innodb_flush_log_at_trx_commit = 2
innodb_max_dirty_pages_pct = 90
innodb_file_per_table = 1
innodb_open_files = 400
innodb_io_capacity = 4000
innodb_flush_method = O_DIRECT
innodb_read_only_compressed=OFF
key_buffer_size = 128M
lc_messages_dir = /usr/share/mysql
lc_messages = en_US
log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
log_error = /var/log/mysql/mysql_error.log
log_slow_verbosity = query_plan
log_warnings = 2
long_query_time = 1
# increased from 16 to 32
max_allowed_packet = 32M
max_binlog_size = 100M
max_connections = 2000
max_heap_table_size = 64M
myisam_recover_options = BACKUP
myisam_sort_buffer_size = 512M
port = 3306
pid-file = /var/run/mysqld/mysqld.pid
query_cache_limit = 2M
query_cache_size = 64M
query_cache_type = 1
query_cache_min_res_unit = 2k
# increased from 2 to 4
read_buffer_size = 4M
# increased from 1 to 2
read_rnd_buffer_size = 2M
skip-external-locking
skip-name-resolve
slow_query_log_file = /var/log/mysql/mariadb-slow.log
slow-query-log = 1
socket = /var/run/mysqld/mysqld.sock
sort_buffer_size = 4M
table_open_cache = 400
thread_cache_size = 128
tmp_table_size = 64M
tmpdir = /tmp
transaction_isolation = READ-COMMITTED
#unix_socket=OFF
user = mysql
wait_timeout = 600

[mysqldump]
# increased from 16 to 32
max_allowed_packet = 32M
quick
quote-names

[isamchk]
key_buffer = 16M
EOF

Meine PHP konfiguration wäre dies Bitte nicht Blind übernehmen :wink: - gerade der 1. Block bezieht sich auf die Kapazitäten von CPU und RAM:

sed -i 's/pm = dynamic/pm = static/' /etc/php/8.2/fpm/pool.d/www.conf
# Total RAM in MB / 2 (on 64GB need to adjust) / 95MB (process size)
sed -i "s/pm.max_children =.*/pm.max_children = 342/" /etc/php/8.2/fpm/pool.d/www.conf
# start_servers 	Number of CPU threads x 4
sed -i "s/pm.start_servers =.*/pm.start_servers = 48/" /etc/php/8.2/fpm/pool.d/www.conf
# min_spare_servers 	Number of CPU threads x 2
sed -i "s/pm.min_spare_servers =.*/pm.min_spare_servers = 24/" /etc/php/8.2/fpm/pool.d/www.conf
# max_spare_servers 	Same as start_servers
sed -i "s/pm.max_spare_servers =.*/pm.max_spare_servers = 48/" /etc/php/8.2/fpm/pool.d/www.conf
sed -i "s/;pm.max_requests =.*/pm.max_requests = 1500/" /etc/php/8.2/fpm/pool.d/www.conf
sed -i "s/pm.max_requests =.*/pm.max_requests = 1500/" /etc/php/8.2/fpm/pool.d/www.conf

sed -i '$aapc.enable_cli=1' /etc/php/8.2/mods-available/apcu.ini
sed -i '$aapc.shm_size=512M' /etc/php/8.2/mods-available/apcu.ini
sed -i '$aapc.ttl=7200' /etc/php/8.2/mods-available/apcu.ini

sed -i "s/allow_url_fopen =.*/allow_url_fopen = 1/" /etc/php/8.2/fpm/php.ini
sed -i "s/;cgi.fix_pathinfo.*/cgi.fix_pathinfo=0/" /etc/php/8.2/fpm/php.ini
sed -i "s/;session.cookie_secure.*/session.cookie_secure = True/" /etc/php/8.2/fpm/php.ini
sed -i "s/memory_limit = 128M/memory_limit = 1024M/" /etc/php/8.2/fpm/php.ini

sed -i "s/output_buffering =.*/output_buffering = Off/" /etc/php/8.2/cli/php.ini
sed -i "s/output_buffering =.*/output_buffering = Off/" /etc/php/8.2/fpm/php.ini
sed -i "s/max_execution_time =.*/max_execution_time = 3600/" /etc/php/8.2/cli/php.ini
sed -i "s/max_execution_time =.*/max_execution_time = 3600/" /etc/php/8.2/fpm/php.ini
sed -i "s/max_input_time =.*/max_input_time = 3600/" /etc/php/8.2/cli/php.ini
sed -i "s/max_input_time =.*/max_input_time = 3600/" /etc/php/8.2/fpm/php.ini
sed -i "s/post_max_size =.*/post_max_size = 10240M/" /etc/php/8.2/cli/php.ini
sed -i "s/post_max_size =.*/post_max_size = 10240M/" /etc/php/8.2/fpm/php.ini
sed -i "s/upload_max_filesize =.*/upload_max_filesize = 10240M/" /etc/php/8.2/cli/php.ini
sed -i "s/upload_max_filesize =.*/upload_max_filesize = 10240M/" /etc/php/8.2/fpm/php.ini
sed -i "s/;date.timezone.*/date.timezone = Europe\/\Berlin/" /etc/php/8.2/cli/php.ini
sed -i "s/;date.timezone.*/date.timezone = Europe\/\Berlin/" /etc/php/8.2/fpm/php.ini

sed -i "s/;opcache.enable=.*/opcache.enable=1/" /etc/php/8.2/fpm/php.ini
sed -i "s/;opcache.enable_cli=.*/opcache.enable_cli=1/" /etc/php/8.2/fpm/php.ini
sed -i "s/;opcache.memory_consumption=.*/opcache.memory_consumption=512/" /etc/php/8.2/fpm/php.ini
sed -i "s/;opcache.interned_strings_buffer=.*/opcache.interned_strings_buffer=64/" /etc/php/8.2/fpm/php.ini
sed -i "s/;opcache.max_accelerated_files=.*/opcache.max_accelerated_files=50000/" /etc/php/8.2/fpm/php.ini
sed -i "s/;opcache.max_wasted_percentage=.*/opcache.max_wasted_percentage=15/" /etc/php/8.2/fpm/php.ini
sed -i "s/;opcache.revalidate_freq=.*/opcache.revalidate_freq=0/" /etc/php/8.2/fpm/php.ini
sed -i "s/;opcache.validate_timestamps=.*/opcache.validate_timestamps=0/" /etc/php/8.2/fpm/php.ini
sed -i "s/;opcache.save_comments=.*/opcache.save_comments=1/" /etc/php/8.2/fpm/php.ini

sed -i "s|;emergency_restart_threshold.*|emergency_restart_threshold = 10|g" /etc/php/8.2/fpm/php-fpm.conf
sed -i "s|;emergency_restart_interval.*|emergency_restart_interval = 1m|g" /etc/php/8.2/fpm/php-fpm.conf
sed -i "s|;process_control_timeout.*|process_control_timeout = 10|g" /etc/php/8.2/fpm/php-fpm.conf

# https://stitcher.io/blog/php-8-jit-setup
# https://php.watch/versions/8.0/JIT
sed -i 's|opcache.jit=off|;opcache.jit=off|g' /etc/php/8.2/mods-available/opcache.ini
sed -i '$aopcache.jit=1255' /etc/php/8.2/mods-available/opcache.ini
sed -i '$aopcache.jit_buffer_size=256M' /etc/php/8.2/mods-available/opcache.ini

# Using the Redis session handler
sed -i 's/^session.save_handler = files/;session.save_handler = files/g' /etc/php/8.2/fpm/php.ini
sed -i '/^;session.save_handler =.*/a session.save_handler = redis' /etc/php/8.2/fpm/php.ini
sed -i 's/;session.save_path =.*/session.save_path = "unix:\/\/\/var\/run\/redis\/redis-server.sock"/g' /etc/php/8.2/fpm/php.ini
sed -i '/^session.save_path =.*/a redis.session.lock_wait_time = 10000' /etc/php/8.2/fpm/php.ini
sed -i '/^session.save_path =.*/a redis.session.lock_retries = -1' /etc/php/8.2/fpm/php.ini
sed -i '/^session.save_path =.*/a redis.session.locking_enabled = 1' /etc/php/8.2/fpm/php.ini

# https://www.php.net/manual/en/mysqli.configuration.php
sed -i '$a[mysql]' /etc/php/8.2/mods-available/mysqli.ini
sed -i '$amysql.allow_local_infile=1' /etc/php/8.2/mods-available/mysqli.ini
sed -i '$amysql.allow_persistent=1' /etc/php/8.2/mods-available/mysqli.ini
sed -i '$amysql.cache_size=2000' /etc/php/8.2/mods-available/mysqli.ini
sed -i '$amysql.max_persistent=-1' /etc/php/8.2/mods-available/mysqli.ini
sed -i '$amysql.max_links=-1' /etc/php/8.2/mods-available/mysqli.ini
sed -i '$amysql.default_port=3306' /etc/php/8.2/mods-available/mysqli.ini
sed -i '$amysql.trace_mode=0' /etc/php/8.2/mods-available/mysqli.ini
sed -i '$amysql.connect_timeout=60' /etc/php/8.2/mods-available/mysqli.ini
1 Like

Hey,

danke für deinen Post, habe nun die letzten Tage immer mal was übernommen und angepasst.
Es läuft nun doch etwas runder. Habe das Memory-Limit auf 1G gesetzt anstatt 512.
Opcache.JIT habe ich ebenfalls von 128MB beim Buffer_size auf 256M gesetzt. Außerdem habe ich nach einigen Tagen noch einmal MySQL-Tuner laufen lassen und konnte da noch einmal 2 Werte anpassen, die jetzt nach einigen Tagen aufgefallen sind.
Die Ladezeit ist nun schon etwas flotter. Beim ersten Aufruf bin ich nun bei 4-5 Sekunden, das Durchnavigieren geht in sekundenschnelle. Die sporadischen Hänger bleiben leider weiterhin, dass die Seite auf einmal mehrere Sekunden lädt, bis dann was passiert.

Also irgendwas muss noch sein :frowning:
Den Großteil an Config habe ich sonst wie du schon eingestellt :slight_smile:

Dankeschön auf jeden Fall, das hat mir schon mal etwas weitergeholfen!

Ich guesse mal weiter ins blaue, was gibt bei dir folgender Befehl aus?

cat /proc/sys/fs/file-nr

Bei mir sieht das (zu diesem Moment) so auf dem produktiven System aus:

76144   0       307200

Ansonsten nutzt du ein Monitoring? Falls nein, würde ich auf die schnelle: Netdata als echtzeit Monitoring empfehlen, weil Open Source und ich einen Bias habe :slight_smile:. Irgendwo muss der Schuh ja drücken…

1 Like

Hey,

wenn ich den Befehl eingebe, erhalte ich aktuell folgende Werte:

root@nextcloud:~# cat /proc/sys/fs/file-nr
5568    0       9223372036854775807

was bedeutet hier die letzte riesige Zahl?

Leider ist Performance immer noch unterirdisch nach wenigen Klicks :frowning:
Mittlerweile habe ich 27.1.2 drauf. Sporadische Hänger bleiben aber nach wie vor, dass die Seite bis zu 10 Sekunden lädt bis es weiter geht.

Hier mal meine MariaDB Config:

[server]
innodb_buffer_pool_size = 8G
innodb_log_file_size = 2G
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 32M
innodb_max_dirty_pages_pct = 90
query_cache_type = 1
query_cache_limit = 2M
query_cache_min_res_unit = 2k
query_cache_size = 256M
tmp_table_size= 2G
max_heap_table_size= 256M
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
read_rnd_buffer_size = 4M
sort_buffer_size = 4M
table_definition_cache = 1024
join_buffer_size = 4M

[mysqld]
user                    = mysql
pid-file                = /run/mysqld/mysqld.pid
socket                  = /run/mysqld/mysqld.sock
#port                   = 3306
basedir                 = /usr
datadir                 = /var/lib/mysql
tmpdir                  = /tmp
lc-messages-dir         = /usr/share/mysql
sql_mode		= ""
performance_schema	= on
skip-name-resolve
#skip-external-locking

key_buffer_size         = 16M
#max_allowed_packet     = 16M
#thread_stack           = 192K
#thread_cache_size      = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
#myisam_recover_options = BACKUP
#max_connections        = 100
#table_cache            = 64
#thread_concurrency     = 10
character_set_server    = utf8mb4
collation_server        = utf8mb4_general_ci
transaction_isolation   = READ-COMMITTED
binlog_format           = ROW
innodb_file_per_table   = 1

#
# * Query Cache Configuration
#
#query_cache_limit       = 1M
#query_cache_size        = 16M
#innodb_buffer_pool_size = 1G
#innodb_io_capacity      = 4000

#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file       = /var/log/mysql/mysql.log
#general_log            = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Enable the slow query log to see queries with especially long duration
#slow_query_log_file    = /var/log/mysql/mariadb-slow.log
#long_query_time        = 10
#log_slow_rate_limit    = 1000
#log_slow_verbosity     = query_plan
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id              = 1
#log_bin                = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
#max_binlog_size        = 100M
#binlog_do_db           = include_database_name
#binlog_ignore_db       = exclude_database_name

character-set-server  = utf8mb4
collation-server      = utf8mb4_general_ci

Hat noch jemand Tipps, wo ich gucken könnte?
Ich weiß nicht was ich ausprobieren könnte.

Würde sonst als letztes einen neuen Server installieren und alles umziehen, klappt das nicht, werde ich NC wohl rauswerfen müssen, da so kein Arbeiten möglich ist was ich eher nicht will, da ich NC sehr mag… :frowning:

gib nicht auf!

du könntest versuchen, statt mariadb mal auf postgesql zu wechseln. Und probier mal testweise, bruteforce zu deaktivieren bzw. generell so viel zu deaktivieren, wie möglich.
Aber tatsächlich primär geh mal rüber auf postgresql.

Andere Frage: wie viele Dateien fliegen da rum, wie groß ist die Datenbank? Und zeig mal die nginx.conf der Nextcloud.

Hey,

danke für deine Antwort!

Ich möchte auch wirklich ungern von NextCloud weg, nur die User suchen sich leider aktuell andere Wege über OneDrive, Google und Dropbox, was eigentlich nicht OK ist. Als Antwort bekommt man dann immer, wenn ich sie darauf anspreche, dass das nicht gestattet ist, dass die anderen Clouds viel schneller sind als die eigene Cloud. Das kann ich ja auch nachvollziehen aber datenschutztechnisch ist das bei unserem Berufsfeld ein NoGo. :smiley:

Ist Postgres denn spürbar schneller?
Habe damit bisher noch nie gearbeitet und denke, dass die kleine Installation die wir haben mit MariaDB eigentlich klar kommen sollte. Ich habe weitaus größere Datenbanken mit MariaDB im Einsatz die sehr sehr flott reagieren (300ms ist das kein Problem). Wenn es an Serverressourcen hängen würde, könnte ich problemlos Kapazitäten hinzu schalten, wir haben einige ESXi Server zur Verfügung aber leider ändert selbst das verdoppeln an RAM und CPU nichts. :frowning:

Bruteforce habe ich mal deaktiviert aber die Datenbank-Tabelle oc_bruteforce_attempts ist aktuell komplett leer. Da wir auch GeoBlocking aktiv haben, haben die Login-Versuche massiv abgenommen :smiley:

Folgende Daten habe ich im Webinterface von NC stehen:
Datenbankgröße: 693,5 MB
Dateien: 803734
Speicher: 417
Freier Speicherplatz: 40,8 GB

Also irgendwo muss ja ein Flaschenhals sein.

Da ich Apache einsetze, hier analog dazu die sites-enabled config:

<VirtualHost *:443>
	ServerAdmin support@meine-domain.de
	ServerName cloud.meine-domain.de
	DocumentRoot /var/www/html

	Protocols h2 http/1.1
	Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"

	SSLEngine on
	SSLCertificateFile	/etc/ssl/certs/wildcard.crt
	SSLCertificateKeyFile /etc/ssl/private/wildcard.key

	ErrorLog ${APACHE_LOG_DIR}/error_cloud.log
	CustomLog ${APACHE_LOG_DIR}/access_cloud.log combined

	<Directory /var/www/html/>
		Require all granted
		AllowOverride All
		Options FollowSymLinks MultiViews

		<IfModule mod_dav.c>
			Dav off
		</IfModule>
	</Directory>

	ProxyPass /push/ws ws://127.0.0.1:7867/ws
	ProxyPass /push/ http://127.0.0.1:7867/
	ProxyPassReverse /push/ http://127.0.0.1:7867/
</VirtualHost>

Danke für die Unterstützung, ich weiß das echt zu schätzen und möchte gerne herausfinden woran das liegt und beheben. Dafür muss es ja einen Grund geben :smiley:

Schwer zu sagen wo es genau hängt. Vielleicht zickt auch esxi rein.
Ich mag eher ein Setup mit Postgres und nginx. Und solange ich nicht als Startseite das Dashboard einstelle, läuft das eigentlich gut.
Wechsel von Mariadb zu Postgres ist auch kein Hexenwerk - schau mal hier: Nextcloud Datenbankmigration von MariaDB zu PostgreSQL - Carsten Rieger IT-Services

Hey,

sag mal, läuft NextCloud eigentlich mit MariaDB 10.11?
In der Doku steht immer nur 10.6 (recommended) aber die aktuelle Version 10.11 (LTS) ist performancetechnisch wohl etwas besser. Vielleicht wäre das der einfachere Weg aktuell.
Oder weißt du, warum nur 10.6 aktuell supported wird?
Weil wenn ich mir die Änderungen ansehe, betrifft da nicht wirklich etwas von Nextcloud :slight_smile:

Introducing Amazon RDS for MariaDB 10.11 for up to 40% higher transaction throughput | AWS Database Blog

ich meine 10.11 wird auch unterstützt, aber nicht mit allen features. Nagel mich nicht darauf fest.
Aber wie gesagt, bin zu postgres gewechselt und damit null probleme oder sonstige Performance-Probleme.

1 Like

Habe mal auf 10.11 aktualisiert. Mal ein paar Tage im Auge behalten :smiling_face:
Danke!

bei der anzahl an dateien die du da hast, macht porstgres allemal sinn.

Und wie gesagt, ist eigentlich easy in der umsetzung.

1 Like

Lieber Dennis,

ich vermute, das Problem liegt daran, dass im Internet wahlloses Hochsetzen aller Buffer als Optimierung verkauft wird, während die Default-Werte von den Leuten gesetzt wurden, die die Software entwickelt haben.
Deine join_buffer_size, sort_buffer_size und Deine query_cache_size sind zu groß.
Beim Query Cache profitiert man nur von ein paar zehner Megabytes, nicht von hunderten, das bremst. Setz den auf 64 MB, dann bist Du das eine Problem los.
Einen großen Join Buffer brauchst Du auch nicht, da die Speicheralloziierung ein Performance-Killer ist - Du siehst ja, wenn Du den Join Buffer halbierst, macht das einen gigabyteweisen Unterschied beim RAM-Verbrauch.
Der Join Buffer nützt nur beim Scan der Tabellen, der Join ohne Index selbst wird nicht schneller, denn den muss man mit Indizes machen, um ihn zu beschleunigen.
Außerdem ist es beim Join Buffer so, dass der globale Wert vom Client oder von der Anfrage überschrieben und angepasst werden kann - der Programmierer weiß ja in dem Fall am besten, was seine Funktion tut.
Man hält die Voreinstellung des Join Buffers also am besten so klein wie möglich.
Beim Sort Buffer ist es tatsächlich so einfach, dass unter Linux alles oberhalb von 2M zu massiven Performanceverlusten führt.
Wenn Du query_cache_size auf 64M setzt und join_buffer_size auf 2M und sort_buffer_size auf 1M, sollte das Problem erstmal gegessen sein.

Ich mache das beruflich und ich verstehe wirklich nicht, warum im Internet aufgeblasen wirkende Seiten Dinge empfehlen, von denen man besser die Finger lässt, weil es eben nicht so ist, dass viel viel hilft.
Übermäßiges Chiptuning beim Auto ohne weitere Anpassungen ruiniert den Motor, Reduktion der Stickoxide steht im Widerspruch zur Reduktion des Verbrauchs und ein White Russian ist super, 150 White Russians wahrscheinlich tödlich.

Viele Grüße

christian

2 Likes