Je voudrais voir quel débit j'ai en lecture sur un serveur.
Ceci en faisant abstraction de ce qui s'y connecte.
Mais en incluant l'accès disque, le serveur lui-même, la connextion
réseau et si possible le protocole.
J'ai tenté ceci :
time scp -qr folder_source autreServer.ici.ch:/dev/null/
Mais ça me dit :
scp: /dev/null/: Not a directory
Alors j'ai fait ça :
find source -type f -exec cat {} \; | ssh -l user server.ici.ch "dd
of=/dev/null" ; date
Qui semble fonctionner.
Mais ça prends pas en compte le protocole.
Conaissez vous un truc pour tester le débit en différents protocoles ?
(afp, cifs, rsync/ssh, scp, ...)
Le seul test "réaliste" est la mesure de l'activité réelle. Et cette mesure peut changer selon les conditions.
Pour quelques tests, je prends ma montre qui a une trotteuse et divise la taille du fichier par le temps - ça donne une idée aussi précise que d'autres méthodes :-) -- A+
Romer
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Le seul test "réaliste" est la mesure de l'activité réelle. Et cette
mesure peut changer selon les conditions.
Pour quelques tests, je prends ma montre qui a une trotteuse et divise
la taille du fichier par le temps - ça donne une idée aussi précise que
d'autres méthodes :-)
--
A+
Le seul test "réaliste" est la mesure de l'activité réelle. Et cette mesure peut changer selon les conditions.
Pour quelques tests, je prends ma montre qui a une trotteuse et divise la taille du fichier par le temps - ça donne une idée aussi précise que d'autres méthodes :-) -- A+
Romer
Eric Levenez
Le 05/06/08 15:27, dans <1ii2edt.zyoyxq1esgiztN%, « Jayce Piel » a écrit :
Heu... 100baseT, c'est du 100Mb/s soit 12,5Mo/s.
Le débit est de 11,9 Mo/s avec M=2^20 (et non M^6)
Mais en pratique, même en full duplex avec des switchs, le débit brute doit plafonner à 80 ou 85 % de la bande passante pour IP soit 9 à 10 Mo/s. Il faut ensuite enlever le pourcentage pour l'encapsulation du protocole (5 % pour FTP/TCP/IP par exemple).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 05/06/08 15:27, dans <1ii2edt.zyoyxq1esgiztN%jayce@mosx.org>, « Jayce
Piel » <jayce@mosx.org> a écrit :
Heu... 100baseT, c'est du 100Mb/s soit 12,5Mo/s.
Le débit est de 11,9 Mo/s avec M=2^20 (et non M^6)
Mais en pratique, même en full duplex avec des switchs, le débit brute doit
plafonner à 80 ou 85 % de la bande passante pour IP soit 9 à 10 Mo/s. Il
faut ensuite enlever le pourcentage pour l'encapsulation du protocole (5 %
pour FTP/TCP/IP par exemple).
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 05/06/08 15:27, dans <1ii2edt.zyoyxq1esgiztN%, « Jayce Piel » a écrit :
Heu... 100baseT, c'est du 100Mb/s soit 12,5Mo/s.
Le débit est de 11,9 Mo/s avec M=2^20 (et non M^6)
Mais en pratique, même en full duplex avec des switchs, le débit brute doit plafonner à 80 ou 85 % de la bande passante pour IP soit 9 à 10 Mo/s. Il faut ensuite enlever le pourcentage pour l'encapsulation du protocole (5 % pour FTP/TCP/IP par exemple).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Nicolas-Michel_REMOVE
Eric Levenez wrote:
Tout (ou presque) est fichier sur Unix. Le socket peut être un fichier, comme /dev/null est un fichier ou comme un répertoire est un fichier. Mais il y a plein de types de fichiers et les fichier "normaux", ne sont qu'un type parmi d'autres.
Ok, c'est juste, en plus je le savais. Mais ça ne m'est revenu qu'après avoir posté.
C'est donc du utile applicatif, pas du débit brute.
Si par brute tu veux dire "raw", genre dd if=/dev/rdisk0, alors oui ça m'intéresse aussi.
De combien le protocole modifie la performance ?
Cela dépend fortement du protocole.
Patpro dit que non. Moi je voudrais pouvoir pour me faire une idée.
Tout cela dépend aussi de ce que l'on sauvegarde et comment. Un gros fichier de 1 Go ira plus vite sur une connexion qu'une multitude de fichiers de la même taille globale.
Bien évidement.
Argh, bon sang, il faut être root pour envoyer du taff sur /dev/null C'est pour ça que ça ne voulait pas <:o)
Donc, j'ai fait ce petit test qui ne teste pas le protocole, mais qui fait déjà un bout :
# time find Music/ -type f -exec cat {} ; >/dev/null => 38G en 2m26 pour 6000 fichier, donc 260Mo/s
# time find Music/ -type f -exec cat {} ; | ssh mac2.ici.ch cat >/dev/null => 63Mo/s, 5x moins qu'en local.
Et ceci sur un mac pro + sonnet D800RAID en raid5 avec un Xserve à l'autre bout.
Tout ça me prouve une fois de plus que le fiber channel de Apple est surdimentionné dans la très grande majorité des cas, comme quasi tous les SAN du marché. Et vu le prix, c'est de l'arnaque.
Mais ça veux aussi dire que mon collègue avec son NetApp qui plafonne entre 10 et 40 Mo/s a un problème sérieux.
Voilà qui tombe super bien, demain j'ai une invitation Apple "Tech Series Storage & Backup", je saurais quoi leur demander ;->
Merci à tous -- Nicolas Michel
Eric Levenez <usenet@levenez.com> wrote:
Tout (ou presque) est fichier sur Unix. Le socket peut être un fichier,
comme /dev/null est un fichier ou comme un répertoire est un fichier. Mais
il y a plein de types de fichiers et les fichier "normaux", ne sont qu'un
type parmi d'autres.
Ok, c'est juste, en plus je le savais.
Mais ça ne m'est revenu qu'après avoir posté.
C'est donc du utile applicatif, pas du débit brute.
Si par brute tu veux dire "raw", genre dd if=/dev/rdisk0, alors oui ça
m'intéresse aussi.
De combien le protocole modifie la performance ?
Cela dépend fortement du protocole.
Patpro dit que non.
Moi je voudrais pouvoir pour me faire une idée.
Tout cela dépend aussi de ce que l'on sauvegarde et comment. Un gros fichier
de 1 Go ira plus vite sur une connexion qu'une multitude de fichiers de la
même taille globale.
Bien évidement.
Argh, bon sang, il faut être root pour envoyer du taff sur /dev/null
C'est pour ça que ça ne voulait pas <:o)
Donc, j'ai fait ce petit test qui ne teste pas le protocole, mais qui
fait déjà un bout :
# time find Music/ -type f -exec cat {} ; >/dev/null
=> 38G en 2m26 pour 6000 fichier, donc 260Mo/s
# time find Music/ -type f -exec cat {} ; | ssh mac2.ici.ch
cat >/dev/null
=> 63Mo/s, 5x moins qu'en local.
Et ceci sur un mac pro + sonnet D800RAID en raid5 avec un Xserve à
l'autre bout.
Tout ça me prouve une fois de plus que le fiber channel de Apple est
surdimentionné dans la très grande majorité des cas, comme quasi tous
les SAN du marché. Et vu le prix, c'est de l'arnaque.
Mais ça veux aussi dire que mon collègue avec son NetApp qui plafonne
entre 10 et 40 Mo/s a un problème sérieux.
Voilà qui tombe super bien, demain j'ai une invitation Apple "Tech
Series Storage & Backup", je saurais quoi leur demander ;->
Tout (ou presque) est fichier sur Unix. Le socket peut être un fichier, comme /dev/null est un fichier ou comme un répertoire est un fichier. Mais il y a plein de types de fichiers et les fichier "normaux", ne sont qu'un type parmi d'autres.
Ok, c'est juste, en plus je le savais. Mais ça ne m'est revenu qu'après avoir posté.
C'est donc du utile applicatif, pas du débit brute.
Si par brute tu veux dire "raw", genre dd if=/dev/rdisk0, alors oui ça m'intéresse aussi.
De combien le protocole modifie la performance ?
Cela dépend fortement du protocole.
Patpro dit que non. Moi je voudrais pouvoir pour me faire une idée.
Tout cela dépend aussi de ce que l'on sauvegarde et comment. Un gros fichier de 1 Go ira plus vite sur une connexion qu'une multitude de fichiers de la même taille globale.
Bien évidement.
Argh, bon sang, il faut être root pour envoyer du taff sur /dev/null C'est pour ça que ça ne voulait pas <:o)
Donc, j'ai fait ce petit test qui ne teste pas le protocole, mais qui fait déjà un bout :
# time find Music/ -type f -exec cat {} ; >/dev/null => 38G en 2m26 pour 6000 fichier, donc 260Mo/s
# time find Music/ -type f -exec cat {} ; | ssh mac2.ici.ch cat >/dev/null => 63Mo/s, 5x moins qu'en local.
Et ceci sur un mac pro + sonnet D800RAID en raid5 avec un Xserve à l'autre bout.
Tout ça me prouve une fois de plus que le fiber channel de Apple est surdimentionné dans la très grande majorité des cas, comme quasi tous les SAN du marché. Et vu le prix, c'est de l'arnaque.
Mais ça veux aussi dire que mon collègue avec son NetApp qui plafonne entre 10 et 40 Mo/s a un problème sérieux.
Voilà qui tombe super bien, demain j'ai une invitation Apple "Tech Series Storage & Backup", je saurais quoi leur demander ;->
Merci à tous -- Nicolas Michel
Nicolas-Michel_REMOVE
patpro ~ Patrick Proniewski wrote:
In article <1ii2edt.zyoyxq1esgiztN%, (Anonyme) wrote:
Michel Nicolas Alex wrote:
Combien on peut mettre d'utilisateurs sur un même serveur avant que ce ne soit plus la connection 100baseT du client qui le limite ? Quelle sera la fenêtre de backup ?
Un collègue me dit que selon ses logs il a un débit qui varie entre 10 et 40 Mo/s quand il fait un backup via réseau. Or aucun des éléments de la chaine de ses serveurs n'est aussi faible : disques raid, connection fibre, gigabit, ... On devrait être à 80Mo d'après moi. Et je voudrais comprendre. Pour ça il me faut un moyen d'analyse.
Heu... 100baseT, c'est du 100Mb/s soit 12,5Mo/s.
Ici les clients sont en 100 et les serveurs sont en 1000.
Si un seul client tente d'accéder à un serveur, il ne va pas le saturer. Mais à partir d'un certain nombre de clients, ... J'aimerais voir à quel moment ça sature en fonction des différents équipements que j'ai sous la main.
oui, et puis c'est théorique, on ne les atteint jamais. En facteur limitants, en dehors du protocole réseau utilisé (ce qui semble t'inquiéter à mon avis inutilement),
Ce serait amha à vérifier.
tu vas avoir :
- la qualité du driver réseau sur chaque système - la config du firewall du client, et du serveur (on a vu des cas ou le débit est moisi sous Mac OS X avec certains réglages de firewall/nat) - la taille des fichiers - leur emplacement sur le disque, et leur destination sur le disque du serveur - débit et temps d'accès des disques client et serveur
Selon moi le goulet est au niveau du réseau gigabit, qui devrait plafonner autour des 70 Mo/s. Si je ne parviens pas à ça, c'est qu'il y a un problème. Reste ensuite à analyser les points que tu donnes, s'il y a un problème. Note que ça peut aussi être un smb.conf foireux.
Si tu veux vraiment avoir une idée précise de tout ça, il faudra faire un test grandeur nature : backuper 2 ou 3 machines en utilisant des protocoles différents, et en plaçant un soft de monitoring entre le serveur et les clients (style wireshark). Tu lances ça la nuit, et le lendemain, tu analyses.
Voilà qui a le mérite d'être clair. Reste à trouver le temps et les moyens ... Merci :)
-- Nicolas Michel
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
In article <1ii2edt.zyoyxq1esgiztN%jayce@mosx.org>,
jayce@mosx.org (Anonyme) wrote:
Michel Nicolas Alex <Nicolas-Michel_REMOVE@THIS_bluewin.ch> wrote:
Combien on peut mettre d'utilisateurs sur un même serveur avant que ce
ne soit plus la connection 100baseT du client qui le limite ?
Quelle sera la fenêtre de backup ?
Un collègue me dit que selon ses logs il a un débit qui varie entre 10
et 40 Mo/s quand il fait un backup via réseau. Or aucun des éléments de
la chaine de ses serveurs n'est aussi faible : disques raid, connection
fibre, gigabit, ... On devrait être à 80Mo d'après moi. Et je voudrais
comprendre. Pour ça il me faut un moyen d'analyse.
Heu... 100baseT, c'est du 100Mb/s soit 12,5Mo/s.
Ici les clients sont en 100 et les serveurs sont en 1000.
Si un seul client tente d'accéder à un serveur, il ne va pas le saturer.
Mais à partir d'un certain nombre de clients, ...
J'aimerais voir à quel moment ça sature en fonction des différents
équipements que j'ai sous la main.
oui, et puis c'est théorique, on ne les atteint jamais.
En facteur limitants, en dehors du protocole réseau utilisé (ce qui
semble t'inquiéter à mon avis inutilement),
Ce serait amha à vérifier.
tu vas avoir :
- la qualité du driver réseau sur chaque système
- la config du firewall du client, et du serveur (on a vu des cas ou le
débit est moisi sous Mac OS X avec certains réglages de firewall/nat)
- la taille des fichiers
- leur emplacement sur le disque, et leur destination sur le disque du
serveur
- débit et temps d'accès des disques client et serveur
Selon moi le goulet est au niveau du réseau gigabit, qui devrait
plafonner autour des 70 Mo/s. Si je ne parviens pas à ça, c'est qu'il y
a un problème. Reste ensuite à analyser les points que tu donnes, s'il y
a un problème. Note que ça peut aussi être un smb.conf foireux.
Si tu veux vraiment avoir une idée précise de tout ça, il faudra faire
un test grandeur nature : backuper 2 ou 3 machines en utilisant des
protocoles différents, et en plaçant un soft de monitoring entre le
serveur et les clients (style wireshark).
Tu lances ça la nuit, et le lendemain, tu analyses.
Voilà qui a le mérite d'être clair.
Reste à trouver le temps et les moyens ...
Merci :)
In article <1ii2edt.zyoyxq1esgiztN%, (Anonyme) wrote:
Michel Nicolas Alex wrote:
Combien on peut mettre d'utilisateurs sur un même serveur avant que ce ne soit plus la connection 100baseT du client qui le limite ? Quelle sera la fenêtre de backup ?
Un collègue me dit que selon ses logs il a un débit qui varie entre 10 et 40 Mo/s quand il fait un backup via réseau. Or aucun des éléments de la chaine de ses serveurs n'est aussi faible : disques raid, connection fibre, gigabit, ... On devrait être à 80Mo d'après moi. Et je voudrais comprendre. Pour ça il me faut un moyen d'analyse.
Heu... 100baseT, c'est du 100Mb/s soit 12,5Mo/s.
Ici les clients sont en 100 et les serveurs sont en 1000.
Si un seul client tente d'accéder à un serveur, il ne va pas le saturer. Mais à partir d'un certain nombre de clients, ... J'aimerais voir à quel moment ça sature en fonction des différents équipements que j'ai sous la main.
oui, et puis c'est théorique, on ne les atteint jamais. En facteur limitants, en dehors du protocole réseau utilisé (ce qui semble t'inquiéter à mon avis inutilement),
Ce serait amha à vérifier.
tu vas avoir :
- la qualité du driver réseau sur chaque système - la config du firewall du client, et du serveur (on a vu des cas ou le débit est moisi sous Mac OS X avec certains réglages de firewall/nat) - la taille des fichiers - leur emplacement sur le disque, et leur destination sur le disque du serveur - débit et temps d'accès des disques client et serveur
Selon moi le goulet est au niveau du réseau gigabit, qui devrait plafonner autour des 70 Mo/s. Si je ne parviens pas à ça, c'est qu'il y a un problème. Reste ensuite à analyser les points que tu donnes, s'il y a un problème. Note que ça peut aussi être un smb.conf foireux.
Si tu veux vraiment avoir une idée précise de tout ça, il faudra faire un test grandeur nature : backuper 2 ou 3 machines en utilisant des protocoles différents, et en plaçant un soft de monitoring entre le serveur et les clients (style wireshark). Tu lances ça la nuit, et le lendemain, tu analyses.
Voilà qui a le mérite d'être clair. Reste à trouver le temps et les moyens ... Merci :)
-- Nicolas Michel
Nicolas-Michel_REMOVE
patpro ~ Patrick Proniewski wrote:
In article <1ii2m9l.1thhuepv6wikrN%, (Michel Nicolas Alex) wrote:
(dans un de mes tests je mettais 30 minutes un dossier de zero kb contenant 10'000 fichiers vides
ce qui est aussi un test hyper-réaliste :)
On est pas loin de ça avec ~/Library/Mails/Mailboxes : Ici j'ai 12430 fichier de 28k en moyenne.
-- Nicolas Michel
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
In article
<1ii2m9l.1thhuepv6wikrN%Nicolas-Michel_REMOVE@THIS_bluewin.ch>,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (Michel Nicolas Alex) wrote:
(dans un de mes tests je mettais 30 minutes un dossier de zero kb
contenant 10'000 fichiers vides
ce qui est aussi un test hyper-réaliste :)
On est pas loin de ça avec ~/Library/Mails/Mailboxes :
Ici j'ai 12430 fichier de 28k en moyenne.
In article <1ii2m9l.1thhuepv6wikrN%, (Michel Nicolas Alex) wrote:
(dans un de mes tests je mettais 30 minutes un dossier de zero kb contenant 10'000 fichiers vides
ce qui est aussi un test hyper-réaliste :)
On est pas loin de ça avec ~/Library/Mails/Mailboxes : Ici j'ai 12430 fichier de 28k en moyenne.
-- Nicolas Michel
laurent.pertois
Michel Nicolas Alex wrote:
Selon moi le goulet est au niveau du réseau gigabit, qui devrait plafonner autour des 70 Mo/s. Si je ne parviens pas à ça, c'est qu'il y a un problème. Reste ensuite à analyser les points que tu donnes, s'il y a un problème.
Si tes clients sont en 100, comment veux-tu atteindre un tel débit ?
Note que ça peut aussi être un smb.conf foireux.
C'est une manie chez toi ;-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Michel Nicolas Alex <Nicolas-Michel_REMOVE@THIS_bluewin.ch> wrote:
Selon moi le goulet est au niveau du réseau gigabit, qui devrait
plafonner autour des 70 Mo/s. Si je ne parviens pas à ça, c'est qu'il y
a un problème. Reste ensuite à analyser les points que tu donnes, s'il y
a un problème.
Si tes clients sont en 100, comment veux-tu atteindre un tel débit ?
Note que ça peut aussi être un smb.conf foireux.
C'est une manie chez toi ;-)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Selon moi le goulet est au niveau du réseau gigabit, qui devrait plafonner autour des 70 Mo/s. Si je ne parviens pas à ça, c'est qu'il y a un problème. Reste ensuite à analyser les points que tu donnes, s'il y a un problème.
Si tes clients sont en 100, comment veux-tu atteindre un tel débit ?
Note que ça peut aussi être un smb.conf foireux.
C'est une manie chez toi ;-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
laurent.pertois
Michel Nicolas Alex wrote:
Tout ça me prouve une fois de plus que le fiber channel de Apple est surdimentionné dans la très grande majorité des cas, comme quasi tous les SAN du marché. Et vu le prix, c'est de l'arnaque.
Tu as un SAN ou juste un Xserve RAID collé à un Xserve ?
Dans le premier cas, combien de contrôleurs de métadonnées ? quel réseau privé ? combien de luns dans les pools ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Michel Nicolas Alex <Nicolas-Michel_REMOVE@THIS_bluewin.ch> wrote:
Tout ça me prouve une fois de plus que le fiber channel de Apple est
surdimentionné dans la très grande majorité des cas, comme quasi tous
les SAN du marché. Et vu le prix, c'est de l'arnaque.
Tu as un SAN ou juste un Xserve RAID collé à un Xserve ?
Dans le premier cas, combien de contrôleurs de métadonnées ? quel réseau
privé ? combien de luns dans les pools ?
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Tout ça me prouve une fois de plus que le fiber channel de Apple est surdimentionné dans la très grande majorité des cas, comme quasi tous les SAN du marché. Et vu le prix, c'est de l'arnaque.
Tu as un SAN ou juste un Xserve RAID collé à un Xserve ?
Dans le premier cas, combien de contrôleurs de métadonnées ? quel réseau privé ? combien de luns dans les pools ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
fx [François-Xavier Peretmere]
on the 5/06/08 23:21 Michel Nicolas Alex wrote the following: ...
Donc, j'ai fait ce petit test qui ne teste pas le protocole, mais qui fait déjà un bout :
# time find Music/ -type f -exec cat {} ; >/dev/null => 38G en 2m26 pour 6000 fichier, donc 260Mo/s
# time find Music/ -type f -exec cat {} ; | ssh mac2.ici.ch cat >/dev/null => 63Mo/s, 5x moins qu'en local.
...sachant que je n'ai plus en tête l'overhead de SSH mais c'est pas exactement un protocole optimisé pour le transfert de blocs de données. J'ai l'impression que mon autres message n'est pas passé alors je me repète : tout a une importance dans la chaîne, y compris le logiciel. Et le pipe SShisé est pas vraiment ce qu'il y a de plus optimal. Quitte à sodomiser^Wse prendre la tête et essayer d'être comparable, il faudrait faire passer le premier dans un ssh. Ou plutôt que SSH, utiliser netpipe ou un package similaire pour le test distant.
Les histoires de blocs entre les différentes couches peuvent être crucial par exemple. On peut avoir le stockage le plus rapide du monde connecté au réseau le plus rapide de l'univers, si la lecture d'un côté se fait par blocs de 8k et l'écriture de l'autre côté par blocs de 12k, les perfs ont de grandes chances d'être pourries. Par blocs de combien le cat lit-il les données?
Et ceci sur un mac pro + sonnet D800RAID en raid5 avec un Xserve à l'autre bout.
Tout ça me prouve une fois de plus que le fiber channel de Apple est surdimentionné dans la très grande majorité des cas, comme quasi tous les SAN du marché. Et vu le prix, c'est de l'arnaque.
Le FC c'est du FC. Ce n'est pas le FC (ou un SAN, même si ce n'est pas la même chose que le FC, beaucoup de gens ont tendance à intervertir les deux termes) qui est une arnaque, c'est l'utilisation d'une architecture qui n'est pas adapté au besoin. Bis repetita, c'est l'architecture qui doit s'adapter au besoin et non pas l'inverse.
Mais ça veux aussi dire que mon collègue avec son NetApp qui plafonne entre 10 et 40 Mo/s a un problème sérieux.
Déjà faudrait voir le modèle du NetApp. Ensuite il faudrait voir comment il est sauvegardé - en mode fichier, avec un agent, snapshots.... Les problèmes de performances en sauvegardes sont malheureusement rarement aussi triviaux qu'un "time cat > /dev/null" malheureusement.
Mes 2 octets. Bon courage.
Fx
-- Serious error. All Shortcuts have disppeared. Screen. Mind. Both are blank.
on the 5/06/08 23:21 Michel Nicolas Alex wrote the following:
...
Donc, j'ai fait ce petit test qui ne teste pas le protocole, mais qui
fait déjà un bout :
# time find Music/ -type f -exec cat {} ; >/dev/null
=> 38G en 2m26 pour 6000 fichier, donc 260Mo/s
# time find Music/ -type f -exec cat {} ; | ssh mac2.ici.ch
cat >/dev/null
=> 63Mo/s, 5x moins qu'en local.
...sachant que je n'ai plus en tête l'overhead de SSH mais c'est pas
exactement un protocole optimisé pour le transfert de blocs de données. J'ai
l'impression que mon autres message n'est pas passé alors je me repète :
tout a une importance dans la chaîne, y compris le logiciel. Et le pipe
SShisé est pas vraiment ce qu'il y a de plus optimal. Quitte à sodomiser^Wse
prendre la tête et essayer d'être comparable, il faudrait faire passer le
premier dans un ssh. Ou plutôt que SSH, utiliser netpipe ou un package
similaire pour le test distant.
Les histoires de blocs entre les différentes couches peuvent être crucial
par exemple. On peut avoir le stockage le plus rapide du monde connecté au
réseau le plus rapide de l'univers, si la lecture d'un côté se fait par
blocs de 8k et l'écriture de l'autre côté par blocs de 12k, les perfs ont de
grandes chances d'être pourries. Par blocs de combien le cat lit-il les données?
Et ceci sur un mac pro + sonnet D800RAID en raid5 avec un Xserve à
l'autre bout.
Tout ça me prouve une fois de plus que le fiber channel de Apple est
surdimentionné dans la très grande majorité des cas, comme quasi tous
les SAN du marché. Et vu le prix, c'est de l'arnaque.
Le FC c'est du FC. Ce n'est pas le FC (ou un SAN, même si ce n'est pas la
même chose que le FC, beaucoup de gens ont tendance à intervertir les deux
termes) qui est une arnaque, c'est l'utilisation d'une architecture qui
n'est pas adapté au besoin. Bis repetita, c'est l'architecture qui doit
s'adapter au besoin et non pas l'inverse.
Mais ça veux aussi dire que mon collègue avec son NetApp qui plafonne
entre 10 et 40 Mo/s a un problème sérieux.
Déjà faudrait voir le modèle du NetApp. Ensuite il faudrait voir comment il
est sauvegardé - en mode fichier, avec un agent, snapshots.... Les problèmes
de performances en sauvegardes sont malheureusement rarement aussi triviaux
qu'un "time cat > /dev/null" malheureusement.
Mes 2 octets. Bon courage.
Fx
--
Serious error. All
Shortcuts have disppeared.
Screen. Mind. Both are blank.
on the 5/06/08 23:21 Michel Nicolas Alex wrote the following: ...
Donc, j'ai fait ce petit test qui ne teste pas le protocole, mais qui fait déjà un bout :
# time find Music/ -type f -exec cat {} ; >/dev/null => 38G en 2m26 pour 6000 fichier, donc 260Mo/s
# time find Music/ -type f -exec cat {} ; | ssh mac2.ici.ch cat >/dev/null => 63Mo/s, 5x moins qu'en local.
...sachant que je n'ai plus en tête l'overhead de SSH mais c'est pas exactement un protocole optimisé pour le transfert de blocs de données. J'ai l'impression que mon autres message n'est pas passé alors je me repète : tout a une importance dans la chaîne, y compris le logiciel. Et le pipe SShisé est pas vraiment ce qu'il y a de plus optimal. Quitte à sodomiser^Wse prendre la tête et essayer d'être comparable, il faudrait faire passer le premier dans un ssh. Ou plutôt que SSH, utiliser netpipe ou un package similaire pour le test distant.
Les histoires de blocs entre les différentes couches peuvent être crucial par exemple. On peut avoir le stockage le plus rapide du monde connecté au réseau le plus rapide de l'univers, si la lecture d'un côté se fait par blocs de 8k et l'écriture de l'autre côté par blocs de 12k, les perfs ont de grandes chances d'être pourries. Par blocs de combien le cat lit-il les données?
Et ceci sur un mac pro + sonnet D800RAID en raid5 avec un Xserve à l'autre bout.
Tout ça me prouve une fois de plus que le fiber channel de Apple est surdimentionné dans la très grande majorité des cas, comme quasi tous les SAN du marché. Et vu le prix, c'est de l'arnaque.
Le FC c'est du FC. Ce n'est pas le FC (ou un SAN, même si ce n'est pas la même chose que le FC, beaucoup de gens ont tendance à intervertir les deux termes) qui est une arnaque, c'est l'utilisation d'une architecture qui n'est pas adapté au besoin. Bis repetita, c'est l'architecture qui doit s'adapter au besoin et non pas l'inverse.
Mais ça veux aussi dire que mon collègue avec son NetApp qui plafonne entre 10 et 40 Mo/s a un problème sérieux.
Déjà faudrait voir le modèle du NetApp. Ensuite il faudrait voir comment il est sauvegardé - en mode fichier, avec un agent, snapshots.... Les problèmes de performances en sauvegardes sont malheureusement rarement aussi triviaux qu'un "time cat > /dev/null" malheureusement.
Mes 2 octets. Bon courage.
Fx
-- Serious error. All Shortcuts have disppeared. Screen. Mind. Both are blank.
fx [François-Xavier Peretmere]
on the 5/06/08 23:29 Laurent Pertois wrote the following:
Michel Nicolas Alex wrote:
Tout ça me prouve une fois de plus que le fiber channel de Apple est surdimentionné dans la très grande majorité des cas, comme quasi tous les SAN du marché. Et vu le prix, c'est de l'arnaque.
Tu as un SAN ou juste un Xserve RAID collé à un Xserve ?
Dans le premier cas, combien de contrôleurs de métadonnées ? quel réseau privé ? combien de luns dans les pools ?
Ces questions me semblent porter sur aucun des deux cas, mais plutôt sur Xsan, le système de fichiers clusterisé d'Apple. Un SAN, c'est juste un réseau de données en mode bloc.
Fx
-- A crash reduces Your expensive computer To a simple stone.
on the 5/06/08 23:29 Laurent Pertois wrote the following:
Michel Nicolas Alex <Nicolas-Michel_REMOVE@THIS_bluewin.ch> wrote:
Tout ça me prouve une fois de plus que le fiber channel de Apple est
surdimentionné dans la très grande majorité des cas, comme quasi tous
les SAN du marché. Et vu le prix, c'est de l'arnaque.
Tu as un SAN ou juste un Xserve RAID collé à un Xserve ?
Dans le premier cas, combien de contrôleurs de métadonnées ? quel réseau
privé ? combien de luns dans les pools ?
Ces questions me semblent porter sur aucun des deux cas, mais plutôt sur
Xsan, le système de fichiers clusterisé d'Apple. Un SAN, c'est juste un
réseau de données en mode bloc.
Fx
--
A crash reduces
Your expensive computer
To a simple stone.
on the 5/06/08 23:29 Laurent Pertois wrote the following:
Michel Nicolas Alex wrote:
Tout ça me prouve une fois de plus que le fiber channel de Apple est surdimentionné dans la très grande majorité des cas, comme quasi tous les SAN du marché. Et vu le prix, c'est de l'arnaque.
Tu as un SAN ou juste un Xserve RAID collé à un Xserve ?
Dans le premier cas, combien de contrôleurs de métadonnées ? quel réseau privé ? combien de luns dans les pools ?
Ces questions me semblent porter sur aucun des deux cas, mais plutôt sur Xsan, le système de fichiers clusterisé d'Apple. Un SAN, c'est juste un réseau de données en mode bloc.
Fx
-- A crash reduces Your expensive computer To a simple stone.
Paul Gaborit
À (at) Thu, 5 Jun 2008 23:27:50 +0200, (Michel Nicolas Alex) écrivait (wrote):
patpro ~ Patrick Proniewski wrote:
In article <1ii2m9l.1thhuepv6wikrN%, (Michel Nicolas Alex) wrote:
(dans un de mes tests je mettais 30 minutes un dossier de zero kb contenant 10'000 fichiers vides
ce qui est aussi un test hyper-réaliste :)
On est pas loin de ça avec ~/Library/Mails/Mailboxes : Ici j'ai 12430 fichier de 28k en moyenne.
Si vous précisiez ce que vous voulez tester !
Vous nous parlez de smb, de ssh, de rsync, de fiberchanel, d'accès aux disques, de liens en 100 ou 1000, de petits ou de gros fichiers...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 5 Jun 2008 23:27:50 +0200,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (Michel Nicolas Alex) écrivait (wrote):
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
In article
<1ii2m9l.1thhuepv6wikrN%Nicolas-Michel_REMOVE@THIS_bluewin.ch>,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (Michel Nicolas Alex) wrote:
(dans un de mes tests je mettais 30 minutes un dossier de zero kb
contenant 10'000 fichiers vides
ce qui est aussi un test hyper-réaliste :)
On est pas loin de ça avec ~/Library/Mails/Mailboxes :
Ici j'ai 12430 fichier de 28k en moyenne.
Si vous précisiez ce que vous voulez tester !
Vous nous parlez de smb, de ssh, de rsync, de fiberchanel, d'accès aux
disques, de liens en 100 ou 1000, de petits ou de gros fichiers...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
