sql >> Databasteknik >  >> RDS >> MariaDB

Skrivoptimeringar för Qualcomm Centriq 2400 i MariaDB 10.3.5 Release Candidate

MariaDB har samarbetat med Qualcomm Datacenter Technologies för att driva prestandaomslutningen genom att utnyttja innovativ ARM-baserad hårdvaruarkitektur med MariaDB:s unika databasarkitektur. Som en del av produktlanseringen av Qualcomm Centriq™ 2400 redan i november 2017, visade vi den starka lässkalbarheten hos MariaDB på detta chip. Sedan dess har MariaDB och Qualcomm engineering arbetat med att förbättra skalbarheten för skrivoperationer som vi skulle vilja dela med utvecklargemenskapen idag.

Vi är glada att kunna tillkännage ett antal prestandaförbättringar som görs tillgängliga i den nyligen levererade versionen av 10.3 versionskandidaten 10.3.4. Genom att utnyttja den mycket parallelliserade 48-kärniga Qualcomm Centriq 2400-processorn som körs på 2,6 GHz med 6 minneskanaler i en helt koherent ringarkitektur, är vårt intresse att extrahera skrivprestandaoptimering i en enda rads skrivanvändningsfall för en mycket trådad applikation.

MariaDB använder sysbench benchmark programvara för att mäta prestanda. I den här bloggen kommer vi att undersöka följande två riktmärken med sysbench 1.0:

  • Oltp_update_index :Detta simulerar uppdatering av ett enstaka radvärde efter primärnyckelindex där ett sekundärt index måste uppdateras som ett resultat av uppdateringen.
  • Oltp_update_nonindex:Detta simulerar uppdatering av ett enstaka radvärde efter primärnyckelindex där det inte finns något sekundärt index. Detta kräver uppenbarligen mindre arbete än oltp_update_index.

Vad vi ser är att när antalet samtidiga trådar ökar, är prestandan upp till 48 % snabbare i 10,3 än 10,2 på Centriq™ 2400:

De förbättringar som gjorts tar bort stridspunkter och optimerar för ARM64-kretsuppsättningen, specifikt:

  • MDEV-15090 :Minska kostnaderna för att skriva ångra loggposter
  • MDEV-15132 :Undvik åtkomst till TRX_SYS-sidan
  • MDEV-15019 :InnoDB:lagra ReadView på trx
  • MDEV-14756 :Ta bort trx_sys_t::rw_trx_list
  • MDEV-14482 :Cachelinjekonflikt på ut_rnd_ulint_counter()
  • MDEV-15158 :Vid commit, skriv inte till TRX_SYS-sidan
  • MDEV-15104 :Ta bort trx_sys_t::rw_trx_ids och trx_sys_t::serialisation_list
  • MDEV-14638 :Ersätt trx_sys_t::rw_trx_set med LF_HASH
  • MDEV-14529 :InnoDB rw-locks:optimera minnesbarriärer
  • MDEV-14374 :UT_DELAY-kod :Tar bort hårdvarubarriär för arm64-bitarsplattform
  • MDEV-14505 :Threads_running blir skalbarhetsflaskhals

Sammanfattningsvis vad detta betyder är att MariaDB kommer att prestera betydligt bättre under höga nivåer av samtidiga uppdateringar, vilket förbättrar svarstiderna i dina applikationer vid toppbelastning.

Förbättringarna kommer också att ge fördelar för andra chiparkitekturer, men en mycket större vinst ses på Centriq™ 2400 på grund av dess design som kan stödja mycket högt antal trådar. Genom att använda fysiska kärnor kontra hypertrådning av ett lägre antal kärnor visar  Centriq™ 2400 ytterligare 13 % vinst jämfört med en jämförbar referens Broadwell-plattform.

När Centriq™ 2400-system kommer ut på marknaden i år är vi glada över att se kundarbetsbelastningar som drar fördel av skalbarheten i kombination med lägre energiförbrukning för att köra högskaliga databasarbetsbelastningar.


  1. Hur man kombinerar resultaten av två frågor i SQL

  2. SQL Server:Fråga snabbt, men långsam från proceduren

  3. Möjliga sätt att åtgärda problem med korruption av SQL Server-metadata

  4. Vad är nolltecken bokstavlig i TSQL?