das ist eine nicht so seltene frage, die man zum glück recht leicht beantworten kann:
1. perfmon öffnen
2. von jedem webfrontend aus “web service” den counter “current connections” hinzufügen
fertig. leichter kanns wirklich nicht sein 😉
Month: February 2009
About Month: February 2009
quick note: determine performance bottlenecks
- Image via Wikipedia
weil ich eben danach gefragt wurde, schnell ein paar anmerkungen – ein guter start ist natürlich perfmon.
processor bottlenecks kann man natürlich am leichtesten erkennen:
– %processor time öfters / andauernd über 90%
– processor queue length öfters / andauernd größer als 2
– bei multi-cpu systemen: %processor time öfters / andauernd über 50%
disk bottlenecks kann man sehr oberflächlich betrachtet an einer average disk queue length größer als 2 erkennen.
memory bottlenecks kann man z.b. am hohen paging erkennen; details z.b. hier.
ebenfalls empfehlen kann man in diesem zusammenhang den windows server 2003 performance advisor
“HTTP 403 Forbidden” exception
die files im 12er directory sollte man ja bekannterweise ohnehin nicht anpassen, trotzdem wird eine design-anpassung gerne direkt in den files application.master, default.master und natürlich in der core.css durchgeführt.
wollte eben ein bestehendes design in meine vm übernehmen, und zwar per drag&drop vom host in die vm direkt auf die entsprechende stelle im 12er directory. und danach war sharepoint sehr böse auf mich und antwortete nur noch mit http 403 meldungen.
des rätsels lösung: fehlende berechtigungen auf den 3 genannten files; vererbung wieder aktivieren, iisreset und schon funktioniert es zum glück wieder…
Backup eines Filenet IS Systems
diesen artikel habe ich nun seit fast 2 jahren als draft hier herumkugeln; fertigschreiben? no time for that. löschen? zu schade. also – here it is…
MKF datenbanken:
– permanent (enthält im wesentlichen informationen über übertragene dokumente)
– transient (enthält im wesentlichen informationen über dokumente im cache)
– security (enthält im wesentlichen informationen über benutzer und gruppen)
– NCH (network clearinghouse db)
Cache:
wird ein neues dokument hinzugefügt, so landet es normalerweise ja zuerst im bes cache (id=3) – mit dem commital wandert es in den page-cache (id=1) und hat den status “locked”, sprich es darf nicht gelöscht werden, weil es ja noch nicht auf osar bzw msar geschrieben wurde. dies passiert durch die migration, das dokument hat nun den status “ageable”. eine ausnahme ist z.b. cold, hier wandern dokumente direkt in den page cache ohne den umweg über den bes cache. im falle des falles kann es also sein, dass dokumente noch nicht auf die library geschrieben wurden – daher muss auch der cache gesichert werden.
die mkf datenbanken und den cache sichert man am besten mit einem filenet tool namens “ebr”, welches allerdings den cache und die transient datenbank nur sichern kann, wenn filenet nicht läuft; mit anderen worten: man hat jedenfalls eine downtime. zwar ist in den ebr sample files der hinweis “First release supports full and offline backup for transient database” enthalten wodurch man vermuten könnte, dass sich das ändern wird – da es den ebr aber schon lange gibt und das noch immer so ist, wird das wohl auch in der zukunft noch so bleiben…
zusätzlich dumpt man
security informationen: mittels “SEC_tool” export filename
classes, families und indexes: mittels “ddexim” -e > filename