Bonjour,
Nous faisons tourner un server 2008 avec SQL server et 4go de RAM.
Bien sûr, on est en 32 bits ce qui fait qu'on ne peu ajouter de la RAM sans tout réinstaller.
Et une réinstall n'est pas à l'ordre du jour.
 
Actuellement, la RAM arrive assez rapidement à saturation et le pagefile est constamment sollicité, quasi 4go en permanence.
 
D'où l'idée d'ajouter un petit SSD de 16go pour pallier au manque de RAM, en mettant le pagefile dessus.
L'idée est d'économiser les disques de la grappe RAID et pourquoi gratter un peu en performances.
 
Est-ce que ça vous paraît cohérent ? Dangereux ?
Quelqu'un a déjà tenté ?

Aucun intérêt à mon avis.
SQL Server utilise-t-il vraiment les 4 Go de RAM (il se les alloue complétement mais n'utilise pas tout ???)
De même pour le pagefile, je ne suis pas spécialiste BdD mais si y'a des gens ici qui connaissent...

Avis contraire :
 
Placer le pagefile sur un support de stockage plus rapide ne peut être que bénéfique. S'il est sollicité, le système sera de fait plus véloce.
 
Mais bon la vrai soluce, tu la connais : passer en 64bits.

Je pense ce que veut dire Akizan.. c'est quel est l'intêret pour une petite base de donnée de faire cette manipulation ? pour gagner combien en perf... sera t'elle vraiment visible pour une si petite base?

Cohérent? Oui; Dangereux? mhh... un SSD qui n'arrête pas d'écrire/lire/réécrire (comportement typique d'un BDD) va s'user prématurément. A priori je dirais que c'est du bricolage. ça peut aider à court terme mais comme dit plus haut, un passage en 64bits et ajouter de la vraie RAM ne peut être que bénéfique!
 
Le pagefile est il en fixe ou en auto? Avec 4Go RAM tu devrais plutot être à 6Go de pagefile

Pas spécialiste, mais j'en ai installé 2 ou 3 dans ma vie des sql serveur
 
Par défaut, ton SQL SERVEUR va tenter de gérer lui même la mémoire (d'où l'intérêt de pas placer un SQL server sur une VM avec mémoire dynamique, mais là n'est pas la question). Donc il va tout prendre, même si il ne l'utilise plus, et ne jamais rendre la mémoire au système.
 
Pour rendre ton système un peu plus sain, tu peux déjà bridé ton sql serveur à utiliser une certain nombre de mémoire ... Et laisser quelques ressources au système (ca se passe dans le studio sql, mais ne me demande pas le chemin de tête, Google it !).
 
Tu vas donc te retrouver avec un système un peu plus véloce, restera à surveiller les perfs du SQL (mais bon ... ca doit pas être une serveur hyper demandé).
 
Par contre, si ton SQL commence à ramer ... là tu as un sous dimensionnement de ton serveur. Et franchement ... jouer sur la rapidité de stockage du swap, c'est reculer pour mieux sauter ... Pour moi le swap c'est un moyen de gestion de contention, en gros ca permet à tes applis de tourner quand la mémoire est pourtant pleine .... C'est très pratique, mais ca doit rester de la gestion occasionnel. Un fonctionnement en swap ... Bof ...
 
Et puis le swap sur un SSD (surtout si le disque en question à base de mémoire MLC) ... Je suis pas sûr de la durée de vie du disque surtout si tu travail de façon permanente en swap.

Bonjour,
 
perso, je mettrais plutôt du 15k en raid 1 pour faire un swap dédié. Le SSD est trop "jeune" pour tenter le coup. Et un seul disque ... si ça crash, j'ai peur que le serveur se demande comment remettre son fichier de SWAP si y a plus de disque pour le faire et reste à se poser la question et ne plus continuer à booter :s

Oui, comme dit c'est du bricolage, c'est sûr. La soluce serait bien sûr le 64bits.
Le soucis c'est qu'il y a peu de chances qu'on réinstalle tout uniquement pour rajouter de la RAM.
Sachant qu'il y a 4 serveurs avec la même config et qu'on ne peut se permettre un arrêt de service aussi long, c'est exclu.
Donc si on change, on rachète des serveurs, on remonte tout chez nous et on remplace les serveurs. Mais ce n'est pas à l'ordre du jour.
 
C'est vrai qu'on pourrait mettre un 15k, ce serait plus sûr, parce qu'effectivement je me demande bien ce que fait Windows quand le disque censé contenir le pagefile n'est plus là.
Et l'idée principale, c'est d'économiser les disques durs principaux. Il n'y a pas de problème de lenteur. J'avais pensé au SSD pour un petit bonus de perfs, mais c'est sûr qu'il est plus sage d'utiliser un bon vieux disque dur.
 
Sinon j'ai check, c'est pas forcément SQL qui lit/écrit sur le pagefile en fin de compte, il utilise dans les 1.6/1.9 go de RAM et génère peu de page faults.
Ce sont les autres applications, notamment un de ces fameux svchost qu'on aime tant.
Vous connaissez un moyen pour connaître les applis qui utilisent le pagefile ? Jamais réussi à trouver un truc valable.
Parce qu'on a un autre serveur avec 1.2go de RAM libre et un pagefile de 2.5go.
C'est normal d'après vous ? Moi ça me perturbe.
 
Et enfin, SQL Server est réglé en auto effectivement, mais je crois que c'est plutôt bien géré l'allocation de mémoire par SQL server, non ?  
D'ailleurs, question pour les experts de SQL server, il alloue la mémoire vis à vis du système Windows ou vis à vis de windows + applis tierces ?
Parce qu'il y a un MySQL aussi, pas très gourmand (500mo), mais tout de même, sur 4go ça compte.

Autrefois il y a bien longtemps (huit ans ) le Gigabyte I-RAM était une carte PCI qui prend 4Go de DDR1, avec un port SATA 1 pour se faire passer pour un disque.
 
Cela aurait été bien sympa, bien entendu ce type de périphérique existe toujours, en "enterprise" qui coûte de gros $$$
 
Sinon, j'attendais qu'une future mémoire telle que la MRAM puisse être utilisée en SATA ou PCIe pour cet usage, pour mon misérable desktop (ou ceux encore plus vieux coincés vers 1Go) mais il s'avère que je peux attendre longtemps.
 
Dernière piste le PAE, est-il possible d'augmenter la RAM, booter en PAE, obliger toutes les applis à rester sous les 4G (c'est ce que fait XP bien que le PAE lui permette de supporter 64Go), créer un ramdisk au dessus de 4G pour mettre le swap dessus? complètement tordu mais un peu envisageable (peut-être plus sous linux)
Ou en oubliant les conneries ci-dessus, s'en remettre au PAE. Tu peux ajouter de la RAM et rebooter et voir ce qui se passe (hum)
 
D'ailleurs.. le Windows est-il booté avec le paramètre /3GB? Ce qui permet à un processus d'utiliser 3Go max sinon la limite est 2Go. On dirait que le SQL Server reste tout seul comme un grand sous la limite des 2Go dans ton cas.

process explorer : http://technet.microsoft.com/fr-fr [...] 96653.aspx
 
tu ajoutes dans l'affichage la colonne virtual memory
pour voir comment est décomposé ton svchost, tu fais View -> Show process tree ; cela permet de voir les process fils et leur consommation
dans svchost.exe en regardant le service associé tu pourras identifier ce qui prend autant de mémoire
 
après normal/pas normal pour l'utilisation du pagefile, de manière globale c'est normal d'en avoir et de l'utiliser ; après la vraie question c'est : est-ce que la mémoire que tu as est en adéquation avec le fonctionnement de tes applis ?
Si tu héberges une appli développée par une TPE de 3 punks sortis d'école, et que pour faire tourner l'appli il te faut 4Go de RAM sinon ca swap, et bien tu n'as pas trop le choix...