Hohe Belastung der DB nach Upgrade

[foolio]

Hallo,

ich habe im Oktober von 1.0-beta1 auf die 1.0.1 geupgraded. Auf dem Server läuft PHP 4.3.10 und MySQL 4.0.24. Seit dem Upgrade fällt mir auf, dass das Laden der Seiten (egal welche) sehr lange dauert. Dabei steigt die CPU-Last vom mysqld auf um die 80% oder mehr. Insgesamt braucht er um die zehn Sekunden für seine Arbeit. IMHO ist das nicht normal. Kann mir jemand sagen, woran das liegt bzw. wie ich das Problem eingrenzen kann?

[garvinhicking]

Hi!

Am Upgrade von 1.0-beta1 auf 1.0.1 dürfte das theoretisch nicht liegen. Datenbanktechnisch hat sich da nichts wirkliches getan.

Gibt es sonst eine Änderung an deinem Server? Hast du evtl. neue Plugins installiert oder sind deine Besucherzahlen gestiegen?

Evtl. liegt es nur an einem speziellen Plugin; welche Event und Seitenleisten-Plugins hast Du installiert?

Ansonsten empfehle ich mal das Slow-Query Log von MySQL zu aktivieren, oder im Falle einer hohen Auslastung in die MySQL Process-List zu schauen. Evtl. gibt es dort Tabellen, die besonders langsam sind.

Ein "OPTIMIZE TABLE" für deine s9y tabellen könnte evtl. auch helfen.

Viele Grüße,
Garvin

[foolio]

Am Upgrade von 1.0-beta1 auf 1.0.1 dürfte das theoretisch nicht liegen. Datenbanktechnisch hat sich da nichts wirkliches getan.

Ich bin auch nicht sicher, ob es daran lag. Mir fiel es nur danach auf.

Gibt es sonst eine Änderung an deinem Server? Hast du evtl. neue Plugins installiert oder sind deine Besucherzahlen gestiegen?

Das letzte Softwareupdate liegt länger zurück. Auch an der Hardware wurde nichts getan. Neue Plugins habe ich mit hoher Wahrscheinlichkeit installiert und deinstalliert. Welche das alles waren, kann ich nicht mehr sagen. Die Nutzerzahlen sind eher rückläufig.

Evtl. liegt es nur an einem speziellen Plugin; welche Event und Seitenleisten-Plugins hast Du installiert?

Sidebar:

• zwei Mal den HTML-Klotz 1.0
  Calendar 1.0
  Quicksearch 1.0
  Archives 1.0
  Categorie 2.0
  Syndicate this blog 1.1
  Powered by 1.0

Event:

• Markup: s9y 1.1
  Markup: Emoticate 1.2
  Markup: nl2br 1.3
  Browser Compat 1.0
  Spam Protector 1.51
  Highlight search queries 1.1
  HTML validator 1.0
  Statistics 1.24
  Markup: track exits 1.5
  Fix common XHTML errors 1.4
  spartacus 2.7
  rules for publishing 1.11
  layout-plugin: printer-friendly version 1.0

oder im Falle einer hohen Auslastung in die MySQL Process-List zu schauen. Evtl. gibt es dort Tabellen, die besonders langsam sind.

Hmm:
Ich habe gerade ein

Code: Select all

SELECT ip from serendipity_visitors;

gemacht. Ergebnis:

Code: Select all

391858 rows in set (13.99 sec)

.
Bei der Prozessliste fiel mir auf, dass S9Y recht lange beim Update der Tabelle verweilt. Ich werde mal ein wenig auf den PHP-Code schauen, wo die Tabelle genutzt wird bzw. ob ich die Größe in den Einstellungen begrenzen kann. Vielleicht liegt hier der Hase im Pfeffer. Was meinst du?

Ein "OPTIMIZE TABLE" für deine s9y tabellen könnte evtl. auch helfen.

Nein, das hat nichts gebracht.

[garvinhicking]

Hi!

Zu den Plugins:

zwei Mal den HTML-Klotz 1.0
-- absolut unkritisch, da gibt es kaum Performance-Probleme

Calendar 1.0
-- auch ziemlich unkritisch

Quicksearch 1.0
-- extrem unkritisch

Archives 1.0
-- unkritisch

Categorie 2.0
-- unkritisch, solange Du nicht das Zählen von Einträgen pro Kategorie aktiviert hast. Diese Option zieht gut an der Datenbank.

Syndicate this blog 1.1
Powered by 1.0
-- beide absolut unkritisch.

Markup: s9y 1.1
Markup: Emoticate 1.2
Markup: nl2br 1.3
Browser Compat 1.0
Spam Protector 1.51
-- allesamt unkritisch

Highlight search queries 1.1
-- das könnte höchstens performance ziehen wenn du viele Google-Bots auf deiner Webseite hast.

HTML validator 1.0
-- nur aktiv wenn du ein blogartikel schreibst, daher zieht das nicht wirklich.

Statistics 1.24
-- Wenn Du das Extended Visitor-Tracking deaktiviert hast, ist dies unkritisch. Die Visitor-Tracking Option kann sehr stark in die Datenbanklast gehen.

Markup: track exits 1.5
-- Unkritisch

Fix common XHTML errors 1.4
-- Das kann etwas Performance ziehen. Da empfehle ich den Einsatz des "Extended Properties for Entries" plugins und da dann das Cachen von artikel aktivieren. Dann wird das Plugin nur einmal beim speichern von Einträgen ausgeführt.

spartacus 2.7
rules for publishing 1.11
layout-plugin: printer-friendly version 1.0
-- Alle drei unkritisch.

Insgesamt ist deine Pluginliste sehr moderat; da dürfte das Problem höchstens an den zwei Option liegen.

Ich habe gerade ein

Code: Select all

SELECT ip from serendipity_visitors;

gemacht. Ergebnis:

Code: Select all

391858 rows in set (13.99 sec)

.

Okay. Also sind die Extended Visotr-Stats aktiviert. Der Code dafür ist recht lahm, weil ich das plugin nie nutze habe ich es mir noch nicht so richtig angeguckt (code stammt von einem kurzzeit entwickler). Deaktiviers am sinnvollsten erstmal.

Viele Grüße,
Garvin

[foolio]

Evtl. liegt es nur an einem speziellen Plugin; welche Event und Seitenleisten-Plugins hast Du installiert?

Es lag definitiv an dem Statistics-Plugin. Ih habe das gelöscht und das Blog läuft wesentlich schneller. Allerdings fehlen mir nur die Statistiken.

[garvinhicking]

Hi!

Leider ist das Statistik-Plugin von mir stark vernachlässigt, da ich es persönlich recht überflüssig finde, da ich Google Analytics nutze oder alternativ Tools wie AWStats. Da müsste man also definitiv mal über eine andere DB-Struktur nachdenken.

Viele Grüße,
Garvin

[foolio]

Leider ist das Statistik-Plugin von mir stark vernachlässigt, da ich es persönlich recht überflüssig finde, da ich Google Analytics nutze oder alternativ Tools wie

Du hast du wohl recht. Ich hatte das anfangs aktiviert und später vergessen. In der gesamten Zeit habe ich vllt. eine Handvoll mal draufgeschaut. Insofern ist es für mir ebenfalls überflüssig.

[thh]

Siehe dazu und zu einer möglichen Lösung auch http://blog.zugschlus.de/archives/403-B ... otopp.html