CYBERTEC Logo

PostgreSQL performance: Encrypted vs. unencrypted

PostgreSQL TDE ist eine Open Source PostgreSQL Version, welche die Daten verschlüsselt bevor diese auf der Festplatte speichert. Diese Verschlüsselungs-Mechanik macht TDE zu einer sichereren PostgreSQL-Variante, die sehr gut für den Einsatz in Unternehmen geeignet ist. Das ist der Grund, warum auch CYBERTEC PostgreSQL Enterprise Edition (PGEE) stark auf Verschlüsselung setzt.

PostgreSQL Performance Analyse

Wir werden oft gefragt, zu welchen Unterschieden in der Performance die Verschlüsselung von PostgreSQL führt. Um diese Frage zu beantworten, haben wir eine umfassende Performance Analyse durchgeführt, die verschiedene PostgreSQL-Settings und deren Performance miteinander vergleicht. Die Performance Tests wurden unter Verwendung der folgend dargestellten Hardware und Software durchgeführt.

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

genutzte Software

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

Randbemerkungen

Da die Ergebnisse auf einer SSD ohne ordnungsgemäßes TRIM Management durchgeführt wurden, wird eine zweite Version aller Analysen mit ordnungsgemäßem TRIM (-o discard mount option) vorbereitet. Zudem werden die Skalen angepasst, um die Auswirkungen des Datensatzes auf den verfügbaren Speichern besser hervorzuheben:

  • klein (um eine Größenordnung kleiner als shared buffers) – scale 12
  • gerade unter dem shared buffer-Limit (90% der shared buffers) – scale 900
  • größer als shared buffers aber dennoch im RAM (120% der shared buffers) – scale 1600
  • größer als RAM (120% des RAM) – scale 5000

Die anderen Parameter und das Tooling bleiben unverändert.

Benchmarking Methodik für PostgreSQL

Alle Tests wurden lokal durchgeführt. Genutzt wurde ein frisch initialisierter, leerer Cluster (fresh initdb).

All tests were performed locally using a freshly initialized, empty cluster (fresh initdb). Caching-Effekte auf der PostgreSQL-Seite sind daher nicht relevant.

Folgende Konfigurationen wurden getestet:

  1. stock — standard PostgreSQL installation using binaries from PGDG packages.
  2. TDE-4 — PostgreSQL TDE installation with encryption disabled, using binaries compiled with gcc 4.8
  3. TDE-9 — PostgreSQL TDE installation with encryption disabled, using binaries compiled with gcc 9.3 and optimized for znver2
  4. TDE-4-e — PostgreSQL TDE installation with encryption enabled, using binaries compiled with gcc 4.8
  5. TDE-9-e — PostgreSQL TDE installation with encryption enabled, using binaries compiled with gcc 9.3 and optimized for znver2

Es wurde nicht nur Standard PostgreSQL mit PostgreSQL TDE verglichen, sondern wir haben verschiedene Compiler-Versionen ausprobiert. Was für einige überraschend sein wird, ist dass der Compiler tatsächlich einen großen Einfluss hat.

PostgreSQL Konfiguration

Es wurde folgende PostgreSQL Konfiguration verwendet (postgresql.conf). Die Variablen wurden unter Verwendung des CYBERTEC Konfigurator festgelegt.

Die während des Benchmarks verwendeten Datenbankgrößen waren wie folgt:

  • 15: 244–287MB
  • 20: 332–404MB
  • 25: 400–458MB
  • 30: 479–543MB
  • 35: 557–629MB
  • 50: 793–880MB
  • 500: 7849–8028MB
  • 5000: 78409–78756MB (übersteigt den verfügbaren Speicher)

Für jeden Skalierungsfaktor wurden folgende Benchmarks gemessen (mit Standardoptionen):

  • standardmäßiger read-only Benchmark (pgbench built-in)
  • Standard TPC-ähnlicher read/write Benchmark (pgbench built-in) – vor jedem TPC-Lauf wurde die Datenbank neu indiziert, um die Auswirkungen der Indexnutzung auf die Ergebnisse zu vermeiden

Die Gleichzeitigkeit ist ein wichtiger Faktor, wenn Sie einen Benchmark in einer professionellen Umgebung durchführen wollen. Es wurden die folgenden Einstellungen verwendet:

  • 12
  • 16 — Anzahl der physischen Cores
  • 20
  • 24
  • 28
  • 32 — Anzahl der Hardware-Threads
  • 36
  • 40
  • 44
  • 48

PostgreSQL Benchmark Ergebnisse

Read-only benchmarks für PostgreSQL TDE

Der folgende Abschnitt enthält die Ergebnisse unserer Analyse. Starten wir mit einem read-only Benchmark und einem Skalierungsfaktor von 50, was 50 MB Daten (kleine Datenbank) entspricht:

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

Werfen wir einen Blick auf die erste Reihe (12 connections): Standard PostgreSQL liefert 598.000 read-only Transaktionen in der Sekunde, was ein guter Wert ist.  Im Allgemeinen haben wir festgestellt, dass AMD-CPUs heutzutage wirklich effizient sind und IBM POWER9 und viele andere deutlich übertreffen. Was wir feststellen, ist, dass der Compiler einen echten Unterschied macht. 651k TPS vs. 598k TPS ist eine satte 9%ige Verbesserung, die im Grunde genommen “umsonst” kommt. gcc 9 schlägt sich hier wirklich gut.

R-O 50: Performance shown by bar chart - TDE

Das folgende Bild zeigt die Architektur von PostgreSQL TDE:

Basic architecture TDE PostgreSQL encryption

Wichtig zu sehen ist auch, dass es im Grunde keinen Unterschied zwischen verschlüsselten und unverschlüsselten Runs gibt. Der Grund dafür ist einfach: PostgreSQL verschlüsselt 8k-Blöcke, bevor es sie auf die Platte schickt, und entschlüsselt sie, wenn ein Block vom Betriebssystem geholt wird. Daher gibt es keinen Unterschied zwischen der verschlüsselten und unverschlüsselten Performance. Was Sie sehen, sind im Grunde genommen Schwankungen, die durchaus zu erwarten sind.

Schauen wir uns jetzt wieder dieselben Daten an. Hier wurde ein Skalierungsfaktor von 500 genutzt, was 8 GB Daten entspricht.

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

Es ergibt sich ein sehr ähnliches Bild zu dem, was wir bei der kleinen Datenbank beobachten konnten. Da wir uns immer noch zu 100% im RAM befinden, gibt es keinen wirklichen Unterschied in der Performance durch die Verschlüsselung. Das was wir sehen, sind meistens Schwankungen:

R-O 500: Performance shown by bar chart - TDE

Der finale Test wurde mit einem Skalierungsfaktor von 5000 durchgeführt. Wichtig ist hierbei, dass die Datenbank nun so groß ist, dass sie nicht mehr im RAM gehalten werden kann. Das führt dazu, das wir einen Einbruch in der Performance feststellen:

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

Hier ist stets zu beachten, dass ein Nutzen der Festplatte viel teurer kommt, als die Durchführung von Zeigerarithmetik im gemeinsamen Speicher. Zu jeder einzelnen Abfrage wird eine Menge Latenz hinzugefügt, was zu niedrigen TPS führt, wenn es nicht genügend Verbindungen gibt. Auf SSDs kann dieser Effekt etwas reduziert werden, indem etwas mehr Gleichzeitigkeit hinzugefügt wird. Das funktioniert aber natürlich nur bis zu einem gewissen Punkt, bis die Kapazität der Platte überschritten wird.

R-O 5000: Performance shown by bar chart - TDE

Read-write Benchmarks für PostgreSQL TDE

Nach dieser schnellen Einführung zu read-only Benchmarks können wir uns nun auf read-write Workloads fokussieren. Wir verwenden hier die von pgbench bereitgestellten Standardmechanismen.

Als erster fällt hier auf, dass die Performance generell wesentlich geringer ist. Dafür gibt es verschiedene Gründe:

  • Eine read-write Transaktion in pgbench hat viel mehr Befehle
  • bei Commit muss PostgreSQL die Änderungen zur Festplatte “flushen” (fsync)

Werfen wir einen Blick auf die Daten:

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

Der Preis der Verschlüsselung beginnt sich bemerkbar zu machen. Wir sehen, dass die verschlüsselten Varianten deutlich unter dem nicht verschlüsselten Setup liegen können, was die Performance betrifft.

TPC 50: Performance shown by bar chart - TDE

Ein ähnliches Bild ergibt sich, wenn die Datenmenge auf einen pgbench-Skalierungsfaktor von 500 erhöht wird:

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
TPC 500: Performance shown by bar chart - TDE

Schauen wir uns nun die Daten zum Skalierungsfaktor 5000 an. Klar ist, dass sich die Performance generell dramatisch verschlechtert hat. Grund dafür ist, dass ein Teil der Daten von der Festplatte kommt. Daher kommt es zu erheblichen Wartezeiten und Latenzzeiten auf der Festplatte:

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
TPC 5000: Performance shown by bar chart - TDE

Bitte beachten Sie, dass alle dieser Ergebnisse mit Vorsicht zu genießen sind. Laufzeiten können immer leicht variieren, insbesondere dann, wenn SSds im Einsatz sind – das haben wir schon in einer Vielzahl an Fällen bemerkt. Der erwartbare Performance Level hängt außerdem stark von der PostgreSQL Cache Performance ab. Denken Sie daran: Jedes Mal wenn ein Block an die Festplatte gesendet wird oder in die shared buffers gelesen wird, hat eine Ver- bzw Entschlüsselung stattzufinden. Es kann daher Sinn machen, PostgreSQL TDE mit höheren shared_buffers-Einstellungen zu nutzen, als man das üblicherweise tun würde.

KONTAKTIEREN SIE UNS

Wenn Sie die Performance Ihrer Datenbank optimieren möchten, empfehlen wir Ihnen, einen Blick auf unsere Consulting Services zu werfen. Wir können Ihnen dabei helfen, Ihre Datenbank merkbar zu verschnellern. Wir bieten eine zeitnahe Lieferung, professionelle Services und über 20 Jahre an PostgreSQL Erfahrung.

Erfahren Sie mehr darüber, wie PostgreSQL Transparent Data Encryption für eine transparente und kryptografisch sichere Verschlüsselung Ihrer Daten sorgt und so Ihr wertvollstes Gut schützt: Ihre Daten.

CYBERTEC Logo white
CYBERTEC PostgreSQL International GmbH
Römerstraße 19
2752 Wöllersdorf
Austria

+43 (0) 2622 93022-0
office@cybertec.at

Get the newest PostgreSQL Info & Tools


    This site is protected by reCAPTCHA and the Google Privacy Policy & Terms of Service apply.

    ©
    2024
    CYBERTEC PostgreSQL International GmbH
    phone-handsetmagnifiercrosscross-circle
    0
    Would love your thoughts, please comment.x
    linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram