Identifiez-vous Devenir membre

Rechercher

Connection time apache

61 réponses

Page |<<<1 23 4 >>>|

Auteur	Message
Bool Modérateur Inscrit le : 09/05/2005	# Le 28/02/2008 à 19:20 Hello, l'ipv6 est activé par défaut ; moi ce n'était pas le cas car cet hebergeur (mailclub) prend généralement la peine de désactiver ce qui ne sert pas. Pour s'en assurer, en supposant que tu ais un kernel officiel : lsmod \| grep ipv6 Réseaux sociaux : LinkedIn / Viadeo
midtownmad Membre Inscrit le : 09/05/2005	# Le 29/02/2008 à 10:08 nsXXXXXX:~# lsmod \| grep ipv6 Opening /proc/modules: No such file or directory Ca, c'est fait lol. Mon kernel actuel est en netboot chez OVH sur : 2.4.33 x86 & SMP & GRSEC ; par contre, je vois que le kernel 2.6.24.2 possède l'option ipv6. midtownmad (dit gigi par ses amis) http://www.macreators.com
Bool Modérateur Inscrit le : 09/05/2005	# Le 29/02/2008 à 11:00 Bah dans le cas d'OVH j'aurais tendance à te conseiller de ne pas toucher Ou bien commence par vraiment analyser le problème pour être certain que ça vienne vraiment de là... Réseaux sociaux : LinkedIn / Viadeo
midtownmad Membre Inscrit le : 09/05/2005	# Le 01/03/2008 à 10:20 En faite, j'ai pris l'initiative de mettre le netboot "2.6.24.2 x86 & SMP & IPv6" et quel initiative... cela marche parfaitement, plus de latence sur mes serveurs apache et mysql ! Merci Bool ;). midtownmad (dit gigi par ses amis) http://www.macreators.com
gab Anonyme Inscrit le : 11/05/2005	# Le 18/03/2008 à 23:03 Bonsoir, Je suis en train de rassembler des élements pour corriger ce bug directement dans le kernel. Pour avancer, je cherche un maximum d'infos sur les conditions dans lesquelles le bug arrive pour vous (il m'arrive aussi en prod en permanence, bien qu'on ait trouvé un moyen de le rendre "invisible" au niveau load-balancing) Alors j'aurais donc des questions: - Les plateformes matérielles utilisées (SMP uniquement? J'ai cru comprendre que des serveurs dual-core n'ont jamais le problème alors que les quad-cores l'ont?) - Les kernels utilisés, et les options notables activées. - Quels trucs et astuces vous ont permi de "résoudre" le problème, et si c'est définitif. j'ai par exemple vu un cas ou l'ipv6 n'avait corrigé le problème que momentanément. - Le réseau utilisé (un hébergeur? votre propre réseau? Si oui quelles specs?) - A partir de quelle version du kernel cela vous arrive-t-il ? J'ai pu reproduire les problèmes de mon côté à partir de 2.6.23.*, et même eu des cas à partir de 2.6.20.7 Un aspect interessant est que le problème n'est pas du tout lié à la qualité du réseau, car si j'ai bien compris le problème est reproduisible en faisant des connexions vers 127.0.0.1 ??? Si cela est confirmé, c'est un aspect très important (=problème du côté de la couche réseau et non du driver de la carte réseau). Pour l'explication, il s'agit d'un timeout de retransmission du ACK client lors de la connexion TCP (le "3ème serrage de main"), qui est précisément de 3 secondes. Cela n'a rien à voir avec l'application MySQL ou PHP ou autre, ni la qualité du réseau, ni netfilter/conntrack. Le fait que le problème soit résolu (ou au moins temporairement), avec la pile IPv6 est que le protocole ne gère pas de la même manière les sessions TCP et la congestion réseau. Ce problème étant particulièrement important, latent depuis pas mal de versions du kernel, mais pas du tout facile à tester/reproduire et encore moins à corriger, vos retours seraient grandement appréciés. Vous pouvez me contacter directement par message privé ou par e-mail pour ceux qui me connaissent déjà. Bien évidemment dès qu'un patch est disponible, il sera mis à dispo pour ceux qui savent compiler leur propre kernel, en attendant d'être intégré dans la prochaine version officielle. Merci d'avance pour vos retours! PS: la config de votre kernel _peut_ se trouver compressée dans /proc/config.gz, si l'option en question à été activée dans le kernel. Dans le cas d'OVH, les kernels sont compilés sans support des modules (ce qu'on appelle une compilation monolithique/statique) et il n'y a donc pas de "modules". Pour vérifier la présence d'ipv6 à coup sur, il suffit de voir si le fichier /proc/net/tcp6 existe. Gabriel
Bool Modérateur Inscrit le : 09/05/2005	# Le 18/03/2008 à 23:48 Hello, grande nouvelle tout ça ! Je rencontre toujours le soucis, quelques centaines de fois par jour depuis 2 serveurs web se connectant à 1 serveur MySQL. J'en étais à envisager la migration des sites chez un autre hébergeur (ne serait ce qu'à titre temporaire). Il s'agit de Xeon "netburst : 4 core en HT => 8 CPU "détectés" ; les 3 machines font tourner des Debian etch 64bits. Pour la version minimale je ne saurais dire exactement ; j'ai l'impression d'en avoir testé... Une chose est certaine : de la 2.6.22 (du repository debian backports), à la 2.6.24.2 (kernel vanilla, compilé quasiment avec les mêmes options que le kernel debian). J'ai bien utilisé le kernel 2.6.18 (debian etch) pendant un moment, mais je ne pourrais pas affirmer à 100% qu'il était présent à la fois sur le serveur web et le serveur mysql. Sur les 3 machines il s'agit de cartes "Intel Corporation 631xESB/632xESB DPT LAN Controller Copper". Nous avons rencontré le soucis en utilisant le réseau de l'hébergeur MailClub (100Mbps avec les cartes configurées en 10Mbps FD) ainsi qu'un "mini réseau local" : l'hébergeur a fourni auquel seules nos machines sont branchées, depuis la seconde interface. Cette fois aucun bridage, nous sommes en 100Mbps. Les syncookies sont activés uniquement sur les serveurs Web (meme en les désactivant, ça ne change rien). Je n'ai pas non plus résolu le problème en changeant d'algo de congestion (j'avais testé htcp). Un changement de la taille des fenetres (net.ipv4.tcp_rmem et net.ipv4.tcp_wmem) n'a rien changé non plus. Je viens de voir dans mon sysctl que "net.ipv4.conf.default.forwarding" est à 1, si cela peut avoir un impact... Coté netfilter, j'ai testé avec et sans règles, ça n'a rien changé non plus. Le fait d'activer ipv6 nous a effectivement permis de résoudre le soucis pendant quelques temps.... entre 24 et 48 heures je dirais de tête ; ce qui est déjà énorme comme "trêve". Je précise : le module ipv6 est chargé, mais pas vraiment utilisé, aucune route n'est configuré. On tourne depuis plusieurs semaines avec les kernels Debian 2.6.22-4-amd64 ; l'idée était d'avoir la configuration la plus standard possible (on a même été jusqu'à virer le firewall, la conf MySQL, et passer à PDO pour voir.... sans succès évidement). Comme l'a suggéré mon hébergeur aujourd'hui, j'ai ajouté un "socket connect" derrière chaque mysql_connect() afin de vérifier : l'erreur est la même "#110 Connection timed out". Chose (peut être) importante, ces latences sont toujours de 3, 9 ou 27 secondes. Donc pas des multiples de 3 secondes, mais des puissances de 3. Pour limiter la casse j'ai mis un timeout de 4 secondes coté MySQL, et je retente la connexion plusieurs fois. Cela nous a permis d'établir régulièrement la connexion sous 7-8 secondes au lieu des nombreux timeouts qu'on rencontrait. Dois je te communiquer le fichier config de Debian ? Bool / Kioob (que tu as peut être vu sur d'autres forums traitant de ce problème). Réseaux sociaux : LinkedIn / Viadeo
gab Anonyme Inscrit le : 11/05/2005	# Le 19/03/2008 à 00:07 Donc en fait on se croise partout . Les latences de ^3 secondes sont "normales" et codées dans le kernel pour le délai de retransmission d'un etablissement de connexion TCP. Le problème est avec certitude maintenant situé côté client. Avait tu testé ton kernel 2.6.18 sur un serveur web(client) ou mysql ? Etait-ce exactement le même problème ? Si c'est le cas, cela va devenir de plus en plus compliqué de trouver d'ou vient le problème par bisection, il faudra donc le trouver "à la main" et non par test de regression. Tout cela ne nous facilite pas la tache... Ce qui m'interesserais, c'est de confirmer que ce problème arrive aussi en se connectant a 127.0.0.1. Est ce possible? Quel était le protocole de test ? Gabriel
Bool Modérateur Inscrit le : 09/05/2005	# Le 19/03/2008 à 00:13 Le 2.6.18 était à coup sûr sur le serveur MySQL ; mais je n'en suis pas certain pour les serveurs Apache. Pour la connexion en local sur 127.0.0.1, je n'en suis pas certain non plus ; je n'avais pas encore recueilli suffisamment d'infos donc mon test saturait peut être pour une autre raison. J'essayerais de reproduire ça demain. Réseaux sociaux : LinkedIn / Viadeo
Rano Modérateur Inscrit le : 13/04/2005	# Le 09/04/2008 à 22:01 Et bien rebelote pour moi. Ca recommence sur une machine sur laquelle je n'ai rien changée. Et pas forcément plus de trafic... C'est vraiment la loose cette histoire. Pour le localhost, j'avais testé et il y avait bien le problème. Avec un "ab" un peu fort sur localhost, sur une machine pas en prod, ça se produisait. Et pourtant, ça ne faisait pas spécialement monter le load, donc c'était pas un problème de puissance de la machine. Chambres d'hote tavel Séjours en provence Forum mariage
Bool Modérateur Inscrit le : 09/05/2005	# Le 10/04/2008 à 08:49 J'ai fait plusieurs modifs en début de semaine, ce qui semble avoir complètement résolu le problème... reste à savoir laquelle de ces modifs en est la cause Les 2 principales : - mise à jour du kernel 2.6.24.4, qui à ce que j'ai compris résout des problèmes de temporisation avec les Xeon - utilisation de MySQL Proxy... bien que le "connection pooling" ne soit pas encore dispo (du moins, pas en natif). Notre "paliatif" des dernières semaines était de rebooter les machines aussi souvent que possible... ça me rappel Windows 98 Réseaux sociaux : LinkedIn / Viadeo
Bool Modérateur Inscrit le : 09/05/2005	# Le 15/04/2008 à 13:43 Pfiou, donc je confirme, le kernel 2.6.24.4 résoud complètement le problème chez moi. Réseaux sociaux : LinkedIn / Viadeo
Rano Modérateur Inscrit le : 13/04/2005	# Le 20/04/2008 à 09:49 Toujours bon avec le 2.6.24.4 ? Que je vois si je m'aventure dans la compilation de ce kernel J'ai jamais réussi à pondre un noyau qui fonctionne :\| Chambres d'hote tavel Séjours en provence Forum mariage
Bool Modérateur Inscrit le : 09/05/2005	# Le 20/04/2008 à 11:05 Yep yep, plus aucun soucis depuis qu'on est passé à ce kernel. Pour ce qui est de la compilation, rien de bien sorcier : utilises le fichier "config" fournit par Debian, et compile avec "make-kpkg" de Debian. Tout est automatisé. Réseaux sociaux : LinkedIn / Viadeo
Rano Modérateur Inscrit le : 13/04/2005	# Le 21/04/2008 à 00:39 ah oui, effectivement, comme ça c'est plutôt simple J'ai mis le kernel 2.6.25 pour voir si c'est bon. merci Chambres d'hote tavel Séjours en provence Forum mariage
Rano Modérateur Inscrit le : 13/04/2005	# Le 21/04/2008 à 15:02 après quelques heures, tout semble nikel Chambres d'hote tavel Séjours en provence Forum mariage
dob Modérateur Inscrit le : 10/05/2005	# Le 22/04/2008 à 14:02 Toujours nickel ? SDNS.fr - conseil & hébergement web privés
Rano Modérateur Inscrit le : 13/04/2005	# Le 22/04/2008 à 14:20 pour moi c'est tout bon pour les serveurs passés en 2.6.25 Par contre, j'ai essayé de mettre ce kernel sur les dernières machines ovh ( http://www.ovh.com/fr/particulier/produits/mg.xml ). Tout se passe comme sur les anciennes machines, sauf que la machine ne boot plus avec :/ Chambres d'hote tavel Séjours en provence Forum mariage
Bool Modérateur Inscrit le : 09/05/2005	# Le 22/04/2008 à 14:47 Si tes machines n'utilisent pas un Kernel Debian mais un Kernel OVH, c'est le fichier config d'OVH qu'il faut utiliser. C'est probablement la carte RAID hardware qui coince. Réseaux sociaux : LinkedIn / Viadeo
Rano Modérateur Inscrit le : 13/04/2005	# Le 22/04/2008 à 14:50 J'utilise ça à chaque fois : ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6-config-x... en fait, y a que la quantité de ram qui est différente... en apparence en tout cas. Mais j'ai peut etre fait une boulette quelque part, c'est possible. Je m'y suis pris que trois fois en même temps. Il m'en faut généralement une bonne dizaine avant que ça fonctionne Chambres d'hote tavel Séjours en provence Forum mariage
dob Modérateur Inscrit le : 10/05/2005	# Le 24/04/2008 à 09:18 Bonne nouvelle, OVH a passé le netboot en 2.6.24.5 SDNS.fr - conseil & hébergement web privés

Auteur

Message

Bool
Modérateur

Inscrit le : 09/05/2005

# Le 28/02/2008 à 19:20

Hello,

l'ipv6 est activé par défaut ; moi ce n'était pas le cas car cet hebergeur (mailclub) prend généralement la peine de désactiver ce qui ne sert pas.

Pour s'en assurer, en supposant que tu ais un kernel officiel :

lsmod | grep ipv6

Réseaux sociaux : LinkedIn / Viadeo

midtownmad
Membre

Inscrit le : 09/05/2005

# Le 29/02/2008 à 10:08

nsXXXXXX:~# lsmod | grep ipv6

Opening /proc/modules: No such file or directory

Ca, c'est fait lol. Mon kernel actuel est en netboot chez OVH sur : 2.4.33 x86 & SMP & GRSEC ; par contre, je vois que le kernel 2.6.24.2 possède l'option ipv6.

midtownmad (dit gigi par ses amis)
http://www.macreators.com

Bool
Modérateur

Inscrit le : 09/05/2005

# Le 29/02/2008 à 11:00

Bah dans le cas d'OVH j'aurais tendance à te conseiller de ne pas toucher

Ou bien commence par vraiment analyser le problème pour être certain que ça vienne vraiment de là...

Réseaux sociaux : LinkedIn / Viadeo

midtownmad
Membre

Inscrit le : 09/05/2005

# Le 01/03/2008 à 10:20

En faite, j'ai pris l'initiative de mettre le netboot "2.6.24.2 x86 & SMP & IPv6" et quel initiative... cela marche parfaitement, plus de latence sur mes serveurs apache et mysql !
Merci Bool ;).

midtownmad (dit gigi par ses amis)
http://www.macreators.com

gab
Anonyme

Inscrit le : 11/05/2005

# Le 18/03/2008 à 23:03

Bonsoir,

Je suis en train de rassembler des élements pour corriger ce bug directement dans le kernel. Pour avancer, je cherche un maximum d'infos sur les conditions dans lesquelles le bug arrive pour vous (il m'arrive aussi en prod en permanence, bien qu'on ait trouvé un moyen de le rendre "invisible" au niveau load-balancing)
Alors j'aurais donc des questions:
- Les plateformes matérielles utilisées (SMP uniquement? J'ai cru comprendre que des serveurs dual-core n'ont jamais le problème alors que les quad-cores l'ont?)

- Les kernels utilisés, et les options notables activées.

- Quels trucs et astuces vous ont permi de "résoudre" le problème, et si c'est définitif. j'ai par exemple vu un cas ou l'ipv6 n'avait corrigé le problème que momentanément.

- Le réseau utilisé (un hébergeur? votre propre réseau? Si oui quelles specs?)

- A partir de quelle version du kernel cela vous arrive-t-il ? J'ai pu reproduire les problèmes de mon côté à partir de 2.6.23.*, et même eu des cas à partir de 2.6.20.7

Un aspect interessant est que le problème n'est pas du tout lié à la qualité du réseau, car si j'ai bien compris le problème est reproduisible en faisant des connexions vers 127.0.0.1 ??? Si cela est confirmé, c'est un aspect très important (=problème du côté de la couche réseau et non du driver de la carte réseau).

Pour l'explication, il s'agit d'un timeout de retransmission du ACK client lors de la connexion TCP (le "3ème serrage de main"), qui est précisément de 3 secondes. Cela n'a rien à voir avec l'application MySQL ou PHP ou autre, ni la qualité du réseau, ni netfilter/conntrack. Le fait que le problème soit résolu (ou au moins temporairement), avec la pile IPv6 est que le protocole ne gère pas de la même manière les sessions TCP et la congestion réseau.

Ce problème étant particulièrement important, latent depuis pas mal de versions du kernel, mais pas du tout facile à tester/reproduire et encore moins à corriger, vos retours seraient grandement appréciés.

Vous pouvez me contacter directement par message privé ou par e-mail pour ceux qui me connaissent déjà. Bien évidemment dès qu'un patch est disponible, il sera mis à dispo pour ceux qui savent compiler leur propre kernel, en attendant d'être intégré dans la prochaine version officielle.

Merci d'avance pour vos retours!

PS: la config de votre kernel _peut_ se trouver compressée dans /proc/config.gz, si l'option en question à été activée dans le kernel. Dans le cas d'OVH, les kernels sont compilés sans support des modules (ce qu'on appelle une compilation monolithique/statique) et il n'y a donc pas de "modules". Pour vérifier la présence d'ipv6 à coup sur, il suffit de voir si le fichier /proc/net/tcp6 existe.

Gabriel

Bool
Modérateur

Inscrit le : 09/05/2005

# Le 18/03/2008 à 23:48

Hello,

grande nouvelle tout ça ! Je rencontre toujours le soucis, quelques centaines de fois par jour depuis 2 serveurs web se connectant à 1 serveur MySQL. J'en étais à envisager la migration des sites chez un autre hébergeur (ne serait ce qu'à titre temporaire).
Il s'agit de Xeon "netburst : 4 core en HT => 8 CPU "détectés" ; les 3 machines font tourner des Debian etch 64bits.

Pour la version minimale je ne saurais dire exactement ; j'ai l'impression d'en avoir testé... Une chose est certaine : de la 2.6.22 (du repository debian backports), à la 2.6.24.2 (kernel vanilla, compilé quasiment avec les mêmes options que le kernel debian).
J'ai bien utilisé le kernel 2.6.18 (debian etch) pendant un moment, mais je ne pourrais pas affirmer à 100% qu'il était présent à la fois sur le serveur web et le serveur mysql.

Sur les 3 machines il s'agit de cartes "Intel Corporation 631xESB/632xESB DPT LAN Controller Copper".

Nous avons rencontré le soucis en utilisant le réseau de l'hébergeur MailClub (100Mbps avec les cartes configurées en 10Mbps FD) ainsi qu'un "mini réseau local" : l'hébergeur a fourni auquel seules nos machines sont branchées, depuis la seconde interface. Cette fois aucun bridage, nous sommes en 100Mbps.

Les syncookies sont activés uniquement sur les serveurs Web (meme en les désactivant, ça ne change rien). Je n'ai pas non plus résolu le problème en changeant d'algo de congestion (j'avais testé htcp). Un changement de la taille des fenetres (net.ipv4.tcp_rmem et net.ipv4.tcp_wmem) n'a rien changé non plus.
Je viens de voir dans mon sysctl que "net.ipv4.conf.default.forwarding" est à 1, si cela peut avoir un impact...
Coté netfilter, j'ai testé avec et sans règles, ça n'a rien changé non plus.

Le fait d'activer ipv6 nous a effectivement permis de résoudre le soucis pendant quelques temps.... entre 24 et 48 heures je dirais de tête ; ce qui est déjà énorme comme "trêve".
Je précise : le module ipv6 est chargé, mais pas vraiment utilisé, aucune route n'est configuré.

On tourne depuis plusieurs semaines avec les kernels Debian 2.6.22-4-amd64 ; l'idée était d'avoir la configuration la plus standard possible (on a même été jusqu'à virer le firewall, la conf MySQL, et passer à PDO pour voir.... sans succès évidement).

Comme l'a suggéré mon hébergeur aujourd'hui, j'ai ajouté un "socket connect" derrière chaque mysql_connect() afin de vérifier : l'erreur est la même "#110 Connection timed out".

Chose (peut être) importante, ces latences sont toujours de 3, 9 ou 27 secondes. Donc pas des multiples de 3 secondes, mais des puissances de 3.
Pour limiter la casse j'ai mis un timeout de 4 secondes coté MySQL, et je retente la connexion plusieurs fois. Cela nous a permis d'établir régulièrement la connexion sous 7-8 secondes au lieu des nombreux timeouts qu'on rencontrait.

Dois je te communiquer le fichier config de Debian ?

Bool / Kioob (que tu as peut être vu sur d'autres forums traitant de ce problème).

Réseaux sociaux : LinkedIn / Viadeo

gab
Anonyme

Inscrit le : 11/05/2005

# Le 19/03/2008 à 00:07

Donc en fait on se croise partout . Les latences de ^3 secondes sont "normales" et codées dans le kernel pour le délai de retransmission d'un etablissement de connexion TCP.

Le problème est avec certitude maintenant situé côté client. Avait tu testé ton kernel 2.6.18 sur un serveur web(client) ou mysql ? Etait-ce exactement le même problème ?

Si c'est le cas, cela va devenir de plus en plus compliqué de trouver d'ou vient le problème par bisection, il faudra donc le trouver "à la main" et non par test de regression. Tout cela ne nous facilite pas la tache...

Ce qui m'interesserais, c'est de confirmer que ce problème arrive aussi en se connectant a 127.0.0.1. Est ce possible? Quel était le protocole de test ?

Gabriel

Bool
Modérateur

Inscrit le : 09/05/2005

# Le 19/03/2008 à 00:13

Le 2.6.18 était à coup sûr sur le serveur MySQL ; mais je n'en suis pas certain pour les serveurs Apache.

Pour la connexion en local sur 127.0.0.1, je n'en suis pas certain non plus ; je n'avais pas encore recueilli suffisamment d'infos donc mon test saturait peut être pour une autre raison. J'essayerais de reproduire ça demain.

Réseaux sociaux : LinkedIn / Viadeo

Rano
Modérateur

Inscrit le : 13/04/2005

# Le 09/04/2008 à 22:01

Et bien rebelote pour moi. Ca recommence sur une machine sur laquelle je n'ai rien changée. Et pas forcément plus de trafic...
C'est vraiment la loose cette histoire.

Pour le localhost, j'avais testé et il y avait bien le problème. Avec un "ab" un peu fort sur localhost, sur une machine pas en prod, ça se produisait. Et pourtant, ça ne faisait pas spécialement monter le load, donc c'était pas un problème de puissance de la machine.

Chambres d'hote tavel
Séjours en provence
Forum mariage

Bool
Modérateur

Inscrit le : 09/05/2005

# Le 10/04/2008 à 08:49

J'ai fait plusieurs modifs en début de semaine, ce qui semble avoir complètement résolu le problème... reste à savoir laquelle de ces modifs en est la cause

Les 2 principales :
- mise à jour du kernel 2.6.24.4, qui à ce que j'ai compris résout des problèmes de temporisation avec les Xeon
- utilisation de MySQL Proxy... bien que le "connection pooling" ne soit pas encore dispo (du moins, pas en natif).

Notre "paliatif" des dernières semaines était de rebooter les machines aussi souvent que possible... ça me rappel Windows 98

Réseaux sociaux : LinkedIn / Viadeo

Bool
Modérateur

Inscrit le : 09/05/2005

# Le 15/04/2008 à 13:43

Pfiou, donc je confirme, le kernel 2.6.24.4 résoud complètement le problème chez moi.

Réseaux sociaux : LinkedIn / Viadeo

Rano
Modérateur

Inscrit le : 13/04/2005

# Le 20/04/2008 à 09:49

Toujours bon avec le 2.6.24.4 ? Que je vois si je m'aventure dans la compilation de ce kernel
J'ai jamais réussi à pondre un noyau qui fonctionne :|

Chambres d'hote tavel
Séjours en provence
Forum mariage

Bool
Modérateur

Inscrit le : 09/05/2005

# Le 20/04/2008 à 11:05

Yep yep, plus aucun soucis depuis qu'on est passé à ce kernel.

Pour ce qui est de la compilation, rien de bien sorcier : utilises le fichier "config" fournit par Debian, et compile avec "make-kpkg" de Debian. Tout est automatisé.

Réseaux sociaux : LinkedIn / Viadeo

Rano
Modérateur

Inscrit le : 13/04/2005

# Le 21/04/2008 à 00:39

ah oui, effectivement, comme ça c'est plutôt simple J'ai mis le kernel 2.6.25 pour voir si c'est bon. merci

Chambres d'hote tavel
Séjours en provence
Forum mariage

Rano
Modérateur

Inscrit le : 13/04/2005

# Le 21/04/2008 à 15:02

après quelques heures, tout semble nikel

Chambres d'hote tavel
Séjours en provence
Forum mariage

dob
Modérateur

Inscrit le : 10/05/2005

# Le 22/04/2008 à 14:02

Toujours nickel ?

SDNS.fr - conseil & hébergement web privés

Rano
Modérateur

Inscrit le : 13/04/2005

# Le 22/04/2008 à 14:20

pour moi c'est tout bon pour les serveurs passés en 2.6.25
Par contre, j'ai essayé de mettre ce kernel sur les dernières machines ovh ( http://www.ovh.com/fr/particulier/produits/mg.xml ). Tout se passe comme sur les anciennes machines, sauf que la machine ne boot plus avec :/

Chambres d'hote tavel
Séjours en provence
Forum mariage

Bool
Modérateur

Inscrit le : 09/05/2005

# Le 22/04/2008 à 14:47

Si tes machines n'utilisent pas un Kernel Debian mais un Kernel OVH, c'est le fichier config d'OVH qu'il faut utiliser. C'est probablement la carte RAID hardware qui coince.

Réseaux sociaux : LinkedIn / Viadeo

Rano
Modérateur

Inscrit le : 13/04/2005

# Le 22/04/2008 à 14:50

J'utilise ça à chaque fois : ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6-config-x...
en fait, y a que la quantité de ram qui est différente... en apparence en tout cas. Mais j'ai peut etre fait une boulette quelque part, c'est possible. Je m'y suis pris que trois fois en même temps. Il m'en faut généralement une bonne dizaine avant que ça fonctionne

Chambres d'hote tavel
Séjours en provence
Forum mariage

dob
Modérateur

Inscrit le : 10/05/2005

# Le 24/04/2008 à 09:18

Bonne nouvelle, OVH a passé le netboot en 2.6.24.5

SDNS.fr - conseil & hébergement web privés

Page |<<<1 23 4 >>>|

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.