chrome://tracing/ Database::ReleaseCacheMemorylfNeeded chrome高cpu占用分析

Release Cache Memory lf Needed

 

chrome Database::ReleaseCacheMemorylfNeeded

 

record选项

Web developer
Input latency输入延迟
Rendering
UI Rendering
Javascript and rendering
Frame Viewer
Chrome developer (overall)
Chrome developer (navigation)
Manually select settings

完全搜不到

 

overall和navigation的区别

两者不是包含关系，各有独特的项

 

---

 

 分析

任务管理器中可以看到只有主进程CPU占用率很高，所以只需看主进程

 

 

 

点这个放大镜就能直接跳转到https://source.chromium.org/chromium/chromium/src/+/main:sql/database.cc?q=Database::ReleaseCacheMemoryIfNeeded&ss=chromium

不错，根据源码来看，这个大概是用来释放sqlite在内存页面中的缓存？

看ThreadPool_RunTask参数

src_file"storage/browser/quota/quota_manager_impl.cc"
src_func"NotifyStorageAccessed"

直接在source.chromium.org还搜不到。。。代码改了，还得history回到旧版

 

// Called by storage backends via proxy.

// Quota-managed storage backends should call this method when storage is accessed. Used to maintain LRU ordering.

void NotifyStorageAccessed(const url::Origin& origin,

blink::mojom::StorageType type,

base::Time access_time);

大概是service worker的缓存的文件太大了？没法在内存中存下

quota

概述
配额系统的主要作用是在浏览器级别和源级别设置和强制执行磁盘使用限制（有关这些限制值，请参阅 ./quota_settings.cc）。配额系统仅管理特定 Web 平台存储 API 的磁盘使用情况。

为了让存储后端与配额系统集成，它必须实现 QuotaClient 接口。

配额系统的大部分工作目前都是在浏览器进程的 IO 线程上完成的。有计划将配额转移到存储服务，它将在桌面平台上以自己的进程运行。

 

---

 

CrBrowserMain这个函数似乎没什么明显的异常

 

 

解密了解密了，原来在args参数里，下图可以看到service_worker_storage.cc里的"FindRegistrationForScope"导致的

 

---

 

删了几个大的service worker文件夹，居然还是高cpu。。，原因还是"components/services/storage/service_worker/service_worker_storage.cc" "FindRegistrationForScope"

难道要全删了