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:
- stock — standard PostgreSQL-installation med binärfiler från PGDG-paket.
- TDE-4 — PostgreSQL TDE-installation med kryptering avaktiverad, med hjälp av binärfiler kompilerade med gcc 4.8
- 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
- TDE-4-e — PostgreSQL TDE-installation med kryptering aktiverad, med hjälp av binärfiler kompilerade med gcc 4.8
- 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 | |||||
connections | stock | TDE-4 | TDE-4-e | TDE-9 | TDE-9-e |
12 | 598.004,94 | 652.870,65 | 640.867,94 | 651.161,67 | 668.317,19 |
16 | 717.080,83 | 806.152,21 | 795.300,37 | 794.494,71 | 821.915,21 |
20 | 735.584,04 | 813.589,44 | 801.139,14 | 807.197,44 | 829.891,65 |
24 | 757.834,24 | 818.350,37 | 809.893,87 | 817.332,59 | 832.810,15 |
28 | 865.626,22 | 911.020,73 | 896.977,27 | 909.858,10 | 916.804,18 |
32 | 1.095.158,47 | 1.212.918,76 | 1.175.538,12 | 1.182.331,49 | 1.233.930,94 |
36 | 885.519,57 | 958.732,55 | 931.091,56 | 967.514,37 | 986.631,16 |
40 | 847.388,93 | 943.701,45 | 915.369,45 | 919.076,23 | 964.899,29 |
44 | 830.018,15 | 914.696,79 | 901.860,60 | 913.789,27 | 954.813,04 |
48 | 818.142,23 | 916.199,48 | 894.018,17 | 901.936,11 | 964.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.

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

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 | |||||
connections | stock | TDE-4 | TDE-4-e | TDE-9 | TDE-9-e |
12 | 583.003,70 | 623,487,99 | 611.303,93 | 615.277,51 | 628.507,18 |
16 | 723.460,41 | 772.852,04 | 750.083,11 | 761.129,07 | 782.628,12 |
20 | 750.054,44 | 782.333,97 | 770.649,65 | 778.393,73 | 795.200,14 |
24 | 755.796,29 | 792.365,30 | 773.744,79 | 787.903,80 | 802.164,80 |
28 | 842.270,11 | 890.584,06 | 872.163,41 | 886.265,42 | 895.721,71 |
32 | 1.087.753,87 | 1.166.292,93 | 1.124.810,04 | 1.133.026,80 | 1.170.395,10 |
36 | 881.376,33 | 926.521,14 | 901.508,03 | 914.466,29 | 948.293,12 |
40 | 860.762,15 | 911.308,67 | 875.478,96 | 911.961,05 | 912.369,46 |
44 | 857.354,28 | 895.126,03 | 863.349,07 | 878.027,97 | 916.855,40 |
48 | 853.062,65 | 881.192,84 | 858.566,69 | 882.463,09 | 910.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:

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 | |||||
connections | stock | TDE-4 | TDE-4-e | TDE-9 | TDE-9-e |
12 | 78.858,92 | 75.226,39 | 74.968,65 | 80.913,53 | 82.063,75 |
16 | 104.880,27 | 99.974,75 | 99.921,82 | 106.414,78 | 107.763,35 |
20 | 126.328,88 | 120.898,40 | 119.139,41 | 124.199,94 | 125.980,44 |
24 | 143.740,06 | 139.041,17 | 134.917,30 | 136.937,95 | 140.407,50 |
28 | 156.813,58 | 152.443,32 | 147.754,62 | 148.286,04 | 152.065,41 |
32 | 170.999,35 | 162.929,84 | 156.527,94 | 157.810,55 | 164.181,20 |
36 | 180.937,04 | 171.578,25 | 165.513,33 | 167.660,63 | 172.848,70 |
40 | 189.501,24 | 180.439,46 | 173.084,98 | 174.142,58 | 179.936,11 |
44 | 196.615,29 | 187.607,67 | 178.765,27 | 179.044,87 | 185.212,72 |
48 | 201.491,30 | 192.716,50 | 183.124,81 | 183.379,49 | 190.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.

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 | |||||
connections | stock | TDE-4 | TDE-4-e | TDE-9 | TDE-9-e |
12 | 3.580,13 | 3.520,69 | 2.014,56 | 2.014,16 | 2.024,19 |
16 | 4.537,57 | 4.493,65 | 2.548,15 | 2.565,76 | 2.547,17 |
20 | 5.311,45 | 5.374,37 | 3.002,80 | 5.091,04 | 2.995,52 |
24 | 6.192,00 | 6.208,62 | 3.432,04 | 4.998,44 | 3.420,59 |
28 | 6.904,77 | 6.766,71 | 3.784,67 | 4.923,47 | 3.803,69 |
32 | 7.626,48 | 7.473,48 | 4.134,59 | 4.725,00 | 4.139,35 |
36 | 8.040,79 | 7.838,61 | 4.456,76 | 5.474,01 | 4.463,35 |
40 | 8.389,51 | 8.408,85 | 4.697,79 | 7.043,24 | 4.713,90 |
44 | 8.971,14 | 8.853,69 | 4.983,57 | 4.982,57 | 4.965,51 |
48 | 9.246,47 | 9.085,38 | 5.191,75 | 7.751,70 | 5.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.

Bilden är liknande om mängden data ökas till en pgbench-skalfaktor på 500:
TPC | |||||
500 | |||||
connections | stock | TDE-4 | TDE-4-e | TDE-9 | TDE-9-e |
12 | 4.088,59 | 4.098,60 | 2.201,37 | 3.106,54 | 3.080,33 |
16 | 5.417,76 | 5.372,61 | 2.818,17 | 3.400,99 | 3.278,76 |
20 | 6.716,89 | 6.688,04 | 3.437,78 | 3.712,33 | 3.672,65 |
24 | 7.792,77 | 7.903,35 | 4.021,37 | 4.484,28 | 4.576,07 |
28 | 9.061,49 | 7.850,11 | 4.631,35 | 4.926,10 | 5.150,77 |
32 | 10.399,70 | 10.428,75 | 5.235,09 | 5.515,01 | 5.818,24 |
36 | 11.631,82 | 11.737,26 | 5.811,99 | 6.056,26 | 6.381,50 |
40 | 12.998,91 | 12.986,14 | 6.349,06 | 6.911,43 | 6.526,33 |
44 | 14.201,98 | 14.301,64 | 6.913,72 | 7.360,12 | 7.472,31 |
48 | 14.908,41 | 15.259,67 | 7.489,46 | 8.097,42 | 7.650,18 |

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 | |||||
connections | stock | TDE-4 | TDE-4-e | TDE-9 | TDE-9-e |
12 | 4.232,58 | 4.350,82 | 2.176,31 | 2.183,95 | 2.167,18 |
16 | 5.466,42 | 5.259,30 | 2.908,34 | 2.960,76 | 2.908,90 |
20 | 4.791,08 | 6.854,99 | 3.385,01 | 3.415,35 | 3.381,12 |
24 | 4.676,96 | 5.967,64 | 3.983,86 | 3.993,32 | 3.994,85 |
28 | 4.568,79 | 4.544,86 | 4.514,53 | 4.547,60 | 4.537,21 |
32 | 5.151,62 | 5.085,77 | 5.058,35 | 5.087,52 | 5.029,79 |
36 | 5.658,66 | 5.718,43 | 5.507,31 | 5.616,75 | 5.511,39 |
40 | 6.138,71 | 6.167,15 | 5.952,18 | 5.948,25 | 6.007,10 |
44 | 6.437,95 | 6.569,21 | 6.453,01 | 6.356,46 | 6.432,60 |
48 | 6.968,81 | 7.012,23 | 6.807,95 | 6.845,92 | 6.791,73 |

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 >>