Avant le plantage j'avais plutôt 160ko de swap utilisés.
Apparemment c'est le noyau qui a tué le processus
postmaster, j'ai vu ça ce matin quand j'ai voulu voir
ce qui s'est passé:
(j'ai gardé ce qui me semblait pertinent)
<---- extrait de la sortie de dmesg -------------
oom-killer: gfp_mask=0x1d2
Node 0 DMA per-cpu:
cpu 0 hot: low 2, high 6, batch 1
cpu 0 cold: low 0, high 2, batch 1
cpu 1 hot: low 2, high 6, batch 1
cpu 1 cold: low 0, high 2, batch 1
cpu 2 hot: low 2, high 6, batch 1
cpu 2 cold: low 0, high 2, batch 1
cpu 3 hot: low 2, high 6, batch 1
cpu 3 cold: low 0, high 2, batch 1
cpu 4 hot: low 2, high 6, batch 1
cpu 4 cold: low 0, high 2, batch 1
cpu 5 hot: low 2, high 6, batch 1
cpu 5 cold: low 0, high 2, batch 1
cpu 6 hot: low 2, high 6, batch 1
cpu 6 cold: low 0, high 2, batch 1
cpu 7 hot: low 2, high 6, batch 1
cpu 7 cold: low 0, high 2, batch 1
Node 0 Normal per-cpu:
cpu 0 hot: low 32, high 96, batch 16
cpu 0 cold: low 0, high 32, batch 16
cpu 1 hot: low 32, high 96, batch 16
cpu 1 cold: low 0, high 32, batch 16
cpu 2 hot: low 32, high 96, batch 16
cpu 2 cold: low 0, high 32, batch 16
cpu 3 hot: low 32, high 96, batch 16
cpu 3 cold: low 0, high 32, batch 16
cpu 4 hot: low 32, high 96, batch 16
cpu 4 cold: low 0, high 32, batch 16
cpu 5 hot: low 32, high 96, batch 16
cpu 5 cold: low 0, high 32, batch 16
cpu 6 hot: low 32, high 96, batch 16
cpu 6 cold: low 0, high 32, batch 16
cpu 7 hot: low 32, high 96, batch 16
cpu 7 cold: low 0, high 32, batch 16
Node 0 HighMem per-cpu: empty
J'ai regardé ce qu'était oom_killer, et je suis tombé là dessus:
http://linux-mm.org/OOM_Killer
on y dit:
«Any particular process leader may be immunized against the oom killer
if the value of it's /proc/<pid>/oomadj is set to the constant
OOM_DISABLE (currently defined as -17)»
Or le process postmaster est 9928 et je ne trouve pas de fichier
/proc/9928/oomadj
(où me goure-je?)
Comment puis je m'assurer que ce comportement ne va pas se reproduire?
Vu que le problème semble venir d'un manque de mémoire, j'ai pensé
rajouter de l'espace de swap, mais comme le disque est occupé
je vais devoir rajouter du swap sous forme d'un fichier et pas
comme partition de swap... est ce que je peux activer
un swap (partition)+un swap (fichier) sans que ça pose de problèmes
ou que les performances se dégradent?
Est ce que je peux désactiver le oom_killer? (ou est ce
une très très mauvaise idée?)
ps: je *pense* avoir trouvé la source du problème
au niveau de la base de données, mais je voudrais bien
comprendre ces histoires de oom_killer ;)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
Tanguy wrote in message <fdvog9$4hq$:
Or le process postmaster est 9928 et je ne trouve pas de fichier /proc/9928/oomadj (où me goure-je?)
Chez moi, c'est oom_adj.
est ce que je peux activer un swap (partition)+un swap (fichier) sans que ça pose de problèmes ou que les performances se dégradent?
Se dégradent... par rapport à quoi ? Toute la question est là. Si tu mets le fichier avec une priorité inférieure à la partition, alors les performances seront tout à fait identiques tant que le fichier n'est pas sollicité. Et dès qu'il commence à l'être... Eh bien avant il n'y en avait tout simplement pas.
Est ce que je peux désactiver le oom_killer? (ou est ce une très très mauvaise idée?)
Si l'OOM-killer s'est réveillé, c'est qu'un programme a bouffé toute la mémoire. Si tu t'arranges pour désactiver l'OOM-killer, ça n'empêche pas ce processus de sévir, donc il se trouve un moment où le noyau n'a plus de mémoire à attribuer : un programme voit une allocation échouer. S'il est très bien écrit, il va essayer de recompacter ses structures de données ou de libérer des caches, mais c'est rare. En pratique, il y a de bonnes chances qu'il se termine sur « Out of memory, aborting. » ou sur une segfault un peu plus loin parce qu'il n'a pas vérifié l'allocation.
De plus, désactiver l'OOM-killer, ça suppose que le noyau ne promette de la mémoire que quand il est certain de pouvoir la fournir. Ça interdit un certain nombre d'opérations tout à fait légitimes et sans risque, par exemple un très gros processus qui forke pour exécuter une petite commande shell.
Ce ne sont pas des questions faciles.
Tanguy wrote in message <fdvog9$4hq$1@s1.news.oleane.net>:
Or le process postmaster est 9928 et je ne trouve pas de fichier
/proc/9928/oomadj
(où me goure-je?)
Chez moi, c'est oom_adj.
est ce que je peux activer
un swap (partition)+un swap (fichier) sans que ça pose de problèmes
ou que les performances se dégradent?
Se dégradent... par rapport à quoi ? Toute la question est là. Si tu mets le
fichier avec une priorité inférieure à la partition, alors les performances
seront tout à fait identiques tant que le fichier n'est pas sollicité. Et
dès qu'il commence à l'être... Eh bien avant il n'y en avait tout simplement
pas.
Est ce que je peux désactiver le oom_killer? (ou est ce
une très très mauvaise idée?)
Si l'OOM-killer s'est réveillé, c'est qu'un programme a bouffé toute la
mémoire. Si tu t'arranges pour désactiver l'OOM-killer, ça n'empêche pas ce
processus de sévir, donc il se trouve un moment où le noyau n'a plus de
mémoire à attribuer : un programme voit une allocation échouer. S'il est
très bien écrit, il va essayer de recompacter ses structures de données ou
de libérer des caches, mais c'est rare. En pratique, il y a de bonnes
chances qu'il se termine sur « Out of memory, aborting. » ou sur une
segfault un peu plus loin parce qu'il n'a pas vérifié l'allocation.
De plus, désactiver l'OOM-killer, ça suppose que le noyau ne promette de la
mémoire que quand il est certain de pouvoir la fournir. Ça interdit un
certain nombre d'opérations tout à fait légitimes et sans risque, par
exemple un très gros processus qui forke pour exécuter une petite commande
shell.
Or le process postmaster est 9928 et je ne trouve pas de fichier /proc/9928/oomadj (où me goure-je?)
Chez moi, c'est oom_adj.
est ce que je peux activer un swap (partition)+un swap (fichier) sans que ça pose de problèmes ou que les performances se dégradent?
Se dégradent... par rapport à quoi ? Toute la question est là. Si tu mets le fichier avec une priorité inférieure à la partition, alors les performances seront tout à fait identiques tant que le fichier n'est pas sollicité. Et dès qu'il commence à l'être... Eh bien avant il n'y en avait tout simplement pas.
Est ce que je peux désactiver le oom_killer? (ou est ce une très très mauvaise idée?)
Si l'OOM-killer s'est réveillé, c'est qu'un programme a bouffé toute la mémoire. Si tu t'arranges pour désactiver l'OOM-killer, ça n'empêche pas ce processus de sévir, donc il se trouve un moment où le noyau n'a plus de mémoire à attribuer : un programme voit une allocation échouer. S'il est très bien écrit, il va essayer de recompacter ses structures de données ou de libérer des caches, mais c'est rare. En pratique, il y a de bonnes chances qu'il se termine sur « Out of memory, aborting. » ou sur une segfault un peu plus loin parce qu'il n'a pas vérifié l'allocation.
De plus, désactiver l'OOM-killer, ça suppose que le noyau ne promette de la mémoire que quand il est certain de pouvoir la fournir. Ça interdit un certain nombre d'opérations tout à fait légitimes et sans risque, par exemple un très gros processus qui forke pour exécuter une petite commande shell.
Ce ne sont pas des questions faciles.
Tanguy
Le 03/10/2007 12:08, Nicolas George ecrivait :
Tanguy wrote in message <fdvog9$4hq$:
Or le process postmaster est 9928 et je ne trouve pas de fichier /proc/9928/oomadj (où me goure-je?)
Chez moi, c'est oom_adj.
hmm... chez moi je n'ai rien du tout... il y a une option à spécifier, peut être? (lors de la config du noyau, ou ailleurs?)
est ce que je peux activer un swap (partition)+un swap (fichier) sans que ça pose de problèmes ou que les performances se dégradent?
Se dégradent... par rapport à quoi ? Toute la question est là.
par rapport à l'existant. C'est un serveur de base de données, il est moyennement sollicité, mais c'est mieux s'il est réactif ;) Il me semble bien que le swap sur un fichier est plus lent que le swap sur partition. Ma question était plutôt dans le sens «est ce que la différence est sensible?»
Si tu mets le
fichier avec une priorité inférieure à la partition, alors les performances seront tout à fait identiques tant que le fichier n'est pas sollicité.
je ne savais pas qu'on pouvait spécifier des priorités. Je vais regarder ça, ça répond en grande partie à ma question. (ça donnera une petite rallonge pour le swap... j'ai peut être prévu un peu court avec 2Go de swap pour 2Go de RAM)
Et
dès qu'il commence à l'être... Eh bien avant il n'y en avait tout simplement pas.
Est ce que je peux désactiver le oom_killer? (ou est ce une très très mauvaise idée?)
Si l'OOM-killer s'est réveillé, c'est qu'un programme a bouffé toute la mémoire. Si tu t'arranges pour désactiver l'OOM-killer, ça n'empêche pas ce processus de sévir, donc il se trouve un moment où le noyau n'a plus de mémoire à attribuer : un programme voit une allocation échouer.
oui oui, mais ce qui m'ennuie dans l'histoire c'est qu'il a tué le processus postmaster.
De plus, désactiver l'OOM-killer, ça suppose que le noyau ne promette de la mémoire que quand il est certain de pouvoir la fournir. Ça interdit un certain nombre d'opérations tout à fait légitimes et sans risque, par exemple un très gros processus qui forke pour exécuter une petite commande shell.
ok. Mais pour le coup je voudrais bien protéger certains processus, si c'est possible, pour m'assurer qu'ils ne soient pas tués arbitrairement. Par exemple, sur ce cas il a visiblement tué une connexion à un client qui ne s'arrête jamais, alors que le processus qui à causé le souci, et que j'aurais préféré voir disparaitre, était le compactage d'une base problématique (opération qui peut attendre que je sois revenu au boulot )
Ce ne sont pas des questions faciles.
oui je pense bien ;)
Merci pour ta réponse.
Le 03/10/2007 12:08, Nicolas George ecrivait :
Tanguy wrote in message <fdvog9$4hq$1@s1.news.oleane.net>:
Or le process postmaster est 9928 et je ne trouve pas de fichier
/proc/9928/oomadj
(où me goure-je?)
Chez moi, c'est oom_adj.
hmm... chez moi je n'ai rien du tout...
il y a une option à spécifier, peut être? (lors de la config du noyau,
ou ailleurs?)
est ce que je peux activer
un swap (partition)+un swap (fichier) sans que ça pose de problèmes
ou que les performances se dégradent?
Se dégradent... par rapport à quoi ? Toute la question est là.
par rapport à l'existant. C'est un serveur de base de données, il
est moyennement sollicité, mais c'est mieux s'il est réactif ;)
Il me semble bien que le swap sur un fichier est plus lent que
le swap sur partition. Ma question était plutôt dans le sens
«est ce que la différence est sensible?»
Si tu mets le
fichier avec une priorité inférieure à la partition, alors les performances
seront tout à fait identiques tant que le fichier n'est pas sollicité.
je ne savais pas qu'on pouvait spécifier des priorités. Je vais regarder
ça, ça répond en grande partie à ma question. (ça donnera une petite
rallonge pour le swap... j'ai peut être prévu un peu court avec
2Go de swap pour 2Go de RAM)
Et
dès qu'il commence à l'être... Eh bien avant il n'y en avait tout simplement
pas.
Est ce que je peux désactiver le oom_killer? (ou est ce
une très très mauvaise idée?)
Si l'OOM-killer s'est réveillé, c'est qu'un programme a bouffé toute la
mémoire. Si tu t'arranges pour désactiver l'OOM-killer, ça n'empêche pas ce
processus de sévir, donc il se trouve un moment où le noyau n'a plus de
mémoire à attribuer : un programme voit une allocation échouer.
oui oui, mais ce qui m'ennuie dans l'histoire c'est qu'il a tué le
processus postmaster.
De plus, désactiver l'OOM-killer, ça suppose que le noyau ne promette de la
mémoire que quand il est certain de pouvoir la fournir. Ça interdit un
certain nombre d'opérations tout à fait légitimes et sans risque, par
exemple un très gros processus qui forke pour exécuter une petite commande
shell.
ok. Mais pour le coup je voudrais bien protéger certains processus,
si c'est possible, pour m'assurer qu'ils ne soient pas tués
arbitrairement. Par exemple, sur ce cas il a visiblement tué une
connexion à un client qui ne s'arrête jamais, alors que le processus qui
à causé le souci, et que j'aurais préféré voir disparaitre, était le
compactage d'une base problématique (opération qui peut attendre
que je sois revenu au boulot )
Or le process postmaster est 9928 et je ne trouve pas de fichier /proc/9928/oomadj (où me goure-je?)
Chez moi, c'est oom_adj.
hmm... chez moi je n'ai rien du tout... il y a une option à spécifier, peut être? (lors de la config du noyau, ou ailleurs?)
est ce que je peux activer un swap (partition)+un swap (fichier) sans que ça pose de problèmes ou que les performances se dégradent?
Se dégradent... par rapport à quoi ? Toute la question est là.
par rapport à l'existant. C'est un serveur de base de données, il est moyennement sollicité, mais c'est mieux s'il est réactif ;) Il me semble bien que le swap sur un fichier est plus lent que le swap sur partition. Ma question était plutôt dans le sens «est ce que la différence est sensible?»
Si tu mets le
fichier avec une priorité inférieure à la partition, alors les performances seront tout à fait identiques tant que le fichier n'est pas sollicité.
je ne savais pas qu'on pouvait spécifier des priorités. Je vais regarder ça, ça répond en grande partie à ma question. (ça donnera une petite rallonge pour le swap... j'ai peut être prévu un peu court avec 2Go de swap pour 2Go de RAM)
Et
dès qu'il commence à l'être... Eh bien avant il n'y en avait tout simplement pas.
Est ce que je peux désactiver le oom_killer? (ou est ce une très très mauvaise idée?)
Si l'OOM-killer s'est réveillé, c'est qu'un programme a bouffé toute la mémoire. Si tu t'arranges pour désactiver l'OOM-killer, ça n'empêche pas ce processus de sévir, donc il se trouve un moment où le noyau n'a plus de mémoire à attribuer : un programme voit une allocation échouer.
oui oui, mais ce qui m'ennuie dans l'histoire c'est qu'il a tué le processus postmaster.
De plus, désactiver l'OOM-killer, ça suppose que le noyau ne promette de la mémoire que quand il est certain de pouvoir la fournir. Ça interdit un certain nombre d'opérations tout à fait légitimes et sans risque, par exemple un très gros processus qui forke pour exécuter une petite commande shell.
ok. Mais pour le coup je voudrais bien protéger certains processus, si c'est possible, pour m'assurer qu'ils ne soient pas tués arbitrairement. Par exemple, sur ce cas il a visiblement tué une connexion à un client qui ne s'arrête jamais, alors que le processus qui à causé le souci, et que j'aurais préféré voir disparaitre, était le compactage d'une base problématique (opération qui peut attendre que je sois revenu au boulot )
Ce ne sont pas des questions faciles.
oui je pense bien ;)
Merci pour ta réponse.
Nicolas George
Tanguy wrote in message <fdvv8s$8fq$:
hmm... chez moi je n'ai rien du tout... il y a une option à spécifier, peut être? (lors de la config du noyau, ou ailleurs?)
Rien de particulier. Ton noyau est peut-être trop vieux.
Par exemple, sur ce cas il a visiblement tué une connexion à un client qui ne s'arrête jamais, alors que le processus qui à causé le souci, et que j'aurais préféré voir disparaitre, était le compactage d'une base problématique (opération qui peut attendre que je sois revenu au boulot )
Je ne pense pas qu'il y ait réellement moyen de garantir ce genre de choses. Les heuristiques du noyau essaient de trouver le processus responsable, mais c'est une notion assez vague, et très difficile à évaluer. Désactiver l'OOM-killer serait probablement pire. Utiliser les options de priorité que tu as trouvées peut peut-être aider.
Tanguy wrote in message <fdvv8s$8fq$1@s1.news.oleane.net>:
hmm... chez moi je n'ai rien du tout...
il y a une option à spécifier, peut être? (lors de la config du noyau,
ou ailleurs?)
Rien de particulier. Ton noyau est peut-être trop vieux.
Par exemple, sur ce cas il a visiblement tué une
connexion à un client qui ne s'arrête jamais, alors que le processus qui
à causé le souci, et que j'aurais préféré voir disparaitre, était le
compactage d'une base problématique (opération qui peut attendre
que je sois revenu au boulot )
Je ne pense pas qu'il y ait réellement moyen de garantir ce genre de
choses. Les heuristiques du noyau essaient de trouver le processus
responsable, mais c'est une notion assez vague, et très difficile à évaluer.
Désactiver l'OOM-killer serait probablement pire. Utiliser les options de
priorité que tu as trouvées peut peut-être aider.
hmm... chez moi je n'ai rien du tout... il y a une option à spécifier, peut être? (lors de la config du noyau, ou ailleurs?)
Rien de particulier. Ton noyau est peut-être trop vieux.
Par exemple, sur ce cas il a visiblement tué une connexion à un client qui ne s'arrête jamais, alors que le processus qui à causé le souci, et que j'aurais préféré voir disparaitre, était le compactage d'une base problématique (opération qui peut attendre que je sois revenu au boulot )
Je ne pense pas qu'il y ait réellement moyen de garantir ce genre de choses. Les heuristiques du noyau essaient de trouver le processus responsable, mais c'est une notion assez vague, et très difficile à évaluer. Désactiver l'OOM-killer serait probablement pire. Utiliser les options de priorité que tu as trouvées peut peut-être aider.
Tanguy
Le 03/10/2007 13:57, Nicolas George ecrivait :
Je ne pense pas qu'il y ait réellement moyen de garantir ce genre de choses. Les heuristiques du noyau essaient de trouver le processus responsable, mais c'est une notion assez vague, et très difficile à évaluer.
en plus je ne pense pas maitriser suffisamment la gestion de la mémoire sur linux pour me lancer là dedans. Statu quo, donc; j'ai rajouté du swap en attendant.
Désactiver l'OOM-killer serait probablement pire. Utiliser les options de priorité que tu as trouvées peut peut-être aider.
oui je viens de faire ça... # swapon -s Filename Type Size Used Priority /dev/sda6 partition 2048248 11508 -1 /data/swapfile file 999992 0 -4
d'après ce que j'ai compris les zones de swap ajoutées prennent une priorité inférieure. C'est ce que je veux.
Le 03/10/2007 13:57, Nicolas George ecrivait :
Je ne pense pas qu'il y ait réellement moyen de garantir ce genre de
choses. Les heuristiques du noyau essaient de trouver le processus
responsable, mais c'est une notion assez vague, et très difficile à évaluer.
en plus je ne pense pas maitriser suffisamment la gestion de la mémoire
sur linux pour me lancer là dedans. Statu quo, donc; j'ai rajouté
du swap en attendant.
Désactiver l'OOM-killer serait probablement pire. Utiliser les options de
priorité que tu as trouvées peut peut-être aider.
oui je viens de faire ça...
# swapon -s
Filename Type Size Used Priority
/dev/sda6 partition 2048248 11508 -1
/data/swapfile file 999992 0 -4
d'après ce que j'ai compris les zones de swap ajoutées prennent une
priorité inférieure. C'est ce que je veux.
Je ne pense pas qu'il y ait réellement moyen de garantir ce genre de choses. Les heuristiques du noyau essaient de trouver le processus responsable, mais c'est une notion assez vague, et très difficile à évaluer.
en plus je ne pense pas maitriser suffisamment la gestion de la mémoire sur linux pour me lancer là dedans. Statu quo, donc; j'ai rajouté du swap en attendant.
Désactiver l'OOM-killer serait probablement pire. Utiliser les options de priorité que tu as trouvées peut peut-être aider.
oui je viens de faire ça... # swapon -s Filename Type Size Used Priority /dev/sda6 partition 2048248 11508 -1 /data/swapfile file 999992 0 -4
d'après ce que j'ai compris les zones de swap ajoutées prennent une priorité inférieure. C'est ce que je veux.
Thierry B.
--{ Tanguy a plopé ceci: }--
oui oui, mais ce qui m'ennuie dans l'histoire c'est qu'il a tué le processus postmaster.
Attention, de mémoire, c'est peut-être approximatif... Lors du
traitement de certaines requètes contenant des ORDER BY, Psql peut manger beaucoup de mémoire. Il est possible de lui demander de travailler avec des fichiers intermédiaires sur disque. Bon, d'accord, ça être bien plus lent, mais ça passe. J'ai pas la doc sous la main, mais ça doit se trouver au chapitre "tuning"...
A regarder, peut-être une piste pour traiter un cas particulier.
-- Ya pas pire vieux con, qu'un vieux con qui s'y connais, car non seulement il râle, mais en plus il a raison. --{ LC (connaisseur) in f.m.b.l }--
--{ Tanguy a plopé ceci: }--
oui oui, mais ce qui m'ennuie dans l'histoire c'est qu'il a tué le
processus postmaster.
Attention, de mémoire, c'est peut-être approximatif... Lors du
traitement de certaines requètes contenant des ORDER BY, Psql
peut manger beaucoup de mémoire. Il est possible de lui demander
de travailler avec des fichiers intermédiaires sur disque. Bon,
d'accord, ça être bien plus lent, mais ça passe. J'ai pas la doc
sous la main, mais ça doit se trouver au chapitre "tuning"...
A regarder, peut-être une piste pour traiter un cas particulier.
--
Ya pas pire vieux con, qu'un vieux con qui s'y connais, car non
seulement il râle, mais en plus il a raison.
--{ LC (connaisseur) in f.m.b.l }--
oui oui, mais ce qui m'ennuie dans l'histoire c'est qu'il a tué le processus postmaster.
Attention, de mémoire, c'est peut-être approximatif... Lors du
traitement de certaines requètes contenant des ORDER BY, Psql peut manger beaucoup de mémoire. Il est possible de lui demander de travailler avec des fichiers intermédiaires sur disque. Bon, d'accord, ça être bien plus lent, mais ça passe. J'ai pas la doc sous la main, mais ça doit se trouver au chapitre "tuning"...
A regarder, peut-être une piste pour traiter un cas particulier.
-- Ya pas pire vieux con, qu'un vieux con qui s'y connais, car non seulement il râle, mais en plus il a raison. --{ LC (connaisseur) in f.m.b.l }--
Tanguy
Le 03/10/2007 15:43, Thierry B. ecrivait :
--{ Tanguy a plopé ceci: }--
oui oui, mais ce qui m'ennuie dans l'histoire c'est qu'il a tué le processus postmaster.
Attention, de mémoire, c'est peut-être approximatif... Lors du
traitement de certaines requètes contenant des ORDER BY, Psql peut manger beaucoup de mémoire. Il est possible de lui demander de travailler avec des fichiers intermédiaires sur disque. Bon, d'accord, ça être bien plus lent, mais ça passe. J'ai pas la doc sous la main, mais ça doit se trouver au chapitre "tuning"...
A regarder, peut-être une piste pour traiter un cas particulier.
En fait je ne pense pas qu'un tel traitement (requete couteuse) soit en cause. C'est arrivé la nuit, normalement il n'y a que très peu d'accès à ce moment là. Je pense avoir trouvé ce qui n'allait pas, sans pouvoir en être sûr malheureusement; je pense que le compactage que je fais toutes les nuits a coincé à un moment donné (Le coupable était une base de test que j'avais créée. C'est rentré dans l'ordre quand je l'ai supprimée.)
Ceci dit je garde ta remarque sous le coude, ça peut servir... ;)
Le 03/10/2007 15:43, Thierry B. ecrivait :
--{ Tanguy a plopé ceci: }--
oui oui, mais ce qui m'ennuie dans l'histoire c'est qu'il a tué le
processus postmaster.
Attention, de mémoire, c'est peut-être approximatif... Lors du
traitement de certaines requètes contenant des ORDER BY, Psql
peut manger beaucoup de mémoire. Il est possible de lui demander
de travailler avec des fichiers intermédiaires sur disque. Bon,
d'accord, ça être bien plus lent, mais ça passe. J'ai pas la doc
sous la main, mais ça doit se trouver au chapitre "tuning"...
A regarder, peut-être une piste pour traiter un cas particulier.
En fait je ne pense pas qu'un tel traitement (requete couteuse) soit en
cause.
C'est arrivé la nuit, normalement il n'y a que très peu d'accès à ce
moment là. Je pense avoir trouvé ce qui n'allait pas, sans pouvoir en
être sûr malheureusement; je pense que le compactage que je fais toutes
les nuits a coincé à un moment donné (Le coupable était une base de test
que j'avais créée. C'est rentré dans l'ordre quand je l'ai supprimée.)
Ceci dit je garde ta remarque sous le coude, ça peut servir... ;)
oui oui, mais ce qui m'ennuie dans l'histoire c'est qu'il a tué le processus postmaster.
Attention, de mémoire, c'est peut-être approximatif... Lors du
traitement de certaines requètes contenant des ORDER BY, Psql peut manger beaucoup de mémoire. Il est possible de lui demander de travailler avec des fichiers intermédiaires sur disque. Bon, d'accord, ça être bien plus lent, mais ça passe. J'ai pas la doc sous la main, mais ça doit se trouver au chapitre "tuning"...
A regarder, peut-être une piste pour traiter un cas particulier.
En fait je ne pense pas qu'un tel traitement (requete couteuse) soit en cause. C'est arrivé la nuit, normalement il n'y a que très peu d'accès à ce moment là. Je pense avoir trouvé ce qui n'allait pas, sans pouvoir en être sûr malheureusement; je pense que le compactage que je fais toutes les nuits a coincé à un moment donné (Le coupable était une base de test que j'avais créée. C'est rentré dans l'ordre quand je l'ai supprimée.)
Ceci dit je garde ta remarque sous le coude, ça peut servir... ;)
