SMPFR

Bonjour !

J'ai une petite question, je m'y connais pas du tout en carte raid et ce serait pour un serveur au boulot ^^

La machine a un peu de mal à faire marcher correctement postgres avec son raid 1 de disques Sata 7200 tours avec une carte PERC H200

Y a des transactions (1 ou 2 Go) toutes les 3 minutes sur la base. Pensez vous que mettre une carte raid avec un cache de 512 Mo / 1 Go ça pourrait résoudre mon problème ?

Sur le site de DELL, sur le serveur actuel (un R410), ils proposent des cartes PERC H700A avec 512 Mo ou 1 Go de cache.


Et petite question aussi, y a une carte qui coute plus cher (genre 50 €) que la 512 Mo, c'est écrit "512 MV" Ca veut dire quoi MV ?

Merci à tous

spa le cache format flash le MV ?
j'ai un doute, mais je crois bien que c'est sa

Ben alors, personne ?

Heuuuuuu, démerde toi !







Perso, en sait rien, alors vais rien dire
Passe sur du SSD

fuck ssd useless vive le sas

il faut voir le genre de transaction si c'est du répétitif oui le cache te filera un bon coup de boost sinon ça changera rien

non c'est pas répétitif. C'est un volume de 1 à 2 Go qui subit un gros UPDATE (donc c'est du delete + insert) toutes les 3 minutes

je vais d'abord essayer de passer par un ramdisk pour stocker les transactions, y a plein de ram sur le serveur et elle sert à rien

2Go toute les 3mn
666Mo toute les mn
11Mo/s

je dois avoir un vieux disque IDE de 10Go qui fera l'affaire

tout ça pour dire que c'est pas ton stockage qui va ralentir, mais il faut que tu absorbes rapidement les transactions. ta solution du ramdisk me parait etre la meilleure, avec ecriture différée sur disque (RAID1 de n'importe quoi)

bah autant jouer avec le cache de la bdd directement pourquoi un ramdisk

ça depend ou il veut "deporter" le cache.

mais ça reviens en effet au meme.

Pas sur que ce soit une bonne idée le RAMDISK... C'est rapide, mais niveau fiabilité ça craint (coupure de courant, même ondulé, le système n'aura pas le reflexe de flusher les données sur un hdd classique, donc si la coupure persiste c'est adieu les données des tables que t'as mis dans la RAMDISK. Après y a moyen d'écrire des scripts pour faire ça, mais c'est un peu de boulot) surtout pour un serveur de Prod (enfin après faut voir suivant les contraintes ).
Je pense qu'en jouant sur le cache de la BDD ça peut aider pas mal sans perdre niveau fiabilité (le moteur de postgres gère la RAM (mémoire volatile) en connaissance de cause).
Au risque de froisser les adeptes du SCSI/SAS, c'est vrai qu'un SSD ça roxx pas mal niveau IOPS surtout pour une utilisation BDD

Au risque de froisser les adeptes du SCSI/SAS, c'est vrai qu'un SSD ça roxx pas mal niveau IOPS surtout pour une utilisation BDD

Oui mais : utiliser des SSD avec "Supercapacitor"
=> Intel G3
=> OCZ Vertex 3
+ ceux équipés du contrôleur Marvell C400 or Sandforce SF2000

2 SSD OCZ Vertex 3 de 60 Go en Raid 1 et le tour est joué ! ^^

// LSI propose de ne plus mettre de batteries sur leur contrôleur mais justement des SSD avec Supercapacitor.

=> En cas de panne de courant, pas de perte de données !

++

/dev/mapper/vm1-root on / type ext4 (rw,noatime,errors=remount-ro,nobh,barrier=0,commit=300)

Le serveur fonctionne niquel avec ces options de montage (sans changement de matériel). Et oui je sais, c'est pas safe du tout ^^

oui ?

Rien capté... mais ça, tu l'avais compris... :d

Rien capté... mais ça, tu l'avais compris... :d

Pas assez d'être geek ?

sinon les ramdisk physiques, du genre ceux de chez gigabyte, reactivité et securité...

Le but était que la machine aille plus vite, même au détriment de l'intégrité de la base en cas de coupure (on se sert de la bdd pour des calculs, les données changent toutes les 1-3 minutes à l'intérieur) et pour pas cher.

Je parlais d'un ramdisk logiciel avec tmpfs, mais j'ai essayé ça n'a rien apporté (sur le dossier pg_xlog). J'ai donc modifié les options de montage du système de fichiers pour qu'il ne bloque pas en attendant que le disque réponde que c'est bien écrit dessus pour continuer.

En cas d'arrêt inopiné de la machine, il y aura de la perte de fichiers à cause de ce réglage.

Le but était que la machine aille plus vite, même au détriment de l'intégrité de la base en cas de coupure (on se sert de la bdd pour des calculs, les données changent toutes les 1-3 minutes à l'intérieur) et pour pas cher.

Je parlais d'un ramdisk logiciel avec tmpfs, mais j'ai essayé ça n'a rien apporté (sur le dossier pg_xlog). J'ai donc modifié les options de montage du système de fichiers pour qu'il ne bloque pas en attendant que le disque réponde que c'est bien écrit dessus pour continuer.

En cas d'arrêt inopiné de la machine, il y aura de la perte de fichiers à cause de ce réglage.

[:al0y]

C'est du "writeback" sans BBU. :d