Make QueuedTracking more stable when running out of memory
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
首先检查启用队列的流程和 queuedtracking::test 命令，然后跟踪内存耗尽时 Redis 锁和队列跟踪请求的处理方式。评估拟议的 Redis eviction-policy 检查和故障报告。完成的标准是，低内存条件不会悄无声息地破坏队列或其锁，并且相关检查或错误都有测试覆盖。
由索引模型根据 Issue 内容生成。
描述
Currently, we assume that always enough memory is available. Usually processing the data from Redis into the database should be kinda fast and the queue should not take loads of space. However, if there's eg a problem with tracking then it might just collect requests into Redis and never remove them from there when it is eg not possible to acquire a lock see #22 and #24 . In such cases it might be possible to run out of memory over time.
We should think about ways to make the Queue better handle such problems.
- Maybe we can detect a no more memory available and print or log a clear error message.
- Also when enabling the queue and when testing the queue via "queuedtracking::test", we should check whether eg the
noevictionorallkeys-lrueviction policy is activated (these are OK). Other policies might result in problems when it comes to low memory and will most likely always release our lock.
Background:
If no more memory is available, and eg volatile-lru is set, it would always evict first our key for the lock as it is probably the only one with an expire set. The same for volatile-random etc.
From http://redis.io/topics/lru-cache:
volatile-lru: evict keys trying to remove the less recently used (LRU) keys first, but only among keys that have an expire set, in order to make space for the new data added.
allkeys-lru: evict keys trying to remove the less recently used (LRU) keys first, in order to make space for the new data added
I was also thinking about using two databases, one for the lock etc and one for the actual tracking requests but this doesn't solve much. We could have had a small database just for the lock which doesn't need much space, maybe 1MB. This way we would make sure to never evict a lock key etc but I think it is not really needed as it makes configuration more difficult etc.
Maybe there are other things we can do too?
- 主要语言
- PHP
- 星标
- 87
- 派生
- 42
- 平均合并
- 1 天 13 小时
- 30 天内合并 PR
- 10
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
matomo-org/plugin-QueuedTracking 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 58/100
matomo-org/plugin-QueuedTracking#324 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
matomo-org/plugin-QueuedTracking#320 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 50/100
matomo-org/plugin-QueuedTracking#311 ·
维护者通常 1 天内回复
-
enhancement
难度 3/5 1-2 天 新手友好度 42/100
matomo-org/plugin-QueuedTracking#308 ·
维护者通常 1 天内回复
-
enhancement triaged
难度 4/5 3-5 天 新手友好度 43/100
matomo-org/plugin-QueuedTracking#296 · 2 条评论 ·
维护者通常 1 天内回复
查看 matomo-org/plugin-QueuedTracking 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 71/100
Automattic/blocks-engine#3438 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
getgrav/grav-plugin-api#66 ·
-
Document Laravel 12/13 attributes that work in modules (UsePolicy, ObservedBy, UseFactory, Bind)未关闭enhancement
难度 2/5 1-3 小时 新手友好度 74/100
nWidart/laravel-modules#2236 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 68/100
-
难度 1/5 1 小时以内 新手友好度 92/100
维护者通常 1 天内回复