| Ooaniki | Velikost schranky na serveru |
| Dobry den,
mam situaci kdy schanka na serveru zabira 600MB - pokud se podivam na properties -> info -> vidim 84 % used
pokud vytvorim lokalni kopii databaze tak databaze zabira vseho vsudy 30MB (a to by odpovidalo velikostne poctu emailu a priloh)
Jak zjistim konkretne co zabira tak strasne moc mista?
Je spravnym reseni pouzit tento prikaz:
load compact -i -c -d -K ; copy-style kompakt,ignoruj chyby,smaz pohledy,nastav vetsi UNK tabulku
???
Pripadne napada nekoho nejake lepsi reseni?
Predem diky moc! |
| peto | 30 MB? |
10.04.2008
16:18:23
ID: 2588.1
| Skutečně to má být 30 a ne 300? Jenom prázdná mail db má snad kolem 15 MB. To by byl skutečně dramatický rozdíl.
Při replikaci se přenáší pouze "data", třeba indexy pohledů se vytvoří až následně. Zkuste se podívat kolik místa zabírají indexy. Ve administraci: Soubory - kontextové menu "Spravovat pohledy" |
| Ooaniki | ano - 30MB |
LN admin
10.04.2008
16:59:07
ID: 2588.2
| Ano, opravdu jen 30MB - v databazi je par emailu s nekolika malyma prilohama. Prave proto si rikam cim by to tak mohlo byt zpusobene...
Pokud se podivam na pohledy tak zjistim tuto informaci "view indexes consume 1MB of disc space, which is 0% of the entire space used by this database" takze timhle to neni. Uzivatelka navic nema zadne specialni pohledy.
Nestalo se nekdy nekomu neco podobneho? |
| Martin Humpolec | Re: Velikost schranky na serveru |
10.04.2008
20:14:28
ID: 2588.3
| že by tam bylo tolik smazaných dokumentů úplně nečekám, ale kdoví :) v každém případě po compactu uvidíš víc. |
| VZ | Možnosti |
10.04.2008
21:07:26
ID: 2588.4
| Je to divné - 84% ze 600MB je zhruba 504 MB. 50MB by tedy bylo 8,4%. Na jakém OS běží ten server a klient a jaký je tam filesystém? Ale že by až o tolik ovlivnila případné rozložení dat vzhledem k velikosti bloků na disku je také nepravděpodobné. Není nějaké replikační omezení na té lokální replice (např. na posledních 90 dní)? Nebo že by tam byl nějaký velký dokument obsahující např. nějaké instalační CD nebo video, ke kterému by neměl admin. nebo uživatel přístup pro čtení? To by šlo zkontrolovat po zapnutí funkce Full Access Administrator v Admin. klientovi, |
| Ooaniki | Tezko rict |
LN Admin
10.04.2008
21:27:49
ID: 2588.5
| Nakonec jsem tedy spustil prikaz
load compact -i -c -d -K
a databaze po kompaktaci na serveru zabira onech 33MB - takze vyreseno ...
Ted mi ale vrta hlavou jestli tech mailboxu (bezduvodne velkych) na serveru nebude vic. Na toto jsem narazil opravdu nahodou, kdyz uzivatelka hlasila, ze ma prekrocenou kapacitu schranky a kdyz jsme se koukali co promazeme tak jsme zjistili, ze je ve firme par mesicu a ma jen par emailu.
Preci jenom 0,5GB u nekolika uzivatelu se uz projevi trebas na velikosti zalohovanych dat (samozrejme ne nejak markantne, ale je to zbytecne).
Na serveru bezi LN 7.0.1, Windows 2003 Server, predpokladam NTFS, klienti jsou rovnez 7.0.1, Windows XP SP2
Lokalni replika obsahuje stejny pocet emailu jako databaze na serveru, zadne omezeni (coz vlastne dokazuje, ze stejnou velikost ma DB na serveru po kompaktaci).
Priznavam, ze posledni moznost overeni databaze s Full Access jsem nezkousel, takze tohle pro me zustava zahadou. |
| Ooaniki | Utilitka |
LN admin
11.04.2008
08:28:52
ID: 2588.6
| Nevi nekdo o nejake utilitce, ktera by projela mailboxy a spocitala/odhadla by misto zabrane emaily a k tomu jeste pro porovnani vypsala misto, ktere databaze na serveru opravdu zabira?
|
| VZ | FAA |
11.04.2008
08:32:54
ID: 2588.7
| Jestli se to po kompaktaci tak výrazně zmenšilo, tak ten Full Access Admin by asi nepomohl. Spíš to byly nějaké smazané e-maily, které mohly obsahovat relativně velké soubory. Jedna sekretářka dostávala e-mailem různá vtipná videa (soubory kolem 10MB), kdyby jich přišlo jen 5 za týden (některá opakovaně), za deset týdnů je to 500 MB. Pokud uživatel(ka) narazil(a) na kvótu kapacity, možná pak všechny takové zbytečné maily najednou smazal(a), ale databáze by zůstala pořád stejně velká do první kompaktace s potřebnými parametry. Jen ten ukazatel % využití je trochu divný. Ale odpovídalo by to zhruba tomu, co psal Martin v ID: 2588.3. |
| VZ | Re: Utilitka - log by nestačil? |
11.04.2008
08:38:27
ID: 2588.8
| V log.nsf na serveru je pohled Usage\By size, který ukazuje celkem přehledný souhrn a jednotlivé dokumenty v něm obsahují celkem detailní informace. |
| Ooaniki | Log neni moc prehlednej |
LN admin
11.04.2008
09:23:24
ID: 2588.9
| No v logu vidim usage\by size vidim jen velikost, ktera je na serveru...Takze v mem pripade bych tedy videl, ze databaze zabira na serveru 600MB a vyuziti je 84%, to ze realne ta DB obsahuje 30MB z toho nevyctu ... |
| Martin Humpolec | Re: Velikost schranky na serveru |
14.04.2008
19:02:27
ID: 2588.10
| Kdysi jsem takové udělátko pro klienta psal, srovnávalo mu to i minulé měsíce a uživatelům automaticky posílalo, aby zazálohovali se speciálním tlačítkem, které jim tu zálohu do určitého data samo provedlo. Zkrátka a prostě pořádně jsme to tehdy vyšperkovali :) |
| Ooaniki | Co dodat :) |
LN admin
15.04.2008
08:35:41
ID: 2588.11
| Inu co k tomu dodat nez ze takove udelatko by se hodilo :) |
| Ooaniki | Hmm |
LN admin
17.04.2008
13:51:25
ID: 2588.12
| Tak jsem bohuzel narazil na dalsiho uzivatele... tentokrat vyuziti databaze 96procent, velikost na serveru 3GB, po vynucenem spusteni kompaktace je velikost 1,5GB
Jedine co me napada je rucne proverit u uzivatelu pocet mailu s velikosti mailboxu (tady to bylo kolem 1500emailu a 3000MB schranky) - samozrejme u nekterych jedincu, kteri pracuji na projektech a chodi jim emaily s obrovskymi prilohami to fungovat nebude.
Opravdu nikdo nezna nejakou pomucku na sledovani velikosti emailu nebo jejich zaplneni? Bohuzel pomoci informaci z logu tyhle situace nepodchytim :-/ |
| cifra | Automatizace |
17.04.2008
19:00:47
ID: 2588.13
| A proc to vubec resis? Jednou za tyden (nebo i vicekrat pust kompaktaci na vsech db na serveru a je po problemu. navic se tomu da klidne rict, ze ma kompaktovat pokud je vyuziti mista pod nejakym procentem...
|
| Ooaniki | . |
LN admin
18.04.2008
08:21:23
ID: 2588.14
| Na serveru je nastavena kompaktace pokud je vyuziti databaze pod 95procent ... v tomto pripade byla ale informace, ze vyuziti je 96 procent takze kompaktace by stejne spustena nebyla.
Mozna resim nesmysly, ale preci jen bych mel rad tohle pod kontrolou - pokud by byla informace spravna tak by to melo hlasit vyuziti DB 50% ne 96% (jak tomu bylo a jak to pisu v predchozim prispevku) |
| VZ | Verze ODS? |
18.04.2008
09:45:04
ID: 2588.15
| Ten nepřesný výpočet % využití DB je možná chyba (vlastnost?) konkrétní verze LN, ale také může souviset s vnitřní strukturou DB, tedy ODS (On Disk Structure). ODS se zobrazuje od R5 ve vlastnostech DB, od R6 je to vidět i administračním klientovi ve sloupci "File format". Např. DB vytvořené původně v R3 nebo R4 mají ODS version 20, v R5 je to tuším 41, od R6 je ODS verze 43. Na vyšší verzi vnitřní struktury to přechází po kompaktaci v novější verzi LN a lze to vrátit i na nižší verzi ODS. Např. u starých poštovních DB z R3 (ODS 20), které měly velikost např. 1GB a využití kolem 95% se po kompaktaci v R5 (změna na ODS 41) zmenšila velikost na 100MB při využití 99% procent. Takže procento využití pro danou verzi ODS bylo nejspíš správně, ale stejná DB v novější verzi LN při obdobném procentu využití byla o 90% menší.
Jaká byla u těch DB verze ODS před kompaktací a jaká po kompaktaci? |
| Ooaniki | ODS je 43 |
LN admin
18.04.2008
10:16:13
ID: 2588.16
| Pomalu ve volnych chvilich projizdim mailboxy a narazil jsem na dalsi schranku:
ODS 43
disk space: 377MB
documents: 51
Pokud vytvorim lokalni kopii smrskne se schranka na 50MB, ODS zustane verze 43
Pocet dokumentu se snizi z 51 na 44 (pokud to porovnam, tak v lokalni kopii neni 7 emailu z kose, ktere ale dohromady zabiraji cca 1MB) |
| Ooaniki | reseni?? |
LN admin
18.04.2008
10:26:39
ID: 2588.17
| Asi bude opravdu resenim pustit jednou za tyden compact na vsechny databaze .. jen me prekvapilo, ze se to takto chova. Diky vsem za info a rady |
| VZ | Nejstarší DB? |
18.04.2008
11:21:08
ID: 2588.18
| Jen tak ze zvědavosti jsem prohlédl admin. klientem všechny DB na lokále a je tam ještě jedna původní R3 s ODS 17:1 - "Notes Mobile Survival Kit". Takže ODS 20 byla až od R4 a 90% úspora mohla být při převodu z ODS 17 na ODS 41 (tehdy se těch cca 200 poštovních DB navíc migrovalo z LN R3 na SUN Solarisu 2.6 na LN R5 na Linuxu). A některé historické DB jsou asi ještě v původním R3 formátu na demo disketách ze školení na R3, na lokále jsou už ale zkompaktované na ODS 43. |
| Martin Humpolec | Re: Velikost schranky na serveru |
20.04.2008
14:09:51
ID: 2588.19
| Udělátko na prohlížení databází a počítání velikostí je skoro napsané, teď tomu už dát jenom nějaký hezký ksicht a uvidíme, zda to k něčemu bude. |
| Martin Humpolec | Re: Velikost schranky na serveru |
28.04.2008
14:59:39
ID: 2588.20
| Udělátko na procházení mailboxů je napsané - link1 schválně jestli to k něčemu bude :-) |
| standa | Re: Automatizace |
28.04.2008
20:26:14
ID: 2588.21
| No souhlasím s Frantou, já si nedokažu představit nasevení serveru bez jednou týdenního compactu bez vyjímek na uvolnění místa. A pak řízení archivace mailboxů uživatelů, a pro uživatele pohled podle velikosti, apod.. Používání standardní šablony si nedokážu představit. Upravenou používám o 4.6 verze k 8.x a rozšíření z openntf.org jsou super a pár vlastních. |
| Martin Humpolec | Re: Velikost schranky na serveru |
29.04.2008
17:14:31
ID: 2588.22
| Ten kompakt s uvolněním místa má trochu problém s transakčními logy, kdy místo nezmenšuje nebo je potřeba po jeho spuštění udělat fullbackup. A to je úloha ve velkých firmách na několik hodin, takže je lepší strpět víc zabraného místa na disku a dělat to jednou za dlouhý čas. |
| VZ | Fullbackup na několik hodin? |
29.04.2008
18:18:48
ID: 2588.23
| To se dá celkem snadno obejít pomocí diskových klonů. V takovém případě celé backup okno trvá jen pár minut potřebných na rozpojení primárních disků a jejich zrcadlových klonů a pak může server běžet dál na primárních discích a zálohu provádí druhý server z naklonovaných disků. Až záloha doběhne, tak se pustí synchronizace mezi primárními disky a klony. Anebo, pokud by se mezitím něco ošklivého stalo na primárních discích, pak by se provedla zpětná synchronizace z klonů a bylo by obnoveno podstatně rychleji než z pásek.
Takový fullbackup děláme na hlavních serverech každý den, na pásky se to pak sice sype pár hodin, ale provoz to nezdržuje. Navíc když si někdo omylem něco během dne vymaže, prostě se jen sáhne ze zálohovacího serveru na rozpojený diskový klon a obnoví se to z něj během pár minut (pokud to tam v době rozpojení bylo). Ale na druhou stranu to zabírá několikanásobně víc místa na discích. Naštěstí jsou taková chytrá disková pole (a jejich ovládací SW) čím dál tím levnější. |
| standa | Většinou se řešení najde .. |
29.04.2008
20:12:48
ID: 2588.24
| Je vidět, že nějaké řešení se vždycky najde. Takže je jen na administratorovi, kdy je nasadí, kdy které použije, kdy musí třpět nějaká omezení a jaké politiky nastaví. A pokud to roste volí včas systém archivace do jiné databáze a na jiné místo. Tím se odleví serveru s mailboxy. Takže na závěr - otázka optimální administrace IT managerem a spolupráce s BP při návrzích a řešeních. Pak může být spokojenost na všech frontách (uživatel-vedení-IT-BP,..). Doba řešit si vše jako "Ferda mravenec" je .... |
| Ooaniki | na adminovi? |
LN admin
02.05.2008
14:12:11
ID: 2588.25
| Vzdycky to reseni neni jen na adminovi - kuprikladu pokud ma zhora nadiktovano, ktera sablona se musi pouzivat anebo proste nejsou penize na zalohovaci disky/servery. |
| standa | RE : na adminovi? |
06.05.2008
10:43:22
ID: 2588.26
| A jak to admin řeší? když má disktováno, nemá peníze, apod..... asi musí řešení hledat ne ? Nebo to nechá spadnout. Já ted vidět řešení které nebylo náročné na disky apod. |
| VZ | Nechávám to spadnout ;-) |
06.05.2008
11:16:35
ID: 2588.27
| Je docela pěkné zjištění, že Domino dokáže chvíli přežít i bez datových disků. Nedávno jeden (nyní již bývalý) kolega za plného provozu zavadil o "emergency" vypínač na hlavním rozvaděči v místnosti diskových polí a vše se okamžitě vypnulo. Servery vedle běžely dál a Domino to ustálo - prostě hlásilo na konzole nepřístupné disky a po nahození polí to jelo bez restartu dál - poškozený pouze log.nsf a mail.box - asi 3 ztracené maily (nejspíš spamy)a 2 logovací dokumenty. Něco podobného jsem naposled zažil asi před 15 lety na AS/400, když nám uklízečka vypnula za provozu jeden šuplík disků 9336. I tenkrát to nějak data přežila a provoz jel dál. Produkty IBM zkrátka přežijí ledacos. |
| Jirka | Quota R7 |
IT
29.05.2008
14:16:35
ID: 2588.28
| Dobrý den,
mám problém s Quotou u R7 na serveru u replikované pošty. Všichni uživatelé, kteří používají poštovní LOKÁLNÍ repliku jsou schopni překročit Quotu poštovní databáze na serveru, protože replikace ignoruje serverovou quotu. nemáte někdo nějakou radu?
Jirka |
