Le but de l'analyse comparative d'une base de données n'est pas seulement de vérifier la capacité de la base de données, mais également le comportement d'une base de données particulière par rapport à votre application. Différents matériels fournissent des résultats différents en fonction du plan d'analyse comparative que vous définissez. Il est très important d'isoler le serveur (celui qui fait l'objet d'un benchmark) des autres éléments tels que les serveurs qui pilotent la charge ou les serveurs utilisés pour collecter et stocker les mesures de performances. Dans le cadre de l'exercice d'analyse comparative, vous devez obtenir les caractéristiques de l'application telles que a) L'application est-elle intensive en lecture ou en écriture ? ou b) quelle est la répartition lecture/écriture (par exemple 80:20) ? ou c) Quelle est la taille de l'ensemble de données ?, les données et la structure sont-elles représentatives de la base de données de production réelle, etc.
PostgreSQL est la base de données open source la plus avancée au monde. Si un client RDBMS d'entreprise souhaite migrer sa base de données vers l'open source, alors PostgreSQL serait la première option à évaluer.
Ce message couvre les éléments suivants :
- Comment comparer PostgreSQL
- Quels sont les facteurs de performance clés dans PostgreSQL
- Quels sont les leviers que vous pouvez utiliser pour augmenter les performances ?
- Quels sont les pièges à éviter en termes de performances ?
- Quelles sont les erreurs courantes commises ?
- Comment savoir si votre système fonctionne ? Quels outils pouvez-vous utiliser ?
Comment comparer PostgreSQL
L'outil standard pour évaluer PostgreSQL est pgbench. Par défaut, les tests pgbench sont basés sur TPC-B. Il implique 5 commandes SELECT, INSERT et UPDATE par transaction. Cependant, selon le comportement de votre application, vous pouvez écrire vos propres fichiers de script. Examinons la valeur par défaut et certains résultats de test orientés script. Nous allons utiliser la dernière version de PostgreSQL pour ces tests, qui est PostgreSQL 10 au moment de la rédaction. Vous pouvez l'installer à l'aide de ClusterControl ou en suivant les instructions ici :https://www.openscg.com/bigsql/package-manager/.
Spécifications de la machine
Version :RHEL 6 - 64 bits
Mémoire :4 Go
Processeurs :4
Stockage :50 G
Version PostgreSQL : 10.0
Taille de la base de données :15 G
Avant d'exécuter l'analyse comparative avec l'outil pgbench, vous devez l'initialiser sous la commande :
-bash-4.1$ ./pgbench -i -p 5432 -d postgres
NOTICE: table "pgbench_history" does not exist, skipping
NOTICE: table "pgbench_tellers" does not exist, skipping
NOTICE: table "pgbench_accounts" does not exist, skipping
NOTICE: table "pgbench_branches" does not exist, skipping
creating tables…
100000 of 100000 tuples (100%) done (elapsed 0.18 s, remaining 0.00 s)
Vacuum…
set primary keys…
done.Comme indiqué dans les messages NOTICE, il crée les tables pgbench_history, pgbench_tellers, pgbench_accounts et pgbench_branches pour exécuter les transactions à des fins d'analyse comparative.
Voici un test simple avec 10 clients :
-bash-4.1$ ./pgbench -c 10
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 100/100
latency average = 13.516 ms
tps = 739.865020 (including connections establishing)
tps = 760.775629 (excluding connections establishing)Comme vous le voyez, il fonctionnait avec 10 clients et 10 transactions par client. Il vous a donné 739 transactions/sec. Il vous a donné 739 transactions/sec. Si vous souhaitez l'exécuter pendant une durée spécifique, vous pouvez utiliser l'option "-T". En général, une course de 15 min ou 30 min est suffisante.
À partir de maintenant, nous avons parlé de la façon d'exécuter pgbench, mais pas de ce que devraient être les options. Avant de commencer l'analyse comparative, vous devez obtenir les détails appropriés de l'équipe d'application sur :
- Quel type de charge de travail ?
- Combien de sessions simultanées ?
- Quel est l'ensemble de résultats moyen des requêtes ?
- Quels sont les tps attendus (transaction par seconde) ?
Voici un exemple de charges de travail en lecture seule. Vous pouvez utiliser l'option "-S" pour n'utiliser que les SELECT qui relèvent de la lecture seule. Notez que -n permet d'ignorer l'aspirateur sur les tables.
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15741
latency average = 1916.650 ms
tps = 52.174363 (including connections establishing)
tps = 52.174913 (excluding connections establishing)
-bash-4.1$Ici, la latence est le temps de transaction écoulé moyen de chaque instruction exécutée par chaque client. Il donne 52 tps avec le matériel donné. Comme ce benchmark est pour un environnement en lecture seule, essayons de peaufiner les paramètres shared_buffers et effective_cache_size dans le fichier postgresql.conf et vérifions le nombre de tps. Ils sont aux valeurs par défaut dans le test ci-dessus, essayez d'augmenter les valeurs et vérifiez les résultats.
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15215
latency average = 1984.255 ms
tps = 68.396758 (including connections establishing)
tps = 68.397322 (excluding connections establishing)La modification des paramètres a amélioré les performances de 30 %.
pgbench exécute généralement des transactions sur ses propres tables. Si vous avez une charge de travail de 50 % de lectures et 50 % d'écritures (ou un environnement 60:40), vous pouvez créer un fichier de script avec un ensemble d'instructions pour atteindre la charge de travail attendue.
-bash-4.1$ cat /tmp/bench.sql
INSERT INTO test_bench VALUES(1,'test');
INSERT INTO test_bench VALUES(1,'test');
SELECT * FROM test_bench WHERE id=1;
SELECT * FROM test_bench WHERE id=2;
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n -f /tmp/bench.sql
transaction type: multiple scripts
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 25436
latency average = 1183.093 ms
tps = 84.524217 (including connections establishing)
tps = 84.525206 (excluding connections establishing)
SQL script 1: <builtin: select only>
- weight: 1 (targets 50.0% of total)
- 12707 transactions (50.0% of total, tps = 42.225555)
- latency average = 914.240 ms
- latency stddev = 558.013 ms
SQL script 2: /tmp/bench.sql
- weight: 1 (targets 50.0% of total)
- 12729 transactions (50.0% of total, tps = 42.298662)
- latency average = 1446.721 ms
- latency stddev = 765.933 msQuels sont les facteurs de performance clés dans PostgreSQL
Si nous considérons un environnement de production réel, il est consolidé avec différents composants au niveau de l'application, du matériel comme le processeur et la mémoire, et le système d'exploitation sous-jacent. Nous installons PostgreSQL sur le système d'exploitation pour communiquer avec d'autres composants de l'environnement de production. Chaque environnement est différent et les performances globales seront dégradées s'il n'est pas correctement configuré. Dans PostgreSQL, certaines requêtes s'exécutent plus rapidement et d'autres plus lentement, mais cela dépend de la configuration qui a été définie. L'objectif de l'optimisation des performances de la base de données est de maximiser le débit de la base de données et de minimiser les connexions pour obtenir le débit le plus élevé possible. Vous trouverez ci-dessous quelques facteurs de performance clés qui affectent la base de données :
- Charge de travail
- Ressource
- Optimisation
- Conflit
La charge de travail se compose de travaux par lots, de requêtes dynamiques pour les transactions en ligne, de requêtes d'analyse de données utilisées pour générer des rapports. La charge de travail peut être différente au cours de la période de la journée, de la semaine ou du mois et dépend des applications. L'optimisation de chaque base de données est unique. Il peut s'agir d'une configuration au niveau de la base de données ou d'une optimisation au niveau de la requête. Nous couvrirons plus d'informations sur l'optimisation dans d'autres sections de l'article. Le conflit est la condition dans laquelle deux ou plusieurs composants de la charge de travail tentent d'utiliser une seule ressource de manière conflictuelle. À mesure que la contention augmente, le débit diminue.
Que sont les conseils et les bonnes pratiques ?
Voici quelques conseils et bonnes pratiques que vous pouvez suivre pour éviter les problèmes de performances :
- Vous pouvez envisager d'exécuter des activités de maintenance telles que VACUUM et ANALYZE après une modification importante de votre base de données. Cela aide le planificateur à trouver le meilleur plan pour exécuter les requêtes.
- Recherchez tout besoin d'indexer des tables. Cela accélère l'exécution des requêtes, plutôt que d'avoir à effectuer des analyses complètes de la table.
- Pour accélérer le parcours d'un index, vous pouvez utiliser les commandes CREATE TABLE AS ou CLUSTER pour regrouper les lignes avec des valeurs de clé similaires.
- Lorsque vous constatez un problème de performances, utilisez la commande EXPLAIN pour examiner le plan sur la manière dont l'optimiseur a décidé d'exécuter votre requête.
- Vous pouvez essayer de modifier les plans en influençant l'optimiseur en modifiant les opérateurs de requête. Par exemple, si vous voyez une analyse séquentielle pour votre requête, vous pouvez désactiver l'analyse séquentielle à l'aide de "SET ENABLE_SEQSCAN TO OFF". Il n'y a aucune garantie que l'optimiseur ne choisira pas cet opérateur si vous le désactivez. L'optimiseur considère simplement que l'opérateur est beaucoup plus cher. Plus de détails ici :https://www.postgresql.org/docs/current/static/runtime-config-query.html
- Vous pouvez également essayer de modifier les paramètres de coûts tels que CPU_OPERATOR_COST, CPU_INDEX_TUPLE_COST, CPU_TUPLE_COST, RANDOM_PAGE_COST et EFFECTIVE_CACHE_SIZE pour influencer l'optimiseur. Plus de détails ici :https://www.postgresql.org/docs/current/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
- Toujours filtrer les données sur le serveur plutôt que dans l'application cliente. Cela minimisera le trafic réseau et offrira de meilleures performances.
- Pour effectuer des opérations courantes, il est toujours recommandé d'utiliser des procédures côté serveur (déclencheurs et fonctions). Les déclencheurs ou fonctions côté serveur sont analysés, planifiés et optimisés la première fois qu'ils sont utilisés, et non à chaque fois.
Quelles sont les erreurs courantes que les gens commettent ?
L'une des erreurs les plus courantes consiste à exécuter le serveur de base de données et la base de données avec des paramètres par défaut. La configuration par défaut de PostgreSQL est testée dans quelques environnements, mais toutes les applications ne trouveront pas ces valeurs optimales. Vous devez donc comprendre le comportement de votre application et, en fonction de celui-ci, définir vos paramètres de configuration. Vous pouvez utiliser l'outil pgTune pour obtenir des valeurs pour vos paramètres en fonction du matériel que vous utilisez. Vous pouvez consulter :http://pgtune.leopard.in.ua/. Cependant, gardez à l'esprit que vous devrez tester votre application avec les modifications que vous apportez, pour voir s'il y a une dégradation des performances avec les modifications.
Une autre chose à considérer serait l'indexation de la base de données. Les index aident à récupérer les données plus rapidement, mais plus d'index créent des problèmes de chargement des données. Vérifiez donc toujours s'il existe des index inutilisés dans la base de données et supprimez-les pour réduire la maintenance de ces index et améliorer le chargement des données.
