Si je lis correctement la sortie de votre top, elle n'est pas prise à un moment où vous manquez de mémoire.
L'erreur réelle semble correcte - elle ne demande pas une énorme quantité de mémoire, donc il est probable que la machine manquait de mémoire à ce moment-là.
Examinons rapidement vos paramètres :
max_connections = 1000 # (change requires restart)
work_mem = 40MB # min 64kB
Donc - vous êtes d'avis que vous pouvez prendre en charge 1000 requêtes simultanées chacune en utilisant, disons, 10 + 40 Mo (certains peuvent utiliser des multiples de 40 Mo, mais soyons raisonnables). Donc - cela me suggère que votre machine a> 500 cœurs et disons 100 Go de RAM. Ce n'est pas le cas.
Donc - prenez votre nombre de cœurs et doublez-le - c'est une valeur raisonnable pour le nombre maximum de connexions. Cela vous permettra d'effectuer une requête sur chaque cœur pendant qu'une autre attend les E/S. Ensuite, placez un pooler de connexion devant la base de données si vous en avez besoin (pgbouncer / pooling de connexion de Java).
Ensuite, vous pourriez même envisager d'augmenter work_mem si nécessaire.
Oh - parfaitement raisonnable de fonctionner sans swap activé. Une fois que vous commencez à échanger, vous êtes de toute façon dans un monde de douleur en ce qui concerne l'utilisation de la base de données.
Modifier :développer work_mem vs partagé
En cas de doute, reportez-vous toujours au documentation .
Les shared_buffers La valeur est, comme son nom l'indique, partagée entre les backends. Le work_mem n'est pas seulement par backend, c'est en fait par tri. Ainsi, une requête peut utiliser trois ou quatre fois ce montant si elle effectue des tris sur trois sous-requêtes.
