这个我确定之前我导入快速的时候日志中也有这个切换日志打印, 但是就是不清楚,现在为啥真没慢了
我确定我的source是读的很快的, …
二位哥哥, 求助啊, @nicole @Shylock-Hg
这是之前的高速导入时候的监控截图, 磁盘的写入和网络绝对不是瓶颈, 可以轻松上GB级别, IOPS也是10W+ 的随机读写, 上次的时候也是速度在慢慢降低, 但是最后还是稳住在100mb/s的速度导入了100亿数据
之前高速和现在,是使用同一个集群的同一个 space 么,还是两个集群?
现在速度比较慢的时候,space 的磁盘大小有多大,你们有统计这个 space 一共插入了多少条数据么?
你是用的 docker-compose 么,多个 storage 实例是共用一个磁盘,还是每个实例一个磁盘。
能贴一下你 storage 的配置么?
你好
是同一个集群, 用一个space, space 的id都是357
是 docker-compose , 每个storage是一个独立机器,
配置
对了, 还有这个
建索引后写入肯定会慢的。
这2次不是同一个表, 那个问题就是单纯咨询有索引的话速度会慢很多
这次是我新建的一张新表, 没有索引的
具体是这样的, 上次的(假如A表)点有88亿, 已经导入完成, 并且已经建立索引, 这次导入的是点A表的自循环关系数据, 不知道这个有没有影响?>>
@nicole 我验证了一下, 怀疑是索引问题导致的, 具体步骤如下
2, 那么问题来了, A点的话有88亿, 上次已经导入完成, 并且建立了索引, 现在的B关系是A点的自循环, 现在导入B关系数据的话, A的索引是对B关系导入有影响的??? (我现在删除了A点的索引再试试, 但不知道删除索引快不快,)
3, 我删除完索引后在开始导入, 可以看到正常了
额,你再观察观察,A建立的索引与边的导入速度没关系的。 你删掉了索引相当于该space 占用的磁盘少了,应该和删掉一部分数据起到的效果一样。
1 那就奇怪了, 我昨天这边的结果是已删除索引,就导入速度OK了,
@nicole @Shylock-Hg 大佬求助, 紧急问题
2. 新问题: 从昨天18点开始导入88亿数据, 跑到今天早上快9点了, 出问题了, 集群的master节点的机器一直自动挂了重启, 导致我这个导入是但副本数据也报错了, 至于这master节点挂了的原因是/var/lib/docker/overlay2目录问题太大了, 暴增到100% 导致我的 “/” 分区也100% , 每次master自动重启的话会立马释放这个目录空间,但是没过多久又会暴增, 其实这个问题已经出现这是第三次了, 之前都是重启解决 大佬知道这啥原因吗??? (备注: docker是默认路径安装的)
百度结果: https://www.cnblogs.com/wswang/p/10736726.html 大佬看下这个解释靠谱吗?? 如果靠谱的话, 那为啥nebula会一直重启呢???
监控信息:
也可以考虑把 docker 目录从 /
中移动到另一个地方。停了 docker 服务,移动到新的地方,改 docker 配置里的路径,启动docker 服务
1 我这方法可以是可以, 但是为啥部署的nebula在什么情况下会大量占用这个目录/var/lib/docker/overlay2呢???
建议后续改进, 这个虽然失败了, 但是最终的状态还是running,
du -shx 的结果呢?
有点乱, 整理一下,
问题1 现在的问题是: 删除完所有的容器, 重新启动部署neubla后开始导入数据, 发现这目录overlay2一直在增大, 并伴随这容器挂掉重新启动, 数据导入自然也就报错了, 大佬有啥定位办法吗??? 当然我们这数据量比较大, 已经导入100亿数据, 现在导入的也是有88亿, 如果方便的视频会议的话, 我可以发送邮件视频会议, 连线指导一下
问题2 我昨天晚上导入的同时发现监控上还有慢查询, 问一下,这FLink导入会涉及到大量查询嘛?
该主题在最后一个回复创建后7天后自动关闭。不再允许新的回复。