Page MenuHomePhabricator

Blazegraph write performance tuning
Closed, DeclinedPublic

Description

Those questions about Blazegraph perf tuning were asked on the wikidata mailing list by Thad Guidry. I'm not sure how much of that we've already done:

<quote>
Is the Write Retention Queue adequate?
Is the branching factor for the lexicon indices too large, resulting in a non-linear slowdown in the write rate over tim?
Did you look into Small Slot Optimization?
Are the Write Cache Buffers adequate?
Is there a lot of Heap pressure?
Is the MemoryManager have the maximum amount of RAM it can handle? 4TB?
Is the RWStore handling the recycling well?
Is the SAIL Buffer Capacity adequate?
Are you not using exact range counts where you could be using fast range counts?

Start at the Hardware side first however.
Is the disk activity for writes really low...and CPU is very high? You have identified a bottleneck in that case, discover WHY that would be the case looking into any of the above.

and a 100+ other things that should be looked at that all affect WRITE performance during UPDATES.

https://wiki.blazegraph.com/wiki/index.php/IOOptimization
https://wiki.blazegraph.com/wiki/index.php/PerformanceOptimization
</quote>

Event Timeline

Gehel created this task.Nov 14 2019, 7:40 PM
Restricted Application added a project: Wikidata. · View Herald TranscriptNov 14 2019, 7:40 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Tarrow added a subscriber: Tarrow.Nov 15 2019, 8:34 AM
EBernhardson triaged this task as Medium priority.Nov 21 2019, 8:05 PM
EBernhardson moved this task from needs triage to Current work on the Discovery-Search board.
Sj added a subscriber: Sj.Apr 7 2020, 9:10 PM
Sj added a comment.Apr 7 2020, 9:12 PM

Are these questions answered elsewhere? Seems to not quite fit the phab-task format

Gehel closed this task as Declined.Apr 15 2020, 12:39 PM

Some investigation and tuning was done by Igor already. Our current higher level understanding is that we don't have a write throughput issue, but a combination of read / writes due to the naive updater implementation. We're moving to a streaming updater which will change the context enough that we should revisit this once the change is implemented.