Vous n'êtes pas identifié(e).
Pages : 1
Bonjour je lance une migration entre deux bases de Postgres 9.1, mais je me rend compte que depuis le début je swap, ce qui plombe mes perfs.
Je dois migrer à partir de 15 tables vers 32 Tables.
ma RAM est 28GB,
shared_buffers=8GB,
effective_cache_size=16Gb
work_mem=256MB
J'utilise des COPY(SELECT ..)
Chacune de mes tables à migrer fait entre 7GB et 9GB.
Quelqu'un aurait-il une idée.
Merci
Hors ligne
Ça ne devrait pas swapper. Pouvez-vous décrire exactement la procédure que vous suivez ?
Marc.
Hors ligne
Oui, effectivement je ne sais pas que le swap n'est pas vidé.
Par contre, je me demande comment ça se fait que le sharded_buffers est rapidement à 100%.
Hors ligne
Pouvez-vous expliquer comment vous diagnostiquez que «sharded_buffers est rapidement à 100%.» ?
Marc.
Hors ligne
j'ai une question : Copy utilise work_mem ?
Hors ligne
Seulement si c'est un copy sur un ordre sql qui fait un tri ou un hachage. Par exemple:
COPY (SELECT * FROM ma_table ORDER BY col) TO STDOUT.
Marc.
Hors ligne
ok merci Marc !
Hors ligne
Bonjour Marc,
j'ai installer l'extension pg_buffercache, ensuite j'ai procedé comme indiqué dans la doc DALIBO suivante :
http://www.dalibo.org/glmf107_gestion_m … postgresql
Hors ligne
Ah ok. Alors, c'est tout à fait normal que le shared_buffers soit à 100%. C'est même son but… avoir un maximum d'entrées dans le cache, en permanence. Ce qui serait anormal, c'est d'en avoir la majorité en dirty, mais même ça, ça peut arriver.
J'aimerais donc savoir quel est le processus qui prend la mémoire. Suivant le système d'exploitation, la méthode pour le déterminer est différente. Avec un Linux, par exemple, ps aux donne une bonne idée (attention, le shared_buffers est comptabilisé comme faisant partie de la mémoire de chaque processus).
Marc.
Hors ligne
ps -aux | grep postgres
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ
postgres 3776 0.0 0.5 6640344 152812 ? S 09:15 0:00 /usr/pgsql-9.1/bin/postmaster -p 5434 -D /data/pgdata91/data
postgres 3778 0.0 0.0 174936 1132 ? Ss 09:15 0:00 postgres: logger process
postgres 3780 0.5 8.9 6644588 2569000 ? Ss 09:15 1:13 postgres: writer process
postgres 3781 0.3 0.0 6643388 17896 ? Ss 09:15 0:51 postgres: wal writer process
postgres 3782 0.0 0.0 178628 2500 ? Ss 09:15 0:00 postgres: stats collector process
postgres 4020 0.0 0.0 6645604 10160 ? Ss 09:29 0:00 postgres: superdba postgres 10.23.11.12(49481) idle
postgres 4303 0.0 0.3 6657096 86560 ? Ss 09:51 0:01 postgres: superdba base_test 10.23.11.12(49600) idle
postgres 4966 0.0 1.3 6661188 391720 ? Ss 10:42 0:02 postgres: superdba base_test 10.23.11.12(49849) idle
postgres 5122 51.6 0.8 6802616 239208 ? Ds 11:21 56:33 postgres: superdba base_prod [local] ANALYZE
postgres 5150 51.8 0.4 6667144 123200 ? Ds 11:23 55:21 postgres: superdba base_prod [local] CREATE INDEX
Comment pouvez voir la mémoire consommée par chaque process ici, moi je n y comprend pas grand chose.
Hors ligne
Marc,
je me demande si je crée un index est-ce-que cette opération mets des données dans le cash.
Aurai-je besoin d'un analyze aprés la création d'un index.
Hors ligne
C'est ps aux, pas ps -aux. Heureusement, il a compris quand même.
Les colonnes:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
Ce qui nous intéresse donc c'est RSS (la mémoire utilisée). La subtilité, c'est que RSS augmente au fur et à mesure que les processus manipulent le shared_buffer (c'est à dire quand ils accèdent à des blocs de cache), même si ces blocs sont alloués.
Ce ps aux est pendant un COPY ? (je ne le vois pas dans la liste)
Marc.
Hors ligne
ps aux | grep postgres
postgres 3776 0.0 0.5 6640344 152812 ? S 09:15 0:00 /usr/pgsql-9.1/bin/postmaster -p 5434 -D /data/pgdata91/data
postgres 3778 0.0 0.0 174936 1132 ? Ss 09:15 0:00 postgres: logger process
postgres 3780 0.4 8.9 6644588 2570580 ? Ss 09:15 1:13 postgres: writer process
postgres 3781 0.3 0.0 6643388 17896 ? Ss 09:15 0:51 postgres: wal writer process
postgres 3782 0.0 0.0 178628 2500 ? Ss 09:15 0:00 postgres: stats collector process
postgres 4020 0.0 0.0 6645604 10160 ? Ss 09:29 0:00 postgres: superdba postgres 10.23.11.12(49481) idle
postgres 4303 0.0 0.3 6657096 86560 ? Ss 09:51 0:01 postgres: superdba base_test 10.23.11.12(49600) idle
postgres 4966 0.0 1.3 6661188 391720 ? Ss 10:42 0:02 postgres: superdba base_test 10.23.11.12(49849) idle
root 5183 0.0 0.0 191072 3576 pts/4 S 10:55 0:00 sudo su - postgres
root 5189 0.0 0.0 192788 2512 pts/4 S 10:55 0:00 su - postgres
postgres 5190 0.0 0.0 108416 1872 pts/4 S 10:55 0:00 -bash
postgres 5223 0.0 0.0 100924 612 pts/4 S+ 10:55 0:00 tail -f postgresql-Mon.log
postgres 5624 0.3 0.8 6645476 246260 ? Ss 12:24 0:13 postgres: superdba base_test 10.23.11.12(50298) idle
postgres 6293 42.6 0.1 6646108 47908 ? Rs 13:22 0:11 postgres: superdba base_prod [local] COPY
postgres 6294 0.0 0.0 6644688 6596 ? Ss 13:22 0:00 postgres: superdba base_prod [local] COPY
postgres 6295 41.4 0.1 6646108 47876 ? Ds 13:22 0:11 postgres: superdba base_prod [local] COPY
postgres 6296 0.0 0.0 6644688 6608 ? Ss 13:22 0:00 postgres: superdba base_prod [local] COPY
Hors ligne
Je ne crois pas que le create index écrive ses données dans le cache (mais pas le temps de vérifier là).
Pour les statistiques, oui, c'est recommandé, même si peu de choses sont collectées (toujours de mémoire, la taille de l'index et le nombre d'enregistrements au moment de l'analyze)
Marc.
Hors ligne
Ok, donc apparemment, ce ne sont pas les copy qui fuient (le rss reste petit). Un ps aux sans grep serait intéressant, au cas où ça serait autre chose qui consomme de la mémoire.
Marc.
Hors ligne
à quoi correspond exactement le RSS, VSZ, TTY
Hors ligne
RSS: c'est la quantité de mémoire non swappée mappée par le processus (c'est à dire à laquelle elle accède). Attention, cette mémoire peut être partagée (shared memory, ou fork d'un processus) entre plusieurs
VSZ: c'est la quantité de mémoire mappée par le processus (dont en swap)
TTY: c'est le terminal auquel le processus est attaché. Quand c'est ?, c'est qu'il n'est pas attaché à une console (un démon par exemple).
L'évaluation de la consommation mémoire d'un processus est un peu compliquée sous Linux, et les Unix en général, parce que beaucoup de mémoire est naturellement partagée (par le mécanisme du fork par exemple).
Marc.
Hors ligne
Merci beaucoup
Hors ligne
Bonjour Marc,
j'ai des process qui sont idle, cependant, leur RSS ne vaut pas 0 :
postgres 7909 0.0 0.6 6658892 196032 ? Ss 07:58 0:01 \_ postgres: superdba base_sans_part 10.23.11.12(52181) idle
postgres 8056 0.2 4.2 6661736 1219716 ? Ss 08:10 0:13 \_ postgres: superdba base_sans_part 10.23.11.12(55897) idle
Est-ce-que ça veut dire que c'est de la fuite mémoire?
Hors ligne
Ce matin, je vois que ça SWAP toujours !
Est-ce-que je peux mettre le resultat de ps aux dans un fixhier et l'envoyer sur le forum ?
Hors ligne
Je crois que je vais metter que les process dont le RSS != 0 :
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 21424 1092 ? Ss Oct29 0:02 /sbin/init
root 809 0.0 0.0 11312 256 ? S<s Oct29 0:00 /sbin/udevd -d
root 1990 0.0 0.0 27612 684 ? S<sl Oct29 0:00 auditd
nslcd 2015 0.0 0.0 441484 1248 ? Ssl Oct29 0:01 /usr/sbin/nslcd
root 2028 0.0 0.0 248680 1076 ? Sl Oct29 0:00 /sbin/rsyslogd -c 4
root 2085 0.0 0.0 9136 548 ? Ss Oct29 0:11 irqbalance
rpc 2099 0.0 0.0 18948 588 ? Ss Oct29 0:00 rpcbind
rpcuser 2117 0.0 0.0 23120 740 ? Ss Oct29 0:00 rpc.statd
root 2129 0.0 0.0 4540 236 ? Ss Oct29 0:00 mdadm --monitor --scan -f --pid-file=/var/run/mdadm/mdadm.pid
root 2184 0.0 0.0 29436 248 ? Ss Oct29 0:00 rpc.idmapd
dbus 2262 0.0 0.0 99368 1120 ? Ssl Oct29 0:00 dbus-daemon --system
avahi 2274 0.0 0.0 29868 1048 ? S Oct29 0:00 avahi-daemon: running [colorado.local]
avahi 2275 0.0 0.0 29740 144 ? Ss Oct29 0:00 avahi-daemon: chroot helper
root 2285 0.0 0.0 189008 1632 ? Ss Oct29 0:00 cupsd -C /etc/cups/cupsd.conf
root 2310 0.0 0.0 4064 472 ? Ss Oct29 0:00 /usr/sbin/acpid
68 2319 0.0 0.0 27464 1856 ? Ss Oct29 0:00 hald
root 2320 0.0 0.0 18092 656 ? S Oct29 0:00 hald-runner
root 2348 0.0 0.0 20208 608 ? S Oct29 0:00 hald-addon-input: Listening on /dev/input/event0
68 2358 0.0 0.0 17792 696 ? S Oct29 0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
root 2383 0.0 0.0 392100 1044 ? Ssl Oct29 0:00 automount --pid-file /var/run/autofs.pid
root 2402 0.0 0.0 63940 512 ? Ss Oct29 0:00 /usr/sbin/sshd
ntp 2410 0.0 0.0 32216 1136 ? Ss Oct29 0:00 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g
root 2486 0.0 0.0 78536 1992 ? Ss Oct29 0:00 /usr/libexec/postfix/master
postfix 2496 0.0 0.0 80776 2008 ? S Oct29 0:00 qmgr -l -t fifo -u
root 2497 0.0 0.0 265128 3632 ? Ss Oct29 0:00 /usr/sbin/abrtd
root 2505 0.0 0.0 175448 1216 ? Ss Oct29 0:00 /usr/sbin/httpd
apache 2506 0.0 0.0 177540 740 ? S Oct29 0:00 /usr/sbin/httpd
apache 2508 0.0 0.0 177540 740 ? S Oct29 0:00 /usr/sbin/httpd
apache 2509 0.0 0.0 177540 740 ? S Oct29 0:00 /usr/sbin/httpd
apache 2510 0.0 0.0 177540 740 ? S Oct29 0:00 /usr/sbin/httpd
apache 2511 0.0 0.0 177540 740 ? S Oct29 0:00 /usr/sbin/httpd
apache 2512 0.0 0.0 177540 740 ? S Oct29 0:00 /usr/sbin/httpd
apache 2513 0.0 0.0 177540 740 ? S Oct29 0:00 /usr/sbin/httpd
apache 2515 0.0 0.0 177540 740 ? S Oct29 0:00 /usr/sbin/httpd
root 2521 0.0 0.0 117172 840 ? Ss Oct29 0:00 crond
root 2532 0.0 0.0 21412 308 ? Ss Oct29 0:00 /usr/sbin/atd
root 2542 0.0 0.0 100912 552 ? Ss Oct29 0:00 rhnsd
root 2550 0.0 0.0 23004 160 ? Ss Oct29 0:00 /usr/sbin/oddjobd -p /var/run/oddjobd.pid -t 300
root 2564 0.0 0.0 4048 460 tty1 Ss+ Oct29 0:00 /sbin/mingetty /dev/tty1
root 2566 0.0 0.0 4048 460 tty2 Ss+ Oct29 0:00 /sbin/mingetty /dev/tty2
root 2568 0.0 0.0 4048 460 tty3 Ss+ Oct29 0:00 /sbin/mingetty /dev/tty3
root 2570 0.0 0.0 4048 460 tty4 Ss+ Oct29 0:00 /sbin/mingetty /dev/tty4
root 2572 0.0 0.0 4048 460 tty5 Ss+ Oct29 0:00 /sbin/mingetty /dev/tty5
root 2580 0.0 0.0 4048 460 tty6 Ss+ Oct29 0:00 /sbin/mingetty /dev/tty6
root 2581 0.0 0.0 12364 360 ? S< Oct29 0:00 /sbin/udevd -d
root 2582 0.0 0.0 12364 360 ? S< Oct29 0:00 /sbin/udevd -d
postgres 2685 0.0 0.3 6640348 99488 ? S Oct29 0:01 /usr/pgsql-9.1/bin/postmaster -p 5434 -D /data/pgdata91/data
postgres 2687 0.0 0.0 174940 700 ? Ss Oct29 0:00 postgres: logger process
postgres 2692 0.4 16.4 6644596 4719328 ? Ss Oct29 3:22 postgres: writer process
postgres 2693 0.3 0.0 6643392 17300 ? Ss Oct29 2:29 postgres: wal writer process
postgres 2694 0.0 0.0 178632 1912 ? Ss Oct29 0:01 postgres: stats collector process
1611 2747 0.0 0.0 110548 572 ? S Oct29 0:00 -bash
1611 2757 0.0 0.0 110548 824 ? S Oct29 0:00 -bash
root 6189 1.3 0.0 0 0 ? D 04:06 4:34 [flush-253:2]
root 7872 0.0 0.0 119428 4796 ? Ss 07:57 0:00 sshd: user2 [priv]
user2 7877 0.0 0.0 119428 1936 ? S 07:57 0:00 sshd: user2@pts/1
user2 7878 0.0 0.0 110548 1928 pts/1 Ss+ 07:57 0:00 -bash
postgres 7908 0.0 0.0 6645556 10712 ? Ss 07:58 0:00 postgres: superdba postgres 10.23.11.12(52180) idle
postgres 7909 0.0 0.6 6658892 196036 ? Ss 07:58 0:01 postgres: superdba base_test 10.23.11.12(52181) idle
root 8018 0.0 0.0 119428 4796 ? Ss 08:09 0:00 sshd: user2 [priv]
user2 8022 0.0 0.0 119428 1936 ? S 08:09 0:00 sshd: user2@pts/2
user2 8023 0.0 0.0 110548 1924 pts/2 Ss 08:09 0:00 -bash
postgres 8056 0.2 4.2 6661736 1219716 ? Ss 08:10 0:14 postgres: superdba base_test 10.23.11.12(55897) idle
root 8134 0.0 0.0 119428 4792 ? Ss 08:21 0:00 sshd: user2 [priv]
user2 8138 0.0 0.0 119428 1932 ? S 08:21 0:00 sshd: user2@pts/3
user2 8023 0.0 0.0 110548 1924 pts/2 Ss 08:09 0:00 -bash
postgres 8056 0.2 4.2 6661736 1219716 ? Ss 08:10 0:14 postgres: superdba base_test 10.23.11.12(55897) idle
root 8134 0.0 0.0 119428 4792 ? Ss 08:21 0:00 sshd: user2 [priv]
user2 8138 0.0 0.0 119428 1932 ? S 08:21 0:00 sshd: user2@pts/3
user2 8139 0.0 0.0 110548 1920 pts/3 Ss 08:21 0:00 -bash
root 8175 0.0 0.0 191072 3612 pts/3 S 08:23 0:00 sudo su - postgres
root 8186 0.0 0.0 192788 2508 pts/3 S 08:23 0:00 su - postgres
postgres 8187 0.0 0.0 108416 1872 pts/3 S 08:23 0:00 -bash
postgres 8218 0.0 0.0 100924 612 pts/3 S+ 08:23 0:00 tail -f postgresql-Tue.log
root 8382 0.0 0.0 119376 4292 ? Ss 08:30 0:00 sshd: user1 [priv]
user1 8386 0.0 0.0 119376 1832 ? S 08:30 0:00 sshd: user1@pts/4
user1 8387 0.0 0.0 110512 1952 pts/4 Ss 08:30 0:00 -bash
root 8425 0.0 0.0 119376 4292 ? Ss 08:32 0:00 sshd: user4 [priv]
1611 8429 0.0 0.0 119376 1820 ? S 08:32 0:00 sshd: user4@pts/5
1611 8430 0.0 0.0 110548 1900 pts/5 Ss 08:32 0:00 -bash
1611 8453 0.0 0.0 170476 2896 pts/5 S+ 08:32 0:00 psql service=service_prod
postgres 8454 0.0 0.1 6647060 48968 ? Ss 08:32 0:00 postgres: superdba base_prod [local] idle
root 8462 0.0 0.0 119376 4284 ? Ss 08:33 0:00 sshd: user4 [priv]
1611 8466 0.0 0.0 119376 1824 ? S 08:33 0:00 sshd: user4@pts/6
1611 8467 0.0 0.0 110548 1972 pts/6 Ss+ 08:33 0:00 -bash
root 8671 0.0 0.0 0 0 ? S 08:53 0:00 [flush-253:4]
1611 8701 0.0 0.0 106084 1264 ? S 08:56 0:00 /bin/bash ./charger_niveau.sh axis 1
1611 8711 0.0 0.0 106084 1264 ? S 08:56 0:00 /bin/bash ./charger_niveau.sh c3 1
1611 8717 0.0 0.0 106080 1224 ? S 08:56 0:00 /bin/bash ./extraire_niveau.sh service=service_prod axis 1 256
1611 8727 0.0 0.0 106080 1220 ? S 08:56 0:00 /bin/bash ./extraire_niveau.sh service=service_prod c3 1 256
1611 8729 0.0 0.0 170316 2404 ? S 08:56 0:00 psql service=service_prod -c SET work_mem = '256'; COPY
1611 8730 0.0 0.0 170316 2404 ? S 08:56 0:00 psql service=service_prod -c SET work_mem = '256'; COPY
1611 8731 0.0 0.0 170316 2412 ? S 08:56 0:00 psql service=service_prod -c COPY
1611 8732 0.0 0.0 170316 2412 ? S 08:56 0:00 psql service=service_prod -c COPY
postgres 8733 30.7 0.2 6647268 69580 ? Ds 08:56 14:16 postgres: superdba base_prod [local] COPY
postgres 8734 0.0 0.0 6644692 6072 ? Ss 08:56 0:00 postgres: superdba base_prod [local] COPY
postgres 8735 31.0 0.2 6647268 69704 ? Ds 08:56 14:22 postgres: superdba base_prod [local] COPY
postgres 8736 0.0 0.0 6644692 6076 ? Ss 08:56 0:00 postgres: superdba base_prod [local] COPY
root 8818 0.0 0.0 119428 4796 ? Ss 09:00 0:00 sshd: user2 [priv]
user2 8823 0.0 0.0 119428 1844 ? S 09:00 0:00 sshd: user2@pts/7
user2 8824 0.0 0.0 110548 1936 pts/7 Ss+ 09:00 0:00 -bash
root 8956 0.0 0.0 119376 4288 ? Ss 09:04 0:00 sshd: user4 [priv]
1611 8960 0.0 0.0 119376 1736 ? S 09:04 0:00 sshd: user4@pts/8
1611 8961 0.0 0.0 110548 1972 pts/8 Ss 09:04 0:00 -bash
root 9241 0.0 0.0 119376 4288 ? Ss 09:13 0:00 sshd: user3 [priv]
1623 9245 0.0 0.0 119376 1724 ? S 09:13 0:00 sshd: user3@pts/9
1623 9246 0.0 0.0 110548 1900 pts/9 Ss+ 09:13 0:00 -bash
user1 14301 1.4 0.0 17752 1556 pts/4 S+ 09:39 0:03 htop
root 14310 0.0 0.0 119376 4268 ? Ss 09:40 0:00 sshd: user2 [priv]
user2 14314 0.0 0.0 119524 1812 ? S 09:40 0:00 sshd: user2@notty
user2 14315 0.0 0.0 57284 2200 ? Ss 09:40 0:00 /usr/libexec/openssh/sftp-server
user2 14380 0.0 0.0 105940 948 pts/2 S+ 09:42 0:00 awk -F {print "TRUNCATE TABLE "$1"."$3" CASCADE;";}
user2 14381 0.0 0.0 170320 2444 pts/2 S+ 09:42 0:00 psql service=base_test postgres 14382 21.2 0.1 6644628 51132 ? Ds 09:42 0:05 postgres: superdba base_test [local] TRUNCATE TABLE
1611 14388 4.0 0.0 110140 1120 pts/8 R+ 09:43 0:00 ps aux
postfix 26976 0.0 0.0 80708 3184 ? S 09:22 0:00 pickup -l -t fifo -u.Alors quelqu'un saurat'il m'expliquer pourquoi mon serveur SWAP ?
Dernière modification par Postgres.0 (30/10/2012 11:58:17)
Hors ligne
Je pense que les seuls qui ont un RSS à zéro sont des thread noyaux (leur nom est entouré de crochet). Je ne vois pas vraiment de processus qui soit susceptible de faire swapper le système ici. Qu'est-ce qui fait dire que ça swap ? avec vmstat ?
Marc.
Hors ligne
Quand je faits htop, je vois que le swap est utilisé.
vmstat :
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 541144 1548372 4324 25560436 3 3 673 1022 8 24 4 0 91 5 0
Par contre j'aimerai bien avoir des reponses à ce post :
Bonjour Marc,
j'ai des process qui sont idle, cependant, leur RSS ne vaut pas 0 :
postgres 7909 0.0 0.6 6658892 196032 ? Ss 07:58 0:01 \_ postgres: superdba base_sans_part 10.23.11.12(52181) idle
postgres 8056 0.2 4.2 6661736 1219716 ? Ss 08:10 0:13 \_ postgres: superdba base_sans_part 10.23.11.12(55897) idleEst-ce-que ça veut dire que c'est de la fuite mémoire?
Merci
Hors ligne
- Avoir des données en swap n'est pas en soit un problème. Ce qui est problématique, c'est le temps passé à monter et descendre des données entre le swap et la mémoire. Pour ça, il faut lancer une commande comme «vmstat 1» (pour avoir un relevé par seconde), et surveiller les colonnes si et so.
- Aucun programme n'a une RSS à 0. Ça voudrait dire un programme qui ne consomme pas de mémoire. Les seuls pour lesquels vous avez 0, ce sont des threads du noyau linux (noms entre crochets dans ps), simplement parce que leur mémoire n'est pas comptabilisée comme pour les processus normaux.
Marc.
Hors ligne
Pages : 1