Hallo,
mit dem Befehl
php bin/console dal:refresh:index
versuche ich auf dem Produktions Server die Indizies neu aufzubauen. Doch er bricht nach 40 Minuten ab, ohne weitere Errormeldung. Was läuft da schief bzw. wie können die Indizies komplett neu aufgebaut werden. Aber bitte nicht übers Backend, das funktioniert a priori nicht…
Entweder du hast ein Produkt mit sehr vielen Varianten und/oder du bist im Dev-Modus und der Speicher wird mit Logs zugebombt
APP_ENV="prod"
und
SELECT COUNT(id) FROM product UNION
SELECT COUNT(id) FROM product WHERE parent_id IS NOT NULL UNION
SELECT COUNT(id) FROM product WHERE parent_id IS NULL;
ergibt 201172,140793,60379
. Diese Begründung entbehrt folglich jeglicher Grundlage…
Summen auszugeben hilft hier wenig, schließlich könnten die Varianten aus Ergebnis 2 auch alle in einem Parent sein.
Vielleicht wäre es klug mit Informationen weniger zu geizen, mit mehr Grundlagen muss man weniger raten.
Wie hoch ist denn die Speicherauslastung beim generieren?
Würde behaupten, dass dein System bei 8 GB also ~ 7,5 GiB den Stecker zieht…
Du hast nicht zufällig Shopware 6.3 oder 6.4?
PS: Schon mal versucht deinen seoURLGenerator zu deaktivieren oder zumindest die Berechtigungen zu korrigieren, dass er die log schreiben kann?
Seit wann werden Logs denn in den /config/jwt Ordner gespeichert?
Das frage ich mich auch. Eigentlich befinden die sich im Ordner var/log, wo auch die prod*.log liegen. Benutze Shopware 6.4.19.0 . Berechtigungen sind mittels chmod 777 gesetzt. Und momentan sieht das so aus:
Müsste ich raten, würde ich sagen: in der fehlenden Variablen ist der Pfad zu den Logs gespeichert.
Würde dann heißen, dass entweder eine Config Datei beschädigt ist oder etwas anderes den relevanten Part überschreibt.
Einmal lokal mit Xdebug drauf geschaut?
Auf dem Stage Server läuft der Indizie Aufbau sauber durch. Da wird aber eine wesentlich kleinere Datenbank verwendet, sonst ist aber alles identisch. XDebug läuft also leider ins Leere…Was meinst Du mit „relevanten Part“?
Stand:
Mit relevant meine ich die Klassen/Methoden, die bei der Ausführung verwendet werden.
Wie Moorleiche weiter oben schon angemerkt hat, kenne ich „das Problem des Abbruchs“ auch nur aus der Situation, dass das Memory Limit erreicht wurde. Und auch da ist der Grund der selbe. Eine zu Hohe Anzahl an Produkten, durch die ganzen Varianten.
Da kann helfen das Limit, ich glaube von 50 auf 1 zu setzen. Gibt dazu einen Thread, in dem Moorleiche das erklärt.
memory_limit=-1
in der php.ini, schon immer…
Stand:
Ich verstehe nicht ,warum es bis jetzt nicht abgesoffen ist?! Mehr als 10 Varianten hat keines der Masterprodukte. Und 201172 Produkte dürfte kein Grund sein, dass er absäuft…
Shopware lädt da 50 x (max. 10) = ungefähr 500 gleichzeitig.
Wobei das Problem erst ab einer fünf- oder stelligen Zahl auftreten sollte.
Oder MySQL schmiert ab, da es nicht genügend Swap gibt. Das hatte ich auch schon.
Weiß nicht genau, wann das Problem mit dem Index gelöst wurde… irgendwann in 6.5 glaube ich.
Das Limit lässt sich zwar verändern, jedoch brachte das bei mir (damals) keine Verbesserung bis ich selbst im Quellcode das Limit für die Childs der Parents angepasst habe.
// Gesucht und gefunden…
Mach mal noch eine SSH Verbindung und starte „top“ oder „htop“ - wird wohl „nur“ gerade mehr RAM übrig sein bzw. wird der Swap nach und nach voll…
top
Hast ja noch ca. 11 GB vom Swap frei… dann wird es kritisch für‘s System zumal es jetzt schon ziemlich langsam sein sollte…
However, es handelt sich hier um dedizierte Cluster Server, die alle in denselben Netzwerk sind- die Datenbank z.B. wird mit eigenem RAM versorgt, ebenso der WebServer und ElasticSearch. Die Angaben beziehen sich auf den WebServer. 4 GB sind für PHP reserviert.
pm.max_children = 80
da
ps --no-headers -o "rss,cmd" -C php-fpm8.1 | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"M") }'
202 ergibt(pm.max_children = 16000 MB / 202= 79,8~80 =>
pm.max_children = 80)
Stand:
Weiter oben hattest Du geschrieben, dass Du die Rechte auf 777 gesetzt hast. bitte aufpassen, dass der Ordner config/jwt auf max 660 steht. Unter bestimmten Bedingungen führt das evtl. zu einem Abbruch. Durch Environment auf PROD kommen die Fehler aber immer max. ins Log.
Der Index-Aufbau ist letztlich aber ne Blackbox.
Mit welchem User Account wird der Index-Lauf denn durchgeführt (Root oder anderer User) ?
Durch Environment auf PROD kommen die Fehler aber immer max. ins Log
Du meinst wohl, durch Environment auf DEV kommen die Fehler max. in die Log?
Was meinst Du mit Blackbox bzgl. der Indexierung?
Wenn die private/public keys auf chmod 777 gesetzt werden, funktioniert Shopware6 nicht mehr. Das ist mir bekannt. Der SSH Zugriff erfolgt als root. Ein sudo ist deshalb nicht notwendig. Abbruch erfolgte gestern nach 4 Stunden und 63% auf grund eines TimeOut’s.
ich meine PROD, damit werden die Fehler ja nicht mehr angezeigt (auch nicht auf der Console und wenn bekommt die Meldungen nur im Log zu sehen).
genau das Problem mit den Keys. Scheint es dann wohl nicht zu sein.
Wenn Du die Prozesse mit ps beobachtest, wo akkumuliert sich denn etwas ? im PHP Prozess oder im ES ?
Der Indexer nutzt sicherlich die Symfony Messenger Infrastructure evtl. sollte man dass hier dann so ein, dass der Task-Handler ein max. Zeit oder einen max. Speicher nutzt. Dann beendet sich der Handler automatisch beim Erreichen des Limits.
Dann muss der Handler irgendwie in einen automatischen Neu-Start (als Service, Supervisord oder batch-script als Endlos schleife).
Und nochwas: wenn Du als ROOT arbeitest und dann auch so die Prozesse anwirfst, ist natürlich auch der File Owner Root. Würde ich eher nicht tun. Sondern eher auf einen „non-priv“ user umschalten …
Das Problem liegt wo anders. Folgender Code war in der Datei SeoURLGenerator.php
try {
$variables = $this->twigVariableParser->parse($template);
} catch (\Exception $e) {
file_put_contents("../config/jwt/seoURLGenerator.log", $e->getMessage() . " at line" . __LINE__ . " in file " . __FILE__ . PHP_EOL, FILE_APPEND);
$e = new InvalidTemplateException($e->getMessage());
/*changed in order to prevent unknown error do not throw Exception
throw $e;
*/
}
...
Die Pfadangabe zur definierten Log File habe ich korrigiert. Das Problem vorab ist, dass $variables null ist, so dass in der Log steht
Unexpected "}" in "content.html.twig" at line 1. at line188 in file /var/www/shop.com/releases/test_release/vendor/shopware/core/Content/Seo/SeoUrlGenerator.php
Wenn ich den Code wie folgt abändere:
if(isset($variables)){
foreach ($variables as $variable) {
$fields = EntityDefinitionQueryHelper::getFieldsOfAccessor($definition, $variable, true);
/** @var Field|null $lastField */
$lastField = end($fields);
$runtime = new Runtime();
if ($lastField && $lastField->getFlag(Runtime::class)) {
$associations = array_merge($associations, $runtime->getDepends());
}
$associations[] = EntityDefinitionQueryHelper::getAssociationPath($variable, $definition);
}
}
Werden die Indizies wie folgt neu gebildet, allerdings ohne die nötigen Assoziationen. Es wird ein leeres Array zurück gegeben, und das ist nicht im Sinne des Erfinders! Wie auch immer, so sieht das jetzt aus:
Was spricht denn gegen ein Update? 
