Performance Killer? Suche?

Hallo Leute

Wir haben seit Sonntag einen OXID 4.7.1 CE mit 5000 Herstellern und ca 15000 Artikeln auf einem Virtuellen Server (Hosteurope XXL-Paket) laufen.
Immer wieder werden wir von Serverabstürzen geplagt. Und das nicht hin und wieder, sondern ständig.

Ich dachte erst die getArticleCount-Funktionen wären daran schuld, doch dieses Feature habe ich nun ebenso ausgeschaltet wie “Ähnliche Artikel” und dergleichen.

Doch Zack, wieder der Server gecrasht.
Da ich gerade die Suche benutzte liegt es sehr nahe, daß die Suche dafür verantwortlich ist. Laut unserem Provider war angeblich folgender Query für den Absturz verantwortlich:


select count(oxv_oxarticles_de.oxid) from oxv_oxarticles_de where oxv_oxarticles_de.oxparentid = ''

Ein “GREP” über die OXID-Dateien brachte naturgemäß keinen Erfolg, aber ein GREP mit “select count” identifizierte die oxsearch.php als eventuellen Feind!

Ich habe jetzt erstmal die Suche aus dem OXID ausgebaut…

Hat jemand hier Infos und Tipps für mich, wie ich den OXID stabil an den Start bekomme?

Johannes

ICH BITTE DRINGEND UM HILFE!

Uns schmiert ständig der Webserver ab. Ständig LOG-Einträge von verlorener Verbindung zu mysqld! Provider kann nicht weiterhelfen. Webserver lief vorher (typo3, wordpress, xtcommerce) sauber und schnell. OXID bringt ihn um!

Wie kann man die MYSQL-Abstürze verhindern?

Johannes

Schon mal eine Testinstallation gemacht mit weniger Herstellern? Die Anzahl Artike dürfte eigentlich kein Problem sein.

Moin Johannes,

normalerweise sollte das aber problemlos laufen!
Ich kann jetzt nichts über die 4.7.x sagen aber ich hab z.B. einen Shop mit über 80.000 Artikeln und einen weiteren mit knapp 140.000 Artikeln (auch eine vierstellige Herstelleranzahl) sogar auf dem gleichen Server laufen…
Und keinerlei Abstürze oder Performance-Probleme.

Sonst probier doch mal eine ältere Version (4.5.x oder 4.6.x). Die läuft definitiv ohne Probleme in den Grössenordnungen.

Beste Grüsse

Thomas

Hallo Johannes,

wie viele Sprachen gibt es denn? Läuft der DB-Server auf der gleichen Büchse? Stürzt der MySQL oder der Apache ab?

Gruß

Hallo Johannes,

welches OS?
btw, ich glaube nicht, dass es an OXID liegt. Ich hab einen ähnlichen Effekt bei einem meiner VServer mit Wordpress. Läuft WP auf Version 2.9.x läuft alles bestens, Mach ich ein Update auf 3.x stürzt der Server regelmäßig ab. Ich hab da ganz stark Debian im Verdacht oder die Hardware.

Hast Du schon geprüft, auf welchem Stand Dein OS ist?

Moin zusammen,

das klingt irgendwie ziemlich richtig…

Ich hatte mal versucht, auf einem Root-Server von 1&1 e-Fire einzurichten…
Keine Chance ohne gravierende Änderungen!
Damals lags auch am Standard-Debian.

Ich schwöre für Oxid auf Ubuntu, das läuft völlig stressfrei und wie geschmiert!

Beste Grüsse

Thomas

Soweit ich weiß hat Hosteurope Debian am Laufen. Aber auch mein zweiter “Lieblingsprovider” hat seine Kisten (meiner Meinung nach auch korrekt) auf Debian.

Das WordPress ist nicht meine Baustelle -das betreut jemand anders. Da muß ich erst nachfragen.

Wie Hosteurope das mit den Datenbanken löst kann ich nur ahnen Ich denke die DBs liegen direkt auf dem virtuellen Server.

ich habe 2 Sprachen aktiv

Laut Provider stürzt der Apache ab. Laut meinen Erfahrungen stürzt erst der MySQL-Server und danach der Apache ab, da ich noch die offline-Seite zu sehen bekomme bevor nichts mehr geht.

bei HE kannst Du glaub ich bei VServer zwischen Debian und Ubuntu wählen. Ich würde auch sagen, dass zuerst Mysql abschmiert und der zieht dann den Indianer mit in die Tiefe.

sicher dass das snippet nicht so ausschaut:


$sQ = "select count($sArtTable.oxid) from $sArtTable where $sArtTable.oxparentid = '' and oxmanufacturerid = '$sMnfId' and ".$oArticle->getSqlActiveSnippet();

dann liegts wirklich an den Herstellern. Ist aus der oxutilscount.php in der function setManufacturerArticleCount.

OT: ich schwör auf debian und das auch bei 1und1, läuft problemlos auch mit e-fire(auch wenn dies bereits gekündigt ist) :slight_smile: aber jeder hat seine eigenen Präferenzen :slight_smile:

Daran dachte ich auch, weswegen ich das als Erstes ausgeschaltet habe und auch komplett die Manufacturers-Liste herausgenommen hatte.
Leider kam “der Fehler” trotzdem wieder.

Wie es sich in meinem anderen Thread gerade herauskristallisiert sieht es anscheinend am vServer/Debian/Config.

sorry war quatsch.

Danke für all Eure Antworten.
Leider lag das Thema wo ganz anders und ich entschuldige mich, daß ich OXID dafür verantwortlich gemacht habe (nur kam der Fehler erst zum Tragen als OXID online gegangen ist.
Problem war (und ist leider manchmal noch) das in einer typo3-Installation auf selben Server irgendein dämlicher Redirect steckt, der den Server zum Abschmieren bringt.

EnzephaloN

Na danke für’s Bescheid sagen :slight_smile: