Quel matos pour serveur de base de données ?
le_boss
Messages postés
168
Date d'inscription
Statut
Membre
Dernière intervention
-
DROE Messages postés 148 Date d'inscription Statut Membre Dernière intervention -
DROE Messages postés 148 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
Je me demandais qu'est-ce qui influence la rapidité d'un serveur de base de données...
un gros paquet de RAM ? un "disque" SSD ? un processeur de fou ? un peu de tout ?
Pour un usage en réseau local, est-ce que la vitesse du réseau est le facteur limitant en 100Mbits/s ? Et en 1Gbit/s ?
Si un connaisseur pouvait m'éclairer sur tout ça... ou me passer un bon lien.
Merci
Je me demandais qu'est-ce qui influence la rapidité d'un serveur de base de données...
un gros paquet de RAM ? un "disque" SSD ? un processeur de fou ? un peu de tout ?
Pour un usage en réseau local, est-ce que la vitesse du réseau est le facteur limitant en 100Mbits/s ? Et en 1Gbit/s ?
Si un connaisseur pouvait m'éclairer sur tout ça... ou me passer un bon lien.
Merci
A voir également:
- Quel matos pour serveur de base de données ?
- Fuite données maif - Guide
- Base de registre - Guide
- Changer serveur dns - Guide
- Supprimer les données de navigation - Guide
- Serveur de reception mail - Guide
6 réponses
Ce devrait être plus facile si on passe de la théorie à la pratique. Puisque là tu peux étudier la machine lors de son utilisation.
Tu peux utiliser le moniteur de ressources de la machine, tu verras l'activité du processeur, de la mémoire, des disques, du réseau.
Donc pendant le traitement tu peux surveiller l'utilisation de la mémoire. La ram utilisée dépasse t-elle la mémoire physique ? Il faut éviter la mémoire paginée (c'est stocké sur disque). Sur un serveur de préférence le swap est sur un autre axe que le disque système (et aussi que les données beaucoup utilisées) et il ne devrait être utilisé qu'au minimum.
Cependant dans un moteur de base de données la mémoire utilisée ne dépend pas nécessairement de la mémoire disponible. Ainsi sur Oracle (je ne sais pas quel est ton sgbd) il y a de nombreux paramètres pour fixer les valeurs d'utilisation de la mémoire. On détermine la mémoire totale, les espaces de bufferisation, de log , du dictionnaire, zone de tri, ... Il y a des paramètres très précis, un mauvais paramétrage peut diminuer les performances. Par exemple ce paramètre : Pour que le gain de performance soit valable, n'oubliez pas que la taille du DB_BLOCK_SIZE choisi doit être un multiple du facteur d'entrelacement (stripping) de vos disques RAID. Là tu commences à te dire que tu aurais mieux fait de ne pas consulter cette doc.
Sur Oracle on peut affecter à une base jusqu'à 80% de la mémoire disponible pour des performances max. Mais si tu fixes cette valeur à 5%, la moteur de la base n'en utilisera pas plus.
Pour le processeur il faut observer l'activité de chaque coeur. Un quadri-processeur à quatre coeurs chaque ne sert à rien si ton traitement n'utilise qu'un seul processus. Tu peux être à 100 % sur un coeur et ne pas pouvoir aller plus vite alors que les 15 autres coeurs ne font rien. Là un gros mono serait plus efficace.
Pour faire simple je dirais que quand le/s processeurs/s sont à fond, c'est le cpu qui sature et que lorsque le cpu est cool ce sont les i/o disques qui limitent la vitesse du traitement.
Mais quand tu écris que ce sont des traitements qui durent plusieurs jours, il est peu probable que des améliorations matérielles entrainent une réduction de durée importante. Sauf si tu utilise un vieux coucou ou un netbook avec un atom 160, un disque à 4200tpm et 1GO mémoire sous Windows7 ;-))
Des traitements de ce type nécessitent peut être un autre mode de programmation/développement : la parallélisation de process plutôt que leur exécution en linéaire.
Un étranger, c'est un ami qu'on n'a pas encore rencontré.
Tu peux utiliser le moniteur de ressources de la machine, tu verras l'activité du processeur, de la mémoire, des disques, du réseau.
Donc pendant le traitement tu peux surveiller l'utilisation de la mémoire. La ram utilisée dépasse t-elle la mémoire physique ? Il faut éviter la mémoire paginée (c'est stocké sur disque). Sur un serveur de préférence le swap est sur un autre axe que le disque système (et aussi que les données beaucoup utilisées) et il ne devrait être utilisé qu'au minimum.
Cependant dans un moteur de base de données la mémoire utilisée ne dépend pas nécessairement de la mémoire disponible. Ainsi sur Oracle (je ne sais pas quel est ton sgbd) il y a de nombreux paramètres pour fixer les valeurs d'utilisation de la mémoire. On détermine la mémoire totale, les espaces de bufferisation, de log , du dictionnaire, zone de tri, ... Il y a des paramètres très précis, un mauvais paramétrage peut diminuer les performances. Par exemple ce paramètre : Pour que le gain de performance soit valable, n'oubliez pas que la taille du DB_BLOCK_SIZE choisi doit être un multiple du facteur d'entrelacement (stripping) de vos disques RAID. Là tu commences à te dire que tu aurais mieux fait de ne pas consulter cette doc.
Sur Oracle on peut affecter à une base jusqu'à 80% de la mémoire disponible pour des performances max. Mais si tu fixes cette valeur à 5%, la moteur de la base n'en utilisera pas plus.
Pour le processeur il faut observer l'activité de chaque coeur. Un quadri-processeur à quatre coeurs chaque ne sert à rien si ton traitement n'utilise qu'un seul processus. Tu peux être à 100 % sur un coeur et ne pas pouvoir aller plus vite alors que les 15 autres coeurs ne font rien. Là un gros mono serait plus efficace.
Pour faire simple je dirais que quand le/s processeurs/s sont à fond, c'est le cpu qui sature et que lorsque le cpu est cool ce sont les i/o disques qui limitent la vitesse du traitement.
Mais quand tu écris que ce sont des traitements qui durent plusieurs jours, il est peu probable que des améliorations matérielles entrainent une réduction de durée importante. Sauf si tu utilise un vieux coucou ou un netbook avec un atom 160, un disque à 4200tpm et 1GO mémoire sous Windows7 ;-))
Des traitements de ce type nécessitent peut être un autre mode de programmation/développement : la parallélisation de process plutôt que leur exécution en linéaire.
Un étranger, c'est un ami qu'on n'a pas encore rencontré.
Salut,
Dans un serveur tout entre un peu en ligne de compte. Mais tout d'abord les disques, on utilise des disques à 15000tpm et un serveur n'est pas bâti comme un pc. Le controleur raid est une carte physique spécialisée, qui comporte des barrettes mémoires et fait office de cache. Mémoire et processeur vont plus entrer en jeu par rapport au nombre d'utilisateurs simultanés 10 ou 500 cela change la donne.
Pour le réseau aujourd'hui on ne peut pas envisager un serveur sérieux sans gigabit, mais la aussi c'est dépendant du sujet. Si tu utilises ta base de données pour des statistiques et que tu veux la moyenne appliquée sur 200 millions de lignes, le résultat qui va transiter sur le réseau c'est 10 octets alors que si tu fabriques un état avec les 200 millions de lignes ce sont des gigas qui vont traverser le réseau.
Puis enfin, utiliser une base de données c'est d'abord optimiser la structure de la base en fonction de son utilisation, et pour les développeurs chercher les requêtes les plus adaptées.
A chaque contexte son point faible. Mais le plus souvent les gains de performance énormes se s'effectuent pas sur le matériel, mais sur l'organisation de la base et l'optimisation des programmes et requêtes l'utilisant.
cdlt
ps : je n'ai pas encore vu dans mon entourage de serveurs avec des ssd, parce qu'on privilégie souvent de gros serveurs avec de fort volumes disques.
Un étranger, c'est un ami qu'on n'a pas encore rencontré.
Dans un serveur tout entre un peu en ligne de compte. Mais tout d'abord les disques, on utilise des disques à 15000tpm et un serveur n'est pas bâti comme un pc. Le controleur raid est une carte physique spécialisée, qui comporte des barrettes mémoires et fait office de cache. Mémoire et processeur vont plus entrer en jeu par rapport au nombre d'utilisateurs simultanés 10 ou 500 cela change la donne.
Pour le réseau aujourd'hui on ne peut pas envisager un serveur sérieux sans gigabit, mais la aussi c'est dépendant du sujet. Si tu utilises ta base de données pour des statistiques et que tu veux la moyenne appliquée sur 200 millions de lignes, le résultat qui va transiter sur le réseau c'est 10 octets alors que si tu fabriques un état avec les 200 millions de lignes ce sont des gigas qui vont traverser le réseau.
Puis enfin, utiliser une base de données c'est d'abord optimiser la structure de la base en fonction de son utilisation, et pour les développeurs chercher les requêtes les plus adaptées.
A chaque contexte son point faible. Mais le plus souvent les gains de performance énormes se s'effectuent pas sur le matériel, mais sur l'organisation de la base et l'optimisation des programmes et requêtes l'utilisant.
cdlt
ps : je n'ai pas encore vu dans mon entourage de serveurs avec des ssd, parce qu'on privilégie souvent de gros serveurs avec de fort volumes disques.
Un étranger, c'est un ami qu'on n'a pas encore rencontré.
Bonsoir le Boss et Jee pee
Apres toute ces bonnes tartines d'explications :)
tu pourras via le gestionnaire de taches, regarder la place mémoire occupé par le processus oracle.exe en plein traitement. Si c'est du genre 300 000 K ou 1 700 000 K.
Si tu es à 300 000 K par exemple, il faudra penser à augmenter la SGA.
quelle est la version oracle ?
le traitement de plusieurs jours effectue seulement des calculs ? pas d'insert, update ou autres?
http://www.dba-ora.fr
Apres toute ces bonnes tartines d'explications :)
tu pourras via le gestionnaire de taches, regarder la place mémoire occupé par le processus oracle.exe en plein traitement. Si c'est du genre 300 000 K ou 1 700 000 K.
Si tu es à 300 000 K par exemple, il faudra penser à augmenter la SGA.
quelle est la version oracle ?
le traitement de plusieurs jours effectue seulement des calculs ? pas d'insert, update ou autres?
http://www.dba-ora.fr
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Quelle tartine... :-) Cool, merci pour les infos.
On est bien d'accord sur le fait que le plus grand potentiel d'optimisation se situe au niveau de la structure et des requêtes. En partant du principe qu'on ne peut pas faire mieux de ce côté là, y a-t-il un moyen de connaître le facteur limitant au niveau matériel ?
J'explique un peu mon cas:
On a une base de données (mûrement réflechie lors de sa conception) qu'on utilise pour faire des calculs qui actuellement peuvent durer plusieurs jours. Sachant qu'on utilise des machines desktop "normales" comme serveurs de base de données, j'aimerais bien savoir qu'est-ce qui pêche le plus au niveau matériel sur ces serveurs pour améliorer leurs performances, si possible.
On est bien d'accord sur le fait que le plus grand potentiel d'optimisation se situe au niveau de la structure et des requêtes. En partant du principe qu'on ne peut pas faire mieux de ce côté là, y a-t-il un moyen de connaître le facteur limitant au niveau matériel ?
J'explique un peu mon cas:
On a une base de données (mûrement réflechie lors de sa conception) qu'on utilise pour faire des calculs qui actuellement peuvent durer plusieurs jours. Sachant qu'on utilise des machines desktop "normales" comme serveurs de base de données, j'aimerais bien savoir qu'est-ce qui pêche le plus au niveau matériel sur ces serveurs pour améliorer leurs performances, si possible.
ça c'est de la réponse...
Okay, je pourrais effectivement regarder ce que raconte le gestionnaire des tâches pendant que les calculs tournent. Au niveau proc/ram, ça tient encore plus ou moins la route, c'est des core 2 duo avec au minimum 3 Go de RAM, par contre je n'ai aucune idée si les disques durs sont véloces ou pas. A priori, j'aurais tendance à croire que ce n'est pas le cas, comme presque toujours sur les machines desktop de M/Mme tout le monde.
On est sous Oracle, mais je me vois mal commencer à bidouiller dans les paramètres des trucs aussi pointus que celui que tu cites... (bon en l'occurrence on a un seul disque physique par machine donc pour le raid c'est raide ;-))
Merci jee pee pour tous ces éclaircissements fort bien rédigés :-)
Okay, je pourrais effectivement regarder ce que raconte le gestionnaire des tâches pendant que les calculs tournent. Au niveau proc/ram, ça tient encore plus ou moins la route, c'est des core 2 duo avec au minimum 3 Go de RAM, par contre je n'ai aucune idée si les disques durs sont véloces ou pas. A priori, j'aurais tendance à croire que ce n'est pas le cas, comme presque toujours sur les machines desktop de M/Mme tout le monde.
On est sous Oracle, mais je me vois mal commencer à bidouiller dans les paramètres des trucs aussi pointus que celui que tu cites... (bon en l'occurrence on a un seul disque physique par machine donc pour le raid c'est raide ;-))
Merci jee pee pour tous ces éclaircissements fort bien rédigés :-)