Druhý ze série Jump start session, tentokráte pod vedením Andy Pedisiche. Zaměřil se na monitorování obecně – bez výrazné vazby na DDM (Domino Domain Monitoring), která je dostupná až od verze 7. Jeho vystoupení zdaleka nebylo špatné, ale ve srovnání se Susan, která měla předchozí prezentaci, to přeci jenom byla jiná káva – výrazně klidnější, skoro bych až řekl moc. Nicméně nehaním, spoustu informací jsem se dozvěděl i tak.
První z nich (a tu už jsem věděl) je, že se při monitorování nemůžete spolehnout na údaje, které dává operační systém – typicky obsazení paměti ve Windows není tak úplně pravda, respektive Domino to cítí jinak než Windows. Blbě se to sice vysvětluje Windows administrátorům, ale to už se nedá nic dělat.
Takže věc na začátek, která by měla být hrozně překvapivá, ale není – většina Lotus zákazníků vůbec nesleduje statistiky a ti, kteří je sledují na ně věětšinou nekoukají. Sám se k tomu klidně přiznám – statistiky i trendy sledujeme, ale nekoukám na ně. I když díky zapnutému sledování alespoň mám možnost se na ně kdykoliv podívat a díky nim rozhodnout zda má smysl koupit nový server nebo ne, případně zda nová verze přinešla zlepšení. Ale že bych sledoval vytížení serveru po nasazení nové databáze …
Hned druhým bodem tedy bylo upozornění na databázi events4.nsf (jasně, všichni víme že je, i třeba jak ji využít) a na její možnost nastavení kolekcí serverů – tedy pouze jeden server má spuštěn COLLECT úlohu a stahuje informace z dalších serverů. Informace jsou tak na jednom místě a dají se sledovat – výrazně lepší, než se dívat na 20 různých serverů a sledovat každý z nich individuálně. A při té příležitosti nakousl i otázku jak často sledovat (Collection report interval) – většinu času prý stačí 60 minut, při upgradu nebo výrazné změně to snížit na 30 minut a pokud se ladí problémy tak zpět na standardních 15 minut.
Jmenoval také pár zajímavých statistik, konkrétně Platform.LogicalDisk.1.PctUtil.Avg – na Windows to prý většinou nepřekčí hodnotu 60%, AIX a iSeries mohou zvládnout i 90%. Poté většinou nastávají problémy. Další, Platform.LogicalDisk.1.AvgQueueLen.Avg a Peak – pokud je fronta větší než několik vteřin, tak disky nestíhají, občas se to dá akceptovat, když to trvá tak se musí serveru odlehčit. Navíc by to člověk měl vždy srovnávat s využitím procesoru (Platform.Process.ActiveDomino.TotalCpuUtil) a paměti (Platform.Memory.RAM), protože paměť = disk a pokud se hodně sahá na disk, tak to může znamenat nedostatek paměti. A nakousl správný problém – databáze statrep.nsf nemá pohledy, kde by to bylo snadno vidět a daly by se dělat trendy. Takže na CD máme ukázkovou verzi s pohledy, nicméně udělat je zvládne každý – pole jsou pojmenovaná logicky, takže to není žádná velká věda. A pak ještě statistiky Platform.Process.xxx.PctCpuUtil, které ukazují pro jednotlivé úlohy (xxx) jak využívají procesor.
Pro clustery jsou pak statistiky Replica.Cluster.SecondsOnQueue, která by měla být do 10 vteřin, Replica.Cluster.SecondsOnQueue.Avg, která by měl být také do deseti. Pokud nejsou, tak pomůže přidání více cluster replikátorů, pomocí nastavení CLUSTER_REPLICATORS=x v notes.ini. Další replikátor se samozřejmě spustí až po startu serveru, případně se dá pustit ručně jako další úloha.
Při nastavování eventů upozornil na monitorování změny ACL u adresní knihy – to by se totiž v provozním systému moc měnit nemělo, takže ať to hezky posílá maily při změně. A zmínil první nedostatek DDM (k dalším v jiném příspěvku) – neupozorňuje, takže člověk to zjistí, až když koukne do DDM databáze.
Když teď procházím tu prezentaci ještě jednou, tak rovnou připojím informaci z další přednášky. Spíše vtípek. Jedna z možností notifikace je totiž přehrání zvuku. A to v serverovně dává velký smysl 🙂 Takže jednou se prý administrátoři dohodli, do serveru dali zvukovou kartu, připojili repráčky, nahráli zvuk („Help me, help me“) a spojili to s událostí, ke které docházelo celkem často. No a ráno přišel maník vyměňovat pásky a v serverovně slyšel – Help me, help me – a nebyl schopen nikoho najít. A to byl prý jeden z nejlepších telefonátů, který měli po dlouhou dobu. To pobaví a asi to je jediné „smyslupné“ využití.
Zapnutí Activity Logging také doporučovali, ale nikoliv jejich slepé povolení – vynechat by se prý měl typ Domino.Mail, protože generuje enormní množství dat, která jdou většinou lépe zjistit jinak, takže to zbytečně zatěžuje server.
Jedna perlička, která je popsaná i v Technote, ale na kterou přicházeli dlouhou dobu. Databáze Activity.nsf se většinou nereplikuje mezi servery, ale není důvod proč ne. Respektive důvod existuje – Sametime. Pokud používáte Sametime, tak databáze vpuserinfo.nsf, ve které jsou uložené buddy listy (seznamy kontaktů) má totiž stejné replika ID, takže když zapnuli replikaci, tak se to hezky proreplikovalo, databáze vpuserinfo.nsf měla rázem 2GB a uživatelé se do Sametime přihlašovali 10 minut. Tak to je bomba. A řešení jednoduché – udělejte kopii databáze a tu rozreplikujte na servery.
Celé, 3 hodiny za námi a 3 dny před námi. A jak zjistím, tak budou ještě náročnější.