On Thu, 2024-10-10 at 08:39 +0200, felix via gull wrote: > Voilà un sujet surprenant. > > Un client me contacte car il à créé une base de données PostgreSQL, > sous window, avec une machine performante. Son projet fonctionne, > il décide de le passer sur machine tournant sous Linux. > > Là il constate qu'un requête `select count(*) from SomeView where > Id=12;` > prend environ 28 secondes sous Linux alors que sous Window, la > réponse > arrive en 8 secondes! > > Les machines sont différentes, mais cela n'explique pas: > - Window 32G 12 coeurs 3GHz > - Linux 16G 8 coeurs. 3.2GHz > Sous linux la swap n'est pas accédée. > > En donc en suivant les acticités des processeurs, sous window on voit > clairement les 12 cpu qui s'agittent durant les 8 secondes, alors que > sous linux, on voit 1 processeur au top durant 4 secondes, puis un > autre > ``prend le relais'', ainsi de suite, à aucun moment je ne voit plus > d'un > coeur au top. A noter que sous window, les 12 courbes s'agittent mais > aucune ne top (cela me semble logique en réfléchissant à la > complexité > d'un requête de VUE qui contient des JOIN et autre resultat à > imbriquer). > > J'ai cherché les options de parallelization dans les configs de > postgresql, > sur google&co, je dois dire que je ne vois pas... > Je n'ai pas bien compris non plus les calculs de coûts: > > #seq_page_cost = 1.0 # measured on an arbitrary > scale > #random_page_cost = 4.0 # same scale as above > #cpu_tuple_cost = 0.01 # same scale as above > #parallel_tuple_cost = 0.1 # same scale as above > #parallel_setup_cost = 1000.0 # same scale as above > ... > > Il faut dire que ``measured on an arbitrary scale'' et ``same scale > as above'' > ne sont pas des information très explicites.
Bonjour, Ce qui est surprenant c'est déjà le temps d'exécution quelque soit le systême: - Que fait donc la "SomeView" comme calcul ou accès pour que cela prenne autant de temps ? - Est-ce vraiment le CPU qui est limitant ? - Ne manquerait-il pas tout simplement des index sur les critères de filtrage, en supposant qu'ils sont présents sur les foreign key utilisés pour les jointures ? Pour optimiser, je recommande l'usage de: - pg_stat_statements - pgBadger afin d'identifier si le temps de réponse correspond à des accès disque ou des calculs "bruts" (formules ou procédures stockées) ou à des parcours d'index Je pose aussi un pari sur une valeur de work_mem trop faible qui limite les traitements de jointure et de tri. En espérant que ça puisse aider -- Yves Martin _______________________________________________ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull
