PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 19/01/2015 17:10:05

unibio
Membre

Dimensionnement de serveur pour un postgres

Bonjour,

sur un serveur Virtuel, j'ai un serveur Redhat sur lequel est installé le postrgres

La base fait 237GB, les tables les plus grandes font entre 82 et 90GB

il aura assez peu de connexion simultanées au serveur (- de 10 pour le moment)

Combien de RAM dois-je allouer à ce serveur pour faire tourner postgres correctement ?

Merci

Hors ligne

#2 19/01/2015 18:27:19

gleu
Administrateur

Re : Dimensionnement de serveur pour un postgres

Difficile à dire. Si la partie active fait 4Mo, 4Mo suffira. Si elle fait 230 Go, il en faudra autant. J'ai vu des bases de cette taille fonctionner avec 4 Go de mémoire et d'autres avoir du mal avec 64 Go. Ça dépend vraiment de la partie active de la base. Est-ce qu'il y a un historique de données peu souvent utilisé ? Est-ce que les requêtes récupèrent peu d'informations ou est-ce qu'elles lisent toujours les tables complètes ? etc.


Guillaume.

Hors ligne

#3 20/01/2015 09:42:15

unibio
Membre

Re : Dimensionnement de serveur pour un postgres

Ok, mais comment mesurer la partie active ?
des requêtes croisée sur 10 jours fonctionne, mais j'ai un memory fault à partir de 15 jours.....
Merci,

Hors ligne

#4 20/01/2015 22:59:49

gleu
Administrateur

Re : Dimensionnement de serveur pour un postgres

"memory fault" est un peu court. En tout cas, ce n'est pas un message de PostgreSQL. Quel est le vrai message d'erreur ? quand intervient-il ? etc.


Guillaume.

Hors ligne

#5 22/01/2015 15:33:41

unibio
Membre

Re : Dimensionnement de serveur pour un postgres

Merci pour votre aide.

Je viens de faire plusieurs tests et je ne comprends pas l'utilisation de la mémoire du serveur.

Garce à la VM, je surveille la consommation en temps réel de la mémoire du serveur où se trouve la base.

Ma requête faite à partir du serveur QlikView me sort une erreur  SQL##f - SqlState: S1001, ErrorCode: 4, ErrorMsg: Out of memory while reading tuples
Pendant cette requête, la consommation de la mémoire du serveur de la base monte à 80%

ma requête faite à partir de mon poste depuis un pgadmin passe sans erreur, mais la consommation de la mémoire du serveur en globalement identique

La même requête faite sur le serveur directement passe, mais la consommation de la mémoire est seulement de 20%

pouvez-vous éclairer ma lanterne ?

Laurent

Hors ligne

#6 22/01/2015 16:22:31

unibio
Membre

Re : Dimensionnement de serveur pour un postgres

A noter que sur le serveur QlikView, j'utilise le pilote ODBC PostreSQL35W

Laurent

Hors ligne

#7 22/01/2015 17:25:46

unibio
Membre

Re : Dimensionnement de serveur pour un postgres

La requête lancée correctement donne les mêmes résultats quelque soit le serveur depuis le quel est est lancée.

SELECT dana_id,dana_dos_id,dana_index,dana_ana_id,dana_ana_affi,dana_ana_blcaffi_index,dana_ordre FROM dosana,dossier WHERE dana_dos_id=dos_id AND dos_datdos>='20141201' AND dos_datdos<='20141231';

plante avec out of memory sur le serveur  directement, et la consommation de la mémoire arrive à 80%

Hors ligne

#8 22/01/2015 18:32:46

SQLpro
Membre

Re : Dimensionnement de serveur pour un postgres

Le problème vient du fait que vous faites du décisionnel sur un serveur de bases de données relationnel (ROLAP). Or dans ce cas, la plupart du temps, il faudra lire séquentiellement l'intégralité des lignes des tables en jeu. Il vous faut donc une RAM au moins équivalent à la plus grande table, voire à la base entière si jointure il y a...


Le mieux serait d'avoir un véritable moteur décisionnel, car ces derniers ne stockent pas les données de la même façon, afin d'accélérer les manipulations :
1) il y a compression des données (contrairement aux bases relationnelles ou cela couterait trop cher du fait des mises à jour incessantes)
2) le NULL n'est pas stocké (contrairement aux bases relationnel ou le changement d'état d'une donnée est courante, passant du NULL à une valeur)
3) certains agrégats sont pré-calculés afin de diminuer l'accès aux données (voir la règle 4 de Codd sur le décisionnel : "la rapidité d'extraction de l'information ne doit pas être dépendante du volume des données à traiter, mais du volume des données restituées")
4) certains SGBD Décisionnel font du cache de résultat en sus de la règle 3


Ces deux dernières règles n'ayant aucun intérêt dans un SGBD Relationnel, car l'état des informations changent tout le temps du fait des multiples transactions dans la journée, ce qui n'est pas le cas du décisionnel dans lequel on "statifie" les données.


Parmi les SGBD Décisionnel il y a :
* Terradata
* Oracle (BI Suite)
* SQL Server (SSAS/SSRS)




A +

Dernière modification par SQLpro (22/01/2015 18:33:08)


Frédéric Brouard, alias SQLpro,  ARCHITECTE DE DONNÉES,  Expert langage SQL
Le site sur les SGBD relationnel et langage SQL   : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * *  Enseignant CNAM PACA, ISEN Toulon,  CESI Aix en Provence  * * * * *

Hors ligne

#9 22/01/2015 22:26:24

gleu
Administrateur

Re : Dimensionnement de serveur pour un postgres

pouvez-vous éclairer ma lanterne ?

Pas plus qu'avant. Vous parlez de serveur PostgreSQL et de serveur QlikView, puis de consommation de mémoire du serveur sans préciser lequel. Du coup, on ne sait plus de quoi vous parlez.

Quand vous avez cette erreur "out of memory", qu'y a-t-il dans les traces de PostgreSQL ? est-ce PostgreSQL qui est en manque mémoire ou QlikView ?


Guillaume.

Hors ligne

Pied de page des forums