Ich hatte die Fehlermeldung auch nach dem Update auf Nextcloud 27.0.1.
Ich habe es nach einigem Ausprobieren glaube ich so gelöst:
sudo apt-get install php-apcu
sudo apt-get install redis-server php-redis
usermod -a -G redis www-data
Dann noch folgende Einträge in die config.php:
‘memcache.local’ => ‘\OC\Memcache\APCu’,
‘memcache.locking’ => ‘\OC\Memcache\Redis’,
‘redis’ => [
‘host’ => ‘localhost’,
‘port’ => 6379,
],
Die Fehlermeldung ist weg. Sonst ist alles wie immer.
Ich habe das so ähnlich wie bisam2000, aber mit ein paar Unterschieden:
Wie in den NextCloud Docs empfohlen, habe ich Redis als UNIX-Socket konfiguriert (damit Redis nicht immer auf den Port lauschen muss).
Das steht alles in der Anleitung, die hier hier verlinkt ist:
NextCloud Memcache mit Redis • Schächner (xn–schchner-2za.de)
Darin kann man auch nachlesen, wie man Redis grundlegen konfiguriert (wenn man das noch nicht gemacht hat).
Am Ende habe ich dann diese Konfiguration ergänzt:
'memcache.local' => '\\OC\\Memcache\\APCu',
'filelocking.enabled' => 'true',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' => array (
'host' => '/var/run/redis/redis-server.sock',
'port' => 0,
),
Selbes Problem hier nach dem Update von 26.0.5 auf Version 27.0.2.
Ich habe alle oben beschriebenen Lösungsvorschläge einzeln durchprobiert. Die Meldung “Die Datenbank wird zum Sperren von Transaktionsdateien verwendet. Um die Leistung zu verbessern, richte bitte, sofern verfügbar, Memcache ein.” kommt weiterhin.
Das nervt schon etwas. 
Sorry aber warum eröffnest du dann nicht einen neuen Thread, und füllst das Support Template aus, damit wir die Details zu deinem System kennen und wissen was du genau gemacht hast? Uns hier mitzuteilen, dass du genervt bist, mag dir vielleicht helfen etwas Frust abzubauen, dein eigentliches Problem wird es aber nicht lösen… 
Sorry, aber ich bin sicher, wenn ich einen neuen Thread eröffne, zu diesem bereits bekannten Problem, noch dazu völlig identisch, dann bekomme ich dafür wieder einen Rüffel.
Dann baruchen wir die Details halt hier, ansonsten wird es schwierig.
Kurze Zusammenfassung was du alles tun musst:
/etc/redis/redis.confconfig.php im Nextcloud Ordner.Hier ein Beispiel, wie ich es auf meiner Instanz installiert und konfiguriert habe: Installing Redis for Memcache - #6 by bb77
Danach folgendes zur config.php der Nextcloud hinzufügen:
Wichtig: Der Pfad für den
redis-server.sockmuss mit dem in der Datei/etc/redis/redis.confübereinstimmen!:
'filelocking.enabled' => true,
'memcache.locking' => '\OC\Memcache\Redis',
'redis' =>
array (
'host' => '/var/run/redis/redis-server.sock',
'port' => 0,
'password' => '<secret>',
'timeout' => 0.0,
'dbindex' => 1,
),
Hier noch der Link zu den offiziellen Docs: Transactional file locking — Nextcloud latest Administration Manual latest documentation
Meine Nextcloud V. 27.0.2 läuft auf einem Raspberry Pi 4 mit 8 GB RAM unter Debian GNU/Linux 11 (bullseye) mit Apache/2.4.56 und PHP 8.1.21
Ich bin exakt nach deiner Anleitung vorgegangen (copy & paste, gleiches Pwd in der redis.conf wie in der config.php). Geändert hat sich leider dadurch nichts. Die Meldung kommt nach wie vor.
Was mich noch ein wenig irritiert sind die verschiedenen Schreibweisen in den diversen Postings.
Bei ‘\OC\Memcache\Redis’ findet man auch ‘\OC\Memcache\Redis’.
Und bei ‘filelocking.enabled’ => true steht auch manchmal ‘true’ (mit einfachen Anführungszeichen).
Mal abgesehen von all diesen Versuchen die Fehlermeldung mit Redis wegzubringen, bin ich ganz beim Eröffner des Threads. Die Nextcloud Doku sagt für kleine Server reicht APCu. Ist das mit der V.27 nun nicht mehr der Fall? Ich habe nur 8 Benutzer hier von denen selten zwei gleichzeitig eingeloggt sind. In meiner Config ist ‘memcache.local’ => ‘\OC\Memcache\APCu’ eingetragen und das hat bisher tadellos funktioniert.
Vielleicht postest du ja mal deine redis.conf und deine config.php hier, ansonsten kann man nur raten an was es liegt. (sensitve Daten bitte anomysieren)
Memcache ist nicht das gleiche wie Transactional File Locking. Das sind zwei verschiedene Funktionen, die beide unabhängig voneinender konfiguriert werden können.
Und nein, man braucht Redis nicht zwingend, damit Transactional File Locking funktioniert. Mit Redis wird halt die Last auf die Datenbank reduziert, und somit die Performance der Nextcloud erhöht, was vorallem bei vielen gleichzeitigen Dateizugriffen zum Tragen kommt. Wenn für dich aber auch so alles “gut genug” läuft, kannst du Redis auch weglassen.
Ich denke ich werde es weglassen solange nicht mehr Nutzer darauf zugreifen.
Danke für die Antworten.
Ihr könnt froh sein, das Ihr überhaupt noch zugriff auf Eure Nextcloud habt.
Bei mit war nur noch der Zugang via ssh möglich und hatte mit dem selben Problem zu kämpfen.
Um alle Warnmeldungen bezüglich “cache” habe ich das gleiche wie “bisam2000” geändert und folgendes in meine config.php stehen
<?php
$CONFIG = array (
'memcache.local' => '\\OC\\Memcache\\APCu',
'filelocking.enabled' => 'true',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' =>
array (
'host' => '127.0.0.1',
'port' => 6379,
'timeout' => 0.0,
),
seitdem läuft die Nextcloud wieder und ohne Warnmeldungen.
Deine Konfiguration ist eine der möglichen Konfigugration, und ob sie funktioniert, hängt davon ab, wie der darunterliegende Redis Server konfiguriert ist.
Btw. Mit Glück hat das nur dann etwas zu tun, wenn man nicht weiss, was die Einträge in dem Konfigurationsschnippsel bedeuten, das man sich aus dem erst besten Forenpost in seine config.php kopiert hat.
Plus kann es natürlich noch Syntax Fehler geben, was auch zu einem “Internal Server Error” führen kann, wenn z.B. irgendwo ein ), fehlt nach einem Array oder man eine config Option aus Versehen innerhalb eines bestehenden Arrays platziert hat. Btw. Die gesammte config.php ist auch ein Array, fügt man also etwas ganz am Schluss der Datei ein, fügt man es ausserhalb des CONFIG Arrays ein, was auch Probleme gibt.
Gleiches problem, bei mir hat geholfen das in die config.php einzutragen:
'memcache.locking' => '\OC\Memcache\APCu',
Ich verwende APCu und nicht redis.
Das ist keine Entweder-oder-Frage. APCu wird für den Memory Cache empfohlen und ausschliesslich für diesen. Für Transactional File Locking wird hingegen Redis vorausgesetzt: Transactional file locking — Nextcloud latest Administration Manual latest documentation
Siehe auch die Empfehlungen hier: Memory caching — Nextcloud latest Administration Manual latest documentation
Im Idealfall nutzt du also beides: APCu für dem Memory Cache und Redis für File Locking.
Doch ist es, man kann ja auch APCu für beides verwenden. Ich habe so einige NC Instanzen und alle laufen prima so.
Sie würden auch laufen wenn man weder noch einrichtet oder nur APCu für den Memory Cache und dann die Datenbank Transactional File Locking machen lässt (was übrigens bei kleinen Instanzen trotz der Warnung nicht zwingend ein Problem sein muss) Die Frage ist halt wie gut, repektive wie performant es dann läuft, und ob APCu als “File Locking Cache” im schlimmsten Fall nicht sogar Probleme verursachen könnte…
Und solange du mir zu diesen Fragen keine technisch fundierten Antworten liefern kannst (ich kann es nicht), halte ich mich lieber an die Empfehlungen aus der offiziellen Dokumentation, als an eine “Lösung” aus dem Forum, bei der ich den Eindruck kriege, es ging weniger darum die beste Lösung zu finden, sondern darum eine Warnung wegzukriegen ohne sich die Hände mit Redis schmutzig machen zu müssen.
Du tönst wie einer von denen die damals sagten die Erde sei eine Scheibe. 
Mir egal, mach was du willst. 
Ja klar mach ich was ich will, und in diesem Fall will ich mich halt an die Empfehlungen in der Doku halten.
Btw. bei mir läuft APCu als Memory Cache und Redis für File Locking schon lange bevor diese Warnung eingeführt wurde. Kenne die nur aus dem Forum hier.
Bei mir auch.
‘memcache.locking’ => ‘\OC\Memcache\APCu’,
und alles ist sauber.
| FreeBSD 13.1-RELEASE-p9 amd64 | PHP 8.0.30 | MySQL 8.0.33 |
Bis heute NC 25 und keine Warnugen, Hinweise, etc und heute mit
2 × updater/updater.phar
rauf auf NC 27.1.4 und nun bekomme ich auch die Meldung.
- Die Datenbank wird zum Sperren von Transaktionsdateien verwendet. Um die Leistung zu verbessern, richte bitte, sofern verfügbar, Memcache ein. Weitere Informationen findest du in der Dokumentation
.
Server
redis_version:7.2.3
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:879d28d41b60ee24
redis_mode:standalone
os:FreeBSD 13.1-RELEASE-p9amd64
arch_bits:64
monotonic_clock:POSIX
clock_gettime
multiplexing_api:kqueue
atomicvar_api:c11-builtin
gcc_version:4.2.1
process_id:12866
process_supervised:no
run_id:b89ac84d282475bcf07732e7706b0137e789ac5e
tcp_port:0
server_time_usec:1701376713458201
uptime_in_seconds:7836
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:6877897
executable:/usr/local/bin/redis-server
config_file:/usr/local/etc/redis.conf
io_threads_active:0
listener1:name=unix,bind=/tmp/redis.sock
used_memory:2350768 used_memory_human:2.24M used_memory_rss:11288576 used_memory_rss_human:10.77M used_memory_peak:3012952 used_memory_peak_human:2.87M used_memory_peak_perc:78.02% used_memory_overhead:1409376 used_memory_startup:1406984 used_memory_dataset:941392 used_memory_dataset_perc:99.75% allocator_allocated:2328464 allocator_active:11256832 allocator_resident:11256832
und Redis mit langen und kurzen Test laufen lassen… ☼☼
====== XADD ======
2 requests completed in 0.00 seconds
18 parallel clients
3 bytes payload
keep alive: 1
host configuration “save”: 3600 1 300 100 60 10000
host configuration “appendonly”: no
multi-thread: noLatency by percentile distribution:
0.000% <= 0.063 milliseconds (cumulative count 1)
75.000% <= 0.079 milliseconds (cumulative count 2)
100.000% <= 0.079 milliseconds (cumulative count 2)Cumulative distribution of latencies:
100.000% <= 0.103 milliseconds (cumulative count 2)Summary:
throughput summary: inf requests per second
latency summary (msec):
avg min p50 p95 p99 max
0.068 0.056 0.063 0.079 0.079 0.079
Das ist auch nur ein kleiner Server mit wenigen User… und ich sehe es auch als overkill und würde mir wünschen, die Doku erkärte auch, wie NC zu dieser Feststellung kommt — denn das wäre gut zu wissen!?
NC 26 hab ich beim updaten auch ~30min gestestet und dort gab es die Meldung auch nicht.
Ist also jemand etwas schlauer geworden, bis heute?
Gruß
PS: Erster Post hier, aber viele Versionen NC & OC durchlaufen 
Gebe auf für heute — egal ob socket oder über localhost — NC nutzt Redis nicht.
root@nextcloud:~ # tail -f /var/log/redis/redis.log
81622:M 01 Dec 2023 00:36:31.646 - DB 0: 5 keys (0 volatile) in 8 slots HT.
81622:M 01 Dec 2023 00:36:31.647 . 0 clients connected (0 replicas), 1827464 bytes in use
81622:M 01 Dec 2023 00:36:36.739 - DB 0: 5 keys (0 volatile) in 8 slots HT.
81622:M 01 Dec 2023 00:36:36.739 . 0 clients connected (0 replicas), 1827464 bytes in use
81622:M 01 Dec 2023 00:36:41.833 - DB 0: 5 keys (0 volatile) in 8 slots HT.
81622:M 01 Dec 2023 00:36:41.833 . 0 clients connected (0 replicas), 1827464 bytes in use