分布式部署时各 storaged 进程负载不均匀

问答 问题
1

nebula 版本: 1.1.0
部署方式: 分布式
硬件信息: 每台机器都是 磁盘 NVMe 240G, CPU8核16线程，内存32G

配置信息：

Server1 metad 和 storaged混布:

etc/nebula-metad.conf
--meta_server_addrs=192.168.2.11:45500,192.168.2.12:45500,192.168.2.13:45500
--local_ip=192.168.2.11

etc/nebula-storaged.conf
--meta_server_addrs=192.168.2.11:45500,192.168.2.12:45500,192.168.2.13:45500
--local_ip=192.168.2.11

Server2 metad 和 storaged混布:

etc/nebula-metad.conf
--meta_server_addrs=192.168.2.11:45500,192.168.2.12:45500,192.168.2.13:45500
--local_ip=192.168.2.12

etc/nebula-storaged.conf
--meta_server_addrs=192.168.2.11:45500,192.168.2.12:45500,192.168.2.13:45500
--local_ip=192.168.2.12

Server3 metad 和 storaged混布:

etc/nebula-metad.conf
--meta_server_addrs=192.168.2.11:45500,192.168.2.12:45500,192.168.2.13:45500
--local_ip=192.168.2.13

etc/nebula-storaged.conf
--meta_server_addrs=192.168.2.11:45500,192.168.2.12:45500,192.168.2.13:45500
--local_ip=192.168.2.13

Server4 graphd单布:

etc/nebula-graphd.conf
--meta_server_addrs=192.168.2.11:45500,192.168.2.12:45500,192.168.2.13:45500
--local_ip=192.168.2.14

Space信息：

(root@nebula) [MYSP]> show hosts;
==================================================================================================
| Ip           | Port  | Status | Leader count | Leader distribution   | Partition distribution  |
==================================================================================================
| 192.168.2.11 | 44500 | online | 10           | MYSP: 10              | MYSP: 30                |
--------------------------------------------------------------------------------------------------
| 192.168.2.12 | 44500 | online | 10           | MYSP: 10              | MYSP: 30                |
--------------------------------------------------------------------------------------------------
| 192.168.2.13 | 44500 | online | 10           | MYSP: 10              | MYSP: 30                |
--------------------------------------------------------------------------------------------------
| Total        |       |        | 30           | MYSP: 30              | MYSP: 90                |
--------------------------------------------------------------------------------------------------


(root@nebula) [MYSP]> describe space MYSP;
======================================================================
| ID | Name | Partition number | Replica Factor | Charset | Collate  |
======================================================================
| 1  | MYSP | 30               | 3              | utf8    | utf8_bin |
----------------------------------------------------------------------

问题描述:

现在发现在写入和查询的时候，Server1、Server2、Server3 的 nebula-storaged 进程 的 CPU 占用并不相近。通过 htop 观察有时候 Server1 的 nebula-storaged 进程占用有 500% ，但是此时 Server2、Server3 的 nebula-storaged 进程占用只有 50% 左右

2

是长期不均匀还是临时现象？

3

我发现所有的 nebula-storaged 进程都被 OOM 了，然后一个一个全部启动起来后，发现的这个问题。然后我把所有客户端全部断开后 1 各小时左右后重新连接客户端后正常了。

4

Linux 内核有个机制叫OOM killer(Out Of Memory killer)，该机制会监控那些占用内存过大，尤其是瞬间占用内存很快的进程，然后防止内存耗尽而自动把该进程杀掉。内核检测到系统内存不足、挑选并杀掉某个进程的过程可以参考内核源代码linux/mm/oom_kill.c，当系统内存不足的时候，out_of_memory()被触发，然后调用select_bad_process()选择一个”bad”进程杀掉。如何判断和选择一个”bad进程呢？linux选择”bad”进程是通过调用oom_badness()，挑选的算法和想法都很简单很朴实：最bad的那个进程就是那个最占用内存的进程。
可以改下 --rocksdb_block_cache=1024，另外partition数目可以减少下。
再或者是你读的query获取的数据比较多，导致内存会上涨。

1 个赞
5

32G 内存的机器确定只设这么大？我现在设置的是 10240