Maximale Länge Suche Fehler

Hallo, 

folgendes Produkt wollte ich im Shop suchen lassen: 

Oral-B Elektro Vitality 100 Kids Star Wars

In der Suchezeile (Formular) wird aber der String abgekürzt auf 30 Zeichen:

Oral-B Elektro Vitality 100 Ki

Aber anstatt einem Vorschlag (max 6) bekomme ich eine 503 vom Server in der Console(Netzwerk).

ajax_search?sSearch=Oral-B%20Elektro%20Vitality%20100%20Ki

Auf der Suchergebnisseite (fuzzy) bekomme ich:

Ups! Ein Fehler ist aufgetreten!

Um ein Suchergebnis zu bekommen muss ich den String kürzen bis auf  25 Zeichen

Oral-B Elektro Vitality 1

bei einem anderen Product reichen 29 Zeichen um ein Ergebnis zu bekommen

FUJIFILM X-T3 Silver Kit XF 16-80mm
->
FUJIFILM X-T3 Silver Kit XF 1

Hat jemand hier eine Idee warum die Suche das macht? Liegt das an Zahlen, Stringlänge?

Danke und Gruss

SW 5.6.6
PHP 7.4.3

Was steht denn im Log für ein Fehler?

Mhh, nur eine Ausführung kostet jeweils 20MB Fehlermeldung im Errorlog. Der war dann heute auf 545 angeschwollen. Sieht aus wie eine Fehler den ich hier (https://forum.shopware.com/discussion/comment/266707/#Comment_266707) schon einmal hatte und immernoch habe im zusammen mit der Suche (Suchindex aufbauen) Ganz viele UNIONS und am Schluss:

SQLSTATE(42000): Syntax error or access violation: 1064 memory exhausted near 'relevance, '100' as term, 3295539 as keywordID UNION ALL SELECT 20 ' at line 10659 in /var/www/clients/client1/web1/web/vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php:179 Stack trace: #0 /var/www/clients/client1/web1/web/vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php(150): Doctrine\DBAL\DBALException::wrapException() #1 /var/www/clients/client1/web1/web/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(915): Doctrine\DBAL\DBALException::driverExceptionDuringQuery() #2 /var/www/clients/client1/web1/web/vendor/doctrine/dbal/lib/Doctrine/DBAL/Query/QueryBuilder.php(206): Doctrine\DBAL\Connection->executeQuery() #3 /var/www/clients/client1/web1/web/engine/Shopware/Bundle/SearchBundleDBAL/ProductNumberSearch.php(98): Doctrine\DBAL\Query\QueryBuilder->execute() #4 /var/www/clients/client1/web1/web/engine/Shopware/Bundle/SearchBundleDBAL/ProductNumberSearch.php(80): Shopware\Bundle\SearchBundleDBAL\ProductNumberSearch->getProducts() #5 /var/www/clients/client1/web1/web/engine/Shopware/Bundle/SearchBundle/ProductSearch.php(59): Shopware\Bundle\SearchBundleDBAL\ProductNumberSearch->search() #6 /var/www/clients/client1/web1/web/engine/Shopware/Bundle/SearchBundle/VariantSearch.php(66): Shopware\Bundle\SearchBundle\ProductSearch->search() #7 /var/www/clients/client1/web1/web/engine/Shopware/Controllers/Frontend/AjaxSearch.php(129): Shopware\Bundle\SearchBundle\VariantSearch->search() #8 /var/www/clients/client1/web1/web/engine/Shopware/Controllers/Frontend/AjaxSearch.php(59): Shopware_Controllers_Frontend_AjaxSearch->search() #9 /var/www/clients/client1/web1/web/engine/Library/Enlight/Controller/Action.php(192): Shopware_Controllers_Frontend_AjaxSearch->indexAction() #10 /var/www/clients/client1/web1/web/engine/Library/Enlight/Controller/Dispatcher/Default.php(478): Enlight_Controller_Action->dispatch() #11 /var/www/clients/client1/web1/web/engine/Library/Enlight/Controller/Front.php(228): Enlight_Controller_Dispatcher_Default->dispatch() #12 /var/www/clients/client1/web1/web/engine/Shopware/Kernel.php(188): Enlight_Controller_Front->dispatch() #13 /var/www/clients/client1/web1/web/vendor/symfony/http-kernel/HttpCache/SubRequestHandler.php(102): Shopware\Kernel->handle() #14 /var/www/clients/client1/web1/web/vendor/symfony/http-kernel/HttpCache/HttpCache.php(453): Symfony\Component\HttpKernel\HttpCache\SubRequestHandler::handle() #15 /var/www/clients/client1/web1/web/engine/Shopware/Components/HttpCache/AppCache.php(261): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward() #16 /var/www/clients/client1/web1/web/vendor/symfony/http-kernel/HttpCache/HttpCache.php(426): Shopware\Components\HttpCache\AppCache->forward() #17 /var/www/clients/client1/web1/web/vendor/symfony/http-kernel/HttpCache/HttpCache.php(317): Symfony\Component\HttpKernel\HttpCache\HttpCache->fetch() #18 /var/www/clients/client1/web1/web/engine/Shopware/Components/HttpCache/AppCache.php(188): Symfony\Component\HttpKernel\HttpCache\HttpCache->lookup() #19 /var/www/clients/client1/web1/web/vendor/symfony/http-kernel/HttpCache/HttpCache.php(192): Shopware\Components\HttpCache\AppCache->lookup() #20 /var/www/clients/client1/web1/web/engine/Shopware/Components/HttpCache/AppCache.php(113): Symfony\Component\HttpKernel\HttpCache\HttpCache->handle() #21 /var/www/clients/client1/web1/web/shopware.php(122): Shopware\Components\HttpCache\AppCache->handle() #22 {main} [] {"uid":"47868dd"}

 

Hast Du die Live-Aktualisierung des Such-Index aktiv und neue Produkte im Shop oder den Index gelöscht?

Du bekommst die Fehlermeldung wenn:

a) das RAM nicht ausreicht, um die Indexierung durchzuführen. Das geht ziemlich schnell, wenn Du eine vernünftige php-memory-limit Grenze gewählt hast oder grundsätzlich zu wenig RAM für deine MySQL Operationen zur Verfügung steht. 

b) evtl. wenn dein Raid1 Probleme mit einer defekten Fesplatte hat. Ist dann letztlich ein Folgefehler. Haben wir schon im Support gehabt. Wahrscheinlicher ist allerdings Option a

Probier mal den Suchindex per CLI aufzubauen und dort geziel ein hohes RAM-Limit zu setzen. 

Falls Dir das aufgrund Eures Hostings nicht möglich ist, bleibt eigentlich nur die Datenbankfelder für den Suchindex zu begrenzen. 

 

 

 

1 „Gefällt mir“

Ich habe noch ca 15GB von 32GB frei.

Habe (rambo-mässig) memory_limit auf 15000M gesetzt und live modus ist aktiv. Aktuell sind  schon 15.000 Keywords vorhanden.

CLI bringt ein haufen Fehler (Auszug s.u.) und stoppt nach 10004012:

...  
SELECT sk.id as keywordID, 4043 as elementID, 5 as fieldID FROM s_search_keywords sk WHERE sk.keyword IN ('10004010')

UNION ALL

SELECT sk.id as keywordID, 4044 as elementID, 5 as fieldID FROM s_search_keywords sk WHERE sk.keyword IN ('10004011')

UNION ALL

SELECT sk.id as keywordID, 4045 as elementID, 5 as fieldID FROM s_search_keywords sk WHERE sk.keyword IN ('10004012')'

und am Schluss:

SQLSTATE[42000]: Syntax error or access violation: 1064 memory exhausted near 'sk.id as keywordID, 4043 as elementID, 5 as fi
  eldID FROM s_search_keywords sk WH' at line 15995

 

Nimm mehr RAM. Ich habe das bei der “Intelligenten” Suche schon mit 48GB laufen lassen, weil es mit irgendetwas in den 20er GB nicht funktionierte. Und das war kein besonders großer Shop. Im Endeffekt habe ich die Suche auf absolut notwendige Datenfelder reduziert, um mit den häufigsten Suchphrasen vernünftige Ergebnisse zu bekommen. 

Also Rambo ist noch nicht 15GB :wink: . Reduzier mal die DB-Spalten auf Name und Meta-Keyowords oder so und schau, ob es mit den 15GB auf der Kommandozeile funktioniert. Du hast auch schon explizit bei dem CLI-Aufruf die 15Gb zugeordnet?

In einer zweiten SSH.Sitzung kannst Du dir mit top ansehen, welcher Prozeß RAM zieht.

Wenn Du dir die Select-Statements bei der Keyword-Index Erstellung ansiehst, weißt Du auch, warum RAM die entscheidende Stellschraube ist.

Die Aktualisierung musst Du auf jeden Fall aus Live auf Cron stellen müssen. Den Fehler wirst Du sonst dauernd sehen. 

1 „Gefällt mir“

Im CLI habe ich keine Angabe zu 15GB gemacht, das habe ich in Timmes Einstellungen “memory_limit = 15000M” gemacht. Wie ist der Befehl das an die CLI zu hängen? Unter --help stand nix davon. Bitte ein Beispiel. Danke.

Das mit htop habe ich schon gemacht, aber der bleibt bei seinen ausgelastetem RAM, also keine Veränderung wenn ich das Script oder den Backendprozess laufen lasse.

Ja, ich habe die Suche angepasst gehabt, Ich habe Artikel-Eigenschaften mit einbezogen. Ich teste es mal wenn ich das rausnehme. Aber wir brauche das! :-/ 

EDIT: ich muss ncoh sagen, dass ich vorher 64GB (Hetzner) hatte und jetzt nur noch 32GB (Timme).

@brettvormkopp schrieb:

Im CLI habe ich keine Angabe zu 15GB gemacht, das habe ich in Timmes Einstellungen „memory_limit = 15000M“ gemacht. Wie ist der Befehl das an die CLI zu hängen? Unter --help stand nix davon. Bitte ein Beispiel. Danke.

Das mit htop habe ich schon gemacht, aber der bleibt bei seinen ausgelastetem RAM, also keine Veränderung wenn ich das Script oder den Backendprozess laufen lasse.

Ja, ich habe die Suche angepasst gehabt, Ich habe Artikel-Eigenschaften mit einbezogen. Ich teste es mal wenn ich das rausnehme. Aber wir brauche das! :-/ 

EDIT: ich muss ncoh sagen, dass ich vorher 64GB (Hetzner) hatte und jetzt nur noch 32GB (Timme).

 

php -d memory_limit=1024M

 

1024M entsprechend anpassen; php entsprechend deiner verwendeten PHP-Verison bei Timme-Hosting anpassen.

Es hat also bei Hetzner funktioniert den Suchindex komplett neu aufzubauen und bei Timme nicht? 

 

Optionen zur Verwendung der php-CLI findest Du  auch in der PHP-Dokumentation : https://www.php.net/manual/de/features.commandline.options.php