De sleutel voor RocksDB performance

Er is géén wondermiddel mbt RocksDB performance. Nu ik je aandacht heb getrokken: er bestaat een kans dat je “geluk” hebt als je upstream Ceph Ubuntu packages gebruikt.

Wat betekent dat?

De performance van RocksDB is suboptimaal wanneer deze wordt gebouwd zonder RelWithDebInfo. Dit kan worden verholpen door “performance” package builds te installeren. De daadwerkelijke performance increase is afhankelijk van het cluster, maar de RocksDB compaction tijd wordt met een factor drie verminderd. In sommige gevallen wordt de performance van random 4K writes verdubbeld. Zie deze links [1] en [2].

Hoe kan ik dit performance issue oplossen?

1. Installeer een versie waarin dit probleem al is opgelost voor de release die je gebruikt: Pacific, Quincy,Reef
2. Als je een EOL-versie van Ceph gebruikt kan je het zelf bouwen. Raadpleeg de documentatie of de korte versie hieronder:

git clone ceph
cd ceph
git checkout vYour_Release_Verion
add "extraopts += -DCMAKE_BUILD_TYPE=RelWithDebInfo" to debian/rules file
./do_cmake.sh -DCMAKE_BUILD_TYPE=RelWithDebInfo
dpkg-buildpackage -us -uc -j$DOUBLE_NUMBER_OF_CORES_BUILD_HOST 2>&1 | tee ../dpkg-buildpackage.log

Opmerking: voeg de “-b” optie toe aan dpkg-buildpackage als je alleen binaire packages wil en geen source packages. Zorg ervoor dat je voldoende bestandsruimte vrij hebt en voldoende geheugen, vooral als je gaat bouwen met veel threads. Ik heb een VM gebruikt met 256 GB RAM, 64 cores en 300 GB schijfruimte, en dat duurde 1 uur en 7 minuten (voor een volledige build inclusief source packages).

Zorg ervoor dat je de dpkg-buildpackage.log controleert en controleer of DCMAKE_BUILD_TYPE=RelWithDebInfo zoals hieronder staat:

cd /home/stefan/ceph/obj-x86_64-linux-gnu/src/rocksdb && /usr/bin/cmake -DCMAKE_POSITION_INDEPENDENT_CODE=ON -DWITH_GFLAGS=OFF -DCMAKE_PREFIX_PATH= -DCMAKE_CXX_COMPILER=/usr/bin/c++ -DWITH_SNAPPY=TRUE -DWITH_LZ4=TRUE -Dlz4_INCLUDE_DIRS=/usr/include -Dlz4_LIBRARIES=/usr/lib/x86_64-linux-gnu/liblz4.so -DWITH_ZLIB=TRUE -DPORTABLE=ON -DCMAKE_AR=/usr/bin/ar -DCMAKE_BUILD_TYPE=RelWithDebInfo -DFAIL_ON_WARNINGS=OFF -DUSE_RTTI=1 "-GUnix Makefiles" -DCMAKE_C_FLAGS=-Wno-stringop-truncation "-DCMAKE_CXX_FLAGS='-Wno-deprecated-copy -Wno-pessimizing-move'" "-GUnix Makefiles" /home/stefan/ceph/src/rocksdb

Daadwerkelijke verbeteringen in de prestaties van RocksDB zoals gezien op een van onze clusters

We hebben de opnieuw opgebouwde packages (waarbij ceph-osd het belangrijkste is) op onze storage nodes geïnstalleerd en de resultaten zijn goed.

En om in te zoomen op een specifieke OSD

Als je jezelf ooit in de situatie bevindt waarin je je OSD’s moet comprimeren, staat je een aangename verrassing te wachten. De nieuwe performance packages zorgen voor de volgende drie voordelen:

1. Verbeterde prestaties van RocksDB zelf.
2. Verbeterde schrijfprestaties van OSD’s, wat leidt tot snellere recovery times.
3. Verminderde downtime, resulterend in een kleinere hoeveelheid gegevens die moeten worden hersteld.

Enkele grafieken van servermetrieken om dit te laten zien. Onze procedure voor het comprimeren van OSD’s omvat een gestaggerde shutdown van OSD’s. Zodra alle OSD’s zijn uitgeschakeld, wordt de compressie parallel uitgevoerd (df|grep "/var/lib/ceph/osd" |awk '{print $6}' |cut -d '-' -f 2|sort -n|xargs -n 1 -P 10 -I OSD ceph-kvstore-tool bluestore-kv /var/lib/ceph/osd/ceph-OSD compact).

Debug package disk IOPS (voor)

Performance package disk IOPS (na)

Dit is een node met SATA SSD’s. Een node met NVMe-drives is nog sneller. De tijd voor compactie varieert tussen de 3-5 minuten.

Debug package disk IOPS (voor)

Performance package disk IOPS (na)

Er is een oplopend verschil in OSD compression time tussen SATA SSDs en NVMe drives. Eerder was dit gat niet zo groot vanwege de performance issues van RocksDB. Echter, met de introductie van snellere en lower-latency drives is dit verschil groter geworden. Dit suggereert dat de meest significante performance verbeteringen gezien zullen worden in clusters die zijn uitgerust met snellere drives.

In dit specifieke cluster hebben de performance packages de tijd die nodig is om alle OSD te comprimeren met ongeveer een derde verminderd. Waar dit proces eerder negen en een half uur duurde, duurt het er nu nog maar zes.

Real world performance gains

Hoewel de hoop was dat de prestaties zouden verdubbelen, was dit niet het geval. Desondanks hebben we nog steeds significante verbeteringen gezien in de prestaties. Om gray failure te ontdekken, hebben we virtuele machines draaien in onze cloud om continu (met tussenpozen van 5 minuten) de prestaties te monitoren vanuit de virtuele machine zelf. Een van deze tests is een FIO 4K random write test (single threaded, queue depth of 1).

4K random write op CephFS (voor)

4K random write op CephFS (na)

We hebben ook andere FIO-benchmarks uitgevoerd en de voornaamste voordelen zijn dat de standaardafwijking lager is en dat de tail latencies zijn afgenomen.

Conclusies

• Het loont om performance verification uit te voeren tegen een “well-known” cluster, zoals Mark Nelson heeft gedaan. Dit helpt bij het vroegtijdig identificeren van performance issues, voordat production workloads worden uitgevoerd.
• Clusters die zijn uitgerust met snellere drives hebben meer kans op significante performance verbeteringen vergeleken met clusters met low-performance drives zoals SAS/SATA SSDs of HDDs.

Aanbevelingen en overwegingen

• Bij performance tests is het goed om verschillende implementatiestrategieën te verkennen. Dit kan het testen op bare metal met verschillende besturingssystemen omvatten, gecontaineriseerde omgevingen met upstream containers, en andere ondersteunde implementatiemethoden binnen het Ceph-project.

Oké, dat is in de praktijk misschien veel te veel, maar om problemen als deze op te vangen is het goed om een paar verschillende tests uit te voeren.

• In de loop van de tijd kan het uitvoeren van deze tests leiden tot meer gestandaardiseerde metingen, zoals een “IO/Watt” of “throughput/Watt” ratio, wat gemakkelijker vergelijkingen mogelijk maakt tussen verschillende tests. Misschien kunnen we Ceph-specifieke tests ontwikkelen voor gebruik met tools zoals de Phoronix test-suite?
• Hoewel het in dit specifieke geval geen probleem is, is het het vermelden waard dat er prestatieverminderingen kunnen zijn met betrekking tot specifieke CPU-architecturen. Bijvoorbeeld, het hebben van zowel een ARM64 als een x86-64 prestatiecluster zou discrepanties aan het licht kunnen brengen die verbonden zijn met specifieke build opties. Deze aanpak helpt om dergelijke regressies vroegtijdig op te sporen.

TL;DR

Mark Nelson ontdekte dat voordat de Pull Request (PR) werd samengevoegd, het build process de CMAKE_BUILD_TYPE-opties niet goed doorstuurde naar externe projecten die door Ceph werden gebouwd – in dit geval RocksDB. Voorheen werden packages gebouwd met de RelWithDebInfo-optie om een “performance” release package te bouwen. Hoewel het nog niet geverifieerd is, is het mogelijk dat upstream Ceph Ubuntu-packages hier last van hebben gehad sinds Luminous.

Een Engelse versie van dit blog verscheen eerder op de website van Ceph.

Geschreven door: Stefan Kooman