OVH Cloud OVH Cloud

[SPS2003- WSS] Indexation

3 réponses
Avatar
Sandra Maury
Bonjour,

J'ai programmé dans l'administration de SPS, 3 indexations incrémentielles
par jour pour l'index "non-portal-content". Il y a 30 000 documents dans mes
sites et l'index fait 140 Mo.
Lorsque l'indexation commence les utilisateurs s'en aperçoivent car les
pages des sites sont longues à charger. Sur le serveur la CPU ne dépasse pas
20% mais le process w3wp.exe en consomme une bonne partie. J'ai 4 Go de RAM
sur ce serveur qui est bi-processeurs. Le fichier d'échange tourne à 2,7 Go.
En plus de temps en temps j'obtiens cette erreur dans l'observateurs
d'évènements :
"L'arrêt d'un processus servant le pool d'application
'MSSharePointPortalAppPool' a pris trop de temps. L'identificateur de
processus était '1160'."
Je n'ai pas touché au paramétrage des pools d'IIS pour Sharepoint j'ai
laissé les options par défaut.
Avez-vous déjà rencontré ce problème ?
Merci pour vos réponses.

Sandra

3 réponses

Avatar
Chrislap [MS]
Bonjour,

Vous devez savoir que lors de grand sollicitation du moteur d'indexation de
SPS2003, il est préconiser d'utiliser une seconde machine SPS2003 dédié à
l'indexation. Cela empêchera de prendre de la CPU pour le rendu utilisateur.
Un autre axe est de paramétrer l'indexation pour qu'elle n'ai lieu que
lorsque le portail est peu utilisé (la nuit par exemple) afin de ne pas
pénaliser la navigation des utilisateurs.

Pour l'erreur rencontrée, verifiez si votre serveur SPS est en version SP2.

Cdlt
--
Chrislap [MS]


"Sandra Maury" a écrit dans le
message de news:
Bonjour,

J'ai programmé dans l'administration de SPS, 3 indexations incrémentielles
par jour pour l'index "non-portal-content". Il y a 30 000 documents dans
mes
sites et l'index fait 140 Mo.
Lorsque l'indexation commence les utilisateurs s'en aperçoivent car les
pages des sites sont longues à charger. Sur le serveur la CPU ne dépasse
pas
20% mais le process w3wp.exe en consomme une bonne partie. J'ai 4 Go de
RAM
sur ce serveur qui est bi-processeurs. Le fichier d'échange tourne à 2,7
Go.
En plus de temps en temps j'obtiens cette erreur dans l'observateurs
d'évènements :
"L'arrêt d'un processus servant le pool d'application
'MSSharePointPortalAppPool' a pris trop de temps. L'identificateur de
processus était '1160'."
Je n'ai pas touché au paramétrage des pools d'IIS pour Sharepoint j'ai
laissé les options par défaut.
Avez-vous déjà rencontré ce problème ?
Merci pour vos réponses.

Sandra


Avatar
Sandra Maury
Bonjour,

Merci pour votre réponse. Connaissez-vous les préconisations Microsoft pour
savoir à partir de combien de documents on doit séparer SPS et SQL ? D'autre
part, cela peut-il être fait sans devoir tout réinstaller ?

J'ai bien le SP2 installé.

Cordialement,

Sandra Maury

"Chrislap [MS]" a écrit :

Bonjour,

Vous devez savoir que lors de grand sollicitation du moteur d'indexation de
SPS2003, il est préconiser d'utiliser une seconde machine SPS2003 dédié à
l'indexation. Cela empêchera de prendre de la CPU pour le rendu utilisateur.
Un autre axe est de paramétrer l'indexation pour qu'elle n'ai lieu que
lorsque le portail est peu utilisé (la nuit par exemple) afin de ne pas
pénaliser la navigation des utilisateurs.

Pour l'erreur rencontrée, verifiez si votre serveur SPS est en version SP2.

Cdlt
--
Chrislap [MS]


"Sandra Maury" a écrit dans le
message de news:
> Bonjour,
>
> J'ai programmé dans l'administration de SPS, 3 indexations incrémentielles
> par jour pour l'index "non-portal-content". Il y a 30 000 documents dans
> mes
> sites et l'index fait 140 Mo.
> Lorsque l'indexation commence les utilisateurs s'en aperçoivent car les
> pages des sites sont longues à charger. Sur le serveur la CPU ne dépasse
> pas
> 20% mais le process w3wp.exe en consomme une bonne partie. J'ai 4 Go de
> RAM
> sur ce serveur qui est bi-processeurs. Le fichier d'échange tourne à 2,7
> Go.
> En plus de temps en temps j'obtiens cette erreur dans l'observateurs
> d'évènements :
> "L'arrêt d'un processus servant le pool d'application
> 'MSSharePointPortalAppPool' a pris trop de temps. L'identificateur de
> processus était '1160'."
> Je n'ai pas touché au paramétrage des pools d'IIS pour Sharepoint j'ai
> laissé les options par défaut.
> Avez-vous déjà rencontré ce problème ?
> Merci pour vos réponses.
>
> Sandra





Avatar
Pierre Vivier-Merle
Bonjour,

Je complète les dires de Christophe par rapport à votre remarque.
D'après ceux-ci, vous êtes dans une configuration où SQL Server et SPS 2003
sont installées sur la même machine.
Vous pouvez en effet déjà envisagé de séparer les deux : vous basculez en
ferme simple et cela peut améliorer les performances car SQL Server est
sollicité en lecture lors des indexations.

Ce que propose Christophe, c'est d'ajouter une machine supplémentaire qui
sera dédié à l'indexation et aux jobs. Vous basculez alors en ferme moyenne.

Un document Microsoft "capacity planning" est disponible sur le site
Microsoft expliquant sous forme d'abaque les recommandations. Il tient
compte également du nombre d'utilisateurs ainsi que d'autres facteurs
(nombre de recherche simultanées...) Combien d'utilisateurs se connectent
sur votre SPS 2003 ?

Cependant, il y a peut être d'autres optimisations à effectuer. Tout d'abord
au niveau accès disques :
. SQL. Celui-ci est sollicité en lecture lors des accès aux pages et lors de
l'indexation. Avez-vous une configuration des disques SCSI de type RAID 1+0
ou RAID 5 sur les fichiers de données et de transaction de SQL ?
. Ensuite au niveau des fichiers d'indexation qui sont sollicité dans ce cas
en écriture : même question.

vous pouvez également essayer l'analyse auto-adaptative :
=> Issus du guide administrateur SPS 2003 :

"La mise à jour adaptative, comme la mise à jour incrémentielle, analyse
uniquement le contenu qui a été modifié depuis la dernière mise à jour.
Contrairement à la mise à jour incrémentielle toutefois, la mise à jour à
jour adaptative se caractérise par une plus grande efficacité car elle tente
d'accéder uniquement aux documents susceptibles d'avoir été modifiés, en se
basant sur l'analyse des informations des historiques.

La mise à jour adaptative utilise les données accumulées lors des mises à
jour précédentes, quel que soit leur type. L'efficacité du système augmente
au fil du temps et des mises à jour, car un plus grand nombre d'échantillons
statistiques est disponible pour l'algorithme. Après une semaine de mises à
jour adaptatives quotidiennes, le système se trouve dans un état stable. Un
état stable est l'état dans lequel se trouve le système lorsqu'il a acquis
suffisamment de données pour que la mise à jour adaptative puisse
fonctionner correctement et avec des performances optimales.

Les mises à jour calculent les données statistiques quel que soit le type de
mise à jour effectué par Microsoft Office SharePoint Portal Server 2003.
Vous pouvez effectuer des mises à jour incrémentielles et ultérieurement
effectuer des mises à jour adaptatives. Les performances augmentent
immédiatement car le système se trouve déjà dans un état stable. Cela
signifie que SharePoint Portal Server a déjà accumulé suffisamment de
données statistiques pour appliquer l'algorithme. Il est peu probable que
l'amélioration des performances soit significative si les mises à jour
adaptatives sont appliquées à des collections de moins de 2 500 documents.

Important L'exécution d'une mise à jour adaptative est plus rapide qu'une
mise à jour incrémentielle ou intégrale, mais le risque existe que du
contenu mis à jour soit ignoré. Toutefois, SharePoint Portal Server analyse
toujours les documents qui n'ont pas été modifiés pendant deux semaines et,
par conséquent, aucune modification ne peut passer inaperçue pendant plus
longtemps."

Cordialement,
Pierre - MVP SPS
Venez visiter mon blog : http://blogs.developpeur.org/pierre !


"Sandra Maury" a écrit dans le
message de news:
Bonjour,

Merci pour votre réponse. Connaissez-vous les préconisations Microsoft
pour
savoir à partir de combien de documents on doit séparer SPS et SQL ?
D'autre
part, cela peut-il être fait sans devoir tout réinstaller ?

J'ai bien le SP2 installé.

Cordialement,

Sandra Maury

"Chrislap [MS]" a écrit :

Bonjour,

Vous devez savoir que lors de grand sollicitation du moteur d'indexation
de
SPS2003, il est préconiser d'utiliser une seconde machine SPS2003 dédié à
l'indexation. Cela empêchera de prendre de la CPU pour le rendu
utilisateur.
Un autre axe est de paramétrer l'indexation pour qu'elle n'ai lieu que
lorsque le portail est peu utilisé (la nuit par exemple) afin de ne pas
pénaliser la navigation des utilisateurs.

Pour l'erreur rencontrée, verifiez si votre serveur SPS est en version
SP2.

Cdlt
--
Chrislap [MS]


"Sandra Maury" a écrit dans le
message de news:
> Bonjour,
>
> J'ai programmé dans l'administration de SPS, 3 indexations
> incrémentielles
> par jour pour l'index "non-portal-content". Il y a 30 000 documents
> dans
> mes
> sites et l'index fait 140 Mo.
> Lorsque l'indexation commence les utilisateurs s'en aperçoivent car les
> pages des sites sont longues à charger. Sur le serveur la CPU ne
> dépasse
> pas
> 20% mais le process w3wp.exe en consomme une bonne partie. J'ai 4 Go de
> RAM
> sur ce serveur qui est bi-processeurs. Le fichier d'échange tourne à
> 2,7
> Go.
> En plus de temps en temps j'obtiens cette erreur dans l'observateurs
> d'évènements :
> "L'arrêt d'un processus servant le pool d'application
> 'MSSharePointPortalAppPool' a pris trop de temps. L'identificateur de
> processus était '1160'."
> Je n'ai pas touché au paramétrage des pools d'IIS pour Sharepoint j'ai
> laissé les options par défaut.
> Avez-vous déjà rencontré ce problème ?
> Merci pour vos réponses.
>
> Sandra