Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#51 Re : Optimisation » lenteur de lecture sur les foreign tables. » 17/11/2014 16:18:36
Est il possible de le rendre intelligent et Comment?
#52 Re : Optimisation » lenteur de lecture sur les foreign tables. » 17/11/2014 15:23:57
Merci Guillaume,
le count(*) n'est qu'un exemple.
Est ce que je sous entend que si on crée un index sur une table (toto) en locale est bénéfique pour l'exploitation de la foreign table?
Bien à toi
#53 Re : Optimisation » lenteur de lecture sur les foreign tables. » 17/11/2014 13:25:45
Est ce que quelqu'un pourras m'aider ou m'aiguiller SVP?
#54 Optimisation » lenteur de lecture sur les foreign tables. » 17/11/2014 12:31:54
- lemjid
- Réponses : 20
Bonjour tout le monde,
Après avoir mis en place foreign_data_wrapper sur postgresql, Je rencontre un énorme lenteur sur l'exploitation des tables. Le temps de réponse de select sur des petite tables est multiplié par *5 voir par *10.
Le problème c'est que les foreign tables n'ont ni clé primaire ni index et je suis désolé de dire que je ne sais pas comment créer une clé voir un index sur foreign table.
l'ordre de creation de foreign table n'accepte pas le (CONSTRAINT) et je suis à court d'idées. 
--
voici quelques infos:
--------------------------------------------------------------------------------------------------------------
PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3), 64-bit
--
plan d'exécution select count(*);
===
table réelle:
=========
explain analyze select count(*) from accord;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------
Aggregate (cost=31.00..31.01 rows=1 width=0) (actual time=3.473..3.474 rows=1 loops=1)
-> Seq Scan on accord (cost=0.00..27.60 rows=1360 width=0) (actual time=0.026..1.823 rows=1360 loops=1)
Total runtime: 3.581 ms
(3 rows)
=======
foreign table:
===========
explain analyze select count(*) from accord;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------
Aggregate (cost=220.92..220.93 rows=1 width=0) (actual time=11.130..11.132 rows=1 loops=1)
-> Foreign Scan on accord (cost=100.00..212.39 rows=3413 width=0) (actual time=2.786..9.258 rows=1360 loops=1)
Total runtime: 37.167 ms
(3 rows)
==>
Merci d'avance pour votre aide.
#55 Re : Installation » Problème initdb post changement d'authentification postgres en md5 » 24/10/2014 15:07:35
Bonjour,
Moi aussi je ne voit pas comment "initdb" démarre ou pas!?
Concernant le paramètre "md5" dans hba_file, voici ce qu'il faut faire.
$ initdb --help
Usage :
initdb [OPTION]... [RÉP_DONNÉES]
Options :
-A, --auth=MÉTHODE méthode d'authentification par défaut pour les
connexions locales
==>initdb -D /répertoire/pg_data -U adminuser -W(for pwd) -A md5 -E 'ENCODING'.
==>C'est quoi le message d'erreur que tu as eu? vérifie aussi ton .bash_profile ensuite essaie de faire /usr/pgsql-9.3/bin/initdb ...
Bien à toi
#56 Re : Réplication » Server esclave in read only. » 06/10/2014 15:34:47
Bonjour tout le monde,
Désolé de vous déranger encore une fois. J'ai essayé d'avoir une vue analytique des différentes réponses afin d'avoir une configuration avec PostgreSQl qui me permet de faire du réporting à partir des données en temps réel, sans succès.
Quelqu'un pourra me donner un avis sur la configuration "idéale" (la plus adéquate) pour faire du reporting? Avec ou sans "slony"? Si avec, ya il des préconisations ou spécificités? Si sans, qu'est ce que je peut mettre en place?
Merci d'avance
#57 Re : Réplication » Server esclave in read only. » 30/09/2014 17:59:28
Merci Julien,
Est il possible de m'orienter vers un lien URL ou tuto explicant l'agrégation sur serveur esclave?
Merci d'avance
#58 Re : Réplication » Server esclave in read only. » 30/09/2014 16:03:08
Bonjour,
Oublions le reporting à J-1.
Dans le cas de reporting (pour des données en temps réel), est ce que SLONY me permet d'écrire sur un serveur postgresql esclave?
d'avance merci.
#59 Re : Réplication » Server esclave in read only. » 30/09/2014 09:28:53
Bonjour,
Désolé je me suis mal exprimé. Je site:"Il n'y a que deux solutions : 1. vous leur laissez une autre base pour qu'ils y stockent des données (mais ce sera lent et moche)".
Comment ça peut se présenter? deux serveur distincts avec une base chacun (bases identiques) dont un accessible par les utilisateurs? comment la base de reporting se met à jour? par restauration? quotidienne? permanente? et comment?
Merci d'avance
#60 Re : Réplication » Server esclave in read only. » 29/09/2014 20:02:18
Bonjour,
D'abord, merci pour vos réponses qui sont interessantes.
Pour "ruisebastien" la restauration s'effectue une fois par jour? (la nuit après maj des données sur maître par exemple). Est ce que c'est ça ce que t'appel "une restaure d'une hotback"?
Pour "guillaume L." comment voit-on le stockage c.a.d plus ou moins ce que j'ai compris de la proposition de "ruisebastien"? ou autre chause car je n'ai pas compris pourquoi (lent) si c'est une base autonome? ou tu veux dire autre chose?
Pour Slony et londiste je n'ai rien à dire car je n'ai pas de recule la dessus. C'est peut être le moment fatidique pour ce lancer!
#61 Réplication » Server esclave in read only. » 29/09/2014 15:44:00
- lemjid
- Réponses : 10
Bonjour tout le monde,
J'ai mis en place un environnement postgresql-9.2 en (hot-standby). le plus important c'est que l'esclave soit accessible en (LECTURE SEUL). Or cette spécificité me pose un petit souci, eeeeh grand plutôt.
Disant que les "utilisateurs" qui veulent faire du reporting sur l'esclave, utilisent de requêtes pour faire "create t1 (temp-table) from select ....from table t2 join...+condition" pour avoir un rapport bien définie et sélectif puis ils consultent le contenu de cette table.!!!!!???
Non! je n'ai pas fumé, je sais que je peut pas faire (create "même pas table temporaire", update, drop...) sur l'esclave car les tables système sont verrouillées.
Je fait appel à votre lumière pour savoir comment je peut avoir une solution à ce PBM. Sachant que les utilisateurs normaux n'ont pas accès au maître (que l'admin application(pour maj données) et admin base(pour maintenance).
D'avance Merci!
#62 Re : Réplication » pgloader pour streaming replication: » 23/12/2013 18:15:16
En gros c'est l'utilisation de ~6 fichiers '.csv'
1- 22567649 lignes comme ceci "3024820100000012230#9991000000000011176#GROLLIER#NATHALIE#2#24/10/1963#3#1#0182#09144#0#22/12/2001#04/06/2011#18/11/2013#IM"
2- 19146869 lignes comme ceci "3250390100133810089#10494#228#04/12/2013#20/12/2013 11:59:59"
3- 523444 lignes comme ceci "3250390040000617656#9996000000000009719#MULLIE#Roger#1#10/03/1930#3#1#3121#95001#0#28/06/2007#04/01/2011#13/11/2013#IB"
4- 19146869 lignes comme ceci "3250390100040682654#02132#641#03/12/2013#19/12/2013 11:59:59"
5- 2049939 lignes comme ceci "3250390240000002178#9994000000000072660#CARDOSO RAMOS#Monica Isabel#2#02/07/1980#3#1#2829#06301#0#06/06/2005#04/12/2012#13/11/2013#IP"
6- 1837191 lignes comme ceci "3250390260014507988#01820#0#18/07/2012#19/12/2013 11:59:59"
Donc une somme de ~"65271961" lignes.
#63 Re : Réplication » pgloader pour streaming replication: » 20/12/2013 10:23:14
checkpoint_warning = 30s par défaut je n'ai pas touché. et checkpoint_segments j'ai commencé à 60, 80, 100, 150, 200 et puis 300. à 300 je n'ai plus le message mais avant oui.
#64 Re : Réplication » pgloader pour streaming replication: » 19/12/2013 23:00:21
J'avais indiqué que j'ai augmenté au fur et à mesure ce paramètre même à 200 j'avais un message m'invitant à l'augmenter. C'est la raison pour laquelle je suis arrivé à cette valeur. Je commence à m'inquieter.
Est ce que cette valeure est très haute?
Autour de combien tu me conseil de la mettre?
Merci d'avance
#65 Re : Réplication » pgloader pour streaming replication: » 19/12/2013 15:32:25
Merci encore,
Pour le paramètre checkpoint_segments je l'ai mis à 300. C'est un peut trop oui mais j'ai commencé par 60 et à chaque fois j'ai le message dans le log PostgreSQL me demandant de l'augmenter même à 200 du coup je l'ai mis à 300 et depuis plus de message. Est ce que c'est considéré comme valeur trop grosse?
Bien à toi
#66 Re : Réplication » pgloader pour streaming replication: » 18/12/2013 16:58:33
Bonjour Guillaume,
Merci beaucoup pour ta réponse.
Je suis vraiment étonné du fait que la taille du FS 'pg_xlog' et 'pg_arch' soient petits (17Go chacun). C'est juste une interrogation. Si ma base au final fera qq chose comme ~25-30 Go, pour le FS 'pg_data' pas de problème il faut juste prévoir plus que 30Go c.a.d 35 et plus. Mais pour les FS 'pg_xlog' et 'pg_arch' je suis incapable de dire ou d'estimer la taille adéquate.
Pour ne pas faire au (pif o mètre), tu pourras STP me dire ce que je dois mettre comme taille ou comment peut on faire une estimation?
Merci d'avance
#67 Réplication » pgloader pour streaming replication: » 18/12/2013 16:02:34
- lemjid
- Réponses : 10
Bonjour tout le monde,
j'ai une replication en streaming entre 2 machines identiques:
PostgreSQL 9.2.6 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3), 64-bit
MemTotal: 12198524 kB
cat /proc/cpuinfo | grep model | cut -c14-
Intel(R) Xeon(R) CPU X5670 @ 2.93GHz
Intel(R) Xeon(R) CPU X5670 @ 2.93GHz
Intel(R) Xeon(R) CPU X5670 @ 2.93GHz
Intel(R) Xeon(R) CPU X5670 @ 2.93GHz
FS pg_arch=17Go sur machine esclave.
FS pg_xlog= 17Go
Mon problème est: Pendant le chargement de la base "~12Go" pgloader crée un fichier temporaire puis il commence a faire l’insertion de donner. C'est dans cet étape que je commence à voir mon FS 'pg_arch' gonfler et se remplir puis le "pg_xlog" du maître jusqu’à que la réplication soit corrompu et puis ma base esclave et maître arrêté.
Ce que j'ai fait:
work_mem = 500MB
maintenance_work_mem = 1GB
autocommit = off
checkpoint_completion_target = 0.5
checkpoint_timeout = 15mina
temp_buffers = 100MB
Ces modifications on améliorées un peut la situation mais vers la fin il y a un crash aussi.
Questions:
1-Suis je obliger de couper la replication avant le chargement des données? (chose que je ne devrai pas faire car je suis susceptible de faire un chargement important via un batch la nuit).
2-J'ai eu l'expérience de charger des données plus importantes sans pgloader avec succès. Faut il faire qq chose avec pgloader vu que je ne maîtrise pas son fonctionnement?
3-Que fait mon "pg_archivecleanup" qui est bien renseigné dans "recovery.conf" alors que pg_arch arrive jusqu'a 100% de taux de remplissage (17Go)? peut on le forcer afin d'éviter le crash?
4-Est ce que tout simplement je suis passé à côté d'un paramètre et ou j'ai mal fait qq part?
Merci d'avance pour votre aide
Bonne fête de fin d'année à toutes et à tous
B.LEMJID
#68 Re : Migration » Migration PostgreSQL 8.2 vers 9.2 » 14/11/2013 17:44:52
Bonjour,
Je prends ce poste pour ne pa en créer un de plus pour le même sujet.
Je devrai faire une migration postgresql-8.1 à postgresq-9.x (probablement 9.3). J'ai lu qu'il ya en effet des problème de procédures stockées (fonctions) concernant les "implicit_cast". Ma question est:
Comment on peut palier au problème sans devoir retaper toutes les fonctions? Car il y a une différence de syntaxe de création (CREATE CAST)
postgres8.1=====>CREATE CAST (text AS int4) WITH FUNCTION int4(text);
postgres9.3=====>CREATE CAST (bigint AS int4) WITH FUNCTION int4(bigint) AS ASSIGNMENT;
Merci d'avance
B.LEMJID
#69 Re : Optimisation » DUMP trop lent » 22/10/2013 12:31:30
Je ne connais pas l'option nummactl pour avoir la valeure zone_reclaim_mode en revanche j'ai ça comme valeure:
cat /proc/sys/vm/zone_reclaim_mode
0
et ça aussi:
cat /etc/sysctl.conf | grep zone_reclaim_mode
vm.zone_reclaim_mode=0
Je te t'informerai du résultat du dump avec zip externe.
#70 Re : Optimisation » DUMP trop lent » 22/10/2013 11:37:27
Merci julien pour ta réponse,
Les dés sont jetés. Pas de plateforme NUMA:
[root@xxxxxx ~]# numactl --hardware
available: 1 nodes (0)
node 0 size: 8828 MB
node 0 free: 168 MB
node distances:
node 0
0: 10
Pas de NUMA pas de "zone_reclaim_mode"! Pas de bras...
Je n'ai pas vu la valeure par défaut car je n'ai pas redémarrer la machine pour le voir (ce n'est pas possible pour l'instant). Si c'est utile pour avancer je peut le faire ultérieurement le W.E.
#71 Re : Optimisation » DUMP trop lent » 21/10/2013 17:08:02
Bonjour Julien,
Le sujet c'est que j'aurai bien aimé que le paramètre "vm.zone_reclaim_mode" marche ça sera génial. Mais je vais essayé avec un noyau plus récent. En revanche je n'ai pas bien saisie ta proposition!! Est ce que tu veux dire que j'imbrique la sortie de mon dump dans un zip? c.a.d je fais la sauvegarde de la base et en même temps je zippe le fichier de sortie "$DB.dump" avec (pgzip2 ou pzip)?
Une curiosité toujours sur "vm.zone_reclaim_mode" sur quelle distribution et version de linux tu l'as essayé?
Bien à vous
#72 Re : Optimisation » DUMP trop lent » 21/10/2013 11:25:52
Bonjour,
Je ne sais pas s'il faudra fournir plus d'informations? Ou si Julien (ou quelqu'un d'autre bien évidemment) pourra nous dire ce qu'il pense de cette situation. Il sera très pénible pour moi de rester sur sa faim.
Bien à vous
#73 Re : Optimisation » DUMP trop lent » 18/10/2013 09:50:39
Voici d'autre éléments:
sysctl.conf
# Controls IP packet forwarding
net.ipv4.ip_forward = 0
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0
# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0
# Controls whether core dumps will append the PID to the core filename
# Useful for debugging multi-threaded applications
kernel.core_uses_pid = 1
# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1
# Controls the maximum size of a message, in bytes
kernel.msgmnb = 65536
# Controls the default maxmimum size of a mesage queue
kernel.msgmax = 65536
# Controls the maximum shared segment size, in bytes
kernel.shmmax = 68719476736
# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296
#configuration postgresql
vm.dirty_background_ratio=5
vm.dirty_ratio=10
vm.swappiness=10
#perform_dump
vm.zone_reclaim_mode=0
/etc/fstab:
file system postgres:
/dev/VolGroup00/lv_softwares /softwares ext3 defaults,noatime 1 2
Bien à vous
#74 Re : Optimisation » DUMP trop lent » 18/10/2013 09:41:20
Bonjour Guillaume bonjour Julien,
Je n'ai pas de bonnes nouvelles à vous annoncer à propos du paramètre "vm.zone_reclaim_mode".
Alors j'ai fait un test 3 fois le dump d'une base de ~40Go. avec la même commande "$PGDUMP -Fc $DB -v > $BACKUP_DIR/$DB.dump" et j'ai eu le même temps d'exécution du dump avec le paramètres "vm.zone_reclaim_mode=0". et sans ce paramètre. La 3ème fois j'ai rajouté l'option "-Z 2" et là il y a eu une différence significative. sauf la taille du dump qui à été un peu plus grand.
Une précision après avoir modifier le fichier "/etc/sysctl.conf", je n'ai pas redémarrer le serveur, j'ai juste fait "sysctl -p".
Faut il redémarrer le serveur? Est ce que j'ai loupé une coche ou une étape? Faut il modifier qq paramètre postgresql.conf à fin de l'associé au changement de sysctl? Si ça marche chez vous pourquoi pas chez moi?! faut il faire un autre test? SNIF...
Bien à vous
#75 Re : Optimisation » DUMP trop lent » 10/10/2013 22:45:45
Je ne manquerai pas de vous communiquer le résultat. Il faut juste me donner le temps pour demander un environnement de test identique. Dès que je l'aurai je vous fait part des résultats.