introduktion
Recap: i blogg Episode-1 Vi har täckt RHCS, BlueStore introduktion, lab hårdvara detaljer, benchmarking metodik och prestanda jämförelse mellan Standard Ceph konfiguration vs trimmad Ceph konfiguration
Detta är det andra avsnittet av Performance Blog-serien på rhcs 3.2 bluestore som körs på All-Flash-klustret. Det finns ingen tumregel att kategorisera blockstorlekar i en liten, medelstor och stor kategori. Som sådan har vi utsett 4K till liten blockstorlekskategori, 8K-64K till medium och 1m-4m till stor blockstorlekskategori. I det här avsnittet lär du dig om prestandakarakterisering av Ceph-blocklagring för små (4k), medelstora (8K-32k) och stora (1m-4m) blockstorlekar över slumpmässiga Läs -, slumpmässiga skriv-och slumpmässiga arbetsbelastningsmönster.
sammanfattning
- litet block 4K arbetsbelastning, levereras upp till 2.2 miljoner slumpmässiga läsningar, 691k slumpmässig läs-skriv (70/30) och 463k slumpmässig skriv IOPS tills begränsad av CPU och media påstående.
- i likhet med små block arbetsbelastning, medium block prestanda befanns begränsas av CPU och media påstående.
- stort block 4m arbetsbelastning topprestanda inspelad vid 10.9 GB/s för alla tre testmönster, dvs slumpmässig läs, skriv och läs-skriv (70/30) blanda tills det begränsas av klientens nätverksbandbredd.
Del-1: liten blockstorlek (4KB) prestanda
viktiga hämtställen
- Random läsa arbetsbelastning visade 2.2 miljoner IOPS@3ms Genomsnittlig latens tills flaskhalsad av mediemättnad.
- slumpmässig Läs-skriv (70/30) mix arbetsbelastning visade 691K IOPS@6ms Genomsnittlig latens tills flaskhalsad av Ceph nod CPU resurs påstående.
- Random skriv: 463k IOPS@11ms Genomsnittlig latens tills flaskhalsad av Ceph nod CPU resurs påstående.
sammanfattning
i denna del av testningen utövades Ceph-blocklagringsgränssnittet med liten blockstorlek (4KB) arbetsbelastning över slumpmässig läsning, slumpmässig skrivning och slumpmässig läs-skriv (70/30) mixmönster. De viktigaste mätvärdena som fångats under testningen inkluderar IOPS, average, latency, Ceph node CPU och media utilization.
Graph – 1 visar Top-line prestanda för 4K blockstorlek över olika åtkomstmönster med 5 ALL-flash noder. Som sådan befanns den maximala prestandan vara
- slumpmässig läsning: 2,2 miljoner IOPS@ 3ms Genomsnittlig latens
- slumpmässig Läs-skriv (70/30) blanda: 691k IOPS @6ms Genomsnittlig latens
- slumpmässig skrivning: 463k IOPS@11ms Genomsnittlig latens
HPROCESSOR-och medieutnyttjandet som fångats i graph – 2 och graph-3 hjälpte oss att förstå flaskhalsarna för olika arbetsbelastningsmönster.
- den slumpmässiga läsprestandan visade sig vara flaskhalsad av CPU-resurskonflikt, men medieutnyttjandet visade sig också vara på den högre sidan. Som sådan har vi lagt till ytterligare Ceph-noder (CPU och media) den slumpmässiga läsprestandan kunde ha skalats högre.
- för både random write och random read-write (70/30) mix, prestandan flaskhals av högre CPU-konsumtion. Intressant på samma gång media hade tillräckligt med extra genomströmning som förblev oanvänd på grund av bristen på beräkningskraft. Som sådan kunde högre CPU-kärnallokering till Ceph OSDs ha levererat högre prestanda för slumpmässig skrivning & slumpmässig läs-skrivmix arbetsbelastning.
OSD data device (P4500 NVMe) utnyttjande stannade under 50% utnyttjande, Intel Optane P4800 enhet som var värd BlueStore WAL och Rocksdb metadata befanns vara mycket upptagen@90%. Bluestore_min_alloc_size_ssd-parametern var inställd på 16KB, varför alla skrivningar under 16KB uppskjutits, skrivningen går först in i WAL-enheten och skrivs sedan asynkront till OSD-data, varför Optane P4800-enheten hade absorberat skrivningarna för alla OSDs på värden. Trots det höga utnyttjandet på RocksDB/WAL-enheten har vi inte sett några tecken på strid på P4500 OSD-dataenheten. Men baserat på denna erfarenhet skulle vi inte rekommendera att lägga mer än 7 x P4500 NVMe-enheter bakom en enda Intel Optane P4800 för WAL/RocksDB.
Diagram 2
Diagram 3
ett annat intressant test vi körde var client sweep test, där vi har linjärt skalat upp antalet kunder som börjar 20 och upp till 140. När vi ökade klientbelastningen observerade vi linjär prestandaförbättring tills vi träffade CPU-trängsel på Ceph OSD. Med 100 kunder har vi observerat ~445K aggregerad 4K skriv IOPS. Efter denna punkt systemresurser trängsel resulterade i hög svans latenser. Intel Optane används som metadata bidragit till att absorbera latens spik med ett stort antal parallella klienter, som sådan genomsnittlig latens stannade under 40ms.
G
del-2: Medium blockstorlek prestanda
viktiga Takeaways
- tills prestandan flaskhalsades av CPU och mediemättnad, levererade 5 ALL-flash Ceph-noder ~1,8 miljoner slumpmässiga läsningar, ~636K slumpmässig readwrite (70/30) och ~410k slumpmässig skriv IOPS.
- för att skala prestandan måste ytterligare Ceph OSD-noder läggas till i det befintliga Ceph-klustret.
sammanfattning
i följande diagram har vi försökt att representera olika datapunkter som IOPS, Genomsnittlig latens, svanslatens, Ceph-nod CPU och mediautnyttjande. Och alla dessa över en rad blockstorlek, dvs från 4k upp till 64K för slumpmässig skrivning, slumpmässig läsning och slumpmässig läs-skriv (70/30) mix.
några intressanta datapunkter inkluderar
- som förväntat visade små blockstorlekar högsta IOPS och lägre genomsnittliga och svans latenser jämfört med medelstora blockstorlekar. Som sådan observerade vi ~1,8 miljoner, ~636K, ~410K IOPS för slumpmässig läsning, slumpmässig ReadWrite Mix respektive slumpmässig skrivbelastning.
- högt utnyttjande observerades på CPU-och medieenheter på Ceph OSD-noder. Utnyttjandet befanns vara så högt som ~90% respektive ~80% för CPU respektive media. Som sådan kunde prestandan ha ökat har vi lagt till Ceph OSD-noder till det befintliga Ceph-klustret.
G
del-3: Stor blockstorlek prestanda
viktiga Takeaways
- stort block 4m prestanda toppade vid 10.9 GB/s för slumpmässig läs, skriv och läs-skriv (70/30) blanda.
- Klientnätverk visade sig vara den begränsande faktorn och orsakade en prestandaflaskhals.
- prestandan kunde ha varit högre, har vi antingen haft fler klientnoder eller större nätverksrör.
sammanfattning
alla de olika mönster som vi har testat, dvs slumpmässig läs -, skriv-och läs-skriv (70/30) mix för stor blockstorlek 4m arbetsbelastning toppad vid 10.9 GB/s aggregerad genomströmning. Klientnätverket visade sig vara den begränsande faktorn som orsakade prestandaflaskhalsen. Annat än nätverk den näst mest använda resursen var media, men det hade tillräckligt med utrymme tillgängligt för att leverera mer prestanda, om nätverket inte var flaskhalsen.
G
upp nästa
fortsatt benchmarking blogserie, i nästa avsnitt, kommer att förklara resultaten i samband med RHCS 3.2 skalbarhet testning. Svara på några viktiga frågor som”Hur förändras prestanda genom att gå från 3 nodkluster till 5 noder”. Håll Ögonen Öppna.