une quetion simple a propos de la commande time et de l'utilisation CPU
sous linux. Je mesure le temps necessaire a la sauvegarde d'une base de
donnée de 7G.
pourcent 6,13%
real 17m28.692s
user 0m34.230s
sys 0m30.060s
D'apres les résultats ci-dessus, le programme pg_dump a passé environ 15
minute a rien foutre ou a faire autre chose (bizare y'a rien d'autre qui
tourne sur la becane)
Cela signifie aussi que mon job à pris en moyenne 6.13% du CPU. Pas
vraiment efficace. Le probleme viendrait t-il de postgres ?
Comment expliquer cela quand on sais qu'un gzip /var/tmp/base_bench.dump
prend a peu pres 95% du CPU.
De plus, je tourne a 200MB/s en ecriture sur disque donc le probleme ne
vient pas de la.
tu peux essayer taskset pour fixer un process sur un CPU. Dans certain cas les process tournent plus vite, le scheduler ne perd pas son temps a changer le contexte d'un CPU a un autre.
J'avais fait l'essai sous Solaris, et je constatais le contraire: un processus A lié à un processeur prenait plus de temps qu'un processus libre de changer. L'explication est simple: comme toutes les autres processus sont libres de changer, ils viennent parfois s'incruster sur le processeur auquel le processus A est lié. Donc le processus A ne dispose plus de 100% de « son » processeur.
Ensuite, si un programme n'est pas prévu pour tourner sur du multiCPU, je ne pense pas que l'OS pourra le faire.
Pour Postgres, la solution la plus simple me semble de diviser la base en plusieurs, qui pourront être dumpées en parallèle. Suivant la structure des données, la répartition peut être naturelle, possible ou stupide (au choix), et en usage courant, les requêtes pourront être, respectivement, plus rapides, insensibles ou plus lentes.
-- Jérémy JUST
Le 20 Apr 2007 02:54:08 -0700,
tu peux essayer taskset pour fixer un process sur un CPU. Dans
certain cas les process tournent plus vite, le scheduler ne perd pas
son temps a changer le contexte d'un CPU a un autre.
J'avais fait l'essai sous Solaris, et je constatais le contraire: un
processus A lié à un processeur prenait plus de temps qu'un processus
libre de changer.
L'explication est simple: comme toutes les autres processus sont
libres de changer, ils viennent parfois s'incruster sur le processeur
auquel le processus A est lié. Donc le processus A ne dispose plus de
100% de « son » processeur.
Ensuite, si un programme n'est pas prévu pour tourner sur
du multiCPU, je ne pense pas que l'OS pourra le faire.
Pour Postgres, la solution la plus simple me semble de diviser la
base en plusieurs, qui pourront être dumpées en parallèle. Suivant la
structure des données, la répartition peut être naturelle, possible ou
stupide (au choix), et en usage courant, les requêtes pourront être,
respectivement, plus rapides, insensibles ou plus lentes.
tu peux essayer taskset pour fixer un process sur un CPU. Dans certain cas les process tournent plus vite, le scheduler ne perd pas son temps a changer le contexte d'un CPU a un autre.
J'avais fait l'essai sous Solaris, et je constatais le contraire: un processus A lié à un processeur prenait plus de temps qu'un processus libre de changer. L'explication est simple: comme toutes les autres processus sont libres de changer, ils viennent parfois s'incruster sur le processeur auquel le processus A est lié. Donc le processus A ne dispose plus de 100% de « son » processeur.
Ensuite, si un programme n'est pas prévu pour tourner sur du multiCPU, je ne pense pas que l'OS pourra le faire.
Pour Postgres, la solution la plus simple me semble de diviser la base en plusieurs, qui pourront être dumpées en parallèle. Suivant la structure des données, la répartition peut être naturelle, possible ou stupide (au choix), et en usage courant, les requêtes pourront être, respectivement, plus rapides, insensibles ou plus lentes.
-- Jérémy JUST
Fabien LE LEZ
On Sat, 21 Apr 2007 13:55:34 +0200, Jérémy JUST :
L'explication est simple: comme toutes les autres processus sont libres de changer, ils viennent parfois s'incruster sur le processeur auquel le processus A est lié.
N'y a-t-il pas moyen d'empêcher ça, en réservant un processeur à l'usage exclusif de A ?
On Sat, 21 Apr 2007 13:55:34 +0200, Jérémy JUST
<jeremy_just@netcourrier.com>:
L'explication est simple: comme toutes les autres processus sont
libres de changer, ils viennent parfois s'incruster sur le processeur
auquel le processus A est lié.
N'y a-t-il pas moyen d'empêcher ça, en réservant un processeur à
l'usage exclusif de A ?
L'explication est simple: comme toutes les autres processus sont libres de changer, ils viennent parfois s'incruster sur le processeur auquel le processus A est lié.
N'y a-t-il pas moyen d'empêcher ça, en réservant un processeur à l'usage exclusif de A ?
Nicolas George
Fabien LE LEZ wrote in message :
N'y a-t-il pas moyen d'empêcher ça, en réservant un processeur à l'usage exclusif de A ?
Ça dépend énormément du scheduler, et celui de Linux n'est pas le même que celui de Solaris.
Fabien LE LEZ wrote in message
<t72k23d467rlhquodcak71j8sijsnvfoj7@4ax.com>:
N'y a-t-il pas moyen d'empêcher ça, en réservant un processeur à
l'usage exclusif de A ?
Ça dépend énormément du scheduler, et celui de Linux n'est pas le même que
celui de Solaris.
