space 的partition_num=30，
在spark 中没有指定相关参数，hive 表的task 数量是130左右
你可以在spark的webui中看下，真正跑起来的有多少个task，以及同时执行的task数有多少个
我之前看过，好像同时跑起来的就是10 exector * 3 core = 30个，(现在任务停了，history 过期了看不到了)
另外space 的partition_num=30 合适吗
你这个快了好多，奇怪。难道是读hive table 导致的吗？我记得我看了一个task 完成都要30min 左右
你可以单独计时，分别观察从hive里面读数据的时间和数据写入nebula的时间
df = spark.sql("select * from hive_tmp.nebula_test_node")
df.write.format("com.vesoft.nebula.connector.NebulaDataSource")\
.mode("overwrite")\
.option("timeout", 60000)\
.option("connectionRetry", 3)\
.option("executionRetry", 3)\
.option("vidPolicy", "")\
.option("metaAddress", "metad:9559")\
.option("graphAddress", "graphd:9669")\
.option("user", "root")\
.option("passwd", "nebula")\
.option("type", "vertex")\
.option("spaceName", "Relation")\
.option("label", "Test")\
.option("vertexField", "vid")\
.option("batch", 1024)\
.option("writeMode", "insert").save()
我想做这个事情，但是因为是这样写的，df 是的read 是transform 算子，我不知道该怎么去分开观察这两个时间
df = spark.sql(“select * from hive_tmp.nebula_test_node”)
df.count()
df.write.format(“com.vesoft.nebula.connector.NebulaDataSource”)\xxx
只观察df.write.format的时间
1 个赞
ok 明白了，感谢。我重新跑一下，观察下
你的集群中有几个graph服务，如果多个可以全部配上，这样请求会分别打到不同的机器上。
不论executor是几个，同一个connection都不会有并发，一个executor有一个session，一个session有一个connection。
当你executor多的时候容易出现timeout，有可能是因为请求都打给了一个graph导致该graph或者storage在处理写请求时压力大未在一定时间内返回结果。
你好，对上面还有点疑问，我的理解如果一个executor 上只有一个connection pool 对应着一个connection 那么 cpu 的core 多少不是没有作用吗？一个executor 上的所有的task 都是串行了
core 和nebula client中的connection pool没关系啊，一个core内的task肯定是串行的，spark的并发是通过多个core来实现的。
cores是你的spark任务所分配的executor 数量 * 每个executor分配的core数， 可以理解为这是你的程序可用的总线程数M。
你代码里面所配置的partitions是你程序切分的task数N。
所以实际并发是 min（M，N）
好的，谢谢，我理解下。
我上面观察到的目前read 挺快的，write 这一步太慢了，这个有什么方式调优下吗
调大一下batch 参数，如果你的数据属性不多可以调成2000-4000试试。
还可以调大分配的core数，看图片你应该是有122个partition，分配的总核数最好是40或60
1 个赞
上午调整了下参数，发现并发太大，这个很容易出现timeout
com.vesoft.nebula.client.graph.exception.IOErrorException: java.net.SocketTimeoutException: Read timed out
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。