- Dieses Thema hat 12 Antworten und 3 Stimmen, und wurde zuletzt aktualisiert vor 3 Jahren, 9 Monaten von
.
-
Beiträge
-
Hallo,
bei uns läuft das System in den letzten Wochen recht langsam. Jlawyer-Server ist bei uns auf einem eigenen Windows10pro System installiert (es wird an dem Rechner nichts anderes gemacht).
Die Prozessanzeige vom Taskmanager gibt mir folgendes aus:
Zum Zeitpunkt vom Screenshot wurde mit 7 Clients gearbeitet. Ich vermute mal, dass die Datenträgerauslastung das System so ausbremst. Ist dieser Wert normal. Hat jemand schon mal das Phänomen gehabt und eine Lösung gefunden?
von Bedeutung vielleicht noch (Umfang was in der Datenbank verwaltet wird):
verbaute SSD: Samsung SSD 860 EVO 500 GB
jlawyer-dump.sql hat eine Größe von 11.470 KB
3.764 Akten, 1.413 im Archiv, 4.682 Adressen, 75.232 DokumenteBeste Grüße
Christian
Hallo Christian,
bei einer 11 MB großen Datenbank ist es nicht plausibel, dass 280 MB pro Sekunde(!) gelesen/geschrieben werden. Da ist irgendetwas im Argen. Ein paar Ansätze:
- Kannst Du mal schauen welche Dateien in C:\ProgramData\MySQL\MySQL Server 5.7\Data existieren und wie groß diese sind?
- Bleibt die Last so hoch, wenn alle Clients geschlossen sind?
- Habt Ihr mal den j-lawyer.org Serverdienst gestoppt und dann den MySQL-Dienst neu gestartet?
Grüße,
Jens
(j-lawyer.org)Zu den Fragen:
Diesen „Data“-Ordner gibt es in meiner Installation MySQL Server 5.7 gar nicht. Hier sind nur die Unterverzeichnisse bin, docs, include, lib und share.
Serverdienste stoppen und starten bringt keine Veränderung. Systemneustart bringt auch keine Veränderung.
Antivirensoftware ist auf dem Rechner mit der J-Lawyser-Server-Installation nicht vorhanden, nur die Firewall von ZoneAlarm. Auf den ganzen Rechnern, auf denen die Clients laufen, sind Antivirus-Programme installiert, da habe ich aber derzeit keinen Überblick was überall genau (3 verschiedene Standorte). An dem Standort hier ist überall auf den Client-Rechnern Avira-FreeAV zusätzlich installiert. Das wird an den anderen Standorten auch so sein.
Die Mittagspause haben wir mal genutzt und alle Clients zu schließen. Dann sieht das ganze so aus:
Wir verwenden folgende Versionen:
Serverversion: 1.12.0.10
Clientversion: 1.12.0.9Diesen „Data“-Ordner gibt es in meiner Installation MySQL Server 5.7 gar nicht.
Wurde aus Versehen in den „Programme“ statt „ProgramData“-Ordner geschaut? (ProgramData ist auf einigen Windowsinstallationen ein versteckter Ordner).
Die Mittagspause haben wir mal genutzt und alle Clients zu schließen. Dann sieht das ganze so aus:
Okay, dann kommt die Last also von den Arbeitsplätzen.
Ich könnte genau beschreiben wie weiter analysiert wird, das wird aber etwas technisch. Oder wir machen einen Fernwartungstermin.
Falls selbständig weiter geschaut werden soll, hier eine erste Bitte (der j-lawyer.org Client sollte auf den Arbeitsplätzen dafür geöffnet sein und die hohe Last auf dem Server zu beobachten sein):
– Eingabeaufforderung öffnen
– mysql -u root -p
– Datenbankpasswort eingeben
– show full processlist; (Semikolon am Ende nicht vergessen)
– Ausgabe des letzten Kommandos an die E-Mail im Impressum senden.Grüße,
Jens
(j-lawyer.org)Ok da war ich vorhin im falschen Ordner.
Am Montag – wenn alle wieder auf das System zugreifen – mache ich mal mit den weiteren Schritten weiter.
Beste Grüße
Christian
Hallo und guten Tag,
wie ich das gerade lese, möchte ich auch meinen Senf dazugeben:
Der j-lawyer-Server läuft auf einem Windows Homeserver 2011 (Name: WHS2011). Nach meiner Urlaubsrückkehr am Mittwoch habe ich im Verzeichnis
c:\Users\All Users\MySQL\MySQL Server 5.7\Data\
eine Datei
WHS2011.log
mit einer Größe von 33 GB (Gigabyte) (!) gefunden. Da ich keine weiteren Anwendungen mit SQL nutze, konnte ich mir das nur mit einem Fehler im Dateisystem erklären. Ich habe dann den j-lawyer-Dienst und den SQL-Dienst beendet, die Datei gelöscht und SQL und j-lawyer wieder gestartet.
Zunächst wollte j-lawyer dann den Server nicht mehr finden (Schreck!!), nach einem Neustart und etwas Abwarten läuft die Sache wieder.
Jetzt ist die Log-Datei (wohl von mysql) neu erstellt und 44.772 byte (also ca. 45 kb) groß.
Dafür scheinen sich da andere Dateien zu entwickeln:
ibdata1. (ohen Endung), ca. 79 MB
ib_logfile0. ca. 50 MB
ib_logfile1. ca. 50 MBDas scheint sich aber in Grenzen zu halten …
Kann ich irgendwie helfen?
Gruß
RoVo
Ja, das kann eine Ursache sein. Daher hatte ich auch die Informationen bzgl. der Informationen in dem betroffenen Verzeichnis angefordert.
Ein reines Löschen der Datei ist allerdings nicht empfohlen.
Grüße,
Jens
(j-lawyer.org)@Christian danke für das Bild mit den Dateien. Ja, es scheint als sei das sogenannte „MySQL General Log“ aktiviert. Bitte wie folgt vorgehen:
Datensicherung machen – prüfen ob der Dump der Datenbank ordentlich generiert wurde.
Eingabeaufforderung öffnen
mysql -u root -p
(Datenbankpasswort eingeben)use mysql;
(Semikolon am Ende nicht vergessen)SET GLOBAL general_log = ‚OFF‘;
(Semikolon am Ende nicht vergessen)quit;
(Semikolon am Ende nicht vergessen)Dann die 97GB große Datei DESKTOP-ETBPVFR umbenennen in DESKTOP-ETBPVFR-alt oder ähnliches
Schauen ob sich die Situation dadurch verbessert. Wenn ja, dann kann die Datei nach zwei Tagen „Karenzzeit“ gelöscht werden. Wenn nicht, nochmal melden.
Grüße,
Jens
(j-lawyer.org)Guten Abend,
mysql -u root -p
(Datenbankpasswort eingeben)[…]
Dann die 97GB große Datei DESKTOP-ETBPVFR umbenennen in DESKTOP-ETBPVFR-alt oder ähnliches
Das habe ich gleich mal gemacht. Wenn es das schon gewesen ist, werden wir das morgen Vormittag gleich sehen, ansonsten probiere ich morgen das mal mit „show full processlist;“ aus.
Beste Grüße
ChristianIch auch. Die WHS2011.log-Datei ist 679 MB groß, sie wächst aber bei Benutzun von j-lawyer nicht.
Nun warte ich mal ein paar Tage und beobachte das Szenario. Wenn sie sich nit bewegt, werde ich die Datei löschen.
Danke für die schnelle kompetente Hilfe !!
Gruß
RoVo
Zu Dokumentation- und Recherchezwecken hier ein paar Stichpunkte zu den Maßnahmen, die ich heute bei Christian durchgeführt habe:
Letztlich lag es in diesem Fall nicht an der großen Logdatei. Die Analyse hat ergeben, dass eine bestimmte Abfrage, die zur Aktualisierung der Desktopansicht regelmäßig und zyklisch ausgeführt wird, eine hohe Last auf dem Datenträger verursachte. Nach dem Ausschlussprinzip konnten verschiedene mögliche Ursachen ausgeschlossen werden (defekte Datenbanktabelle, fehlende Indexe, falsche Optimizer-Einstellungen, …).
Ursächlich war hier eine Einstellung des Datenbankcaches, der in MySQL wie folgt ermittelt werden kann:
show variables like '%innodb_buffer_pool_size%';Das ergab einen Wert von 512 Byte, also praktisch wurde kein Cache genutzt und immer alles von Platte gelesen.
Man kann die Werte für Größe des Caches und aktuelle Nutzung auch wie folgt abfragen:
SHOW ENGINE INNODB STATUS\G(Achtung, sehr umfangreiche Ausgabe)
Dort finden sich dann u.a. diese Ausgaben:---------------------- BUFFER POOL AND MEMORY ---------------------- Buffer pool size 512 Free buffers 0In diesem Fall wurde „nichts frei“ angezeigt.
Der Cache wurde dann mit Hilfe des untenstehenden Befehls auf einen Wert von 128 MB gesetzt:
SET GLOBAL innodb_buffer_pool_size=134217728;Das alles geht „online“, ohne die Datenbank neu zu starten. Wenn man den Wert permanent erhöhen möchte, so muss er zusätzlich in die MySQL-Konfiguration „my.cnf“ eingetragen werden.
Grüße,
Jens
(j-lawyer.org)
- Du musst angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.