OWSTIMER.EXE

Thomas Östreich Als Antwort am 28 Okt. 2010 10:48

Hängt davon ab was er zu tun hat -> Viele Benachrichtigungen verarbeiten, Optimierungen duchführen, 1000 von (Spam) Emails verarbeiten ...

Einfach mal den Dienst neustarten und schauen was passiert. Alternativ ins Log vom SharePoint schauen ..\12\Logs\

Auch mal in die CA schauen welche TimerJobs laufen.

kk 236 Als Antwort am 28 Okt. 2010 10:59

(Spam) E-mails können es überhaupt nicht sein da laufen über moss keine.

Kann das an einem Prozess liegen der zwar auf einem anderen Server läuft, aber den Sharepoint (z.b. Listen etc.) mit Daten aus einer Datenbank füttert und versch. andere Einstellungen vornimmt?

Andi Fandrich Als Antwort am 28 Okt. 2010 11:05

Das kann Dir keiner von uns hier sagen, weil wir alle nicht wissen, welche TimerJobs da laufen. Thomas hat Dir ja beschrieben, wie Du das herausfinden kannst.

Thomas Östreich Als Antwort am 28 Okt. 2010 11:10

Wenn es einer TimerJob ist der im SharePoint registriert ist kann es natürlich möglich sein das dieser externe Daten verarbeitet.

Einfach mal in der Zentraladministration schauen was dort für Jobs geplannt sind, falls ihr externe Erweiterungen für SharePoint nutz oder aber auch den ProjectServer dann stehen dort die Job drin mit ihren Ausführungszeiten. Dazu hilft natürlich auch immer ein Blick in die Logs (Windows, SharePoint).

kk 236 Als Antwort am 28 Okt. 2010 11:39

10/28/2010 11:16:32.65* OWSTIMER.EXE (0x12B0)                    0x14BC Windows SharePoint Services    General                        0 Monitorable ...upCode backoutCode, Object userData)     at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)     at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)     at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state) 

 
10/28/2010 11:16:32.65  OWSTIMER.EXE (0x12B0)                    0x14BC Windows SharePoint Services    General                        8m90 Medium   195 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage. 

10/28/2010 11:16:32.65  OWSTIMER.EXE (0x12B0)                    0x14BC Windows SharePoint Services    General                        0 Monitorable Potentially excessive number of SPRequest objects (15) currently unreleased on thread 43.  Ensure that this object or its parent (such as an SPWeb or SPSite) is being properly disposed. This object is holding on to a separate native heap. Allocation Id for this object: {F6626782-F815-4F00-B545-EF6F4BDA37DA} Stack trace of current allocation:    at Microsoft.SharePoint.SPRequestManager.Add(SPRequest request, Boolean shareable)     at Microsoft.SharePoint.SPGlobal.CreateSPRequestAndSetIdentity(Boolean bNotGlobalAdminCode, String strUrl, Boolean bNotAddToContext, Byte[] UserToken, String userName, Boolean bIgnoreTokenTimeout, Boolean bAsAnonymous)     at Microsoft.SharePoint.SPWeb.InitializeSPRequest()     at Microsoft.SharePoint.SPWeb.EnsureSPRequest()     at Microsoft.SharePoint.SPWeb.get_R... 

 
10/28/2010 11:16:32.65* OWSTIMER.EXE (0x12B0)                    0x14BC Windows SharePoint Services    General                        0 Monitorable ...equest()     at Microsoft.SharePoint.SPWeb.SetMondoProcHint(Int32 hint)     at Microsoft.SharePoint.SPSite.OpenWeb(Guid gWebId, Int32 mondoHint)     at Microsoft.SharePoint.SPSite.OpenWeb(Guid gWebId)     at Microsoft.SharePoint.Workflow.SPWinOeWorkflow.get_InitiatorWeb()     at Microsoft.SharePoint.Workflow.SPWinOEWSSService.GetWebForListItemService()     at Microsoft.SharePoint.Workflow.SPWinOEWSSService.UpdateListItem(Guid id, Guid listId, Int32 itemId, Hashtable itemProperties)     at Microsoft.SharePoint.WorkflowActions.ActivityHelper.DoCorrectUpdateMethod(WorkflowContext theContext, Int32 item, Guid listId, Hashtable properties, IListItemService hostInterface)     at Microsoft.SharePoint.WorkflowActions.UpdateItemActivity.Execute(ActivityExecutionContext provider)     at System.Workf... 

10/28/2010 11:16:32.65* OWSTIMER.EXE (0x12B0)                    0x14BC Windows SharePoint Services    General                        0 Monitorable ...low.ComponentModel.ActivityExecutor`1.Execute(T activity, ActivityExecutionContext executionContext)     at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(Activity activity, ActivityExecutionContext executionContext)     at System.Workflow.ComponentModel.ActivityExecutorOperation.Run(IWorkflowCoreRuntime workflowCoreRuntime)     at System.Workflow.Runtime.Scheduler.Run()     at System.Workflow.Runtime.WorkflowExecutor.RunScheduler()     at System.Workflow.Runtime.WorkflowExecutor.RunSome(Object ignored)     at System.Workflow.Runtime.Hosting.DefaultWorkflowSchedulerService.WorkItem.Invoke(WorkflowSchedulerService service)     at System.Workflow.Runtime.Hosting.DefaultWorkflowSchedulerService.QueueWorkerProcess(Object state)     at System.Threading.ExecutionContext.runTryCode(Obj... 

10/28/2010 11:16:32.65* OWSTIMER.EXE (0x12B0)                    0x14BC Windows SharePoint Services    General                        0 Monitorable ...ect userData)     at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)     at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)     at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)     at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)   

Kann jemand damit was anfangen? Ich hab ne 82mb große logdatei die voll ist mit Meldungen vom owstimer...

Thomas Östreich Als Antwort am 28 Okt. 2010 11:56

Ich würde einfach mal den Dienst neustarten (auf eigenes Risiko!).

Es ist auf jeden Fall zu erkennen das die Workflows Probleme bereiten. Wenn es zuviele WF gibt die immer nur auf was warten wie z.b die Uhrzeit also nicht auf ein Ereignis wie z.B den Status, dann werden diese WF auch (höchstwahrscheinlich) nicht entladen und der TimerJob Speicherverbrauch wächst an und zusätzlich benötigt auch noch jeder WF Rechenzeit beim Prüfen der Zeit (hängt von der Implementierung ab)

kk 236 Als Antwort am 28 Okt. 2010 12:09

ich tipp auf einen von den beiden...

Thomas Östreich Als Antwort am 28 Okt. 2010 12:19

Das könnte gut möglich sein, dann am besten diese beiden deaktivieren und schauen wie es sich mit dem OWSTIMER über einen gewissen Zeitraum verhält.

kk 236 Als Antwort am 28 Okt. 2010 12:21

[quote user="Thomas Östreich"]

Das könnte gut möglich sein, dann am besten diese beiden deaktivieren und schauen wie es sich mit dem OWSTIMER über einen gewissen Zeitraum verhält.

ich hab noch ein 3. eingefügt das zu dem 2. Workflow gehört. Ich glaub da könnte er hängen...

Thomas Östreich Als Antwort am 28 Okt. 2010 12:21

Ach nein die führen eine Aktion aus und warten nicht (Condition)

Thomas Östreich Als Antwort am 28 Okt. 2010 12:23

ahh doch da ist ja eine Pause enthalten.

Thomas Östreich Als Antwort am 28 Okt. 2010 12:24

Zeig mal den Task mit Pause.

kk 236 Als Antwort am 28 Okt. 2010 12:26

Da steht nur drin:

Actions: Für 0 Tage, 0 Stunden, 2 Minuten

kk 236 Als Antwort am 28 Okt. 2010 13:27

könnt ihr mit dieser Fehlermeldung was anfangen?

Exception from HRESULT: 0x80040E14

C.Kaiser Als Antwort am 28 Okt. 2010 13:34

Außer das was Google sagt nichts:
http://www.google.de/#hl=de&source=hp&q=Exception+from+HRESULT%3A+0x80040E14+&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=2121bb55b55ecf8c

Tritt das im gleichen Zusammenhang auf oder ist das eine andere Baustelle? Hast du die SQL server Logs schonmal überprüft?

kk 236 Als Antwort am 28 Okt. 2010 13:52

Hab jetzt rausgefunden dass das ein Datenbankfehler ist und wohl die SQL Datenbank wo der Sharepoint seine Daten hin speichert keinen Platz mehr hat.

Aber da ich den Server weder aufgesetzt hab noch den Sharepoint installiert UND erst seit 1 Monat hier beschäftigt bin is das grad ein Problem für mich.

Legt der Sharepoint selbst eine SQL Datenbank an wo er reinspeichert? Wenn ja wo liegt die?

C.Kaiser Als Antwort am 28 Okt. 2010 13:56

[quote user="kk 236"]

Legt der Sharepoint selbst eine SQL Datenbank an wo er reinspeichert? Wenn ja wo liegt die?

Der SharePoint hat mehrere Datenbanken. ich würde einfach mal auf dem SQL Srver gucken ob der Plattenplatz überhaupt ausreichend ist. Wohin die DBs gespeichert werden kann man dir nicht sagen, Standardeinstellungen ist sowas hier C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA sollte aber bei jeder ordentlichen Installation geändert werden.

kk 236 Als Antwort am 28 Okt. 2010 14:00

[quote user="C.Kaiser"]

[quote user="kk 236"]

Legt der Sharepoint selbst eine SQL Datenbank an wo er reinspeichert? Wenn ja wo liegt die?

Der SharePoint hat mehrere Datenbanken. ich würde einfach mal auf dem SQL Srver gucken ob der Plattenplatz überhaupt ausreichend ist. Wohin die DBs gespeichert werden kann man dir nicht sagen, Standardeinstellungen ist sowas hier C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA sollte aber bei jeder ordentlichen Installation geändert werden.

Die Datenbank liegt wohl nicht lokal, ist wohl "anständig" geändert worden, denn auf den lokalen Platten wäre für die Datenbank noch genug Platz.

Es is definitiv die SQL Datenbank die wirft seit einer Woche SQL Errors (zu wenig Speicherplatz) wie blöde (Event Viewer), hat aber wohl von den Systemadmins keiner gemerkt.

C.Kaiser Als Antwort am 28 Okt. 2010 14:04

Wenn du das SQL Server management Studio auf dem SQL Server öffnest, eine SharePoint Datenbank auswählst -> Rechtsklick -> Properties -> Files siehst du den Pfad wo die DB liegt.

Da mal nachschauen. Interessant sind meistens auch die SQL Log Dateien, die können mal unnötig groß werden, wenn von diesen nicht regelmäßig ein Backup gemacht wird.

kk 236 Als Antwort am 28 Okt. 2010 14:39

[quote user="C.Kaiser"]

Wenn du das SQL Server management Studio auf dem SQL Server öffnest, eine SharePoint Datenbank auswählst -> Rechtsklick -> Properties -> Files siehst du den Pfad wo die DB liegt.

Da mal nachschauen. Interessant sind meistens auch die SQL Log Dateien, die können mal unnötig groß werden, wenn von diesen nicht regelmäßig ein Backup gemacht wird.

Jetzt hab ich mal einen vom Serverteam angerufen, die SQL DB hat 410GB zur Verfügung, der Log speichert auf der gleichen Platte wie die DB, das Logfile ist 320GB groß, den Rest hat die DB, heißt Log und DB haben keinen Platz mehr.

C.Kaiser Als Antwort am 28 Okt. 2010 14:46

Die LogFiles sollten nicht übermäßig wachsen, wenn die Datenbanken gesichert werden (die Logfiles sollten die Transaktionen beinhalten, welche seit dem letzten Backup durchgeführt wurden) -> werden die Datenbanken regelmäßig gesichert (also nicht nur Snapshot-Sicherung oder dergleichen)?

Ich würde jetzt die Datenbanken sichern und dann die LogFiles shrinken, aber damit soll sich dann denke ich mal euer DB Admin auseinandersetzen. ;-)

kk 236 Als Antwort am 28 Okt. 2010 14:49

macht er schon...

ich hoffe mal dass hier vernünftige backups gemacht werden... ich kenn das garnicht anders, es muss alles gesichert werden womit gearbeitet wird... jeder server UND db... :)

C.Kaiser Als Antwort am 28 Okt. 2010 15:00

[quote user="kk 236"]

ich hoffe mal dass hier vernünftige backups gemacht werden... ich kenn das garnicht anders, es muss alles gesichert werden womit gearbeitet wird... jeder server UND db... :)

Ich schon :) und das leider in sehr vielen Fällen...

Thomas Östreich Als Antwort am 28 Okt. 2010 15:01

Es kann schon sein das die DB's gesichert werden aber bei DB's mit dem Wiederherstellungsmodel "Vollständig" müssen die Transactionslogs explizit gesichert werden. Naja ich denke mal euer DB Admin würd jetzt ertmal ein kleines Problem haben wohin mit 480 GB Daten so auf die schnelle um das log dann verkleinern zu können, geht halt nur wenn es gesichert wurde.

kk 236 Als Antwort am 28 Okt. 2010 15:33

damit dass ich es nicht anders kenne meine ich von meinen vorherigen firmen... :)

ja die Einstellung ist definitiv "Vollständig" sonst wär es ja auch garnicht so groß geworden. Das wird wohl das Problem sein die riesige Logfile kriegt man da jetzt nicht so einfach raus...

Naja mal abwarten werd gleich nochmal anrufen... :)

Henning Eiben Als Antwort am 28 Okt. 2010 23:01

[quote user="C.Kaiser"]

Die LogFiles sollten nicht übermäßig wachsen, wenn die Datenbanken gesichert werden (die Logfiles sollten die Transaktionen beinhalten, welche seit dem letzten Backup durchgeführt wurden) -> werden die Datenbanken regelmäßig gesichert (also nicht nur Snapshot-Sicherung oder dergleichen)?

Ich würde jetzt die Datenbanken sichern und dann die LogFiles shrinken, aber damit soll sich dann denke ich mal euer DB Admin auseinandersetzen. ;-)

[/quote]

Nicht nur sichern, sondern auch das Transaktionsprotokoll abschneiden! Sonst bleibt das Log auch nach der Sicherung so groß.

C.Kaiser Als Antwort am 29 Okt. 2010 10:06

[quote user="Henning Eiben"]

[quote user="C.Kaiser"]

Ich würde jetzt die Datenbanken sichern und dann die LogFiles shrinken, aber damit soll sich dann denke ich mal euer DB Admin auseinandersetzen. ;-)

[/quote]

Nicht nur sichern, sondern auch das Transaktionsprotokoll abschneiden! Sonst bleibt das Log auch nach der Sicherung so groß.

Sagte ich ja - aber wird der Admin wohl gemacht haben :-)

Henning Eiben Als Antwort am 29 Okt. 2010 10:14

Bestimmt! :) Genauso wie er ja auch eine Sicherung für Datenbanken im Recovery-Modell "Full" eingerichtet hat.

kk 236 Als Antwort am 29 Okt. 2010 10:36

jo is erledigt worden... zumindest die sql datenbank passt jetzt wieder die workflows hab ich auch überarbeitet und den owstimer neugestartet, hoffe der bleibt jetzt unten...

stephan12345 Als Antwort am 31 Jan. 2011 10:42

Hallo Christian,

besteht ein direkter Zusammenhang zwischen den SQL Server Logs und dem OWSTIMER Problem ?

Ich habe das gleiche Problem, bei mir sind einfach 11 Tasks in eine Art deadlock verfallen und auf 0 Prozent, laut Zentraladministration,
stehen geblieben.

Gruß
Stephan

C.Kaiser Als Antwort am 31 Jan. 2011 17:40

Die OWSTimer und SQL Logs sollte da nichts miteinander zu tun haben (wie henning auch schon sagte). ich würde mal versuchen den Timer Dienst neu zu starten.

Was für "Tasks" sind denn das? Sind das Standard Sharepoint TimerJobs, oder will da auch noch ein Workflow mitspielen?

Henning Eiben Als Antwort am 31 Jan. 2011 15:44

Hi,

der OWSTIMER ist dafür da, zeitgesteuert Jobs auszuführen. Darüber werden alle asynchronen Abläufe im SharePoint gesteuert. Asynchron werden alle diejenigen Operationen ausgeführt, die tendenziell etwas länger brauchen können. Somit soll sichergestellt werden, dass nicht eine einzelne Aktion das Portal als solches blockiert.

Dass der Prozess permanent auf 45% Auslastung läuft erscheint mir nicht normal. Das ist deutlich zu viel. Ich würde auch mal sagen, dass da ein Job "quer" schießt. Ggf. solltest du in der Zentral-Administration und Operations\Timer Job Status einmal gucken welche Jobs alle aktuell ausgeführt werden. Vielleicht gibt das einen Hinweis welcher Job dort quer schießt.

stephan12345 Als Antwort am 1 Feb. 2011 10:09

Hi,

dort waren seit 3 Tagen 11 Jobs in Ausführung, alle standen auf 0 Prozent und der Prozessor klühte.

Ich habe den Rechner dann neu gestartet. Aber wie das System in diesen Zustand kam kann ich nicht herausfinden.

Gruß
Stephan

C.Kaiser Als Antwort am 1 Feb. 2011 10:11

Was sagen denn die Windows- und Sharepoint-EventLogs. Normalerweise ist Sharepoint in so einem Fall (Vorausgesetzt es sind Standard TimerJobs) sehr gesprächig.

stephan12345 Als Antwort am 21 Feb. 2011 09:23

Hallo Christian,

hab jetzt wieder mal auf der Server geschaut, seit dem 08.02 hängen elf Aufträge(siehe unten) und die beiden CPUs laufen auf 100 Prozent.
Hat jemand irgendeine Idee wie es zu so einem Deadlock kommen kann ?

Grüße
Stephan

Integritätsanalyseauftrag (Stündlich, Word Automation Services, Beliebiger Server)  xxx 0%  Wird ausgeführt. 08.02.2011 15:00
Import der Microsoft SharePoint Foundation-Verwendungsdaten  xxx 0%  Wird ausgeführt. 08.02.2011 15:00
Word Automation Services-Zeitgeberauftrag  xxx 0%  Wird ausgeführt. 08.02.2011 15:00
Integritätsanalyseauftrag (Stündlich, Microsoft SharePoint Foundation-Timer, Beliebiger Server)  xxx 0%  Wird ausgeführt. 08.02.2011 15:00
Integritätsanalyseauftrag (Stündlich, Microsoft SharePoint Foundation-Timer, Alle Server)  xxx 0%  Wird ausgeführt. 08.02.2011 15:00
Integritätsanalyseauftrag (Stündlich, Sicherheitstokendienst, Alle Server)  xxx 0%  Wird ausgeführt. 08.02.2011 15:00
Aktualisierungsauftrag für Anwendungsadressen  xxx 0%  Wird ausgeführt. 08.02.2011 15:00
Benutzerprofildienst-Anwendung – Vollständige Synchronisierung des Benutzerprofils mit SharePoint  xxx 0%  Wird ausgeführt. 08.02.2011 15:00
Integritätsanalyseauftrag (Stündlich, Benutzerprofildienst, Beliebiger Server)  xxx 0%  Wird ausgeführt. 08.02.2011 15:00
Benutzerprofildienst-Anwendung – Synchronisierungsauftrag für thematische Bewertung 
Auftrag zur Lizenzsynchronisation  xxx 0%  Wird ausgeführt. 08.02.2011 15:00
Benutzerprofildienst-Anwendung – Auftrag für Änderungen an Benutzerprofilen 

C.Kaiser Als Antwort am 21 Feb. 2011 09:50

Starte mal den Timer Dienst neu.

stephan12345 Als Antwort am 21 Feb. 2011 10:03

Ich hab jetzt den Server komplett neu gestartet.

Jetzt läuft erst einmal wieder alles sauber.
Ich würde halt gerne das Problem auf dauer loswerden. In den Eventlogs steht auch nichts brauchbares.