Inleiding
Samenvatting: In Blog-Aflevering-1 wij hebben RHCS, BlueStore inleiding, lab hardware details, methodologie en de prestaties van de vergelijking tussen de Standaard Cervisia configuratie vs Afgestemd Cervisia configuratie
Dit is de tweede aflevering van de prestatie-blog-serie over RHCS 3.2 BlueStore uitgevoerd op de all-flash-cluster. Er is geen vuistregel om blokgroottes te categoriseren in een kleine, middelgrote en grote categorie. Als zodanig hebben wij 4K aan kleine blokgrootte categorie aangewezen, 8K-64K aan middelgrote en 1M-4M in grote blokgrootte categorie. In deze aflevering leer je over de performance karakterisering van Ceph block storage voor kleine (4K), middelgrote (8K-32K) en grote (1M-4M) block maten over random lees, random schrijf en random lees-schrijf werkbelasting patronen.
samenvatting
- small block 4K workload, geleverd tot 2.2 miljoen random reads, 691k random read-write (70/30) en 463K random write IOPS totdat beperkt door CPU en media contention.
- net als bij de werkbelasting voor kleine blokken, bleken de prestaties van middelgrote blokken beperkt te zijn door de CPU en de media.
- groot blok 4m workload piekprestaties geregistreerd bij 10,9 GB / s voor alle drie de testpatronen, d.w.z. willekeurige lees -, schrijf-en lees-en schrijfmix (70/30) totdat deze beperkt worden door de bandbreedte van het Clientnetwerk.
deel 1: prestaties van kleine blokken (4KB)
Key Takeaways
- Random Read workload toonde 2.2 miljoen IOPS@3ms gemiddelde latency tot bottlenecken door Media verzadiging.
- Random Read-Write (70/30) mix workload toonde 691K IOPS@6ms gemiddelde latency tot bottlenecken door Ceph node CPU resource contention.
- Random Write: 463K IOPS@11ms gemiddelde latency tot bottlenecken door Ceph node CPU resource contention.
samenvatting
in dit deel van de test werd de Ceph block storage interface uitgevoerd met een kleine blokgrootte (4KB) werkbelasting over willekeurig lezen, willekeurig schrijven en willekeurig lezen-schrijven (70/30) mixpatronen. De belangrijkste statistieken vastgelegd tijdens het testen omvat IOPS, gemiddelde, latency, Ceph node CPU en media gebruik.
grafiek-1 toont top-line prestaties voor 4K blokgrootte over verschillende toegangspatronen met 5 all-flash nodes. Als zodanig bleek de maximale prestatie te zijn
- Random Read: 2,2 miljoen IOPS@ 3ms gemiddelde latentie
- Random Read-Write (70/30) Mix: 691K IOPS @6ms gemiddelde latentie
- Random Write: 463K IOPS@11ms gemiddelde latentie
hde CPU-en mediagebruik vastgelegd in graph-2 en graph-3 hielp ons inzicht te krijgen in de knelpunten voor verschillende werkdrukpatronen.
- de willekeurige leesprestaties bleken bottlenecked te zijn door CPU resource contention, maar het mediagebruik bleek ook aan de hogere kant te zijn. Als zodanig hebben we extra Ceph nodes toegevoegd (CPU en media) de willekeurige leesprestaties hadden hoger kunnen worden geschaald.
- voor zowel random write als random read-write (70/30) mix werd de performance geblokkeerd door een hoger CPU-verbruik. Interessant genoeg op hetzelfde moment media had genoeg Reserve doorvoer die ongebruikt bleef vanwege het gebrek aan rekenkracht. Als zodanig had een hogere CPU-kerntoewijzing naar Ceph-besturingssystemen hogere prestaties kunnen leveren voor random write & random read-write mix workloads.
het gebruik van het OSD-gegevensapparaat (P4500 NVMe) bleef onder de 50%, het Intel Optane p4800-apparaat dat metadata van BlueStore WAL en Rocksdb hostte, bleek zeer druk te zijn@90%. De bluestore_min_alloc_size_ssd parameter werd ingesteld op 16KB, dus alle schrijft onder 16KB werden uitgesteld, het schrijven gaat eerst in de wal apparaat en vervolgens asynchroon wordt geschreven naar de OSD gegevens, vandaar de Optane p4800 apparaat had geabsorbeerd de schrijft voor alle OSD ‘ s op de host. Ondanks het hoge gebruik op de RocksDB / WAL-apparaat, hebben we geen tekenen van betwisting op de P4500 OSD-gegevensapparaat gezien. Maar op basis van deze ervaring raden we niet aan om meer dan 7 x P4500 NVMe-apparaten achter een enkele Intel Optane P4800 voor WAL/RocksDB te plaatsen.
grafiek 2
grafiek 3
een andere interessante test die we hebben uitgevoerd was client sweep test, waar we lineair opgeschaald-up van het aantal klanten vanaf 20 en tot 140. Toen we de belasting van de klant verhoogden, zagen we lineaire prestatieverbetering totdat we op CPU-congestie op Ceph OSD raakten. Met 100 klanten hebben we waargenomen ~ 445K geaggregeerde 4K schrijven IOPS. Na dit punt systeem resources congestie resulteerde in hoge staart latencies. Intel Optane gebruikt als metadata hielp om latency piek te absorberen met een groot aantal parallelle clients, als zodanig gemiddelde latency bleef onder 40ms.
G
deel 2: Prestaties van gemiddelde blokgrootte
Key afhaalmaaltijden
- totdat de prestaties werden geblokkeerd door CPU-en mediaverzadiging, leverden 5 All-flash Ceph nodes ~1,8 miljoen willekeurige reads, ~636K random readwrite (70/30) en ~410K random write IOPS.
- om de prestaties te schalen, moesten extra Ceph OSD-knooppunten worden toegevoegd aan het bestaande Ceph-cluster.
samenvatting
In de volgende grafieken hebben we geprobeerd verschillende gegevenspunten weer te geven, zoals IOPS, gemiddelde latency, tail latency, Ceph node CPU en mediagebruik. En al deze over een bereik van blokgrootte dwz van 4K tot 64K voor random write, random read en random read-write (70/30) mix.
enkele interessante gegevenspunten omvatten
- zoals verwacht vertoonden kleine blokgroottes de hoogste IOPS en lagere gemiddelde en staart latenties, vergeleken met middelgrote blokgroottes. Als zodanig merkten we ~1,8 miljoen, ~636K, ~410K IOPS voor Random ReadWrite Mix en Random write workload respectievelijk.
- hoog gebruik werd waargenomen op CPU en media apparaten op Ceph OSD nodes. Het gebruik bleek zo hoog als ~90% en ~80% respectievelijk voor CPU en media respectievelijk. Als zodanig hadden de prestaties kunnen toenemen hebben we Ceph OSD nodes toegevoegd aan het bestaande Ceph cluster.
G
Deel 3: De Grote Grootte van het Blok Prestaties
Key Takeaways
- Groot blok 4M prestaties piekte op 10.9 GB / s voor willekeurige lezen, schrijven en lezen-schrijven (70/30) mix.
- het Clientnetwerk bleek de beperkende factor te zijn en een knelpunt voor de prestaties te veroorzaken.
- de prestaties hadden hoger kunnen zijn, hadden we meer clientknooppunten of Grotere netwerkpijpen gehad.
samenvatting
alle verschillende patronen die we hebben getest, d.w.z. willekeurige lees -, schrijf – en lees-schrijfmix (70/30) voor grote blokgrootte 4m werkbelasting, aangevuld met 10,9 GB/s geaggregeerde doorvoer. Het clientnetwerk bleek de beperkende factor te zijn die de bottleneck van de prestaties veroorzaakte. Anders dan netwerk de tweede meest gebruikte bron was media, echter, het had genoeg ruimte beschikbaar om meer prestaties te leveren, als het netwerk was niet de bottleneck.
G
volgende
voortzetting van de benchmarking blog serie, in de volgende paragraaf, zal de resultaten in verband met RHCS 3.2 schaalbaarheidstesten uitleggen. Het beantwoorden van een aantal belangrijke vragen zoals “hoe verandert de prestaties door te gaan van 3 knooppunt cluster naar 5 knooppunten”. Blijf Kijken.