postgresql 9 - parallأ‰lisme postgresql est multi-process et pas multi-thread une requأھte est...

Download POSTGRESQL 9 - PARALLأ‰LISME PostgreSQL est multi-process et pas multi-thread Une requأھte est exأ©cutأ©e

Post on 01-Sep-2019

1 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • POSTGRESQL 9.6QUELQUES NOUVEAUTS

    Cr par / Guillaume Lelarge @g_lelarge

    http://blog.guillaume.lelarge.info/http://twitter.com/g_lelarge
  • L'AUTEURAuteur : Guillaume LelargeSocit : Date : Juin 2016URL :

    Dalibo

    KB Dalibo

    http://dalibo.com/https://kb.dalibo.com/conferences/nouveautes_de_postgresql_9.6/
  • INTRODUCTIONDveloppement commenc en Juin 2015En beta 2

    c'est le moment pour tester !Sortie prvue en septembre 2016

  • PARALLLISMEPostgreSQL est multi-process

    et pas multi-threadUne requte est excute par un processus

    et donc par un CPU !Un goulet d'tranglement peut tre la vitesse du CPU

    seule solution pour une excution plus rapide : utiliserplusieurs CPU

  • EXEMPLE D'UN PARCOURS EN 9.5EXPLAIN(ANALYSE,COSTSOFF)SELECT*FROMt1WHEREc1

  • LE MME EN 9.6EXPLAIN(ANALYSE,COSTSOFF)SELECT*FROMt1WHEREc1ParallelSeqScanont1(actualtime=26.338..747.273...Filter:(c1

  • AU NIVEAU SYSTME$psef|greppostgres172215:18postmasterD/opt/postgresql/datas/r96173815:18postgres:checkpointerprocess174015:18postgres:writerprocess174115:18postgres:walwriterprocess174215:18postgres:autovacuumlauncherprocess174315:18postgres:statscollectorprocess178115:18postgres:postgrespostgres[local]EXPLAIN206715:23postgres:bgworker:parallelworkerforPID1781206815:23postgres:bgworker:parallelworkerforPID1781

  • TENDUE DU PARALLLISMEParcours squentiel

    Parallel Seq ScanJointureAgrgat

    Partial Aggregate et Finalize Aggregate

  • AGRGATEXPLAIN(ANALYSE,COSTSOFF)SELECTcount(*),min(C1),max(C1)FROMt1

    QUERYPLANFinalizeAggregate(...)>Gather(...)WorkersPlanned:2WorkersLaunched:2>PartialAggregate(...)>ParallelSeqScanont1(...)Planningtime:0.196msExecutiontime:1759.422ms(8rows)

  • CONFIGURATIONParamtre max_parallel_workers_per_gather

    valeur par dfaut en beta : 2niveau maximum de paralllisation pour une requte

    Paramtre max_worker_processesvaleur par dfaut en beta : 8nombre maximum de background workers

    Degr de paralllisation d'une tableALTER TABLE t1 SET (parallel_degree = 2);

    FonctionsPARALLEL SAFE

  • SQL/MEDMED pour Management of External DataIntgr PostgreSQL

    8.3, infrastructure9.1, tables externes (lecture seule)9.2, des statistiques sur les donnes des tablesexternes9.3, tables externes en lecture et criture9.5, dclaration des tables rcuprableautomatiquement

    Nombreux connecteursPostgreSQL, Oracle, autres moteurs SQL, moteursNoSQL, fichiers, services web

  • NoSQL, fichiers, services web

    SORT PUSHDOWNEXPLAIN(ANALYZE,COSTSOFF,VERBOSE)SELECT*FROMft1ORDERBYc1

    QUERYPLANForeignScanonpublic.ft1(...)Output:c1,c2RemoteSQL:SELECTc1,c2FROMpublic.t1ORDERBYc1ASCNULLSLASTPlanningtime:0.136msExecutiontime:32644.751ms(5rows)

  • JOIN PUSHDOWNEXPLAIN(VERBOSE)SELECT*FROMft1aJOINft1bONa.c1=b.c1WHEREa.c1=100

    QUERYPLANForeignScan(cost=100.00..754686.03rows=1width=36)Output:a.c1,a.c2,b.c1,b.c2Relations:(public.ft1a)INNERJOIN(public.ft1b)RemoteSQL:SELECTr1.c1,r1.c2,r2.c1,r2.c2FROM(public.t1r1INNERJOINpublic.t1r2ON(((r2.c1=100))AND((r1.c1=100))))(4rows)

  • DML (UPDATE/DELETE) PUSHDOWNEXPLAIN(ANALYZE,VERBOSE,COSTSOFF)UPDATEft1SETc2=upper(c2)WHEREc1=2

    QUERYPLANUpdateonpublic.ft1(...)>ForeignUpdateonpublic.ft1(...)RemoteSQL:UPDATEpublic.t1SETc2=upper(c2)WHERE((c1=2))Planningtime:0.302msExecutiontime:1317.554ms(5rows)

  • RPLICATIONPlusieurs secondaires synchronesPossibilit d'attendre l'application des modifications surles secondairesAttention

    valeurs archive et hot_standby de wal_levelremplaces par replicaanciennes valeurs toujours acceptes, mais remplacessilencieusement par replica

  • PLUSIEURS SECONDAIRESSYNCHRONES

    Avant la 9.6un seul serveur synchroneles autres serveurs sont potentiellement synchronessynchronous_standby_names : liste des serveurs

    partir de la 9.6synchronous_standby_names = 'X (standby1, standby2,standby3)'X = nombre de serveurs synchrones

  • NOUVEAU MODE DESYNCHRONOUS_COMMIT

    Nouveau mode remote_applyLe matre attend l'application des modifications sur lessecondaires synchronesPotentiellement beaucoup plus lent

    mais aucune diffrence en lecture entre le matre et lessecondaires synchrones

  • MVCCMeilleure gestion des VACUUM FREEZEAmlioration des CHECKPOINTDure maximale d'un snapshot

  • MEILLEURE GESTION DES FREEZEge des transactions, entier non sign de 32 bitsRisque de dpassement

    utilisation d'un identifiant spcial pour les anciennestransactions

    Action de gel des lignesmanuel (FREEZE) ou automatique(autovacuum_freeze_max_age)parcours complet que la table soit modifie ou pas

    En 9.6extension de la Visibility Mapun bit supplmentaire (par bloc) pour identifier lesblocs parcourirextension pg_visibility

  • AMLIORATION DES CHECKPOINTAvant la 9.6, un checkpoint

    lisait le cache dans le dsordreet les crivait dans les fichiers

    Avec la 9.6rpartit les blocs modifis suivant les tablespacesles trie par fichier et numro de blocpuis les critles critures sont beaucoup plus squentielles

  • DURE MAXIMALE D'UN SNAPSHOTPermet de contrler la fragmentation des tablesParamtre old_snapshot_threshold

    -1, fonctionnalit dsactiveau maximum 60 jours

    Exemple pour une dure de 5 secondespostgres=#DELETEFROMt1WHEREc1%3=1ERROR:snapshottooold

  • DIVERSIndication de progression d'une commandePlus de dtails sur les blocages

  • INDICATION DE PROGRESSIOND'UNE COMMANDE

    Infrastructure de progression de commandesUtilis uniquement pour le VACUUM

    pour l'instant...et pas pour les VACUUM FULL

    Vue pg_stat_progress_vacuumpid|4299datid|13356datname|postgresrelid|16384phase|scanningheapheap_blks_total|127293heap_blks_scanned|86665heap_blks_vacuumed|86664index_vacuum_count|0max_dead_tuples|291num_dead_tuples|53

  • PLUS DE DTAILS SUR LESBLOCAGES

    Dans pg_stat_activityColonne waiting remplace par

    wait_eventwait_event_type

  • REQUTE DE VRIFICATIONSELECTpid,state,CASEWHENwait_eventisnotnullTHENconcat(wait_event,'(',wait_event_type,')')ELSENULL::textENDASlock_intel,pg_blocking_pids(pid)ASblocked_by,substr(query,1,20)FROMpg_stat_activity

  • EXEMPLE : BLOCAGE SUR OBJETpid|state|lock_intel|blocked_by|substr++++3801|active||{}|selectpid,state,c3905|idleintransaction||{}|select*fromt1whe4015|active|relation(Lock)|{3905}|droptablet1(3rows)

  • AUTRE EXEMPLE: BLOCAGE SURLIGNE

    pid|state|lock_intel|blocked_by|substr++++4299|active||{}|selectpid,state,c4976|idleintransaction||{}|select*fromt1whe5078|active|transactionid(Lock)|{4976}|select*fromt1whe(3rows)

  • CONCLUSIONEnfin de la paralllisationBeaucoup de nouvelles fonctionnalits

    SQL/MEDMaintenanceMonitoring

    tester fortement !

  • DALIBO EMBAUCHE !4 postes de DBA pourvoirContacter recrutement@dalibo.com

Recommended

View more >