-
开启同步后,思源开启缓慢!提供个思路
2024-11-24 00:20实际上现在就是这样的,启动阶段不会真正进行数据交换,只是对比索引,然后决定要锁住哪些文档以避免本地修改和云端造成冲突。
前面我已经说了,启动慢主要是就是因为要加载最新本地快照,加载以后才能对比索引,加载快照时读取文件对象慢是目前的瓶颈。
-
开启同步后,思源开启缓慢!提供个思路
2024-11-24 00:16- 这种场景建议用收集箱
- 最后看的那个笔记也可能需要同步(从云端下载更新),但是不同步之前是无法判断要不要预加载的,这是一个鸡蛋问题
-
开启同步后,思源开启缓慢!提供个思路
2024-11-24 00:01对了,刚刚我说的移动端用最后一个快照的想法实际上也不会有多大提升……因为慢是慢在加载本地快照(就是界面上出现“正在索引数据仓库,获取最新文件...”),而不是慢在下载索引或者对比差异等,这些在库较大时耗时其实不高,主要就是加载快照比较耗时,因为要读取本地仓库最新快照中的所有文件对象。
这个点我们得再看看是否还有优化空间,如果代码实现上优化空间不大的话可能就要考虑下用其他结构来辅助一下,总之,我觉得还是有希望提升突破一下的。
-
开启同步后,思源开启缓慢!提供个思路
2024-11-23 23:50不索引的话会有问题的,相当于外部改动不进快照,如果云端更新了这种情况就无法判断覆盖方向了,只能云端覆盖本地,并且不会生成冲突历史。
移动端上可能可以考虑用最后一个快照,因为移动端上不存在外部更新的情况。
-
开启同步后,思源开启缓慢!提供个思路
2024-11-23 21:16不太可行,因为不进行对比的话是不知道最近修改了哪些文件的,对比放在启动时就是为了加快整个进度,避免进入界面后还要等待太久。
可以等下个版本 v3.1.14 再试试,我们做了一些优化 Issue #13216 · siyuan-note/siyuan
- 并行 数仓索引 和 下载云端快照索引 这两个过程来降低启动时间,在固态盘上测试 1W 个文件且网络良好的情况下大致可以比之前节省 1/3 的启动时间,3K 个文件的情况下大致节省 1/2 的启动时间
- 数仓索引 时使用更高效的遍历函数
filepath.WalkDir
替换filepath.Walk
,大概可以节省 1/5 的遍历时间
-
同步失败: 云端数据已经损坏, 请参考这里解决该问题 (Provider: S3) v3.1.11
2024-11-20 11:21新建云端目录不要用已经使用过的名称,新建一个比如 main2,在最新数据的设备同步完成后再到其他设备上选择该云端目录,以后就统一使用这个云端目录同步就行。
之前的 main 点一次删除就行了,如果数据多,云端删除会比较慢,暂时不用管它,等过几分钟再看看云端目录列表,应该就不会出现并且释放空间了(如果是使用 S3 的话需要自行到 S3 提供商控制面板删除存储桶)。
PS:你正文提供的日志没有出现同步报错,是不是提供错日志文件了?
-
关于每日保留 2 个快照的疑问
2024-11-20 09:56主要是为了权衡性能和可用性,因为大部分快照都是“随机”产生的,过多的快照对性能会造成较大影响(比如影响启动时间),默认保留 2 个在大部分场景下已经能够应对灾难恢复。
补充一下,快照保留机制是固定保留每天的最后一个,其他随机保留,比如配置为每天保留 10 个,那么每天最后的 1 个快照是肯定会保留的,然后在随机选择 9 个保留,剩余的清理。