Avez-vous des recommandations (logiels, m=C3=A9thode) pour tester =C3=A0 fo=
nd le
mat=C3=A9riel d'un nouveau serveur avant de le mettre en production ?
La distribution StressLinux dont je d=C3=A9couvre l'existence a l'air con=
=C3=A7ue
pour cet usage mais avec une derni=C3=A8re publication remontant =C3=A0 201=
1 et le
d=C3=A9veloppement r=C3=A9cent des SSD, j'imagine que des outils plus r=C3=
=A9cents
auraient un int=C3=A9r=C3=AAt.
<div dir=3D"ltr"><div><div>Bonjour,<br><br></div>Avez-vous des recommandati=
ons (logiels, m=C3=A9thode) pour tester =C3=A0 fond le mat=C3=A9riel d'=
un nouveau serveur avant de le mettre en production ?<br><br></div><div>La =
distribution StressLinux dont je d=C3=A9couvre l'existence a l'air =
con=C3=A7ue pour cet usage mais avec une derni=C3=A8re publication remontan=
t =C3=A0 2011 et le d=C3=A9veloppement r=C3=A9cent des SSD, j'imagine q=
ue des outils plus r=C3=A9cents auraient un int=C3=A9r=C3=AAt.<br><br></div=
><div>Slts<br></div></div>
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
JF Straeten
Hello, On Tue, May 15, 2018 at 06:54:22PM +0200, FF __/ FF wrote: [...]
Si tu procèdes a l'installation complète du serveur, tu peux déjà observé si c'est stable a 100 % [...]
Je suis assez d'accord. Un lien intéressant : https://blog.codinghorror.com/is-your-computer-stable/ Il utilise MPrime... Pourquoi pas, mais je parie qu'un burnMMX (paquet cpuburn) par core pendant quelques heures, c'est déjà suffisant pour débusquer les canards boiteux. Par contre, un memtest86 en soi ne suffit pas toujours pour trouver les barrettes qui ne fonctionnent pas bien ensemble. Un bon test, qui sollicite bien l'ensemble, était aussi proposé par la SuSE, à l'époque, qui consistait à faire des compilations de kernel en boucle et puis à comparer les logs, (qui devaient tous être identiques, sauf le dernier quand on casse la boucle :-)... Hih, -- JFS.
Hello,
On Tue, May 15, 2018 at 06:54:22PM +0200, FF __/ FF wrote:
[...]
Si tu procèdes a l'installation complète du serveur, tu peux déjà
observé si c'est stable a 100 % [...]
Je suis assez d'accord.
Un lien intéressant : https://blog.codinghorror.com/is-your-computer-stable/
Il utilise MPrime...
Pourquoi pas, mais je parie qu'un burnMMX (paquet cpuburn) par core
pendant quelques heures, c'est déjà suffisant pour débusquer les
canards boiteux.
Par contre, un memtest86 en soi ne suffit pas toujours pour trouver
les barrettes qui ne fonctionnent pas bien ensemble.
Un bon test, qui sollicite bien l'ensemble, était aussi proposé par la
SuSE, à l'époque, qui consistait à faire des compilations de kernel en
boucle et puis à comparer les logs, (qui devaient tous être
identiques, sauf le dernier quand on casse la boucle :-)...
Hello, On Tue, May 15, 2018 at 06:54:22PM +0200, FF __/ FF wrote: [...]
Si tu procèdes a l'installation complète du serveur, tu peux déjà observé si c'est stable a 100 % [...]
Je suis assez d'accord. Un lien intéressant : https://blog.codinghorror.com/is-your-computer-stable/ Il utilise MPrime... Pourquoi pas, mais je parie qu'un burnMMX (paquet cpuburn) par core pendant quelques heures, c'est déjà suffisant pour débusquer les canards boiteux. Par contre, un memtest86 en soi ne suffit pas toujours pour trouver les barrettes qui ne fonctionnent pas bien ensemble. Un bon test, qui sollicite bien l'ensemble, était aussi proposé par la SuSE, à l'époque, qui consistait à faire des compilations de kernel en boucle et puis à comparer les logs, (qui devaient tous être identiques, sauf le dernier quand on casse la boucle :-)... Hih, -- JFS.
Andre Majorel
On 2018-05-15 18:54 +0200, FF __/ FF wrote:
Le 15 mai 2018 à 16:33, Olivier a écrit :
Avez-vous des recommandations (logiels, méthode) pour tester à fond le matériel d'un nouveau serveur avant de le mettre en production ?
Il y a trop de cas de figure possibles pour les inclure tous dans une procédure de test. Enfonçage de portes ouvertes : la première chose à faire serait d'utiliser la procédure qui teste les services que ce serveur doit assurer. Ainsi, les états qui seront testés seront plus ou moins ceux par lesquels le serveur passera quand il sera en exploitation.
Si tu procèdes a l'installation complète du serveur, tu peux déjà observé si c'est stable a 100 %,
C'est un bon début mais c'est pas une garantie. Je parle d'expérience. :-> -- André Majorel <http://www.teaser.fr/~amajorel/> # ln -s reportbug /usr/bin/getspam
On 2018-05-15 18:54 +0200, FF __/ FF wrote:
Le 15 mai 2018 à 16:33, Olivier <oza.4h07@gmail.com> a écrit :
> Avez-vous des recommandations (logiels, méthode) pour tester
> à fond le matériel d'un nouveau serveur avant de le mettre
> en production ?
Il y a trop de cas de figure possibles pour les inclure tous
dans une procédure de test. Enfonçage de portes ouvertes : la
première chose à faire serait d'utiliser la procédure qui teste
les services que ce serveur doit assurer. Ainsi, les états qui
seront testés seront plus ou moins ceux par lesquels le serveur
passera quand il sera en exploitation.
Si tu procèdes a l'installation complète du serveur, tu peux
déjà observé si c'est stable a 100 %,
C'est un bon début mais c'est pas une garantie. Je parle
d'expérience. :->
--
André Majorel <http://www.teaser.fr/~amajorel/>
# ln -s reportbug /usr/bin/getspam
Avez-vous des recommandations (logiels, méthode) pour tester à fond le matériel d'un nouveau serveur avant de le mettre en production ?
Il y a trop de cas de figure possibles pour les inclure tous dans une procédure de test. Enfonçage de portes ouvertes : la première chose à faire serait d'utiliser la procédure qui teste les services que ce serveur doit assurer. Ainsi, les états qui seront testés seront plus ou moins ceux par lesquels le serveur passera quand il sera en exploitation.
Si tu procèdes a l'installation complète du serveur, tu peux déjà observé si c'est stable a 100 %,
C'est un bon début mais c'est pas une garantie. Je parle d'expérience. :-> -- André Majorel <http://www.teaser.fr/~amajorel/> # ln -s reportbug /usr/bin/getspam
Luc Novales
Bonjour, Je déterre ce vieux fil car c'est une question assez commune et peu de réponses ont été données. Le 19/05/2018 à 16:20, Andre Majorel a écrit :
On 2018-05-15 18:54 +0200, FF __/ FF wrote:
Le 15 mai 2018 à 16:33, Olivier a écrit :
Avez-vous des recommandations (logiels, méthode) pour tester à fond le matériel d'un nouveau serveur avant de le mettre en production ?
Il y a trop de cas de figure possibles pour les inclure tous dans une procédure de test. Enfonçage de portes ouvertes : la première chose à faire serait d'utiliser la procédure qui teste les services que ce serveur doit assurer. Ainsi, les états qui seront testés seront plus ou moins ceux par lesquels le serveur passera quand il sera en exploitation.
+1. Donc, si le serveur doit être utilisé sous Debian, la suite de tests Phoronix est vraiment adaptée, avec une couverture de tests très importante : https://phoronix-test-suite.com/ par contre, certains tests (ou collections) nécessitent l'installation de paquets (dont certains ne sont pas libres). Il est certainement préférable de les supprimer pour passer en prod. Bonne journée, Luc.
Si tu procèdes a l'installation complète du serveur, tu peux déjà observé si c'est stable a 100 %,
C'est un bon début mais c'est pas une garantie. Je parle d'expérience. :->
Bonjour,
Je déterre ce vieux fil car c'est une question assez commune et peu de
réponses ont été données.
Le 19/05/2018 à 16:20, Andre Majorel a écrit :
On 2018-05-15 18:54 +0200, FF __/ FF wrote:
Le 15 mai 2018 à 16:33, Olivier <oza.4h07@gmail.com> a écrit :
Avez-vous des recommandations (logiels, méthode) pour tester
à fond le matériel d'un nouveau serveur avant de le mettre
en production ?
Il y a trop de cas de figure possibles pour les inclure tous
dans une procédure de test. Enfonçage de portes ouvertes : la
première chose à faire serait d'utiliser la procédure qui teste
les services que ce serveur doit assurer. Ainsi, les états qui
seront testés seront plus ou moins ceux par lesquels le serveur
passera quand il sera en exploitation.
+1.
Donc, si le serveur doit être utilisé sous Debian, la suite de tests
Phoronix est vraiment adaptée, avec une couverture de tests très
importante :
https://phoronix-test-suite.com/
par contre, certains tests (ou collections) nécessitent l'installation
de paquets (dont certains ne sont pas libres). Il est certainement
préférable de les supprimer pour passer en prod.
Bonne journée,
Luc.
Si tu procèdes a l'installation complète du serveur, tu peux
déjà observé si c'est stable a 100 %,
C'est un bon début mais c'est pas une garantie. Je parle
d'expérience. :->
Bonjour, Je déterre ce vieux fil car c'est une question assez commune et peu de réponses ont été données. Le 19/05/2018 à 16:20, Andre Majorel a écrit :
On 2018-05-15 18:54 +0200, FF __/ FF wrote:
Le 15 mai 2018 à 16:33, Olivier a écrit :
Avez-vous des recommandations (logiels, méthode) pour tester à fond le matériel d'un nouveau serveur avant de le mettre en production ?
Il y a trop de cas de figure possibles pour les inclure tous dans une procédure de test. Enfonçage de portes ouvertes : la première chose à faire serait d'utiliser la procédure qui teste les services que ce serveur doit assurer. Ainsi, les états qui seront testés seront plus ou moins ceux par lesquels le serveur passera quand il sera en exploitation.
+1. Donc, si le serveur doit être utilisé sous Debian, la suite de tests Phoronix est vraiment adaptée, avec une couverture de tests très importante : https://phoronix-test-suite.com/ par contre, certains tests (ou collections) nécessitent l'installation de paquets (dont certains ne sont pas libres). Il est certainement préférable de les supprimer pour passer en prod. Bonne journée, Luc.
Si tu procèdes a l'installation complète du serveur, tu peux déjà observé si c'est stable a 100 %,
C'est un bon début mais c'est pas une garantie. Je parle d'expérience. :->