Discussion :

[Invité]

Bonjour à tous,

Depuis la refonte récente de notre site internet, notre serveur IIS v6.0 plante (chargement sans fin) 2 à 4 fois environ par jour : il nous faut donc, à chaque fois, redémarrer manuellement les services IIS.

Voici la config système de notre serveur :



Pour information, nous avons modifié les propriétés de l’« application pools » comme ceci :



le paramètre « connection timeout » de notre site :



et ajouté une page 404 personnalisée.



Dans un premier temps nous avons vérifié :

- La totalité des fichiers .asp : les connections, enregistrements et autres objets sont ouverts/fermés proprement (donc aucune boucle sans fin). De plus, aucune erreur de code n’a été détectée.
- Les fichiers .js : aucune incompatibilité semble exister entre les différents scripts (jquery version 1.8.2 étant utilisée)

Nous nous sommes tournés, par la suite, vers les fichiers logs, et il y aurait probablement une piste : chaque crash serveur, correspond à une visite d’un bot (googlebot, googlebot-image, msnbot, bingbot etc…) quelques secondes avant.

Voici un exemple :



Nous avons redéfini le crawl-delay de notre fichier robots.txt à 5 (donc plutôt lent) et revu la vitesse d’exploration, via les « outils pour les webmasters » de Google, à la baisse.

Le nombre de pages indexées a quasiment doublé depuis la mise en place de notre nouveau site (15 850 => 28 592, à ce jour).
Le nombre moyen de visiteurs uniques est de 400.

Avez-vous une explication ? d’autres pistes ? Notre config serveur est-elle tout simplement suffisamment performante pour « encaisser » les connections des différents bots ?

Nous comptons opter prochainement pour un serveur (hébergé en interne, comme celui actuel) Windows 2008 avec IIS 7.


J’ai essayé de vous apporter un minimum d’informations, s’il vous faut d’autres renseignements, n’hésitez pas.

Merci à vous.

[fredoche]

salut

Si c'est IIS qui plante, tu n'en trouvera pas trace dans les logs IIS que tu affiches ici, qui sont des logs dédiés aux requêtes http/https de tes sites


que disent tes logs dans l'observateur d'événement ?


Si c'est l'url demandé par un bot qui fait planter, il est facile de le vérifier en demandant la même URL, tu devrais avoir le même plantage. A tester pour éliminer cette option qui me parait très hypothétique.

En principe ta machine a largement de quoi tenir la route au niveau matériel.

[Invité]

Bonjour Fredoche et merci pour ta réponse.

N'ayant pas vraiment l'habitude d'aller dans l'observateur d'événements, j’espère que les informations ci-dessous correspondent à ce que tu demandes.

- Voir les évènements "application"
- Voir les évènements "System"

(J'ai essayé, pour chaque "Error" ou "Warning" de mettre à quoi cela correspondait.
Pour les "Error" sans explications du system, cela correspond à des erreurs diverses internes : imprimantes, pdf, etc...)

En sachant que notre serveur a planté ce matin : 2012-11-05 10:49:56

Si c'est l'url demandé par un bot qui fait planter, il est facile de le vérifier en demandant la même URL, tu devrais avoir le même plantage. A tester pour éliminer cette option qui me parait très hypothétique.

Cela fut un de nos premiers tests effectivement, et les urls visitées ne posent aucun problème.

Merci.

Edit 05/11/12 à 14h58 :
Nouveau plantage. Dans les évènements système, j'ai ceci ? Coïncidence ? Je vais essayer d'obtenir des informations sur cette erreur

[fredoche]

Les erreurs affichés dans le journal d'application sont plutôt assez anciennes, je ne crois pas que ce soit lié à ton plantage IIS.

Tu y trouves une erreur ASP qui doit pouvoir être corrigée facilement, Le 2) est en principe sans importance, le 3) qui concerne isapi_rewrite lite pourrait être un éventuel indicateur de tes problèmes : tu fonctionnes en IIS 32 bits sur une plateforme 64 bits. En attendant, aucun de ces événements n'est la source directe de tes problèmes

Dans l'event log système, tu as bien trace de tes plantages avec les points 2 et 3, et c'est vrai que cela arrive souvent (83 et plus).
Le point 1 est consécutif au 2 et 3, je ne sais pas trop si cela peut en être la cause. Tu dois pouvoir retrouver la DLL correspondante à partir du CLSID, en faisant une recherche dans la base de registre (regedit.exe), puis corriger le problème évoqué avec le service de composants.

J'essaierais ça, et et de faire tourner IIS en 64 bits pour voir, d'ailleurs j'essaierais le 64 bits avant de bricoler la DLL.

Mais bon tu as peu d'infos sur ton plantage de toute façon. Etant donné qu'il se reproduit régulièrement, tu peux chercher d'autres concomitances lors des précédents plantages, ou bien essayer de retrouver les mêmes.

Pour ma gouverne, tes services IIS admin et WWW publishing ne sont pas paramétrés pour un redémarrage auto ? Ils ne redémarrent pas seuls ?

[Invité]

Tu y trouves une erreur ASP qui doit pouvoir être corrigée facilement

C'est corrigé : cela venait d'une autre application web très simple, indépendante de notre site.

le 3) qui concerne isapi_rewrite lite pourrait être un éventuel indicateur de tes problèmes : tu fonctionnes en IIS 32 bits sur une plateforme 64 bits.

C'est de ma faute, j'ai téléchargé puis tenté d'installer la mauvaise version . Également corrigé depuis.

Tu dois pouvoir retrouver la DLL correspondante à partir du CLSID, en faisant une recherche dans la base de registre (regedit.exe), puis corriger le problème évoqué avec le service de composants.
J'essaierais ça, et et de faire tourner IIS en 64 bits pour voir, d'ailleurs j'essaierais le 64 bits avant de bricoler la DLL.

Comme tu l'as évoqué, je vais attendre un peu avant de modifier la DLL, de risque de faire une fausse manip' sur quelque chose que je ne maîtrise pas pour le moment.

Nous allons acheter un nouveau serveur (c'était prévu), passer sur Windows Server 2008 R2 SP1, Standard Edition x64 et installer IIS 7 64 bits, en espérant que cela résolve tout simplement le problème (mais dans ce cas on ne saura pas vraiment d'où venait l'erreur...)

Pour ma gouverne, tes services IIS admin et WWW publishing ne sont pas paramétrés pour un redémarrage auto ? Ils ne redémarrent pas seuls ?

Est-ce bien ces paramétrages dont tu parles :
IIS Admin Service
World Wide Web Publishing service

Je viens de mettre "Restart the service" pour la "first failure". Le paramètre par défaut "Take no action" était utilisé.

Merci.

Edit : Le "Restart the service" pour la "first failure" n'ayant rien changé, je l'ai également mis pour la "second" et les "subsequent failures"

Edit 2 : Re-plantage, cela ne change rien, je l'ai remis en "Take no action" par defaut.

[fredoche]

salut

je viens de lire tes messages, plus les édits.

Dommage que tu ne suives pas les conseils donnés, tu aurais pu progresser vers la solution, notamment en faisant la recherche dans la base de registre ... que tu n'as pas fait visiblement

moi j'ai fait cette même recherche sur le CLSID sur google, et voici ce que l'on trouve :
http://support.microsoft.com/kb/290398/fr

Lis en entier et essaye de comprendre, ok ?

je soupçonne que tu fasses tourner IIS sous l'identité de "Network service". Si ce n'est le cas, tu dois avoir cette identité quelque part sur ton pool d'application ou autre.

Visiblement ton IIS plante, tente d'appeler le débuggueur, mais l'accès lui est refusé du fait de l'impersonnalisation sous "Network service".
Peut être que tu auras plus d'infos sur tes plantages, peut être même qu'ils disparaitront si tu ramènes cette impersonnalisation à "System", l'identité par défaut du service.

Ou sinon suis la procédure pour donner des droits à network service sur ce composant.

Là tu as des éléments. A toi de jouer.

[Invité]

Bonjour Fredoche,

Entre ta dernière réponse et mes précédents edits, j'avais bien entendu fait des recherches sur internet + base de registre comme tu me l'avais suggéré

Ce sujet, entre autres, m'avait mis sur la voie : j'ai donc ajouté le profil "Network service" et lui ai attribué les droits nécessaires. Depuis, il n'y a effectivement plus l'erreur en question dans l'observateur d'évènement, c'est donc une bonne chose et je te remercie pour cela.

Le serveur n'a pas planté une seule fois hier. Malheureusement ce ne fût pas le cas cette nuit* : obligé de le redémarrer ce matin même.

* je ne peux pas être plus précis, ne connaissant pas l'heure exacte du plantage mais peut-être qu'il y a un rapport avec le "warning" à 3h15 du matin. Je vais encore faire quelques recherches là dessus



(Les deux erreurs à 10h39 correspondent au redémarrage manuel).

Merci pour tes réponses

[fredoche]

tes services IIS admin et WWW fonctionnent avec "network service" comme compte de fonctionnement ?

Y'a t'il une raison à cela ?

Pourquoi as tu des erreurs lors du redémarrage manuel ? Que disent ces erreurs exactement ?

C'est assez étonnant que ces plantages ne laissent pas de traces dans tes logs.

[Invité]

tes services IIS admin et WWW fonctionnent avec "network service" comme compte de fonctionnement ?

Y'a t'il une raison à cela ?

J’essaie d'avoir l'info (n'ayant pas installé/configuré personnellement ce serveur et les outils présents dessus).

Pourquoi as tu des erreurs lors du redémarrage manuel ? Que disent ces erreurs exactement ?

Voilà les 3 évènements qui apparaissent après redémarrage manuel du serveur.

[Invité]

Bonjour, des nouvelles du front :

nous avons mis en place notre nouveau serveur Jeudi dernier (Windows Server 2008 R2). Malheureusement, il a déjà planté deux fois depuis : Vendredi dernier vers 16h10 et ce matin même vers 9h30, comme peut le montrer l'observateur d'évènements

J'ai regardé l'aide pour l'évènement 5138 mais hormis le redémarrage des services ils ne préconisent rien.

J'avoue être un peu perdu dans ce nouvel observateur d'évènements, donc je ne sais pas trop quoi/où regarder pour trouver une piste.

Je ne sais pas si cela peut aider mais voici la config. de nos services (nous n'avons rien modifié) :
- Liste services 1
- Liste services 2
- Liste services 3

Ce que je ne comprends pas c'est que, même si l'on part sur le fait qu'il y ait une erreur de code, la boucle devrait s'arrêter à un moment ? (le server.timeout n'a pas été modifié) et donc le serveur re-fonctionner après un laps de temps ?

Peut-il y avoir également un quelconque rapport avec notre firewall ? notre serveur DNS ? (ça n'a peut-être aucun rapport mais honnêtement, je ne sais plus trop où chercher)

Merci.

[fredoche]

les services iis_admin et publication WWW tournent toujours avec le compte "network service" ?

le truc que tu as regardé, 5138, n'est pas la cause d'un plantage à mon avis.

[Invité]

A vrai dire, je ne vois plus que les utilisateurs "Système" et "N/A" dans l'observateur d'évènements pour les divers évènements qui y sont remontés.

Le dernier "SERVICE RESEAU" (nous sommes passés à la version française mais je suppose que c'est la traduction de "network service" ) date du 12/12/12 et, entre temps le serveur a bien planté plusieurs fois.

Question (qui a peut-être rien à voir) : est-ce normal que la taille virtuelle de notre pool d'application atteigne 1 000 000 Ko et plus ? (je n'ai pas encore pu vérifier que la plantage se faisait lorsque que cette taille critique était atteinte / Ne pas se fier à la capture d'écran qui n'est qu'à 327 272 Ko)

Merci.

[fredoche]

Pour la RAM, je ne crois pas que ce soit un souci, 1 Go quand tu en as beaucoup plus, c'est le but que de la remplir.

Etonnant tes plantages quand même. Tu n'utilises pas urlscan ou un truc équivalent ?

Ton appli ne se base pas sur des dll plus ou moins instables ?

[Invité]

Bonjour,

je n'avais pas oublié ce sujet et souhaitais y apporter la solution lorsque que nous l'aurions trouvé et... nous l'avons trouvé (enfin) ! Notre site ne plante plus !

Pour la connexion à notre base Access (.accdb), j'utilisais ces deux lignes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Set conn = Server.CreateObject("ADODB.Connection")
conn.Open ("Provider= Microsoft.ACE.OLEDB.12.0;Data Source=" & Server.MapPath("Emplacement de la base/NomBase.accdb"))

que j'ai finalement remplacé par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Set conn = Server.CreateObject("ADODB.Connection")
conn.Open "nomDeLaSourceDeDonnées"

Après avoir configuré cette même connexion (ainsi que deux autres, par la même occasion...) via L'administrateur de sources de données ODBC sur notre serveur.

L'administrateur de sources de données ODBC existant en deux versions (32 et 64 bits), j'ai du ouvrir la version 32 bits (bien qu'étant en 64 bits sur le serveur) accessible sur C:\\Windows\SysWOW64\odbcad32.exe et ajouté les Sources de données système nécessaires.



Voilà, cette manip. fonctionne pour nous, ça peut peut-être aider quelqu'un d'autre.

PS : Encore merci Fredoche pour tes réponses ci-dessus.