<@U0A71G31CDV> I see this log in cn node and be no...
# questions-and-troubleshooting
p
@Rocky I see this log in cn node and be node, I20260904 162958.498337 140438936626752 page_cache.cpp:90] Fail to adjust cache capacity, delta: -16777216, reason: adjust quota failed
r
This log message is an informational notification (indicated by the
I
at the start) from the StarRocks storage engine's Page Cache module. Meaning of the Log The message
Fail to adjust cache capacity, delta: -16777216, reason: adjust quota failed
indicates that the system attempted to dynamically shrink the memory allocated to the Page Cache, but the request was rejected by the internal memory quota manager. *
delta: -16777216
: The system tried to reduce the cache capacity by exactly 16 MiB (16,777,216 bytes). This is a common step size for StarRocks' background memory reclaimer. *
reason: adjust quota failed
: The underlying cache implementation (which manages memory limits) could not fulfill the request to lower its limit further. This typically happens if the cache is already at its minimum allowed size or if a concurrent operation is locking the quota. Why does this happen? StarRocks periodically monitors the memory usage of BE (Backend) and CN (Compute Node) processes. If the process is under memory pressure or if a "memory reclaimer" task is running, it will try to shrink various caches (like the Page Cache or Metadata Cache) to free up memory for queries or loading. This log is common in environments where: 1. Memory pressure is present: The system is actively trying to reclaim memory. 2. Small Cache Limits: If you have manually set a very small
storage_page_cache_limit
or
datacache_mem_size
, the reclaimer might try to shrink it below a functional threshold. 3. Recent Versions (v3.1+): In newer versions, StarRocks has more aggressive and dynamic memory management that frequently issues these adjustment requests. Is it a problem? In most cases, no. Because it is an
INFO
level log, it is not considered an error. It simply means a background optimization (shrinking the cache) didn't complete. You should only be concerned if: * The nodes are experiencing OOM (Out of Memory) crashes. * You see a high frequency of
WARN
or
ERROR
logs related to memory or
MemTracker
. Recommendations 1. Check Memory Metrics: You can verify the current memory usage and cache limits by visiting the BE/CN web console: * Overall memory:
http://<node_ip>:<be_http_port>/mem_tracker
* Page Cache specific:
http://<node_ip>:<be_http_port>/metrics
(look for
starrocks_be_storage_page_cache_mem_bytes
). 2. Review Configurations: * `storage_page_cache_limit`: Default is 20% of system memory. If you have set this very low, the system may frequently fail to "shrink" it further. * `datacache_mem_size`: If you are using Data Cache (common in shared-data or cloud-native clusters), this parameter controls the memory portion of that cache. 3. Ignore if Stable: If your cluster performance is normal and there are no OOMs, you can safely ignore these INFO logs. References • administration/management/resource_management/Memory_management.md • knowledge/trouble_shooting/fe_memory_problems.md • release_notes/release-2.4.md