Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Make QueuedTracking more stable when running out of memory

Abierto
  • ¿Algo no está bien?
#28 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
php, redis
Área
backend, databases

Línea de trabajo

Comienza revisando el flujo de habilitación de la cola y el comando queuedtracking::test; después, sigue cómo se gestionan los bloqueos de Redis y las solicitudes de seguimiento de la cola cuando se agota la memoria. Evalúa las comprobaciones propuestas de la política de eviction de Redis y la notificación de errores. Se considera terminado cuando las condiciones de poca memoria no socavan silenciosamente la cola ni su bloqueo, y las comprobaciones o errores relevantes están cubiertos por pruebas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

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 noeviction or allkeys-lru eviction 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?

Lenguaje dominante
PHP
Estrellas
87
Forks
42
Merge medio
2 d 8 h
PR fusionados (30 d)
4

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de matomo-org/plugin-QueuedTracking

Todos los issues de matomo-org/plugin-QueuedTracking

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.