[gelöst (naja)] Prozessor Peaks sl.exe beim Start dvwin32 - zu viele Clients ?

Hallo Forum.

Wir kämpfen mit hausweiten "chokes" von 1 bis 5 Sekunden (und manchmal totalen Stillstand) des TIC.

Wird ein TIC im Haus gestartet oder geschlossen, gibt es einen solchen Choke mit ~100% CPU Last.

Eckdaten:

David.ZEHN!, latest feature Pack, Win2k3 - ADS MemberServer, 2 3,4er Xeons, 4GB RAM, 2xGb Nic (HT ausgeschaltet)

--~900-- Clients, ca 150 davon Win2k, Rest XP, ca. 100 Clients per Citrix Metaframe aus externen Netzen angebunden,

'Datenlager' im SAN mit 10Gb lokalem FibrechannelControler angebunden

Uns macht eine mit Chokes ausgelastete erste CPU Probleme, auf der der Service Layer (fast) alleine läuft.

Die NICs des Servers sind wegen vermutetem Defekt erneuert worden.

Doch die Problematik scheint im ServiceLayer zu liegen.

Unsere Vermutungen:
SL.exe treibt die CPU auf die Spitze, wenn mehr Anfragen eingehen,
als der Dienst beantworten kann.
Durch dieses Verhalten (hausweit 'steht' die Applikation fuer einige Sekunden)
entsteht ein Rückstau in der Kommunikation. Bald beginnt die Netzwerkkarte, Pakete
zu verwerfen, weil sie von höheren Ebenen keine Reaktion/Abnahme bekommt.
Dieses äussert sich dann in wachsenden Fehlerquotes der Karte.
Eine Direkte Frage zu dieser Überlegung:

Wieviele 'Ohren' hat der Service Layer ?

Keine anderen Werte (PageFaults, NIC_usage, Datenzugriff, DPCs, Interrupts/s, etc) scheinen mit diesen Lastspitzen in direkter Verbindung zu stehen, das Verhältnis Chokes/Pozessorlast zu OpenFileSessions wird zur Zeit noch erörtert.

Ein Filemon-Dump zeigt, die Apllikation sl.exe 'nudelt' ständig auf der herum,

die angegebenen Offsets entsprechen den IOs der Archivinformationen (je 430), doch was macht die SL.EXE da genau ?

Ein 'debuggen' zeigt merkwürdige Einträge, leider bin ich selber nicht in der Lage, das Log richtig zu deuten :

Immer wiederkehrende Einträge (ist das die 'Hängschleife' ?) in der debug_sl.txt:

7392: fwapi.cpp(6400): UserName= (ist WIRKLICH leer)
7392: fwtools.cpp(776): SetUserOnlineCount: OnlineCnt=1
7392: TCPIPDV.CPP(1215): ListenThread: Thread returned from accept
7392: TCPIPDV.CPP(260): ReadThread: ReadThread gestartet
7392: fwapi.cpp(6400): UserName=
7392: fwtools.cpp(776): SetUserOnlineCount: OnlineCnt=1
7392: TCPIPDV.CPP(1215): ListenThread: Thread returned from accept
7392: TCPIPDV.CPP(260): ReadThread: ReadThread gestartet
7392: fwapi.cpp(6400): UserName=
7392: fwtools.cpp(776): SetUserOnlineCount: OnlineCnt=1
7392: TCPIPDV.CPP(1215): ListenThread: Thread returned from accept
7392: TCPIPDV.CPP(260): ReadThread: ReadThread gestartet
7392: fwapi.cpp(6400): UserName=

Seltsam sind auch diese Einträge :

7392: CONTROL.CPP(1472): CheckRXFile: Betreffzeilentexthier sr->FileName=\\SERVER\DAVID\tld\port\extra\007837EB sr->AktLine=0
7392: VERTEIL.CPP(118): CheckNameing sender@fremd.dom
7392: VERTEIL.CPP(920): CheckVerteilung
7392: VERTEIL.CPP(348): FindRoutingRecord: reciepient@myd.dom
7392: NRBUCH.CPP(100): TVer_CmpRec: r1: reciepient@myd.dom
7392: NRBUCH.CPP(101): TVer_CmpRec: R2: 12252
7392: NRBUCH.CPP(100): TVer_CmpRec: r1: reciepient@myd.dom
7392: NRBUCH.CPP(101): TVer_CmpRec: R2: 21247
7392: NRBUCH.CPP(100): TVer_CmpRec: r1: recipient@myd.dom
7392: NRBUCH.CPP(101): TVer_CmpRec: R2: 22151
7392: NRBUCH.CPP(100): TVer_CmpRec: r1: reciepient@myd.dom
7392: NRBUCH.CPP(101): TVer_CmpRec: R2: 22434
7392: NRBUCH.CPP(100): TVer_CmpRec: r1: reciepient@myd.dom

7392: NRBUCH.CPP(101): TVer_CmpRec: R2: 31188
7392: NRBUCH.CPP(100): TVer_CmpRec: r1: reciepient@myd.dom
7392: NRBUCH.CPP(101): TVer_CmpRec: R2: 32143
7392: NRBUCH.CPP(100): TVer_CmpRec: r1: reciepient@myd.dom
7392: NRBUCH.CPP(101): TVer_CmpRec: R2: 32680
7392: NRBUCH.CPP(100): TVer_CmpRec: r1: reciepient@myd.dom
7392: NRBUCH.CPP(101): TVer_CmpRec: R2: 42214
7392: NRBUCH.CPP(100): TVer_CmpRec: r1: reciepient@myd.dom
7392: NRBUCH.CPP(101): TVer_CmpRec: R2: 42222
7392: NRBUCH.CPP(100): TVer_CmpRec: r1: reciepient@myd.dom
7392: NRBUCH.CPP(101): TVer_CmpRec: R2: 42680
7392: VERTEIL.CPP(930): VR.ArchivePath=~E
7392: TCPIPDV.CPP(1215): ListenThread: Thread returned from accept
7392: TCPIPDV.CPP(260): ReadThread: ReadThread gestartet
7392: fwapi.cpp(6400): UserName=
7392: fwtools.cpp(776): SetUserOnlineCount: OnlineCnt=1
......
EDIT: doch habe ich was vergessen :

Zu 7392: NRBUCH.CPP(101): TVer_CmpRec: R2: 42214

bei der 42214 handelt es sich um eine interne Faxnummer, die Nummern

sind im DViSE Admin unter "Verteilregeln" eingetragen,

drei dieser in der Liste auftauchenden Verteilregeln waren mit fehlerhaften Pfade versehen,

der Rest ist okay und funktional. /EDIT

Ich hoffe, keine Info vergessen zu haben, wir sind ein bissl ratlos.

Unser aller Liebling Tobit.Software verkauft 5000 (!!!)er Lizenzen, hat jemand

mal einen DAVID Server mit 5000 Usern gesehen ?

Gruß aus dem Sumpfloch,

Chris

Hallo Forum,

ein Nachtrag : Es zeigt sich, dass ab ca. 600 open Files

die Chokes beginnen, dann stärker werden und ab ca 1300 - 1500 offenen Geschichten

ist wohl wegen der PeakSumme ein Arbeiten kaum mehr möglich, das geht bis zum

Droppen von Paketen und Nichterreichbarkeit des Servers (RDP).

Genauere Werte sind noch nicht definiert.

Anfang nächster Woche folgen noch weitere Test bezüglich VirenScanner unter Last,

vielleicht hat jemand Erfahrungen mit installieren Virenscannern von Framdanbietern

bei David Installationen dieser Grösse ?

Schönes WE Euch allen !

Chris

Hi Chris!

Habt ihr auf dem Archive-System auch noch einen Virenscanner laufen? Den würde ich erfahrungsgemäß ersteinmal aabschalten. David kann einen eigenen Suchlauf machen, der mit der Archive-Bereinigung am Samstag läuft.

Das zweite, was ich versuchen würde, ist die Archive.dir im User-Archive zu reparieren (Arcutil oder ArcRepair von Itacom). Auch wenn die Offsets in der Archive dir stimmen, evtl. stimmt da ein Pfad nicht, der dann den SL stört.

Bzgl. des Debug:
Der erste Teil ist, wenn ich das so richtig interpretiere, das akzeptieren von Verbindungsanfragen.
Der zweite Teil ist einfach nur die Verteilung von Faxen anhand der Verteilregeln.

Gruß

Björn

Hallo Björn ! (..die Welt ist nie gross

Erstmal Danke für Deine Antwort.

Bestimmte (auch vom Hersteller vorgegebenen) Archive sind vom Virenscanner ausgenommen, einen

Windows Server mit 900 Konfigurierten Konten, der SMB und SMTP spricht, ohne Virenscanner zu betreiben

ist natürlich ziemlicher Horror. Wir haben diesbezüglich schon einen Test gemacht, dabei reichte aber die Last nicht aus,

(nicht genügend Sessions, um Aussagen treffen zu können) also werden wir das als nächsten "Task" ansehen.

Verstehe ich Dich richtig, der 'tobit-eigene' AV-Scanner läuft 'nur' zusammen mit der Bereinigung ?

(die läuft übrigends sehr schnell und ohne Probleme)

Die entsprechende user\archiv.dir (auf der auch seltsam viel Zugriffe sind) wurde schon mehrfach geprüft und reparriert,

werde dieses nochmals durchfürhren.

In den Logs (erster Teil) macht mich nur "Username=[leer]" sehtr stutzig. Das tritt sehr häufig auf.

Auch sind das ja auch debug-Logs, die mit einer anderen sl.exe erstellt wurden, aber das ist

ja leider nicht anders möglich.

Momentaner Stand: ca700 Sessions und zwischendurch Peaks bis 100%, ich denke dass er innerhalb der nächsten Stunde die Grätsche macht.

BAUZ !

...es liegt wohl an der server\david\archive\user\archive.dir (oder an Folgefehlern)

Wenn ich diese da wegklaube, läuft alles ohne Chokes !!

Naja... 'fast' alles ... das interne Userhandling ist natürlich dann für'n Popo.

Nachtrag: Habe gerade die archive\user\archive.dir mit arcutil neu erstellt.

Leider noch der gleiche Effekt, es scheint nicht an Fehlern in dieser Datei zu liegen.

Wieso rödelt der SL da SO excessiv drauf herum ?

Gruß,

Chris

Hi Chris!

(Ja, die Welt ist manchmal klein...)

Der Virenscanner von Tobit läuft nur mit der Bereinigung über die Archive, allerdings immer im Grabbingserver und Postman.
Die Performance vom David verbessert sich meisten deutlich, wenn grundsätzlich auf dem gesamten Archivsystem kein weiterer Virenscanner läuft.
(In dem Wissen, dass das alles andere als optimal ist...)

Ok, ich glaube mal die Archive.dir können wir ausschließen...

Der leere Benutzername ist merkwürdig, stimmt, aber mir sagt das im Moment nix...

Gruß

Björn

Hallo,

ich habe gestern ein paar schockierende Antworten bekommen:

Der Server ist für die Anzahl der Clients unterdimensioniert!

4 GB RAM ist zu wenig ! (Für mehr (min. 16MB)brauche ich ein Enterprise-OS und muss neu installieren)

- Für den Normalbetrieb sollten höchstens 40% RAM belegt sein, sonst kann der SL nicht gescheit arbeiten.

Die Fax Ports (4 TLDs - AVM C4) sind SEHR Systemlastig (wegen der Konvertierung) und sollten auf einem dafür eigenen externen Server

eingerichtet werden.

Bei den Clients ist es tödlich, wenn welche mehr als 5.000 Objekte in 'einem' Verzeichnis haben.

- Pro Clientstart sind MINIMUM 256kB RAM auf dem Server belegt

Das sind alles Sachen, die man nicht 'mal eben' realisieren kann.

...ist das wirklich so ?! WO sind denn hier die Leute mit den 'richtig grossen' Installationen ??

...ich möchte doch 'nur' die PEAKS beim TIC Start vom Prozessor runter haben. Zwar ist dieses keine unbedingte Glaubensfrage, ich denke schon, dass er wohl mit diesen Veränderungen 'besser' läuft, aber ist das NÖTIG ??

Versumpfend,

Chris

Hi Chris!

Ok, soviel zum "performanten" ServiceLayer...
"Unterdimensioniert"???

Aber die Ausgkünfte bzgl. der 5000 "Objekte" pro Archive und die Konvertierung sind nicht neu...
Allerdings glaube ich mal, dass es mit "nur" einer C4 laufen sollte. Ich habe ein System im Einsatz, wo 15 TLD auf einem PMX laufen, mit ca. 30000 Faxen / Monat. Dort ist der Server allerdings noch lange nicht am Limit... (Allerdings läuft der nur als "Backend" für einen Exchange-Cluster)

Mehr Ram könnte evtl. helfen, glaube ich aber nicht...

Ist ein UPgrade von Standard auf Enterprise nicht direkt möglich?
Alternativ ist die "Neuinstallation" auch relativ problemlos, wenn man das Archivsystem ausgelagert hat... (Ich würde trotzdem mit allen Mitteln versuchen das Problem anders zu lösen...:-) )

Evtl. ist irgendwo ein Archiv, welches tatsächlich (deutlich) mehr als 5000 Objekte hat, woran er sich aufhängt.

Gruß

Björn

Hallo Björn,

erstmal vielen Dank für Deine Unterstützung und Einschätzungen, wir sind für jeden Strohhalm dankbar

Spitzenreiter ist bei uns ein UserArchive mit 15 GB, 155.000+ Objekte.

Wir werden beginnen, diese UserAccounts sukzessive (hab ich das richtig geschrieben *g*?) vom

Server zu verbannen.

Leider scheint es uns nicht möglich, dieses Verhalten auf irgendeine einzelne Geschichte

herunterzubrechen, es erscheint als kummulatives Lastenproblem.

Ein kurzzeitiger Testbetrieb ohne Virenscanner unter Last zeigt

KEINERLEI Veränderung, am Scanner liegt es als Einzelproblem nicht.

Gruß,
Chris

Hi Chris!

Also 155000 Objekt in einem Archiv ist mit Sicherheit tötlich im Bezug auf die Performance... (Wie groß ist denn da die Archive.dir?)

Die automatische Archivierung ist sicherlich ein probates Mittel, allerdings empfehle ich die nur in Zusammenhang mit vernünftigen Qouta-Einstellungen und "Maßregelung" der Benutzer.
Ich nehme Mal an, die Archvierung der eMail-Inhalte läuft bei euch nicht nur im David...

Nachteil an der Archivierung im David: Bei so großen User-Archiven dauert der bereinigungsjob sicherlich eine ganze Weile...

Gruß

Björn

150.000 Dateien in einem Archive? Und da kommt Windows mit klar? Wie lang warteste den, wenn den Ordner auf Dateiebene öffnen magst? Dauert doch Jahre oder?

Bye Anni

Hallo Forum,

erst einmal vielen Dank für Eure Reaktionen !

Momentan arbeiten wir mit keiner elektronischen Mail_archivierung. So ein Konzept muss gut geplant sein, dafür fehlt

uns wegen diesem momentanen Problem die Zeit. Der Vorschlag ist sehr gut, wir müssen nur erst klären, ob sich die Anschaffung für uns

überhaupt noch lohnt.

Das einzige, worauf die sl.exe excessiv 'rumrödelt' ist keinlink\david\archive\user\archive.dir , die

einzenlen grossen Archive werden bei diesen Peaks nicht angesprochen.

Es gitb archive.dat(s) mit 15MB und mehr, aber diese Dateien werden während der Peaks nicht angefasst.

Bis solche Archive im Client angezeigt werden vergeht schon einmal eine Minute.

Somit würde die automatische Bereinigung/Archivierung sicher insgesamt das Datenlager stark entlasten, bringt aber momentan

keine Linderung.

Die automatische Bereinigung (startet nachts) ist recht schnell (letzter Lauf 46 Minuten).

Das Datenlager im David liegt in einer SAN, für den Server ist es ein lokales NTFS Laufwerk (über SCSI-Virtuallisierung angesprochen) , physikalisch fliegen die Daten durch ein Glaskabel in eine grosse Blackbox.

Insgesamt liegen in diesem SAN Bereich ca 3 Millionen Dateien (es waren schon 4.5, durchschn. Fragmentierung ist 1,03 ), die MFT ist 4,49 GB, 10.600 Fragmente.

Hat jemand Erfahrungen mit solen Werten ?

Vielleicht liegt es an 'zu langer Zugriffszeit' beim Zugriff auf kleine Dateien, aber der SAN-Controller hat einen Cache,

einer unserer nächster Schritte ist den SAN Hersteller nach einer Einschätzung zu fragen.

Danke für's Mitgrübeln,

Chris

Hallo Citab,

Danke für die Anführungen, dieses 'Problem' ist uns bekannt.

Unsere Mail-Archivierung ist sehr wohl nach diesen Konventionen

gestrickt, jedoch nicht elektronisch.

_EDIT_off_topic: 'lohnen' ist eher eine Anspielung auf die Frage : "wieviele Clients verträgt 'unser' David?"

Die rechtliche Betrachtung der E-Mail als "Brief" halte ich persönlich für ebenso sinnreich wie ein Gesetz gegen
böse "H4ckert00ls" (wie soll ich ohne Monitoring meine Arbeit machen ?!?) !
Eine E-Mail ist allerhöchstens eine Postkarte ! (Certs sind da was anderes!)
Solche Konstrukte entstehen, wenn der Maler den Lackierer nach der Baustatik fragt.
Dennoch ist die Archivierung durchaus wichtig.
Aber da unterhalten sich die Falschen im falschen Thread

/_EDIT_off_topic

Gruß,

Chris

Hallo Forum,

ein Info-Update:

der Käfer liegt irgendwo im Verhalten des ServiceLayers bezeuglich der Zugriffe auf die ...user/archive.dir .
Wenn ich diese Datei umbenenne ist unser Problem hinfort !
Allerdings fehlt uns dann halt auch alles, was die Zugriffe auf diese Datei ermöglichen, da
das Infocenter nicht mehr "sehen" kann, was in "Benutzer" liegt;
- Kontakliste
- 1 zu 1 Rechtebeziehungen (zB Kalenderzugriff auf fremde Konten)
- Verteilregeln einrichten
- etc. (genug für ein K.O.)

kingcopy:
Wir haben heute mit dem Upport für die SAN-Anbindung 'philosophiert', leider ist es nicht bis ins Detail klärbar.
Definitiv leidet die SAN Anbindung nicht, die ist so, wie sie sein sollte.
Was sich leider NICHT überprüfen lässt ist ein gedankliches Möglichkeitskonstrukt;
Was wäre, wenn die Gesamtperformanz der SAN okay ist, aber eine Xkilobyte Datei -mehrfach in einzelnen Fragmenten/Offsets angefordert- nicht schnell genug zum Transport bereitgestellt werden kann ?
Ich wüsste leider keine Monitoring-Möglichkeit, um dieses zu überprüfen

Wir haben rumgesponnen, diese eine Datei auf ein RAM-Drive auszulagern, da koennten vielleicht
traumhafte Zugriffszeiten entstehen *schwelg*, nur leider weiss erstens nicht 'wie' wir das machen könnten,
zweitens nicht 'womit'.
Jemand eine Idee dazu ?
Unter anderen Systemen wäre ein ln -s /target /source denkbar, aber das kann weder
NTFS, noch Windows in seiner Architektur leisten, oder ? Selbst wenn ich der Registry beibringe,
eine .lnk auch als eine solche zu zeigen (und dann umzubenennen), bleibt das immer noch eine Datei mit Ziel als Inhalt,
das wird NIEMALS ein Link!

Ein nächster Schritt ist vielleicht, diese Datei (wenn auch schrittweise) manuell neu zu erstellen (Arcutil-Recover brachte nichts), das wird ein Riesenspass.
Vielleicht hat jemand noch eine Idee ?

Danke und Gruß,
Chris

Hallo kingcopy,

Hast Du vielleicht eine Idee, wie man die Zugriffe so im Detail prüfen kann ?

Wir haben nur den einen david Server.

Vielleicht ist es auch ein Lösungsansatz, einen weiteren David Server in Netz zu nehmen so viele User

herüberzunehmen, bis die Last 'erträglich' ist. Falls nicht in Kürze eine Wende oder eine

Erkenntnis kommt, werden wir damit beginnen.

Aber die Lizenz ist für 5000 Clients.

Also geht's oder geht's nicht ?