ویونیکس
گفت‌وگو با کارشناس
← شروع آموزش

WIUNIX ACADEMY

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

صفحهٔ 2 از 2؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.

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

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

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

RHEL / Rocky Linux / AlmaLinux 9 — بررسی نصب موجودبررسی‌شده با مستندات رسمی ·

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

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

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

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

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

اول بدانید حذف این داده چه پیامدی دارد

اگر Redis کش است، حذف بعضی کلیدها فقط زمانی پذیرفتنی است که منبع اصلی و مسیر miss بتوانند بار جبران را تحمل کنند. دادهٔ صف، قفل یا رکورد ماندگار چنین فرضی ندارد و نباید صرفاً برای کم‌کردن خطای حافظه، سیاست allkeys بگیرد.

noeviction تضمین نمی‌کند که میزبان دچار کمبود حافظه نشود؛ در فشار حافظه ممکن است نوشتن را با خطا رد کند. سیاست‌های volatile فقط کلید دارای TTL را نامزد می‌کنند و ممکن است نامزد کافی نداشته باشند. خودِ eviction نیز همیشه شکست نیست؛ اثر آن روی miss، بار مبدأ، تأخیر و صحت کار برنامه را بررسی کنید.

05

قدم بعدی

از SLOWLOG فقط اطلاعات لازم را بیرون بکشید

ورودی SLOWLOG ممکن است کلید، مقدار و اطلاعات کلاینت داشته باشد. فیلتر محلی این پنل فقط شناسهٔ ورودی، زمان، مدت اجرا به میکروثانیه و نام دستور را چاپ می‌کند. دسترسی به دادهٔ اصلی همچنان حساس است و ترمینال باید خصوصی بماند.

خالی‌بودن خروجی می‌تواند به آستانهٔ بالا یا خاموش‌بودن جمع‌آوری مربوط باشد. نبودن دستور کند در این فهرست، سرعت مسیر برنامه یا سلامت شبکه را ثابت نمی‌کند.

bash

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

redis-cli -s '/run/redis/redis.sock' --user 'observer' --askpass --json SLOWLOG GET 20 | python3 -c 'import json,sys; rows=json.load(sys.stdin); [(print({"id":r[0],"unix_time":r[1],"duration_us":r[2],"verb":r[3][0] if r[3] else ""})) for r in rows]'
از کجا بدانم درست انجام شد؟

فقط فرادادهٔ لازم چاپ شده و واحد مدت اجرا، میکروثانیه، روشن است.

06

قدم بعدی

رخدادهای موجود را با زمان مشکل تطبیق دهید

LATEST و DOCTOR به تنظیم آستانهٔ پایش تأخیر وابسته‌اند. اگر جمع‌آوری خاموش است، این مقاله آن را خودکار فعال نمی‌کند؛ چنین تغییری باید با ثبت مقدار قبلی و تصمیم مسئول سرویس انجام شود.

زمان رخداد را کنار fork، دیسک و AOF، حذف کلید و تغییر بار بگذارید. commandstats هم دربارهٔ اجرای دستورها اطلاعات می‌دهد، نه زمانی که درخواست در صف برنامه برای گرفتن connection مانده است.

bash

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

redis-cli -s '/run/redis/redis.sock' --user 'observer' --askpass LATENCY LATEST
redis-cli -s '/run/redis/redis.sock' --user 'observer' --askpass LATENCY DOCTOR
redis-cli -s '/run/redis/redis.sock' --user 'observer' --askpass INFO commandstats
از کجا بدانم درست انجام شد؟

رخدادهای موجود با فرضیهٔ علت تأخیر تطبیق داده شده‌اند و خاموش‌بودن جمع‌آوری، در صورت وجود، ثبت شده است.

07

قدم بعدی

در صورت مجازبودن، ده ثانیه پاسخ محلی را بسنجید

این مرحله اختیاری است و بار کوچکی با PINGهای تکراری ایجاد می‌کند؛ اندازه‌گیری کاملاً غیرفعال نیست. نتیجه به میلی‌ثانیه است و زمان‌بندی همین کلاینت و مسیر سوکت محلی را هم شامل می‌شود، نه شبکه‌ای که برنامه از آن استفاده می‌کند.

خروج۱۲۴ در پایان ده ثانیه، نتیجهٔ timeout بیرونی است. این خط مبنا را با زمان اتصال، صف و پاسخ در برنامه مقایسه کنید. در میانهٔ رخداد برای جمع‌کردن اطلاعات بیشتر، MONITOR گسترده یا اسکن همهٔ کلیدها را اضافه نکنید.

bash

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

timeout 10s redis-cli -s '/run/redis/redis.sock' --user 'observer' --askpass --latency
از کجا بدانم درست انجام شد؟

یک نمونهٔ کوتاه از پاسخ محلی دارید و آن را با تأخیر سرتاسری برنامه یکی نمی‌دانید.

برای علت احتمالی، تغییر محدود پیشنهاد کنید

اگر برنامه کند شده اما اجرای سرور کوتاه مانده، اول صف اتصال، بازوبسته‌شدن مکرر اتصال‌ها و شبکه را بررسی کنید. اگر eviction و miss با هم بالا رفته‌اند، ظرفیت کش و TTL را با توجه به تحمل بارِ منبع اصلی بررسی کنید.

اگر RSS هنگام persistence بالا می‌رود، برای ظرفیت کافی برنامه‌ریزی کنید؛ خاموش‌کردن ذخیره‌سازی پایدار راه‌حل پیش‌فرض نیست. اگر خود دستور زمان زیادی می‌گیرد، شکل داده و نوع کار را در staging بازتولید کنید. هیچ آستانه یا سیاست حافظه‌ای برای همهٔ این مسئله‌ها مناسب نیست.

بررسی موقت را تمام و شواهد لازم را نگه دارید

نمونهٔ PING با timeout تمام می‌شود و چون تنظیم سرور تغییر نکرده، فرمان برگشت لازم ندارد. زمان بازه، run_id، اختلاف شمارنده‌ها، وضعیت حافظه و فرادادهٔ پاک‌سازی‌شدهٔ دستور کند را نگه دارید و یک اقدام بعدی مشخص بنویسید.

اگر بعداً تغییر تنظیمی مجاز شد، پیش از اعمال مقدار قبلی، اثر آن بر ماندگاری و روش برگشت را ثبت کنید. برای تمیزشدن نمودار، دیتابیس را FLUSH، شمارنده‌ها را reset یا Redis را restart نکنید.

پشتوانهٔ این آموزش

منابع رسمی

وضعیت بررسی هر محیط بالای صفحه مشخص است؛ بررسی مستندات به معنی اجرای عملی همهٔ نسخه‌ها نیست.

ادامهٔ مسیر

قدم بعدی تو

وب و پایگاه داده

آموزش نصب Redis Sentinel در اوبونتو و دبیان

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

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