Comments (4)
Testing inside virtual machine might be ok too. But looks like the seq write inside virtual machine is capped at 10k somehow. Is it the max that VM can achieve natively?
I believe it may be limited by my laptop's capabilities. I set up the cluster using Multipass, and there wasn't a way to configure that.
from longhorn.
Ref PR: longhorn/longhorn-engine#1104
from longhorn.
Verified on v1.6.x-head 20240508
- longhorn
v1.6.x-head
46706be - longhorn-engine
v1.6.x-head
longhorn/longhorn-engine@4f53092
The test steps
#8436 (comment)
Result Passed
- In the AWS EC2 t2.xlarge environment, I did not observe significant differences in IOPS.
Therefore, I have decided to build up a cluster in a local virtual machine to conduct this test.
The test result is as follows.
v1.6.1
=========================
FIO Benchmark Summary
For: test_device
CPU Idleness Profiling: disabled
Size: 30G
Quick Mode: disabled
=========================
IOPS (Read/Write)
Random: 10,329 / 4,684
Sequential: 17,677 / 10,204
Bandwidth in KiB/sec (Read/Write)
Random: 413,252 / 141,958
Sequential: 461,723 / 170,358
Latency in ns (Read/Write)
Random: 431,773 / 553,568
Sequential: 357,682 / 547,949
v1.6.x-head
=========================
FIO Benchmark Summary
For: test_device
CPU Idleness Profiling: disabled
Size: 30G
Quick Mode: disabled
=========================
IOPS (Read/Write)
Random: 14,329 / 6,573
Sequential: 22,396 / 10,423
Bandwidth in KiB/sec (Read/Write)
Random: 513,981 / 153,945
Sequential: 536,158 / 169,366
Latency in ns (Read/Write)
Random: 392,363 / 527,421
Sequential: 343,545 / 515,456
Here is the summary table
IOPS (Random Read/Write) | IOPS (Sequential Read/Write) | |
---|---|---|
v1.6.1-1st | 10,329 / 4,684 | 17,677 / 10,204 |
v1.6.x-head-1st | 14,329 / 6,573 | 22,396 / 10,423 |
Bandwidth KiB/sec (Random Read/Write) | Bandwidth KiB/sec (Sequential Read/Write) | |
---|---|---|
v1.6.1-1st | 413,252 / 141,958 | 461,723 / 170,358 |
v1.6.x-head-1st | 513,981 / 153,945 | 536,158 / 169,366 |
Latency ns (Random Read/Write) | Latency ns (Sequential Read/Write) | |
---|---|---|
v1.6.1-1st | 431,773 / 553,568 | 357,682 / 547,949 |
v1.6.x-head-1st | 392,363 / 527,421 | 343,545 / 515,456 |
Hi @PhanLe1010
I think we can close this ticket. If there are any concerns regarding the test results, please let me know.
from longhorn.
Hi @roger-ryao
Thank you for testing!
In the AWS EC2 t2.xlarge environment, I did not observe significant differences in IOPS.
t2.xlarge is using EBS with burst performance to 3,000 IOPS. This is too slow and will not expose the improvement. Please use the ec2 with instance store (attached nvme) like c5d.2xlarge
Therefore, I have decided to build up a cluster in a local virtual machine to conduct this test.
Testing inside virtual machine might be ok too. But looks like the seq write inside virtual machine is capped at 10k somehow. Is it the max that VM can achieve natively?
from longhorn.
Related Issues (20)
- [BUG] Fix longhorn-manager `TestCleanupRedundantInstanceManagers` HOT 6
- [BUG] When revision counter is disabled, the engine might choose a replica with a smaller head size to be the source of truth for auto-salvage HOT 1
- [BACKPORT][v1.5.6][BUG] When revision counter is disabled, the engine might choose a replica with a smaller head size to be the source of truth for auto-salvage HOT 1
- [BACKPORT][v1.6.3][BUG] When revision counter is disabled, the engine might choose a replica with a smaller head size to be the source of truth for auto-salvage HOT 1
- [FEATURE] Supporting SYNCHRONIZE_CACHE and SYNCHRONIZE_CACHE_16 command in tgt
- [TEST][FEATURE] Supporting SYNCHRONIZE_CACHE and SYNCHRONIZE_CACHE_16 command in tgt
- [TEST][IMPROVEMENT] Disable revision counter by default HOT 1
- [FEATURE] v2 volume supports snapshot checksum
- [TEST][FEATURE] v2 volume supports snapshot checksum
- [BUG] `toomanysnapshots` UI message displays incorrect snapshot count
- [FEATURE] Smarter volume scheduling
- [BACKPORT][v1.6.3][BUG] Fix longhorn-manager `TestCleanupRedundantInstanceManagers` HOT 1
- [BACKPORT][v1.6.3][IMPROVEMENT] Restore Latest Backup should be applied with BackingImage name value
- [BACKPORT][v1.6.3][IMPROVEMENT] `toomanysnapshots` UI element not prominent enough to prevent runaway snapshots HOT 1
- [IMPROVEMENT] Revisit gRPC client and proxy functions design
- [IMPROVEMENT] Improve the rebuilding speed of volume with data pattern 4k_data-4k_hole-4k_data-4k_hole-...
- [BACKPORT][v1.6.3][BUG] instance-manager is stuck at starting state
- [BUG] Unable to attach or mount volumes after systemctl restart k3s HOT 2
- [BUG]Upgrade from 1.4.2 to 1.5.5 fails. longhorn-manager pods are stuck at init HOT 6
- [FEATURE] Upload volumes
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from longhorn.