Huge downloading performance gap between s3g and ozone cli #9314
Replies: 5 comments 5 replies
-
|
Hi @Lucas12138 are you still running the Ozone 1.4.x line? This sounds similar to #8946. Did you try the answer there in this case as well? |
Beta Was this translation helpful? Give feedback.
-
|
hdds.ratis.raft.server.watch.timeout=180s By the way, this value is too large and can be reduced to 30s (see HDDS-10972). |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
"ozone.s3g.client.buffer.size": "4KB" // change this to 4MB. |
Beta Was this translation helpful? Give feedback.
-
|
@Lucas12138 has there been any update on this? Did setting the prop as suggested by @ChenSammi help? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi community,
We're usually using s3 APIs to access our ozone clusters (our clusters are using EC) and we recently detected a performance drop after switch pvc providers. So, we did some deep dive and found that the
s3g speed: 16.2MB/s (observed from a manually created pod within the same namespace with s3 cli)
ozone speed: 823MB/s (observed from om node via ozone cli)
There's a huge downloading performance gap if we go through s3g.
What are the common bottlenecks that we should look out for our s3g? We're wondering if we need to fine tune some configs? I checked the cpu/mem/io seems none of them are bottlenecked
Our s3g settings currently are:
Beta Was this translation helpful? Give feedback.
All reactions