Star

KNeighbor计算导致图服务器崩溃

nebula version: 1.0.1
机器: ubuntu 16.04
内存: 128G
点边文件: 1.5G

1.执行期间 ssh连接服务器失败,但可以ping通
2.nebula服务崩溃后可以ssh连接
3.ssh连接后table自动补全命令不可用
报错原因 ~bash: cannot create temp file for here-document: Read-only file system
KNeighbor执行前table自动补全是可以的
4. 通过命令shutdown -r now 重启服务器,关机后服务器无法启动, 已物理启动

dmesg看一下

disk 满了?

不是磁盘满了, 倒是跑着的时候内存满了

Filesystem      Size  Used Avail Use% Mounted on
udev             63G     0   63G   0% /dev
tmpfs            13G  9.8M   13G   1% /run
/dev/sdb2       314G  183G  116G  62% /
tmpfs            63G  192K   63G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs            63G     0   63G   0% /sys/fs/cgroup
/dev/sda        5.5T  206G  5.0T   4% /data6
/dev/sdc        917G   67G  805G   8% /data
/dev/sdb1       511M  3.7M  508M   1% /boot/efi
tmpfs            13G   32K   13G   1% /run/user/108
tmpfs            13G     0   13G   0% /run/user/0
tmpfs            13G     0   13G   0% /run/user/1005



              total        used        free      shared  buff/cache   available
Mem:         128612         448      126929          18        1235      126943
Swap:        130741           0      130741

机器已经物理重启dmesg信息是否还有参考意义? dmesg信息太长了我截取一部分还是加个链接放上来?

这个崩溃时的服务器状况吗?

内存信息不是, 磁盘信息是
服务崩溃后内存占用恢复

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                            
 9416 lsz       20   0   43964   4104   3360 R   0.3  0.0   0:00.06 top                                                                                                
31817 root      20   0  863656  10544   5360 S   0.3  0.0   0:14.95 nebula-metad                                                                                       
    1 root      20   0  185152   3336   2704 S   0.0  0.0   0:05.97 systemd                                                                                            
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.04 kthreadd  

用1.2吧

三天前用集群版的1.2也跑崩溃了,崩溃的是主节点,早上5点左右崩溃的,上午十点左右机器一直不恢复(ssh连不上), 物理重启

机器128G+128G+128G
内网带宽1G

这个数据量没道理啊,是啥操作?

String.format("FIND SHORTEST PATH FROM %s to %s OVER *  UPTO 5 STEPS;", s[0], s[1])

dmesg kill之前应该会说谁占用了多少mem。不过为什么1.5GB数据,能扩张成这么多内存 128G。。。。
什么数据集啊
另外默认的配置参数有改过吗?

dmesg当时未保存.

用户之间的关系图谱, 点百万,边1.5亿左右
配置文件只改了data_path和meta存储位置

深度遍历的OOM是个常见问题了。
但是1.5GB硬盘数据能扩张那么多,我很难理解

唉,不知道哪里出了问题

你分别试试2跳 3 跳和 4跳吧。
如果数据量大,单个进程OOM是大概率的。这个是架构问题。

1,2,3,4,5,6跳在1~2亿(边)小数据集下没问题, 但是在大数据集下(10亿边+)4跳,5跳,6跳就会卡死。
使用nebula-2.0-beta,Go跳的有点慢,1.0的语句直接用在2.0上不知道为啥很慢, nebula2.0 go速度太慢?

2.0 还没调优过。

浙ICP备20010487号