Ich habe hier einen OXID-Shop 4.8.4 mit 16.000 Artikeln. Er lief bis eben noch problemlos - das Frontend scheint auch immernoch sauber zu funktionieren.
Doch im Backend in der Artikelverwaltung (und anscheinend nur dort) bekomme ich einen Fehler:
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 32 bytes) in /is/htdocs/.../core/oxbase.php on line 362
Dem Apache sind hier 256MB zugesprochen, was eigentlich dicke reichen sollte. Das Admin-Panel ist auch im default-Zustand (keine Erweiterungen).
Der Gesundheitscheck brachte keine Fehler zu Tage.
Was ist da los? Hat jemand eine Ahnung wie ich die Artikelverwaltung wieder “an” bekomme?
Ich habe hier einen OXID-Shop 4.8.4 mit 16.000 Artikeln. Er lief bis eben noch problemlos - das Frontend scheint auch immernoch sauber zu funktionieren.
Doch im Backend in der Artikelverwaltung (und anscheinend nur dort) bekomme ich einen Fehler:
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 32 bytes) in /is/htdocs/.../core/oxbase.php on line 362
Dem Apache sind hier 256MB zugesprochen, was eigentlich dicke reichen sollte. Das Admin-Panel ist auch im default-Zustand (keine Erweiterungen).
Johannes[/QUOTE]
der apache scheint da anderer meinung zu sein, das 256 reichen. setz doch mal hoch und schau was er dann sagt.
nunja ich weiss ja nicht was oxid standardmäßig so braucht… aber wenn er die artikelliste läd kommen da bestimmt ein paar bytes zusammen. 160000 sind ja nun doch auch ein paar stück.
Neee, bei 16.000 Artikeln, 'ner oxarticles von 60MB kann mit “aus der datenbank holen, objekte draus machen, templating anwerfen, etc” nicht über 256MB Arbeitsspeicherbedarf werden. Das muß einen Grund haben.
Kann es sein das es daran liegt, daß in der Datenbank die Kollationen “wild” gemischt sind mit latin1_general_ci und utf8_general_ci ???
Nach etwas Datenbankoptimieren (utf8_unicode_ci einstellen und DB optimieren) hat sich kaum etwas getan. Die Ladezeiten der Artikelliste im Backend ist ein Krampf!
Habe mal spaßenshalber das memory_limit zurück auf 256MB gestellt -> FATAL.
vlt irgendwo was falsch reingemacht und dadurch einen “loop” drin …[/QUOTE]
Hallo
@caladan: Nein, ein von Azure abgeleitetes Template - aber das Frontend sollte hier keinen Einfluß haben. Im Admin-Bereich ist alles Default (garkeine Template-Änderungen).
[QUOTE=caladan;142288]
probier doch mal mit default einstellungen…
ich glaub mein apache hat grad 128mb eingestellt.[/QUOTE]
Wie gesagt sind bei mir 256MB der Default und da bekomme ich einen Fatal Error. Hebe ich auf 512MB an dauerts zwar ewig bis die Liste erscheint und ein Arbeiten ist fast nicht möglich, aber es kommt kein Fatal Error mehr.
das hab ich schon verstanden … aber irgendwas macht er … und irgendwie läd er offensichtlich viele daten in den speicher.
das kann auch bei einem “loop” passieren wenn evtl. datensätze mehr als 1x geladen werden. daher die vermutung mit dem template… könnte natürlich auch eine sql sache sein.
Kabumm!
Hatte gerade an anderer Stelle gemerkt, daß meine Zuordnung von OXVENDOR nicht so recht hinhaut und sowohl die Tabelle oxvendor als auch die Spalte oxarticles.OXVENDORID geleert.
Schwupps und schon rennt die Artikelliste wieder .
Es liegt also daran, daß bei mir (ausversehen) jeder Artikel einen Lieferanten hat, der Lieferant aber je Artikel angelegt ist (also 16000 Artikel und 16000 Lieferanten).
Muß also mein Importskript hier nochmal überprüfen
.