Per today's Search Platform triage meeting, I'm creating this ticket to specifically test hardware optimizations that could speed up the import process. This is in contrast to T336443 , where we are trying to figure out why a data reload is so much slower for our newest R450 chassis.
AC:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T241128 EPIC: Reduce the time needed to do the initial WDQS import | |||
| Open | None | T351662 Test hardware-based performance optimizations for WDQS import |
I/O testing: We'll test I/O wdqs1014 (R440) and wdqs1021 (R450) using fio. This Wikitech page might be useful
Hey @bking
I did some experiments a few years back (2021)
You can find my writeup from back then https://addshore.com/2021/02/testing-wdqs-blazegraph-data-load-performance/
This was mainly trying different Java and Blazegraph options to see how things changed the behaviour while loading data, but I also tried a bunch of different GCP hardware including different disk setups.
Thanks @Addshore , this is a wealth of great info!
Your observation
CPU clock speed makes a big difference with the first 10 batches of RDF taking 2 hours less on a c2-standard-8 3.1-3.8 Ghz machine instead of a n1-standard-8 2.2-3.7 Ghz machine. This was a reduction from 6 hours to 4 hours.
Seems to line up with the observations from T336443 . Will get a data-reload started on wdqs1024 and report back.
@dr0ptp4kt mentioned that it's possible to limit the scope of a data reload. Specifically, it's possible to execute this against a single munged file instead of completing a whole reload. My guess is this can be done fairly easily with the current loadData script . Tagging this for further discussion.
@Addshore has completed an extensive battery of tests related to data reloading. Any benchmarking we do should probably follow his approach.