Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Make QueuedTracking more stable when running out of memory

Đang mở
  • Có gì không ổn?
#28 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
php, redis
Lĩnh vực
backend, databases

Hướng nghiên cứu

Bắt đầu bằng cách xem xét luồng bật queue và lệnh queuedtracking::test, sau đó theo dõi cách các lock của Redis và các yêu cầu theo dõi queue được xử lý khi bộ nhớ cạn kiệt. Đánh giá các kiểm tra được đề xuất đối với chính sách eviction của Redis và việc báo cáo lỗi. Hoàn thành khi các điều kiện thiếu bộ nhớ không âm thầm làm suy yếu queue hoặc lock của nó, và các kiểm tra hoặc lỗi liên quan được bao phủ bằng các bài kiểm thử.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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?

Ngôn ngữ chính
PHP
Star
87
Fork
41
Merge trung bình
3 ngày 17 giờ
Pull request đã merge (30 ngày)
5

Chuẩn bị môi trường

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của matomo-org/plugin-QueuedTracking

Tất cả issue của matomo-org/plugin-QueuedTracking

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.