Vous n'êtes pas identifié(e).
Pages : 1
Retour sur Azure database for Postgresql Flexible Server en v13.
C'est la déception, sur un 4 core / 16 MB mémoire, j'ai des grosses pertes de performances par rapport à un azure postgresql single en v 11.
Je m'attendais à un peu mieux, mais ce n'est pas le cas.
Sur ma requête benchmark, elle s'exécute en moins de 20 min sur la v11 et en plus d'une heure sur la v13.
Le random_page_cost est différent entre les 2, et cela me donne d'un côté un bitmap scan sur la v13 contre in index scan sur la v11. En mettant le random_page_cost = 1 (il est à 1.1 sur la v11) sur la v13, je change le bitmap par le même index scan.
L'explain analyze sur le v13 tourne en presque 3H, contre 20 min pour la v11 sur un volume très similaire (une grosse table de 200 millions de ligne, puis des plus petites).
L'explain analyze sur le v13 indique 1H13 passé sur un materialize (le même tourne en 2m30 sur la v11) puis un merge join de 1H (contre 17 min sur v11).
Côté attente, j'ai du DAtaFileRead sur les premières minutes (mais à peine 5 min) puis après plus rien n'est affiché dans le wait sur pg_stat_activity.
Je vais continuer à comparer les settings entre les 2.
C'est un peu la douche froide.
J'ai oublié de parler rapidement des points suivants :
- Single Server est l'ancien modèle, la version de postgresql indique compilé sous Visual C++ (je présume windows derrière). C'est limité à l'édition 11 et débute à 9.6. Le SLA de 99,99% est géré par 3 containeurs propriétaires (sans plus de détail). Les fichiers sont sur blob storage.
- Flexible Server, le nouveau modèle, tourne dans un containeur sur une VM linux permettant de stopper le service (Ubuntu 18.04 sur mon server), dispose de l'édition 11 à 13. Le SLA est géré par remonté d'une VM Linux avec le containeur et remappage des fichiers. Le flexible server indique pgBouncer. MS recommande ce modèle au lieu et place du Single Server.
- en tiers Basic, on reste en Basic, pas moyen de passer aux tiers supérieurs. Donc, éviter le tiers Basic en production (ou environnement similaire).
- les backups autogérés par Azure permettent du PITR. Je suppose que c'est derrière quelque chose de similaire à un pgbackurest ou un pgbackup + fichiers wal mais la doc ne détaille pas. Il est indiqué 2 backups différentiels / jour, un backup full / semaine et des backups de transaction toutes les 5 min. Attention, l'espace pris par les backups est offert à hauteur de la taille de stockage alloué, après c'est payant. Exemple, le stockage est de 250 Go, les 250 premiers Go de backups sont inclus. La rétention défaut est 7 jours et on peut étendre à 35 jours (ou plus avec azure backups).
Pour en revenir au query_store, j'ai l'extension pg_stat_statement visible sur mon serveur qui a le query store actif (mais pas le pg_stat_statement). Je suppose que le query_store se base dessus. Mais la documentation ne détaille rien (sauf que c'est mieux, ce qui est un peu court).
Des roles et bases systèmes sont installées. La base azure_sys contient le query_store. La base azure_maintenance est gérée par Azure et est inaccessible.
Le role azure_admin permet de donner des droits "admin" (non superuser, il s'agit de droit étendu). Entre Single server et Flexible server, certains rôles ont changé de nom (d'où des erreurs remontées en migrant via pg_dump/pg_restore entre un single et un flexible).
Je n'ai pas eu le loisir de tester la géoréplication.
Le gros manque est comment ça marche sous le capot (query_store, container derrière ...) et la limitation des droits "admin" dans ce que j'ai pu voir jusqu'ici.
Bonjour, je me permets de remonter ce fil sur un petit retour sur le query store que j'ai pu tester.
Le query store est simple a installer (un ou deux paramètres serveurs). Je n'ai pas pu voir un surcoût de son activation, mon serveur étant assez peu actif. Par défaut, il conserver 7 jours de données.
le query store se compose de 2 parties, une table qui reprend tout pg_stat_statement mais sur une fenêtre de temps (avec un start_time et end_time) et une vue d'échantilonage des waits toujours sur une fenêtre de temps. La doc n'indique pas vraiment comment cela est récupéré (est-ce pg_stat_statement en dessous et l'extension pg_wait_sampling ?).
Le fait d'avoir des fenêtres temporelles m'a été bien utile quand un utilisateur indique un ralentissement de son application à telle moment de journée, on arrive à retrouver facilement les requêtes les plus longues.
Côté wait, c'est aussi simple à requêter et fournit un enregistrement par wait par exécution. Dommage, qu'il n'y a pas de plus de détail de comment c'est alimenté derrière.
Tout est dans une bases créée par Azure nommée azure_sys.
J'en suis plutôt satisfait au final.
Pour le log analytics, une fois qu'on a pris le coup sur le K-SQL, on peut facilement interroger (mais parfois le parsing du message des logs est un peu laborieux). Sin on envoie les fichiers logs, on retrouve tout ce qu'il y a dedans avec la possibilité de faire des rapports et avoir des graphiques.
A propos du service PaaS lui même, côté administration, le compte fourni comme admin n'est pas superuser (comme RDS). Ca peut être un peu plus pénible pour gérer les permissions/proriétés des objets (je passe par un set role xxx). Pour la mise en place, ça peut être facile (portail ou terraform). 2 modes d'accès : public (règles pg_hba à notre main via le portail dan la zone networking security ou du CLI) ou vnet integration (et là, la complication vient de comment y accéder depuis des VM onprem, il faut les intégrer dans le vnet).
Côté migration entre 2 serveurs, on passe par pg_dump/pg_restore (je n'ai traité qu'une base de 80 Go, ça peut prendre du temps en fonction du tiers service).
Voilà.
Bon, ça a tourné pendant des heures sans aboutir et fait planter mon client.
Mais au moins, le métier est d'accord pour migrer sur au moins une v11 (v13 possible si je peux aller sur du Azure PostgreSQL flexible server).
Merci. Je vais essayer de le faire (il faut que je planifie avec le métier).
Bonjour,
Sur une version 9.5 (!!!) en Azure for postgresql single server, j'ai une requête qui met environ 4H à s'exécuter. Il y a une grosse table de presque 200 millions de lignes d'un côté et une autre de quelques centaines de milliers.
Dans le plan d'exécution https://explain.dalibo.com/plan/vmJ, j'ai une branche avec un SORT de 6096 lignes (actual) suivi ensuite d'un materialize qui a 25 milliards en rows.
Ensuite entre le materialize et l'autre branche, j'ai un merge left join qui met 4H à s'exécuter et passe tout son temps à retirer les 25 milliards de lignes.
En testant sur une v11 (Azure for postgresql single server), je n'ai plus le materialize sur un volume similaire, j'ai le sort et tout de suite le merge left join. Et la requête tourne en une dizaine de min. J'ai aussi du parallelisme sur le merge que je n'ai pas en 9.5 (la doc sur parallel plans ne me donne pas de lien 9.5) et je n'ai jamais travaillé sur cette version, est-ce que ça signifie qu'elle ne fait pas de parallelism ou de façon très limitée ?
Je suppose que le plannificateur a ce comportement particulier de materialize en 9.5 et pas en 11.
Comment est-ce que ce 25 milliards est calculé ? Est-ce juste le plannificateur qui fonctionne comme cela pour l'époque ?
Est-ce qu'il y aurait, juste pour ma culture personnelle, une astuce qui permet de supprimer ce materialize (il est prévu de migrer en v11 pour ne pas rester sur une version non supportée - et je pense que ça réglera ce soucis et il suffira d'optimiser ensuite de manière classique) ?
Merci.
Bonjour,
Je débute sur Azure Database for PostgreSQL (et je ne suis pas expert PostgreSQL tout court). J'ai un serveur où les utilisateurs se plaignent des performances sur certains traitements. Je souhaite mettre en place le outils à disposition pour monitorer (query store azure, logs analytics ...)
Est-ce que quelqu'un a un retour d'expérience sur le query store et le log analytics sur un serveur Azure Database for PostgreSQL single server ? Sur les paramètres de mise en place ?
Est-il moins impactant que pg_stat_statement comme le dit la doc ?
Pour les logs, est-ce simple à analyser par log analytics (pour traiter les requêtes lentes que je pourrais enregistrer dans les logs par exemple) ?
Merci.
Pages : 1
