Doppelte Anzahl von Artikeln bei Shopabgleich ?

[Gabbahead]

Ich bin gerade etwas verwundert, mal abgesehen das der Import nun schon 2 Tage dauert ohne das wirklich etwas passiert, wird mir beim Import die doppelte Anzahl an Artikel angezeigt.
In der Datenbank stehen eigentlich "nur" 2068147 Artikel. Beim Import selber werden mir dann aber 4069081 Artikel angezeigt und das sind ja fast doppelt so viele wie es eigentlich wirklich sind.
Gibt es dafür irgendeinen logisch nachvollziehbaren Grund, oder ist das ein Bug ?

Auch tut sich in der MySQL Datenbank wärend des Imports bei der Tabelle tArtikel nicht wirklich etwas, es werden irgendwo anders Daten importirt aber nicht dort.
Auch die Geschwindigkeit lässt sehr zu wünschen übrig, das es lange dauern würde war mir klar, aber nicht das es so lange dauern würde. Siehe Screenshot. Soweit nach 2 Tagen.

 

[Janusch]

AW: Doppelte Anzahl von Artikeln bei Shopabgleich ?

Hallo,

schaue direkt in die Datenbank was dort alles vorhanden ist:

SELECT COUNT(*) FROM tArtikel

Für Artikelanzahl und mit

SELECT COUNT(*) FROM tArtikelShop

Hier sollten bei einem Shop die gleiche Anzahl Einträge sein wie Artikel wenn alle im Shop angezeigt werden sollen.


Es sieht mir danach aus das es hängt. Eine Mögliche Ursache wäre dies hier:
http://forum.jtl-software.de/fehler...stehen-ohne-fehlermeldungen-5.html#post332442

 

[Gabbahead]

AW: Doppelte Anzahl von Artikeln bei Shopabgleich ?

Ja ich weiß, diese Abfragen hab ich ja gemacht und dort wird mir eben eine ganz andere Anzahl angezeigt, die später beim Shopabgleich steht.
Inzwischen habe ich nun per SQL Statement alle Artikel deaktiviert, die keinen Preis haben um die Anzahl der zu übertragenen Artikel nochmals zu reduzieren:

update tartikel set caktiv = 'N' where caktiv = 'Y' and feknetto = 0

Trotzdem das selbe Ergebniss, nach der Übertragung der Kategorien werden angeblich 4069081 Artikel übertragen und das dauert bis sich dort der Balken überhaupt auch nur 1mm rühert.

 

[Janusch]

AW: Doppelte Anzahl von Artikeln bei Shopabgleich ?

Das hat keine Auswirkung.

fEKNetto = Einkaufspreis und nicht der Verkaufspreis!

Setzt man cAktiv=N so muss ein Löscheintrag in tQueue damit der Artikel im Webshop gelöscht wird.

Artikel die zum Webshop gesendet werden stehen in tArtikelshop.


Ich denke Du hast 2 Mio. Einträge in tQueue

SELECT COUNT(*) FROM tQueue


Diese werden zu den in tArtikelShop hinzuaddiert.

 

[Gabbahead]

AW: Doppelte Anzahl von Artikeln bei Shopabgleich ?

Das Statement hab ich so von euch bekommen. maik.schwefer hatte mir das so letzten Donnerstag geschickt.

SELECT COUNT(*) FROM tArtikelshop zeigt die selbe Anzahl an, das ist korrekt. Eigentlich sollten da ja nun nur noch die auftauchen, die einen Preis haben. Wie müsste also das Statement korrekt aussehen damit die Artikel ohne Preis vom Webshopabgleich ausgeschlossen werden ?

SELECT COUNT(*) FROM tQueue

zeigt mir 2002128 Artikel an.

Das deaktivieren an sich scheint aber funktioniert zu haben, der Import läuft schon und aktuell tauchen im shop keine Artikel ohne Preis auf.
Aber die Importanzeige irritiert mich halt, da dort über 4 Millionen Artikel stehen und die Anzeige sich nicht rühert, in der MySQL Datenbank tauchen aber die ganze Zeit neue Einträge auf.
Vielleicht hat ja jemand von euch kurz Zeit für ne TV Sitzung.

 

[Gabbahead]

AW: Doppelte Anzahl von Artikeln bei Shopabgleich ?

Was die ganze Sache so verlangsamt sind glaube ich die tkategorieartikel bzw. tkategorieartikelgesamt in der MySQL Datenbank, denn dort landen derzeit viel mehr Dateien. Die Anzahl in tartikel verändert sich gerade beim Import kaum.

Aktuell in der MySQL DB vom Shop:

tartikel = 3,526
tkategorieartikel = 868,490
tkategorieartikelgesamt = 457,323

Import läuft seit ca. ner Stunde

Webshopableich sieht wieder so aus, nach einer Stunde:

 

[Janusch]

AW: Doppelte Anzahl von Artikeln bei Shopabgleich ?

SELECT COUNT(*) FROM tArtikelshop + SELECT COUNT(*) FROM tQueue = 4 Mio.

Müsstest Du schauen was in tqueue drin ist, kann von falschen handhabung der Ameiseimporte kommen.
Falls der Shop leer ist, kann tqueue geleert werden. Die wird als erstes abgearbeitet und deshalb nix zum Webshop gesendet.

 

[Gabbahead]

AW: Doppelte Anzahl von Artikeln bei Shopabgleich ?

Hatte oben mein Beitrag nochmal editiert.
Aber ok, dann leere ich nun erstmal die tQueue und setze den Shop zurück und schau mir die Zahlen danach nochmal an.

 

[Gabbahead]

AW: Doppelte Anzahl von Artikeln bei Shopabgleich ?

Ok nun wird beim Import die gesamte Anzahl der Kategorien angezeigt. Also nicht mehr 4 Millionen +, sondern 2 Millionen +.
Das sieht schon mal sehr viel besser aus. Aber wie kommt es zu dieser tQueue Geschichte und warum werden nun nicht die inaktiven Artikel mit abgezogen ? Sie werden ja trotzdem nicht mit importiert ?

Warum wird beim Zurücksetzen des Shops eigentlich die Tabelle tkategorieartikelgesamt nicht geleert ?

 

[Gabbahead]

AW: Doppelte Anzahl von Artikeln bei Shopabgleich ?

Mich am Dienstag Abend gefreut das es endlich mal durchläuft und irgendwie passiert nun seit gestern wieder nichts, zumindest nichts was die Grafik angeht.
Auf dem Server scheinen aber immer noch Daten zu landen.

 

[Janusch]

AW: Doppelte Anzahl von Artikeln bei Shopabgleich ?

Schaue die Auslastung der mySQL auf dem Webserver. Auch mal Long Queries anschauen.
Ich denke das wird der Flaschenhals sein. Das sieht auch nach der Grenze von 500-600k Aritkel was der Shop auf normalem Server handhaben kann.

 

[Gabbahead]

AW: Doppelte Anzahl von Artikeln bei Shopabgleich ?

Na die Auslastung vom Server ist in Ordnung.
Log schaue ich auch gleich nochmal rein...

 

[Gabbahead]

AW: Doppelte Anzahl von Artikeln bei Shopabgleich ?

Und der Shop sollte eigentlich locker mit mehr Artikel umgehen können als die Wawi selber. Wüsste jetzt nicht wieso da schon das limit erreicht werden sollte. Die suche funktioniert ja auch schnell bis jetzt. Also der MySQL Server pfeift nicht nach Luft. Klar, aktuell läuft die DB mit MyISAM und würde wärend des Shopableichs mit InnoDB etwas besser laufen, aber soweit ich weiß läuft die Suche selber mit MyISAM ja besser.

 

[Janusch]

AW: Doppelte Anzahl von Artikeln bei Shopabgleich ?

Ich verweise nochmal darauf:

http://forum.jtl-software.de/beta-b...tei-33gb-32-millionen-artikel.html#post422043

Das mag sein das der Shop jetzt noch läuft. Das Ändert sich gewaltig sobald da Traffic kommt. Dazu zählen nicht nur normale Nutzer, Boots, SUMAs usw. Auch der Abgleich. Die mySQL vebraucht jetzt beim Abgleich 90% CPU!

Die Beschränkungen die wir aufzeigen betreffen auch diesen Webserver.

 

[Gabbahead]

AW: Doppelte Anzahl von Artikeln bei Shopabgleich ?

Diese 90% beziehen sich lediglich auf ein CPU von 4 bzw. 1 Kerne von 4.
Da ist noch ne Menge Luft nach oben offen. Der Server idlet vor sich hin wie man an der Load sehen kann, der Mittelwert der Load liegt aktuell bei 0,8.



Könntest du bitte noch meine Frage bezüglich der Artikelanzahl beantworten die aktuell in den Shop importiert werden ?
Ich habe ja alle Artikel die keine Preise haben deaktiviert, trotzdem scheint es so als wenn alle Artikel rübergeschoben werden.



Im Shop selber tauchen aber nur Artikel auf die einen Preis haben. Ist die im Abgleich angezeigte Zahl nicht korrekt ?
So lange dauern tut der Import, weil er ca. 30 Millionen Verknüpfungen anlegt. Derzeit liegt die Anzahl der Datensätze bei 16 Millionen.



Artikel befinden sich derzeit nur 314,782
Den Bärenanteil machen zur Zeit die Kategorieartikel und die Kategorieartikelinsgesamt aus 6,632,085 und 1,629,017.



Ich denke die Tabelle kPreis entspricht den Finalen Stand der Artikel die derzeitig wirklich importiert werden. Alles andere sind nur Kopien bzw. Verknüpfungen der einzelne Kategorien.



Und hier die Gesamtanzahl der Datensätze und Gesamtgröße der aktuellen Datenbank

 

[Gabbahead]

AW: Doppelte Anzahl von Artikeln bei Shopabgleich ?

Was die Hardware angeht, der Server kommt in einem Cluster mit Failover. Die Datenbank wird auf einem extra Server laufen nicht dort wo der Apache läuft.
Auch die größe von 1.5GB ist noch händelbar. Die Hardware wird ebenfalls noch aufgestockt. Daran soll es also nicht hapern. Sollte es täglich Preisänderungen geben wird die DB Testweise auf InnoDB umgestellt. Je nach dem wie wir die Suche noch optimieren können. Denn aktuell scheint es ja nur eine Volltextsuche zu sein.