[gnucash-de] Datenbankanbindung und Performance
Andreas Seidel
jack at mellonet.de
Mi Apr 19 12:30:21 EDT 2017
Hallo Christian,
vielen Dank für Deinen Rat.
Das Projekt Mini-Multi-User-gnucash kann ich wohl nicht beginnen.
Dafür sind meine Programmier- und vor allem Datenbankkenntnisse zu
gering.
Frage an die Gruppe: Gibt es ambitionierte Programmierer, die Spaß an
einer Umsetzung hätten? Ich würde mich zumindest zum testen und auch
für Dokumentation bereit erklären.
Aber das eigentliche Problem ist die Performance der Datenbank:
Ich arbeite nun seit ca. einem halben Jahr mit PostgreSQL auf einem
gesonderten Server. Zugegeben, der Server ist nicht der jüngste Rechner
und für solche Anwendungen nicht mehr geeignet. Interessant sind aber
folgende Beobachtungen:
- Die Datenbank beinhaltet in der Zwischenzeit 14MB. Die XML-Datei wahr
nur 2,4 MB groß. So viele neue Buchungen sind da nicht dazugekommen.
Aber man sieht, dass die Datenbank wesentlich mehr Speicherplatz
benötigt.
- Der Start von GnuCash ist nicht wesentlich verzögert gegenüber dem
Start mit XML-Datei. Vielleicht, 0,5 - 1 sec. Das fällt nicht wirklich
ins Gewicht.
- Jede Buchung wird direkt in die Datenbank geschrieben. Man benötigt
also keine weitere Speicherung. Das erleichtert die Arbeit sehr, auch
wenn GnuCash akribisch zwischenspeichert. Da jede Buchung einzeln
gespeichert wird, fällt keinerlei Speicherzeit an. Mich hat eher die
Zwischenspeicherung bei der Eingabe gestört.
- Der Zeitverzug erscheint aktuell nur beim Kontoabruf per HBCI. Mein
Workaround ist daher, dass ich nur Fehlbuchungen in der Abrufmaske neu
zuweise. Ansonsten lasse ich gelbe Buchungen einfach in das
Ausgleichkonto buchen und weise diese Buchungen nach dem Kontoabruf
direkt zu.
Ich versuche das Verhalten beim Kontenabruf noch zu verstehen. Wie kann
es sein, dass Einzelbuchungen so schnell sind, in der Abrufmaske aber
eine halbe Ewigkeit benötigen? Irgendjemand eine Idee?
Grüße,
Andreas
Am Donnerstag, den 19.01.2017, 21:25 +0100 schrieb Christian Stimming:
> Hallo Andreas,
>
> also wenn die Frage nun explizit nach Multi-User-Fähigkeit ist: Nein,
> die ist
> leider weiterhin nicht in naher Zukunft zu erwarten.
>
> Wenn jemand dieses Feature ernsthaft haben will, wäre mein Ratschlag
> folgender: Die SQL-Datenbank von Gnucash ist durchaus ein sinnvolles
> Format
> für die Daten, um die es geht. Aber der Datenbankzugriff von der
> Gnucash-
> Applikation aus ist auf allen Programmcode-Ebenen leider weiterhin
> völlig
> ungeeignet für einen Multi-User-Zugriff. Ich würde daher vorschlagen,
> dass man
> ein neues GUI-Programm beginnt, welches auf die Datenbank zugreift,
> aber den
> Datenbankzugriff selber dabei völlig neu programmiert und dabei die
> Multi-
> User-Fähigkeit auch von vorneherein einplant. Im Sinne einer agilen
> Vorgehensweise sollte es auch durchaus möglich sein ("minimum viable
> product"), relativ schnell eine GUI-Applikation hinzubekommen, die
> die
> Buchungen und den Saldo eines gewünschten Kontos anzeigt und die
> Eingabe neuer
> Buchungen erlaubt - und dabei für Multi-User-Zugriff dann parallele
> Änderungen
> in der Datenbank korrekt berücksichtigt. Gleichzeitig könnte man
> alternierend
> das bisherige Gnucash in vollem Feature-Umfang nutzen, wenn man
> vorhandene
> Features nutzen will, nur dann eben ohne Multi-User-Zugriff. (Das
> entsprechende Locking in der DB wird ja durchaus gesetzt, wenn
> gnucash
> gestartet wird.) Auf diese Weise könnte man mit einem kleinen neuen
> Projekt
> starten, welches Multi-User hat, und dann schrittweise weitere
> Entwickler
> hinzugewinnen und Features ergänzen.
>
> Aber für den ersten Schritt müsste schon jemand ca. 2-4 Wochen
> investieren.
> Ich selber habe dafür zu wenig Anreiz und werde das nicht machen.
> Aber wenn
> das jemand will, wäre das durchaus eine Möglichkeit. Ich würde das
> auch gerne
> mit Rat&Tat, naja eher Rat, unterstützen.
>
> Solange das aber niemand anpackt, gibt es auch aus meiner Sicht
> weiterhin
> eigentlich keinen Vorteil von SQL gegenüber XML und Umstieg auf XML
> wäre wohl
> sinnvoll.
>
> Gruß
> Christian
>
> Am Montag, 16. Januar 2017, 01:14:35 schrieb Andreas Seidel:
> >
> > Hallo Christian,
> >
> > vielen Dank für Deine ehrliche und schnelle Antwort.
> > Sowas hatte ich mir bereits gedacht.
> > Mein SQL-Server ist auf meinem Home-Server. Somit ohne SSH-Tunel.
> > (Siehe Eingangsthread).
> > Die Ladezeit am Anfang hält sich eigentlich noch in Grenzen.
> > Dass GnuCash die Datenbank voll in den Speicher nimmt, erklärt,
> > warum
> > Buchungen sehr schnell funktionieren.
> > Ich verstehe, dass die Datenbankanbindung keine Prio hat, solange
> > noch
> > kein Multi-User-Zugriff möglich ist. Das wäre ja eigentlich der
> > wichtigste Grund für eine Auslagerung auf einen Server. Ist die
> > Implementierung denn prinzipiell geplant? Ansonsten würde ich
> > nämlich
> > auch wieder auf die XML-Datei zurückstellen.
> >
> > Grüße,
> > Andreas
> >
> > Am Sonntag, den 15.01.2017, 22:33 +0100 schrieb Christian Stimming:
> > >
> > > Hallo Andreas,
> > >
> > > mit der Datenhaltung in einer SQL-Datenbank habe ich mal kurz
> > > experimentiert,
> > > benutze in der täglichen Arbeit aber weiterhin nur die XML-
> > > Datei.
> > >
> > > Ist das hier eine Datenbank auf localhost oder ist die woanders,
> > > auf
> > > einem
> > > anderen Rechner im lokalen Netz oder mit etwas mehr Verzögerung
> > > irgendwo im
> > > Internet (über SSH-Tunnel hoffentlich)? Ich hatte mal einen
> > > Server
> > > woanders
> > > via SSH-Tunnel versucht und bin dann bei der Ladezeit beim
> > > Programmstart von
> > > Gnucash vom Glauben abgefallen (wenn auch 1-2 Berichte
> > > ausgewertet
> > > werden) -
> > > das dauerte mir definitiv viel zu lange. Von daher war mein
> > > Zwischenstand,
> > > dass eine etwas größere Datei (200 Konten, 30.000 Transactions /
> > > Buchungssätze) für SQL nicht geeignet ist, außer vielleicht auf
> > > localhost.
> > >
> > > Die Verzögerungen bei den Import-Zuordnungen sind natürlich
> > > ärgerlich. Das ist
> > > schlecht programmiert, eben für den Use Case SQL-Datenbank.
> > > Eigentlich sollte
> > > es machbar sein, dies besser hinzukriegen - aber ich müsste dafür
> > > 4
> > > Stunden am
> > > Code sitzen, und dafür hab ich a) nicht die Zeit, b) nicht die
> > > Lust,
> > > und c)
> > > nicht selber den Leidensdruck, es machen zu müssen... sorry, das
> > > ist
> > > die
> > > ehrhliche Einschätzung.
> > >
> > > Ein Multi-User-Zugriff auf die SQL-Datenbank ist nicht (!)
> > > möglich!
> > > Das würde
> > > nur abwechselnd gehen. Grund: Gnucash benutzt dummerweise das SQL
> > > teilweise
> > > noch immer wie eine Datei, d.h. die Kontenstruktur wird beim
> > > Programmstart
> > > geladen und im Speicher gehalten. Es wird zwar kontinuierlich
> > > gespeichert,
> > > aber es wird eben nicht kontinuierlich geladen, d.h. eine zweite
> > > Programm-
> > > Instanz bekommt die Änderungen nicht mit, die von einer ersten
> > > Programm-
> > > Instanz gespeichert worden wären. Aus diesem Grund bekommt man
> > > (hoffentlich)
> > > auch eine Fehlermeldung, wenn ein zweiter User auf die SQL-
> > > Datenbank
> > > zugreift,
> > > solange noch ein erster User drin ist.
> > >
> > > Da ist gnucash also leider weiterhin noch lange kein Multi-User-
> > > Programm.
> > > Sorry.
> > >
> > > Gruß
> > >
> > > Christian
> > >
> > > Am Sonntag, 15. Januar 2017, 15:27:48 schrieb Andreas Seidel:
> > > >
> > > > Hallo Zusammen,
> > > >
> > > > schade, dass es in der Mailingliste bisher keine Antwort zu dem
> > > > Thema
> > > > SQL-Anbindung gibt. Ich habe in der Zwischenzeit folgende
> > > > Beobachtung
> > > > machen können:
> > > >
> > > > 1. Eine einfache Buchung in GnuCash benötigt kaum Server-
> > > > Performance.
> > > > Das funktioniert sehr gut. Man muss nicht mehr speichern, da
> > > > das
> > > > die
> > > > Datenbank bei jeder Buchung automatisch tut.
> > > > 2. Die "Abfrage der Kontoumsätze" per HBCI benötigt ungefähr
> > > > die
> > > > gleiche Zeit, wie vorher.
> > > > 3. Bei einer "Saldenabfrage" per HBCI entstehen keine
> > > > zusätzlichen
> > > > Zeitverzüge.
> > > > 4. Während der Anpassung der Kontobuchungen aus "Abfrage der
> > > > Kontoumsätze" mit der eigenen Datenbank entstehen wesentliche
> > > > Verzögerungen während einer Umbuchung. z.B. hat GnuCash eine
> > > > Buchung
> > > > Konto A zugewiesen. Ich möchte, dass die Buchung auf Konto B
> > > > gebucht
> > > > wird. Sobald ich das neue Konto ausgewählt habe, vergehen für
> > > > diese
> > > > Umbuchung ca. 1 Minute.
> > > > 5. Wenn ich "Abfrage der Kontoumsätze" abschließe, werden alle
> > > > Buchung
> > > > in die Datenbank übernommen. Hier kann ich abhängig von der
> > > > Anzahl
> > > > der
> > > > neuen Buchungen zwischen 5 und 15 Minuten warten, bis ich
> > > > GnuCash
> > > > wieder benutzen kann.
> > > >
> > > > Ein Workaround ist aktuell, dass ich Umbuchungen erst nach dem
> > > > Abschluss Eingabemaske "Abfrage der Kontoumsätze" durchführe.
> > > > Aber
> > > > das
> > > > ist ja eigentlich nicht so gewollt und auch unübersichtlich.
> > > > Ich
> > > > weiß
> > > > auch nicht, ob die KI von GnuCash sich dann falsche
> > > > Buchungszuordnungen
> > > > einübt.
> > > > Serverseitig habe ich folgende Optimierungen versucht:
> > > > Anpassen der Speicherbelegung durch Postgresql in
> > > > /etc/postgresql/8.4/main/postgesql.conf
> > > >
> > > > #------------------------------------------------------------
> > > > ----
> > > > ----
> > > > ----------
> > > > # RESOURCE USAGE (except WAL)
> > > > #------------------------------------------------------------
> > > > ----
> > > > ----
> > > > ----------
> > > >
> > > > # - Memory -
> > > >
> > > > shared_buffers = 112MB # min 128kB
> > > > # (change requires
> > > > restart)
> > > > temp_buffers = 8MB # min 800kB
> > > > max_prepared_transactions = 0 # zero disables the
> > > > feature
> > > > # (change requires
> > > > restart)
> > > > #
> > > >
> > > > Evtl. kann man da auch noch mehr Performance rausholen, in dem
> > > > man
> > > > Write ahead oder files per process anhebt.
> > > > Hier erhoffe ich mir mehr Input aus Eurer Erfahrung.
> > > >
> > > > Des Weiteren würde ich gerne mehrere Nutzer auf die Datenbank
> > > > zugreifen
> > > > lassen und auch deren Aktivität loggen. Wie kann ich Benutzern
> > > > Zugriff
> > > > auf die Datenbank gewähren?
> > > >
> > > > Ich hoffe, jemand kann mir hierzu irgendetwas schreiben.
> > > > Vielen Dank im Voraus,
> > > >
> > > > Andreas
> > > >
> > > > Am Freitag, den 30.12.2016, 12:22 +0100 schrieb Andreas Seidel:
> > > > >
> > > > > Hallo Zusammen,
> > > > >
> > > > > Zunächst wünsche ich der Mailingliste einen erfolgreichen
> > > > > Start
> > > > > in
> > > > > das
> > > > > neue Jahr 2017. Auf dass GnuCash in diesem Jahr wieder einen
> > > > > guten
> > > > > Sprung voran macht.
> > > > >
> > > > > Ich benutze GnuCash 2.6.12 auf einem Ubuntu 16.04 LTS Rechner
> > > > > mit
> > > > > einer
> > > > > Datenbankanbindung an eine PostgreSQL-Datenbank 8.4 auf einem
> > > > > Server
> > > > > mit Ubuntu 12.04.5 LTS Server.
> > > > > Ich weiß, die Datenbank und der Server sind nicht mehr
> > > > > aktuell.
> > > > > Trotzdem war ich erstaunt, wie leicht auf die Datenbank
> > > > > umzustellen
> > > > > war.
> > > > > Nun ist mein Server auch nicht mehr der neueste Rechner. Mit
> > > > > einem
> > > > > Pentium 4 2,66GHz erledigt er aber bisher meine Ansprüche
> > > > > ganz
> > > > > ordentlich. Nur bei GnuCash habe ich jetzt ein echtes
> > > > > Performance-
> > > > > Problem. Dadurch, dass ich direkt mit der Datenbank verbunden
> > > > > bin,
> > > > > benötige ich für jede neue Buchung ca. 1 Minute.
> > > > > Wenn ich Online meine Kontoumsätze abrufe, kann das dann
> > > > > schon
> > > > > eine
> > > > > Weile dauern. Gibt es Tricks, um die Performance für den
> > > > > Benutzer
> > > > > zu
> > > > > erhöhen? Evtl. einen Buchungs-Cache, der erst bei Beendigung
> > > > > von
> > > > > GnuCash ausgeführt wird? Oder vielleicht eine Einstellung auf
> > > > > dem
> > > > > PostgreSQL-Server? Ich habe gesehen, dass die Datenbank nur
> > > > > 40% -
> > > > > 60%
> > > > > der CPU auslastet.
> > > > > Im schlimmsten Fall muss ich dann doch wieder filebasiert
> > > > > arbeiten.
> > > > > Da die Vorteile einer Datenbank (Multiuser-fähigkeit) bei
> > > > > GnuCash
> > > > > anscheinend noch nicht implementiert sind, gibt es aktuell eh
> > > > > keinen
> > > > > Grund auf eine Datenbank umzustellen.
> > > > >
> > > > > _______________________________________________
> > > > > gnucash-de mailing list
> > > > > gnucash-de at gnucash.org
> > > > > https://lists.gnucash.org/mailman/listinfo/gnucash-de
--
Mit freundlichen Grüßen,
Andreas Seidel
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.14 (GNU/Linux)
mQGiBD76+vYRBACgpkmwejHTlEz2+xgWhlYDpFOGr0GdbG8zR+yVCBtpRl6gD6EB
qQB8XHiWVNVDZ6VRyvDdD2lcHFeXVs01x1NdFJ7SZV6iEkbaJ5K07+SQw1/g8PlZ
a6/7ivvDkhn//Ir4exEhdR0cIQhY8+flC1ZOzjSX+O5w0HO+gW6GH4xoGwCg4ky8
YXANAxysbZUxtQ0G2AEeOkUD/1zkD5mv49/K+a2haDQsouWVipngdioq4LWoRgK8
sHf8EoYQ9O5w4pvcsE5jbnp+JJlGHBcdX4X69aXeO+NkXOtI7Mzag+2lCtDZxgaF
yWL3lNibLV7ozyeeYWKhHQQPL1Xkgv/DTWkjYWmCTzIfjCWkGobNUPrB/fIdFDdp
sskBA/0ZXuNha6SsKHgdRMobEDJbst/Sor1KjEkdkdIV98EkVu6b8rA4dbH0IFSo
hwsor4RE0UPO9FLw9bmxbXoGggkmMPbswWFLdEFc7jFHxOclb3H+JNzB1cenY9D3
mCmLhgX2DLSqGWVIEBvFMTGfR2YfT7LEjlygdNbh0n5vkJYPG7QhQW5kcmVhcyBT
ZWlkZWwgPGphY2tAbWVsbG9uZXQuZGU+iGUEExECACUCGyMGCwkIBwMCBhUIAgkK
CwQWAgMBAh4BAheABQJM/XSEAhkBAAoJEC7xdPI2uOOQYEkAn37ITp/u8zYZyRVT
KwkM0y5LR269AJwPC0uNKzZh/5qaX1hJXCDF03M6zLQyQW5kcmVhcyBTZWlkZWwg
KEFyY29yLUFjY291bnQpIDxhbnNlMDAwMUBhcmNvci5kZT6IYgQTEQIAIgUCTP10
XQIbIwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQLvF08ja445CqLgCgw5C2
i3CVCcj3wp8FjRdMVx6LBYoAoLqioi27vP4iiw33UGjjuRxNzWatuQENBD76+v4Q
BAC/x5diquj6jZWQ2kTptgWRiOrWCWtwb/NAERrjZkmJ5Hnq0y2lE8B6aYAEJicR
Gef6R2jNeoTnzASBSulVGOEdZX4thcpX8SmfqdDf+M9oJphstJpA0PDzdCfU7Uzv
1o1r6dgMdTInAfJtPfp4X5UZOm0K/Uc0TJeUz3k5TK8aYwADBgQAgh8VRWHM52wM
YgLIwykIkI1uIgDgzUfpHvcUOQWT8KgvN64XMruPgBmYD1AJCouqYlijY6r0QsSq
GoAf7Abtlj4LMb4HtCMtk91BTNVpATSEM+Gst2CLbKf1cfBoRwvoMjvnRq967/TR
/yr/W6kJGqddI6R/QQqsRQi33z6JXmuIRgQYEQIABgUCPvr6/gAKCRAu8XTyNrjj
kCZAAKClcNXgQkSHeMV6SWyQNg0jfVbkJQCbBVd92FSWYzOdg+F2QW62uhkqTKI=
=FgzN
-----END PGP PUBLIC KEY BLOCK-----
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : signature.asc
Dateityp : application/pgp-signature
Dateigröße : 181 bytes
Beschreibung: This is a digitally signed message part
URL : <http://lists.gnucash.org/pipermail/gnucash-de/attachments/20170419/afd92b63/attachment.sig>
Mehr Informationen über die Mailingliste gnucash-de