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号
