Amibien
-
Compteur de contenus
47 -
Inscrit(e) le
-
Dernière visite
Messages postés par Amibien
-
-
tjs est-il que moi après 5h30 "d'indisponibilité" (attention je ne veux pas mettre le feu au poudres avec ce terme), j'avais fini par faire également un reboot hard car j'en pouvais plus, et le serveur est remonté 5mn après...
Bon faut dire aussi que j'avais une sauvegarde qui datait d'a peine quelques h donc j'avais pas grand chose à perdre
Allez à bientôt pour de nouvelles aventures pleines d'adrénaline
-
bah moi c'a marche toujours pas et je commence à trouver le temps long...
-
merci beaucoup dan !
Je sais maintenant que je suis en baie G03 et qu'apparemment je suis le seul serveur hs de cette baie.
J'espère qu'il vont pas passer en dernier dans cette baie
-
en effet visiblement je suis pas le seul :-)
Y'a moyen de savoir dans quelle salle et dans quelle baie on se trouve ?
-
mon dédié est encore hs (pas de ping) y'en a encore qui ont des problèmes la ?
-
Tu l'as eu comment cette réponse, car la page des travaux en cours sur Ovh déconne aussi.
T'a reçu ce message par email ?
-
Bizarre, on observe un retour à la normal hier vers 8h du mat et d'un coup c'a repart en liénaire à partir des valeurs précédentes vers 10h...
Et puis à 19h hier de nouveau rechute
En ce qui concerne le swap, je vérifie régulièrement avec un top, et je confime que ce dernier est bien à 0 tout le temps.
Mem: 498344K av, 459292K used, 39052K free, 0K shrd, 95936K buffSwap: 522104K av, 0K used, 522104K free 50528K cached
-
C'est quand même incroyable cette linéarité.
La courbe continue exactement sur sa lancée encore...
Je graphe également le swap et pour l'instant il est toujours à 0
-
Bonjour
Regarder cette capture de mon serveur :
Bizarrement cette courbe ne cesse d'augmenter depuis env 14h hier et je me dis qu'à priori si c'a s'arrête pas, c'a va bien finir par planter non ?
A noter que c'est la seule courbe MRTG qui fait ca. Tout le reste (proc, mémoire, bits émis recus etc.) se comportent normalement...
Vous avez une idée de ce que c'a peut être
-
bon rebelotte plantage hier soir... ovhm hs, apache hs, j'ai pu accéder uniquement au ssh et faire un reboot
J'ai effectué un check disk aujourd'hui, rien d'anormal...
Quelques pics mrtg cependant (cf url de mon précédent post)
Je viens de tomber en revanche sur une doc intéressante :
configuration du serveur:les serveurs qui sortent d'ovh sont testés 48H sur nos bancs d'essais.
pendant ces tests on bride les serveurs web en nombre de connexion
simultané qui est souvent en fonction de la RAM disponible sur le
serveurs. Ce bridage permet d'avoir un serveur stable même pendant
les attaques flood ou des surchargés su serveur. Par contre si vos
visiteurs sont plus nombreaux que le nombre de connexion max alors
_ça rame_ . En gros ils attendent qu'une connexion se libere.
Vous avez aussi compris qu'il est donc à éviter le download massives
des fichiers via le web vu que le telechagement prend souvent
plusieurs minutes. Si vous avez 100 connexions ouverts (128RAM) et
vous avez 1 clients par sec et ça dure plus que 100 sec son telechargement
vous saturez le serveur web et ça rame alors que le serveur a du CPU
libre. Il faut utiliser le ftp anonymous pour ce genre des choses
lequel est possible en plus brider à nombre de connexions simultanés
et la bande passante par connexion. Bref.
l'option dans httpd.conf la variable qui fixe ceci est
MaxClients 30
permet de choisir le nombre de connexion en simu. Ne debridez pas cette
valeur si vous ne faites pas l'augmentation de la RAM sinon votre
serveur swappera et tombera en 2sec. Il faudra le rebooter EN HARD
et un check des disques s'imposera (entre 20-90minutes). Donc
si votre nombre de connexion est au max, il faut augmenter la RAM
et monter le nombre de MaxClients. Le problème est qu'après l'augmentation
de la RAM, nous on ne fait plus des tests en charge et on ne peut
que se baser sur l'experiance pour fixer le MaxClients, alors tout
depend du CPU/IDE/SCSI/RAID/type des connexion etc. voilà voilà.
Je vérifie ma conf et je contaste que mes paramètres sont les suivants :
MaxKeepAliveRequests 100KeepAliveTimeout 15
MinSpareServers 10
MaxSpareServers 20
StartServers 15
MaxClients 150
MaxRequestsPerChild 60
Pourquoi ce paramètre de conf ne semble pas bridé (je possède 512 mo de ram ce qui ne me semble pas enorme).
Dois-je diminuer sa valeur et si oui à cb ?
Quand est-il des autres paramètres, sont -ils bien paramétrés ?
-
Moi c'est revenu vers 17h45 env et depuis c'a semble tenir (je dis çà en croisant les doigts
)Vous êtes sur que les travaux indiqués sur la carte SLB impliquait aussi les dédiés ? On a pas l'impression quand on regarde dans quelles catégories c'a a été classé.
-
Y'a pas eu une grosse coupure Ovh vers 17h15 aujourd'hui ?
Je pouvais ni accéder à mon site, ni ovh ni webmasterhub... y'a surement eu beaucoup d'autres webmasters qui ont du le remarquer.
-
Snif, je reviens vers vous car même après avoir fait la modif dans le fichier mysql, les plantages continuent...
Toujours pareil, ftp ok, apache ok, mails ok, mais mysql et ovhm HS...
L'intervention du technicien a donné ca :
Voici le détail de l'intervention réalisée:2006-04-13 17:41:43 - Votre serveur ne ping plus
2006-04-13 17:52:53 - rachid prends en charge l'intervention
2006-04-13 18:13:15 - rachid a fait: Downgrade hardware
le serveur etait sur ecran noir.
apres reboot ping ok,
amelioration du refroidissement cpu.
A titre informatif, le temps de resolution de l'incident a ete de:
31 minutes 32 secondes
C'est la 1ère fois d'ailleurs que j'entends parlé de downgrade... ils m'ont mis un pentium 100 en CPU ?
J'ai profité de tous ces plantages pour ajouter également quelques infos mrtg :
*ttp://ns31893.ovh.net/mrtg/
*ttp://ns31893.ovh.net/mrtg/qmail
J'ai remarqué au moment du plantage une utilisation CPU à 90-100%, et utilisation du swap
Mais tout çà me semble la plupart du temps bien peu surchargé...
En espérant que vous aurez d'autres pistes de recherches
-
Tu as raison, je m'en vais de ce pas m'occuper de ces fichiers temporaires.
Pour moi c'est mysql. Pense aussi à vérifier ta base de données et à mettre un index sur tous les champs que tu trouves après 'WHERE..." dans tes scriptsTu peux m'en dire un peu plus sur cet index
A quoi sert-il, comment le mettre, ou lien vers une éventuelle doc à ce sujet ?
Merci encore pour ton aide.
Pour l'espace au moment des crash, j'ai juste remarqué que la ram ne semblait pas saturée... je vais essayer d'obtenir plus d'info la dessus.
-
Merci pour cette info Dan.
Ce qui m'étonne quand même c'est que la base est loin d'être grosse (10-15 mo !) et j'imaginais qu'un dédié dans une conf de base était capable de gérer un trafic vraiment pas exagéré du style un millier de visiteurs par jour...
Tu penses toujours que celà peut en être la cause avec de si faibles données ?
-
Bonjour à tous,
Je fais appel à vos connaissances car depuis trois mois, notre serveur dédié plante de plus en plus souvent et le support OVH semble galérer pour résoudre le problème :'(
Le problème est le suivant :
Sans prévenir la base mysql devient inacessible, il m'est alors impossible de redémarrer le serveur via l'admin. La seule solution à mon niveau est de rebooter la machine.
Suite à ces plantage, je vous dresse la liste des opérations effectuées (vous remarquerez que certaines sont bien étonnantes vis à vis de la panne)
Voici le détail de l'intervention réalisée:2006-04-1 17:32:50 - Votre serveur ne ping plus
2006-04-01 18:03:09 - Thibault prends en charge l'intervention
2006-04-01 18:03:25 - Thibault a fait: Remplacement de l alimentation
alim hs
installation d'une nouvelle alim
ping ok ssh ok
Voici le détail de l'intervention réalisée:2006-03-25 00:16:08 - Votre serveur ne ping plus
2006-03-25 00:22:20 - khaled prends en charge l'intervention
2006-03-25 00:27:41 - khaled a fait: Remplacement de l alimentation
Alimentation HS, changement du bloc d'alim,
vérification du cpu ok,
le serveur est sur login, port SSH open,ping ok.
Voici le détail de l'intervention réalisée:2006-03-24 18:50:45 - Votre serveur ne ping plus
2006-03-24 20:53:06 - cedric prends en charge l'intervention
2006-03-24 21:29:43 - cedric a fait: Remplacement par un spare
SYSTEME de refroidissment hs. remplacer.serveur remplacer par un sapre. ping ok sur login
Voici le détail de l'intervention réalisée:merci de verifier la RAM de ce serveur qui plante avec des messages d alerte sur la ram
Date: 2006-03-24 18:42:58 cedric a fait: Vérification du serveur
remplacement de la ram, car erreur dans les log. ping ok sur login . ssh open
Voici le détail de l'intervention réalisée:2005-11-17 04:38:31 - Votre serveur ne ping plus
2005-11-17 05:04:00 - cedric prends en charge l'intervention
2005-11-17 05:22:09 - cedric a fait: Remplacement de l alimentation
alim hs remplacer;ping ok sur login
Nous avons le plaisir de vous annoncer que l'interventionsur votre serveur ns31893.ovh.net s'est terminiee avec succes.
Pour rappel, il ete realise sur votre serveur:
- upgrade de la ram
Date de debut d'intervention: 2005-06-27 11:59:52
Date de fin d'intervention: 2005-06-27 12:02:44
Bilan, en quatre mois, trois alim, de la ram, un spare... Je trouve que celà commence à faire beaucoup et j'en appelle donc à vos expériences.
Je note régulièrement le même message d'erreur avant que la base (puis le serveur) plante.
Ce message est le suivant :
Apr 1 16:04:30 ns31893 kernel: VM: killing process httpdApr 1 16:04:50 ns31893 kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0)
Apr 1 16:05:21 ns31893 last message repeated 5 times
Apr 1 16:06:31 ns31893 last message repeated 10 times
Apr 1 16:06:53 ns31893 last message repeated 4 times
Apr 1 16:08:00 ns31893 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Apr 1 16:08:02 ns31893 kernel: VM: killing process httpd
Apr 1 16:08:02 ns31893 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Apr 1 16:08:02 ns31893 kernel: VM: killing process httpd
Je vous en prie heeeeeeeeelp
-
C'a serait le rêve n'empêche une caisse équipée d'un gps et cartographie gg earth même pourrie mais financée par les adsenses
-
Bigdaddy is a software upgrade to Googles infrastructure that provides the framework for a lot of improvements to core search quality in the coming months
Dois-t-on comprendre qu'actuellement les vrais fonctionalités de l'algo de bigdaddy sont bridées pour sans doutes favoriser les tests, et que ce dernier bénéfiera de nouvelles optimisations un peu plus tard ?
-
J'ai été surpris de voir ce post remonter dans la liste... cela fait longtemps qu'il avait été abandonné smile.gif
Pour une fois je remercie celui qui a réactualisé ce post, il était très intéressant.
Ps : je note au passage que tes messages Dan sont passés de 3000 à presque 12000 !!! plutôt impressionnant
-
En ce qui me concerne, je suis plutôt pessimiste sur les possibilités de renversement de situation...
Il existe tellement de sites à présent, que 80% des interrogations classiques d'internautes trouvent une réponse avec n'importe quel moteur de recherche.
Changer les mentalités ne se fera donc pas à mon avis sur la course à l'efficacité pour s'approcher de 85 ou 90%.
Les seules possibilités serait une communication importante, et difficile de battre GG sur ce domaine (ex l'échec cuisant de msn), ou faire preuve d'un patriotisme aveugle, et dans ce domaine la France est loin d'être un modèle.
Ceci dit c'a serait une première belle victoire de l'Europe si celle-ci s'avérait
Je vois plus l'avenir des autres moteurs de recherche dans la spécialisation et les thématiques (photo, vidéo, littérature, loisirs, actualité etc.).
Mais cette fois, il seraient directement opposés aux annuaires...
Enfin, je trouve qu'Exalead est hyper dur à prononcer et fait pas du tout "européen"
-
De toute façon gd ou pas, dès que l'on modifie le contenu, la navigation, le titre ou la description de ses pages (l'index n'est pas la seule page où le titre et les descriptions ont de l'importance) on a toujours droit à un bon déclassement...
Après c'a revient plus ou moins vite en fonction de l'importance des modifs mais en général il faut un bon mois au minimum pour retrouver des positions correctes.
C'est la raison pour laquelle beaucoup hésitent entre refaire un site de a à z une fois par an ou faire des petites corrections régulières.
-
Si c'est tout le contenu de la page qui est trafiqué, c'est un autre problème que mon outil n'a nullement l'ambition d'adresser.
La seule solution envisageable serait de passer après le robot comme internaute lambda, lire la page et l'envoyer au MR pour comparaison avec le cache.
Et c'est une toute autre histoire...
A nouveau, je pense que ce genre d'approche "internaute mystère" serait très intéressante.
Il ne s'agit pas de vérifier toutes les pages mais, disons, les dix premières sur les 20 % de mots clés représentant 80 % des recherches, et ce de façon aléatoire.
Contrôle anti-dopage est probablement la meilleure analogie.
Et je verrais très bien une communauté comme le Hub jouer les contrôleurs.
Bon je mélange encore un peu les termes cloaking, pages satellites, redirections etc. car je suis novice, mais il me semble que le problème en gros c'est qu'il est possible d'afficher une page en fonction du visiteur cad de son ip.
Les moteurs étant surveillés, connus, et ne pouvant avoir des ip qui changent à tout bout de champs, ils restent donc quelques que soient leurs méthodes, identifiables et sujets à cette fraude...
Faire appel à une communauté par définition variable et illimité qui comparerai ses "maigres" résultats en terme de pages indéxées par site, avec le même panel de page disons scannées par google (on parle donc d'un partenariat avec les moteurs) me semblerait donc une bonne méthode pour distinguer du contenu traffiqué et du contenu utile.
Et puis pour les dommages collatéraux, google a à mon avis une échelle d'évaluation suffisament large pour faire perdre quelque places a un site utilisant des techniques peu habituelles mais pas systématiquement mal intentionnées sans pour autant le faire complétement disparaitre.
Un tout dernier mot au sujet de jagger, il semble que nous devons encore faire face à sa version 2 puis 3 dans les prochaines semaines donc il nous réserve peut être de très agréables surprises en terme de détection de spam...
Il faut quand même lui reconnaitre que c'a bouge ces temps-ci sur ce point.
-
Dans notre cas nous avons privilégié le .fr et juste réservé le .com (la redirection est prévue) et au final nous commencons à avoir des doutes sur ce choix
Nous avons remarqué que pour de nombreux utilisateurs, le .fr parait moins "fort" qu'un .com
Le .fr étant encore peu répandu, je crois que les mentalités donnent encore plus de sérieux au .com qu'un .fr
Et puis j'émet le doute (mais j'attends le point de vue des pros à ce sujet) que google préfère encore les .com aux .fr (une fois encore pour leurs dimensions international)
En bref je ne suis pas sûr pour l'instant que le fr doit être l'extension prioritaire de ton site...
-
Bonjour,
Pourriez vous êtes plus précis sur cette histoire d'entetes jouant un rôle dans le positionnement des moteurs ?
Premature end of script headers
dans PC-Gyver
Posté · Modifié par Amibien
Bonjour à tous,
Il y a un an, j'avais décrit mes multiples péripécies sur un serveur qui tombait très régulièrement.
Le sujet avait été évoqué ici :
http://www.webmaster-hub.com/index.php?sho...c=23254&hl=
Depuis celà toutes les modifs ont été effectués (répertoire des fichiers temporaires, index...)
Celà n'a jamais rien arrangé et c'a fait donc un an que nous rebootons tous les jours ce serveur suite aux plantages.
Lassés nous avons décidé il y a deux jours de changer de serveur.
Nous pensions alors que celà pouvait provenir du disque dur qui était fatigué, et puisque les nouvelles offres Ovh sont bien plus interessantes que notre serveur actuel, pourquoi nous en priver....
Nous avons donc effectué la migration le jeudi 31 mai et voilà que ce matin, soit pile un jour après, ce nouveau serveur est lui aussi par terre
Ne sachant plus quoi faire, je fais à nouveau appel à vous.
ps :
En jetant un oeil au ficchier error_log de apache, j'ai remarqué les messages suivant curieusement au même moment de la panne :
Merci d'avance pour votre aide