| chat.freenode.net #tryton.de log beginning Wed Oct 9 00:00:02 CEST 2013 | ||
| 2013-10-09 09:50 -!- scrapper(~scrapper@88.117.159.6) has left #tryton.de | ||
| 2013-10-09 14:43 <scrapper> moin liebe leute, ich betreibe trytond mittels postgresql datenbank auf ubuntu server 10.04 _ alles läuft super! (nur langsam) egal was ich mache und auch bei postgresql konfigurationen einstelle - von meinen mehr als 3000MB RAM werden nur etwas mehr als 200MB verwendet. hat jemand ähnliche Erfahrungen gemacht und kann mir einen Tipp geben woran das liegen könnte? Wenn jeder *** von der HDD gelesen werden muss ist das schon extrem langsam. Trytond v | ||
| 2013-10-09 14:43 <scrapper> ersion 2.2.0 - Datensicherheit ist mir nicht großartig wichtig, da wir jede Nacht Backups erstellen und im worstcase mit einem Tag Datenverlust leben könnten... | ||
| 2013-10-09 15:45 <scrapper> für mich wär das nicht so das große Problem... ich nütze die Pausen während dem Warten auf die HDD (CPU meist unausgelastet) für andere Überlegungen... das Problem ist meine Mitarbeiter werden schön langsam etwas ungemütlich weil sie auf Grund des langsamen Systems unentspannt werden :D | ||
| 2013-10-09 15:45 <scrapper> keine Ahnung wie ich Tryton dazu überreden kann mehr RAM zu verwenden :-) | ||
| 2013-10-09 15:49 <corro> scrapper: Tryton ist sehr sparsam mit Arbeitsspeicher, die Erfahrung habe ich auch gemacht. Das ist eigentlich eine gute Sache! Deine Performanceprobleme haben wahrscheinlich keinen Zusammenhang mit dem Arbeitsspeicherverbrauch, jedenfalls ist mir noch nie solch ein Fall untergekommen. | ||
| 2013-10-09 15:50 <corro> scrapper: Meist sind es rechenintensive Operationen die Tryton langsam machen, daher überrascht mich deine Aussage, dass die CPU nicht belastet wird. | ||
| 2013-10-09 15:53 <corro> scrapper: Ausserdem sind meistens einzelne Module schuld an Performanceproblemen. Welche Module verwendest du (grob)? Hast du inoffizielle Module installiert? Bei welchen Vorgängen macht sich das Problem bemerkbar? | ||
| 2013-10-09 15:53 <scrapper> corro: ich überwache die Ausführung der Arbeiten am Tryton-Server (trytond) via des Programms "htop" natürlich springt die CPU kurz mal rauf... aber ein großteil der Wartezeit besteht aus dem Warten der Daten von der HardDisk. RAM ist nur bei ca. 200MB (das ist das System selbst) | ||
| 2013-10-09 15:54 <yangoon1> scrapper: wie du selbst schreibst, scheint der falschenhals I/O von der disk zu sein | ||
| 2013-10-09 15:56 <scrapper> corro: ich muss zugeben JA ich habe inoffizielle Module installiert. :-( ... Am stärkstens bemerkbar macht sich die Sache wenn ich "Kontenplan öffnen" für ein ganzes Jahr ausführe... dauer ca. 5Minuten. ok klar hab ich einige hundert Moves. Aber bei meiner kleinen Firma sollte das trotzdem schneller gehen. | ||
| 2013-10-09 15:58 <scrapper> yangoon1: naja es ist ein Raid 5 auf einem HP ML350 Server. Vor zwei Wochen lief das ganze noch auf einem Uralt-System. Die Performance am "neuen" Server ist nicht viel besser. Grund RAM wird nicht verwendet... vielleicht liegts an meinem account_at Modul :-( | ||
| 2013-10-09 16:01 <scrapper> jetzt bitte nicht lachen, dass mein "neuer" Server ein "alter" HP ML350 ist :D | ||
| 2013-10-09 16:04 <corro> scrapper: Ich kenne htop zu wenig, wo siehst du wieviel Zeit auf I/O gewartet wird? | ||
| 2013-10-09 16:07 <scrapper> corro: du hast Recht, das war nur eine Vermutung wenn eine Abfrage extrem lange läuft 30Sek bis 5Minuten und ich sehe dass die CPU Auslastung großteils gegen 10% oder 0% tendiert und nur manchmal kurz sprunghaft gegen 100% fährt dann aber wieder gegen 10% - 0% dann vermute ich die CPU ist unausgelastet und wartet auf neue Daten zum Verarbeiten... die vermutlich erst von den HDDs ausgelesen werden müssen!? ist nur ne Vermutung :-( | ||
| 2013-10-09 16:12 <corro> scrapper: Nur so zum sicher gehen: Implementiert account_at nur einen österreichischen Kontenplan oder hat das Modul seine Finger sonst noch irgendwo drin? (z.B. eben beim "Kontenplan öffnen") | ||
| 2013-10-09 16:13 <scrapper> corro: was ich schon gemacht habe ist in der postgresql.config datei die werte für "effective_cache_size = 2000MB" usw... erhöht + ubuntu kernel mittels vim /etc/sysctl.conf und sudo sysctl -p das auch zu akzeptieren... dann postgresql neu gestartet. er akzeptiert zwar den erhöhten effective_cache_size ... verwendet ihn aber trotzdem nicht. | ||
| 2013-10-09 16:15 <scrapper> corro: das Modul account_at macht nicht viel... implementiert nur den österreichischen Kontenplan. macht sonst nichts. Großteils nur ein xml-file. | ||
| 2013-10-09 16:16 <scrapper> corro: sonst habe ich noch installiert "Parteien, Dashboard, Zeiterfassung, Verkauf, Einkauf, Währungen, Buchhaltung, Artikel,..." also ne ganze Menge :-) | ||
| 2013-10-09 16:18 <corro> scrapper: Wir hosten Tryton für ca. 20 Kunden die z.T. sehr intensiv damit arbeiten und können PostgreSQL problemlos mit den Standardeinstellungen laufen lassen. Ich vermute daher dass das Problem nicht bei der DB liegt. Der Arbeitsspeicherverbrauch liegt übrigens nicht gross über 1GB total ;) | ||
| 2013-10-09 16:19 <corro> scrapper: Die Modulauswahl tönt nach einer Standardinstallation wenn man wirklich damit arbeiten will. Das sollte eigentlich gut funktionieren. | ||
| 2013-10-09 16:21 <scrapper> Ein Hinweis... wenn ich mittels pgAdmin mich auf die Datenbank direkt verbinde und account_invoice Aufrufe und mir sagen wir die letzten 100 anzeigen lasse... dann dauert das ca. 2Minuten (CPU fast auf 0.7%) ... das heisst Tryton hat damit nichts zu tun... also stimmt mit meiner postgresql etwas nicht... oder ist das normal dass das solange dauert? (Sorry bin kein großer Datenbank-Experte) | ||
| 2013-10-09 16:22 <scrapper> (ich meinte die letzten 100 Rechnungen) "account_invoice" | ||
| 2013-10-09 16:23 <scrapper> vielleicht ist das ja normal, dass das solange dauert... ps war auf meinem "alten!" Rechner ebenfalls Ubuntu-Server 10.04 das selbe Problem. ich dachte es liegt daran, dass der Rechner so alt war... aber am neuen Server jetzt ist es auch nur ein bischen schneller... | ||
| 2013-10-09 16:23 <yangoon1> scrapper: nein, das kannst du so nicht testen | ||
| 2013-10-09 16:23 <yangoon1> das hat miteinander nichts zu tun | ||
| 2013-10-09 16:24 <scrapper> yangoon1: ich will nur ausschließen dass es mit Tryton zu tun hat... ich vermute mit meinem postgresql stimmt etwas nicht. | ||
| 2013-10-09 16:24 <yangoon1> wenn du mit pgadmin die datensätze von account_invoice holst, holt er das report field mit | ||
| 2013-10-09 16:24 <yangoon1> das ist schlicht datenintensiv | ||
| 2013-10-09 16:24 <scrapper> yangoon1: oh das hast du recht... | ||
| 2013-10-09 16:24 <scrapper> yangoon1: das macht sinn! | ||
| 2013-10-09 16:24 <yangoon1> scrapper: speziell die accounting berichte haben schon immer lang gebraucht | ||
| 2013-10-09 16:25 <yangoon1> da wurde auch nochmal einiges optimiert zur 2.8 hin | ||
| 2013-10-09 16:26 <scrapper> yangoon1: Leute ich bedanke mich für Eure Hilfe. Jetzt hab ich was gelernt, dass die fetten Berichte hie auch mitgeholt werden... klar ist das Datenintensiv... dass die Berichte lange dauern stört mich nicht... und Rechnungen schreiben geht am neuen Server eh ziemlich schnell. | ||
| 2013-10-09 16:26 <scrapper> Ich bedanke mich bei Euch beiden für die Hilfe! | ||
| 2013-10-09 16:26 <yangoon1> scrapper: gerne | ||
| 2013-10-09 17:33 -!- scrapper(~scrapper@88.117.159.6) has left #tryton.de | ||
| 2013-10-09 18:59 -!- _droid(~Thunderbi@197.36.144.27) has left #tryton.de | ||
| 2013-10-09 22:04 -!- scrapper(~scrapper@62-46-156-37.adsl.highway.telekom.at) has left #tryton.de |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!