为何在golang goroutine中使用ReadOnlyTransaction执行Spanner查询会逐渐变缓?
亲爱的编程学习爱好者,如果你点开了这篇文章,说明你对《为何在golang goroutine中使用ReadOnlyTransaction执行Spanner查询会逐渐变缓?》很感兴趣。本篇文章就来给大家详细解析一下,主要介绍一下,希望所有认真读完的童鞋们,都有实质性的提高。
我正在尝试从表中查询大约 10,000 行。在尝试了涉及 limit offset 的各种其他选项并且没有找到所需的成功之后,我尝试在每个 goroutine 中查询单行。思路是每行只需要 ~5ms 来查询和获取,但是一批 10k 会接管 20s。
下面显示的是代码的简化版本:
func queryEmp(IDs[]string, spannerClient *spanner.Client) (Employee,error){
query := "Select name from Employee Where id = @id"
g, gCtx := errgroup.WithContext(ctx)
for _, ID := range IDs {
id := ID
g.Go(func() error {
tx := spannerClient.Single()
defer tx.Close()
stmt2 := spanner.NewStatement(query)
stmt2.Params = map[string]interface{}{
"ID": id,
}
qstart := time.Now()
it := tx.Query(gCtx, stmt2)
defer it.Stop()
logrus.Debugf("%s took %v \n", "query execution.", time.Since(qstart))
for {
row, err := it.Next()
if err == iterator.Done {
break
}
if err != nil {
return err
}
var eID string
if err := row.Column(0, &eID); err != nil {
return err
}
}
return nil
})
}
err = g.Wait()
}
结果跟踪如下:
{"message":"query execution. took 39.677µs \n","severity":"debug","time":"2023-11-03T20:51:29-04:00"}
{"message":"query execution. took 34.125µs \n","severity":"debug","time":"2023-11-03T20:51:29-04:00"}
{"message":"query execution. took 26.634µs \n","severity":"debug","time":"2023-11-03T20:51:29-04:00"}
{"message":"query execution. took 29.303µs \n","severity":"debug","time":"2023-11-03T20:51:29-04:00"}
...
...
...
{"message":"query execution. took 188.749562ms \n","severity":"debug","time":"2023-11-03T20:51:29-04:00"}
{"message":"query execution. took 276.424692ms \n","severity":"debug","time":"2023-11-03T20:51:29-04:00"}
{"message":"query execution. took 188.62849ms \n","severity":"debug","time":"2023-11-03T20:51:29-04:00"}
{"message":"query execution. took 217.067524ms \n","severity":"debug","time":"2023-11-03T20:51:29-04:00"}
{"message":"query execution. took 276.949166ms \n","severity":"debug","time":"2023-11-03T20:51:29-04:00"}
...
...
...
{"message":"query execution. took 454.64281ms \n","severity":"debug","time":"2023-11-03T20:51:29-04:00"}
{"message":"query execution. took 452.0848ms \n","severity":"debug","time":"2023-11-03T20:51:29-04:00"}
{"message":"query execution. took 525.748738ms \n","severity":"debug","time":"2023-11-03T20:51:29-04:00"}
{"message":"query execution. took 454.704656ms \n","severity":"debug","time":"2023-11-03T20:51:29-04:00"}
{"message":"query execution. took 455.4276ms \n","severity":"debug","time":"2023-11-03T20:51:29-04:00"}
...
...
...
{"message":"query execution. took 6.767574136s \n","severity":"debug","time":"2023-11-03T20:52:00-04:00"}
{"message":"query execution. took 6.780578444s \n","severity":"debug","time":"2023-11-03T20:52:00-04:00"}
{"message":"query execution. took 6.785085491s \n","severity":"debug","time":"2023-11-03T20:52:00-04:00"}
{"message":"query execution. took 6.779527006s \n","severity":"debug","time":"2023-11-03T20:52:00-04:00"}
一开始很好,符合预期,但查询时间不断增加。
MaxSessions 和 MinSessions 对于 spannerClient 是 100 所以人们会想象它可能会在 100 后看到轻微的减速,但事实并非如此。
请阅读此处:
Sessions can execute only one transaction at a time. Standalone reads, writes, and queries use a transaction internally, and count toward the one transaction limit.
非迭代查询(ReadRow 等)给了我相同的结果。
在 for 循环之外使用 tx := spannerClient.Single() 也会给出类似的结果。
问题:
- 这是否意味着尽管在 goroutine 中执行了
spannerClient.Single(),但 goroutine 仍尝试使用相同的会话/事务? - 如何修改上述内容来解决该问题?
正确答案
TLDR:默认最大会话池大小为 400,这意味着并行运行的查询永远不会超过 400 个。您需要增加会话池大小才能实现这种并发性。
首先:我认为并行发送 10,000 个查询以让每个查询读取一行并不是解决您的问题的最有效的解决方案。如果没有其他条件,您可以使用比员工 ID 进行过滤的方法,而这些 ID 分散在各处,那么在表单中创建查询仍然会更有效
select * from employees where id in unnest(@ids)
有关完整示例,请参阅此评论:https:// /github.com/googleapis/google-cloud-go/issues/858#issuecomment-550982307
回到你的具体问题:
- 您实际上并没有测量执行查询所需的时间。这有点令人困惑,但是
it := tx.Query(gCtx, stmt2)行确实不执行查询,它只是准备执行查询。第一次调用row, err := it.Next()时执行。您还可以在记录的执行时间中看到这一点。第一条语句似乎在 30 微秒内执行,这是不可能的。 - 这意味着您的客户端上的某些内容限制了您的进度,在这种情况下,我非常确定它是您的会话池的最大大小。默认最大会话池大小为 400。这意味着最多可以并行运行 400 个查询。您看到的等待时间不断增加是因为 goroutine 被放置在等待队列中等待会话变得可用。队列末尾的 goroutine 的等待时间会更长。
今天带大家了解了的相关知识,希望对你有所帮助;关于Golang的技术知识我们会一点点深入介绍,欢迎大家关注golang学习网公众号,一起学习编程~
设置Go HTTP服务器标头的内容类型为multipart/form-data,但在客户端获取的Content-Type为text/plain
- 上一篇
- 设置Go HTTP服务器标头的内容类型为multipart/form-data,但在客户端获取的Content-Type为text/plain
- 下一篇
- 为什么下列 go 程序会出现“致命错误:所有 goroutine 都在睡眠 - 死锁!”的死锁错误?
-
- Golang · Go问答 | 23小时前 |
- Go t.Cleanup注册后测试提前Fatal的资源释放边界
- 399浏览 收藏
-
- Golang · Go问答 | 1天前 |
- Go testing t.Parallel与t.Setenv冲突时的组织方式
- 265浏览 收藏
-
- Golang · Go问答 | 1天前 | 并发 · go · sync.Mutex go vet copylocks
- Go mutex复制后锁状态失效的代码审查要点
- 431浏览 收藏
-
- Golang · Go问答 | 1天前 | 并发 · go · 排查 · 数据竞争 Go并发 sync/atomic
- Go atomic值混用普通读写引起数据竞争的修复清单
- 289浏览 收藏
-
- Golang · Go问答 | 1天前 |
- Go sync.Pool取回旧对象状态时的重置排查
- 327浏览 收藏
-
- Golang · Go问答 | 1天前 |
- Go copy返回长度小于预期时的切片容量分析
- 246浏览 收藏
-
- Golang · Go问答 | 1天前 | 排序 · go ·
- Go sort.Slice比较器不满足严格弱序时的异常表现
- 404浏览 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 485次学习
-
- PubMedQA
- 深入了解PubMedQA生物医学问答数据集,涵盖其核心功能、使用方法及在临床决策、药物研发等场景的应用,助力提升NLP模型性能。
- 198次使用
-
- H2O EvalGPT
- H2O EvalGPT是H2O.ai推出的开源LLM评估平台,提供详细的大模型性能排行榜、行业特定基准测试及A/B测试功能,助您快速选择最适合项目的高性能大语言模型。
- 254次使用
-
- LMArena
- LMArena是加州大学伯克利分校推出的AI模型匿名评测平台。通过盲测投票机制,用户可对比不同大模型回答并生成实时排行榜,助力开发者优化模型及用户选择最佳AI工具。
- 209次使用
-
- HELM
- 深入了解斯坦福推出的HELM(Holistic Evaluation of Language Models)大模型评测体系。本文解析其核心功能、安装配置步骤及应用场景,涵盖准确性、公平性、鲁棒性等多维度指标,助力开发者全面优化语言模型性能。
- 193次使用
-
- CMMLU
- 深入了解CMMLU中文评估基准,涵盖67个学科主题,提供数据集下载、Zero-shot/Five-shot评估方法及排行榜,助力优化中文语言模型性能。
- 184次使用
-
- 用Nginx反向代理部署go写的网站。
- 2023-01-17 502浏览
-
- GoLand调式动态执行代码
- 2023-01-13 502浏览
-
- Go sql.Tx提交成功前读取结果导致事务边界混乱的修复方法
- 2026-09-20 501浏览
-
- Go select 用 time.After 做超时有什么资源代价
- 2026-09-10 501浏览
-
- Go 取 range 变量地址为什么得到重复指针
- 2026-09-07 501浏览

