Access blockiert kompl. Terminalserver
Axel Gruber
Wir arbeiten hier mit einer Datenbank auf einem Terminal-SERVER. Maximal
sind
15 Benutzer Online.
Normalerweise klappt das prima- nur hin und wieder bekomm ich anrufe, dass
alles
"furchbar langsam wird" - eine Recherche bestätigt dann meine Befürchtung:
Access (ein Access eines angemeldeten benutzers) benötigt 99% der CPU-Power
des gesamten TS.
Nach einer weiteren Recherche konnte ich folgendes feststellen:
Der Benutzer hatte gerade eine Abfrage offen und links unten stand noch
"Berechnung läuft"
Obwohl die Berechnung längst fertig war und der USER eigendlich nichts
machte.
Dieser Fehler läst sich auch nicht reproduzieren - versuche, die gleiche
Abfrage zu öffnen
zu scrollen, usw... führten nicht zum gleichen Phänomen.
Hier hilft es auch nichts, den TS-sERVER mit noch mehr CPU-Power
auszustatten, da
dieser Prozess dann auch nur 99% dieser CPU Power benutzten würde.....
Auch MEM ist ausreichend vorhanden (über 2 GB)
Wenn der Benutzer diese "fressende" Abfrage schliesst, oder was anderes
macht, kehrt alles wieder in den normal-Zustand
zurück
Evtl hat von euch noch jemand eine Idee .... - ich bin mit meinem Latein am
ende....
(Ausser ein Board mit 2. CPU aufzurüsten, da ein Prozess immer nur 1 CPU
blockieren kann)
CU
Axel
PS: Access 2000
WTS=WIN2000SERVER
PS˛:
Ein Gedanke war auch, die Prozess-Priorität auf "niedrig" zu setzten, dann
kann es nicht den gesamten SERVER verlangsamen - nur wie ?
Reinhold Wehrle
"Axel Gruber" <ax...@agm.de> schrieb im Newsbeitrag
news:bku645$ne0$1...@online.de...
> Hallo Leute
> Wir arbeiten hier mit einer Datenbank auf einem Terminal-SERVER.
Maximal
> sind
> 15 Benutzer Online.
Dein Problem kommt mir irgendwie bekannt vor. Habe in grauer Vorzeit
auch mal eine
Access (2.0) Applikation auf einem TS laufen gehabt und in etwa die
gleichen
Effekte erlebt. 15 gleichzeitige Benutzer sind IMO je nachdem wie
intensiv die
arbeiten schon recht "happig".
> Normalerweise klappt das prima- nur hin und wieder bekomm ich
anrufe, dass
> alles
> "furchbar langsam wird" - eine Recherche bestätigt dann meine
Befürchtung:
> Access (ein Access eines angemeldeten benutzers) benötigt 99% der
CPU-Power
> des gesamten TS.
>
> Nach einer weiteren Recherche konnte ich folgendes feststellen:
> Der Benutzer hatte gerade eine Abfrage offen und links unten stand
noch
> "Berechnung läuft"
> Obwohl die Berechnung längst fertig war und der USER eigendlich
nichts
> machte.
Genau so ist es bei mir auch gelaufen. Den Grund hab ich nie
rausgefunden.
Vermutung: Irgendwie müllte meine Applikation den Speicher mit der
Zeit zu.
Wahrscheinlich deshalb fanden "meine" Abstürze meist abends statt. ;-)
> Dieser Fehler läst sich auch nicht reproduzieren - versuche, die
gleiche
> Abfrage zu öffnen
> zu scrollen, usw... führten nicht zum gleichen Phänomen.
>
> Hier hilft es auch nichts, den TS-sERVER mit noch mehr CPU-Power
> auszustatten, da
> dieser Prozess dann auch nur 99% dieser CPU Power benutzten
würde.....
>
> Auch MEM ist ausreichend vorhanden (über 2 GB)
>
> Wenn der Benutzer diese "fressende" Abfrage schliesst, oder was
anderes
> macht, kehrt alles wieder in den normal-Zustand
> zurück
Das deutet nun hingegen wieder eher darauf hin, dass mit der Abfrage
etwas nicht
ganz stimmt z.B. eine benutzerdefinierte Funktion, die nicht ganz
"sauber" ist.
Hast Du das schon überprüft? Tritt das Problem immer bei der gleichen
Abfrage auf?
> Evtl hat von euch noch jemand eine Idee .... - ich bin mit meinem
Latein am
> ende....
>
> (Ausser ein Board mit 2. CPU aufzurüsten, da ein Prozess immer nur 1
CPU
> blockieren kann)
>
> CU
> Axel
>
> PS: Access 2000
> WTS=WIN2000SERVER
>
> PS²:
> Ein Gedanke war auch, die Prozess-Priorität auf "niedrig" zu
setzten, dann
> kann es nicht den gesamten SERVER verlangsamen - nur wie ?
Tja mit den Geheimnissen von TS kenn ich mich leider nicht so gut aus.
"Mein" TS-Spezialist konnte mir damals allerdings auch nicht
weiterhelfen.
Meine Lösung:
Ich hab das Frontend und die Access-Runtime lokal auf jedem Client
statt auf
dem TS installiert und das Backend mit den Daten auf einen "normalen"
Server
gestellt. Seither funzte das ganze ziemlich gut und überstand auch Y2K
ohne Probleme.
Seit meinen schlechten Erfahrungen lass ich die Finger von
Access-Anwendungen
auf Terminalservern, vor allem seit ich gehört habe, dass auch andere
relativ
speicherhungrige Applikationen Mühe haben auf einem TS.
Gruss
Holdi
Axel Gruber
Danke für deine Antwort ! - Das mit dem auf den lokalen SERVER legen,
kommt nicht inFrage, da die Nuzer über das Internet (Tunnel) auf
den TS zugreiffen.
> Meine Lösung:
> Ich hab das Frontend und die Access-Runtime lokal auf jedem Client
> statt auf
> dem TS installiert und das Backend mit den Daten auf einen "normalen"
> Server
> gestellt. Seither funzte das ganze ziemlich gut und überstand auch Y2K
> ohne Probleme.
>
Eine Lösung währe sicherlich Citrix - allerdings ist mir das zu teuer.
(15 Benutzer=20er Citrix-Packet=3800Euro).
> Seit meinen schlechten Erfahrungen lass ich die Finger von
> Access-Anwendungen
> auf Terminalservern, vor allem seit ich gehört habe, dass auch andere
> relativ
> speicherhungrige Applikationen Mühe haben auf einem TS.
Ansonsten sind wir eigendlich sehr zufrieden mit dem TS und durch
den Ausbau auf 2GB Hauptspeicher kommt dieser auch ganz gut mit
speicherhungrigen Anwendungen zurecht (z.B.: Access)
Ich werd mir die Abfrage nochmals vornehmen - aber auf den 1. Blick
sehe ich hier nix ungewöhnliches...
Danke trotzdem.
CU
Axel
Martin Behrens
[Performance Probleme von Access und Terminal-Server]
> Eine Lösung währe sicherlich Citrix - allerdings ist mir das zu teuer.
> (15 Benutzer=20er Citrix-Packet=3800Euro).
Die Lösung heißt weniger Citrix sondern eher AppSense Performance Manager.
Martin
Stefan Bunt
> Hallo Leute
>
> Wir arbeiten hier mit einer Datenbank auf einem Terminal-SERVER. Maximal
> sind
> 15 Benutzer Online.
>
> Normalerweise klappt das prima- nur hin und wieder bekomm ich anrufe, dass
> alles
> "furchbar langsam wird" - eine Recherche bestätigt dann meine Befürchtung:
> Access (ein Access eines angemeldeten benutzers) benötigt 99% der
CPU-Power
> des gesamten TS.
Hast Du ACCESS 97 im Einsatz?
Dann ist die 100% Last normal.
Schau mal hier:
http://support.microsoft.com/default.aspx?scid=kb;de;D36071
Gruß
Stefan
Axel Gruber
> Hast Du ACCESS 97 im Einsatz?
> Dann ist die 100% Last normal.
Nein - A00
> Schau mal hier:
> http://support.microsoft.com/default.aspx?scid=kb;de;D36071
Hmm -. kann ich mir nicht vorstellen, da es 1. A00 ist und 2. laut Artikel
nicht 100% CPU benutzt werden, sondern nur die Anzeige falsch ist - hier
werden aber
wirklich 99% CPU-Power benutzt - und dies ohne grund !
CU
Axel
Axel Gruber
> Die Lösung heißt weniger Citrix sondern eher AppSense Performance Manager.
Ah - hoert sich interessant an :-)
Ich werd mal Googlen ....
CU
Axel
Stefan Bunt
> 2. laut Artikel nicht 100% CPU benutzt werden, sondern nur die
> Anzeige falsch ist - hier werden aber wirklich 99% CPU-Power
> benutzt - und dies ohne grund !
Hier mal ein kleiner Haufen Fragen:
- wie sieht die Aufteilung FE/BE aus? SQL- oder Fileserver?
- bei SQL Server: was sagt dessen Monitor?
- was sagt der Netzwerkmonitor?
- was wird genau ausgeführt (z.B. read und update parallel)
- wie sind die Datensatzsperren eingerichtet?
Gruß
Stefan
Axel Gruber
> Hier mal ein kleiner Haufen Fragen:
> - wie sieht die Aufteilung FE/BE aus? SQL- oder Fileserver?
Garnix - Fileserver ohne SQL - alle greiffen auf die gleiche MDB zu.
> - bei SQL Server: was sagt dessen Monitor?
siehe oben.
> - was sagt der Netzwerkmonitor?
nix (keine ausergewöhnliche Belastung)
> - was wird genau ausgeführt (z.B. read und update parallel)
read (Abfrage mehrer Tabellen)
> - wie sind die Datensatzsperren eingerichtet?
Ähmmm - sorry - ich nix wissen :-) Ich hab nix geändert also ist es so wie
default.
CU
Axel
PS: Es passiert auch sehr selten - jetzt schon 2 Wochen nicht mehr - aber
irgendwann passierts dann wieder..... Es währ ja auch nicht schlim, wenn
Access nur z.b.: 80% Cpu für diesen
User schnappt - dann würden wenigstens die anderen Prozesse noch ein wenig
Luft haben - aber
es schnappt sich wirklich die volle CPU (99%) womit eben alles "fast steht"
und die RDP-Verbindungen aufgrund des hohen Delay´s abbrechen.