Open wangw-david opened 1 year ago
Hi, short-circuit with k8s is really not supported. Also short-circuit read/write is a deprecated functionality so we would not recommend to use it any more
@jja725 Thanks for your answer, I want to know what conditions are needed for short-circuit reading and writing? I see that the worker and fuse have mounted the same cache directory, both of which use hostNetwork, and the fuse container uses a privileged mode. According to the monitoring data, it is read and write locally.
For short-circuit read and write to be discarded, do you know which version it starts from? I see that the latest 2.9.3 document does not show this.
@Kai-Zhang Hello, Mr. Zhang, I have supplemented the configuration of the worker. If use fluid to deploy alluxio, these are basically the default configurations.
Is your feature request related to a problem? Please describe. I deployed alluxio version 2.9.0 (alluxio/alluxio-dev:2.9.0) with fluid 0.9.1. Then I used 2 nodes A and B, here is my vdbench test configuration:
fsd=fsd1,anchor=/test,width=1,depth=1,files=1,size=10G,openflags=o_direct fwd=fwd1,fsd=fsd,operation=write,xfersize=4M,fileio=sequential,fileselect=sequential,threads=64 fwd=fwd2,fsd=fsd,operation=read,xfersize=4M,fileio=sequential,fileselect=sequential,threads=1 rd=rd1,fwd=fwd1,fwdrate=max,format=(restart,only),maxdata=10G,elapsed=300,warmup=5,interval=1 rd=rd2,fwd=fwd2,fwdrate=max,format=restart,maxdata=10G,elapsed=300,warmup=5,interval=1
Alluixo uses memory(tmpfs, quota 100G) as the tieredstore0, the read strategy is CACHE, and the write strategy is ASYNC_THROUGH, UFS uses s3.
I tested the following scenarios:
ps: I checked the following configuI judge that this scenario uses short-circuit read and write through the following configuration and monitoring items:
config: alluxio.user.short.circuit.enabled=true alluxio.user.short.circuit.preferred=false
monitoring items: Cluster.BytesReadLocal (Type: COUNTER, Value: 12.80GB) Cluster.BytesReadLocalThroughput (Type: GAUGE, Value: 11.19MB/MIN) Cluster.BytesWrittenLocal (Type: COUNTER, Value: 10.00GB) Cluster.BytesWrittenLocalThroughput (Type: GAUGE, Value: 8.74MB/MIN)
In order to solve the situation of low read performance, I added the following configuration: alluxio.user.client.cache.enabled: "true" alluxio.user.client.cache.store.type: MEM alluxio.user.client.cache.size: 1GB alluxio.user.client.cache.page.size: 4MB
Repeat test(use memory as tieredstore0 (quota 100G)):
Both worker and fuse are on node A: readBW: 510.9MB/s, writeBW: 368.05MB/s
The worker is on node A, and the fuse is on node B: readBW: 605.78MB/s, writeBW: 422.69MB/s
Then use nvme as tieredstore0 (quota 100G):
Both worker and fuse are on node A: readBW: 1067MB/s, writeBW: 697.71MB/s
The worker is on node A, and the fuse is on node B: readBW: 1079MB/s, writeBW: 1077.1MB/s
Question1: Why is remote reading and writing faster than short-circuit reading and writing? When I replace the nvme disk for caching, the same result remains, and cross-node reading and writing is higher than short-circuit reading and writing. ps: My network bandwidth is very high, it will not affect the transmission.
Question2: Why is the acceleration effect based on nvme higher than that of memory?
configuration of woker:
Describe the solution you'd like Can someone explain the reason for me? I read that the alluxio documentation says that short-circuit read and write performance is the highest.
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
Urgency Explain why the feature is important
Additional context Add any other context or screenshots about the feature request here.