Einkauf Bestellung viel langsamer als der Rest

Hallo,
wir haben ein offenbar zunehmendes und deshalb immer lästigeres Problem bei den Einkaufs-Bestellungen. In diesem Modul sind alle Aktionen extrem zäh und langsam. Egal, ob man neue Positionen einfügen, Stückzahlen und Preise ändern oder die Position hoch-/runterschieben möchte, alles dauert mittlerweile zwischen 10 und 15 Sekunden, bis CAO die Änderungen übernimmt und man die nächste Bearbeitung vornehmen kann. Klingt erstmal wenig, aber wenn man 5 Positionen anfässt, ist eine Minute rum. DB-Maintenance bringt leider keine Verbesserung.
Alle anderen Vorgänge, egal ob Angebote, Rechnungen oder Lieferscheine arbeiten dagegen fast völlig verzögerungsfrei. Ich bin ratlos, woran kann das liegen?

Hallo,
möglicherweise ist ein Index defekt?
DB-Reorg?
DB sichern und rücksichern?

DB-Maintenance mit Prüfen, und optmieren habe ich wie gesagt bereits gemacht. Da wurde nichts bemängelt. Und Sichern und Rücksichern dürfte eigentlich nichts ändern, die Datenbank ist ja nicht kaputt, es funktioniert doch alles fehlerfrei. Nur stellenweise halt etwas langsam.

Wieviele Einträge sind denn in den Tabellen EKBESTELL und EKBESTELLPOS?

DB-Maintenance mit Prüfen, und optmieren habe ich wie gesagt bereits gemacht. Da wurde nichts bemängelt. Und Sichern und Rücksichern dürfte eigentlich nichts ändern, die Datenbank ist ja nicht kaputt, es funktioniert doch alles fehlerfrei. Nur stellenweise halt etwas langsam.

Ich hatte mal ein Performanceproblem bei einer Kasse.
Sichern/Rücksichern hat das Problem behoben.

Bin nicht ganz sicher, aber:
- Sichern sichert nur die Tabellen
- Rücksichern stellt die Tabellen wieder her und macht die Indizes neu
Wenn nun ein Index gefehlt haben sollte oder defekt war, wird er neu erstellt.

Dies nur als meine persönliche unmaßgebliche Meinung.
Wenns anders sein sollte, bitte sagen!

Index hin oder her (natürlich seeeehr wichtig). Meist liegt es an der Config des MariaDB bzw. MySQL Servers.
Bei größeren Datenbanken kann man einen gewaltigen Schub erlangen wenn die Variablen key_buffer_size und table_cache angepasst werden.
key_buffer_size ist m.E nach die wichtigere. Laut Manual sollen 25-50% des verfügbaren Arbeitsspeichers darauf zugewiesen werden.
Meist hat so ein Server allerdings noch was anderes zu tun. Der Defaultwert von 8 Mb ist aber viel zu klein.

key_buffer_size = 256M

sollte für´s erste reichen. Auch join_buffer_size könnte man mal verdoppeln.

Es kommt aber auf meinen vorherigen Post an. Sollten da 1000 EkBestellungen drin sein, macht das kaum einen unterschied.

Die EKBESTELL hat 15676 und die EKBESTELL_POS 39424 Zeilen. Ich habe jetzt sowohl eine Sicherung/Rücksicherung gemacht als auch die Key Buffer Size auf 256 MB (war 16) erhöht. Werde morgen berichten, ob sich die Kollegen noch beklagen.

Die EKBESTELL hat 15676 und die EKBESTELL_POS 39424 Zeilen.

Ok, das ist "nicht viel".
Wir warten trotzdem mal ab was die Erhöhung der key_buffer_size bringt.

Tja, hat leider alles nichts gebracht. Die Kollegin, die bei uns den Einkauf macht, meinte, es sei genauso langsam wie vorher.
Könnte es was mit den Bestellvorschlägen zu tun haben? Die nutzen wir nicht und wenn ich wüsste wo, würde ich die einfach mal abschalten um zu sehen, ob das was bewirkt.

Gibt es denn Bestellvorschläge in der Liste unter den Positionen?

Ach ja. Bitte darauf achten, dass im Menü unter Modul->SQL Log der "aktiv" Haken nicht gesetzt ist.

Bei den Bestellvorschlägen steht immer alles mögliche, in der Regel ist die Liste voll. Wenn man den Haken bei "Nur verkaufte Artikel" setzt, wird sie etwas kürzer, aber gefüllt ist die Liste immer. Allerdings variiert es je nach gewähltem Lieferanten. Besonders viel steht halt bei denen, wo ich regelmäßig den Warenkorb importiere, der ja aber auch >100000 Artikel umfasst. Nutzen tun wir die Funktion halt gar nicht, deshalb die Frage, ob man das nicht abschalten kann.
SQL-Log ist aktuell und normalerweise immer aus. Ich hatte es einmal mitlaufen lassen, es zeigt mir einige ellenlange SQL-Abfragen, wenn ich z.B,. eine Stückzahl in der Einkaufsbestellung ändere. Aber nichts, was ich eindeutig als Ursache der Verzögerungen identifizieren könnte.

Ok, jetzt fällt mir ohne die Datenbank zu sehen nicht mehr viel ein.
Über z.B HeidiSQL lässt sich die Datenbankstruktur exportieren, bzw. einfach mal von EKBESTELL und EKBESTELLLPOS einen Screenshot von dem Indexreiter machen.

Gleichzeitig bitte mal die die Befehle

Code: Alles auswählen

select @@table_open_cache;

und

Code: Alles auswählen

show global status like 'opened_tables';

eingeben und das Ergebnis mitteilen. Wenn wir dort nichts sehen, müssten wir uns mal per Teamviewer und einem Telefonat verabreden.

P.S Die Bestellvorschläge lassen sich nicht einfach abschalten. Das könnte man mal als Featurewunsch aufnehmen. Ich denke aber nicht, dass es daran liegt. Ich kenne wesentlich größere Installationen wo dieses Problem nicht auftritt. JA, es wird über die Jahre zäher, aber wir reden von 0,2-0,5 Sekunden und nicht von 10.

Die Screenshots sind im Anhang.
@@table_open_cache bringt 64 und Opened_tables 358

hth

Stop. table_open_cache ist 64 ???

Im Standard ist das 2000 seit MariaDB 10.1.7. vorher war es 400.

Das sagt eigentlich aus, das 358 Tabellen geöffnet sind under Cache nur für 64 geschaltet wurde.
Erhöhe mal table_open_cache auf 500.

Die Indexe sehen so gut aus.

Ach ja open_files_limit muss größer sein als table_open_cache
Merk dir mal den vorherigen Wert. Es geht sich nur um´s Testen. Wird es dadurch besser oder nicht. Sonst bitte wieder zurück ändern.

Wenn es die Zeit zulässt würde ich auch noch folgendes Probieren.

Lokal auf einem PC die MariaDB aus dem CAO-Faktura Download installieren und darin eine Datensicherung des aktuellen Mandanten einspielen. Tritt das Problem dort auch auf?

open_files_limit war bereits auf 1024 eingestellt, ich habe den Wert für table_open_cache auf 500 eingestellt, die Kollegin testet gerade.
Mir ist aufgefallen, dass Werte, die ich in PHPMyAdmin setze, einen Serverneustart nicht überstehen. Ich hatte vorige Woche die Key_buffer_size testweise von 256 auf 512 erhöht, nach einem Serverneustart war sie wieder auf 256. Muss ich die Variablen vielleicht irgendwo anders ändern (wo?), damit das wirkt?

Also mit table_open_cache 500 wird es etwas schneller, Änderungen an Stückzahlen oder Preisen dauern jetzt "nur" noch ca. 5 Sekunden statt 10-15. Das ist zwar immer noch mehr, als z.B. bei Rechnungen oder Angeboten, aber halbwegs erträglich.
in der etc/my.cnf hab ich mal den Wert auf 2000 gesetzt und open_files_limit=5000 hinzugefügt. Aber trotz Serverneustart werden in phpMyAdmin andere Werte angezeigt. Anscheinend liest MariaDB die Werte aus einer anderen my.cnf, das muss ich mal noch rauskriegen.

In phpmyadmin oder sonstigen Tools ändert man nur die laufende Session. Solche Werte "muss" man in der my.cnf anpassen und den Dienst (MySQL bzw MariaDB) dann neu starten.
Im schlimmsten Fall (und den vermute ich gerade) wird per phpmyadmin nur die Session des derzeit laufenden Clients geändert (also der von phpmyadmin selbst).
Das hilft CAO natürlich gar nicht. Am einfachsten prüft man das im CAO-Admin unter DB-Status->Server Variablen. Das sind die Werte die für CAO relevant sind.

Hallo ICAD55,

hier solltest Du alles finden :

https://mariadb.com/kb/en/library/confi ... ion-files/