کارشناس زن در صحنهٔ آموزشی تولیدشدهٔ بررسی تأخیر و مصرف حافظهٔ Redis.

WIUNIX ACADEMY

وقتی Redis کند می‌شود؛ بررسی حافظه، حذف کلیدها و زمان اجرای دستور

از روی آمار یک بازه تشخیص دهید تأخیر از اجرای دستور، فشار حافظه یا مسیر برنامه می‌آید؛ بدون حذف کلیدها یا تغییر شتاب‌زدهٔ سیاست حافظه و ذخیره‌سازی.

پیشرفته35 دقیقه مطالعهبه‌روزرسانی
محیطت را انتخاب کن

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.

Ubuntu 26.04 — بررسی نصب موجودبررسی‌شده با مستندات رسمی ·

آموزش متناسب با مقادیر تو

تنظیمات این آموزش

مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.

آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.

تنظیم مقادیر برای محیط من2 مقدار قابل‌تغییر

از اینجا شروع کن

در پایان چه چیزی خواهی داشت؟

زمان رخداد را با رشد حافظه، حذف کلیدها، خطاهای نوشتن و مدت اجرای دستورها تطبیق دهید و برای علت احتمالی شواهد جمع کنید.

سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده

مسیرهای مستند برای Ubuntu، Debian و خانوادهٔ Red Hat؛ محصول و کلاینت سازگار باید از قبل نصب باشند. محدودیت هر شاخه در گام نخست آمده است. فرمان‌ها هنگام نگارش روی سرویس واقعی اجرا نشده‌اند.

قبل از شروع

  • Redis مستقل و نصب‌شدهٔ سازگار با نسخهٔ 7.2 یا جدیدتر؛ این راهنما نصب یا تبدیل Redis Cluster را انجام نمی‌دهد.
  • حساب مشاهدهٔ مجاز، سوکت خصوصی موجود، redis-cli سازگار و دسترسی به آمار فعلی برنامه؛ رمز در خط فرمان یا فرم قرار نمی‌گیرد.
  • فرصت بررسی محدود روی میزبان، بدون تغییر persistence، سیاست حذف کلید یا احراز هویت.

تأخیر درخواست فقط زمان اجرای Redis نیست

درخواست برنامه ممکن است برای گرفتن اتصال منتظر بماند، از شبکه عبور کند، در Redis اجرا شود و سپس پاسخ به برنامه برگردد. SLOWLOG فقط زمان اجرای سمت سرور را می‌سنجد؛ کل این مسیر را نشان نمی‌دهد. بنابراین خالی‌بودن آن، علت شبکه یا صف کلاینت را رد نمی‌کند.

در این راهنما نمونهٔ مستقل Redis را از سوکت خصوصی بررسی و زمان‌ها را با آمار برنامه مقایسه می‌کنیم. کلید، تنظیم حافظه و persistence تغییر نمی‌کنند. برای Cluster باید وضعیت هر shard و مسیر توزیع درخواست جدا بررسی شود.

دسترسی مشاهده را محدود و رمز را خارج از فرم نگه دارید

مسیر سوکت و نام کاربر ACL موجود را وارد کنید؛ رمز فقط در prompt خصوصی CLI پرسیده می‌شود و در آرگومان پردازش قرار نمی‌گیرد. مقدارهای فرم در همین تب نگه‌داری و پس از «اعمال» در متن و پنل‌ها یکسان می‌شوند.

این حساب فقط به دستورهای مشاهدهٔ موردنیاز نیاز دارد. خطای ACL را با دادن دستهٔ کامل مجوزهای مدیریتی رفع نکنید. خصوصی‌بودن سوکت نیز به معنی بی‌نیازی از احراز هویت یا حفاظت برنامه نیست.

01

قدم بعدی

پیش از شروع، مسیر ابزار و محل اجرای فرمان‌ها را بررسی کنید

Redis نسخهٔ ۷٫۲ یا بالاتر و redis-cli سازگار باید از قبل نصب باشند. فهرست آزمون فعلی سازنده، Ubuntu نسخهٔ ۲۶٫۰۴، Debian نسخه‌های ۱۲ و ۱۳ و نسخه‌های فرعی مشخصی از Rocky و Alma شاخه‌های ۹ و ۱۰ را نام می‌برد؛ Ubuntu نسخهٔ ۲۶٫۱۰ در آن نیست. انتخاب ۲۶٫۱۰ فقط برای بررسی یک نصب موجود است که سازگاری آن جداگانه تأیید شده؛ ادعای پشتیبانی سازنده نیست. نام محصول و نسخه را بررسی کنید و Redis را بی‌توضیح با Valkey جایگزین نکنید. در خانوادهٔ Debian معمولاً فایل /etc/redis/redis.conf و سرویس redis-server.service دیده می‌شود؛ در بسته‌های RPM ممکن است سرویس redis.service باشد. این نام‌ها برای پیدا کردن نصب‌اند، نه فرض قطعی. مسیر سوکت باید دقیقاً از تنظیمات همان سرویس بیاید؛ وجود هیچ‌یک از دو نمونهٔ /run/redis/redis-server.sock و /run/redis/redis.sock تضمین‌شده نیست.

این مسیرها از مستندات استخراج شده‌اند و آزمون عملی سازگاری محسوب نمی‌شوند. ابتدا /etc/os-release و نسخهٔ دقیق محصول را بررسی کنید. حساب‌ها، دسترسی شبکه و اعتبارنامه‌های محافظت‌شده باید از قبل آماده باشند. برای آماده‌کردن ابزارها، سرویس موجود را دوباره راه‌اندازی نکنید، دیتابیس تازه مقداردهی اولیه نکنید، پورتی روی فایروال باز نکنید و Python سیستم را تغییر ندهید.

bash

کلاینت مدیریت مجاز؛ بررسی‌های مخصوص گره فقط روی همان گرهٔ موجود

cat /etc/os-release
id
command -v redis-cli
redis-cli --version
python3 --version
test -S "/run/redis/redis-server.sock"
stat -c "%U:%G %a %n" "/run/redis/redis-server.sock"
از کجا بدانم درست انجام شد؟

سیستم‌عامل، مسیر و نسخهٔ ابزار با محیط انتخابی سازگار است؛ در صورت تفاوت، پیش از تغییر داده توقف کنید.

02

قدم بعدی

مطمئن شوید دو نمونه‌برداری از یک پردازش‌اند

روی میزبان Redis، نسخه، run_id، uptime، نقش و سیاست حافظه را ثبت کنید. اگر بین دو نمونه run_id عوض شده یا uptime کمتر شده باشد، سرور دوباره راه‌اندازی شده و تفریق مستقیم شمارنده‌ها معتبر نیست.

CONFIG GET فقط تنظیم‌های نام‌برده و غیرمحرمانه را می‌خواند. مقدار صفر برای maxmemory یعنی Redis سقفی در این لایه اعمال نمی‌کند؛ از آن نتیجه نگیرید که حافظهٔ میزبان کافی یا نامحدود است.

bash

میزبان Redis موجود؛ حساب مجاز پایش

redis-cli -s '/run/redis/redis-server.sock' --user 'observer' --askpass INFO server
redis-cli -s '/run/redis/redis-server.sock' --user 'observer' --askpass INFO replication
redis-cli -s '/run/redis/redis-server.sock' --user 'observer' --askpass CONFIG GET maxmemory maxmemory-policy latency-monitor-threshold slowlog-log-slower-than
از کجا بدانم درست انجام شد؟

نمونهٔ Redis و عمر پردازش مشخص‌اند و می‌توانید پیوستگی بازهٔ بررسی را کنترل کنید.

03

قدم بعدی

مصرف داده را با حافظهٔ واقعی پردازش اشتباه نگیرید

used_memory، RSS، اوج مصرف، سهم allocator، بافرها و فشار حافظهٔ میزبان را کنار هم ببینید. maxmemory سقف RSS نیست و بعضی بافرهای موقت replication و AOF در محاسبهٔ حذف کلید حساب نمی‌شوند. هنگام fork مربوط به persistence نیز ممکن است برای copy-on-write حافظهٔ بیشتری لازم شود.

نسبت fragmentation بدون اندازهٔ واقعی داده و بایت مصرف‌شده می‌تواند گمراه‌کننده باشد. پیش از هر تغییر، فضای لازم برای جهش مصرف و وضعیت swap را بسنجید. خاموش‌کردن persistence یا اجرای PURGE نباید واکنش فوری به یک نمودار بالا باشد.

bash

میزبان Redis موجود؛ حساب مجاز پایش

redis-cli -s '/run/redis/redis-server.sock' --user 'observer' --askpass INFO memory
redis-cli -s '/run/redis/redis-server.sock' --user 'observer' --askpass MEMORY STATS
free -m
vmstat 1 5
از کجا بدانم درست انجام شد؟

رشد داده، RSS، بافرها و فشار حافظهٔ میزبان از هم تفکیک شده‌اند.

04

قدم بعدی

شمارنده‌ها را در دو سرِ همان رخداد مقایسه کنید

در آغاز و پایان بازه، زمان و run_id را همراه شمارنده‌ها از مانیتورینگ خصوصی موجود یا ترمینال ثبت کنید. نرخ حذف کلید از اختلاف evicted_keys تقسیم بر ثانیه‌های بازه به دست می‌آید؛ شمارندهٔ کل عمر سرویس، نرخ فعلی نیست.

برای نسبت hit نیز اختلاف hits را بر مجموع اختلاف hits و misses تقسیم کنید؛ اگر مخرج صفر است نتیجه‌ای ندارید. یک نسبت خوب از ابتدای عمر سرویس می‌تواند افت همین چند دقیقه را پنهان کند. برای آسان‌شدن محاسبه شمارنده‌ها را reset نکنید.

bash

میزبان Redis موجود؛ حساب مجاز پایش

date -u +%FT%TZ
redis-cli -s '/run/redis/redis-server.sock' --user 'observer' --askpass INFO server
redis-cli -s '/run/redis/redis-server.sock' --user 'observer' --askpass INFO stats
redis-cli -s '/run/redis/redis-server.sock' --user 'observer' --askpass INFO errorstats
redis-cli -s '/run/redis/redis-server.sock' --user 'observer' --askpass INFO persistence
از کجا بدانم درست انجام شد؟

نمونه‌های قابل‌مقایسه، حذف کلید، miss، خطای OOM و هم‌زمانی کار persistence را نشان می‌دهند.

همهٔ آموزش‌های آکادمی ↗