Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
comme vous avez pu le constater, nous testons Postgre en vue de remplacer Oracle.
Dans un premier temps, je devais faire deux versions de l'application, une pour Windows, l'autre pour Linux. Pour l'instant, nous nous occupons que de Windows.
Je dois proposer une configuration matérielle qui permette de tester postgre et non le matériel (c'est à dire une configuration rapide, efficace, ... ).
dans l'pplication, j'ai 4 tablespaces : un pour les tables, un autre pour les indexs, un troisième pour les tables paramètres. Si il y a quelque chose dans le 4éme , c'est que j'ai raté une option sur une table ou un index.
2 questions sur le matériel donc :
- multi-coeur : je n'ai pas du tout pensé à ce paramètre dans l'application. Je n'ai aucune option concernant la parallélisation (j'ai vu passer des infos dans la doc mais sans approfondir). Est-ce important ?
- plusieurs disques. Je pensai demander au moins 3 disques C: pour windows, les programmes et les tables paramètres; un disque rapide pour les tables et un autre pour les indexs. C'est bon? Que pensez-vous des disques SSD ?
Bref, je suis preneur de tout conseil concernant la configuration matérielle !
D'avance merci
Jean
Hors ligne
- multi-coeur : je n'ai pas du tout pensé à ce paramètre dans l'application. Je n'ai aucune option concernant la parallélisation (j'ai vu passer des infos dans la doc mais sans approfondir). Est-ce important ?
Tout dépend du nombre d'utilisateurs qui vont exécuter des requêtes simultanément. D'expérience, je dirais qu'il vaut mieux avoir plein de CPU que des CPU rapides.
- plusieurs disques. Je pensai demander au moins 3 disques C: pour windows, les programmes et les tables paramètres; un disque rapide pour les tables et un autre pour les indexs. C'est bon? Que pensez-vous des disques SSD ?
Avoir les journaux de transactions sur leur propre disque est généralement une bonne idée, à la fois pour s'assurer des performances et de la disponibilité du service. Sinon, les trois autres disques, très bien. Si vous pouvez avoir du SSD pour les index, ce serait parfait (moins intéressant pour les tables mais si vous avez le budget, il ne faut pas s'en priver (je parle de budget car je ne parle pas de SSD grand public, mais de SSD entreprises, donc très chers)).
Guillaume.
Hors ligne
Si vous mettez différents tablespaces sur différents disques (en particulier s'il y a du HDD et du SDD mixés), bencher les différents disques en lecture séquentielle/aléatoire (IOPS), et adapter en conséquence les options seq_page_cost/random_page_cost des fifférents tablespace, faute de quoi l'optimiseur peut choisir des plans d'exécution non-optimaux.
Dernière modification par herve.lefebvre (10/12/2018 14:17:39)
Hors ligne
Pages : 1
