Je poste mon message ici car il m'est impossible de contacter
PhpNet.org, mon hébergeur, suite à une panne de la base de données du
serveur 1 depuis 13h45 (cf. http://www.phpnet.org/forum/ pour une démo !)
En effet, l'astreinte téléphonique n'est pas assurée en cette période de
vacances, et les autres moyens de signaler les pannes sont le forum, et
le panel de gestion du site. Ils reposent tous les deux sur cette
fameuse base cl1-sql1, qui est en panne. C'est donc la fête, donc,
d'autant qu'en ce moment, les défaillances de cette base de données qui
affectent tantôt une table, tantôt une autre, et obligent à réparer ces
tables sont nombreuses !
J'espère que ce sera vite réparé, et j'invite les autres utilisateurs
victimes de cette panne à en discuter ici.
"BlueWhisper" a écrit dans le message de news:ce7p3p$98f$
Faudra également que tu m'expliques comment changer la ram par télépathie, ça m'intéresserait...
Sincèrement,
Laurent Fasnacht ben moi je change pas de ram je met de la ECC d'office sur mes machines
avant de les mettres en prod et puis je ne charge pas comme un malade mes serveurs. 80/85 sites maxi par machines comme cela je ne suis pas obligé d'aller chez LDCOM tout le temps.... et puis j'ai un tech sur place au cas ou je viens de le dire dans le post precedent hébergeur est un METIER....
"BlueWhisper" <BlueWhisper-nospamplz@o-t.ch> a écrit dans le message de
news:ce7p3p$98f$1@newshispeed.ch...
Faudra également que tu m'expliques comment changer la ram par
télépathie, ça m'intéresserait...
Sincèrement,
Laurent Fasnacht
ben moi je change pas de ram je met de la ECC d'office sur mes machines
avant de les mettres en prod
et puis je ne charge pas comme un malade mes serveurs.
80/85 sites maxi par machines
comme cela je ne suis pas obligé d'aller chez LDCOM tout le temps....
et puis j'ai un tech sur place au cas ou
je viens de le dire dans le post precedent hébergeur est un METIER....
"BlueWhisper" a écrit dans le message de news:ce7p3p$98f$
Faudra également que tu m'expliques comment changer la ram par télépathie, ça m'intéresserait...
Sincèrement,
Laurent Fasnacht ben moi je change pas de ram je met de la ECC d'office sur mes machines
avant de les mettres en prod et puis je ne charge pas comme un malade mes serveurs. 80/85 sites maxi par machines comme cela je ne suis pas obligé d'aller chez LDCOM tout le temps.... et puis j'ai un tech sur place au cas ou je viens de le dire dans le post precedent hébergeur est un METIER....
thibaud
"webvisio" wrote in message news:<41081716$0$12492$...
ben moi je change pas de ram je met de la ECC d'office sur mes machines avant de les mettres en prod
et donc parce ton "metier" est hebergeur, ta superbe ram ecc n'a jamais de defaut ? jamais aucune barette de ECC peut avoir de probleme... normal c'est ton metier
et puis je ne charge pas comme un malade mes serveurs. 80/85 sites maxi par machines
BOOOO je prefere voir deux clusters composés de plusieurs 10enes de machines plutot que des serveurs independants sur lesquels tu ne passes forcement pas 24/24 a controler que chaque machine fonctionne et donc qui tombe plus facilement.
De tt facon, un bon hébergeur, pour du mutualise, ce n'est pas 20 serveurs independants, c'est carrement nul comme type d'architecture...
comme cela je ne suis pas obligé d'aller chez LDCOM tout le temps.... et puis j'ai un tech sur place au cas ou je viens de le dire dans le post precedent hébergeur est un METIER....
Nous avons aussi des techniciens sur place, qui peuvent intervenir sur les machines dans les 15 minutes.
encore faut il que le materiel defectueux soit en stock pour que nous puissions le remplacer sous 15 minutes. Meme avec le stock de securite que nous conservons en permanence, l'urgence fait que parfois on a plus rien en reserve.
bref, Webvisio est un hebergeur, un vrai :)))))) il ne lui est jamais arrive aucun probleme, il sait tout et a la meilleure architecture du monde, la plus simple aussi [....]
Ca me fait bien rire.
Cdt
Thibaud,
"webvisio" <admin@webvisio.net> wrote in message news:<41081716$0$12492$626a14ce@news.free.fr>...
ben moi je change pas de ram je met de la ECC d'office sur mes machines
avant de les mettres en prod
et donc parce ton "metier" est hebergeur, ta superbe ram ecc n'a
jamais de defaut ? jamais aucune barette de ECC peut avoir de
probleme... normal c'est ton metier
et puis je ne charge pas comme un malade mes serveurs.
80/85 sites maxi par machines
BOOOO
je prefere voir deux clusters composés de plusieurs 10enes de machines
plutot que des serveurs independants sur lesquels tu ne passes
forcement pas 24/24 a controler que chaque machine fonctionne et donc
qui tombe plus facilement.
De tt facon, un bon hébergeur, pour du mutualise, ce n'est pas 20
serveurs independants, c'est carrement nul comme type
d'architecture...
comme cela je ne suis pas obligé d'aller chez LDCOM tout le temps....
et puis j'ai un tech sur place au cas ou
je viens de le dire dans le post precedent hébergeur est un METIER....
Nous avons aussi des techniciens sur place, qui peuvent intervenir sur
les machines dans les 15 minutes.
encore faut il que le materiel defectueux soit en stock pour que nous
puissions le remplacer sous 15 minutes. Meme avec le stock de securite
que nous conservons en permanence, l'urgence fait que parfois on a
plus rien en reserve.
bref, Webvisio est un hebergeur, un vrai :))))))
il ne lui est jamais arrive aucun probleme, il sait tout et a la
meilleure architecture du monde, la plus simple aussi [....]
"webvisio" wrote in message news:<41081716$0$12492$...
ben moi je change pas de ram je met de la ECC d'office sur mes machines avant de les mettres en prod
et donc parce ton "metier" est hebergeur, ta superbe ram ecc n'a jamais de defaut ? jamais aucune barette de ECC peut avoir de probleme... normal c'est ton metier
et puis je ne charge pas comme un malade mes serveurs. 80/85 sites maxi par machines
BOOOO je prefere voir deux clusters composés de plusieurs 10enes de machines plutot que des serveurs independants sur lesquels tu ne passes forcement pas 24/24 a controler que chaque machine fonctionne et donc qui tombe plus facilement.
De tt facon, un bon hébergeur, pour du mutualise, ce n'est pas 20 serveurs independants, c'est carrement nul comme type d'architecture...
comme cela je ne suis pas obligé d'aller chez LDCOM tout le temps.... et puis j'ai un tech sur place au cas ou je viens de le dire dans le post precedent hébergeur est un METIER....
Nous avons aussi des techniciens sur place, qui peuvent intervenir sur les machines dans les 15 minutes.
encore faut il que le materiel defectueux soit en stock pour que nous puissions le remplacer sous 15 minutes. Meme avec le stock de securite que nous conservons en permanence, l'urgence fait que parfois on a plus rien en reserve.
bref, Webvisio est un hebergeur, un vrai :)))))) il ne lui est jamais arrive aucun probleme, il sait tout et a la meilleure architecture du monde, la plus simple aussi [....]
Ca me fait bien rire.
Cdt
Thibaud,
Anthony
De tt facon, un bon hébergeur, pour du mutualise, ce n'est pas 20 serveurs independants, c'est carrement nul comme type d'architecture...
Vu les problèmes actuels chez PHPNET (qui d'ailleurs me sont confirmés en PV par plusieurs personnes) je pense que le <gamin>"C'est carrément nul comme type d'architecture"</gamin> ça le fait pas trop. L'architecture est peut être "nulle" mais si Webvisio arrive à avoir moins de problèmes avec, c'est quand même mieux non ?
bref, Webvisio est un hebergeur, un vrai :)))))) il ne lui est jamais arrive aucun probleme, il sait tout et a la meilleure architecture du monde, la plus simple aussi [....]
Ca me fait bien rire.
Si Webvisio connaissait les problèmes de PHPNET ça le ferai bien rire aussi je pense !
Anthony
De tt facon, un bon hébergeur, pour du mutualise, ce n'est pas 20
serveurs independants, c'est carrement nul comme type
d'architecture...
Vu les problèmes actuels chez PHPNET (qui d'ailleurs me sont confirmés en PV
par plusieurs personnes) je pense que le <gamin>"C'est carrément nul comme
type d'architecture"</gamin> ça le fait pas trop. L'architecture est peut
être "nulle" mais si Webvisio arrive à avoir moins de problèmes avec, c'est
quand même mieux non ?
bref, Webvisio est un hebergeur, un vrai :))))))
il ne lui est jamais arrive aucun probleme, il sait tout et a la
meilleure architecture du monde, la plus simple aussi [....]
Ca me fait bien rire.
Si Webvisio connaissait les problèmes de PHPNET ça le ferai bien rire aussi
je pense !
De tt facon, un bon hébergeur, pour du mutualise, ce n'est pas 20 serveurs independants, c'est carrement nul comme type d'architecture...
Vu les problèmes actuels chez PHPNET (qui d'ailleurs me sont confirmés en PV par plusieurs personnes) je pense que le <gamin>"C'est carrément nul comme type d'architecture"</gamin> ça le fait pas trop. L'architecture est peut être "nulle" mais si Webvisio arrive à avoir moins de problèmes avec, c'est quand même mieux non ?
bref, Webvisio est un hebergeur, un vrai :)))))) il ne lui est jamais arrive aucun probleme, il sait tout et a la meilleure architecture du monde, la plus simple aussi [....]
Ca me fait bien rire.
Si Webvisio connaissait les problèmes de PHPNET ça le ferai bien rire aussi je pense !
Anthony
webvisio
"phpnet" a écrit dans le message de news:
"webvisio" wrote in message news:<41081716$0$12492$...
ben moi je change pas de ram je met de la ECC d'office sur mes machines avant de les mettres en prod
et donc parce ton "metier" est hebergeur, ta superbe ram ecc n'a jamais de defaut ? jamais aucune barette de ECC peut avoir de probleme... normal c'est ton metier
et puis je ne charge pas comme un malade mes serveurs. 80/85 sites maxi par machines
BOOOO je prefere voir deux clusters composés de plusieurs 10enes de machines plutot que des serveurs independants sur lesquels tu ne passes forcement pas 24/24 a controler que chaque machine fonctionne et donc qui tombe plus facilement.
De tt facon, un bon hébergeur, pour du mutualise, ce n'est pas 20 serveurs independants, c'est carrement nul comme type d'architecture...
comme cela je ne suis pas obligé d'aller chez LDCOM tout le temps.... et puis j'ai un tech sur place au cas ou je viens de le dire dans le post precedent hébergeur est un METIER....
Nous avons aussi des techniciens sur place, qui peuvent intervenir sur les machines dans les 15 minutes.
encore faut il que le materiel defectueux soit en stock pour que nous puissions le remplacer sous 15 minutes. Meme avec le stock de securite que nous conservons en permanence, l'urgence fait que parfois on a plus rien en reserve.
bref, Webvisio est un hebergeur, un vrai :)))))) il ne lui est jamais arrive aucun probleme, il sait tout et a la meilleure architecture du monde, la plus simple aussi [....]
Ca me fait bien rire.
Cdt
Thibaud,
juste pour ton info depuis 3 ans aucune plainte de client sur ce news ( sans doutes la preuve de notre serieux) pour autres info notre architecture est basée sur 20 machines independantes pourquoi ? si une machine tombe en panne il n'y a que 80 sites en coupures et pas la totalité.... de meme que le serveur dns si il tombe en panne cela ne touche que 80 sites et pas la totalité pour ta gouverne la memoire ECC chez nous est testée, de meme que nos machine sont testée pendant 15 jours avant de les mettre en prod... d'aure part nous avons une reserve de machine vides capable de remplacer sur le champ une machine cassé et les pieces ? nous avons en stock cartes mere, ventilateurs, disque dur, alimentation ( le tout d'origine constructeur) pour remplacer immediatement une piece deffaillante.
je ne censure pas mes clients moi. et quand une machine est indisponible (upgrade) j'envoi un mail personalisé au clients pour l'informer de ce qui se passe ou de ce qui vas se passer. je n'ai pas besoin de forum et encore moins de membres qui bossent gratos pour administrer un forum et faire de la pub sur ce news group
"phpnet" <thibaud@phpnet.org> a écrit dans le message de
news:8f9e5df8.0407290003.49e6dd86@posting.google.com...
"webvisio" <admin@webvisio.net> wrote in message
news:<41081716$0$12492$626a14ce@news.free.fr>...
ben moi je change pas de ram je met de la ECC d'office sur mes machines
avant de les mettres en prod
et donc parce ton "metier" est hebergeur, ta superbe ram ecc n'a
jamais de defaut ? jamais aucune barette de ECC peut avoir de
probleme... normal c'est ton metier
et puis je ne charge pas comme un malade mes serveurs.
80/85 sites maxi par machines
BOOOO
je prefere voir deux clusters composés de plusieurs 10enes de machines
plutot que des serveurs independants sur lesquels tu ne passes
forcement pas 24/24 a controler que chaque machine fonctionne et donc
qui tombe plus facilement.
De tt facon, un bon hébergeur, pour du mutualise, ce n'est pas 20
serveurs independants, c'est carrement nul comme type
d'architecture...
comme cela je ne suis pas obligé d'aller chez LDCOM tout le temps....
et puis j'ai un tech sur place au cas ou
je viens de le dire dans le post precedent hébergeur est un METIER....
Nous avons aussi des techniciens sur place, qui peuvent intervenir sur
les machines dans les 15 minutes.
encore faut il que le materiel defectueux soit en stock pour que nous
puissions le remplacer sous 15 minutes. Meme avec le stock de securite
que nous conservons en permanence, l'urgence fait que parfois on a
plus rien en reserve.
bref, Webvisio est un hebergeur, un vrai :))))))
il ne lui est jamais arrive aucun probleme, il sait tout et a la
meilleure architecture du monde, la plus simple aussi [....]
Ca me fait bien rire.
Cdt
Thibaud,
juste pour ton info depuis 3 ans
aucune plainte de client sur ce news ( sans doutes la preuve de notre
serieux)
pour autres info
notre architecture est basée sur 20 machines independantes pourquoi ?
si une machine tombe en panne il n'y a que 80 sites en coupures
et pas la totalité....
de meme que le serveur dns si il tombe en panne cela ne touche que 80 sites
et pas la totalité
pour ta gouverne la memoire ECC chez nous est testée, de meme que nos
machine sont testée pendant 15 jours avant de les mettre en prod...
d'aure part nous avons une reserve de machine vides capable de remplacer sur
le champ une machine cassé
et les pieces ? nous avons en stock cartes mere, ventilateurs, disque dur,
alimentation ( le tout d'origine constructeur) pour remplacer immediatement
une piece deffaillante.
je ne censure pas mes clients moi.
et quand une machine est indisponible (upgrade) j'envoi un mail personalisé
au clients pour l'informer de ce qui se passe ou de ce qui vas se passer.
je n'ai pas besoin de forum et encore moins de membres qui bossent gratos
pour administrer un forum et faire de la pub sur ce news group
"webvisio" wrote in message news:<41081716$0$12492$...
ben moi je change pas de ram je met de la ECC d'office sur mes machines avant de les mettres en prod
et donc parce ton "metier" est hebergeur, ta superbe ram ecc n'a jamais de defaut ? jamais aucune barette de ECC peut avoir de probleme... normal c'est ton metier
et puis je ne charge pas comme un malade mes serveurs. 80/85 sites maxi par machines
BOOOO je prefere voir deux clusters composés de plusieurs 10enes de machines plutot que des serveurs independants sur lesquels tu ne passes forcement pas 24/24 a controler que chaque machine fonctionne et donc qui tombe plus facilement.
De tt facon, un bon hébergeur, pour du mutualise, ce n'est pas 20 serveurs independants, c'est carrement nul comme type d'architecture...
comme cela je ne suis pas obligé d'aller chez LDCOM tout le temps.... et puis j'ai un tech sur place au cas ou je viens de le dire dans le post precedent hébergeur est un METIER....
Nous avons aussi des techniciens sur place, qui peuvent intervenir sur les machines dans les 15 minutes.
encore faut il que le materiel defectueux soit en stock pour que nous puissions le remplacer sous 15 minutes. Meme avec le stock de securite que nous conservons en permanence, l'urgence fait que parfois on a plus rien en reserve.
bref, Webvisio est un hebergeur, un vrai :)))))) il ne lui est jamais arrive aucun probleme, il sait tout et a la meilleure architecture du monde, la plus simple aussi [....]
Ca me fait bien rire.
Cdt
Thibaud,
juste pour ton info depuis 3 ans aucune plainte de client sur ce news ( sans doutes la preuve de notre serieux) pour autres info notre architecture est basée sur 20 machines independantes pourquoi ? si une machine tombe en panne il n'y a que 80 sites en coupures et pas la totalité.... de meme que le serveur dns si il tombe en panne cela ne touche que 80 sites et pas la totalité pour ta gouverne la memoire ECC chez nous est testée, de meme que nos machine sont testée pendant 15 jours avant de les mettre en prod... d'aure part nous avons une reserve de machine vides capable de remplacer sur le champ une machine cassé et les pieces ? nous avons en stock cartes mere, ventilateurs, disque dur, alimentation ( le tout d'origine constructeur) pour remplacer immediatement une piece deffaillante.
je ne censure pas mes clients moi. et quand une machine est indisponible (upgrade) j'envoi un mail personalisé au clients pour l'informer de ce qui se passe ou de ce qui vas se passer. je n'ai pas besoin de forum et encore moins de membres qui bossent gratos pour administrer un forum et faire de la pub sur ce news group
webvisio
"BlueWhisper" a écrit dans le message de news:ce7tng$c5a$
julien wrote:
BlueWhisper wrote:
julien wrote:
un serveur mutualisé bien configurée empêche ce genre de requéte pour
éviter les dérives, non ? Ou c'est parce qu'il est surchargé qu'une requéte prend autant de temps ?
À ma connaissance il n'existe pas de bon moyen pour limiter la durée d'éxécution des requêtes (et puis même si tu t'arranges pour en mettre un, tu peux être sûr que tous tes clients vont râler à partir du moment où ils essaient de générer des index ou des trucs comme ça).
biensur il en existe un! Et en programmant bien on peu toujours contourner ce problème, mais dans ce cas on programme bien...
Bah évidemment, tu peux faire un truc qui kill les thread MySQL de plus
de 15s par ex... seulement là tu es mal si tu dois générer un index... de plus ça ralerait beaucoup si cette protection était mise en place, je peux te le garantir...
De toute façon ce n'est pas ça qui a créé le problème au niveau sql... c'est uniquement son site qui a dépassé le nombre de connexions sql utilisées à cause de ça...
D'ailleurs à ma connaissance il y a un script qui verrouille les bases des trop gros consommateurs (ce qui a fait des histoires d'ailleurs).
J'ai hébergé il y a un temps un site du genre. ça m'a saturé 2 machines parce que ce gars savait pas les LIMIT et ORDER BY en mysql, et n'utilisait pas de champ "id" avec lequel il ferait un join, mais le pseudo en entier dans toutes les tables (et sans index bien sûr).
Dans ce cas se client n'aurait pas mis à mal le cluster, si c'était bien configuré pour éviter les abus. Le client aurait simplement vu un message d'erreur disant que la requête est trop longue, sans géner les clients à cote à aucun moment!
une requête de 3s c'est trop long pour toi? Les requêtes n'étaient pas excessivement longues, mais beaucoup trop pour ce que ça aurait dû être (0.02s avec index, limit et order by)... Le gaillard faisait 20Go de traffic par jour... normalement ça aurait du passer sans pb, mais à condition d'avoir un truc un peu optimisé.
Pour ce client, la solution employée a été de mettre un sleep de 3s avant chaque page, mais je doute ce soit une bonne solution pour phpnet ;)
N'empêche pour la "dérive hors-sujet" on fait pas mal... surtout quand on sait que phpnet a été victime d'un problème matériel et non logiciel.
Sincèrement,
Laurent Fasnacht
dit moi tu bosse gratos pour phpnet toi ?
"BlueWhisper" <BlueWhisper-nospamplz@o-t.ch> a écrit dans le message de
news:ce7tng$c5a$1@newshispeed.ch...
julien wrote:
BlueWhisper wrote:
julien wrote:
un serveur mutualisé bien configurée empêche ce genre de requéte
pour
éviter les dérives, non ?
Ou c'est parce qu'il est surchargé qu'une requéte prend autant de
temps ?
À ma connaissance il n'existe pas de bon moyen pour limiter la durée
d'éxécution des requêtes (et puis même si tu t'arranges pour en mettre
un, tu peux être sûr que tous tes clients vont râler à partir du
moment où ils essaient de générer des index ou des trucs comme ça).
biensur il en existe un!
Et en programmant bien on peu toujours contourner ce problème, mais dans
ce cas on programme bien...
Bah évidemment, tu peux faire un truc qui kill les thread MySQL de plus
de 15s par ex... seulement là tu es mal si tu dois générer un index...
de plus ça ralerait beaucoup si cette protection était mise en place, je
peux te le garantir...
De toute façon ce n'est pas ça qui a créé le problème au niveau sql...
c'est uniquement son site qui a dépassé le nombre de connexions sql
utilisées à cause de ça...
D'ailleurs à ma connaissance il y a un script qui verrouille les bases
des trop gros consommateurs (ce qui a fait des histoires d'ailleurs).
J'ai hébergé il y a un temps un site du genre. ça m'a saturé 2
machines parce que ce gars savait pas les LIMIT et ORDER BY en mysql,
et n'utilisait pas de champ "id" avec lequel il ferait un join, mais
le pseudo en entier dans toutes les tables (et sans index bien sûr).
Dans ce cas se client n'aurait pas mis à mal le cluster, si c'était bien
configuré pour éviter les abus.
Le client aurait simplement vu un message d'erreur disant que la requête
est trop longue, sans géner les clients à cote à aucun moment!
une requête de 3s c'est trop long pour toi? Les requêtes n'étaient pas
excessivement longues, mais beaucoup trop pour ce que ça aurait dû être
(0.02s avec index, limit et order by)... Le gaillard faisait 20Go de
traffic par jour... normalement ça aurait du passer sans pb, mais à
condition d'avoir un truc un peu optimisé.
Pour ce client, la solution employée a été de mettre un sleep de 3s
avant chaque page, mais je doute ce soit une bonne solution pour phpnet ;)
N'empêche pour la "dérive hors-sujet" on fait pas mal... surtout quand
on sait que phpnet a été victime d'un problème matériel et non logiciel.
"BlueWhisper" a écrit dans le message de news:ce7tng$c5a$
julien wrote:
BlueWhisper wrote:
julien wrote:
un serveur mutualisé bien configurée empêche ce genre de requéte pour
éviter les dérives, non ? Ou c'est parce qu'il est surchargé qu'une requéte prend autant de temps ?
À ma connaissance il n'existe pas de bon moyen pour limiter la durée d'éxécution des requêtes (et puis même si tu t'arranges pour en mettre un, tu peux être sûr que tous tes clients vont râler à partir du moment où ils essaient de générer des index ou des trucs comme ça).
biensur il en existe un! Et en programmant bien on peu toujours contourner ce problème, mais dans ce cas on programme bien...
Bah évidemment, tu peux faire un truc qui kill les thread MySQL de plus
de 15s par ex... seulement là tu es mal si tu dois générer un index... de plus ça ralerait beaucoup si cette protection était mise en place, je peux te le garantir...
De toute façon ce n'est pas ça qui a créé le problème au niveau sql... c'est uniquement son site qui a dépassé le nombre de connexions sql utilisées à cause de ça...
D'ailleurs à ma connaissance il y a un script qui verrouille les bases des trop gros consommateurs (ce qui a fait des histoires d'ailleurs).
J'ai hébergé il y a un temps un site du genre. ça m'a saturé 2 machines parce que ce gars savait pas les LIMIT et ORDER BY en mysql, et n'utilisait pas de champ "id" avec lequel il ferait un join, mais le pseudo en entier dans toutes les tables (et sans index bien sûr).
Dans ce cas se client n'aurait pas mis à mal le cluster, si c'était bien configuré pour éviter les abus. Le client aurait simplement vu un message d'erreur disant que la requête est trop longue, sans géner les clients à cote à aucun moment!
une requête de 3s c'est trop long pour toi? Les requêtes n'étaient pas excessivement longues, mais beaucoup trop pour ce que ça aurait dû être (0.02s avec index, limit et order by)... Le gaillard faisait 20Go de traffic par jour... normalement ça aurait du passer sans pb, mais à condition d'avoir un truc un peu optimisé.
Pour ce client, la solution employée a été de mettre un sleep de 3s avant chaque page, mais je doute ce soit une bonne solution pour phpnet ;)
N'empêche pour la "dérive hors-sujet" on fait pas mal... surtout quand on sait que phpnet a été victime d'un problème matériel et non logiciel.
Sincèrement,
Laurent Fasnacht
dit moi tu bosse gratos pour phpnet toi ?
Anthony
dit moi tu bosse gratos pour phpnet toi ?
Apparemment, et dans les forums y'a pas que lui...
Anthony
dit moi tu bosse gratos pour phpnet toi ?
Apparemment, et dans les forums y'a pas que lui...
"Christophe Baegert" a écrit dans le message de news:ceah2v$71i$
phpnet wrote:
et donc parce ton "metier" est hebergeur, ta superbe ram ecc n'a jamais de defaut ? jamais aucune barette de ECC peut avoir de probleme...
possible que ça arrive, mais je ne l'ai jamais encore vu... alors que de la
noname standard... ca arrive bien une fois sur 5 !
tout a fait d'accord avec toi. jamais eu de problemes avec de la ECC en plus de prend de l'apairée pour plus de secu cordialement bernard
Dominique ROUSSEAU
notre architecture est basée sur 20 machines independantes pourquoi ? si une machine tombe en panne il n'y a que 80 sites en coupures et pas la totalité....
Le but d'un cluster, c'est que les X machines qui en font partie répondent pour l'ensemble des sites. Si une des machines est indisponible, les (X-1) autres continuent à répondre pour l'en semble des sites, avec des perfs légèrement dégradées. Si X est suffisament grand, l'impact est minimisé.
Dom
notre architecture est basée sur 20 machines independantes pourquoi ?
si une machine tombe en panne il n'y a que 80 sites en coupures et pas
la totalité....
Le but d'un cluster, c'est que les X machines qui en font partie
répondent pour l'ensemble des sites. Si une des machines est
indisponible, les (X-1) autres continuent à répondre pour l'en semble
des sites, avec des perfs légèrement dégradées. Si X est suffisament
grand, l'impact est minimisé.
notre architecture est basée sur 20 machines independantes pourquoi ? si une machine tombe en panne il n'y a que 80 sites en coupures et pas la totalité....
Le but d'un cluster, c'est que les X machines qui en font partie répondent pour l'ensemble des sites. Si une des machines est indisponible, les (X-1) autres continuent à répondre pour l'en semble des sites, avec des perfs légèrement dégradées. Si X est suffisament grand, l'impact est minimisé.
Dom
Spontex
Dominique ROUSSEAU wrote:
notre architecture est basée sur 20 machines independantes pourquoi ? si une machine tombe en panne il n'y a que 80 sites en coupures et pas la totalité....
Le but d'un cluster, c'est que les X machines qui en font partie répondent pour l'ensemble des sites. Si une des machines est indisponible, les (X-1) autres continuent à répondre pour l'en semble des sites, avec des perfs légèrement dégradées. Si X est suffisament grand, l'impact est minimisé.
Dans ce cas, comment une barette de RAM défectueuse peut-elle provoquer la coupure de l'ensemble des sites ?
Dominique ROUSSEAU wrote:
notre architecture est basée sur 20 machines independantes pourquoi ?
si une machine tombe en panne il n'y a que 80 sites en coupures et pas
la totalité....
Le but d'un cluster, c'est que les X machines qui en font partie
répondent pour l'ensemble des sites. Si une des machines est
indisponible, les (X-1) autres continuent à répondre pour l'en semble
des sites, avec des perfs légèrement dégradées. Si X est suffisament
grand, l'impact est minimisé.
Dans ce cas, comment une barette de RAM défectueuse peut-elle provoquer
la coupure de l'ensemble des sites ?
notre architecture est basée sur 20 machines independantes pourquoi ? si une machine tombe en panne il n'y a que 80 sites en coupures et pas la totalité....
Le but d'un cluster, c'est que les X machines qui en font partie répondent pour l'ensemble des sites. Si une des machines est indisponible, les (X-1) autres continuent à répondre pour l'en semble des sites, avec des perfs légèrement dégradées. Si X est suffisament grand, l'impact est minimisé.
Dans ce cas, comment une barette de RAM défectueuse peut-elle provoquer la coupure de l'ensemble des sites ?
