Hallo Zusammen, Seit den SP2.6b habe beim editieren von Artikeln eine 100% CPU auslastung durch den den MySQL Prozess! Hat jemand ähnliche Erfahrung gemacht? Und an welchen Querys könnte das liegen? PHP 5.3.2 Ubuntu MySQL 5.1.41 Was mir aufgefallen ist das im MySQL Error Log: 110620 20:03:04 [Warning] Statement may not be safe to log in statement format. Statement: UPDATE gm_counter_info SET gm_counter_info_hits = gm_counter_info_hits + 1 WHERE gm_counter_info_id = '229' AND gm_counter_info_name = 'Windows NT' LIMIT 1 110620 20:03:04 [Warning] Statement may not be safe to log in statement format. Statement: UPDATE gm_counter_info SET gm_counter_info_hits = gm_counter_info_hits + 1 WHERE gm_counter_info_id = '148' AND gm_counter_info_name = 'de' LIMIT 1
Hallo doc, ich würde mir das Problem gerne genauer ansehen. Falls noch nicht geschehen, schreibe ein Support-Ticket mit der Bitte dies an mich (Moritz Bunjes) weiterzuleiten. FTP- und Admin-Login-Daten sollten mitgesendet werden.
Konnte das Problem etwas eingrenzen: admin/includes/classes/categories.php Line: 1208 $coo_seo_boost->repair('products'); Ist das Problem, auskommentieren und dann geht es wie gewohnt. Die Methode reparier habe ich mir noch nicht angeschaut das werde ich morgen tun. Wenn evtl. Tipps vorab da sind würde ich mich freuen, würde das gerne über das Forum klären damit auch andere eine Lösung finden die das Problem haben. Danke Moritz! gruß DOC
Hallo doc, dass die repair-Funktion das Problem ist, ist mir bekannt. Wir analysieren gerade das Problem und würden gerne zusätzlich in deinem Shop Untersuchungen durchführen, um schnellstmöglich eine Lösung zu finden. Als workaround kann am Anfang der repair-Funktion in der GMSEOBoost-Klasse ein return true; eingetragen werden.
Hier die Korrektur (für GX und GX2), die als Standard aufgenommen werden wird: Die angehängte GMSEOBoost.php in das gm/classes Verzeichnis hochladen und die vorhandene Datei ersetzten. Zuvor sollte die alte Datei gesichert werden. Nun sollte eine Datenbanksicherung durchgeführt werden. Anschließend im Adminbereich unter dem Menüpunkt SQL folgende Befehle eintragen und ausführen: Code: ALTER TABLE `content_manager` CHANGE `gm_url_keywords` `gm_url_keywords` VARCHAR( 255 ) CHARACTER SET latin1 COLLATE latin1_general_cs NOT NULL; ALTER TABLE `categories_description` CHANGE `gm_url_keywords` `gm_url_keywords` VARCHAR( 255 ) CHARACTER SET latin1 COLLATE latin1_general_cs NOT NULL; ALTER TABLE `products_description` CHANGE `gm_url_keywords` `gm_url_keywords` VARCHAR( 255 ) CHARACTER SET latin1 COLLATE latin1_general_cs NOT NULL; OPTIMIZE TABLE `categories_description` , `content_manager` , `products_description`;
Hallo Moritz, vielen Dank für die Hilfe, aber o.a. Lösungsvorschlag bringt uns nur bedingt weiter. Zumindest sieht es so aus, daß der Server nicht mehr neu gestartet werden muß, aber der Bildschirm "friert" immer noch ein! Soeben noch einmal getestet: Es funktioniert doch, dauert aber wahnsinnig lang! Naja, ist schonmal ein Schritt voraus und hilft wirklich weiter! Warten wir mal das ServicePack des ServicePacks ab! Unseren Dank nach Norddeutschland!
Wir rudern zurück: Es ist alles editierbar, nur keine Bilder!!! Und der Server hängt sich nicht mehr auf! Und die Geschwindigkeit ... wir schweigen besser! Nach langem testen haben wir einmal die Ordner- und Dateirechte überprüft. Aus uns unverständlichen Gründen standen diese nicht mehr auf 777. Jetzt klappert´s!
Ich dachte ich greife das hier mal wieder auf. Gambio GX3.1 CentOs7 Server mit Plesk CPU-Auslastung durch MySQL 70-100%, zu unterschiedlichen Zeiten. Hat jemand ggf. eine Idee woran das liegen könnte oder welche Informationen Ihr benötigt um das rauszufinden? Vielen Dank.
Das ist durchaus betrachtenswert. Kannst du das mit dem Aufruf bestimmter Frontend/Backend Seiten in Verbindung bringen? Vielleicht malträtiert auch jemand deine Shopsuche, wenn du Attribute und Eigenschaften mitdurchsuchen lässt und genug davon hast, dann ist das relativ "teuer".
Was Attribute angeht, haben wir definitiv viele. Bestimmt 100k. Nur ist unser Shop nicht so besucht um solch einen Einbruch zu erhalten. Ich wüsste nicht wie ich bestimmte Scripte oder Seiten damit in Verbindung bekomme, bzw. wo ich das ggf. erkennen kann.
Wenn Du bei der suche die Attribute und Eigenschaften einbeziehst, reicht ein Besucher der 10x nacheinander die suche nutzt. Das kannst Du unter Shop Einstellungen -> Mein Shop bei "Suche in Artikelattributen/Artikeleigenschaften" deaktivieren.
Vorab ich kann dein hochgeladenes Bild leider nicht dem Thema zuordnen, aber ich habe deinen Rat versucht. Dennoch keinerlei Besserung - Auslastung gerade aktuell wieder bei 86%. Das der Server soviel zu schwach ist, bezweifle ich.
Kein Problem, Danke dennoch für deine Mühen. Ich suche derzeit noch weiter, ggf. kann da jemand mal helfen. Lastet vielleicht Magnalister so unglaublich aus?
Wie gesagt ich bin nicht sehr damit bewandert. Hier mal ein Bild von der Auslastung Mysqld, ggf. weiß jemand woran es liegt oder was ich noch machen kann. Mit processlist kann ich leider auch nichts anfangen, aber habe sie mal mitgepostet.
Das jetzt nicht so schrecklich viel. Du musst mal in dem Moment wo akut Auslastung auftritt die MySQL Queries aus der MySQL Prozessliste fischen. Daran wird man erkennen können was da grob läuft.