打开一个嵌入块很多的文档后软件直接不能用了,且无法关闭软件

打开下面这样一个有很多嵌入块的文档:

image.png

嵌入块显示不出来,而且软件的索引功能失效,其他所有引用块都点击不了,而且悬浮窗也显示不出东西,反链面板也全部失效,文档树也全部失效,看似没卡,实际上什么功能都用不了

image.png

而且此时软件无法关闭,只能用任务管理器关闭

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • 88250 1 评论
    订阅者

    等下个版本看看,谢谢。

    2 回复
    +1
    zihuzi
  • Belf
    订阅者

    +1

  • fangly
    订阅者 作者

    更新到 1.5.0 后,我一打开软件,就和上面描述的情况一样了,软件用不了,也关不掉,只能用任务管理器关掉,回退到 1.4.8 软件打开没问题:

    temp99.gif

    temp100.gif

    我退回 1.4.8,然后把打开着的标签页全部关掉,再装 1.5.0,这样是没问题的。

    成功升级到 1.5.0 后,这个帖子中嵌入块的问题仍然存在。

    1 回复
    2 操作
    fangly 在 2021-11-09 16:30:25 更新了该回帖
    fangly 在 2021-11-09 16:28:57 更新了该回帖
  • 88250
    订阅者

    请试下重建索引或者删除数据库文件重现初始化库看看。

    1 回复
  • fangly
    订阅者 作者

    两种方法都试了,还是不行(指的是 1.5.0 中的嵌入块问题)

    回退 1.4.6,本帖中的嵌入块是没问题的

    1 回复
  • 88250
    订阅者

    麻烦上传一下日志,谢谢。

    1 回复
  • fangly
    订阅者 作者
  • 88250
    订阅者

    日志里面暂时没发现问题,能否抽空帮忙做个最小重现测试数据集发邮箱 [email protected] 非常感谢。

    1 回复
  • fangly 1
    订阅者 作者

    已经发到您邮箱了,打开《很多嵌入》这个文档:

    image.png

    简述一下我的复现过程:

    我先是在这个页面搞了很多嵌入块,发现没问题

    然后我把所有被嵌入的内容中都加上引用块,就出问题了,回退到 1.4.6,没问题:

    image.png

  • 88250
    订阅者

    非常感谢老铁帮忙,已经定位到问题了,在 Issue #3372 · siyuan-note/siyuan 中修复。

    1 回复
  • fangly
    订阅者 作者

    除了嵌入块和引用嵌套时的问题,还遇到一个卡死的场景,不知道两者是不是一样的问题

    我把鼠标放在引用块悬浮窗上,之后就卡死了:

    temp101.gif

    测试集:

    20210927211858cnulnll.zip

    打开《很多反链》这个文档。

    而且反链面板显示的速度非常慢,要等很久才能显示出来,感觉比 1.4.6 的时候慢了不少,不知道这个性能能不能优化一下

    1 回复
  • 88250
    订阅者

    我这里在开发环境用刚刚你提供的数据集测了下正常,应该是同一个问题:解析动态锚文本的时候数据库连接没关闭导致没有可用连接进行查询。

    性能问题暂时还不确定是否有影响,等下个版本发布看看。

    1 回复
  • fangly 1
    订阅者 作者

    升级到 1.5.1 之后,嵌入块没问题了

    但我后面提到的鼠标放在引用块悬浮窗上的问题仍然存在,第一次放上去的时候会看到能显示,但是没有面包屑,这个时候已经假死了:

    image.png

    鼠标再放上去,就啥也没有了:

    image.png

    1 回复
  • 88250
    订阅者

    我这里用上次的测试集没能重现 😂

    1 回复
  • fangly
    订阅者 作者

    新测试集发到您邮箱了

    把测试集里面的两个笔记本都塞到 data 文件夹里,然后把鼠标悬停在文档树中测试-数据集这个文档的块引用上,之后就假死了

    image.png

    1 回复
  • 88250
    订阅者

    感谢感谢,已经定位到问题了,下个版本修复。

    1 回复
  • fangly
    订阅者 作者

    又发现一个可能导致假死的问题,测试集发您邮箱了(只有一个文档)

    首先 ctrl+alt+4 把一个标题变成普通段落,可以看到这时候左侧大纲中还没反应过来,这时候赶紧把列表转换为段落(要在大纲中还没发生变化的时候转换,手要快,如果大纲这时候已经变化了,即大纲第一行的"符号约定"已经没了,这时候很可能复现不了,当然有时候我没有按 ctrl+alt+4,直接把列表转换为段落也会假死),之后就假死了,这时如果没有假死,可以在这个文档上再 ctrl+z 撤回一下,之后应该也会假死:

    temp102.gif

    不过这个好像不是完全假死,出现假死状态之后,等很久以后会恢复正常,可能是性能问题

    目前主要是在列表中搞标题,以及列表转段落的过程容易出现假死状态,不止上面的复现方法。

    还有就是现在大纲的反应确实太慢了,在文档中修改标题层级后,大纲有时候要 10 秒才反应过来,而且在大纲反应变化的过程中我换到别的文档,大纲也不会变化到别的文档的大纲,而是一直卡着,我猜是某个地方阻塞了。

    还有假死会导致一个比较严重的问题,假死情况下仍然可以输入(但不能粘贴的东西),但是这个输入并不会保存到文件中,重启后写了的内容都会丢失。不知道这个问题能否防范,因为很多时候自己并不知道假死了,在文档里写了很多内容,然后突然程序崩溃重启,刚才写的内容都没了。

    1 回复
    4 操作
    fangly 在 2021-11-12 21:15:13 更新了该回帖
    fangly 在 2021-11-12 20:25:12 更新了该回帖
    fangly 在 2021-11-12 19:12:06 更新了该回帖
    fangly 在 2021-11-12 18:48:34 更新了该回帖
  • 88250
    订阅者

    应该是性能问题,在小库上面我重现不了,大库没做测试。

    目前对于较大列表的保存操作写入数据会比较慢,大纲还有退出等操作是阻塞的,需要等待数据写入以后才返回结果。较大列表的写入性能问题请关注 Issue #2548 · siyuan-note/siyuan

    1 回复
  • fangly
    订阅者 作者

    回退到 1.4.6,在大库下,还是很顺畅的,大纲响应很快,也复现不出假死的 bug,所以这个假死问题和是小库还是大库应该没直接关系,和列表的写入性能应该也没直接关系,可以比较一下两者大纲响应的速度(其他条件都相同,都是在大库下):

    1.4.6:

    temp103.gif

    1.5.1:

    temp104.gif

    在 1.5.1 中,我关闭主笔记本,剩下测试笔记本,也就是在小库下,性能也没问题,大纲响应很快,我不太理解为什么只是打开一个和这个文档无关的笔记本,会影响这个文档的大纲的响应速度 😂

    是不是 1.4.7 中修改了什么东西,对性能造成了比较大的影响。像假死问题,以前从来没遇到过,1.4.7 之后经常出现,而且复现假死的方法有很多,一个一个复现排查估计有难度,假死的核心问题个人猜测在于性能,以前版本性能好,各种代码逻辑问题可能都触发不了,1.4.7 后性能变差了,导致很多问题暴露出来了,而性能变差的原因我猜测是 1.4.7 中的某个 issue 造成的

    1 回复
    1 操作
    fangly 在 2021-11-13 00:53:54 更新了该回帖
  • 88250
    订阅者

    最近的几个版本一直在改进数据库事务实现,但某些地方可能因为事务未关闭导致数据库连接泄漏。这两天也在检查代码,感觉应该补得差不多了,等发布以后继续帮忙测测看吧。

    1 回复
  • fangly
    订阅者 作者

    假死情况目前还是存在,最后发给您的复现方法在 1.5.2 中依然能复现

    下面这个图中,我只是删除了这个文档中的所有内容,就假死了,我猜测是写入数据一直阻塞着:

    temp105.gif

    过了一段时间,弹出内核连接中断:

    image.png

    关掉思源,重启后,发现文档中的内容没有被删除,应该是没有成功写入数据

    复现这个假死问题的一个要点是“大纲的显示与文档真正的内容不匹配”的时候做一些操作,比如说之前的复现方法中,改变标题层级,在大纲还没有反应过来的时候,将列表转换为段落,此时一定会假死,如果大纲此时反应过来了,一般不会假死。

    而在小库下,大纲反应很快,因此很难做到大纲与文档真正内容不匹配,也就很难复现。

    “大纲的显示与文档真正的内容不匹配”这个当然是表面现象,本质肯定是其他原因。

    还有 1.4.7 之后大纲的反应速度在大库下明显比以前慢了很多,这也导致了 1.4.6 之前在大库下也没法复现,而 1.4.7 之后在大库下很容易复现上面的假死问题,说不定这个问题以前版本也存在,只是以前版本大纲反应太快了,没有人有那么快的手速可以在大纲还没反应过来的时候进行其他操作。“大纲的反应速度在大库下慢”这当然也是表面现象,本质应该也是有其他原因。或许可以往提高大纲反应速度的方向修复看看?

    1 回复
    3 操作
    fangly 在 2021-11-14 12:10:41 更新了该回帖
    fangly 在 2021-11-14 12:04:11 更新了该回帖
    fangly 在 2021-11-14 11:57:58 更新了该回帖
  • 88250
    订阅者

    麻烦把日志文件再上传一下,谢谢。

    1 回复
  • fangly
    订阅者 作者

    log.zip

    应该是在这部分的时候假死的:

    image.png

    1 回复
  • 88250
    订阅者

    好的,这个问题我们会继续跟进排查的。

    3 回复
  • fangly
    订阅者 作者

    我之前随便在一个新的工作空间试了下,忘了做了什么操作,日志中有以下记录,不知道能不能看出什么东西(前面几个 rebuilt database 是我主动重建索引的,我把一些东西复制到新工作工作空间,然后重建索引):

    I 2021/11/14 12:43:47 box.go:499: rebuilt database for notebook [20210820214849-sbwv4pi] in [13.83s], tree stat [count=295, size=8.4 MB]
    I 2021/11/14 12:43:51 box.go:499: rebuilt database for notebook [20210927211858-cnulnll] in [3.55s], tree stat [count=57, size=1.1 MB]
    I 2021/11/14 12:44:50 box.go:499: rebuilt database for notebook [20210820214849-sbwv4pi] in [15.37s], tree stat [count=354, size=9.4 MB]
    I 2021/11/14 12:44:54 box.go:499: rebuilt database for notebook [20210927211858-cnulnll] in [3.69s], tree stat [count=57, size=1.1 MB]
    W 2021/11/14 12:46:36 conf.go:370: data is writing
    I 2021/11/14 12:47:17 box.go:499: rebuilt database for notebook [20210820214849-sbwv4pi] in [63.57s], tree stat [count=704, size=22 MB]
    E 2021/11/14 12:47:32 database.go:1084: begin tx failed: database is locked
      goroutine 79128 [running]:
    runtime/debug.Stack()
    	D:/go1.17/src/runtime/debug/stack.go:24 +0x65
    github.com/siyuan-note/siyuan-src/kernel/sql.BeginTx()
    	D:/88250/siyuan-src/kernel/sql/database.go:1084 +0x51
    github.com/siyuan-note/siyuan-src/kernel/model.BuildBlockPath({0xc0083c8540, 0x16})
    	D:/88250/siyuan-src/kernel/model/blockinfo.go:187 +0x65
    github.com/siyuan-note/siyuan-src/kernel/api.getBlockBreadcrumb(0xc000ae4200)
    	D:/88250/siyuan-src/kernel/api/block.go:218 +0xf8
    github.com/gin-gonic/gin.(*Context).Next(...)
    	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
    github.com/siyuan-note/siyuan-src/kernel/model.CheckAuth(0xc000ae4200)
    	D:/88250/siyuan-src/kernel/model/session.go:93 +0x467
    github.com/gin-gonic/gin.(*Context).Next(...)
    	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
    github.com/gin-contrib/sessions.Sessions.func1(0xc000ae4200)
    	D:/gogogo/pkg/mod/github.com/gin-contrib/sessions@v0.0.3/sessions.go:52 +0x18d
    github.com/gin-gonic/gin.(*Context).Next(...)
    	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
    github.com/gin-contrib/gzip.(*gzipHandler).Handle(0xc00066ef60, 0xc000ae4200)
    	D:/gogogo/pkg/mod/github.com/gin-contrib/gzip@v0.0.3/handler.go:60 +0x2ed
    github.com/gin-gonic/gin.(*Context).Next(...)
    	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
    github.com/gin-gonic/gin.CustomRecoveryWithWriter.func1(0xc000ae4200)
    	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/recovery.go:99 +0x82
    github.com/gin-gonic/gin.(*Context).Next(...)
    	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
    github.com/gin-gonic/gin.(*Engine).handleHTTPRequest(0xc000502820, 0xc000ae4200)
    	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/gin.go:489 +0x63e
    github.com/gin-gonic/gin.(*Engine).ServeHTTP(0xc000502820, {0x1441b08, 0xc000c6a1c0}, 0xc000ae4000)
    	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/gin.go:445 +0x1c5
    net/http.serverHandler.ServeHTTP({0x143dec8}, {0x1441b08, 0xc000c6a1c0}, 0xc000ae4000)
    	D:/go1.17/src/net/http/server.go:2878 +0x43b
    net/http.(*conn).serve(0xc000708000, {0x144cf00, 0xc000541410})
    	D:/go1.17/src/net/http/server.go:1929 +0xb08
    created by net/http.(*Server).Serve
    	D:/go1.17/src/net/http/server.go:3033 +0x4e8
    I 2021/11/14 12:47:43 working.go:94:
    

    现在我每次操作标题都得非常小心,要等大纲反应过来了才放心进行其他操作,不然很容易假死,而现在大纲反应太慢了,最近我对标题的操作又比较多,所以用起来比较心累 😂

  • fangly
    订阅者 作者

    可以看下面这个录屏,我只是把一个三级标题变成一级标题(当然这对底层.sy 文件来说意味着要大改结构),大纲反应过来要等 1 分多钟(这个视频有 1 分多钟,在中间可以看到任务管理器中思源 CPU 占用非常高,大纲反应过来之后 CPU 占用迅速降低):

    这个要在大库下才能复现,小库下复现不了

    1 操作
    fangly 在 2021-11-14 14:15:22 更新了该回帖
  • fangly
    订阅者 作者

    除了大纲的反应特别慢,反链面板的反应也特别的慢,对于一个有 100 多条反链的文档,引用块悬浮窗一秒不到就出来了,而反链面板却要 5 秒以上才能出来,我不太理解为什么引用块悬浮窗那么快而反链面板却要这么久,两者本来应该差不太多吧

  • 88250
    订阅者

    下个版本会稍微进行一些参数上的优化,性能应该会和 v1.4.6 接近。 Issue #3405 · siyuan-note/siyuan

    1 回复
  • fangly
    订阅者 作者

    在标题操作上的性能和 v1.4.6 相比还是差得有点多:

    v1.4.6,大纲是秒变化:

    temp110.gif

    v1.5.3,大纲要 50 秒才能变化,在等待大纲变化的期间,能写东西,但是所有引用块都失效,切换到其他文档大纲也不会变化,处于“半假死”状态:

    1 回复
  • 88250
    订阅者

    下个版本重写了数据索引,编辑更新慢的问题需要等数据索引稳定以后再优化。

    这次重构主要是降低数据索引内存使用和提升索引性能,会先发布内测版,老铁有空的话可以帮忙跟进测试下。

请输入回帖内容 ...