Reprise du message précédent :

Sly Angel a écrit a écrit :     Les bases du forum passent pas en RAM

Cé con ... grace à ce genre de conneries j'ai enfoncé M$/Compaq avec  un serveur Sun sur des benchs avec un SGBD ...
J'ai demandé aux avants vente Sun de mettre le maxi en mémoire vive sur leur serveur ... 4 Go je crois ... et je leur ai demandé de me faire confiance pour la config du SGBD ...
M$ et Compaq sont repartis la queue entre les jambes du bench ...    

Sly Angel a écrit a écrit :     On m'a pas donné le choix c'est pas moi qui ai choisi la distrib     D'ailleurs peut être qu'il demande à l'install pour le /tmp mais ça m'étonnerait, dans ce cas c'est le mec qui l'a installé que je vais tuer

 
je pense pas qu'il le demande, sur ma mandrake, j'ai aussi un petit script comme ça qui se lance périodiquement. installé automatiquement bien sur.

Chubaca a écrit a écrit : En gros tu sait que Redhat a raison mais tu essaie de te persuader que tu est compétant en rejettant la faute sur eux, et tu pousse le vice a nous prendre à témoin ?

c joliment dit ça

et ca fait un moment que les redhat ont le logrotate par défaut, le clear du /tmp toutes les X ou a chaque reboot, des ptits trucs comme ça qui font qu'on peut se concentrer sur l'essentiel au niveau conf (apache, mail, ftp, nfs, nis, etc....) et qu'on peut laisser les merdes avec de la conf par défaut...
et chuis désolé mais quand on bosse sur des fichiers, ben on est dans son /home... et si on a besoin que ca soit plus rapide, on monte un bout de son /home en ram...

Zzozo a écrit a écrit :   Cé con ... grace à ce genre de conneries j'ai enfoncé M$/Compaq avec  un serveur Sun sur des benchs avec un SGBD ... J'ai demandé aux avants vente Sun de mettre le maxi en mémoire vive sur leur serveur ... 4 Go je crois ... et je leur ai demandé de me faire confiance pour la config du SGBD ... M$ et Compaq sont repartis la queue entre les jambes du bench ...

 
Tu m'étonnes, RAM powah ( enfin faut une machine stable et des synchros sur le DD de temps en temps sinon t'as l'air con en cas de crash )

 
et on configure X programmes pour qu'ils aillent bosser en /home plutôt qu'en /tmp comme c'est quasi toujours le cas par défaut. Ouais mais tu vois, j'ai pas envie de configurer TOUS mes services vers un /home/tmp.
 
Chacun sa vision, je dis pas que la mienne est bonne mais j'ai pas envie de me prendre la tête à penser à bien changer le rep de travail quand je compile un programme sur le serveur...
 

/var/tmp power
 
Resiste au reboot , meme sur debian, meme sur solaris !

Sly Angel a écrit a écrit :     Tu m'étonnes, RAM powah ( enfin faut une machine stable et des synchros sur le DD de temps en temps sinon t'as l'air con en cas de crash )

Tu met pas tout en RAM ... surtout ce qui est CONSULTE fréquemment ... en fait dans le bench, je m'étais apercu, qu'il y avait 2 bases importantes grosso modo ... l'une était quasiment utilisée en consultation uniquement, et faisait un Go en taille ... j'ai regardé de plus près la tête qu'elle avait ... j'ai droppé les indexs inutiles, en ai reconstruit des intéressants, et à chaque reboot de la machine, cette base était recopiée dans un fs en RAM ... le SGBDR n'y voyait rien ... ... ca plus un volume pour le système, et un autre pour la 2ème base (lecture-écriture) ... que du UltraSCSI en Raid  5 ... cé que du bonheur ...   ... un proc alloué au système, un pour les opérations internes au SGBDR et les 2 restants pour servir les requetes ... raaa ca marche bien comme bestiole ... les petits gars de Compaq et M$ z'étaient écoeurés ... y comprenais pas ... on leur a mis un facteur 3 dans ce bench là ...  

Zzozo a écrit a écrit :   Tu met pas tout en RAM ... surtout ce qui est CONSULTE fréquemment ... en fait dans le bench, je m'étais apercu, qu'il y avait 2 bases importantes grosso modo ... l'une était quasiment utilisée en consultation uniquement, et faisait un Go en taille ... j'ai regardé de plus près la tête qu'elle avait ... j'ai droppé les indexs inutiles, en ai reconstruit des intéressants, et à chaque reboot de la machine, cette base était recopiée dans un fs en RAM ... le SGBDR n'y voyait rien ... ... ca plus un volume pour le système, et un autre pour la 2ème base (lecture-écriture) ... que du UltraSCSI en Raid  5 ... cé que du bonheur ...   ... un proc alloué au système, un pour les opérations internes au SGBDR et les 2 restants pour servir les requetes ... raaa ca marche bien comme bestiole ... les petits gars de Compaq et M$ z'étaient écoeurés ... y comprenais pas ... on leur a mis un facteur 3 dans ce bench là ...

 
Ouais c'est clair que dans cette situation c'est l'ideal
 
La différence entre un Linuxien et un Windowsien c'est pas que l'OS est super plus puissant, c'est que le Linuxien il sait utiliser son OS

une question sur vos /home , /tmp ... en ramdisk :  comment vous mettez à jour le vrai fs ensuite ?  
copier les points de montage en ramdisk dans les repertoire réels ?

Euh ... le /home vaut mieux pas le mettre en RAM Disk ... cé un coup à avoir des ennuis ...

ca repond pas à ma question

prendre le cas d'un serveur web par exemple comme dans ce cas là par exemple :  
http://www.linuxfocus.org/Francais [...] le124.html

J aime c 'est topic hyper intructif    

 
merci

 
En général ce sont des données peu sensibles, donc en gros perso je fais un "rsync -xavlW" du répertoire en RAM vers le répertoire sur disque réguliérement en crontab et lorsque le système shutdown, il rsync automatiquement le contenu du rép en RAM vers un rép du DD.
 
En tenant compte du fait que la machine est fiable ( un serveur bien installé/hébergé qui roule depuis un moment sans problème ), on a quasi pas besoin de s'en occuper à part au shutdown du système.  
 
google avait sorti un article disant qu'ils préféraient mettre toutes leurs données en RAM parce que ça faisait acheter moins de serveur pour des performances meilleures d'ailleurs. Je suis curieux de savoir la quantité de RAM qu'ils ont pour les serveurs ceux là

 
je pense qu'il parlait d'un sous rép dans /home ( enfin j'espère )

superX a écrit a écrit : ca repond pas à ma question

Dans mon cas, je te parle de Solaris, qd je devais synchroniser un fs en RAM avec son original, et dans les deux sens, je la faisais dans un script éxécuté lors du boot/shutdown de la machine ... genre sous Linux, faut que t'amuses à créer un "service" de syncrho (un script avec un start/stop quoi ...) que tu places ensuite dans le ou les  
runlevels qui t'intéressent (aussi bien en boot qu'en shutdown, oublie pas ...) ....
Les détails exacts dépendent de ta distrib après, vu que chaque distrib a une facon légèrement/radicalement différente de gérer les runlevels ...
 
EDIT : Mais je te conseille de ne mettre en RAM disk que des trucs tempo ou utilisés en consultation  ou auxquels tu ne tiens pas forcément ... genre mets pas la base de données d'un système d'achat en ligne en RAM disk ... ... et prévois un bon onduleur de préférence ...

thx pour les tuyaux !

 

 
C'est la meilleure config!

asphro a écrit a écrit : J aime c 'est topic hyper intructif       merci

Ben cé plus un topic orienté serveurs là ... au moins on est sur d'être tranquille avec les "windowsien" là  ...

Zzozo a écrit a écrit :   Ben cé plus un topic orienté serveurs là ... au moins on est sur d'être tranquille avec les "windowsien" là  ...

 
pour ca j aime bien ce topic, j y ai appris plein de chauffe sur les ramdisk

asphro a écrit a écrit :     pour ca j aime bien ce topic, j y ai appris plein de chauffe sur les ramdisk

Si tu es amené en service de production info, tu verras que cé très souvent utilisés pour booster les perfs de serveurs Unix/Linux de tout poil ... à condition qu'il y ait un minimum d'analyse au prréalable de ce qu'il faut mettre en RAM Disk ou pas ...

Genre curieusement mettre les images/smileys du forum en RAM ça allège carrément la charge du serveur au niveau des accès disque

Sly Angel a écrit a écrit : Genre curieusement mettre les images/smileys du forum en RAM ça allège carrément la charge du serveur au niveau des accès disque

Cé sur que tu as du soulager la machine ...
Par contre, mettre les indexs pour la fonction recherche en RAM ca a pas du changer grand chose, vu le nombre de fois ou elle est utilisée ...

Zzozo a écrit a écrit :   Cé sur que tu as du soulager la machine ... Par contre, mettre les indexs pour la fonction recherche en RAM ca a pas du changer grand chose, vu le nombre de fois ou elle est utilisée ...

 
Sont trop gros ces indexs là

 
 
 tu me feras le plaisir de lire la FHS ( File Hierarchy Standart ) et la LSB , pour ce qui des data des demons c est dans /var  ( /var/named /var/www /var/ftp ... ) pas dans /home

houplaboom42 a écrit a écrit :      tu me feras le plaisir de lire la FHS ( File Hierarchy Standart ) et la LSB , pour ce qui des data des demons c est dans /var  ( /var/named /var/www /var/ftp ... ) pas dans /home

 
 
merde moi il sont dans /chroot/nondudaemon/ !!!

un topic instructif ca ne vous genes pas si je pose des question ?
 

j ai pas tout compris la tu pourrais expliquer svp ?
 
sinon quel est l interet de changer de rep pour le /var/www , /var/ftp etc  je croyais  que les repertoire et ce qu il y avait dedans etait defini tres precisement non ?
 
je ne comprend pas ce que vous mettre ds /tmp pour avoir besoin de le mettre ailleur et que celui-ci ne soit pas vider au reboot de la machine ? (pour mon utilisation j ai un rep perso qui sert de poubelle)
 
(et si vous avez un bon howto de deriere les fagos sur le ram disk je veux bien )

houplaboom42 a écrit a écrit :      tu me feras le plaisir de lire la FHS ( File Hierarchy Standart ) et la LSB , pour ce qui des data des demons c est dans /var  ( /var/named /var/www /var/ftp ... ) pas dans /home

 
Aaaahh !
Ca existe ca !
Depuis le temps que je cherchais ce genre d'info !
Ma quête touche à sa fin !
 (Par contre, standard, en anglais comme en francais, c'est un 'd' à la fin )
 
Lelfe

http://www.freenix.org/unix/fhs/

très bon topic, super instructif      
par contre faudrait voir à changer le titre, parceque c plus vraiment hyper explicite là

Pilou51 a écrit a écrit : très bon topic, super instructif       par contre faudrait voir à changer le titre, parceque c plus vraiment hyper explicite là

 
Ouais, le titre est un poil trollesque ( je le change de suite )

lol si en plus c toi qui le dis    

houla alors là respect   c sûr que ça fait moins troll

tu peux modifier l'icone du topic, parce que la ca fait le gars qui est vraiement pas content de savoir ce qu'eqst un ramdisk

houplaboom42 a écrit a écrit :      tu me feras le plaisir de lire la FHS ( File Hierarchy Standart ) et la LSB , pour ce qui des data des demons c est dans /var  ( /var/named /var/www /var/ftp ... ) pas dans /home

pour ce qui est des démons... mais le guy lui y bosse sur des fichiers a lui...on aurait dit sinon que la machine bosse.. dans ce cas, biensur tu vas pas t'amuser a aller changer tous les paths... et dans ce cas tu te fais ton propre OS qui fonctionne tout en ram et pas du tout sur le DD...

quand je bosse sur un site je bosse sur des fichiers et
pourtant c est (  ca doit etre si on respecte les normes et les standards ) par default dans /var/www/html/ et pas dans /home/httpd/html/ .

asphro a écrit a écrit :       merde moi il sont dans /chroot/nondudaemon/ !!!

 
oui et alors ? le chroot tu le met ou tu veux mais par default c est pareil les datas du demons chrootés seront dans le var/ du chroot
 
par exemple pour un bind chrooté t aura  
/chroot/bind/var/named
 
pour apache un  
 
/chroot/apache/var/www
 
etc ...

hum... j'ai lu le thread en diagonale, alors je réponds juste à Sly, même si j'ai vu des énormitées dans un ou deux posts...
 
*/ concernant le vidage auto de /tmp, ENORMEMENT d'Unix font ca... ils se basent sur le atime en général, mais certains sont un peut plus malins que ca. C'est normal. /tmp, comme son nom l'indique est pour les fichiers temporaires, donc ... _volatiles_
*/ déjas, /tmp, c une atrocitée... Entre les race conditions, et autres... Donc dans un premier temps, avis à la populasse, foutez moi un bit sticky sur /tmp, et tous les reps de ce genre (/var/run, ...). De toute facon, le mieux c'est que le tmp de chaque user soit séparré de celui des autres (~/tmp par exemple) et surtout que /tmp ne serve pas à un programme/daemon/script/cequevousvoullez à créer des fichiers...
*/ hum... /tmp en ram, c'est bourin, tout le monde à les droits sur /tmp, je peux te saturer ta ram (en accès, pas en taille) même si tu m'as foutu des limitations (setrlimit par exemple...) asser facilement...
*/ fouttre un truc en ram, ca sert juste si tu accède souvent à des fichiers du disque... Si c'est des binaires, anyway quand ils sont lancés ils sont chargés en ram.
 
Mon conseil :  
*/ si c'est pour toi, pour des fichiers -> tu te créé un ~/ram_tralala_pwetpwet chargé en ram, tu fout tes fichiers dedans...
*/ si c'est un daemon ou une appli lancée continuelement -> ca sert à rien
*/ si c'est une appli lancée fréquement ->
**/ si tu en est l'auteur -> tu créé une sorte de daemon qui reste en mémoire et qui contiens/charge/map la majorité des chaoses
**/ sinon bah tu la fout dans un ramdisk, monté de préférence dans ~/ram/foo_bar
 
 
 
Pour tout le monde :
*/ fouttez des sticky bits dans les reps où tout le monde à les droits d'écriture
*/ utilisez ~/tmp au lieu de /tmp (caca) sauf pour l'échange de fichiers, et encore...
*/ si vous codez faites gaffes si votre appli doit gérer des fichiers temp... pour vous en convaincre, jettez un oeuil sur eliott par exemple...
 
 
vala, ct le coup de geule du mec qu'en a marre que tout le monde fasse n'importe quoi.

 
moi c /chroot/apache/usr/local/apache/
      /chroot/web <-- les fichier web
  /chroot/libexec/libapache <-- les modules apache  
 
apres y mysql
 
/chroot/myysql/usr/local/mysql
/chroot/home/mysql <-- les db
 
apres postfix courrier imap meme principe
 
apres bind meme principe
 
car je m y retrouve mieux et c pour moi
 
 
 

hummm... sinon, le coup de la DB de plusieurs Go en ram, c mauvais plan, parceque même avec un onduleur qui t'alertes 5 minutes avant la perte de batterie... tu as le temps de copier/rsync la DB, plus le sync sur le HD, plus le halt propre? c'est quoi tes HDD?
 
sinon, faudrait intercepter le signal pf (power fail) dès le début du problème, copier la DB sur le HD, sync le cache HD, puis si le pn (powerfail now) surviens, tu halt proprement, sinon, si tu te prends un po (power ok), tu refout tou en ram? trops risqué...