Vous n'êtes pas identifié(e).
Pages : 1
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 ?
Hors ligne
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 ?
Chaque ligne de pg_stat_activity indique bien une connexion réussie.
Est-ce que le message "too many clients already" veut dire qu'il y a 100 connexions ouvertes ?
Oui.
Comment tracer plus avant pour trouver l'origine du problème, si il y a un problème ?
La première idée qui me vient serait d'activer les paramètres log_connections et log_disconnections.
Ou sommes-nous bien aux limites de connexions ?
Je pense que vous êtes à la limite de vos connexions. Il est tout à fait possible, par exemple, que votre programme PHP réclame plusieurs dizaines de connexions et qu'au moment de l'erreur, il relâche toutes ses connexions. Du coup, quand vous rencontrez l'erreur et que vous regardez la vue pg_stat_activity, vous ne vous retrouvez qu'avec 40 connexions.
Guillaume.
Hors ligne
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.
Hors ligne
Bonjour.
Votre ram est utilisée en grande partie par le cache (10Go) car elle est disponible et votre os l'utilise pour accélérer les lectures disque. Si vous augmentez votre max_connection, il y aura juste un peu moins de données en cache mais pas de dépassement de mémoire.
Dans la commande top, vous pouvez utiliser la touche M pour afficher les processus les plus gourmands en mémoire vive.
Sinon, si vous avez bien des problèmes de non déconnexion, vous pouvez peut-être tester des pg_cancel_backup ou pg_terminate_backup sur ces processus si vous arrivez à les identifier de façon sure.
Julien.
https://rjuju.github.io/
Hors ligne
Par ailleurs, dans la colonne VIRT, on voit la «mémoire virtuelle» allouée à chaque processus. Dans cette mémoire virtuelle, on trouve évidemment la mémoire locale au processus, mais aussi la mémoire partagée, les librairies, voire des pages qui sont partagées entre divers processus: un processus qui fork à partir d'un autre, sous Unix, a la majeure partie des pages mémoire en commun avec le processus père, marquées comme copy on write: le premier à la modifier en créera une copie, mais elles sont initialement en lecture seule avec deux pointeurs.
Il faut regarder les descriptions exacte de chaque champ et avoir une bonne connaissance du modèle de mémoire unix pour comprendre vraiment la mémoire allouée avec ps.
À ma connaissance, l'outil le plus simple à interpréter, c'est pmap:
pmap -d pid donne exactement le mapping mémoire d'un processus, et un récapitulatif en dernière ligne.
Marc.
Hors ligne
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 ?
Hors ligne
Si la valeur de 4Go vous donne des résultats satisfaisants il n'y a pas de raison de le changer, cette valeur n'est pas aberrante.
Si vous souhaitez avoir plus de connexion, vous pouvez toujours augmenter le max_connections, en gardant en mémoire que chaque connexion supplémentaire prendra 10Mo de ram dans votre cas.
Utiliser uniquement le connection limit n'est peut-être pas la meilleure solution, en effet une fois toutes les connections utilisées et si elles ne se libèrent pas, vous ne pourrez plus utiliser du tout l'appli web. Je pense qu'il faudrait plutôt libérer ces connexions (manuellement ou avec un cron) à intervalle régulier ou quand la limite est atteinte en attendant la réécriture de l'appli.
Julien.
https://rjuju.github.io/
Hors ligne
Ok, merci Rjuju pour les infos et le support.
Hors ligne
Pages : 1
