PostgreSQL TDE är en Open Source-version av PostgreSQL som krypterar data innan den lagras säkert på disk. Det är därför en säkrare och därmed en mer företagsklar variant av databasen. Därför är CYBERTEC PostgreSQL Enterprise Edition (PGEE) också starkt beroende av kryptering.

Prestationsanalys av PostgreSQL

Människor frågar ofta om prestandaskillnaderna mellan krypterad och okrypterad PostgreSQL. För att svara på denna fråga har vi genomfört en omfattande prestandaanalys för att belysa detta viktiga ämne och för att ge användarna ett sätt att jämföra olika PostgreSQL-inställningar och deras prestanda. Våra prestandatester har utförts med följande hårdvaru- och mjukvarukomponenter:

Hardware setup

CPU: AMD Ryzen 5950X — 16 cores / 32 thread, 72MB cache, support for AES-NI

MEMORY: 64GB RAM — DDR4 2666 ECC dual channel

STORAGE: SSD Samsung 980 PRO — nvme, PCIe v4 ×4

simple lvm volume, XFS filesystem, exclusive use

Software in use

OS: Linux Centos 7.9.2009, kernel 5.10.11-1.el7.elrepo.x86_64

PostgreSQL: postgresql13-13.1-3PGDG.rhel7.x86_64 from PGDG repo

PostgreSQL 13.1 TDE: built locally with the standard compile options used for PGDG packages using base GCC 4.8.5 20150623 (Red Hat 4.8.5-44)

PostgreSQL 13.1 TDE: built locally with the standard compile options used for PGDG packages using software collection devtoolset-9 GCC 9.3.1 20200408 (Red Hat 9.3.1-2) and -march=znver2

We have used a few scripts to run these benchmarks in an automated way. You can download the tools for free from our Github page.

Sidoteckningar

Eftersom resultaten utfördes på en SSD-enhet utan korrekt TRIM-hantering förbereds den andra versionen av alla dessa analyser, med korrekt TRIM (-o kassera monteringsalternativ) och skalor justeras för att bättre betona effekterna av en datamängd på tillgängliga minne:

  • liten (storleksordning mindre än delade buffertar) – skala 12
  • strax under gränsen för delade buffertar (90% av delade buffertar) – skala 900
  • större än delade buffertar men passar fortfarande i RAM (120% av delade buffertar) – skala 1600
  • större än RAM (120% av RAM) – skala 5000

Andra params och verktyg kommer att vara desamma.

Benchmarking-metodik för PostgreSQL

Alla tester utfördes lokalt med ett nyinitierat, tomt kluster (ny initdb). Därför är cachingeffekter på PostgreSQL-sidan inte relevanta.

Följande konfigurationer testades:

  1. stock — standard PostgreSQL-installation med binärfiler från PGDG-paket.
  2. TDE-4 — PostgreSQL TDE-installation med kryptering avaktiverad, med hjälp av binärfiler kompilerade med gcc 4.8
  3. TDE-9 — PostgreSQL TDE-installation med kryptering inaktiverad, med hjälp av binära filer sammanställt med gcc 9.3 och optimerad för znver2
  4. TDE-4-e — PostgreSQL TDE-installation med kryptering aktiverad, med hjälp av binärfiler kompilerade med gcc 4.8
  5. TDE-9-e — PostgreSQL TDE-installation med kryptering aktiverad, med binärfiler kompilerade med gcc 9.3 och optimerade för znver2

Observera att vi inte bara jämförde standard PostgreSQL med PostgreSQL TDE utan också försökte olika kompilatorversioner. Du kommer att få reda på att kompilatorn verkligen har stor inverkan, vilket kan komma som en överraskning för många.

PostgreSQL-konfiguration

Följande PostgreSQL-konfiguration har använts (postgresql.conf). Dessa variabler har bestämts med hjälp av CYBERTEC-konfiguratorn:

max_connections = 100
unix_socket_directories = '/var/run/postgresql'
port = 15432
shared_preload_libraries = 'pg_stat_statements'
shared_buffers = 16GB
work_mem = 64MB
maintenance_work_mem = 620MB
effective_cache_size = 45GB
effective_io_concurrency = 100
huge_pages = try
track_io_timing = on
track_functions = pl
wal_level = logical
max_wal_senders = 10
synchronous_commit = on
checkpoint_timeout  = '15 min'
checkpoint_completion_target = 0.9
max_wal_size = 1GB
min_wal_size = 512MB
wal_compression = on
wal_buffers = -1
wal_writer_delay = 200ms
wal_writer_flush_after = 1MB
bgwriter_delay = 200ms
bgwriter_lru_maxpages = 100
bgwriter_lru_multiplier = 2.0
bgwriter_flush_after = 0
max_worker_processes = 16
max_parallel_workers_per_gather = 8
max_parallel_maintenance_workers = 8
max_parallel_workers = 16
parallel_leader_participation = on
enable_partitionwise_join = on
enable_partitionwise_aggregate = on
jit = on

Databasstorlekar som användes under riktmärket var följande:

  • 15: 244–287MB
  • 20: 332–404MB
  • 25: 400–458MB
  • 30: 479–543MB
  • 35: 557–629MB
  • 50: 793–880MB
  • 500: 7849–8028MB
  • 5000: 78409–78756MB (exceeds total available memory)

För varje skalfaktor mättes följande riktmärken (med standardalternativ):

  • standard skrivskyddat riktmärke (pgbench inbyggt)
  • standard TPC-liknande läs / skriv-riktmärke (inbyggd pgbench) – före varje TPC-körning indexerades databasen om för att undvika påverkan av indexanvändning på resultaten

Samtidighet är en viktig faktor om du vill mäta i en professionell miljö. Följande inställningar användes:

  • 12
  • 16 — number of physical cores
  • 20
  • 24
  • 28
  • 32 — number of hardware threads
  • 36
  • 40
  • 44
  • 48

PostgreSQL-benchmarking-resultat

Skrivskyddade riktmärken för PostgreSQL TDE

Följande avsnitt innehåller resultaten av vår undersökning. Låt oss börja med ett skrivskyddat riktmärke och en skalfaktor på 50, vilket översätter till 880 MB data (liten databas):

R-O
50
connectionsstockTDE-4TDE-4-eTDE-9TDE-9-e
12598.004,94652.870,65640.867,94651.161,67668.317,19
16717.080,83806.152,21795.300,37794.494,71821.915,21
20735.584,04813.589,44801.139,14807.197,44829.891,65
24757.834,24818.350,37809.893,87817.332,59832.810,15
28865.626,22911.020,73896.977,27909.858,10916.804,18
321.095.158,471.212.918,761.175.538,121.182.331,491.233.930,94
36885.519,57958.732,55931.091,56967.514,37986.631,16
40847.388,93943.701,45915.369,45919.076,23964.899,29
44830.018,15914.696,79901.860,60913.789,27954.813,04
48818.142,23916.199,48894.018,17901.936,11964.656,08

 

Ta en titt på första raden (12 anslutningar). Standard PostgreSQL ger 598.000 skrivskyddade transaktioner per sekund vilket är ett bra antal. I allmänhet har vi funnit att AMD-processorer är riktigt effektiva i dessa dagar och överträffar IBM POWER9 och många andra. Vad vi märker är att kompilatorn gör en verklig skillnad. 651k TPS jämfört med 598k TPS är en jättestor förbättring på 9% som i grund och botten kommer ”gratis”. gcc 9 mår riktigt bra här.

TDE performance R-O 50

Följande bild visar den grundläggande arkitekturen för PostgreSQL TDE:

TDE architecture

Vad som också är viktigt att se är att det i princip inte finns någon skillnad mellan krypterade och icke-krypterade körningar. Anledningen till det är enkelt: PostgreSQL krypterar 8k block innan de skickas till disk och dekrypteras när ett block hämtas från operativsystemet. Därför är det ingen skillnad mellan den krypterade och okrypterade prestandan. Vad du ser är i grunden fluktuationer som förväntas helt.

 

Låt oss ta en titt på samma data. I det här fallet använder vi en skalfaktor 500 som översätts till 8 GB data

R-O
500
connectionsstockTDE-4TDE-4-eTDE-9TDE-9-e
12583.003,70623,487,99611.303,93615.277,51628.507,18
16723.460,41772.852,04750.083,11761.129,07782.628,12
20750.054,44782.333,97770.649,65778.393,73795.200,14
24755.796,29792.365,30773.744,79787.903,80802.164,80
28842.270,11890.584,06872.163,41886.265,42895.721,71
321.087.753,871.166.292,931.124.810,041.133.026,801.170.395,10
36881.376,33926.521,14901.508,03914.466,29948.293,12
40860.762,15911.308,67875.478,96911.961,05912.369,46
44857.354,28895.126,03863.349,07878.027,97916.855,40
48853.062,65881.192,84858.566,69882.463,09910.616,50

 

Bilden är ganska lik vad vi observerade med den lilla databasen. Vi har fortfarande 100% RAM och därför finns det ingen verklig prestandaskillnad mellan PostgreSQL TDE med kryptering på eller kryptering av. Vad du ser är mest fluktuationer:

TDE performance R-O 500

 

Det slutgiltiga testet genomfördes med en skalfaktor på 5000. Den viktiga delen är att databasen har vuxit så stor att det inte finns något sätt att hålla den i RAM längre. Således kan vi observera en kraftig nedgång i prestanda:

R-O
5000
connectionsstockTDE-4TDE-4-eTDE-9TDE-9-e
1278.858,9275.226,3974.968,6580.913,5382.063,75
16104.880,2799.974,7599.921,82106.414,78107.763,35
20126.328,88120.898,40119.139,41124.199,94125.980,44
24143.740,06139.041,17134.917,30136.937,95140.407,50
28156.813,58152.443,32147.754,62148.286,04152.065,41
32170.999,35162.929,84156.527,94157.810,55164.181,20
36180.937,04171.578,25165.513,33167.660,63172.848,70
40189.501,24180.439,46173.084,98174.142,58179.936,11
44196.615,29187.607,67178.765,27179.044,87185.212,72
48201.491,30192.716,50183.124,81183.379,49190.149,00

 

Du måste komma ihåg att gå till disk är många många gånger dyrare än att göra någon pekare aritmetik i delat minne. Mycket latens läggs till i varje enskild fråga vilket leder till låg TPS om det inte finns tillräckligt med anslutningar. På SSD: er kan denna effekt minskas lite genom att lägga till lite mer samtidighet. Att lägga till samtidighet fungerar dock bara upp till en viss punkt tills diskens kapacitet har överskridits.

TDE performance R-O 5000

Läs-skriv riktmärken för PostgreSQL TDE

Efter denna korta introduktion till skrivskyddade riktmärken kan vi fokusera vår uppmärksamhet på skriv- och arbetsbelastningar. Vi använder de standardmekanismer som tillhandahålls av pgbench här.

Det första vi märker är att prestanda är mycket lägre. Det finns två skäl till det:

  • En läs-skriv-transaktion i pgbench har många fler kommandon
  • PostgreSQL måste spola ändringar (fsync) ändringar till disk on commit

Låt oss ta en titt på data:

TPC
50
connectionsstockTDE-4TDE-4-eTDE-9TDE-9-e
123.580,133.520,692.014,562.014,162.024,19
164.537,574.493,652.548,152.565,762.547,17
205.311,455.374,373.002,805.091,042.995,52
246.192,006.208,623.432,044.998,443.420,59
286.904,776.766,713.784,674.923,473.803,69
327.626,487.473,484.134,594.725,004.139,35
368.040,797.838,614.456,765.474,014.463,35
408.389,518.408,854.697,797.043,244.713,90
448.971,148.853,694.983,574.982,574.965,51
489.246,479.085,385.191,757.751,705.170,42

 

Priset på kryptering börjar säga. Vi ser att prestanda för de krypterade varianterna kan vara betydligt lägre än för den icke-krypterade installationen.

TDE performance tpc 50

 

Bilden är liknande om mängden data ökas till en pgbench-skalfaktor på 500:

TPC
500
connectionsstockTDE-4TDE-4-eTDE-9TDE-9-e
124.088,594.098,602.201,373.106,543.080,33
165.417,765.372,612.818,173.400,993.278,76
206.716,896.688,043.437,783.712,333.672,65
247.792,777.903,354.021,374.484,284.576,07
289.061,497.850,114.631,354.926,105.150,77
3210.399,7010.428,755.235,095.515,015.818,24
3611.631,8211.737,265.811,996.056,266.381,50
4012.998,9112.986,146.349,066.911,436.526,33
4414.201,9814.301,646.913,727.360,127.472,31
4814.908,4115.259,677.489,468.097,427.650,18

 

TDE performance TPC 500

 

Låt oss nu inspektera testet med en skalfaktor på 5000. Det vi tydligt ser är att den totala prestandan dramatiskt minskar. Anledningen är naturligtvis att mycket av data måste komma från disken. Vi ser därför en hel del diskväntan och latens:

TPC
5000
connectionsstockTDE-4TDE-4-eTDE-9TDE-9-e
124.232,584.350,822.176,312.183,952.167,18
165.466,425.259,302.908,342.960,762.908,90
204.791,086.854,993.385,013.415,353.381,12
244.676,965.967,643.983,863.993,323.994,85
284.568,794.544,864.514,534.547,604.537,21
325.151,625.085,775.058,355.087,525.029,79
365.658,665.718,435.507,315.616,755.511,39
406.138,716.167,155.952,185.948,256.007,10
446.437,956.569,216.453,016.356,466.432,60
486.968,817.012,236.807,956.845,926.791,73

 

TDE performance TPC 5000

Observera att alla resultat måste tas med ett saltkorn. Driftstider kan alltid variera något. Detta gäller särskilt om SSD-enheter används. Vi har sett det om och om igen. Prestandanivån som vi kan förvänta oss beror också mycket på PostgreSQL-cacheprestanda. Kom ihåg: varje gång ett block skickas till disken eller läses in i delade buffertar måste krypterings- / dekrypteringsmagiken hända. Således kan det vara mycket meningsfullt att köra PostgreSQL TDE med högre shared_buffers-inställningar än vad du normalt skulle göra för att minska påverkan av säkerhet.

KONTAKTA OSS

Om du siktar på bättre PostgreSQL-databasprestanda, föreslår vi att du tittar på våra konsulttjänster. Vi kan hjälpa dig att snabba upp din databas avsevärt. Vi erbjuder snabb leverans, professionell hantering och över 20 års erfarenhet av PostgreSQL.

Kontakta oss >>

 

Också: kolla in PostgreSQL Transparent Data Encryption för transparent och kryptografiskt säker datakryptering (kluster). TDE hjälper dig att säkra din mest värdefulla tillgång: dina data.

Kolla in TDE >>