我今天尝试通过清理系统缓存的方式，看能否解决这个问题，尝试了后发现：
steam
2024 年4 月 7 日 02:41
3
你压测的时候，把 auto-compaction 关了么？如果开启的话，可能 compaction 在你压测的时候启动了，然后占用了大量内存。
请问下这个怎么关闭呢？我应当没改什么配置，都是默认的
另外，我清明跑了几天，又发现了几个问题，可以麻烦帮忙解答下吗？
每5秒执行完全一模一样的查询操作，偶现查询失败，storaged报错：
E20240404 05:27:18.828509 47 Serializer.h:43] Thrift serialization is only defined for structs and unions, not containers thereof. Attemping to deserialize a value of type `nebula::HostAddr`.
同上，执行完全相同操作，偶现查询失败，graphd报错语法错误？比如说这个：
E20240404 09:42:37.358704 25 QueryInstance.cpp:151] SyntaxError: Unterminated string: near `S '9', query: USE `test`;
在有大量数据写入时，studio上面统计点和边的数量（40万点，700W边），storaged内存一下增加了3G，达到了4.9G，且之后无下降，并且由于还存在着查询操作，内存依然持续上涨，达到5G后，被K8s OOM kill掉了
公司最近要要孵化新项目，TL硬要引入nebula图数据库，我现在在弄预研，头都大了，给各位爹磕头了，麻烦帮忙解答下，我看社区好多帖子都有我类似的问题，但都没有最终结论
贴一下配置文件：
--daemonize=true
--pid_file=pids/nebula-graphd.pid
--enable_optimizer=true
--default_charset=utf8
--default_collate=utf8_bin
--heartbeat_interval_secs=10
--local_config=true
--log_dir=logs
--minloglevel=0
--v=0
--logbufsecs=0
--redirect_stdout=true
--stdout_log_file=graphd-stdout.log
--stderr_log_file=graphd-stderr.log
--stderrthreshold=3
--timestamp_in_logfile_name=true
--accept_partial_success=false
--max_allowed_query_size=4194304
--meta_server_addrs=127.0.0.1:9559
--local_ip=127.0.0.1
--listen_netdev=any
--port=9669
--reuse_port=false
--listen_backlog=1024
--client_idle_timeout_secs=28800
--session_idle_timeout_secs=28800
--num_accept_threads=1
--num_netio_threads=0
--num_max_connections=0
--num_worker_threads=0
--ws_ip=0.0.0.0
--ws_http_port=19669
--storage_client_timeout_ms=60000
--enable_record_slow_query=true
--slow_query_limit=100
--slow_query_threshold_us=200000
--ws_meta_http_port=19559
--enable_authorize=true
--auth_type=password
--system_memory_high_watermark_ratio=0.8
--enable_audit=false
--audit_log_handler=file
--audit_log_file=./logs/audit/audit.log
--audit_log_strategy=synchronous
--audit_log_max_buffer_size=1048576
--audit_log_format=xml
--audit_log_es_address=
--audit_log_es_user=
--audit_log_es_password=
--audit_log_es_batch_size=1000
--audit_log_exclude_spaces=
--audit_log_categories=login,exit
--enable_space_level_metrics=false
--enable_experimental_feature=false
--ng_black_box_switch=false
--ng_black_box_home=black_box
--ng_black_box_dump_period_seconds=5
--ng_black_box_file_lifetime_seconds=1800
--max_sessions_per_ip_per_user=300
--memory_tracker_limit_ratio=0.8
--memory_tracker_untracked_reserved_memory_mb=50
--memory_tracker_detail_log=false
--memory_tracker_detail_log_interval_ms=60000
--memory_purge_enabled=true
--memory_purge_interval_seconds=10
--max_job_size=1
--min_batch_size=8192
--optimize_appendvertices=false
--path_batch_size=10000
--enable_http2_routing=false
--stream_timeout_ms=30000
--enable_ssl=false
--enable_graph_ssl=false
--enable_meta_ssl=false
--cert_path=certs/server.crt
--key_path=certs/server.key
--ca_path=certs/ca.crt
--ca_client_path=certs/ca.crt
--password_path=certs/password
--ssl_watch_path=certs
metad：
--daemonize=true
--pid_file=pids/nebula-metad.pid
--log_dir=logs
--minloglevel=0
--v=0
--logbufsecs=0
--redirect_stdout=true
--stdout_log_file=metad-stdout.log
--stderr_log_file=metad-stderr.log
--stderrthreshold=3
--timestamp_in_logfile_name=true
--meta_server_addrs=127.0.0.1:9559
--local_ip=127.0.0.1
--port=9559
--ws_ip=0.0.0.0
--ws_http_port=19559
--ws_storage_http_port=19779
--data_path=data/meta
--minimum_reserved_bytes=268435456
--default_parts_num=10
--default_replica_factor=3
--heartbeat_interval_secs=10
--agent_heartbeat_interval_secs=60
--rocksdb_wal_sync=true
--ng_black_box_switch=false
--ng_black_box_home=black_box
--ng_black_box_dump_period_seconds=5
--ng_black_box_file_lifetime_seconds=1800
--enable_ssl=false
--enable_meta_ssl=false
--cert_path=certs/server.crt
--key_path=certs/server.key
--ca_path=certs/ca.crt
--ca_client_path=certs/ca.crt
--password_path=certs/password
--ssl_watch_path=certs
storaged：
--daemonize=true
--pid_file=pids/nebula-storaged.pid
--local_config=true
--log_dir=logs
--minloglevel=0
--v=0
--logbufsecs=0
--redirect_stdout=true
--stdout_log_file=storaged-stdout.log
--stderr_log_file=storaged-stderr.log
--stderrthreshold=3
--timestamp_in_logfile_name=true
--meta_server_addrs=127.0.0.1:9559
--local_ip=127.0.0.1
--port=9779
--ws_ip=0.0.0.0
--ws_http_port=19779
--heartbeat_interval_secs=10
--raft_heartbeat_interval_secs=30
--raft_rpc_timeout_ms=500
--wal_ttl=14400
--snapshot_send_files=true
--data_path=data/storage
--minimum_reserved_bytes=268435456
--rocksdb_batch_size=4096
--rocksdb_block_cache=4096
--disable_page_cache=false
--engine_type=rocksdb
--rocksdb_compression=lz4
--rocksdb_compression_per_level=
--enable_rocksdb_statistics=false
--rocksdb_stats_level=kExceptHistogramOrTimers
--enable_rocksdb_prefix_filtering=true
--enable_rocksdb_whole_key_filtering=false
--rocksdb_db_options={}
--rocksdb_column_family_options={"write_buffer_size":"67108864","max_write_buffer_number":"4","max_bytes_for_level_base":"268435456"}
--rocksdb_block_based_table_options={"block_size":"8192"}
--enable_storage_cache=false
--storage_cache_capacity=0
--storage_cache_entries_power=20
--enable_vertex_pool=false
--vertex_pool_capacity=50
--vertex_item_ttl=300
--enable_negative_pool=false
--negative_pool_capacity=50
--negative_item_ttl=300
--query_concurrently=true
--auto_remove_invalid_space=true
--num_io_threads=16
--num_max_connections=0
--num_worker_threads=32
--max_concurrent_subtasks=10
--snapshot_part_rate_limit=10485760
--snapshot_batch_size=1048576
--rebuild_index_part_rate_limit=4194304
--rebuild_index_batch_size=1048576
--nv_cache_path=/tmp/cache
--nv_cache_size=0
--nv_dram_size=50
--nv_bucket_power=20
--nv_lock_power=10
--ng_black_box_switch=false
--ng_black_box_home=black_box
--ng_black_box_dump_period_seconds=5
--ng_black_box_file_lifetime_seconds=1800
--memory_tracker_limit_ratio=0.8
--memory_tracker_untracked_reserved_memory_mb=50
--memory_tracker_detail_log=false
--memory_tracker_detail_log_interval_ms=60000
--memory_purge_enabled=true
--memory_purge_interval_seconds=10
--enable_ssl=false
--enable_meta_ssl=false
--cert_path=certs/server.crt
--key_path=certs/server.key
--ca_path=certs/ca.crt
--ca_client_path=certs/ca.crt
--password_path=certs/password
--ssl_watch_path=certs
--enable_partitioned_index_filter=true
另外贴一张疑似storaged内存泄漏的图，后面不涨了是因为graphd OOM，客户端挂掉了：
steam
2024 年4 月 7 日 07:32
8
你可以看看不写入数据的时候，内存的一个增长情况。
这个报错的话，可能是执行语句的客户端的版本号和内核的版本号对齐有问题，你可以看下版本匹配问题。
可以贴下具体的查询是啥。
graph应该是使用完内存就会释放的，你确认下是graph进程占用内存吗或者是有query还没执行完。storage又一些固定内存开销，比如block_cache，默认是4G。其他还有一些内存占用你可以看看论坛上关于storage内存的帖子。
storaged的block_cache，默认4G，这个我试过改成100M，对比了下，无明显变化，然后，如果是只查不写，storaged内存基本不会上升或者上升量非常小
查询写死的，就那么几个，我都是每5s执行下这个文件里面的语句，数据集用的那个电影推荐的，不读不写，空负载的情况下，内存很稳定，只读不写，内存增长也是特别缓慢，基本没有增长，然后查询的话，用的是go客户端，代码从官方文档里面copy来的，这个版本匹配在哪里看呢？sql.rar (14.2 KB)
steam
2024 年4 月 7 日 07:57
12
我看了你的语句，像是 ngql1 这种语句的话，执行起来应该耗时不低的，
主要是想模拟一下业务方的真实查询吧，比如说有快查询，也会有烂代码，弄一些慢查询
写数据也会导致内存上升，会先写入memtable里面，这个可以看下rocksdb的写入流程
这个我之前简单看了下介绍，这个我认为是正常的，但是为什么在我写完数据之后，内存仍然不释放呢？停止写入，内存停止增长不下降，开始写入，在原有内存基础上继续增长
你能说下做了哪些处理吗？内存一定时间范围内线性增长不一定是问题。比如是为了 cache 等。所以要看是不是长时间不断的线性增长
建议你可以再研读下上面那篇文章，比较多，耐心看可能有些收获
社区用户经常会反馈什么都没有做，但是内存持续升高。这里整理了几个解题思路：
确定到底什么进程占用过了过多的资源，top 看看到底 CPU、内存哪个进程占用高；
如果是 graph 的话，说明系统正在做查询，等查询完成之后看看是否资源占用会有所下降；
如果是其他服务，storage 会有一些固定的内存开销，比如：wal 会部分缓存在内存，这个会发生在有数据写入的时候，等数据完成写之后，占用情况会…
如果 space 的 name 里有特殊符号的话，需要用反引号，`space#Name` 这样包裹下。