rime
输入法的io写入非常之高,平均每三四个字产生1MB的io写入
rime输入法每开机超过一段时间就会输入起来感觉肉肉的,需要去任务管理器中关闭weaselServer进程方可恢复迅捷.
今天照例关闭进程时撇了一眼他的io写入字节,把我吓一大跳,数量级到达了11位, 换算一下累积io写入达到了十多个GB.可惜当时没有注意他的内存占用是多少.
感觉事情不太对劲,对照了一下其他输入法,均没有如此高的使用时的io写入,想必这是造成我的输入法卡顿的罪魁祸首.
我录了一段视频来展示随着我的输入,weaselServer的io写入的肉眼可见的上涨. 我不晓得他为何会产生如此大的数据量, 这是否正常?
使用的是雾凇方案, 切换到自带方案也有同样的问题. 版本是weasel最新版本, 0.17.4.0
https://github.com/user-attachments/assets/50bbbc2c-fb25-43c3-bb44-b4c903268771
经过process monitor追踪发现是他会实时的进行数据库文件的更新,但是每次只有不到100字节的写入却造成了如此巨量的开销. 我刚才使用gemini cli尝试修复了一下,加了点防抖, 但是没有起到想要的效果. 17:04:04.4281158 WeaselServer.exe 19636 WriteFile C:\Users\revar\AppData\Roaming\Rime\rime_ice.userdb\001014.log SUCCESS Offset: 6,676, Length: 72 17:04:05.0849222 WeaselServer.exe 19636 WriteFile C:\Users\revar\AppData\Roaming\Rime\rime_ice.userdb\001014.log SUCCESS Offset: 6,748, Length: 72 17:04:05.9569996 WeaselServer.exe 19636 WriteFile C:\Users\revar\AppData\Roaming\Rime\rime_ice.userdb\001014.log SUCCESS Offset: 6,820, Length: 72 17:04:06.6731435 WeaselServer.exe 19636 WriteFile C:\Users\revar\AppData\Roaming\Rime\rime_ice.userdb\001014.log SUCCESS Offset: 6,892, Length: 72 17:04:07.2310000 WeaselServer.exe 19636 WriteFile C:\Users\revar\AppData\Roaming\Rime\rime_ice.userdb\001014.log SUCCESS Offset: 6,964, Length: 66 17:04:07.4562742 WeaselServer.exe 19636 WriteFile C:\Users\revar\AppData\Roaming\Rime\rime_ice.userdb\001014.log SUCCESS Offset: 7,030, Length: 66 17:04:07.6816953 WeaselServer.exe 19636 WriteFile C:\Users\revar\AppData\Roaming\Rime\rime_ice.userdb\001014.log SUCCESS Offset: 7,096, Length: 66 17:04:07.9468924 WeaselServer.exe 19636 WriteFile C:\Users\revar\AppData\Roaming\Rime\rime_ice.userdb\001014.log SUCCESS Offset: 7,162, Length: 66 17:04:08.5970428 WeaselServer.exe 19636 WriteFile C:\Users\revar\AppData\Roaming\Rime\rime_ice.userdb\001014.log SUCCESS Offset: 7,228, Length: 72 17:04:09.4250283 WeaselServer.exe 19636 WriteFile C:\Users\revar\AppData\Roaming\Rime\rime_ice.userdb\001014.log SUCCESS Offset: 7,300, Length: 72 17:04:12.7154389 WeaselServer.exe 19636 WriteFile C:\Users\revar\AppData\Roaming\Rime\rime_ice.userdb\001014.log SUCCESS Offset: 7,372, Length: 72
简单看了一下，每次 commit 会造成 leveldb 的 WAL 写入，至于为什么会有这么严重的写放大就不太清楚了（也可能是 taskmgr 统计口径的问题）。解决方案似乎只能是 rime 侧做 batch。
简单看了一下，每次 commit 会造成 leveldb 的 WAL 写入，至于为什么会有这么严重的写放大就不太清楚了（也可能是 taskmgr 统计口径的问题）。解决方案似乎只能是 rime 侧做 batch。
目前观察到的情况是 跟源代码中的逻辑一样 只有开启新的输入时 他会对log文件进行上一次输入的filewrite, 然后问题是我在持续键入未未上屏的情况下, taskmgr的io写入数据一直在暴涨. 此时在process manager中是没有磁盘文件写入的. 就有点不确定是否有真的io写入了. 如果是真的每次输入三个字就会造成ssd硬盘的1MB写入开销多少还是有点遭不住.
接下来我会继续看看taskmgr的统计标准, 和看看能否把这种放大解决一下
简单看了一下，每次 commit 会造成 leveldb 的 WAL 写入，至于为什么会有这么严重的写放大就不太清楚了（也可能是 taskmgr 统计口径的问题）。解决方案似乎只能是 rime 侧做 batch。
目前观察到的情况是 跟源代码中的逻辑一样 只有开启新的输入时 他会对log文件进行上一次输入的filewrite, 然后问题是我在持续键入未未上屏的情况下, taskmgr的io写入数据一直在暴涨. 此时在process manager中是没有磁盘文件写入的. 就有点不确定是否有真的io写入了. 如果是真的每次输入三个字就会造成ssd硬盘的1MB写入开销多少还是有点遭不住.
接下来我会继续看看taskmgr的统计标准, 和看看能否把这种放大解决一下
放大问题我解决不了,等大佬了
今天做了一些更详细的测量，结论是实际上没有问题。
- 虽然的确有很多的 IO 写，
- 但 IO 写并非磁盘写。使用 diskmon 等工具确认，实际写入磁盘并没有那么多
原因是 Weasel Client 和 Weasel Server 通过网络 IPC 交换数据，那当然会产生大量的网络 IO。
好吧,既然这样的话那就先不管io的问题了.
我现在发现让输入法卡顿的原因是chrome导致的,当使用chrome打开过多个视频网站后,就会出现奇卡无比的现象.此时就算关闭所有的标签页也是仍然卡顿.重启weaselServer也无效.只能通过关闭chrome浏览器来解决.
我捕捉到了这一现象,不是很清楚怎么回事,但是卡顿的时候会在process explorer中显示chrome正在等待写资源wait:wrresource与running
此时切换到其他输入法恢复正常.
stack为: ntoskrnl.exe!KeSynchronizeExecution+0x5b66 ntoskrnl.exe!KeWaitForSingleObject+0x1460 ntoskrnl.exe!KeWaitForSingleObject+0x98f ntoskrnl.exe!KeWaitForSingleObject+0x233 ntoskrnl.exe!ExWaitForRundownProtectionRelease+0x7dd ntoskrnl.exe!KeWaitForSingleObject+0x3a29 ntoskrnl.exe!KeWaitForSingleObject+0x1787 ntoskrnl.exe!KeWaitForSingleObject+0x98f ntoskrnl.exe!KeWaitForMultipleObjects+0x2be ntoskrnl.exe!ObWaitForMultipleObjects+0x2f0 win32kfull.sys!NtHWCursorUpdatePointer+0x6b2 0x0000000000000000 win32kbase.sys+0x915b1 win32kfull.sys!NtUserMsgWaitForMultipleObjectsEx+0x3fe 0x0000000000000000 win32u.dll!NtUserMsgWaitForMultipleObjectsEx+0x14 USER32.dll!MsgWaitForMultipleObjectsEx+0x9e chrome.dll!IsSandboxedProcess+0xd0e293 chrome.dll!IsSandboxedProcess+0xd0def2 chrome.dll+0x6dced chrome.dll!IsSandboxedProcess+0x1784929 chrome.dll+0xc62c4e chrome.dll!ChromeMain+0x42f26 chrome.dll!ChromeMain+0x42b7c chrome.dll!ChromeMain+0x41e4f chrome.dll!ChromeMain+0x26ae chrome.dll!ChromeMain+0x19d3 chrome.dll!ChromeMain+0x2c6 chrome.exe+0x3f327 chrome.exe+0x3e12a chrome.exe!IsSandboxedProcess+0xa8c22 KERNEL32.DLL!BaseThreadInitThunk+0x14 ntdll.dll!RtlUserThreadStart+0x21
问了问chatgpt说是Chrome 的 UI / 输入线程，在等待 Windows 图形子系统（win32k）的某个资源释放.
然后拐一下这个issue: https://github.com/rime/weasel/issues/1413
https://github.com/user-attachments/assets/dd7d353d-9c9b-462a-94ff-98fe08626a7e