Vous n'êtes pas identifié(e).
Bonjour Messieurs,
Merci pour les réponses.
Pourriez-vous me répondre sur le paramètrage mémoire ?
PostgreSQL est configuré pour 4Go alors que la machine en a 12.
Faut-il revoir ce paramètrage ? ou juste augmenter le max_connexions ?
Autre point, est-ce que je peux limiter le nombre de connexions simultanées d'un Utilisateur (Alter User et --connection-limit) pour éviter que l'appli Php ne monopolise toutes les connexions et que les autres applis ne soient pas perturbées ?
Kenrio,
Je crois qu'il y a 10 machines Centrion pour 500 machines surveillées, mais je crois que tout n'est pas déployé encore. J'attend des retours d'infos sur la possibilé d'avoir notre propre Centrion pour surveiller les machines PostgreSQL.
Je ne connais pas tail_n_mail, je vais regarder cela de plus prés.
Merci.
Rebonjour,
Guillaume, oui, ce qui nous embête c'est qu'il a le droit de faire ce DELETE.
Kenrio, sur conseil de l'équipe en charge de Nagios (Centrion) il faut limiter le nombre de demande car énormément de machines supervisées. Et oui c'est bien de pouvoir logguer toutes les requêtes sauf celles qui reviennent toujours.
Guillaume,
Pas de remontée d'infos sur des lenteurs.
Le but de la surveillance et de pouvoir identifier, par exemple, une personne qui ferait un delete violent dans la base.
Nous avons mis en place des rôles de connexions et des rôles de groupes pour gérer un maximum d'utilisateurs (interfaçes logiciels), mais certains ont tout de même accès à PgAdmin ou autres.
A l'inverse, ne peut on pas écarter les utilisateurs logiciels qui font toujours les mêmes requêtes ?
Je prend note des autres points à surveiller.
Merci.
Bonjour à tous,
Merci pour le retour d'infos.
Sur un serveur en production, nous avons actuellement le paramètrage suivant :
log_filename = '%d.log'
log_truncate_on_rotation = on
log_rotation_age = 1d
log_min_duration_statement = 300
log_statement = 'all'
Cela veut-il dire que toutes les requêtes sont tracées + la durée pour celles qui s'exécutent en plus de 300 millisecondes ?
Nous avons 1 fichier trace par jour avec rotation sur un mois. La taille des fichiers varie entre 1 et 4 Go.
Cela est-il fortement pénalisant ?
Nous souhaitons tracer toutes les requêtes pour surveiller l'activité de certains utilisateurs. Y a t'il un autre moyen ?
Mais également pour pouvoir analyser avec pgfouine et peut être mettre en évidence certaines choses. Qu'en pensez-vous ?
Nous voulons utiliser Munin pour :
- La volumétrie
- Le nombre d'Insert, Update, Delete
- Les transactions validées, annulées
- Le hit ratio
Nous voulons utiliser Nagios pour :
- Alerter si la base ne répond pas
- Surveiller le nombre de connexions
- Surveiller les locks
Est-ce une bonne approche ? manque t'il certaines choses ?
Je pose beaucoup de questions mais je suis un tout petit DBA et j'ai grand besoin de votre aide pour progresser.
Bonjour,
Je travaille sur des bases en 8.4 et 9.0 sous CentOs 5.
Nous souhaitons mettre en place une surveillance de nos serveurs :
Nagios pour les alertes,
Munin pour les perfs,
PgFouine pour les requêtes.
J'aimerai avoir votre avis sur l'impact de nombreux changements de paramètres dans le fichier PostgreSQL.conf
# Journalisation des messages du Serveur
log_destination = 'stderr'
# Capture et redirection des traces
logging_collector = ON
# Destination des traces
log_directory = '/home/postgres/PG_LOG'
# Fichiers traces
log_filename = '%u-%H.log'
log_rotation_age = 1h
log_rotation_size = 0
log_truncate_on_rotation = ON
Avoir un fichier de trace à l'heure, sur un cycle d'une semaine, avec écrasement.
Ceci afin de pouvoir analyser plus facilement les traces et éviter d'avoir des fichiers trop gros.
# Durée de toutes les instructions
log_min_duration_statement = 0
# Tracer les Checkpoints
log_checkpoints = ON
# Tracer les Connexions
log_connections = ON
# Tracer les Déconnexions
log_disconnections = ON
# Formattage des lignes de traces
log_line_prefix = '%t [%p]: [%l-1] user=%u %h %s '
Pour pouvoir exploiter les traces avec PgFouine
# Tracer les attentes de verrous
log_lock_waits = ON
# Tracer les instructions SQL
log_statement = 'all'
# Tracer l'utilisation des fichiers temporaires
log_temp_files = 0
# Tracer les appels aux Fonctions PL
track_functions = pl
Tout ces changements peuvent ils avoir des impacts importants sur les performances ?
La taille des fichiers traces va t'elle explosé ?
Ce paramètrage est-il en adéquation avec la surveillance ?
Bonjour,
Je me permet de réutiliser ce post pour essayer de résoudre le problème (tout du moins temporairement).
Nous avons identifié des problèmes de connexions persistantes sans déconnexions sur une application PHP (Apache) utilisée par une petite centaine de personnes.
Dans l'attente du redéveloppement de certaines parties de l'application (pas avant mai), nous souhaiterions modifier le MAX_CONNECTIONS qui est actuellement à 100.
Aprés avoir lu plusieurs posts, j'essaye de vous fournir un minimum d'informations utiles :
Postgres a était configuré sur la base de 4 Go de RAM, alors que la machine dispose de 12 Go.
Les autres paramètres du fichier Postgresql.conf sont :
shared_buffers = 1024MB
work_mem = 10MB
maintenance_work_mem = 512MB
effective_cache_size = 2730MB
autovacuum_max_workers = 3
Le fichier Sysctl.conf contient :
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
En faisant un Top, j'obtiens les informations suivantes :
top - 14:54:10 up 102 days, 48 min, 4 users, load average: 2.86, 2.31, 1.35
Tasks: 275 total, 3 running, 272 sleeping, 0 stopped, 0 zombie
Cpu(s): 32.5%us, 0.1%sy, 0.0%ni, 67.2%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 12296208k total, 11663764k used, 632444k free, 182456k buffers
Swap: 5242872k total, 152k used, 5242720k free, 10434344k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19566 postgres 25 0 1139m 118m 104m R 99.8 1.0 4:00.91 postmaster
19620 postgres 17 0 1138m 113m 103m S 96.2 0.9 3:02.81 postmaster
19539 postgres 17 0 1140m 141m 126m R 59.9 1.2 3:24.29 postmaster
22159 daemon 15 0 136m 9176 3488 S 1.0 0.1 0:00.15 httpd
19536 daemon 15 0 138m 10m 3564 S 0.7 0.1 0:05.31 httpd
19560 daemon 15 0 138m 11m 3576 S 0.7 0.1 0:06.24 httpd
22043 daemon 15 0 138m 10m 3488 S 0.7 0.1 0:00.39 httpd
19611 daemon 15 0 138m 11m 3568 S 0.3 0.1 0:04.30 httpd
20343 postgres 15 0 1129m 1.0g 1.0g S 0.3 8.8 9:53.52 postmaster
En voyant le résultat du Top, je dirai que toute la RAM est utilisée ! par conséquent, augmenter le nombre de connexions n'est-il pas dangereux ?
D'aprés les paramètres configurés, est-il normal que toute la RAM soit utilisée ?
Merci pour votre support.
Merci encore Marc pour toute l'aide que vous m'apportez.
Merci Marc.
Puis-je abuser en vous demandant si le fait de modifier le paramètre lc_messages de 'fr_FR.UTF8' vers 'en_US.UTF8' peut avoir un impact autre que le fait de retourner les messages en anglais plutôt qu'en français ?
Bonjour Marc,
Je voulais faire du CSV car dans la doc postgresql on parle de mettre les logs dans une table.
J'imagine que c'est pour faciliter l'exploitation ??
Pouvez-vous jeter un oeil aux autres questions ci-dessus ?
D'avance merci.
Bonjour Cédric,
Je suis sur une base de test, donc effectivement les fichiers étaient vides au moment de ma requête.
Mais si je créé de l'activité, ils se remplissent, pas de souci de ce côté.
J'ai modifié mon paramétrage pour rediriger vers stderr au lieu de csvlog et là tout fonctionne.
Est-il préférable de rester en stderr ou le csvlog apporte t'il un plus ? et est-ce qu'il fonctionne réellement avec PgFouine ?
Ma stratégie d'un fichier par heure et par jour de la semaine est-elle bonne ?
Le fait de modifier le paramètre lc_messages de 'fr_FR.UTF8' vers 'en_US.UTF8' peut-il avoir un impact sur une base de production ?
Est-ce que j'ai maintenant suffisamment d'infos pour analyser (connexions, performances, requêtes lentes, ...) ?
Le résultat de la requête demandé :
geo=# select name,setting,context,source from pg_settings where source != 'default' order by 1;
name | setting | context | source
--------------------------------+--------------------------------------------------+------------+----------------------
application_name | psql | user | client
archive_command | (disabled) | sighup | configuration file
archive_mode | off | postmaster | configuration file
autovacuum_naptime | 60 | sighup | configuration file
checkpoint_completion_target | 0.9 | sighup | configuration file
checkpoint_segments | 32 | sighup | configuration file
config_file | /home/postgres/PG_DATA/postgresql.conf | postmaster | override
data_directory | /home/postgres/PG_DATA | postmaster | override
DateStyle | ISO, DMY | user | configuration file
default_tablespace | | user | configuration file
default_text_search_config | pg_catalog.french | user | configuration file
effective_cache_size | 349440 | user | configuration file
hba_file | /home/postgres/PG_DATA/pg_hba.conf | postmaster | override
ident_file | /home/postgres/PG_DATA/pg_ident.conf | postmaster | override
lc_collate | fr_FR.UTF8 | internal | override
lc_ctype | fr_FR.UTF8 | internal | override
lc_messages | en_US.UTF8 | superuser | configuration file
lc_monetary | fr_FR.UTF8 | user | configuration file
lc_numeric | fr_FR.UTF8 | user | configuration file
lc_time | fr_FR.UTF8 | user | configuration file
listen_addresses | * | postmaster | configuration file
log_autovacuum_min_duration | 300 | sighup | configuration file
log_connections | on | backend | configuration file
log_destination | stderr | sighup | configuration file
log_directory | /home/postgres/PG_LOG | sighup | configuration file
log_disconnections | on | backend | configuration file
log_filename | %u-%H.log | sighup | configuration file
logging_collector | on | postmaster | configuration file
log_line_prefix | %t [%p]: [%l-1] user=%u %h %s | sighup | configuration file
log_min_duration_statement | 0 | superuser | configuration file
log_rotation_age | 60 | sighup | configuration file
log_timezone | Europe/Paris | sighup | command line
log_truncate_on_rotation | on | sighup | configuration file
maintenance_work_mem | 524288 | user | configuration file
max_connections | 100 | postmaster | configuration file
max_stack_depth | 2048 | superuser | environment variable
random_page_cost | 2 | user | configuration file
search_path | geo, sas, igeo_pack, cgu_pack, j_geo, jrn_center | user | user
server_encoding | UTF8 | internal | override
shared_buffers | 131072 | postmaster | configuration file
superuser_reserved_connections | 6 | postmaster | configuration file
temp_tablespaces | | user | configuration file
TimeZone | Europe/Paris | user | command line
timezone_abbreviations | Default | user | command line
transaction_isolation | read committed | user | override
transaction_read_only | off | user | override
wal_buffers | 2048 | postmaster | configuration file
wal_level | minimal | postmaster | configuration file
work_mem | 10240 | user | configuration file
(49 rows)
Merci pour votre aide.
Bonjour,
Je travaille avec une 9.0 sur CentOS 5.
Suite à des problèmes de connexions (too many clients already) et à des fichiers de Log inexploitable (2 Go, tout est tracé, un fichier par jour, avec rotation du 01 au 31), je retravaille la stratégie de tracage, en prenant en compte le fait de pouvoir exploiter les fichiers avec PGFOUINE.
J'ai paramétré mon postgresql.conf avec :
log_destination = 'csvlog'
logging_collector = on
log_directory = '/home/postgres/PG_LOG'
log_filename = '%u-%H'
log_truncate_on_rotation = on
log_rotation_age = 1h
log_min_duration_statement = 0
log_connections = on
log_disconnections = on
log_line_prefix = '%t [%p]: [%l-1] ' # préconisé pour PGFOUINE
lc_messages = 'en_US.UTF8' # préconisé pour PGFOUINE
J'obtiens maintenant 2 fichiers par heure, par exemple :
-rw------- 1 postgres postgres 0 fév 6 10:00 1-10
-rw------- 1 postgres postgres 0 fév 6 10:00 1-10.csv
-rw------- 1 postgres postgres 0 fév 6 11:00 1-11
-rw------- 1 postgres postgres 0 fév 6 11:00 1-11.csv
Pour quelle raison, je ne trouve pas ?
J'ai vu que pour PGFOUINE, il fallait modifier le fichier CsvlogLogReader.class.php pour gérer une version 9. J'ai donc remplacé la ligne indiqué (if((count($csvLine) == 22) || (count($csvLine) == 23)) {).
J'exécute la commande : pgfouine.php -file /home/postgres/PG_LOG/1-11.csv -format text -logtype csvlog > pierre.txt
et je reçois :
pgFouine did not find any valid PostgreSQL log line in your log file:
* check that PostgreSQL uses an english locale for logging (lc_messages in your postgresql.conf),
* check that you use the -logtype option (syslog, stderr) according to your log file,
* if you use syslog and log_line_prefix, check that your log_line_prefix has a trailing space,
* if you use stderr, check that your log_line_prefix is of the form '%t [%p]: [%l-1] '.
If you think your log file and your options are correct, please contact the author (gsmet on #postgresql@freenode or guillaume-pg at smet dot org).
Quelqu'un peut-il m'aider ?
Bonjour,
Je travaille sur des bases en 8.4 et 9.0 sous CentOs 5.
Il semble que nous ayons un problème de connexions.
Detail dans le fichier de log :
127.0.0.1 22631 2012-02-01 09:33:49 CET idle 1 LOG: statement: begin;
127.0.0.1 22631 2012-02-01 09:33:49 CET idle in transaction 2 LOG: statement: select igeo_pack.seculigne('80227',1) as data
127.0.0.1 22631 2012-02-01 09:33:49 CET idle in transaction 3 LOG: statement: fetch all in "<unnamed portal 1>"
127.0.0.1 22631 2012-02-01 09:33:49 CET idle in transaction 4 LOG: statement: commit;
127.0.0.1 22632 2012-02-01 09:33:49 CET startup 1 FATAL: sorry, too many clients already
Nous avons une interface en PHP qui fait beaucoup d'appel à des fonctions Pl/PgSql.
Les 4 premières lignes de log se répettent trés souvent (avec différentes fonctions).
$sQuery = "select igeo_pack.seclig('".$sUserid."',".$sSoft.") as data ";
$aRes = $this->oDbLink->db_ref_cursor($sQuery);
public function db_ref_cursor($_query) {
$_query_bis = "begin;";
$result1 = @pg_query($_query_bis);
$result1 = @pg_query($_query);
list($cname) = @pg_fetch_array($result1);
$_query_bis = "fetch all in \"".$cname."\"";
$result1 = @pg_query($_query_bis);
$arr1 = @pg_fetch_all($result1);
$_query_bis = "commit;";
$result1 = @pg_query($_query_bis);
@pg_free_result($result1);
$aRetTab = $arr1;
return $aRetTab;
Ces fonctions font des requêtes qui retournent des ref_cursor.
CREATE OR REPLACE FUNCTION IGEO_PACK.SecLig(VARCHAR,NUMERIC) RETURNS REFCURSOR AS '
DECLARE
nAllLigne INTEGER;
CurLigne CURSOR FOR
SELECT DISTINCT S.id_ligne
FROM GEO.Securite S
WHERE S.id_perso=$1
AND S.id_soft=$2
ORDER BY S.id_ligne;
RecLigne RECORD;
CurActLigne REFCURSOR;
BEGIN
nAllLigne:=0;
OPEN CurLigne;
FETCH CurLigne INTO RecLigne;
IF FOUND THEN
IF RecLigne.id_ligne = ''****'' THEN
nAllLigne:=1;
END IF;
CLOSE CurLigne;
IF nAllLigne = 1 THEN
OPEN CurActLigne FOR
SELECT DISTINCT L.id_ligne,L.lib_ligne
FROM GEO.VUE_ACTIVITE_GEO L
ORDER BY L.lib_ligne;
ELSE
OPEN CurActLigne FOR
SELECT DISTINCT L.id_ligne,L.lib_ligne
FROM GEO.VUE_ACTIVITE_GEO L
WHERE L.id_ligne IN (
SELECT DISTINCT id_ligne
FROM GEO.Securite
WHERE id_perso=$1 AND id_soft=$2)
ORDER BY L.lib_ligne;
END IF;
ELSE
CLOSE CurLigne;
END IF;
RETURN CurActLigne;
END;
' LANGUAGE 'plpgsql';
Le paramètre MAX_CONNECTIONS vaut 100 dans le fichier postgresql.conf.
En consultant la vue pg_stat_activity, il y a rarement plus de 30 ou 40 lignes. Est-ce que cela correspond bien au nombre de connexions ?
Est-ce que le message "too many clients already" veut dire qu'il y a 100 connexions ouvertes ?
Comment tracer plus avant pour trouver l'origine du problème, si il y a un problème ?
Ou sommes-nous bien aux limites de connexions ?
Ok, merci Guillaume.
Bonjour Guillaume,
Merci pour le conseil.
J'ai mis en place Munin avec des plugins PostgreSQL sans trop de difficulté sur mes machines de test.
J'ai activé la récolte toutes les minutes.
J'ai ajouté un envoi de mail sur le plugins "Connexions", dans le cas où il y a plus de 5 connexions.
Je reçois bien :
dev-local :: dev-local :: PostgreSQL connections to mabase
WARNINGs: Idle is 15.00 (outside range [:5]).
MAIS, de temps en temps je reçois le message ci dessous, alors que mon nombre de connexions est toujours identique :
dev-local :: dev-local :: PostgreSQL connections to mabase
OKs: Idle is 0.00.
Est-ce que j'ai râté quelque chose ?
Bonjour à tous,
Je travaille sur des bases en 8.4 et 9.0 sous CentOs.
En consultant un fichier de log, je suis tombé sur cette ligne :
127.0.0.1 20682 2012-01-27 14:57:52 EAT startup 1 FATAL: connection limit exceeded for non-superusers
Je voudrai donc surveiller le nombre de connexions.
J'ai trouvé la vue pg_stat_activity, qui me donne les connexions à un instant T.
Y-a-t'il une autre infos qui pourrait me donner le nombre max de connexions dans la journée ?
Comment puis-je faire pour récolter cette infos plusieurs fois dans la journée ?
Merci pour votre aide.
Comment savoir si la réindexation s'est intérrompue ou pas ?
J'ai reçu un code retour différent de 0 dans mon script.
Bonjour Marc,
C'est bien la commande que j'ai utililsé pour trouver l'objet mais qui ne me retourne rien.
Y-a-t'il un moyen de gérer ce problème de reindexdb ?
Faire une réindexation plus ciblée ?
ou autre ?
Bonjour,
Je travaille sur des bases 8 et 9 sous CentOS.
J'ai un script de maintenance qui tourne le dimanche avec la commande : reindexdb -a
Cela fait 2 dimanches de suite que le script s'arrête sur erreur.
En consultant les logs, j'ai trouvé :
[local] 1641 2012-01-22 09:58:11 EAT REINDEX 2 ERROR: could not open relation with OID 2183444
[local] 1641 2012-01-22 09:58:11 EAT REINDEX 3 STATEMENT: REINDEX DATABASE toto;
Je précise que le dimanche précédent, l'OID était différent.
Comment remonter au nom de l'objet à partir de son OID ?
Est-ce que cela peut être lié au fait qu'il y a de l'activité le dimanche ?
Certains traitement créent et dropent des tables temporaires à la volée, est-ce lié ?
Comment gérer ce problème ?
Désolé Marc,
Je viens de trouver le problème, les simples quotes sur le ALTER ROLE.
Merci pour votre aide et bon week-end.
Marc,
Aprés Arrêt/Redémarrage complet, la commande SHOW SEARCH_PATH me retourne bien mes différents schémas ('monschema,tonschema,sonschema').
La commande : select * from pg_db_role_setting; me retourne : "{"search_path=\"monschema,tonschema,sonschema\""}"
Bonjour Marc,
Effectivement, il y avait un ALTER USER postgres SET SEARCH_PATH='public';
J'ai effectué un : alter role postgres set search_path='monschema,tonschema,sonschema';
Je relance ma requête : SELECT * FROM matable, j'ai toujours le message : ERROR: relation "matable" does not exist
La commande SHOW SEARCH_PATH me retourne bien mes différents schémas.
J'ai fait un pg_ctl reload, j'ai arrête/redémarré le Serveur, sans succès.
Comment vérifier qu'il y a un ALTER DATABSE ? ou y-a-t'il un autre problème ?
Bonjour,
Je travaille en version 9.0.4 sous Cent-OS.
Je fais un SELECT * FROM matable, cette table appartient au Schéma monschema.
J'obitens un message d'erreur : ERROR: relation "matable" does not exist
Si je fais un SELECT * FROM monschema.matable, cela fonctionne.
J'ai regardé dans mon postgresql.conf, la variable SEARCH_PATH, j'ai bien : search_path = 'monschema,tonschema,sonschema' # Schema names
J'ai arrêté/redémarré le Serveur.
Je me connecte en psql, je fais un SHOW SEARCH_PATH, j'obtiens : # show search_path;
search_path
-------------
public
(1 row)
Quelqu'un à t'il une idée ?
Par avance merci.
Ok.
J'ai lancé le make install.
Le Man check_postgres fonctionne.
J'ai fait un : check_postgres.pl --action=connection --db=geo
qui me répond : POSTGRES_CONNECTION OK: DB "geo" version 9.0.4 | time=0.08s
Cela fonctionne.
Merci et bonne journée.
Bonjour Marc,
Lorsque je suis connecté (OS) en user postgres, j'arrive bien à lancer psql --help et initdb --help.
Peut être un problème lié aux autorisations dans le pg_hba.conf ?
Merci pour votre aide.
