docker-compose方式部署，cpu使用率持续很高

[随风而去]

1.版本号：v3.6.0
2.部署方式：docker-compose方式部署，其中要使用全文索引，故也部署了Raft listener

之前使用官网提供的docker-compose方式成功部署了图数据库，后续要调整服务器文件夹位置，于是删除了之前的pod，修改了挂载位置，把之前的挂载文件移动到了新的挂载位置，重新执行docker-composs.yml文件，pod重新创建，图数据库安装成功，但查询速度非常慢，很简单的查询时间可能都要十多秒，通过top命令查看服务器状态，nebula-storaged对cpu的使用率大概1000%左右，而且持续时间很久了，图数据库总数据量大概十多万条。
查看listener服务日志文件，持续输出类似下述信息：

The tag schema 8 not found in space 3
E20240409 01:59:36.968433   533 MetaClient.cpp:2093] The tag schema 812 not found in space 1
E20240409 01:59:36.968566   533 MetaClient.cpp:2115] The edge schema 825 not found in space 1
E20240409 01:59:55.236948   514 MetaClient.cpp:2093] The tag schema 813 not found in space 1
E20240409 02:00:12.045121   493 MetaClient.cpp:2093] The tag schema 812 not found in space 1
E20240409 02:00:12.045251   493 MetaClient.cpp:2093] The tag schema 813 not found in space 1
E20240409 02:00:12.045289   493 MetaClient.cpp:2115] The edge schema 825 not found in space 1
E20240409 02:00:15.046815   493 ESClient.cpp:141] curl error(28):Timeout was reached
E20240409 02:00:15.046869   493 ESListener.cpp:65] curl error(28):Timeout was reached
E20240409 02:00:16.046973   493 MetaClient.cpp:2093] The tag schema 812 not found in space 1
E20240409 02:00:16.047037   493 MetaClient.cpp:2093] The tag schema 813 not found in space 1
E20240409 02:00:16.047049   493 MetaClient.cpp:2115] The edge schema 825 not found in space 1
E20240409 02:00:19.049275   493 ESClient.cpp:141] curl error(28):Timeout was reached
E20240409 02:00:19.049324   493 ESListener.cpp:65] curl error(28):Timeout was reached
E20240409 02:00:20.049425   493 MetaClient.cpp:2093] The tag schema 812 not found in space 1

请问上述原因是什么，及解决办法

[steam]

@随风而去

通过top命令查看服务器状态，nebula-storaged对cpu的使用率大概1000%左右

把机器配置贴下。

@随风而去

把之前的挂载文件移动到了新的挂载位置，重新执行docker-composs.yml文件，pod重新创建，图数据库安装成功

这是做了一个挂载迁移，之前的数据和 schema 没有变动是吧。

[随风而去]

是的 之前的数据没有动，文件夹直接复制过去的

[steam]

报错的信息这堆都是 meta 信息没有找到，应该是不能单纯地复制文件的（我猜可能 meta 关联了挂在盘的信息）。估计是需要重建图空间和重新导入数据。

[随风而去]

cpu信息：
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 46 bits physical, 57 bits virtual
Byte Order: Little Endian
CPU(s): 144
On-line CPU(s) list: 0-143
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R) Platinum 8352V CPU @ 2.10GHz
CPU family: 6
Model: 106
Thread(s) per core: 2
Core(s) per socket: 36

内存信息：
total used free shared buff/cache available
Mem: 503Gi 65Gi 271Gi 2.1Gi 166Gi 432Gi
Swap: 0B 0B 0B

[随风而去]

可是我通过studio查看图空间，以及图空间下的schema都是正常的，通过cypher查询数据也是正常的，只是查询速度非常慢

[steam]

查询很慢的话，你可以贴下查询语句，以及根据这个帖子，把相关的信息贴一贴：关于性能有调优的你应该知道的非技术姿势

[随风而去]

就很普通的查询语句，而且数据量一共才两万多条，这个太反常了
主要是cpu一直处于高负荷状态，不太明白这部分算力主要是在做什么，不知道是不是把数据加载到内存啥的，而且应该是没成功的

[随风而去]

metad报错信息如下：
Log line format: [IWEF]yyyymmdd hh:mm:ss.uuuuuu threadid file:line] msg
E20240409 02:50:31.015094 252 Serializer.h:43] Thrift serialization is only defined for structs and unions, not containers thereof. Attemping to deserialize a value of type std::vector<nebula::meta::cpp2::ServiceClient>.

[steam]

match v return v limit n 这种语句尽量不要用，因为可能会大量捞取数据，导致资源消耗。

[随风而去]

发现由于nebula-storaged下的data/wal文件夹下含有大量（10个G）的文件，这些文件导致数据加载速度非常慢，CPU长时间处于高强度运转，将wal文件夹删除掉重新挂载就好了，目前只发现了配置文件中 wal_ttl参数配置wal下文件的存活时间（默认为4个小时，单个文件不大，但数量很大，整个下来差不多六七百个文件），请问还有其他改进方案吗，以后此类挂载情形是不是只能手动删除wal文件

[steam]

你可以手动调小 wal 的过期时间，看看会不会好点。