Neue Synology NC Instanz - Uploadperformance kleiner Dateien unfassbar schlecht

Hallo zusammen!

Ich möchte mich hier mit einem Beitrag melden und um eure Hilfe bitten.
Vor zwei Tagen habe ich auf meiner Synology Diskstation DS218 (Aktuellstes DSM 6.2, alle Pakete aktuell) eine NextCloud 21.0.1 Instanz aufgesetzt. Die Installation hat soweit gut funktioniert.
Leider habe ich eine absolut unterirdische Uploadperformance aus den Desktop Clients (Windows 10 UND Mac Big Sur) bei kleinen Dateien heraus.

Konkret stellt es sich wie folgt dar:

  • Mac Client
  • 12,6 GB mit 18.500 Dateien
    Der Sync läuft seit zwei Tagen und es sind noch 3900 Dateien mit ca. 5,3 GB hochzuladen!!!

Identisch verhält es sich auf meiner physischen Windows 10 Maschine. Hier habe ich unter einem anderen Account zum Test die identischen Daten hochgeladen, die Performance war leider gleich schlecht, weshalb ich den Upload abgebrochen habe.
Zum Test habe ich dann eine große ISO Datei mit 2,7 GB synchronisieren lassen. Die Transferrate schoss hoch und der Upload war nach wenigen Minuten erledigt.
Dies bringt mich zu dem Schluss, dass es nicht an der Netzwerkperformance oder aber der grundsätzlichen Performance der DS liegt.

Mir ist bewusst, dass viele kleine Dateien ordentlich Overhead produzieren und Uploads länger dauern als bei einer großen zusammenhängenden Datei.
Aber ich bin mir sicher das ihr mir zustimmt, dass 18.000 Dateien mit in Summe 15 GB nicht drei Tage laufen sollten. :slight_smile:

Ich nutze folgende Config:

Apache 2.4
PHP 7.4
MariaDB 10
Datenverzeichnis und Webverzeichnis der NC sind getrennte Ordner.

PHP Config Limits sind erhöht, Memory ist mit 1GB (von 2GB verfügbar) zugewiesen.
Ich habe ergänzend REDIS installiert und in der config.php eingetragen, was allerdings keinen Effekt hatte. Weder positiv noch negativ.
Ergänzend habe ich die maximal gleichzeitigen Dateiuploads von 20 auf 200 gesetzt, was auch keinen Effekt hatte.

Mir gehen mittlerweile wirklich die Ideen aus. Kann es sein, dass es in der Config der Desktop Clients noch Optionen braucht, die in der Standardinstallation nicht vorgesehen sind?

Ich bin aber auch davon überzeugt, dass sowohl die DS218 als auch diee Nextcloud grundsätzlich mehr Performance erlauben als das, was gerade hier passiert.

Ein “gefühlter” Hinweis noch: Ich nehme von meiner DS wahr, dass die Platten richtig gut zu tun haben. Die Auslastung des Ressourcenmonitor ist aber total niedrig. Weder CPU, RAM noch Platte sind nennenswert ausgelastet. Würde ich nur diese Daten sehen, würde ich sagen die DS langweilt sich.

Viele Grüße
Ernie

Ja, das geht definitiv schneller. Der Client braucht normalerweise keinerlei Tuning.
Hast Du nativ installiert oder Docker oder VM? Ganz konnte ich das nicht rauslesen.

Hallo!

Ist nativ installiert. afaik läuft Docker nicht auf der 218. Habe die “normale”, nicht die + Variante.

Erreichts du deine Nextcloud über eine öffentlich erreichbare Domain? Wenn ja, wäre es möglich die hosts datei auf dem testclient zu bearbeiten und anstatt der öffentlichen IP die interne IP adresse deiner Diskstation einzutragen?

Hi!
Ja, das tue ich. Habe auch auf dem Desktop PC (Windows) das Hosts File bearbeitet und es damit nochmals getestet. Macht keinen Unterschied. Die Datenübertragung der Daten würde noch immer ewig dauern. Stellenweise 1KB/s, meist so rund um 14-17 KB/s.

Hm… Dann habe ich leider keine Idee was das Problem sein könnte.

Trotzdem danke!

1 Like

das könnte mit der DB zusammenhängen. Schaue im NC es Fehler gibt… bei mir hat max_connections = 250 gegen Verbindungsfehler geholfen.

speziell

innodb_flush_log_at_trx_commit = 2
innodb_flush_log_at_timeout = 5

sind meiner Erfahrung nach interessant, vor Allem wenn die DB auf einer magnetischen Disks liegt (Logs und DB file werden seltener geschrieben - bei Ausfall könnten Daten einer Sekunde verloren gehen…)

meine MariaDB config:

my.cnf

    [server]
    skip-name-resolve
    innodb_buffer_pool_size = 256M
    innodb_buffer_pool_instances = 1
    innodb_flush_log_at_trx_commit = 2
    innodb_flush_log_at_timeout = 5
    innodb_log_buffer_size = 32M
    innodb_max_dirty_pages_pct = 75
    query_cache_type = 1
    query_cache_limit = 2M
    query_cache_min_res_unit = 2k
    query_cache_size = 16M #was 64M, tuning primer said mybe less
    tmp_table_size= 64M
    max_heap_table_size= 64M
    slow-query-log = 1
    slow-query-log-file = /var/log/mysql/slow.log
    long_query_time = 1
    max_connections = 250
    join_buffer_size = 1M
    key_buffer = 64M
    [client]
    default-character-set = utf8mb4
    [mysqld]
    character-set-server = utf8mb4
    collation-server = utf8mb4_general_ci
    transaction_isolation = READ-COMMITTED
    binlog_format = ROW
    innodb_large_prefix=on
    innodb_file_format=barracuda
    innodb_file_per_table=1
    default_authentication_plugin=mysql_native_password
    max_binlog_size = 134217728
    expire_logs_days = 3

Hi!
Vielen Dank für deine Antwort und die guten Infos!
Tatsächlich werden im NAS klassiche HDD verwendet. Ich habe bei mir die Fehler angeschaut. Hin und wieder, habe ich am Mac Client die Meldung erhalten das ein File gelockt ist. Ich meine die Meldung war ein 413 Fehler?! Bin mir da nicht mehr sicher.

Was deine Einstellungen betrifft, bin ich nicht sicher, wie ich die ändern kann, ohne mir die aktuelle Konfiguration zu zerlegen.
Wenn ich meine my.cf öffne, ist dort explizit erwähnt, dass ich eine weitere Datei im Pfad /var/… erstellen soll. Wie ich dann auf die Datei verweisen kann, ist mir allerdings nicht ganz klar.
Bist Du sicher, dass diese Anpassungen wirklich nötig sind, damit kleinere Datenmengen mit deutlichem Performancegwinn synchronisiert werden können?

MariaDB durchsucht mehrere Ordner um individuelle config files zu finden - wenn dein System bestimmte Vorgaben (Hinweise) macht würde ich diese befolgen und das Ergebnis anschauen. Mein System ist Docker auf (Qnap) x86 - es ist sicher etwas anders als dein NAS.

Meine Kristallkugel sagt gerade nichts darüber ob dein Problem aufgrund deiner Konfiguration entsteht…

dieser Tipp ist wie jeder andere in einem freien Internet Forum

  • entweder es hilft
  • oder es ist nutzlos und harmlos (Schlangenöl)
  • oder ist bösartig und schadet deinem System und deinen Daten

finde raus was stimmt indem du folgende einfache Schritte befolgst:

  • 1 - informiere dich bei einer seriösen Quelle zB Admin Manual des Herstellers was die Settings/Befehle machen
    • bewerte ob
      • deine Daten sicher sind
      • es Sinn macht die Einstellungen anzupassen (für dein System/Config)
  • 2a - prüfe ob/wie de Einstellungen auf dein System wirken
    • ist die neue Einstellung erfolgsversprechend?
    • ist es ein Problem für mich oder ein Problem bei 10k+ Usern?
    • Anforderungen beachten (zB Reboot einer/aller Komponenten)
  • 2b - wenn das Ergebnis unverändert ist besser auf default zurückstellen >> man erpart sich spätere Probleme und Troubleshooting… weil die System grundsätzlich für übliche use cases bereits optimiert sind
  • 3 - teste das Ergebnis sorgfältig und ausführlich
    • Funktion+Performance (z.B. gleiche Daten vor/nach der Änderung in unterschiedliche Nextcloud Ordner hochladen und Zeit+Durchsatz messen)

wenn es hilft

  • war es die Lösung
  • wenn nicht war es nur dummes Geschwätz aus dem Internet(s) - gehe zum nächsten Google Treffer…

lass dich durch die letze Variante nciht entmutigen - “Umwege erweitern die Ortskenntnisse” - je mehr man über das verwendete System weiss, desto schneller geht die Problemlösung beim nächsten mal…

3 Likes

Nach einer Server Neuinstallation meiner Synology DS718+ hatte ich das selbe Problem und habe wochenlang nach der Ursache gesucht. Mit den in diesem Beitrag beschriebenen Einstellungen fuer die Datenbank konnte ich das Problem loesen.

https://help.nextcloud.com/t/files-operation-upload-copy-move-delete-extremly-slow-also-notes-app/168470

Vielen Dank, super.

1 Like