panagenda - Effizienz im Fokus_DE_FINAL

... oder auch: „Ein Bild sagt mehr als tausend Worte“ 

Effizienz ist das Verhältnis zwischen einem definierten Nutzen und dem Aufwand, der zu dessen 

Erreichung notwendig ist. 

© 2007 - 2012 panagenda

Agenda 

Coming up next … 

Wer bin ich? … und über panagenda 

Grundlagen: Was eigentlich möglich ist – oder auch: 

• Womit Administratoren und IT-Abteilungen zu kämpfen haben 

Ans Eingemachte … 

• Die 30 wichtigsten Serverstatistiken (von 2.000) 

• … und Clients? 

• … und Gruppen? 

• … und Datenbanken? 

Effizienz im Fokus: Clients, Server und Systeme überwachen, analysieren und optimieren 2

Vorstellung 


Über Florian Vogler 

CEO & CTO – (hoffentlich) repräsentativ für die grossartige Arbeit meiner Kollegen bei panagenda 

Geboren in Hamburg (DE), gelebt in London (UK), 

Wien (AT), Frankfurt (DE), Alicante (ES); 

dzt. wieder in Frankfurt (DE) 

Lotus Notes / Domino seit 1992 

Begonnen mit Notes bei Raiffeisen Österreich 

• Administration und Entwicklung 

• 35,000 user weltweit (heute > 100,000) 

Seit 2002 Kernkompetenz Client Management, 

Notes / Domino Infrastruktur-Analyse 

und -Optimierung 

*Viel*reisender, Kunden in vielen verschiedenen 

Ländern 


Über panagenda 

Symbiotische Geschäftsbeziehungen mit Kunden und Partnern 

HQ: Wien/AT, Niederlassungen in Heppenheim bei 

Frankfurt/DE, Boston/USA 

Entwicklung von Standardprodukten 

4++ Millionen Lizenzen in über 70 Ländern 

IBM Lotus Notes 

Client Management 

MarvelClient :: „‘99%‘ manageability “ 

(nicht „nur“ IBM Lotus Domino) 

Server Analytics, Monitoring & Reporting 

GreenLight :: Echtzeit, Langzeit, Smart 

Gruppen, Certifier und ACLs analysieren 

GroupExplorer :: Transparenz, Sicherheit & Automation 

plus: NameChanger (Namensänderungen), DatabaseExplorer (Design-Analyse), Notes2Web (Web-Transformation) 


Agenda 





Ans Eingemachte … 






Womit Administratoren und IT-Abteilungen zu kämpfen haben 

• Allem voran: Unwissen (Verzeihung) 

• Hauptsächlich auf Grund von Überforderung 

� Keine Zeit (mehr) für die „Innereien“ (inner workings) von Clients, Servern, und Systemen 

� Zunehmende Komplexität 

einzelner Systeme 

�� Zunehmende Zahl an Systemen 

� Aufzucht ja – 

(Proaktive) Pflege kaum bis gar nicht 

• Fehlende Wissensquellen 

• Zeitmangel 

• „Wer keine Zeit hat, hat auch keine Ewigkeit“ 

(Deutsches Sprichwort) 

• „Wer keine Zeit hat, wird nicht reif“ 

(Chinesisches Sprichwort) 

• „Falsche“ &| Fehlende Werkzeuge 

Gewachsene Umgebungen – große Server unterscheiden sich 

fundamental von kleinen; neue (8) von alten (< 8)! 


Womit Administratoren und IT-Abteilungen zu kämpfen haben 

Innersystemische Wechselwirkungen – am Beispiel Lotus Notes / Domino 

Übergreifend 

Geographie 

Netzwerk (Bandbreiten, Struktur) 

Online/Offline 

Clustering/Loadbalancing 

… 

Hardware 

Datenhaltung 

Netzwerkanbindung 

Konfiguration 

Datenbanken 

… 

Clients 

Server 

Hardware (CPU, Hauptspeicher) 

Datenhaltung 

Netzwerkanbindung 

Konfiguration 

Datenbanken, Tasks, Mailverkehr 

… 

Datenbanken 

ODS 

Grösse 

Leserfelder 

Design 

# & Größe Dokumente 

… 


Werkzeuge am Beispiel des Domino Servers 

Es gibt … 

� Öffentliches Adressbuch 

– Server 

– Cluster 

– Benutzer/Gruppen 

– Verzeichnisse 

– Mail 

– Replikation 

– Policies 

– Web Konfiguration 



… und es gibt … 

� Öffentliches Adressbuch (8) 

� Log.nsf 

– Verschiedenes 

(!!) 

– Mail 

– Replikation 

– Datenbank-Nutzung 

– Passthrough 




� Log.nsf (5) 

� Admin Client 

– Monitoring 

� Tip 1: Health-Monitoring in 

Admin-Vorgaben aktivieren 

� Tip 2: „Server-Bookmarks 

aktualisieren“ deaktivieren 





� Admin Client 

– Monitoring (1) 

– Analyse 

(~15) 

(ACL, 

Catalog, 

AdminP, ...) 

– Statistiken (1 bzw. ~1.200) 

– Activity Trends („1“) 

– Messaging („1“) 

– Replikation („1“) 





� Admin Client (20) 

� Events (1) & DDM … 

– Probes 

– Filter 

– Collection Hierarchie 

– Event Handlers 

– Event Generators 






� Events & DDM (6) 

� Monitoring Results 

(statrep) 

– Alarms 

– Events 

– Statistic Reports 



42 

Obwohl 42 „die Antwort auf das 

Leben, Universum, und Alles ist“ 

(gemäß Hitchhikers Guide to the Galaxy) 

hilft das leider nur wenig für 

Domino Überwachung & Analyse 




� Events & DDM (6) 

� Monitoring Results 

(statrep) (3) 

� 8 + 5 + 20 + 6 + 3 = 42 

� Das sind mindestens 42 

Ansichten / Bereiche, die 

man ggf. überwachen 

muss / „möchte“ ... 

Tip 3: Wenn Sie Hitchhikers Guide to the Galaxy von Douglas Adams nicht kennen � Lesen 


Bevor wir ans Eingemachte gehen … 

• Viele Unternehmen nutzen nicht einmal das bereits Vorhandene … 

• Wie bereits angesprochen: Realtime Server Monitoring mit Health-Monitoring 

• DDM – Domino Domain Monitoring (manchmal etwas zuviel des Guten, aber viel besser als nichts!) 

• Regelmäßiges Review von Gruppen 

• Regelmäßige Prüfung der 

wichtigsten Server-Statistiken 

(dazu später mehr) 

• Durchsicht von Lotusphere- 

Präsentationen 

• … 

• Regelmäßige Durchsicht 

der Usage-Ansichten in log.nsf; 

dazu ein Beispiel … 


Eine Beispiel-Auswertung der Usage Informationen aus log.nsf 

(die Sie einfach selbst vornehmen können) 

Copy/Paste in Excel � 

Daten Sortieren nach z.B. 

Transaktionen 


Bevor wir ans Eingemachte gehen noch ein paar Worte zu: 

Was noch alles möglich ist … 

• In nahezu jedem der vorgenannten Bereiche 

kann – und sollte man – „Tief(er)tauchen“ 

• Tieftauchen bedarf leider zumeist der 

(aufwendigen) Korrelation von Daten, z.B. … 

• Verbindungsdokumente und log.nsf ( db usage): 

� Welcher Mail- und/oder Replikationstraffic herrscht 

zwischen welchen Servern vor? 

• Clients und log.nsf - Datenbank-Nutzung (db usage): 

� Welche Benutzer verursachen welche Last? 

• Datenbank-Informationen von Clients und Server: 

� Wer hat Repliken von Datenbanken auf die er/sie 

keinen Zugriff mehr hat? 

� Wer hat unverschlüsselte Repliken von kritischen 

Datenbanken? 

• Netzwerk-Komprimierung zwischen Servern und Clients 

• Viele der Daten sind bereits da oder 

verhältnismäßig einfach einholbar 

• Die Korrelation lohnt sich (sehr) … 


Ein Bild sagt mehr als tausend Worte … 

Topologische Visualisierung von Mail- & Replikations-Verkehr zwischen Servern 



Eine Sicht auf Netzwerk-Verkehr-Komprimierung 

87% 

= 1 Server 

of your IBM Lotus Domino servers use port compression 

(33 of 38 servers) 

75% 

= 1.000 Clients 

of your IBM Notes Clients use port compression 

(32.780 of 43.512 clients) 



Die andere Sicht auf Netzwerk-Verkehr-Komprimierung 

4 

2 

0 

2,30 

3,30 

1,65 

current setup no port compression full port compression 

● Network transfer volume per day: 3,3 Gbyte 

saved (GByte) 

transfered (GByte) 

● Current settings: 60% configured „correctly“ � ~1 GByte / 30% saved 

● Applying port compression to all your servers and clients could save you an additional 

~0,65 GByte every day which is an additional 28% reduction / absolute 50% reduction 

of traffic 


Agenda 





Ans eingemachte … 






Bevor wir uns einzelne Statistiken ansehen … 

Zu Risiken und Nebenwirkungen fragen Sie Ihren Arzt oder Apotheker 

• Schwer bis nicht unter Laborbedingungen testbar 

• Fangen Sie mit offensichtlichen / einfachen Dingen an 

• Notieren Sie sich Einstellungen bevor Sie diese ändern 

• Bedenken Sie mögliche Wechselwirkungen 

• „Zuviel des Guten“ kann Performance verschlechtern, 

bis hin zu „Out of Memory“ bedeuten 

• Drehen Sie nicht an mehreren Schrauben gleichzeitig 

• es sei denn, es ist absolut notwendig/so „dokumentiert“ 

• Beobachten Sie Ihre Server nach Änderungen eine 

(sinnvolle) Zeit lang 

• Werten Sie aus, ob es Ihrem Server besser geht 

• „Google“ 

• Denken Sie bitte mit 

• Trauen Sie sich 

• Das hier ist erst der Anfang – bleiben Sie neugierig! 


Noch eine Vorbemerkung … 

• Viele der nachfolgenden Statistiken sind mit einem ‚einmaligen‘ „sh sta“ nicht ausreichend 

erfassbar; die Werte sollten bzw. müssen auf einem Zeitstrahl ausgewertet werden 

• Nur so ist greifbar, ob – und wann – es sich um dauerhafte / wiederkehrende Probleme handelt 

• Nur so ist tatsächlich überprüfbar, ob Änderungen helfen oder nicht (oder „verschlimmbessern“) 

• Ein Bild sagt mehr als tausend Worte … 

• Mit (leider größeren) 

Einschränkungen können Sie 

sich mit dem Admin Client 

behelfen … 

• Ohne Einschränkungen geht 

es nur mit hohem manuellen 

Aufwand oder Zusatz-Lösungen 

(ein paar Links dazu gibt es 

am Ende) 


ViewRebuildDir & Disk Optimierungen 

• Allem voran: freier Plattenplatz 

(„30%“ um Fragmentierung zu vermeiden) 

• Jeweils eigene Disks für … 

– Translog 

– Data 

– Ggf. page file/OS eigene disk 

– „ViewRebuildDir“=… 

view indexing auf eigene disk 

– Ab 8.5.3. ggf. .ft-Verzeichnisse 

(so nötig/gewünscht) 

– DAOS („günstig“) 


Server.Availability 

• Sagt in % aus wie verfügbar = „antwortbereit“ ein Server ist (response times) 

• Spätestens ab < 30% Verfügbarkeit wird es meistens problematisch; 

WENN denn der AvailabilityIndex überhaupt stimmt … 

� (Nur!) wenn der Server gut beschäftigt ist: „sh ai“ auf Console; 

gibt Empfehlung zur Anpassung von SERVER_TRANSINFO_RANGE in notes.ini 

• Ab Notes 8.5 empfiehlt sich: 

– notes.ini: Server_MinPossibleTransTime=1500 

– notes.ini: Server_MaxPossibleTransTime=20000000 

Wichtig: 

loadmon.ncf löschen 

wenn Server runtergefahren 

ist, um alte 

Werte zu löschen 


Monitor.* Warnungen im Auge behalten; Beispiele 

• Monitor.Last.ADMIN PROCESS.Warning(High)Text = Disk space statistics 

could not be found on Servername/Cert. 

• Monitor.Last.EVENT MONITOR.Warning(High)Text = Event: Error adding event 

document to Domino Domain Monitoring: Event correlation cache is full. You 

can increase its size via the NOTES.INI setting 

EVENT_CORRELATION_POOL_SIZE. 

• Monitor.Last.INDEX ALL.Warning(High)Text = Error updating view '#4538' in 

mail\nameabc.nsf: The single copy template associated with this database 

cannot be located. 

• Monitor.Last.SMTP SERVER.FailureText = SMTP Server: Initialization 

failure: Message Queue name already in use. 

• Monitor.Last.STATISTICS.Warning(High)Text = Unable to update activity 

document in log database for mail\namexyz.nsf: In Datenbank kann nicht 

geschrieben werden, da die Datenbank die erlaubte Größe 

überschreiten würde. 


Server.Sessions.Dropped 

• Gibt an, wie oft seit dem letzten 

Serverstart Sessions ‚gedropped‘ 

wurden 

• Verursacht durch „Drop all“ 

und/oder Client-seitigem Ctrl+Break 

(Frust-/Problem-Indikator) 

• Server.Sessions.Dropped = 25407 

• 28.6. - 18.10 = 4*30=120 Tage 

• 25407/120=211 Sessions dropped / 

day 

• Weiterführend in Verhältnis zu Peak 

# of users setzen 

„Drop all“ 

„anderes“ 

Problem 


Platform.LogicalDisk.1.AssignedName = D 

Platform.LogicalDisk.1.AvgQueueLen = 0 

Platform.LogicalDisk.1.AvgQueueLen.Avg = 0,01 

Platform.LogicalDisk.1.AvgQueueLen.Peak = 1,01 

Platform.LogicalDisk.1.BytesReadPerSec = 0 

Platform.LogicalDisk.1.BytesWrittenPerSec = 10.172,49 

Platform.LogicalDisk.1.PctUtil = 0,22 

Platform.LogicalDisk.1.PctUtil.Avg = 0,86 

Platform.LogicalDisk.1.PctUtil.Peak = 101,07 

Platform.LogicalDisk.1.ReadsPerSec = 0 

Platform.LogicalDisk.1.WritesPerSec = 2,07 

Platform.LogicalDisk.* 

Interpretation 

GUT < 2% < AvgQueueLen > 5% > SCHLECHT (1-100% = 0,01 – 1,0!) 

GUT = PctUtil < 80% (1-100% = 1-100) 

HINWEIS: ggf. durch # Spindeln zu dividieren � SAN/NAS 

Lösung 

Diverse Parameter (bufferpool, cache, namelookup), und OS / Disk Tuning 

Platform.LogicalDisk.2.AssignedName = C 

Platform.LogicalDisk.2.AvgQueueLen = 0,01 

Platform.LogicalDisk.2.AvgQueueLen.Avg = 0,73 

Platform.LogicalDisk.2.AvgQueueLen.Peak = 34,74 

Platform.LogicalDisk.2.BytesReadPerSec = 17.272,75 

Platform.LogicalDisk.2.BytesWrittenPerSec = 63.697,52 

Platform.LogicalDisk.2.PctUtil = 1,11 

Platform.LogicalDisk.2.PctUtil.Avg = 72,8 

Platform.LogicalDisk.2.PctUtil.Peak = 3.473,81 

Platform.LogicalDisk.2.ReadsPerSec = 2,58 

Platform.LogicalDisk.2.WritesPerSec = 7,3 


Platform.LogicalDisk.#.PctUtil 


Mail.Mailbox.* 

• (Mail.Mailbox.AccessConflicts/Mail.Mailbox.Accesses) x 100 

• Muss < 2 sein; ansonsten eine weitere Mailbox 

(ab vier-fünf Mailboxen wird der Benefit zunehmend geringer) 

• Beispiel: 

• Mail.Mailbox.AccessConflicts = 1636 

Mail.Mailbox.Accesses = 189864 

• = 0,86 = ok 


• Update.PendingList = Anzahl 

von Ansichten die auf 

Aktualisierung warten 

• Wenn 

Update.PendingList 

„laufend“ > 0, dann … 

• Notes.ini: 

Update_Fulltext_Thread=1 

FTUPDATE_IDLE_TIME=4 

Update.PendingList 

Hintergrund: 

• Wenn Sie viele Anwendungen haben … 

• … und einen vielbeschäftigten 

update task 

– View updates sind beeinträchtigt, solange Full 

Text Index Aktualisierungen in Arbeit sind 

• FTI update von view update trennen 

– FTI erfolgt dann in eigenem Memory Thread 

• Verbessert Performance 

• Update_Fulltext_Thread=1 

Wenn wir schon beim Thema Volltext-Index sind: 

Sie können den FTI thread aus dem limitierten Domino update pool isolieren: 

ftg_use_sys_memory=1 

Der FTI thread bekommt dann memory vom OS pool 

Gibt Domino system memory frei 


Database.Database.BufferPool.* 

• Database.Database.BufferPool.PerCentReadsInBuffer = 78,96 

• SCHLECHT < 90% < PercentReadsInBuffer < 98% < PERFEKT 

• 99.9% ist schlecht ... 

– Führt meist dazu, dass zuviele Anfragen auf Disk raus geschrieben werden 

– Der Server benötigt einen größeren BufferPool 

• Lösung: notes.ini NSF_Buffer_Pool_Size_MB=n (in MB) 

─ Default: 512 MB 


Database.DbCache.* 

• Database.DbCache.CurrentEntries = 1647 

Database.DbCache.HighWaterMark = 1691 

Database.DbCache.MaxEntries = 1536 

Database.DbCache.OvercrowdingRejections = 0 

• GUT = HighWaterMark < MaxEntries 

GUT = 0 OvercrowdingRejections 

• Lösung: 

– notes.ini NSF_DbCache_MaxEntries = n 

• Default: NSF_BUFFER Pool size x 3 


• Replica.Cluster.Failed 

Replica.Cluster.SecondsOnQueue 

Replica.Cluster.WorkQueueDepth 

Replica.Cluster.* 

• PERFEKT < 10 < SecondsOnQueue > 15 > SCHLECHT 

PERFEKT < 10 < WorkQueueDepth > 15 > SCHLECHT 

• Lösung: 

– Weitere Cluster Replikatoren 

hinzufügen 

– Auslastung der Cluster-Server 

optimieren (z.B. aktive User 

im Cluster aufteilen / 

load balancing) 


Server.Trans.PerMinute 

• Server.Trans.PerMinute=956 

Server.Users = 26 

� 956/26=36,7 

• HEAVY < 30 < Trans.PerMinute (per User) > 10 > LIGHT 

• Lösung: 

– Last erzeugende User identifizieren (db usage view!) 


Database.NAMELookupCache* 

• Database.NAMELookupCacheCacheSize = 2.513.328 

Database.NAMELookupCacheHits = 24.628.339 

Database.NAMELookupCacheMisses = 48.160.502 

• WICHTIG: NoHitHits! � 

• Miss > Hits: PRÜFEN 

• �� Cache zu klein oder zu groß(!) 

ini: NLCache_Size=16000000 


Server.ConcurrentTasks* 

• Server.ConcurrentTasks 

Server.ConcurrentTasks.Waiting 

• Waiting sollte NULL sein 

• Lösung: 

─ Server_Pool_Tasks = n ( z.B. 80) 

─ Server_Max_Concurrent_Trans = m 

(z.B. Server_Pool_Tasks * Anzahl Ports) 


Platform.PagingFile.Total.* 

Platform.PagingFile.Total.PctUtil = 0,28 

Platform.PagingFile.Total.PctUtil.Avg = 0,14 

Platform.PagingFile.Total.PctUtil.Peak = 0,8 

OK < 0% < PctUtil.Avg > 10% > SCHLECHT 

OS Level tuning, Check Memory 

Hinweis: Wenn “sh sta” keine Platform.* 

Statistiken ausgibt � Admin-Hilfe 


Agenda 











„Alternativlose“ Werbepause 

http://panagenda.com/giftoftransparency 

• Alternativlos nicht etwa weil Sie nicht weglaufen könnten 

(bitte nicht) – sondern weil effiziente Server- und Client 

Analysen ohne zusätzliche Werkzeuge unmöglich sind 

• Wir stellen Ihnen panagenda GreenLight – unsere Server- 

Monitoring- und Reporting-Lösung – gerne für 4 Wochen 

kostenlos zur Verfügung 

• Wir schenken Ihnen panagenda MarvelClient Analyze 

für ein Jahr kostenlos 

• Die Ergebnisse sprechen schon auf der Clientseite für sich 

• Die Ergebnisse lassen sich für weitere Abgleiche mit Ihrem Server- und 

Datenbank-Haushalt heranziehen 

• Für Gruppen und Datenbanken haben wir natürlich auch etwas 

(GroupExplorer und DatabaseExplorer) 

• Ob wir Ihnen helfen dürfen bestimmen Sie, 

ebenso wie das Tempo und den Fokus 

• „Alles auf einmal“ ist fast immer zuviel 


Agenda 



Grundlagen 

• Eine Übersicht was ein Notes 8 Client so mit sich bringt 



• … und Clients 

• … und überhaupt ☺ 


Endspurt 

45 Minuten für die 

Überwachung von 

Servern, Clients, und Systemen 

reichen gerade einmal für einen 

Spaziergang über den Eisberg – 

wir haben Lösungen für eine MENGE mehr 

business cases als nur die vorher genannten. 

Falls Ihr Problem nicht in dieser Session zur 

Sprache kam – sei es ein Problem mit Clients, 

Servern, Design/Entwicklung, Administration 

oder etwas ganz anderes: 

Wir würden uns freuen von Ihnen zu hören! 


Danke für Ihre Geduld – Fragen? Antworten! 

Q&A 


Ich würde mich freuen von Ihnen zu hören! 

DE: Lahnstrasse 17, 64646 Heppenheim :: +49 6252 305 2840 


Ressourcen / Links 

• Daniel Nashed, Nash!Com 

• LS08: BP112 

• LS11: BP102, BP110, BP118 

• LS12: BP110, BP121, ID112, ID114 

• Windows Indexing: http://bit.ly/ACzO6Z 

• „The internet“ – google „Domino performance ibm“; 

great IBM Whitepapers and articles, some very good site out there

panagenda - Effizienz im Fokus_DE_FINAL

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?