Hallo,
als ich eben von einem anderen Browserfenster ins Backend wechselte, stand dort folgende Fehlermeldung:
"508 Resource Limit Is Reached Resource Limit Is Reached The website is temporarily unable to service your request as it exceeded resource limit. Please try again later. Apache Server at www.domain.de Port 443 "
Was bedeutet das? Ich kann bei google nichts verständliches finden. Ich würde vermuten, dass der Server überlastet ist?
LG
Hallo Toric,
genau. Irgendwas ist entweder nicht richtig eingestellt (das Limit zu niedrig gesetzt) oder dein Server/Paket schafft so viele gleichzeitige Zugriffe nicht.
Dein Hosting Anbieter soltle dir auf jeden Fall mehr dazu sagen koennen, wenn er sich das genauer anschaut.
Gruß
Alexander
Hallo,
ich finde es sonderbar. Ich habe ein Paket gebucht, das für SW-Shops mit 2000 Besuchern täglich empfohlen ist. Die habe ich bei weitem nicht und heute als der Fehler auftrat bzw. eben, als er zum zweiten Mal auftrat, waren vlt 2 Besucher online. Daher rührt die Überlastung ganz sicher nicht.
LG
Hallo Toric,
moeglicherweise gibt es beim Anbieter selbst Probleme oder die Einstellungen wurden veraendert. Auf jeden Fall solltest du da nochmal nachfragen!
Gruß
Alexander
Danke, mach ich morgen 
Hallo,
übrigens, da Aussagen wie oben, daß nur 2 Benutzer online waren, öfters zu lesen ist:
Bei den in Shopware angezeigten Nutzern sind die vielen Bots, die den Server natürlich genauso belasten wie humane Nutzer, nicht enthalten. Die Zahl ist also in dieser Hinsicht leider ohne jede Aussagekraft.
Da hast du Recht Drakon. Aber selbst wenn alle für die Statistik gesperrten Bots zugegriffen hätten (was sicher nicht der Fall war), käme ich nicht auf 2000 Besucher.
Ich werde das heute mal im Auge behalten.
Hallo,
die genannte Fehermeldung muss nicht zwingend durch einen Besucher im Shopfrontend zustande kommen - sei es nun ein echter Mensch oder ein Bot. Man kann nur erkennen, dass der Apache-Server eine Anfrage auf Port 443 aufgrund der zur Verfügung stehenden Ressourcen nicht verarbeiten kann. Wenn es öfters im Backend auftritt, würde ich zuerst dort anfangen zu suchen (Plugins, Cronjobs…). Das ist letztlich ein Problem der Serverdimensionierung und lässt sich nur durch größere Leistungsreserven vermeiden.
Die 2000 Besucher pro Tag sind doch nur grobe Richtwerte. Kämen diese alle zwischen 19 und 19:10 Uhr in den Shop, wäre der wahrscheinlich am Limit. Verteilen sich die Besucher über 24 Stunden sieht es schon wieder ganz anders aus. Bei der Dimensionierung des Hostingpaketes sind die Peak-Belastungen wesentlich wichtiger. Es ist ja wahrscheinlich wieder ein Shared Hosting Paket, da könnten die Fehler je nach Konfiguration des Servers sehr leicht durch andere Installationen verursacht worden sein. Setzt einfach auf einen virtuellen Server mit garantierten Ressourcen, wenn möglich noch während der Laufzeit des Vertrages skalierbar. Ihr erspart euch viele Probleme und müsst nicht direkt in einen dedizierten Server investieren. Die gibt es im gleichen Preisrahmen wie die ganzen hier im Forum oft beworbenen Shopware-Hosting-Pakete. Und Sie bieten zum Teil die Möglichkeit einzelne Parameter , z. B. für php/fcgi , MySQL o.ä. , individuell zu setzen, wenn der eigene Shop dies aus irgendwelchen Gründen erfordert (Wawi, Plugins etc.).
Ja es ist “wieder” Shared Hosting Paket. Das hört sich wie eine Krankheit an.
Ich hatte über 10 Jahre alle meine Seiten bei Strato gehostet mit Ausnahme meines Shops. Das Mietshopsystem lief auf einem Server mit Tausenden anderer Shops des gleichen Anbieters. Ausfälle gab es da quasi nie und dort waren 3000 Besucher/Tag im Shop bei mir die Regel. Alles was irgendwie mit dem Server zu tun hatte, wurde von dem Anbieter geregelt, Ich musste nur eine Email schreiben. Ein Rundum-Sorglos-Paket also für unter 300 Euro/Jahr. Es ist also kein Unding, dass eine Seite auch bei shared Hosting reibungslos läuft.
Den Shopwareshop hatte ich zunächst bei Strato aufgebaut und dann festgestellt, dass alles sehr langsam lief. Auf die Ratschläge hier im Forum hin, hab ich dann einen anderen Hoster gesucht, der nicht wie Strato ein “Massenhoster” ist. Es gab einige Empfehlungen, eine davon habe ich dann gewählt. Es lägen zwar mehrere Hostingpakete auf einem Server, aber das wäre ja gar kein Vergleich zu Strato z.B.
Ich bin bei diesen Dingen darauf angewiesen, dass das, was mir ein Anbieter/Hoster erzählt, auch so ist. Ich besitze nicht die Kenntnisse um an Server irgendwelche Einstellungen vorzunehmen oder diese zu beurteilen.
D. h. alles was du mir in diesem Absatz rätst:
" Setzt einfach auf einen virtuellen Server mit garantierten Ressourcen, wenn möglich noch während der Laufzeit des Vertrages skalierbar. Ihr erspart euch viele Probleme und müsst nicht direkt in einen dedizierten Server investieren. Die gibt es im gleichen Preisrahmen wie die ganzen hier im Forum oft beworbenen Shopware-Hosting-Pakete. Und Sie bieten zum Teil die Möglichkeit einzelne Parameter , z. B. für php/fcgi , MySQL o.ä. , individuell zu setzen, wenn der eigene Shop dies aus irgendwelchen Gründen erfordert (Wawi, Plugins etc.)."
verstehe ich nur bedingt. Also es gäbe eine Alternative, aber was das dann genau ist, wie man die findet, was ich da einstellen muss, kann oder soll überblicke ich nicht mehr.
Wenn mir also ein Anbieter im Gespräch ein Paket empfiehlt, nachdem er weiß, was ich hosten möchte und wie die Besucherzahlen in Spitzenzeiten aussehen, möchte ich mich darauf verlassen können, dass das passt und läuft und nicht bei jeder Kleinigkeit/Rückfrage später die Empfehlung zu einem größeren Paket oder zu einem eigenen Server geraten wird.
Ein eigener Server oä. für 150 Euro/ Monat rechnet sich schlichtweg nicht. Zumal da noch Kosten hinzukämen für den, der die Einstellungen vornimmt, die ich selbst nicht vornehmen kann.
PS: Ich verzichte soweit als möglich auf Plugins, da ich von den ganzen Problemen hier im Forum etwas abgeschreckt bin. Ich habe lediglich google integration, sw cookie löschen und ein kleines Plugin für das Ausklappmenü. Nur das Nötigste eben…
Ich gehe einfach mal davon aus, dass gestern beim Hoster etwas außer der Reihe gemacht wurde, sofern die Meldung sich jetzt wiederholt. Der Fehler 508 war gestern zum ersten Mal innerhalb eines Jahres. 502 Gateway gibt es häufiger mal, aber da ist jetzt auch klar, woher er kommt.
Ich glaube nicht, dass dir für ca. 30 € pro Monat eine Peakt-Last von 2000 Besuchern (gleichzeitig oder innerhalb von 60 Minuten) garantiert worden ist. Ein Beispiel für virtuelle Systeme findest Du hier: hostnet.de (managed root cloud, nicht unbedingt Level1 - 3GB RAM sind besser, obwohl ich auch ordentlich laufende Systeme auf dem Level kenne), oder Du nimmst ein vergleichbares Paket bei anderen Hostern. Wir setzen es wegen einiger Besonderheiten bei unseren Kunden ein, die für dich nicht unbedingt wichtig sind.
Wenn Du auf einem Shared Hosting System bleiben möchtest, spricht nicht unbedingt etwas dagegen. Es bleibt aber eine Tatsache, dass dort die eigene Shopperformance durch andere Systeme beeinflusst wird. Es sollte wirklich nicht sein, dass 502 gateway Errors so oft auftauchen, dass man diese „öfters sieht“. Die sollten gar nicht auftauchen, woher die kommen, kannst Du anhand der Threads vom Wochenende auch nicht beurteilen. Kämen diese durch absichtliche Reboots von Diensten aus einem Kundenmenü, spräche dies auch nur wieder gegen Shared Hosting. Mit einem Virtual Server fiele diese Fehlerquelle komplett weg. Falls z. B. ein 502 Error nur ein Mal im Backend auftaucht und nach einem Reload wieder verschwunden ist, kannst/musst Du damit leben. So etwas kann dir immer mal passieren. Ein solcher Fall ist eigentlich keinen Forumseintrag wert.
Nein, natürlich nicht. In 10 Minuten werde ich auch nie auf diese Zahlen kommen. Durch den Shopsystemwechsel und versch. andere Faktoren bin ich da sowieso weit entfernt. Wenn ich wieder regelmäßig auf diese Besucherzahlen komme, wäre auch ein eigener Server gar kein Thema. Im Moment sind das aber Peanuts, da sollte ein Shopbetrieb auch so laufen.
Da beide Fehler 508 und 502 nur im BE aufgetaucht sind und direkt nach F5 auch wieder verschwunden, konnte ich natürlich nicht feststellen, ob das FE auch betroffen war.
Und da ich nicht weiß, wer mir hier schreibt Gehörst du zu hostnet.de oder buchst du für deine Kunden bei Hostnet?
LG
Nein, natürlich nicht. In 10 Minuten werde ich auch nie auf diese Zahlen kommen. Durch den Shopsystemwechsel und versch. andere Faktoren bin ich da sowieso weit entfernt. Wenn ich wieder regelmäßig auf diese Besucherzahlen komme, wäre auch ein eigener Server gar kein Thema. Im Moment sind das aber Peanuts, da sollte ein Shopbetrieb auch so laufen.
Da beide Fehler 508 und 502 nur im BE aufgetaucht sind und direkt nach F5 auch wieder verschwunden, konnte ich natürlich nicht feststellen, ob das FE auch betroffen war.
Und da ich nicht weiß, wer mir hier schreibt
Gehörst du zu hostnet.de oder buchst du für deine Kunden bei Hostnet?
LG
Gehöre nicht zu hostnet und Du wirst festgestellt haben, dass ich in der Regel nur die Anforderungsprofile für das Hosting beschreibe .
Da du geschrieben hast “für unsere Kunden” habe ich angenommen, dass du zumindest das erwähnte Paket bzw. das höhere, das für wohl nicht unbedingt nötig ist, dort gebucht/getestet hast o.ä.
Genau die Anforderungsprofile sind die “Angaben” bei denen mir der Kopf schwirrt. Neben dem was du genannt hast 3 GB-Ram z.B. gibt es ja gefühlt 1000 weitere Angaben, die ein Anbieter angibt und die ich überhaupt nicht einschätzen kann. Was ist gut, wichtig, was nicht etc. Die Erklärungen würden hier sicher auch den Rahmen sprengen…
Da du geschrieben hast „für unsere Kunden“ habe ich angenommen, dass du zumindest das erwähnte Paket bzw. das höhere, das für wohl nicht unbedingt nötig ist, dort gebucht/getestet hast o.ä.
Genau die Anforderungsprofile sind die „Angaben“ bei denen mir der Kopf schwirrt. Neben dem was du genannt hast 3 GB-Ram z.B. gibt es ja gefühlt 1000 weitere Angaben, die ein Anbieter angibt und die ich überhaupt nicht einschätzen kann. Was ist gut, wichtig, was nicht etc. Die Erklärungen würden hier sicher auch den Rahmen sprengen…
Klar sind die getestet. Wir setzen diese in der Entwicklung für unsere Kundenprojekte ein und ich empfehle diese meinen Kunden, wenn Sie ein Angebot in der Preisklasse 20-60 Euro suchen. Aber wir vermieten keine Hostingangebote als Reseller o. ä. und haben auch Kunden, die bei anderen Hostinganbietern sind bzw. geblieben sind. Daher hatte ich den Namen quasi erst auf Nachfrage genannt.
Im Wesentlichen brauchen dich nur die Anzahl der vCPUs und das RAM zu interessieren. Wobei Du bei virtuellen Servern das Ram nicht mit dem php-RAM-Limit verwechseln darfst. Auch das Betriebssystem benutzt dieses. In der Regel brauchst Du für Shopware keine Konfigurationen an virtuellen Servern vornehmen, wenn die System-Info von Shopware alles in „grün“ anzeigt. So wie Du den Plugineinsatz beschrieben hast, reichen die „Minimal“-Anforderungen von Shopware für den täglichen Betrieb aus.
Ich habe nun die Hälfte der Ursache für den Fehler gefunden. Nachdem er eben wieder auftrat, bekam ich vom Hoster den Hinweis auf eine Logdatei, die den Fehler anzeigt. Durch regelmäßige CSFR Token-Fehler wäre die CPU überlastet. Ich habe bisher immer an der falschen Stelle nach den Logeinträgen gesucht und daher nichts gefunden. Die Fehlermail habe ich nun mal im BE wieder aktiviert und sammle nun wieder Error-Mails.
Nun habe ich zwar die Log-Datei, kann aber den Fehler trotzdem nicht lokalisieren. Kann man hieraus etwas erkennen?
[2017-01-09 14:28:15] core.ERROR:
exception 'Shopware\Components\CSRFTokenValidationException' with message 'The provided X-CSRF-Token is invalid. Please go back, reload the page and try again.' in /var/www/vhosts/server.de/verzeichnis/engine/Shopware/Components/CSRFTokenValidator.php:161 Stack trace:
#0 [internal function]: Shopware\Components\CSRFTokenValidator->checkFrontendTokenValidation(Object(Enlight_Controller_ActionEventArgs))
#1 /var/www/vhosts/server.de/verzeichnis/engine/Library/Enlight/Event/Handler/Default.php(91): call_user_func(Array, Object(Enlight_Controller_ActionEventArgs))
#2/var/www/vhosts/server.de/verzeichnis/engine/Library/Enlight/Event/EventManager.php(214): Enlight_Event_Handler_Default->execute(Object(Enlight_Controller_ActionEventArgs))
#3 /var/www/vhosts/server.de/verzeichnis/engine/Library/Enlight/Controller/Action.php(143): Enlight_Event_EventManager->notify('Enlight_Control...', Object(Enlight_Controller_ActionEventArgs))
#4 /var/www/vhosts/server.de/verzeichnis/engine/Library/Enlight/Controller/Dispatcher/Default.php(523): Enlight_Controller_Action->dispatch('indexAction')
#5 /var/www/vhosts/server.de/verzeichnis/engine/Library/Enlight/Controller/Front.php(223): Enlight_Controller_Dispatcher_Default->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp))
#6 /var/www/vhosts/server.de/verzeichnis/engine/Shopware/Kernel.php(178): Enlight_Controller_Front->dispatch()
#7 /var/www/vhosts/server.de/verzeichnis/vendor/symfony/http-kernel/HttpCache/HttpCache.php(487): Shopware\Kernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#8 /var/www/vhosts/server.de/verzeichnis/engine/Shopware/Components/HttpCache/AppCache.php(255): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL)
#9 /var/www/vhosts/server.de/verzeichnis/vendor/symfony/http-kernel/HttpCache/HttpCache.php(258): Shopware\Components\HttpCache\AppCache->forward(Object(Symfony\Component\HttpFoundation\Request), true)
#10 /var/www/vhosts/server.de/verzeichnis/vendor/symfony/http-kernel/HttpCache/HttpCache.php(275): Symfony\Component\HttpKernel\HttpCache\HttpCache->pass(Object(Symfony\Component\HttpFoundation\Request), true)
#11 /var/www/vhosts/server.de/verzeichnis/engine/Shopware/Components/HttpCache/AppCache.php(133): Symfony\Component\HttpKernel\HttpCache\HttpCache->invalidate(Object(Symfony\Component\HttpFoundation\Request), true)
#12 /var/www/vhosts/server.de/verzeichnis/vendor/symfony/http-kernel/HttpCache/HttpCache.php(206): Shopware\Components\HttpCache\AppCache->invalidate(Object(Symfony\Component\HttpFoundation\Request), true)
#13 /var/www/vhosts/server.de/verzeichnis/engine/Shopware/Components/HttpCache/AppCache.php(114): Symfony\Component\HttpKernel\HttpCache\HttpCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#14 /var/www/vhosts/server.de/verzeichnis/shopware.php(113): Shopware\Components\HttpCache\AppCache->handle(Object(Symfony\Component\HttpFoundation\Request))
#15 {main} [] {"uid":"c7620f5"}
Vor einigen Wochen hatte ich zwischen 70 und 150 Fehlermails am Tag, weil irgendein Bot aus China versucht hat, Bewertungen abzugeben oder Newsletteranmeldungen durchzuführen. Das war in den Mails etwas besser zu erkennen als hier.
LG
Was heißt denn “regelmäßig” in deinem Fall. Wenn es wieder nur 100-200 am Tag sind, sollte das kein Problem darstellen. Soviel Leistungsreserver muss das Hostingpaket haben. Die CSRF-Token Validierung kann in der config.php deaktiviert werden. Dann gehen die Zugriffe durch und erzeugen damit CPU-Last.
Wie geschrieben, 70-150 am Fehlermails am Tag und nur wg. diesen Bots die Bewertungen schreiben wollten. Fing irgendwann im Sommer an, ging einige Wochen so, irgendwann wurden es weniger also 20-50. Da es sonst keine Fehlermeldungen gab, habe ich die Fehlermail deaktiviert. Das Postfach wird ja schon etwas unübersichtlich…
Während dieser Zeit gab es diese Ausfälle nicht oder ich hätte sie zufällig nicht bemerkt.
Inzwischen (also seit ich eben die Fehlermails wieder aktiviert habe) trudeln die Mails wg. Token beim Newsletter wieder ein, im 5-Minuten-Takt etwa, Bisher 7, das kann nicht wirklich ein Problem sein. Wenn ich jetzt in dem Protokoll im Plesk schaue, find ich dort keine Fehlermeldungen in diesem Zeitraum. Ich kann also die IP zu den Fehlern nicht feststellen. (Wäre super, wenn in die in diesen Mails enthalten wäre.)
Die letzten Fehler und Warnungen liegen dort ein paar Stunden zurück, sehen aber auch nicht gut aus:
rot
mod_hostinglimits:Error on LVE enter: LVE(10001) HANDLER(fcgid-script) HOSTNAME(www.domain.de) URL(/shopware.php) TID(828765) errno (7) Read more: http://e.cloudlinux.com/MHL-E2BIG min_uid (0)
keine IP angegeben
gelb
mod_fcgid: stderr: #5 /var/www/vhosts/t in /var/www/vhosts/name.aix-cloud.de/verzeichnis/engine/Library/Zend/Db/Statement/Pdo.php on line 234, referer: https://www.domain.de/kategorie
IP Telekom
Wenn der Code, den ich oben gepostet habe nur ein Zugriff/Fehler ist und nicht jede Zeile mit # ein neuer, habe ich davon im Protokoll nur eine Hand voll.
Das ist jetzt wieder insgesamt für mich nicht nachzuvollziehen. Diese Botzugriffe dürften auf allen Webseiten mehr oder weniger stark stattfinden. Das dürfte doch bei diesen Dimensionen hier nicht gleich zu einem “Hänger” führen?
Weiter frage ich mich, warum dieser bot nicht als Besucher im Shop angezeigt wird. Auf der Ausschlussliste für die Statistik wird er wohl nicht stehen - aber das nur am Rande.
Die oben gepostete Fehlermeldung ist nur ein “Fehler”. Ab der 4. Zeile - immer beginnend mit # - sind dies nur weiterführende Informationen zum Programmzustand bei der Fehlerauslösung. Die Core-Exceptions im Shopware-Logfile sind immer so aufgebaut.
Das hier ist ein Ressourcenproblem deines Hostingpakets mit LVE, das musst Du mit deinem Anbieter klären: mod_hostinglimits:Error on LVE enter: LVE(10001) HANDLER(fcgid-script)
Ansonsten dreht sich das hier im Kreis: Für deine spezielle Situation benötigst Du ein anderes Hostingpaket. Ein Shopwareproblem an sich scheint nicht vorzuliegen. Entweder Du ziehst daraus die Konsequenzen oder lebst mit deinen Fehlermeldungen/Aussetzern.
Ich weiß ehrlich gesagt nicht, was ich da regeln soll.
Wenn die Fehler durch weitere auf dem Server liegende Kunden verursacht werden, ist es klar- hast du ja oben beschrieben.
Wenn es aber an MEINEM Paket liegt. Mir wurde nach Absprache ein Paket empfohlen, damit bin ich gestartet. Danach wurde mir zu einem größeren geraten (vom Hoster), nun habe ich das doppelte Paket/doppelte Größe und nutze nur 50%. Und das Paket ist bei einem quasi toten Shop schon mit ein paar Botzugriffen überfordert? Das kann ja wohl auch nicht sein.
Dazu noch eine Frage:
„Die CSRF-Token Validierung kann in der config.php deaktiviert werden. Dann gehen die Zugriffe durch und erzeugen damit CPU-Last.“
Müsste das nicht andersherum sein, also wenn die Token deaktiviert sind, wir die CPU weniger belastet?
Müsste das nicht andersherum sein, also wenn die Token deaktiviert sind, wir die CPU weniger belastet?
Nicht unbedingt, es kommt darauf an, welche Programmschritte bei einem invaliden Token eingespart werden. Das habe ich mir aber im Detail noch nie angesehen bei Shopware. Wenn z. B. Bots durch den CSFR-Token Schutz nicht gestoppt werden, liegt aber die Vermutung nahe, dass diese noch mehr Seiten aufrufen und damit Last erzeugen.
Ich kann dir wirklich nicht sagen, was auf deinem System genau vor sich geht. Es ist nur so, dass ich weder 503 noch irgendeinen der anderen Fehler-Codes in den Logs von normalen kleineren vituellen Servern sehe, die auf irgendwelchen Schnickschnack mit Proxy-Servern u. ä. verzichten und mit Shopware 5.2 in der von dir beschriebenen Größenordnung laufen. Verzichte auf ein Shared Hosting, dann weißt Du, ob die temporären Lastspitzen von deinem System ausgehen und kannst danach suchen. Alles andere ist doch sinnlos. Ist dann auch mein letzter Post dazu.
Aus meiner Sicht eine Selbstverständlichkeit: Auf einem solchen System sollte neben Shopware natürlich kein weiteres CMS/Shopsystem laufen. Wenn Du das machst, brauchst Du dich auf Dauer nicht über Probleme mit der Last zu wundern. Statische HTML-Seiten kannst Du natürlich nebenbei betreiben.
Ich kann mir eigentlich nicht vorstellen, dass ihr alle so viele Probleme mit der Leistung habt, wenn ihr nur ein System einsetzt. Letztlich kann keiner der Hostinganbieter über Wasser wandeln und bei den allerkleinsten Shared Hosting Paketen ist es immer ein Glücksspiel, wieviel CMS-Systeme parallel laufen.