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

本贴最后更新于 987 天前,其中的信息可能已经时异事殊

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

image.png

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

image.png

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

  • 思源笔记

    思源笔记是一款隐私优先的个人知识管理系统,支持完全离线使用,同时也支持端到端加密同步。

    融合块、大纲和双向链接,重构你的思维。

    20156 引用 • 77734 回帖 • 1 关注

相关帖子

欢迎来到这里!

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

注册 关于
请输入回帖内容 ...
  • 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 更新了该回帖
  • 请试下重建索引或者删除数据库文件重现初始化库看看。

    1 回复
  • fangly

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

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

    1 回复
  • 麻烦上传一下日志,谢谢。

    1 回复
  • 日志里面暂时没发现问题,能否抽空帮忙做个最小重现测试数据集发邮箱 845765@qq.com 非常感谢。

    1 回复
  • fangly 1

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

    image.png

    简述一下我的复现过程:

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

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

    image.png

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

    1 回复
  • fangly

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

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

    temp101.gif

    测试集:

    20210927211858cnulnll.zip

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

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

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

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

    1 回复
  • fangly 1

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

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

    image.png

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

    image.png

    1 回复
  • 我这里用上次的测试集没能重现 😂

    1 回复
  • fangly

    新测试集发到您邮箱了

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

    image.png

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

    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 更新了该回帖
  • 应该是性能问题,在小库上面我重现不了,大库没做测试。

    目前对于较大列表的保存操作写入数据会比较慢,大纲还有退出等操作是阻塞的,需要等待数据写入以后才返回结果。较大列表的写入性能问题请关注 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 更新了该回帖
  • 最近的几个版本一直在改进数据库事务实现,但某些地方可能因为事务未关闭导致数据库连接泄漏。这两天也在检查代码,感觉应该补得差不多了,等发布以后继续帮忙测测看吧。

    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 更新了该回帖
  • 麻烦把日志文件再上传一下,谢谢。

    1 回复
  • fangly

    log.zip

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

    image.png

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

    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 秒以上才能出来,我不太理解为什么引用块悬浮窗那么快而反链面板却要这么久,两者本来应该差不太多吧

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

    1 回复
  • fangly

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

    v1.4.6,大纲是秒变化:

    temp110.gif

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

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

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

请输入回帖内容 ...

推荐标签 标签

  • SQLite

    SQLite 是一个进程内的库,实现了自给自足的、无服务器的、零配置的、事务性的 SQL 数据库引擎。SQLite 是全世界使用最为广泛的数据库引擎。

    4 引用 • 7 回帖
  • Flutter

    Flutter 是谷歌的移动 UI 框架,可以快速在 iOS 和 Android 上构建高质量的原生用户界面。 Flutter 可以与现有的代码一起工作,它正在被越来越多的开发者和组织使用,并且 Flutter 是完全免费、开源的。

    39 引用 • 92 回帖
  • SpaceVim

    SpaceVim 是一个社区驱动的模块化 vim/neovim 配置集合,以模块的方式组织管理插件以
    及相关配置,为不同的语言开发量身定制了相关的开发模块,该模块提供代码自动补全,
    语法检查、格式化、调试、REPL 等特性。用户仅需载入相关语言的模块即可得到一个开箱
    即用的 Vim-IDE。

    3 引用 • 31 回帖 • 82 关注
  • CentOS

    CentOS(Community Enterprise Operating System)是 Linux 发行版之一,它是来自于 Red Hat Enterprise Linux 依照开放源代码规定释出的源代码所编译而成。由于出自同样的源代码,因此有些要求高度稳定的服务器以 CentOS 替代商业版的 Red Hat Enterprise Linux 使用。两者的不同在于 CentOS 并不包含封闭源代码软件。

    238 引用 • 224 回帖
  • 分享

    有什么新发现就分享给大家吧!

    245 引用 • 1776 回帖 • 1 关注
  • Postman

    Postman 是一款简单好用的 HTTP API 调试工具。

    4 引用 • 3 回帖 • 5 关注
  • C

    C 语言是一门通用计算机编程语言,应用广泛。C 语言的设计目标是提供一种能以简易的方式编译、处理低级存储器、产生少量的机器码以及不需要任何运行环境支持便能运行的编程语言。

    83 引用 • 165 回帖 • 5 关注
  • 七牛云

    七牛云是国内领先的企业级公有云服务商,致力于打造以数据为核心的场景化 PaaS 服务。围绕富媒体场景,七牛先后推出了对象存储,融合 CDN 加速,数据通用处理,内容反垃圾服务,以及直播云服务等。

    26 引用 • 222 回帖 • 167 关注
  • 域名

    域名(Domain Name),简称域名、网域,是由一串用点分隔的名字组成的 Internet 上某一台计算机或计算机组的名称,用于在数据传输时标识计算机的电子方位(有时也指地理位置)。

    43 引用 • 208 回帖 • 1 关注
  • 电影

    这是一个不能说的秘密。

    120 引用 • 598 回帖
  • Swagger

    Swagger 是一款非常流行的 API 开发工具,它遵循 OpenAPI Specification(这是一种通用的、和编程语言无关的 API 描述规范)。Swagger 贯穿整个 API 生命周期,如 API 的设计、编写文档、测试和部署。

    26 引用 • 35 回帖
  • 学习

    “梦想从学习开始,事业从实践起步” —— 习近平

    163 引用 • 473 回帖
  • 一些有用的避坑指南。

    69 引用 • 93 回帖
  • GraphQL

    GraphQL 是一个用于 API 的查询语言,是一个使用基于类型系统来执行查询的服务端运行时(类型系统由你的数据定义)。GraphQL 并没有和任何特定数据库或者存储引擎绑定,而是依靠你现有的代码和数据支撑。

    4 引用 • 3 回帖 • 16 关注
  • 星云链

    星云链是一个开源公链,业内简单的将其称为区块链上的谷歌。其实它不仅仅是区块链搜索引擎,一个公链的所有功能,它基本都有,比如你可以用它来开发部署你的去中心化的 APP,你可以在上面编写智能合约,发送交易等等。3 分钟快速接入星云链 (NAS) 测试网

    3 引用 • 16 回帖
  • 链书

    链书(Chainbook)是 B3log 开源社区提供的区块链纸质书交易平台,通过 B3T 实现共享激励与价值链。可将你的闲置书籍上架到链书,我们共同构建这个全新的交易平台,让闲置书籍继续发挥它的价值。

    链书社

    链书目前已经下线,也许以后还有计划重制上线。

    14 引用 • 257 回帖 • 1 关注
  • Angular

    AngularAngularJS 的新版本。

    26 引用 • 66 回帖 • 524 关注
  • 正则表达式

    正则表达式(Regular Expression)使用单个字符串来描述、匹配一系列遵循某个句法规则的字符串。

    31 引用 • 94 回帖 • 2 关注
  • Markdown

    Markdown 是一种轻量级标记语言,用户可使用纯文本编辑器来排版文档,最终通过 Markdown 引擎将文档转换为所需格式(比如 HTML、PDF 等)。

    165 引用 • 1474 回帖
  • Spring

    Spring 是一个开源框架,是于 2003 年兴起的一个轻量级的 Java 开发框架,由 Rod Johnson 在其著作《Expert One-On-One J2EE Development and Design》中阐述的部分理念和原型衍生而来。它是为了解决企业应用开发的复杂性而创建的。框架的主要优势之一就是其分层架构,分层架构允许使用者选择使用哪一个组件,同时为 JavaEE 应用程序开发提供集成的框架。

    942 引用 • 1458 回帖 • 109 关注
  • React

    React 是 Facebook 开源的一个用于构建 UI 的 JavaScript 库。

    192 引用 • 291 回帖 • 430 关注
  • 钉钉

    钉钉,专为中国企业打造的免费沟通协同多端平台, 阿里巴巴出品。

    15 引用 • 67 回帖 • 348 关注
  • Vim

    Vim 是类 UNIX 系统文本编辑器 Vi 的加强版本,加入了更多特性来帮助编辑源代码。Vim 的部分增强功能包括文件比较(vimdiff)、语法高亮、全面的帮助系统、本地脚本(Vimscript)和便于选择的可视化模式。

    28 引用 • 66 回帖 • 7 关注
  • Elasticsearch

    Elasticsearch 是一个基于 Lucene 的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎,基于 RESTful 接口。Elasticsearch 是用 Java 开发的,并作为 Apache 许可条款下的开放源码发布,是当前流行的企业级搜索引擎。设计用于云计算中,能够达到实时搜索,稳定,可靠,快速,安装使用方便。

    116 引用 • 99 回帖 • 249 关注
  • JVM

    JVM(Java Virtual Machine)Java 虚拟机是一个微型操作系统,有自己的硬件构架体系,还有相应的指令系统。能够识别 Java 独特的 .class 文件(字节码),能够将这些文件中的信息读取出来,使得 Java 程序只需要生成 Java 虚拟机上的字节码后就能在不同操作系统平台上进行运行。

    180 引用 • 120 回帖 • 1 关注
  • 创业

    你比 99% 的人都优秀么?

    83 引用 • 1398 回帖
  • uTools

    uTools 是一个极简、插件化、跨平台的现代桌面软件。通过自由选配丰富的插件,打造你得心应手的工具集合。

    5 引用 • 13 回帖