Replies: 1 comment
-
From discussion with @pugachAG - we also tried more threads (numjobs) but parallelism for persistent SSD stayed at 8. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The goal is to analyse raw SSD performance on different platforms. This is important when reasoning and benchmarking neard storage.
In the context of storage we are interested in random read latency since that is the access pattern behind rocksdb
get
operations forState
column. Also we are interested in the max number of parallel reads that can be done without compromising latency, which is important for background trie reads to work.Related work: Low level storage benchmark results.
Setup
fio tool is used to execute random reads workload.
Data is prepared with the following config:
size
is adjusted depending on the SSD size to make it as close to being full as possible.The following config is used to execute the benchmark:
GCP persistant SSD
Persistent SSD is currently the default solution for rocksdb data (
~/.near/data
).The latency seems to be pretty unstable and I got different results for when running the benchmark on different days.
Result 1
Result 2
GCP local SSD
GCP allows using local SSD which suppose to have better performance than the persistent one.
Benchmark result shows better latency when
numjobs=1
, but for some reason it performs much worse with parallel requests.Result with numjobs=1
Result with numjobs=4
Bare metal SSD
MacBook Pro 2021 laptop with 512GB SSD was used to test SSD performance in bare metal setup.
Result
Results Summary
Beta Was this translation helpful? Give feedback.
All reactions