Je viens de m’offrir un serveur privé chez OVH, un RPS. Cela semble de jolies machine pour un cout très modeste (25€ / mois environ). Seul hic, la perf du disque qui est mutualisé dans un NAS et ne garantit que 1 Mo/s dans la version que j’ai. Après c’est plus cher. D’où la question … à quoi correspondent vraiment ses 1Mo. Du coup je lui ait appliqué mes tests habituels, dont je vous livre les résultats.

• hdparm -t /dev/sda1 : donne 2.8Mo /s ce qui est plutôt bon puisque 1Mo/s sont promis
• seeker donne 11 seeks/s avec un temps d’accès de 86.46ms. On a ici un debit de 44 Ko / s
• hdparm -t /dev/sda1 : donne 523Mo /s
• bonnie++ : write (seq char / bloc / rewrite ) – 11M – 11M – 1.8M || read (seq char / bloc ) – 2M – 2M

Les premiers éléments de performance valent grosso modo ceux d’une clef USB 1.0, autant dire que ce n’est pas l’extase. Les performance obtenues avec Bonnie sont de l’ordre du disque USB ou disque reseau NFS sur 100Mbs. Grosso-modo 3 fois moindre qu’un disque interne.
En tout cas, pour mysql, je pense qu’un gros cache est nécessaire ! A suivre avec des tests plus fonctionnels et moins technique ; a noter aussi que la QoS mise en place sur les I/O offre une certaine souplesse puisque les mesures faites ne sont pas systématiquement bloquées à 1Mo/s et tant mieux !

Coté performance calcul le résultat de lmbench est le suivant:

Process | null call / null IO / open-close / slct TCP / fork / exec prog / sh prog | 0,09 / 0,35 / 3.18 / 11.8 / 191 / 654 / 2649
Integer | calculs bits / addition / mult/ div / modulo | 0,48 / 0,48 / 0.19 / 20.5 / 19.6
Float | calculs addition / mult/ div / bogo | 1.9 / 1.9 / 8.4 / 7.63
Latency | context switch / AF UNIX / UDP / TCP / TCP-CON | 2.3 / 7.79 / 20.4 / 25.2 / 80

Ok … c’est barbare, mais il faut le comparer à d’autres tests fait. Globalement, je dirai que la machine est correct, sans plus, pas tres bonne en réseau ni en addition par rapport à mon epia 1.8G, mon P4 ou mon athlon 1.5G ; certe l’outil de bench n’utilise pas le dual core. Par contre la machine est performante en floatant et en mult / div entiere. Bref, correct et suffisant pour mon usage.
voir ici pour les autres tests faits.

Petite liste de commandes à ne pas oublier lorsque l’on part d’un RPS vierge. (A partir d’un UBUNTU serveur) … snif, ils n’ont pas de suse.

• apt-get update
• apt-get install synaptic
• apt-get install update-manager
• dans synaptic, ajouter les repo third party puis installer tomcat5 et java (a voir)
• apt-get install apache2 mysql-server php5 libapache2-mod-php5 php5-mysql
• mettre a jour les paquets en lançant update-manager -c

Un petit tool utile pour créer des clefs USB qui soient bootable, avec une ISO par exemple : UnetBooin qui se télécharge ici. L’outil existe pour Linux et Windows. Au passage, si vous souhaitez créer une clef avec une distribution de Linux, il ira la chercher tout seul comme un grand.

Comme évoqué dans un autre post, j’ai eu l’occasion ce jour de remonter un raid mirroring dont l’un des disque a rendu l’âme.
J’espérai cette manip transparente avec l’outil du bios, j’imaginais celui-ci re-clonant les disques … et bien non. sachez, amis LINUXIENS que dans une telle situation, il faudra installer un Windows pour lancer l’utilitaire nVidia vous permettant de procéder à la reconstruction. Ce n’est pas très long à condition d’avoir un disque en rab et les install du dit OS …
Bref, pour ma part, la prochaine réinstalle se fera avec un soft RAID Linux dont l’usage est finalement plus simple. Dommage car à la création ce mirroring nVidia etait très pratique..;

Vous savez, le bouton, lorsque l’on est sur l”ecran ce veille, qui permet à une autre utilisateur d’ouvrir une session … et bien sur ma Suse 10.3, il a disparu !!! etrange phénomène ! Pour corriger celà, j’ai du éditer le fichier /etc/X11/xdm/Xservers pour y ajouter les lignes suivantes:
:1 local reserve /usr/bin/X -nolisten tcp -br vt8
:2 local reserve /usr/bin/X -nolisten tcp -br vt9
J’ai ensuite créé un lien symbolique de ce fichier vers /opt/kde3/share/config/kdm/

SSHFS est une nouvelle façon de monter des partitions réseau. Par rapport à nfs, sshfs à l’avantage de ne nécessiter aucune configuration coté serveur et de pouvoir être utilisé en mode utilisation avec le mode fuse (file system in user mode)

Pour utiliser sshfs, il faut l’installer ainsi que fusermount ce sont en général deux paquets fournis avec les installs de Linux.
L’usage est ensuite simple : coté client, il faut taper une commande comme suit pour monter un répertoire:
sshfs user@serveur:/repertoire mountPoint Le répertoire répertoire sera alors monté dans “mountPoint”.
Le démontage se fait avec la commande : fusermount -u moutPoint

Coté débit, mes tests sur réseaux donnent 5.3MB/S alors que nfs me donne 10Mb/s environ. Les données sont toutefois cryptées, ce qui peut être considéré comme un plus.

Pour que cvs soit utilisable sur un répertoire monté avec sshfs, il faudra que les options -oreaddir_ino -o workaround=rename lors du montage.

Un moyen de mesurer la performance de NFS est de lancer sur une système monté, de ce type les commandes suivantes :
time dd if=/dev/zero of=test bs=16k count=16k Cette commande va créer un fichier test dans le répertoire courant, rempli de 0 et de 16384 blocs de 16384 octets (268Mb) ; Le débit et le temps seront affichés comme résultat de l’opération.
time dd if=test of=/dev/null bs=16k count=16k Cette commande lire le fichier test précédemment créé dans le répertoire courant, rempli de 0 et de 16384 blocs de 16384 octets (268Mb) ; Le débit et le temps seront affichés comme résultat de l’opération.

L’optimisation passe par la recherche de la taille de bloc la plus appropriée; cette taille est fixée au montage par les options rsize et wsize. J’ai pour ma part lesrésultats suivants:

• mount -t nfs xxxx:/home/mpoint testDir -o rw,wsize=512,rsize=512 – Wr 10,2MB/s – Rd 11,0MB/s
• mount -t nfs xxxx:/home/mpoint testDir -o rw,wsize=1024,rsize=1024 – Wr 10,3MB/s – Rd 11,1MB/s
• mount -t nfs xxxx:/home/mpoint testDir -o rw,wsize=2048,rsize=2048 – Wr 10,4 MB/s – Rd 11,4 MB/s
• mount -t nfs xxxx:/home/mpoint testDir -o rw,wsize=8192,rsize=8192 – Wr 10,2 MB/s – Rd 10,9 MB/s

Bref en conclusion, je dirai que l’impact de ces paramètres est plutôt très limité !!

Une curiosité très efficace dans le plantage de systèmes… J’ai découvert ça il y a quelques jours, venant d’un de mes étudiants (ça fait plaisir ;o) ). il s’agit d’une petite ligne de commande shell particulièrement meurtrière et donc à ne surtout pas utiliser car elle plante immédiatement les systèmes sans ulimit… Et quand je dis immédiatement, c’est immédiatement : pas même le temps de bouger la souris pour fermer le terminal ou de taper un CTRL+C ni même le temps pour le système de tracer l’emploi de la commande.
Cette ligne a en plus la bonne idée d’être particulièrement esthétique…. bref j’adore ! Voici donc la bête :
:(){ : |:& };:
Joli non !!
Voyons un peu plus ce qu’il se passe derrière ces caractères: :() { … } correspond à la création d’une fonction. : | : & correspond à l’appel récursif de la-dite fonction en lançant 2 processus supplémentaires en tâche de fond. Enfin les derniers ; : sont l’appel de la fonction précédemment définie.
Que se passe-t-il alors ? des milliers de processus shell sont lancés sur le système jusqu’à ce que mort s’en suive…
La parade ? Il suffit de limiter le nombre de processus max d’un utilisateur une centaine pour éviter que le scheduler soit saturé et que le système plante.

Cette commande ne doit surtout jamais être utilisée sur une machine autre que votre machine personnelle … et c’est à vos risques et périls !