使用过程中未响应问题

[carson512]

windows 2012 R2 1.4.1.1024
物理内存64G 文件数量确实比较多
目前的Everythine.db文件大概5G左右 索引的内容只留下了文件名 其他都去掉了
everything进程在内存里占用3G左右
不使用一段时间 再搜索的时候出现白板未响应 然后重启进来加载数据库就要很长时间

不知是否是虚拟内存的问题 导致长时间不使用 内存数据被写回硬盘虚拟内存区所以卡顿呢 如何确认下

[void]

检查任务管理器。
在“详细信息”选项卡下，查看工作集（内存）和提交大小。
工作集（内存）= RAM 中的内存。
提交大小 = Everything 请求的内存。
工作集的大小应与提交大小大致相同。
如果 Everything 正在从磁盘分页，则工作集应该会增加。

Everything 可能正在忙于处理更改。
请尝试按修改日期排序，以查看是否有东西在向文件系统发送更改。

Everything 1.5 有 索引日志。
Everything 1.5 可以锁定物理 RAM 中的内存：

• 在 Everything 1.5 中，从 工具 菜单单击 选项。
• 单击左侧的高级选项卡。
• 在显示包含的设置的右侧，搜索：
  lock
• 选择：virtual_lock
• 将值设置为：true
  
• 在显示包含的设置的右侧，搜索：
  working
• 选择：min_working_set_size
• 将值设置为：3758096384
  (3.5GB)
• 选择：max_working_set_size
• 将值设置为：3758096384
  (3.5GB)
• 单击确定。

在内存不足的情况下，Everything 可能仍会被分页到磁盘。

Physical memory 64G, the number of files is indeed quite large
The current Everything.db file is about 5G, the index content only leaves the file name, and the rest is removed
The Everything process occupies about 3G in memory
If it is not used for a period of time, the whiteboard will not respond when searching again, and it will take a long time to load the database after restarting
I wonder if it is a virtual memory problem that causes the memory data to be written back to the virtual memory area of ​​the hard disk when it is not used for a long time, so it is stuck. How to confirm it?

Check the Task Manager.
Under the Details tab, look at the working set (memory) and commit size.
working set (memory) = memory in RAM.
commit size = memory requested by Everything.
working set should be around the same size as the commit size.
working set should be increasing if Everything is being paged from disk.

Everything could be busy processing changes.
Please try sorting by date modified to see if something is spamming your file system with changes.



Everything 1.5 has the index journal.
Everything 1.5 can lock memory in physical RAM:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  lock
• Select: virtual_lock
• Set the value to: true
  
• To the right of Show settings containing, search for:
  working
• Select: min_working_set_size
• Set the value to: 3758096384
  (3.5GB)
• Select: max_working_set_size
• Set the value to: 3758096384
  (3.5GB)
• Click OK.

Everything may still be paged to disk in low memory situations.

[carson512]

目前界面显示排序文件名称
提交（KB）：31,151,100
工作集（KB）：30,912,484
基本一致

那暂时先更新Everything-1.5.0.1383a.x64.zip试下 感谢

检查任务管理器。
在“详细信息”选项卡下，查看工作集（内存）和提交大小。
工作集（内存）= RAM 中的内存。
提交大小 = Everything 请求的内存。
工作集的大小应与提交大小大致相同。
如果 Everything 正在从磁盘分页，则工作集应该会增加。

Everything 可能正在忙于处理更改。
请尝试按修改日期排序，以查看是否有东西在向文件系统发送更改。

Everything 1.5 有 索引日志。
Everything 1.5 可以锁定物理 RAM 中的内存：

• 在 Everything 1.5 中，从 工具 菜单单击 选项。
• 单击左侧的高级选项卡。
• 在显示包含的设置的右侧，搜索：
  lock
• 选择：virtual_lock
• 将值设置为：true
  
• 在显示包含的设置的右侧，搜索：
  working
• 选择：min_working_set_size
• 将值设置为：3758096384
  (3.5GB)
• 选择：max_working_set_size
• 将值设置为：3758096384
  (3.5GB)
• 单击确定。

在内存不足的情况下，Everything 可能仍会被分页到磁盘。

Physical memory 64G, the number of files is indeed quite large
The current Everything.db file is about 5G, the index content only leaves the file name, and the rest is removed
The Everything process occupies about 3G in memory
If it is not used for a period of time, the whiteboard will not respond when searching again, and it will take a long time to load the database after restarting
I wonder if it is a virtual memory problem that causes the memory data to be written back to the virtual memory area of ​​the hard disk when it is not used for a long time, so it is stuck. How to confirm it?

Check the Task Manager.
Under the Details tab, look at the working set (memory) and commit size.
working set (memory) = memory in RAM.
commit size = memory requested by Everything.
working set should be around the same size as the commit size.
working set should be increasing if Everything is being paged from disk.

Everything could be busy processing changes.
Please try sorting by date modified to see if something is spamming your file system with changes.



Everything 1.5 has the index journal.
Everything 1.5 can lock memory in physical RAM:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  lock
• Select: virtual_lock
• Set the value to: true
  
• To the right of Show settings containing, search for:
  working
• Select: min_working_set_size
• Set the value to: 3758096384
  (3.5GB)
• Select: max_working_set_size
• Set the value to: 3758096384
  (3.5GB)
• Click OK.

Everything may still be paged to disk in low memory situations.

[carson512]

昨天更新1.5.0.1383版本后设置了：
virtual_lock：true
依旧只保留文件名的索引配置
索引文件Everythng-1.5a.db 4.46GB 文件的最后修改时间我看是凌晨4点多
刚刚看 再次出现 主界面未响应的情况
内存情况 ：
提交：27,930,532 工作集：27,639,536 整体物理内存使用率65% 仍有余量
目前等待约10分钟 其中间歇有“（未响应）”标识消失的情况
但是左下角的状态栏依旧是排序文件名称的状态

13分钟+ 界面出现了文件列表 左下角的状态栏显示 352,941,177个对象 但是图形界面的操作依旧会变未响应
内存情况 下降至：
提交：22,083,184 工作集：21,695,312 均不断下降

20分钟+ 界面文件列表消失 左下角的状态栏显示 正在扫描 本地磁盘（S:）
内存情况 提升至：
提交：42,904,200 工作集：42,723,772 变动比较缓慢 整体物理内存使用率85%
写这部分内容的时候再次变化
左下角的状态栏显示 Building folder hierarchy
内存情况 下降至：
提交：37,889,392 工作集：37,411,980 整体物理内存使用率80% 还在不断下降

应该还要再等会儿吗
后续还需要具体如何排查问题 感谢