Client客户端问题

內存及性能优化相关

Clint客户端占用内存过高，超过了2GB，对其他业务影响过大
离线修改：在配置文件中设置readRate和writeRate参数，重启客户端，详情请参考
在线修改：http://{clientIP}:{profPort} /rate/set?write=800&read=800

挂载问题

支持子目录挂载吗? 支持。配置文件中设置subdir即可
挂载失败有哪些原因？挂载失败后，输出以下信息

... err(readFromProcess: sub-process: fusermount: exec: "fusermount": executable file not found in $PATH)
```	

查看是否已安装fuse，如果没有则安装

```bash
rpm –qa|grep fuse
yum install fuse
```	

检查挂载目录是否存在
检查挂载点目录下是否为空
检查挂载点是否已经umount
检查挂载点状态是否正常，若挂载点 mnt 出现以下信息,需要先umount，再启动client

```bash
ls -lih
ls: cannot access 'mnt': Transport endpoint is not connected
total 0
6443448706 drwxr-xr-x 2 root root 73 Jul 29 06:19 bin
 811671493 drwxr-xr-x 2 root root 43 Jul 29 06:19 conf
6444590114 drwxr-xr-x 3 root root 28 Jul 29 06:20 log
         ? d????????? ? ?    ?     ?            ? mnt
 540443904 drwxr-xr-x 2 root root 45 Jul 29 06:19 script

检查配置文件是否正确，Master地址、volume name等信息如果以上问题都不存在，通过client error日志定位错误，看是否是MetaNode或者Master服务导致的挂载失败

IO问题

IOPS过高导致客户端占用内存超过3GB甚至更高，有没有办法限制IOPS? 通过修改客户端rate limit来限制客户端响应io请求频率。查看当前iops：

curl -v "http://192.168.0.121:15410/rate/get"
*   Trying 192.168.0.121:15410...
* Connected to 192.168.0.121 (192.168.0.121) port 15410 (#0)
> GET /rate/get HTTP/1.1
> Host: 192.168.0.121:15410
> User-Agent: curl/7.71.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Thu, 20 Apr 2023 06:21:17 GMT
< Content-Length: 53
< Content-Type: text/plain; charset=utf-8
< 
read: 9223372036854775807
write: 9223372036854775807

设置iops，默认值-1代表不限制iops

curl -v "http://192.168.0.121:15410/rate/set?write=800&read=800"
*   Trying 192.168.0.121:15410...
* Connected to 192.168.0.121 (192.168.0.121) port 15410 (#0)
> GET /rate/set?write=800&read=800 HTTP/1.1
> Host: 192.168.0.121:15410
> User-Agent: curl/7.71.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Thu, 20 Apr 2023 06:22:42 GMT
< Content-Length: 69
< Content-Type: text/plain; charset=utf-8
< 
Set read rate to 800 successfully
Set write rate to 800 successfully

ls等操作io延迟过高? 因为客户端读写文件都是通过http协议，请检查网络状况是否健康检查是否存在过载的MetaNode，MetaNode进程是否hang住，可以重启MetaNode，或者扩充新的MetaNode到集群中并且将过载MetaNode上的部分MetaNode下线以缓解MetaNode压力

多客户端并发读写强一致

不是。UDB-TO放宽了POSIX一致性语义，它只能确保文件/目录操作的顺序一致性，并没有任何阻止多个客户写入相同的文件/目录的leasing机制。这是因为在容器化环境中，许多情况下不需要严格的POSIX语义，即应用程序很少依赖文件系统来提供强一致性保障。并且在多租户系统中也很少会有两个互相独立的任务同时写入一个共享文件因此需要上层应用程序自行提供更严格的一致性保障。

能否直接杀死client进程

不建议，最好走umount流程，umount后，client进程会自动停止。