Frederik Hantke
Moin!
in den letzten Monaten bemerken wir, dass wir bei den Rechnern am Empfang 2x pro Tag manuell die lokale Datenbank löschen müssen, da sonst Tomedo extrem langsam wird. Nach dem Löschen flutscht es wieder super, aber je mehr Patienten am Tag durchlaufen (und das sind sicher mit Email, Anmeldung und Telefonaten rund 150-200 pro Halbtag), desto langsamer wird es.
Das Selbe passiert, wenn man Rechnungen erstellt. Die ersten 80-100 gehen flott, dann wird es extrem langsam...
1. kann sich das Entwicklerteam diesem Problem annehmen, damit man wieder zumindest einen vollen Tag speditiv arbeiten kann und die Rechnungen nicht ewig brauchen?
2. kann ich die Defragmentierung auf bestimmte Uhrzeiten 2x (einmal würde ja mit dem Gute Nacht Modus gehen) laufen lassen? Habe nun beim Intervall 0,5 (ist hier eigentlich Komma oder Dezimal nötig?) eingegeben. Whs. wird dies dann aber mitten im Betrieb laufen, anstatt programmiert während der Randzeiten...
Philipp Siebrasse
Das Problem ist in unerer Praxis auch vorhanden und stört massiv den Ablauf!
Andreas Cepin
Haben Sie am Server ausreichend RAM für tomedo eingestellt?
Frederik Hantke
Also bei uns (M1 mit 16 GB RAM) ist min. 4096 und max. 8192 eingestellt.
Die Clients sind auf M2 mit 24 GB RAM...
Andreas Cepin
Falls der Rechner ausreichend RAM hat, würde ich mal probeweise die Einstellung erhöhen.
Aber vielleicht hat jemand anderes noch eine Idee, woran es liegen könnte?
Frederik Hantke
Ich würde das Problem jetzt nicht am Server suchen, sondern an den Client-Settings (die man aber nicht in dieser Art einstellen kann), da es ja immer die jeweils lokale Datenbank betrifft.
Andreas Cepin
vielleicht hilft es die PDF-Umwandlung auf dem Server zu erledigen?
Stand die Tage in einem anderen Thema. Die Umwandlung am Server ist schneller, hat aber die Begrenzung auf neun Seiten.
Frederik Hantke
Nein, es geht hier um die grundsätzliche Bedienung von Tomedo. Egal was man macht, sobald man eine gewisse Menge an Patienten einfach nur geöffnet hat und in die lokale DB gespeichert werden, gehen die Clients in die Knie.
Das hat nichts mit PDF oder Server Settings zu tun.
PS: nein, die Client SSD ist nicht voll, denn von 500 GB sind 366 GB noch frei...
csikystrauss
+1
Frederik Hantke
Passiert übrigens auch auf einem M4 Max mit 64 GB Ram...
Ravil Rubashkin
Hallo,
auf meinem Server ist 192 Gb Ram installilert, allerdings, egal, was ich in dem Feld eingebe, sieht Tomedo "nur" 47 Gb Ram. In meinen Augen sinnlose Einstellung mit Wirkung auf Nix.
Gruß
Oliver Hartmann
Verstehe ich das richtig?: Der Server ist ein M1 mit 16GB Ram? Dies wäre tatsächlich etwas knapp für die immer komplexer werdenden Anwendungen.
Wir hatten diese Problem ebensfalls bei einigen Kunden und haben folgende Lösungsstrategie erarbeitet:
- Welche Endpoint Security verwenden Sie? Teilweise sind besondere Einstellungen notwendig die immer mal an aktuelle Gegebenheiten angepasst werden müssen
- Wie hier bereits erwähnt mehr Speicher für die tomedo-Anwendung auf dem Server einstellen
- noch wichtiger: den Speicher in den Java Einstellungen in den Server Tools möglichst großzügig zuteilen
- auf dem Server keinen tomedo Client starten/betreiben, wenn es nicht zwingend erforderlich ist. Nach kurzer Nutzung wieder schließen
- in den Systemeinstellungen Apple bei Netzwerk das Tracking der IP Adressen deaktivieren (gerade hier lauft der Cache voll und zeigt das von Ihnen genannte Fehlerbild)
Viel Erfolg
Frederik Hantke
Ich glaube, wir reden hier aneinander vorbei: ich spreche die ganze Zeit vom Client, nicht vom Server.
Die jeweilige lokale Datenbank eines jeden einzelnen Clients läuft über den halben Tag randvoll und muss dann immer manell gelöscht werden, damit man wieder vernünftig arbeiten kann. Der Server läuft soweit ohne Probleme im grünen Bereich.
PS: wenn jemand seinen Tomedo Server optimieren will, habe ich z.B. hier einen Tipp gegeben.
Oliver Hartmann
Ich hatte Sie schon verstanden. Einige EInstellungen sind am Serverm einige am Client zu treffen. Siehe oben. Dies hat die Performance bei unseren Kunden wieder massiv verbessert.
Das Löschen der lokalen DB behebt es ja nur temporär. Starten Sie stattdessen einmnal den Client durch ohne vorher die lokale DB zu löschen um den Fehler einzugrenzen.
Wollte nur helfen und Ihnen erklären, was bei unseren Kunden geholfen hat. Da nur einige wenige betroffen sind ist es wohl kein genereller Fehler in tomedo und die Entwickler können da nicht aktiv werden.
Das Zusammentragen alle obiger Tipps plus die umfangreichen Einstellungen in der Sophos Endpoint Security, die wir bei unseren kunden einsetzen, hat viel Zeit und Recherche gekostet und es waren etliche Personen daran beteiligt. Wir haben keine Probleme mehr.
Frederik Hantke
Ich möchte nicht sagen, dass Ihre Anregungen schlecht sind, jedoch leider nicht das Thema adressieren.
1. Wir nutzen kein Sophos Endpoint Security
2. Die IP-Adressen-Tracking Beschränkung ist nicht aktiv
3. der Server hat keine nennenswerten Probleme. WENN, dann müsste dies dann ja alle Clients gleichzeitig betreffen und nicht nur die, die viel im Einsatz sind. Und das Löschen der lokalen Client DB würde nichts bringen, da das Problem am Server läge.
4. Tomedo Client am Server ist stets geschlossen. Auch das Tomedo Server Fenster.
5. ich habe nun die RAM-Settings am Server geändert, erwarte aber keine grossartige Verbesserung am Client...
Oliver Hartmann
Ich versichere Ihnen wir hatten das gleiche Fehlerbild bei diversen Kunden. Es ließ sich durch obige Einstellungen vollständig beheben. Es ist eben ein Zusammenspiel mehrerer Faktoren im Netzwerk. Der Speicher am Server alleine wird dieses Problem natürlich nicht lösen, hilft aber bei der Gesamtperformance. Die Einstellunen am Client sind genauso wichtig. Hier lief eben der Cache bem Tracking der IP Adressen voll und Sophos war von Haus aus etwas zu "sicher/streng" und brauchte Ausnahmen. Wenn Sie eine andere Endpoint Lösung verwenden können Sie dies ja trotzdem mal testen. Einige verwendete Tools werden schnell als verdächtiges Verhaltene eingestuft. Dies natürlich eben erst bei wachsender Nutzung. Nach jeder Änderung dauerte es um den Fehler erneut zu provozieren bis Erfolg gemeldet werden konnte.
Johannes Reichelt
Danke für den Tipp, bei mir kann ich diese Einstellung des RAMs am Server nicht vornehmen.
Erweiterte Einstellungen (nur angemeldet einsehbar) Weitere Einstellungen sind nach Anmeldung als Nutzer mit Admin-Rechten sichtbar. Änderungen können nur durch einen zollsoft Nutzer durchgeführt werde
Andreas Reinhardt
Nur eine Korrektur - für den TomedoServer sind diese Einstellungen relevant für die Speicherverwaltung
Bitte auch beachten: Der „minimale RAM“ ist eher Kosmetik; entscheidend ist der „maximale RAM“ – den nutzt der Tomedo-Server im Zweifel auch. Sofern mehr als nur der Tomedo-Server auf dem System läuft, sollte diese Einstellung wohlüberlegt gewählt werden. Standardmäßig vergeben wir bei Neuinstallationen immer „mindestens 8 GB“ oder 50 % des physisch verfügbaren RAM.
viele Grüße
Andreas Reinhardt
PS.: die Einstellungen die oben (in der ersten Antwort auf diesen Post) genannt wurden sind für alle Java Programme, die im Rahmen des TomedoServer separat gestartet werden (Vacuum der Datenbank, HZV Updater) - normalerweise muss da niemand etwas anpassen.
Frederik Hantke
Aktueller Stand: keine Lösung vorhanden.
Workaround: Clients müssen nach 0.5 Tagen die Datenbank bereinigen lassen.
How-To: Als Admin: tomedo -> Einstellungen -> Arbeitsplatz -> Sonstiges -> Datenbank Defragmentiertung auf 0.5 bzw. 0,5 oder noch kleiner setzen. Damit kommt dann sicher 1x/Tag die Defragmentierungsabfrage.
Frederik Hantke
Ich habe nun am Donnerstag mal unseren Tomedo Server flott (TimeMachine und Zollsofts sehr aufgeräumte Programmierweise ohne viel externer Zusatz-Schnickschnack sei Dank) mal auf einen Mac Studio mit 64 GB RAM umgezogen. Hier die viel diskutierten Server RAM Settings auf 8192 MB bis 48128 MB eingestellt. Gemäss Aktivitätsanzeige liegt die physische Speicherlast bei 24.22 GB, was noch weit unterhalb der 64 GB verfügbaren Grezen liegt.
Am Ende: NULL EFFEKT!
Bereits am Freitag gegen 11:00 waren die Clients nach zahlreichen Patientenaufrufen (war halt Freitag) inklusive meines eigenen (Mac Mini M4 Pro mit 48 GB RAM) Arbeitsplatz dermassen lahm, dass ich noch vor der Mittagspause (hier laufen ja die "Gute-Nacht" Defragmentierungen) die Notbremse (aka manuell lokale Datenbank löschen) ziehen musste.
Anschliessend ging wieder alles flott, aber das oben von mir beschriebene Eingangsproblem besteht weiterhin.
Nochmals: Ich sehe das Problem liegt darin begründet, dass die lokale Datenbank nach einigen Patienten dermassen voll ist, dass die Abfragen extrem lahm werden und die Clients super langsam werden.
