Zum Inhalt der Seite gehen


!Friendica Support

Moin zusammen.
Ich habe die Option "Datenbank aufräumen" und "Optimieren die Tabellen regelmäßig" aktiviert.

Frage: ist der Zeitpunkt planbar?

Bei mir läuft der Job mitten in der Hauptzeit los und scheint Tabellen zu blockieren. In deren Folge steigt die Worker-Warteschlange. Worker-Eintrag: OptimizeTables

In der Config ist folgendes gesetzt:

'maintenance_start' => '02:00 +01:00',
'maintenance_end' => '07:00 +01:00',
Als Antwort auf Matthias

@Matthias
Ich habe diese Option bei mir deaktiviert, da mir diese zur regelm. Unbenutzbarkeit der Instanz geführt hat. Deswegen würde mich diese Frage auch interessieren.

Was führen diese beiden Optionen eigentlich aus? Ein mysqloptimize oder ganz was anderes?

Als Antwort auf Tuxi ⁂

Die Option führt ein optimize von bestimmten Tabellen aus. Es betrifft nur Tabellen, die grundsätzlich eher klein sind, aber sehr häufig geschrieben und gelöscht werden.
Als Antwort auf Matthias

Ich hab die Option bei meinen Maschinen aktiviert und grundsätzlich keine Probleme damit. Das Zeitfenster gilt nur für das Aufräumen, d.h. das Entfernen von alten Beiträgen.
Als Antwort auf Michael 🇺🇦

@Michael 🇺🇦
Ich würde sie auch gerne weiterhin nutzen wollen. Dann brauche ich aber eine Möglichkeit das in den Randzeiten zu starten. Wenn während des Tages die An- und Auslieferung von Beiträgen um 10-15 min. verzögert wird, dann ist das nicht so schön. Nachts schlafe ich und bekomme es nicht mit ;)
Als Antwort auf Matthias

Das Optimieren der kleinen Tabellen sollte nicht länger als 10 Sekunden dauern. Ich schaue mal, dass ich eine Protokollierung einbaue, um die echten Zahlen zu haben.
Als Antwort auf Matthias

Laut der Programmierung werde diese Tabellen im laufenden Betrieb optimiert:

  • workerqueue
  • process
  • post-delivery
  • inbox-entry
  • check-full-text-search

Diese Tabellen hier werden im Wartungsfenster optimiert:

  • cache
  • locks
  • parsed_url
  • session
  • post-engagement
  • channel-post
  • system-channel-post

Bei welchen der Tabellen gibt es Probleme?

Oder hast Du "optimize_all_tables" aktiviert?

Als Antwort auf Michael 🇺🇦

Bei mir sind es 69. Die Tabelle ist auch nur 35 MB groß. Zumindest bei mir entsteht das Problem aber dadurch, dass die Tabelle durch eine andere (lang laufende) Query blockiert ist. Dann muss die ALTER TABLE query warten - wait for table... Und das dauert lange, was dann wiederum dazu führt, dass sich immer mehr Queries stauen, die irgendwas von der Tabelle wollen. Wenn die Warterei vorbei ist, rutschen die anderen Queries dann recht schnell durch. Aber in der Zwischenzeit geht die Last extrem nach oben.
Als Antwort auf Steffen K9 🍮

@Steffen K9 🍮 @Michael 🇺🇦 @Matthias
Das ist das Verhalten, dass ich auch bei mir beobachten kann. Killt man die Abfrage, die alles blockiert, läuft wieder alles normal weiter.
Als Antwort auf Matthias

@Matthias @Michael 🇺🇦
Vielleicht bringt es für die Analyse etwas, wenn man sich mit mysqldumpslow /var/log/mysql/mariadb-slow.log | head -n 10 mal die am längsten laufenden Abfragen anzeigen lässt?
Als Antwort auf Matthias

Wir haben die automatische Optimierung der Datenbank deaktiviert.
Je nach Größe der Instanz kann selbst das optimieren der "kleinen" Tabellen zu ungewollten "Locks" führen, die die Verfügbarkeit / Funktionalität der Instanz beeinträchtigen können.
Wir führen einen "Optimize" der Datenbank und aller Tabellen alle 1-4 Monate durch.
Das funktioniert relativ gut und ist geplante Downtime.

Bei der automatischen Optimierung hatten wir im laufe der Zeit Unannehmlichkeiten, die wir durch die geplante Downtime vermeiden.

Dieser Beitrag wurde bearbeitet. (4 Tage her)