Shopware Shop legt kompletten Server lahm - brauche dringend Hilfe!

Shopware 5 Allgemein
1

Hallo Gemeinde,

ich stehe mit Shopware vor einem großen Problem. Ich habe auf meinem Server ca. 4 Shopware Shops von unterschiedlichen Kunden am laufen. Bei einem Kunden gibt es massiv Probleme. Zunächst einmal ist folgendes ungewöhnlich:

Seit gut einem Monat zählt die Shopware Statistik Besucher, die gar keine sind. Teilweise haben wir bis 9 Uhr morgens schon über 200 Besucher in der Statistik - bis zum Abends sind es derzeit 300. Natürlich kauft keiner dieser User, sodass die Konversationsrate mitlerweile auf unter 2 Prozent gesackt ist (es waren mal über 9 %).

Jetzt kommt das eigentliche Problem:

Gehostet ist der Server bei allinkl. Seit gut 1,5 Monaten kommt es immer im Abständen von ca. 4-5 Tagen zum kompletten Servercrash. Jedes mal ist wohl dieser eine Kundenshop Auslöser, von der in kurzer Zeit ungewöhnlich viele Anfragen ausgehen. Allinkl erklärt es mal so:

von ca. 20.30 Uhr bis 20.55 Uhr kam es zu Überlastungen durch Massenzugriffe von der IP 91.121.142.199 auf mehrere Domains ihres Servers. Laut Logfile handelt es sich dabei um den „Spiderbot/Nutch-1.7“. Wenn sie es wünschen sperren wir den BOT vom Server weg bzw. limitieren ihn.

Oder mal so

Auslöser heute gegen 12 Uhr waren Massenaufrufe der ip 4.79.204.36 auf

Dadurch wurden die Ressourcen des Server aufgebraucht und der Server überlastete.

Ich habe immer jeweils die IP Sperren lassen, als das auch nicht half habe ich sogar die IP-Zugriffe auf maximal 10 setzen lassen.

Und heute kam es wieder zum totalen Servercrash. Habe erneut nachgefragt. Wieder geht es von der Kundendomain aus und hier die Antwort von allinkl:

Soweit ich das im Watchdog nachvollziehen kann gab es wieder umfangreiche Abfragen auf die DB und daraus resultierend einen Stau am Apache Server welcher diesen zum Absturz brachte.

Wobei ich mir gerade die Hits von ansehe. 813.448 im März und 702.792 im April sind eigentlich Zahlen die selbst für die als nicht gerade als Ressourcenschonend bekannte Shopware eher noch als „Spass“ anzusehen sind.

Ich vermute hier einen Fehler in der Shopware selbst.

Im slowquery Log finden sich immer wieder folgende Abfragen welche besonders lange laufen.

User@Host: @ localhost

SELECT COLUMN_NAME AS Field, COLUMN_TYPE AS Type, IS_NULLABLE AS Null, COLUMN_KEY AS Key, COLUMN_DEFAULT AS Default, EXTRA AS Extra, COLUMN_COMMENT AS Comment, CHARACTER_SET_NAME AS CharacterSet, COLLATION_NAME AS Collation FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = ‚‘ AND TABLE_NAME = ‚s_filter_attributes‘;

Zum Zeitpunkt der Überlastung wurde folgender Query mehrfach geschoben:

287344 localhost Query 33 Opening tables SELECT product.id as product_id, product.supplierID as product_supplierID, product.name as product_name, product.description as product_description, product.description_long as product_description_long, product.shippingtime as product_shippingtime, product.datum as product_datum, product.active as product_active, product.taxID as product_taxID, product.pseudosales as product_pseudosales, product.topseller as product_topseller, product.metaTitle as product_metaTitle, product.keywords as product_keywords, product.changetime as product_changetime, product.pricegroupID as product_pricegroupID, product.pricegroupActive as product_pricegroupActive, product.filtergroupID as product_filtergroupID, product.laststock as product_laststock, product.crossbundlelook as product_crossbundlelook, product.notification as product_notification, product.template as product_template, product.mode as prod
uct_mode, product.main_detail_id as product_main_detail_id, product.available_from as product_available_from, product.available_to as product_available_to, product.configurator_set_id as product_configurator_set_id, productAttribute.id as productAttribute_id, productAttribute.articleID as productAttribute_articleID, productAttribute.articledetailsID as productAttribute_articledetailsID, productAttribute.attr1 as productAttribute_attr1, productAttribute.attr2 as productAttribute_attr2, productAttribute.attr3 as productAttribute_attr3, productAttribute.attr4 as productAttribute_attr4, productAttribute.attr5 as productAttribute_attr5, productAttribute.attr6 as productAttribute_attr6, productAttribute.attr7 as productAttribute_attr7, productAttribute.attr8 as productAttribute_attr8, productAttribute.attr9 as productAttribute_attr9, productAttribute.attr10 as productAttribute_attr10, productAttribute.attr11 as productAttribute_attr11, productAttribute.
attr12 as productAttribute_attr12, productAttribute.attr13 as productAttribute_attr13, productAttribute.attr14 as productAttribute_attr14, productAttribute.attr15 as productAttribute_attr15, productAttribute.attr16 as productAttribute_attr16, productAttribute.attr17 as productAttribute_attr17, productAttribute.attr18 as productAttribute_attr18, productAttribute.attr19 as productAttribute_attr19, productAttribute.attr20 as productAttribute_attr20, productAttribute.swag_bonus_exclude as productAttribute_swag_bonus_exclude, productAttribute.bepado_product_description as productAttribute_bepado_product_description, productAttribute.swag_is_trusted_shops_article as productAttribute_swag_is_trusted_shops_article, productAttribute.article_Keynet as productAttribute_article_Keynet, productAttribute.swag_trusted_range as productAttribute_swag_trusted_range, productAttribute.swag_trusted_duration as _productAttribute_swag_trusted_duration, productAttribute.viison
customs_tariff_number as productAttribute_viison_customs_tariff_number, productAttribute.viison_country_of_origin as productAttribute_viison_country_of_origin, topSeller.sales as topSeller_sales, variant.id as variant_id, variant.ordernumber as variant_ordernumber, variant.suppliernumber as variant_suppliernumber, variant.kind as variant_kind, variant.additionaltext as variant_additionaltext, variant.sales as variant_sales, variant.active as variant_active, variant.instock as variant_instock, variant.stockmin as variant_stockmin, variant.weight as variant_weight, variant.position as variant_position, variant.width as variant_width, variant.height as variant_height, variant.length as variant_length, variant.ean as variant_ean, variant.unitID as variant_unitID, variant.releasedate as variant_releasedate, variant.shippingfree as variant_shippingfree, variant.shippingtime as variant_shippingtime, unit.id as unit_id, unit.description as uni
t_description, unit.unit as unit_unit, variant.packunit as unit_packunit, variant.purchaseunit as unit_purchaseunit, variant.referenceunit as unit_referenceunit, variant.purchasesteps as unit_purchasesteps, variant.minpurchase as unit_minpurchase, variant.maxpurchase as unit_maxpurchase, tax.id as tax_id, tax.tax as tax_tax, tax.description as tax_description, priceGroup.id as priceGroup_id, priceGroup.description as priceGroup_description, manufacturer.id as

…

…

Muss hier leider kürzen weil Nachricht zu lang - poste es im Kommentar

Ich brauche jetzt dringend Hilfe was ich machen soll - habe absolut keinen Plan mehr. Und vor allem betreffen die Serverausfälle auch meine anderen Kunden…

Infos zum Problemshop:

Shopware 5.1.3

Hinzuinstallierte Plugins:

Bonuspunkt System
Erweiterter TinyMCE
BillSafe
Bilder aller Varianten
Google Services
Packstation
Trusted Shops
Net Inventors Incomplete Order Reminder
Net Inventors Foundation
DHL Adapter
SOFORT Überweisung
PayPal
Storno Bestandskorrektur
Indididuelles Dropdown Menu
Facebook Conversion Pixel
Facebook Widget Einkaufswelt

Ich wäre über jede Hilfe dankbar.
kweb

2

Hier die Fortsetzung des Querys:

__manufacturer_id, manufacturer.name as __manufacturer_name, manufacturer.img as __manufacturer_img, manufacturer.link as __manufacturer_link, manufacturer.description as __manufacturer_description, manufacturer.meta_title as __manufacturer_meta_title, manufacturer.meta_description as __manufacturer_meta_description, manufacturer.meta_keywords as __manufacturer_meta_keywords, manufacturerAttribute.id as __manufacturerAttribute_id, manufacturerAttribute.supplierID as __manufacturerAttribute_supplierID, es d.id as __esd_id, esd.articleID as __esd_articleID, esd.articledetailsID as __esd_articledetailsID, esd.file as __esd_file, esd.serials as __esd_serials, esd.notification as __esd_notification, esd.maxdownloads as __esd_maxdownloads, esd.datum as __esd_datum, esdAttribute.id as __esdAttribute_id, esdAttribute.esdID as __esdAttribute_esdID, (SELECT 1 FROM s_articles_esd variantEsd WHERE variantEsd.articleID = product.id LIMIT 1) as __product_has_esd, (SELECT GROUP_CONCAT(customerGroups.customergroupId SEPARATOR ‚|‘) FROM s_articles_avoid_customergroups customerGroups WHERE customerGroups.articleID = product.id) as __product_blocked_customer_groups, (SELECT COUNT(availableVariant.id) FROM s_articles_details availableVariant WHERE (availableVariant.articleID = product.id) AND (availableVariant.active = 1)) as __product_has_available_variants, (SELECT COUNT(DISTINCT prices.price) as priceCount FROM s_articles_prices prices INNER JOIN s_articles_details priceVariant ON priceVariant.id = prices.articledetailsID WHERE (prices.from = 1) AND (prices.pricegroup = ‚EK‘) AND (prices.articleID = product.id)) as __product_fallback_price_count FROM s_articles_details variant INNER JOIN s_articles product ON product.id = variant.articleID LEFT JOIN s_core_units unit ON unit.id = variant.unitID LEFT JOIN s_articles_attributes productAttribute ON productAttribute.articledetailsID = variant.id LEFT JOIN s_articles_esd esd ON esd.articledetailsID = variant.id INNER JOIN s_core_tax tax ON tax.id = product.taxID LEFT JOIN s_articles_supplier manufacturer ON manufacturer.id = product.supplierID LEFT JOIN s_core_pricegroups priceGroup ON priceGroup.id = product.pricegroupID LEFT JOIN s_articles_supplier_attributes manufacturerAttribute ON manufacturerAttribute.supplierID = product.supplierID LEFT JOIN s_articles_top_seller_ro topSeller ON topSeller.article_id = product.id LEFT JOIN s_articles_esd_attributes esdAttribute ON esdAttribute.esdID = esd.id WHERE (variant.ordernumber IN (‚4 29.01‘, ‚424.20‘, ‚481.09‘, ‚420.38‘, ‚423.01‘, ‚4295‘, ‚42910‘, ‚4755.1‘, ‚set1005‘, ‚84269‘, ‚84450‘, ‚87502‘)) AND (variant.active = 1) AND (product.active = 1)

3

Ich habe auch mal in die Logfiles geschaut. Dort taucht kurz bevor der Server abgestürzt ist folgender Eintrag mehrfach auf:

37.24.73.197 - - [26/Apr/2016:09:24:18 +0200] „GET /backend/login/getLoginStatus?_dc=1461655466765 HTTP/1.1“ 200 75 „http://domain_des_kunden.de/backend/“ „Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0“

 Immer mit einem anderen dc=

Was bedeutet dieser Zugriff?!

4

GET /backend/login/getLoginStatus?_dc=1461655466765

Das ist die Abfrage des Loginstatus im Backend und wird in regelmäßigen Abständen bei angemeldeten Backenduser erzeugt (s. NetworkPanels der Entwicklertools bei den einzelnen Browsern). 

Wenn man das Hosting von Kundenprojekten übernimmt, sollte man diese auch so gegeneinander abschotten, dass eine fehlerhafte Installation nicht alle anderen Projekte beeinträchtigt. Wozu gibt es denn Virtualisierungstechniken und diese sind heutzutage auch wirklich nicht mehr teuer. Wenn das schon vorher nicht passiert ist, dann sollte es nach 1.5 Monaten die erste Handlung sein, die guten und die schlechten Früchte zu separieren. Damit wäre ein Problem gelöst. 

Bei dem Problem-Shopsystem muss man den Server mal unter Last debuggen, auch mit deinstallierten Plugins. Bevor man damit anfängt, müssen die anderen Shops unbedingt auf einem anderen System liegen. Ist die Datenbank denn noch in Ordnung? Wieviel DB-Abfragen wurden denn in den angegebenen Zeiträumen mit Massenzugriff wirklich erzeugt? Einige Slow-Queries sollten ja auch nicht gleich einen ganzen Server lahmlegen.

 

5

Ich hatte ähnliche Probleme mal in Verbindung mit SEO-Tools wie onpage… Wenn man die entsprechend konfiguriert können die einen kleinen Server schonmal lahmlegen und man baut sich durch’s Crawling quasi sein eigenes DoS. Vielleicht hat dein Kunde ja auch eine übermütige SEO-Agentur.

6

Also ein eifriger SEO kann ich schonmal ausschließen. Allinkl hat mir jetzt angeboten den Account meines Kunden testweise für 7 Tage auf einen V-Server zu legen (was immer das auch ist =))

Nunja, seitdem ist bislang der Server schonmal nicht mehr in die Knie gegangen.

Weiterhin aber völlig unrealistische Besucherwerte. Angeblich 500 Besucher heute gehabt - wieso sollten die Besucher innerhalb von 2 Monaten sich verdreifachen? Die Conversationsrate von 9 % auf jetzt unter 2 % gerutscht. Verstehe die Welt nicht mehr :confused:

7

Habe mir heute morgen mal die Analytics genauer angeschaut und dabei über Semalt gestolpert. Scheinbar haben wir ein Referal Spam Problem.

Habe hier im Forum diesen Beitrag dazu gefunden:

http://forum.shopware.com/discussion/22112/semalt-verzerrt-statistiken-blocken-via-htaccess

Meine Frage: Ist es möglich, dass sich dieser Spam auch auf die Shopware Statistiken auswirkt. Google Analytics zeigt mir im Schnitt am Tag 200 Besucher an. Die Shopware Statistik über 450.