Redis là một cơ sở dữ liệu trong bộ nhớ cung cấp hiệu suất cực nhanh. Điều này làm cho nó trở thành một giải pháp thay thế hấp dẫn cho cơ sở dữ liệu dựa trên đĩa khi hiệu suất là vấn đề cần quan tâm. Bạn có thể đã sử dụng lưu trữ ScaleGrid cho Redis ™ * để cung cấp năng lượng cho các ứng dụng nhạy cảm với hiệu suất của mình. Làm cách nào để bạn đảm bảo rằng việc triển khai Redis của bạn hoạt động tốt và đáp ứng các yêu cầu của bạn? Bạn sẽ cần biết các chỉ số giám sát nào cho Redis ™ để xem và một công cụ để theo dõi các chỉ số máy chủ quan trọng này để đảm bảo sức khỏe của nó. Redis trả về một danh sách lớn các chỉ số cơ sở dữ liệu khi bạn chạy lệnh thông tin trên Redis shell. Bạn có thể chọn một lựa chọn thông minh các chỉ số có liên quan từ các chỉ số này. Và những điều này có thể giúp bạn đảm bảo sức khỏe của hệ thống và nhanh chóng thực hiện phân tích nguyên nhân gốc rễ của bất kỳ vấn đề nào liên quan đến hiệu suất mà bạn có thể gặp phải.
Bài đăng trên blog này liệt kê các chỉ số cơ sở dữ liệu quan trọng cần theo dõi. Chúng tôi sẽ xem xét từng chỉ số từ góc độ hiệu suất cơ sở dữ liệu và thảo luận về các vấn đề chung và giải pháp liên quan đến chúng.
1. Chỉ số hiệu suất:Thông lượng
Thông lượng cho bạn biết máy chủ của bạn đang thực hiện bao nhiêu hoạt động cơ sở dữ liệu trong một khoảng thời gian cụ thể. Nó phụ thuộc vào khối lượng công việc ứng dụng của bạn và logic kinh doanh của nó. Bằng cách xem lịch sử thông lượng, bạn có thể suy ra kiểu tải trên máy chủ, ví dụ:tải cao điểm, tần suất của tải cao điểm, khung thời gian của tải cao điểm, tải trung bình, v.v.
Bạn có thể thu thập các giá trị chỉ số thông lượng cho tất cả các lệnh chạy trên máy chủ Redis bằng cách thực thi “ thông tin lệnh ”.
127.0.0.1:6379> info commandstats # Commandstats cmdstat_get:calls=797,usec=4041,usec_per_call=5.07 cmdstat_append:calls=797,usec=4480,usec_per_call=5.62 cmdstat_expire:calls=797,usec=5471,usec_per_call=6.86 cmdstat_auth:calls=147,usec=288,usec_per_call=1.96 cmdstat_info:calls=46,usec=902,usec_per_call=19.61 cmdstat_config:calls=2,usec=130,usec_per_call=65.00 cmdstat_eval:calls=796,usec=36950,usec_per_call=46.42 cmdstat_command:calls=796,usec=8578,usec_per_call=10.78
Redis nhóm các lệnh khác nhau của nó thành kết nối, máy chủ, cụm, chung, v.v. Giám sát ScaleGrid cho Redis ™ tổng hợp thông lượng của các lệnh khác nhau thành một trong các nhóm nêu trên. Thông lượng được biểu thị dưới dạng biểu đồ vùng xếp chồng, trong đó chiều cao của mỗi vùng được tô màu cung cấp thông lượng của một nhóm lệnh.
Thông lượng giảm nói chung có thể chỉ ra rằng máy chủ nhận được ít truy vấn hơn. Nó cũng có thể chỉ ra một vấn đề tiềm ẩn, chẳng hạn như một truy vấn đắt tiền. Tương tự, thông lượng tăng lên cho thấy khối lượng công việc chuyên sâu trên máy chủ và độ trễ lớn hơn.
2. Sử dụng bộ nhớ
Bộ nhớ là tài nguyên quan trọng đối với hiệu suất của Redis. Bộ nhớ đã sử dụng xác định tổng số byte được Redis phân bổ bằng cách sử dụng trình cấp phát của nó (libc chuẩn, jemalloc hoặc một trình cấp phát thay thế như tcmalloc).
Bạn có thể thu thập tất cả dữ liệu chỉ số sử dụng bộ nhớ cho phiên bản Redis bằng cách chạy “ bộ nhớ thông tin ”.
127.0.0.1:6379> info memory # Memory used_memory:1007280 used_memory_human:983.67K used_memory_rss:2002944 used_memory_rss_human:1.91M used_memory_peak:1008128 used_memory_peak_human:984.50K
Đôi khi, khi Redis được định cấu hình không có giới hạn bộ nhớ tối đa, việc sử dụng bộ nhớ cuối cùng sẽ đạt đến bộ nhớ hệ thống và máy chủ sẽ bắt đầu phát ra lỗi “Hết bộ nhớ”. Vào những lúc khác, Redis được định cấu hình với giới hạn bộ nhớ tối đa nhưng noeviction chính sách. Điều này sẽ làm cho máy chủ không loại bỏ bất kỳ khóa nào, do đó ngăn chặn bất kỳ ghi nào cho đến khi bộ nhớ được giải phóng. Giải pháp cho những vấn đề như vậy sẽ là định cấu hình Redis với bộ nhớ tối đa và một số chính sách loại bỏ. Trong trường hợp này, máy chủ bắt đầu loại bỏ khóa bằng chính sách loại bỏ khi mức sử dụng bộ nhớ đạt đến mức tối đa.
RSS bộ nhớ (Resident Set Size) là số byte mà hệ điều hành đã cấp cho Redis. Nếu tỷ lệ ‘memory_rss’ so với ‘memory_used’ lớn hơn ~ 1,5, thì nó có nghĩa là bộ nhớ bị phân mảnh. Bộ nhớ bị phân mảnh có thể được khôi phục bằng cách khởi động lại máy chủ.
3. Tỷ lệ truy cập bộ nhớ đệm
Tỷ lệ truy cập bộ nhớ cache thể hiện hiệu quả của việc sử dụng bộ nhớ cache. Về mặt toán học, nó được định nghĩa là (Tổng số lần truy cập phím) / (Tổng số lần truy cập phím + Tổng số lần bỏ lỡ phím).
“ thống kê thông tin ”Lệnh cung cấp keyspace_hits & keyspace_misses dữ liệu chỉ số để tính toán thêm tỷ lệ truy cập bộ nhớ cache cho phiên bản Redis đang chạy.
127.0.0.1:6379> info stats # Stats ............. sync_partial_err:0 expired_keys:10 evicted_keys:12 keyspace_hits:4 keyspace_misses:15 pubsub_channels:0 pubsub_patterns:0 .............
Nếu tỷ lệ truy cập bộ nhớ cache thấp hơn ~ 0,8 thì một lượng đáng kể các khóa được yêu cầu sẽ bị loại bỏ, hết hạn hoặc hoàn toàn không tồn tại. Điều quan trọng là phải xem số liệu này trong khi sử dụng Redis làm bộ nhớ đệm. Tỷ lệ truy cập bộ nhớ cache thấp hơn dẫn đến độ trễ lớn hơn vì hầu hết các yêu cầu đang tìm nạp dữ liệu từ đĩa. Nó chỉ ra rằng bạn cần tăng kích thước bộ nhớ cache của Redis để cải thiện hiệu suất ứng dụng của bạn.
4. Kết nối đang hoạt động
Số lượng kết nối là tài nguyên giới hạn được thực thi bởi hệ điều hành hoặc bởi cấu hình Redis. Theo dõi các kết nối đang hoạt động giúp bạn đảm bảo rằng bạn có đủ kết nối để phục vụ tất cả các yêu cầu của bạn vào thời gian cao điểm.
5. Chìa khóa đã hết hạn / đã hết hạn
Redis hỗ trợ nhiều chính sách trục xuất khác nhau được máy chủ sử dụng khi mức sử dụng bộ nhớ đạt đến giới hạn tối đa. Giá trị dương liên tục của số liệu này là dấu hiệu cho thấy bạn cần mở rộng bộ nhớ.
127.0.0.1:6379> info stats # Stats .............. sync_partial_err:0 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 ..............
Redis hỗ trợ TTL (thời gian tồn tại) tài sản cho mỗi khóa. Máy chủ sẽ xóa khóa nếu TTL được liên kết đã trôi qua. Nếu ứng dụng không xác định thuộc tính này, nó sẽ làm cho dữ liệu hết hạn chồng chất trong bộ nhớ. Giá trị số liệu dương cho thấy dữ liệu hết hạn của bạn đang được dọn dẹp đúng cách.
6. Số liệu nhân rộng
‘connect_slaves’ chỉ số thông báo khả năng tiếp cận của máy chủ nô lệ với máy chủ. Không thể truy cập nô lệ có thể dẫn đến độ trễ đọc cao hơn tùy thuộc vào tải đọc trên máy chủ.
127.0.0.1:6379> info replication # Replication role:master/slave connected_slaves:0/master_slave_io_seconds_ago:0 master_repl_offset:0 ..............
‘ master_slave_io_seconds_ago 'Metric cho biết thời gian trôi qua trong quá trình giao tiếp giữa nô lệ và chủ. Giá trị cao hơn cho số liệu này có thể là dấu hiệu của các vấn đề trên máy chủ / máy chủ hoặc một số sự cố mạng. Nó tiếp tục khiến nô lệ cung cấp dữ liệu cũ.
Kết luận
Chúng tôi đã đề cập đến một số chỉ số quan trọng sẽ cung cấp khả năng hiển thị tốt về tình trạng và hiệu suất của máy chủ cơ sở dữ liệu của bạn. Có thể có những người khác có liên quan đến các máy chủ cơ sở dữ liệu cụ thể của bạn và các trường hợp sử dụng. Chúng tôi khuyên bạn nên xem qua và hiểu tất cả các chỉ số được báo cáo bởi lệnh "info".
Nếu bạn cần trợ giúp quản lý dịch vụ lưu trữ AWS của mình để triển khai Redis ™, vui lòng liên hệ với chúng tôi qua email tại [email protected] hoặc trên Twitter @scalegridio.
