Magento 1.9 Indexer / Datenübertragung per Schnittstelle

[Klimek]

Wir haben mit Magento 1.7.0.2 ein Shop System auf die emmida Software angebunden, dabei funktioniert der Indexer beim Übertragen der Daten fehlerfrei.

Zusätzlich haben wir auf dem selben System zwei Magento 1.9.1.0 Shop Systeme laufen und beide haben immer wieder Probleme nach der Datenübertragung. Dabei konnten wir den Fehler soweit eingrenzen, dass wir feststellen konnten, dass der Indexer vor der Datenübertragung deaktiviert wird und nach der Übertragung wieder aktiviert wird. Hier kam es des öfteres dazu, dass einzelne Indexer nicht erneuert wurden und die Schnittstelle in eine exception geworfen hat.

Dieser Fehler war nach einmaligen auftreten dauerhaft, auch, wenn der Neuaufbau über das Backend weiterhin problemlos möglich war. Zur kurzweiligen Lösung des Problems haben wir die catalog flat table 1 geleert. Nach dem dies erfolgt ist lief auch die Schnittstelle "erstmal" wieder ohne Fehler.

Die Frage die sich nun stelle, woher rührt der Fehler. Ist dieser bei der emmida Software / Schnittstelle zu suchen oder im Magento selbst? Ich persönlich kann die Argumentation des Anbieters nicht nachvollziehen wieso bei gerade mal 350 Artikeln der Indexer deaktiviert werden muss. Der Anbieter begründete dies jedoch, dass die Datenübertragung eines Artikels sonst bis zu 10 Min !!! dauern würde, was ich bei einer sauber Programmierten Schnittstelle keinesfalls bei der genannten Anzahl von Artikeln mir erklären kann.

Über einige Meinungen und Ideen wäre ich sehr froh

Danke.

[SKeutmeier]

hallo,

Also bei den magento versionen 1.7.x kann ich mir das durchaus vorstellen dass man den indexer deaktiviert bei einem datenimport.

Das habe ich auch immer gemacht.

10 Minuten für 350 Produkte ist allerdings sehr hoch gegriffen. dafür benötigt man schon einen ausserordentlich schlechten oder schlecht konfigurierten Server.

Von daher kann ich die argumentation von emmida verstehen.

ab der version 1.9 ist der indexer jedoch nahezu komplett überarbeitet worden.

Gerade Ihr szenario wird darduch begünstigt. Ein ausschalten des indexers ist meiner meinung nach ab 1.9 nicht mehr nötig.

Ich hoffe ich konnte Ihnen helfen

[Klimek]

Es ist leider so, dass mir gesagt wurde bis zu 10 Minuten für ein Produkt ...

Was die Serverperformance angeht, ist es ein frisch aufgesetztes Linux System mit 4 Cores, 18 GB RAM ...

Der APC ist auch konfiguriert und das Caching in Magento ist ebenfalls aktiv. Wie erwähnt läuft auch der 1.7.0.1 Shop problemlos auf dem System. Was wir anfangs übrigens auch hatten ist, dass die Datenübertragung bei ausgeschalteten Cache garnicht funktioniert hat, da waren erhebliche performance Probleme, dass erscheint mir bei der Anzahl an Artikeln aber auch nicht ganz so üblich. Klar wird die Performance mit Cache begünstigt, aber dass die Übertragung garnicht mehr geht fand ich seltsam.

Wenn du paar Stichpunkte zur besseren Optimierung hast, die ich noch abklopfen kann schau ich auch gerne da nach, aber

dass es am Server liegt halte ich für eher unwahrscheinlich. Da hab ich schon schwächere gleich Konfigurierte Server mit Magento laufen sehen

[SKeutmeier]

Hallo,

das fällt mir jetzt schwer das aus der ferne zu beurteilen.

Wenn du willst kann ich mir aber mal ne stunde zeit nehmen und mich auf dem Server umsehen.

Bei Interesse schicke mir eine PM.

Grundssätzlich gilt bei performance problemen aber Immer:

Messen, Messen, Messen

Wie monitort Ihr den server, föllt da etwas auf?

[Klimek]

Wenn du das machen würdest, wäre das sicherlich cool.

Ich könnte dir allerdings lediglich über TeamViewer von meinem Rechner aus Zugang ermöglichen, ich denke das ist aus Sicherheitsaspekten her nachvollziehbar

[Klimek]

Btw. was würdest du vermuten als Ursache für die Inkonsistenz der Flat Tabellen nach / bei der Datenübertragung bzw. Reaktivierung des Indexes? Abgesehen davon, dass auch du den Index bei der 1.9er nicht deaktivieren würdest

[meeva]

Noch ein paar Details zu Klimeks Problem:
Die Schnittstelle deaktiviert nicht nur alle Indexer vor dem aktuallisieren der Produkte, sondern stößt beim reaktivieren auch alle (genauergenommen alle 9) Indexer zum reindex an.

Der eigentliche Fehler der auftritt ist ein invalid foreign key constraint. Beim Neuaufbau des catalog_product_flat tritt diese Exception auf, da irgendwie üngültige Daten in der Flat Tabelle gelandet sind. Es ist ab dann nicht möglich einen reindex der product flat tabellen vorzunehmen bis diese Tabelle geleert wurde.

Die eigentliche Frage ist wie es zu diesem Fehler kommen kann (Genaue Fehlermeldung leider gerade nicht zur Hand, wird eventuell nachgereicht).

Dies blockiert leider auch den Full-Reindex der durch die Schnittstelle angestoßen wird. Die neuen Informationen landen nicht im Index und werden dadurch nicht im Frontend sichtbar (hauptsächliches Problem sind fehlende catalog_category_product-Index-Daten).

Ein Inkrementelles Update von Indexen beim normalen Speichern eines Produktes ist davon glücklicherweise nicht betroffen, da die ungültigen Daten in der product_flat dabei nicht stören.

Die eigentliche Frage wäre nun: Wie kann es zu üngültigen Foreign-Key-Daten in der catalog_product_flat_1 kommen, so dass ein Full-Reindex von catalog_product_flat nicht mehr möglich ist?

Update Fehlermeldung, "glücklicherweise" gerade wieder akut:

yyy:/xxx # php shell/indexer.php --reindex catalog_product_flat
Product Flat Data index process unknown error:
exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`GSsql2`.`#sql-e64_d4d8b`, CONSTRAINT `FK_CAT_PRD_FLAT_1_ENTT_ID_CAT_PRD_ENTT_ENTT_ID` FOREIGN KEY (`entity_id`) REFERENCES `catalog_product_entity` (`entity_id`) ON DELETE CASCADE ON UPDATE C)' in /xxx/lib/Zend/Db/Statement/Pdo.php:228
Stack trace:
#0 /xxx/lib/Zend/Db/Statement/Pdo.php(228): PDOStatement->execute(Array)
#1 /xxx/lib/Varien/Db/Statement/Pdo/Mysql.php(110): Zend_Db_Statement_Pdo->_execute(Array)
#2 /xxx/app/code/core/Zend/Db/Statement.php(291): Varien_Db_Statement_Pdo_Mysql->_execute(Array)
#3 /xxx/lib/Zend/Db/Adapter/Abstract.php(480): Zend_Db_Statement->execute(Array)
#4 /xxx/lib/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('ALTER TABLE `ca...', Array)
#5 /xxx/lib/Varien/Db/Adapter/Pdo/Mysql.php(428): Zend_Db_Adapter_Pdo_Abstract->query('ALTER TABLE `ca...', Array)
#6 /xxx/lib/Varien/Db/Adapter/Pdo/Mysql.php(347): Varien_Db_Adapter_Pdo_Mysql->query('ALTER TABLE `ca...')
#7 /xxx/lib/Varien/Db/Adapter/Pdo/Mysql.php(2731): Varien_Db_Adapter_Pdo_Mysql->raw_query('ALTER TABLE `ca...')
#8 /xxx/app/code/core/Mage/Catalog/Model/Resource/Product/Flat/Indexer.php(815): Varien_Db_Adapter_Pdo_Mysql->addForeignKey('FK_CAT_PRD_FLAT...', 'catalog_product...', 'entity_id', 'catalog_product...', 'entity_id', 'CASCADE', 'CASCADE')
#9 /xxx/app/code/core/Mage/Catalog/Model/Resource/Product/Flat/Indexer.php(1389): Mage_Catalog_Model_Resource_Product_Flat_Indexer->prepareFlatTable(1)
#10 /xxx/app/code/core/Mage/Catalog/Model/Product/Flat/Indexer.php(296): Mage_Catalog_Model_Resource_Product_Flat_Indexer->reindexAll()
#11 /xxx/app/code/core/Mage/Catalog/Model/Product/Indexer/Flat.php(350): Mage_Catalog_Model_Product_Flat_Indexer->reindexAll()
#12 /xxx/app/code/core/Mage/Index/Model/Process.php(212): Mage_Catalog_Model_Product_Indexer_Flat->reindexAll()
#13 /xxx/app/code/core/Mage/Index/Model/Process.php(260): Mage_Index_Model_Process->reindexAll()
#14 /xxx/shell/indexer.php(167): Mage_Index_Model_Process->reindexEverything()
#15 /xxx/shell/indexer.php(215): Mage_Shell_Compiler->run()
#16 {main}

[SKeutmeier]

@meeva

ganz genau klar ist das wohl niemanden. hatte in der vergengenheit sogar mal kontakt mit magento darüber.

Dieser Fehler scheint allerdings begünstigt zu werden durch langsame mysql-server.

Es gibt beim Indexieren select und update/insert queries die sich bei einem zu langsam reagierenden server im weg sind.

[meeva]

Ich habe mir das gerade noch einmal genauer angeschaut. In catalog_product_flat_1 befindet sich ein Artikel der in catalog_product_entity nicht mehr existiert. Der Foreignkey mit CASCADE sollte eigentlich dafür sorgen das dies nicht passiert, in dem Artikel instant auch aus der flat-tabelle gelöscht werden.

Das ist in diesem Fall nicht geschehen.

Es gibt eigentlich nur einen Zeitpunkt zu dem dies geschehen kann, während eines Full-Reindex der catalog_product_flat-Tabelle. Denn während dessen wird der FK vorrübergehend entfernt, aktuallisierungen vorgenommen, und der FK wieder hinzugefügt (was aktuell nicht mehr möglich ist).

Durch aus kann ich mir vorstellen, dass ein Super-Langsamer MySQL-Server diesen Zeitraum vergrößert und dadurch das Problem fördert, aber ich kann mir nicht vorstellen wie dies auf einem Durchschnittlichen Server in einer Magento-Instanz mit ca. 250 Produkten genau dann zu einer Löschung kommt wenn für den Bruchteil einer Sekunde der FK auf der Tabelle nicht vorhanden ist. Eine Löschung von Produkten ist hier durchaus die Ausnahme, und es ist mehr als unwahrscheinlich das dies wiederhohlt genau auf den extrem kurzen Zeitraum fällt in dem der FK nicht auf der Flat-Tabelle aktiv ist.

Update: Noch ein paar Erkenntnisse. Der Zeitraum beträgt etwa 3 Sekunden. Magento versucht jedesmal alle Attribut-Spalten zu aktualisieren, obwohl dies eigentlich durch vorherigen Ist/Soll-Vergleich nicht nötig sein sollte. Werde ich mir noch weiter anschauen.

Trotzdem sollte der Full Reindex eigentlich nur laufen nachdem ein Produkt gelöscht wurde, nicht während dessen. Ich kann mir nicht vorstellen das ein derartiger Zufall wiederhohlt auftritt. Irgendwas muss da noch im argen liegen.

[Klimek]

Willst du den über TV mal einen Blick riskieren oder schließt du es mitlerweile durch die Erkentnisse von Possi aus?