Tránh trao đổi trên ElastiCache Redis

Chúng tôi đã gặp rắc rối liên tục với việc hoán đổi ví dụ ElastiCache Redis của chúng tôi. Amazon dường như có một số giám sát nội bộ thô tại chỗ thông báo các đột biến sử dụng hoán đổi và chỉ cần khởi động lại phiên bản ElastiCache (do đó mất tất cả các mục được lưu trong bộ nhớ cache của chúng tôi). Đây là biểu đồ của BytesUsedForCache (dòng màu xanh) và SwapUsage (dòng màu cam) trên ví dụ ElastiCache của chúng tôi trong 14 ngày qua:

Bạn có thể thấy mô hình sử dụng trao đổi ngày càng tăng dường như kích hoạt khởi động lại phiên bản ElastiCache của chúng tôi, trong đó chúng tôi mất tất cả các mục được lưu trong bộ nhớ cache (BytesUsedForCache giảm xuống 0).

Tab 'Sự kiện bộ nhớ cache' trong bảng điều khiển ElastiCache của chúng tôi có các mục tương ứng:

ID nguồn | Loại | Ngày | Biến cố

cache-dụ-id | cụm bộ đệm | Thứ ba ngày 22 tháng 9 07:34:47 GMT-400 2015 | Nút bộ nhớ cache 0001 được khởi động lại

cache-dụ-id | cụm bộ đệm | Thứ ba ngày 22 tháng 9 07:34:42 GMT-400 2015 | Lỗi khởi động lại bộ đệm cache trên nút 0001

cache-dụ-id | cụm bộ đệm | CN ngày 20 tháng 9 11:13:05 GMT-400 2015 | Nút bộ nhớ cache 0001 được khởi động lại

cache-dụ-id | cụm bộ đệm | Ngày 17 tháng 9 22:59:50 GMT-400 2015 | Nút bộ nhớ cache 0001 được khởi động lại

cache-dụ-id | cụm bộ đệm | Thứ tư 16 tháng 9 10:36:52 GMT-400 2015 | Nút bộ nhớ cache 0001 được khởi động lại

cache-dụ-id | cụm bộ đệm | Thứ ba ngày 15 tháng 9 05:02:35 GMT-400 2015 | Nút bộ nhớ cache 0001 được khởi động lại

(bắn tỉa các mục trước đó)

Amazon tuyên bố :

SwapUsage - trong sử dụng bình thường, cả Memcached và Redis đều không được thực hiện giao dịch hoán đổi

Cài đặt có liên quan (không mặc định) của chúng tôi:

• Kiểu sơ thẩm: cache.r3.2xlarge
• maxmemory-policy: allkeys-lru (chúng tôi đã sử dụng biến động-lru mặc định trước đây mà không có nhiều khác biệt)
• maxmemory-samples: 10
• reserved-memory: 2500000000
• Kiểm tra lệnh INFO trên ví dụ, tôi thấy mem_fragmentation_ratiotrong khoảng từ 1 đến 1,05

Chúng tôi đã liên hệ với bộ phận hỗ trợ AWS và không nhận được nhiều lời khuyên hữu ích: họ đề nghị tăng tốc bộ nhớ dành riêng thậm chí cao hơn (mặc định là 0 và chúng tôi có 2,5 GB dành riêng). Chúng tôi không có bản sao hoặc ảnh chụp nhanh được thiết lập cho trường hợp bộ đệm này, vì vậy tôi tin rằng không có BGSAVE nào xảy ra và gây ra việc sử dụng bộ nhớ bổ sung.

Giới maxmemoryhạn của bộ đệm reserved-memory. Vì một số lý do, Amazon đã tăng cường cài đặt swappiness cho hệ điều hành. Bất kỳ ý tưởng nào tại sao chúng tôi sẽ gây ra việc sử dụng trao đổi nhiều như vậy trên ElastiCache / Redis hoặc cách giải quyết mà chúng tôi có thể thử?

Vì không ai khác có câu trả lời ở đây, tôi nghĩ tôi sẽ chia sẻ điều duy nhất có hiệu quả với chúng tôi. Đầu tiên, những ý tưởng này không hoạt động:

• loại đối tượng bộ đệm lớn hơn: gặp vấn đề tương tự trên các trường hợp nhỏ hơn so với bộ đệm .r3.2xlarge chúng tôi hiện đang sử dụng
• điều chỉnh maxmemory-policy: không dễ bay hơi-lru hay allkeys-lru dường như làm cho bất kỳ sự khác biệt
• Nhảy lên maxmemory-samples
• Nhảy lên reserved-memory
• buộc tất cả khách hàng phải đặt thời gian hết hạn, thường là tối đa 24 giờ với một vài người gọi hiếm hoi cho phép tối đa 7 ngày, nhưng đại đa số người gọi sử dụng thời gian hết hạn 1-6 giờ.

Đây là những gì cuối cùng đã giúp, rất nhiều: chạy một công việc cứ sau mười hai giờ chạy SCAN trên tất cả các khóa trong khối ( COUNT) là 10.000. Đây là BytesUsedForCache của cùng một trường hợp đó, vẫn là một cá thể cache.r3.2xlarge dưới mức sử dụng thậm chí còn nặng hơn trước, với cùng các cài đặt như trước:

Các răng cưa giảm trong việc sử dụng bộ nhớ tương ứng với thời gian của công việc định kỳ. Trong khoảng thời gian hai tuần này, việc sử dụng trao đổi của chúng tôi đã đạt mức tối đa ~ 45 MB (đứng đầu ở mức ~ 5 GB trước khi khởi động lại trước đó). Và tab Sự kiện Cache trong ElastiCache báo cáo không có thêm sự kiện Khởi động lại bộ đệm.

Đúng vậy, đây có vẻ như là một loại bùn mà người dùng không nên tự làm và Redis nên đủ thông minh để tự mình xử lý việc dọn dẹp này. Vậy tại sao điều này làm việc? Chà, Redis không làm gì nhiều hoặc làm sạch trước các khóa đã hết hạn, thay vào đó dựa vào việc trục xuất các khóa đã hết hạn trong các GET . Hoặc, nếu Redis nhận ra bộ nhớ đã đầy, thì nó sẽ bắt đầu gỡ bỏ các khóa cho mỗi SET mới, nhưng lý thuyết của tôi là tại thời điểm đó Redis đã bị ho.

Tôi biết điều này có thể cũ nhưng tôi đã xem xét điều này trong tài liệu aws.

https://aws.amazon.com/elasticache/pricing/ Họ tuyên bố rằng r3.2xlarge có bộ nhớ 58.2gb.

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Parameter ERIC.Redis.html Họ tuyên bố rằng maxmemory của hệ thống là 62gb (đây là khi chính sách maxmemory khởi động) và nó không thể thay đổi . Có vẻ như không có vấn đề gì với Redis trong AWS, chúng tôi sẽ trao đổi ..