Unter V5.1.6 arbeitete “Cache aufwärmen” einwandfrei. Vor dem Update sind in Shopware alle Cache Bereiche gelöscht worden.
Nach dem Update auf 5.2.2. wurde der HTTP-Cache wieder aufgewärmt. Beim Stand von 44 von 460 Artikel-URLs blieb der Job jedoch hängen.
Möglicher Konflikt: Der “Zend OPcache” hat eine Größe von 121 MB jedoch aktuell 0 B freien Speicher.
Weiß jemand, mit welchem Cronjob der OPcache gelöscht werden kann? - Ist das ein Bug in 5.2.2.?
Grüsse von Pinnochio
Hallo
der Zend OPCache kann auch erweitert werden.
In der opcache``.so einfach den Wert auf 256 erhöhen, z.B.
opcache.memory_consumption=256
Gruß
Diese Parameteränderung müsste in der php.ini vorgenommen werden, zu der mir der Zugriff fehlt. Daher habe ich versucht, den OPcache mit dem Kommando opcache_reset(); zu löschen. Dennoch werden unter “Performance Statistik” bei Zend OPcache weiterhin 2549 Dateien angezeigt:
Weiß jemand, wie man den kompletten OPcache per FTP oder phpmyadmin löschen kann?
OPcache speichert vorkompilierten Bytecodes im Arbeitsspeicher. Das ist per FTP oder Datenbank nicht einseh- oder löschbar.
opcache_reset() löscht den OPcache. Beim Laden des Backends werden aber sofort wieder alle PHP-Dateien, die dabei involviert sind, neu gecached. 2.549 scheint mir aber zu viel.
Diese Parameteränderung müsste in der php.ini vorgenommen werden, zu der mir der Zugriff fehlt.
Ich würde mal bei Deinem Hoster nachfragen, damit er Dir das Limit erhöht.
Timme Hosting - schnelles nginx-Hosting
Je nach Installationsart (PHP-FPM oder z.B. Apache) wird der Cache gelöscht wenn die Dienste (über Konsole) neu gestartet werden.
Z.B.:
service php5-fpm restart
oder
service apache2 restart
Bei Plesksysteme
service plesk-php70-fpm restart (php 7)
service plesk-php56-fpm restart (php 5.6.xx)
Gruß
Unser Provider dmsolutions hat für die Justierung des OPcache’s testweise eine Neuinstallation der v5.2.2 durchgeführt. In der Standardeinstellung und in der Verarbeitung sind aber keine Fehler festgestellt worden. Scheinbar hängt der Laufzeitfehler in unserer Installation mit dem Update zusammen. Vielleicht hätte ich vor dem Update das Verzeichnis /var/cache komplett löschen sollen. Hilfsweise habe ich jetzt das Verzeichnis „cache“ in „cache-alt“ umbenannt. Draufhin hat Shopware korrekt ein frisches cache Verzeichnis angelegt.
Mir ist aufgefallen, dass die Anzahl der Dateien im OPcache mit 2363 nach wie vor hoch, im Vergleich mit vorgestern aber leicht gefallen ist. Offenbar arbeitet der OPcache zur Laufzeit normal. Vielleicht kommt die große Anzahl Dateien daher, dass der Shop als Subverzeichnis in /html installiert worden war. Unter /html/shop/files sind auch einige Backups zum Shops abgelegt. Dazu unten ein Screenshot aus Filezilla.
Weiß jemand, welche Verzeichnisse/Dateien im OPcache vorgehalten werden, bzw. welche Aktion verändert den OPcache zur Laufzeit maßgeblich?
Im unserem Shop sind 1835 Artikel inkl. aller Artikelvarianten vorhanden (arbeitsschutz.chemfidence-services.com).
Danke für eure Mithilfe & Gruß von Pinnochio
Mittlerweile konnte ich den Fehler auf die Schliche kommen: Der Zend OPcache war es nicht.
In der Logdatei unter /var/log waren Fehlermeldungen dieser Art eingetragen:
[2016-07-21 15:46:42] core.ERROR: Warm up http-cache error with shopId 1 Client error response
[url] http://xxx.com/xxx/xxx/129/scott-cap [status code] 404 [reason phrase] Not Found {„uid“:„8cbbef9“}
[2016-07-21 18:37:30] core.ERROR: Warm up http-cache error with shopId 1 Client error response
[url] http://xxx/xxx/xxx/haendehygiene [status code] 404 [reason phrase] Not Found {„uid“:„30871d0“}
Artikel, die auf diesen Fehler gelaufen sind, waren vor dem Update gelöscht oder „deaktiv“ gesetzt gewesen. - Auch eine früher gelöschte Kategorie rief im Step „Statische URLs“ einen Fehler hervor und bewirkte, dass der Cache-Aufwärmer stehen blieb.
Bis zur V5.1.6 hatte der Cache-Aufwärmer damit keine Probleme, erst ab V5.2.2 blieb er bei mir hängen. Nachdem ich alle deaktiven Artikel wieder aktiv gesetzt habe, ist der Step „Artikel URLs“ wieder durchgelaufen. Aktuell hängt er sich noch an den vermissten statischen URLs auf, der früher gelöschten Seiten auf. Diese müssen wohl in der DB gelöscht werden. Wie, muß ich noch in Erfahrung bringen.
Meine Bitte an die Entwickler ist, den Cache Aufwärmer fehler-redundanter zu programmieren.
Gruß, Pinnochio
Timmehosting hat da schon den richtigen Tipp gegeben
Der zu klein dimensionierte OPCache kann zu den ungewöhnlichsten Folgefehlern führen, sodass Du meinst es läge nicht am OpCache…
Zusätzlich würde ich ihn mal ganz abschalten um zu testen.
Welche PHP-Version wird denn eingesetzt ? Laufen auf dem selben Verzeichnis noch weiter Shops/Installationen ?
PHP Version: php 5.6.15-phpboil.01. Auf unserem Webserver-Verzeichnis läuft noch Contao CMS.
Den OPCache höher zu setzen ist ohne weiteres nicht möglich, da wir einen Shared Hosting Server angemietet haben, wo sich mehrere Kunden die Ressourcen teilen. Die Logs und Cache’s habe ich auch schon x-mal gelöscht und den Bearbeitungsmodus eingestellt. Stets bleibt der Cache Warmer bei den genannten Problemstellen hängen. Bis zur V5.1.6 hatte der blendend funktioniert. Scheinbar hat sich ein Bug eingeschlichen.
Mein abschließender Beitrag zu diesem Thema:
Nach dem Downgrade auf unsere frühere V5.1.6 läuft der Cache Warmer wieder einwandfrei durch und verschickt zu den verwaissten URLs auch wieder Status E-Mails. Eine Erhöung des OPcache.memory brauchte es dafür nicht, für eine bessere Performance aber sicherlich nützlich.
Dank an allen, die sich für die Lösung meines Problems beteiligt haben.
Pinnochio
