none
[WSS 3] owstimer.exe, 80% du processeur RRS feed

  • Question

  • Bonjour à tous,

    Est-ce que quelqu'un saurait pourquoi le processus owstimer.exe occupe autant de ressources processeurs ?
    Souvent aux alentours de 80%, je suis contraint de le tuer de temps en temps afin de pouvoir travailler correctement.

    Ma config actuelle est :
    - machine virtuelle (VMWare)
    - Intel Xeon 5140 @2,33GHz
    - 1Go de RAM
    - Windows Server 2003

    Merci d'avance de votre aide !

    Ludovic
    jeudi 31 mai 2007 03:12

Réponses

  • Ca y est ! J'ai enfin l'impression d'avoir des observations qui ont mené quelque part...

     

    Alors j'ai remarqué que mon serveur SharePoint synchronisait périodiquement son horloge avec celui de mon server DNS/Exchange/AD qui lui même souffre de désynchronisation (il perd tjrs quelques minutes...). Et si au moment de la synchro de l'horloge, SharePoint écrivait dans le log, alors survient le problème de CPU !

     

    Après avoir manuellement réglé l'horloge, là la charge CPU rechute complètement, avec OWStimer.exe donc...

     

    Si cela peut aider, voici d'ailleurs les derniers logs inscrits après que tout soit revenu à la normale :

    06/06/2007 14:26:57.68  OWSTIMER.EXE (0x0E04)                    0x0E34 Windows SharePoint Services    Timer                          7psa Critical The Execute method of job definition Microsoft.SharePoint.Search.Administration.SPSearchJobDefinition (ID a9539e0e-0ee2-46ee-8604-9afc699b3f7a) threw an exception. More information is included below.  Exception from HRESULT: 0x80040D23 
    06/06/2007 14:26:57.68  OWSTIMER.EXE (0x0E04)                    0x0E34 Windows SharePoint Services    Timer                          72ae Unexpected Exception stack trace:    at Microsoft.SharePoint.Search.Administration.MSSITLB.IGatherManagerAdmin3.get_ConfigurationVersion()     at Microsoft.SharePoint.Search.Administration.Gatherer.ProvisionGlobalProperties()     at Microsoft.SharePoint.Search.Administration.Gatherer.Provision()     at Microsoft.SharePoint.Search.Administration.SPSearchServiceInstance.Synchronize(Boolean installGathererApplication)     at Microsoft.SharePoint.Search.Administration.SPSearchJobDefinition.Execute(Guid targetInstanceId)     at Microsoft.SharePoint.Administration.SPTimerJobInvoke.Invoke(TimerJobExecuteData& data, Int32& result)

     

    Est-ce que quelqu'un a déjà eu de tels problèmes ?

    Comment résoudre cette histoires de désynchronisation ?

    jeudi 7 juin 2007 01:18
  • A vrai dire, j'ai le sentiment que ceci est dû au fait que le contrôleur de domaine utilisé dans mon environement de test tourne sur un Virtual PC 2004 ; et s'il l'est censé le faire, ce dernier n'arrivait pas à se synchroniser à time.windows.com. J'ai résolu ce problème en utilisant un de nos contrôleur de domaine en exploit' comme TimeProvider (cf. article)
    Donc pour le moment tout a l'air de fonctionner correctement désormais !

    Je vous l'accorde, ceci n'avait finalement pas de lien direct avec SharePoint, mais ce n'était pas évident à s'en rendre compte vu qu'il était le seul à en souffrir... Sad
    jeudi 7 juin 2007 18:50

Toutes les réponses

  • Franchement ta config virtuel est tres faible

     

    Avec SQL + MOSS en local, il faudrait plutot orienter sur 1,2 - 2 gig de ram

     

    Ca m'a resolue bien des lenteurs de certains process de control

    vendredi 1 juin 2007 10:29
  • A vrai dire, j'avais également mis en place une autre plate-forme MOSS qui tourne sur un P4 2.5GHz / 2Go RAM, et je me rend aujourd'hui compte que celui-ci présente aussi les même symptomes (il atteint même les 98% de CPU). Pourtant en vérifiant hier, il était à 0%...

    Je me pose donc la question, y a-t'il des raisons pour lesquelles OWSTimer "travaille" autant ? et qu'à des certains moments ?

    Par ailleurs, on vient de m'accorder le 2ème giga de RAM sur la VM, et au bout de 15-20 min, il a commencé à déjà occuper les 60% de CPU...
    vendredi 1 juin 2007 18:40
  • Est ce que l'un des Timer Jobs pourrait être à l'origine du problème ?

    J'ai essayé de désactiver tous les jobs et ça avait l'air d'être ok... je suis donc maitenant en train de les réactiver un-à-un.

    lundi 4 juin 2007 18:27
  • Ca y est ! J'ai enfin l'impression d'avoir des observations qui ont mené quelque part...

     

    Alors j'ai remarqué que mon serveur SharePoint synchronisait périodiquement son horloge avec celui de mon server DNS/Exchange/AD qui lui même souffre de désynchronisation (il perd tjrs quelques minutes...). Et si au moment de la synchro de l'horloge, SharePoint écrivait dans le log, alors survient le problème de CPU !

     

    Après avoir manuellement réglé l'horloge, là la charge CPU rechute complètement, avec OWStimer.exe donc...

     

    Si cela peut aider, voici d'ailleurs les derniers logs inscrits après que tout soit revenu à la normale :

    06/06/2007 14:26:57.68  OWSTIMER.EXE (0x0E04)                    0x0E34 Windows SharePoint Services    Timer                          7psa Critical The Execute method of job definition Microsoft.SharePoint.Search.Administration.SPSearchJobDefinition (ID a9539e0e-0ee2-46ee-8604-9afc699b3f7a) threw an exception. More information is included below.  Exception from HRESULT: 0x80040D23 
    06/06/2007 14:26:57.68  OWSTIMER.EXE (0x0E04)                    0x0E34 Windows SharePoint Services    Timer                          72ae Unexpected Exception stack trace:    at Microsoft.SharePoint.Search.Administration.MSSITLB.IGatherManagerAdmin3.get_ConfigurationVersion()     at Microsoft.SharePoint.Search.Administration.Gatherer.ProvisionGlobalProperties()     at Microsoft.SharePoint.Search.Administration.Gatherer.Provision()     at Microsoft.SharePoint.Search.Administration.SPSearchServiceInstance.Synchronize(Boolean installGathererApplication)     at Microsoft.SharePoint.Search.Administration.SPSearchJobDefinition.Execute(Guid targetInstanceId)     at Microsoft.SharePoint.Administration.SPTimerJobInvoke.Invoke(TimerJobExecuteData& data, Int32& result)

     

    Est-ce que quelqu'un a déjà eu de tels problèmes ?

    Comment résoudre cette histoires de désynchronisation ?

    jeudi 7 juin 2007 01:18
  • Ah ce niveau, ce n'est plus du SharePoint mais un pur probléme IT entre la synchro et de la generation de LOG.

    Perso, jamais vu mais ca meriterait d'être vu de prêt par le support MS non ?
    jeudi 7 juin 2007 09:40
  • A vrai dire, j'ai le sentiment que ceci est dû au fait que le contrôleur de domaine utilisé dans mon environement de test tourne sur un Virtual PC 2004 ; et s'il l'est censé le faire, ce dernier n'arrivait pas à se synchroniser à time.windows.com. J'ai résolu ce problème en utilisant un de nos contrôleur de domaine en exploit' comme TimeProvider (cf. article)
    Donc pour le moment tout a l'air de fonctionner correctement désormais !

    Je vous l'accorde, ceci n'avait finalement pas de lien direct avec SharePoint, mais ce n'était pas évident à s'en rendre compte vu qu'il était le seul à en souffrir... Sad
    jeudi 7 juin 2007 18:50