فرایند مخفی مدیریت حافظه

‫Android 17 و نسخه‌های بالاتر از دیمن مدیریت حافظه (mmd) پشتیبانی می‌کند. این دیمن سیستم، پیکربندی دیمن، تنظیمات، و وظایف نگهداری مداوم تعویض یا ZRAM را مدیریت می‌کند.

پس‌زمینه

قبل‌از معرفی mmd، پیکربندی‌های ZRAM در Android تکه‌تکه بود و سفارشی‌سازی محدودی ارائه می‌داد. ‫mmd با متمرکز کردن مدیریت ZRAM، فعال کردن منطق پیکربندی پیچیده‌تر، و ساده کردن افزودن ویژگی‌های جدید و بهبودهای معماری، به این مشکل رسیدگی می‌کند. mmd همچنین تفکیک واضحی بین فرایند مبتنی بر Java system_server و مدیریت حافظه یا مبادله در سطح هسته ایجاد می‌کند.

معماری و مدیریت ZRAM

پس‌از تکمیل راه‌اندازی (یعنی وقتی sys.boot_completed=1)، mmd_setup تلاش می‌کند تا ZRAM را با پارامترهای مشخص‌شده پیکربندی کند. پس‌از تکمیل راه‌اندازی ZRAM، سیستم سرویس mmd را فعال می‌کند که وظیفه انجام کارهای جاری نگهداری را برعهده دارد.

با پروژه mmd، عملیات نگهداری از system_server با ارسال درخواست‌های Binder به mmd بااستفاده از رابط IMmd آغاز می‌شود. ‫mmd براساس موتور خط‌مشی داخلی خود، وظایف نگهداری مربوط به انجام بازنویسی ZRAM، فشرده‌سازی مجدد، و بازنویسی به‌ازای هر فرایند را انجام می‌دهد. هم زمان‌بندی از ActivityManagerService و هم خط‌مشی‌های نگهداری ZRAM را می‌توان بااستفاده از ویژگی‌های سیستم پیکربندی کرد.

یکپارچه‌سازی سرور سیستم (system_server)

فرایند system_server مبتنی بر Java تعیین می‌کند که mmd چه زمانی فراخوانده شود. این فرایند، پاک‌سازی‌های تعمیر و نگهداری سراسری را از بهینه‌سازی‌های هدفمند حافظه برای هر برنامه جدا می‌کند.

تعمیر و نگهداری عادی پس‌پردازش

نگهداری سراسری ZRAM توسط ActivityManagerService بااستفاده از com.android.server.memory.ZramMaintenance انجام می‌شود.

شکل ۱. جریان زمان‌بندی نگهداری ZRAM.

• موتور زمان‌بندی: ZramMaintenance یک کار پس‌زمینه دوره‌ای را با JobScheduler Android ثبت می‌کند.
• محدودیت‌های کار: برای جلوگیری از لکنت رابط کاربری پیش‌زمینه یا رقابت واحد پردازش مرکزی، کار به‌طور صریح با setRequiresDeviceIdle(true) و setRequiresBatteryNotLow(true) پیکربندی شده است.
• راه‌اندازی پوشه: وقتی زمان‌بند onStartJob() راه‌اندازی می‌کند، system_server mmd.doZramMaintenanceAsync() را فرا می‌خواند. این یک تماس یک‌طرفه ناهم‌زمان Binder است؛ system_server منتظر نمی‌ماند تا پاک‌سازی‌های نگهداری تمام شود. ‫mmd این را در یک رشته کارگر پس‌زمینه‌ای در صف قرار می‌دهد تا فشرده‌سازی مجدد و نوشتن مجدد را به‌صورت متوالی انجام دهد.

بازنویسی به‌ازای هر فرایند

ActivityManagerService بااستفاده از com.android.server.am.CachedAppOptimizer، تخلیه حافظه هدفمند برای هر فرایند را مدیریت می‌کند.

شکل ۲. جریان بازنویسی mmd به‌ازای هر فرایند.

وقتی فرایندی به وضعیت حافظه نهان پس‌زمینه منتقل می‌شود، ActivityManager فشرده‌سازی حافظه را انجام می‌دهد. اگر بستن ناشی از کمبود حافظه فرایند برای کاربر قابل‌مشاهده باشد، یعنی فرایند میزبان یک «فعالیت» باشد، و اگر بازنویسی ZRAM برای هر فرایند ردپای حافظه فرایند را به نزدیک صفر برساند، سیستم این مراحل را دنبال می‌کند:

1. پس‌از فشرده‌سازی، CachedAppOptimizer یک پیام تأخیری (ZRAM_WRITEBACK_MSG) را به گرداننده فشرده‌سازی داخلی خود ارسال می‌کند (با تأخیر mZramWritebackWaitSeconds).
2. وقتی تأخیر منقضی می‌شود، ActivityManager توصیفگر فایل فرایند امنی را باز می‌کند pidfd.
3. سرور سیستم با mmd.asyncWritebackProcessZramMemory(pfd, callback) تماس می‌گیرد.
4. mmd ioctl بازنویسی هر فرایند را اجرا می‌کند و بااستفاده از IMmdProcessWritebackCallback گزارش می‌دهد. اگر موفقیت‌آمیز باشد، ‫ActivityManager پرچم گزارش فرایند (setIsZramWrittenBack(app, true)) را برای تقویت oom_score_adj فرایند تنظیم می‌کند و سنجه‌ها را در FrameworkStatsLog.ZRAM_WRITEBACK_EVENT ثبت می‌کند.

واکشی اولیه برای هر پردازش

وقتی کاربر برنامه‌ای را که قبلاً در حافظه نهان ذخیره شده است دوباره راه‌اندازی می‌کند (به‌دلیل UNFREEZE_REASON_ACTIVITY از حالت تعلیق خارج می‌شود)، ActivityManager تأخیر در راه‌اندازی برنامه را که ناشی از خطاهای صفحه اصلی از فضای ذخیره‌سازی پشتیبان است به‌حداقل می‌رساند:

1. CachedAppOptimizer رویداد لغو توقف را رهگیری می‌کند و prefetchZram(app) را فراخوانی می‌کند.
2. سرور سیستم pidfd برنامه را در سراسر Binder بااستفاده از mmd.asyncPrefetchProcessZramMemory(pfd) توزیع می‌کند. ‫mmd دستور ioctl ZRAM_ANDROID_IOC_PROCESS_PREFETCH را صادر می‌کند و به هسته دستور می‌دهد صفحه‌های مبادله‌شده را به‌صورت ناهم‌زمان در RAM پیش‌دریافت کند، درحالی‌که رشته اصلی رابط کاربری برنامه درحال مقداردهی اولیه است.

نمای کلی تکالیف نگهداری و پس‌پردازش

این بخش عملیات نگهداری پس‌زمینه‌ای و وظایف پس‌پردازش را که mmd برای بهینه‌سازی فضای مبادله و حافظه سیستم اجرا می‌کند توضیح می‌دهد.

تعمیر و نگهداری در ماه

در mmd، نگهداری به پاک‌سازی‌های برنامه‌ریزی‌شده و پس‌زمینه‌ای نگهداری اشاره دارد که فضای مبادله و استفاده از حافظه فیزیکی را بدون تأثیر بر عملکرد پیش‌زمینه کاربر فعال بهینه‌سازی می‌کند. به‌جای انجام جاروهای هم‌زمان و پیوسته (که باعث بیدار شدن شدید CPU و لرزش واسط کاربر می‌شود)، تعمیر و نگهداری به‌صورت ناهم‌زمان انجام می‌شود:

1. ‫system_server به‌صورت دوره‌ای doZramMaintenanceAsync() را در سراسر Binder فعال می‌کند.

2. mmd درخواست را در صف کار پس‌زمینه قرار می‌دهد LowPrioWorkItem::ZramMaintenance.

3. در mmd یک رشته کارگر واحد وجود دارد که هم صف اولویت بالا و هم صف اولویت پایین را مدیریت می‌کند. عناصر کاری با اولویت بالا (مثل پیش‌دریافت هر فرایند) ابتدا پردازش می‌شوند و می‌توانند عناصر کاری با اولویت پایین را پیش‌بند کنند. نگهداری و بازنویسی برای هر فرایند به‌عنوان موارد کاری با اولویت پایین عمل می‌کنند. وقتی ظاهر می‌شود، رشته کارگر دو عملیات نگهداری اصلی را به‌ترتیب اجرا می‌کند:

   • فشرده‌سازی مجدد ZRAM: صفحات مبادله موجود را جارو می‌کند و صفحات بیکار را بااستفاده از الگوریتم فشرده‌سازی ثانویه با نسبت بالاتر، برای مثال zstd، مجدداً فشرده می‌کند.

   • بازنویسی ZRAM: صفحه‌های غیرفعال را اسکن می‌کند و آن‌ها را به‌طور کامل از RAM به فضای ذخیره‌سازی فلش پشتیبان دستگاه حلقه از فایلی در /data منتقل می‌کند.

تکالیف پس‌پردازش در ZRAM

در واحد ZRAM هسته Linux و معماری mmd، وظایف پس‌پردازش تبدیل‌های ناهم‌زمان اعمال‌شده بر صفحه‌های حافظه پس‌از اینکه قبلاً توسط مسیرهای استاندارد بازپس‌گیری هسته (kswapd یا فشرده‌سازی) مبادله شده‌اند، هستند.

وقتی صفحه‌ای در ابتدا جابه‌جا می‌شود، سیستم سرعت را در اولویت قرار می‌دهد: از یک الگوریتم فشرده‌سازی اولیه سریع (مانند lz4) استفاده می‌کند و صفحه فشرده‌شده را در RAM ذخیره می‌کند. بااین‌حال، با گذشت زمان، بسیاری از صفحه‌های مبادله‌شده سرد یا غیرفعال می‌شوند، برای مثال، برنامه‌هایی که در حافظه نهان پس‌زمینه هستند و برای ساعت‌ها ازسر گرفته نمی‌شوند. قرار دادن صفحه‌های سرد در ZRAM سریع و با فشرده‌سازی سبک غیرمؤثر است.

خط لوله پس‌پردازش

‫mmd چرخه حیات پس‌پردازش چندمرحله‌ای را برای بهینه‌سازی این صفحات پیاده‌سازی می‌کند:

شکل ۳. چرخه حیات صفحه mmd.

1. مرحله ۱: تعویض اولیه (فشرده‌سازی سریع): ابتدا حافظه ازطریق kswapd یا فشرده‌سازی برنامه بازپس‌گیری می‌شود. معمولاً این بازپس‌گیری اولیه بااستفاده از یک الگوریتم فشرده‌سازی سریع مانند lz4 انجام می‌شود و محتوا در RAM ذخیره می‌شود.

2. مرحله ۲: نشان‌گذاری در حالت آماده به‌کار (قدیمی شدن و ردیابی): ردیابی در حالت آماده به‌کار mmd به ردیابی حافظه هسته (CONFIG_ZRAM_TRACK_ENTRY_ACTIME) دسترسی دارد یا از نشان‌گذار نرم‌افزاری در حالت آماده به‌کار برای ردیابی مدت زمانی که صفحات بدون تغییر باقی مانده‌اند استفاده می‌کند.

3. مرحله ۳: پس‌پردازش ۱ - فشرده‌سازی مجدد (بازپس‌گیری در حافظه): صفحه‌هایی که به سن بیکاری فشرده‌سازی مجدد می‌رسند (min_idle_seconds تا max_idle_seconds) تحت فشرده‌سازی مجدد قرار می‌گیرند. mmd در /sys/block/zram0/recompress می‌نویسد تا به هسته دستور دهد صفحه lz4 را از حالت فشرده خارج کند و آن را بااستفاده از zstd دوباره فشرده کند. این کار حافظه دسترسی تصادفی فیزیکی را بدون ایجاد استهلاک نوشتاری فلش بازپس می‌گیرد.

4. مرحله ۴: پس‌پردازش ۲ - بازنویسی (انتقال به فضای ذخیره‌سازی سریع): اگر فشار حافظه ادامه یابد و صفحه‌ها به سن بیکاری بازنویسی (معمولاً ۲۰ ساعت یا بیشتر) برسند، mmd بازنویسی را راه‌اندازی می‌کند. mmd در /sys/block/zram0/idle و /sys/block/zram0/writeback می‌نویسد تا صفحه فشرده‌شده را به‌طور کامل از RAM به حافظه فلش پشتیبان منتقل کند.

پیکربندی راه‌اندازی ZRAM

‫mmd ویژگی‌های تنظیم ZRAM زیر را بار می‌کند و پردازش می‌کند:

دارایی	استفاده کردن	پیش‌فرض
mmd.zram.enabled	آیا تنظیمات mmd ZRAM فعال است یا نه.	false
mmd.zram.num_devices	تعداد دستگاه‌های ZRAM برای پیکربندی. برای شماره N، دستگاه‌های zram0 تا zram<N-1> باید قبل‌از تنظیم sys.boot_completed=1 توسط سیستم وجود داشته باشند. دارایی‌های فهرست دستگاه براساس ZRAM را می‌توان براساس هر دستگاه پیکربندی کرد.	1
mmd.zram.device_priority	مقادیر اولویت‌دار برای ارسال هنگام تماس با swapon.	تنظیم نشده
mmd.zram.comp_algorithm	الگوریتم فشرده‌سازی ZRAM. اگر الگوریتم فشرده‌سازی مشخص نشده باشد، از الگوریتم فشرده‌سازی پیش‌فرض هسته استفاده می‌شود.	تنظیم نشده
mmd.zram.size	اندازه دستگاه ZRAM برحسب بایت، یا درصدی از اندازه RAM دستگاه، برای مثال، 75%.	50%
mmd.zram.writeback.enabled	فعال کردن بازنویسی ZRAM.	false
mmd.zram.writeback.device_size	اندازه دستگاه بازنویسی براساس بایت یا درصد پارتیشن داده. اندازه واقعی دستگاه را می‌توان براساس فضای دردسترس در پارتیشن داده تنظیم کرد.	‫1073741824 (۱ گیگابایت)
mmd.zram.writeback.min_free_space_mib	حداقل فضای آزاد به مبی‌بایت که باید پس‌از راه‌اندازی دستگاه بازنویسی دردسترس باشد.	1536 (۱٫۵ گیبی‌بایت)
mmd.zram.writeback.use_nr_tags_prop	وقتی true، از مقدار موجود در mmd.zram.writeback.nr_tags برای پیکربندی عمق صف دستگاه حلقه پشتیبان بازنویسی ZRAM استفاده می‌کند. این یک راهکار موقت برای شرایطی است که خط‌مشی SELinux فروشنده نمی‌تواند پیکربندی شود تا به mmd اجازه دهد مستقیماً nr_tags دستگاه بلوک پشتیبان /data را بخواند.	false
mmd.zram.writeback.nr_tags	mmd.zram.writeback.use_nr_tags_prop را ببینید.	تنظیم نشده
mmd.zram.recompression.enabled	فعال کردن ویژگی فشرده‌سازی مجدد ZRAM.	false
mmd.zram.recompression.algorithm	الگوریتم فشرده‌سازی مجدد ZRAM ثانویه.	zstd

خصوصیات دستگاه Per-ZRAM

وقتی mmd.zram.num_devices بزرگ‌تر از یک باشد، ویژگی‌های خاص را می‌توان به‌صورت اختیاری براساس هر دستگاه ZRAM پیکربندی کرد. برای این کار، ویژگی را روی مقدار جداشده با کاما که دقیقاً mmd.zram.num_devices عنصر دارد تنظیم کنید. این دارایی‌ها شامل موارد زیر می‌شود:

• mmd.zram.size
• mmd.zram.comp_algorithm
• mmd.zram.device_priority
• mmd.zram.recompression.enabled
• mmd.zram.recompression.huge_idle.enabled
• mmd.zram.recompression.idle.enabled
• mmd.zram.recompression.huge.enabled
• mmd.zram.recompression.threshold_bytes
• mmd.zram.recompression.algorithm
• mmd.zram.writeback.device_size
• mmd.zram.writeback.huge_idle.enabled
• mmd.zram.writeback.idle.enabled
• mmd.zram.writeback.huge.enabled

منسوخ شدن تنظیمات ZRAM موجود

اگرچه swapon_all همچنان در Android برای راه‌اندازی ZRAM و فضای مبادله مبتنی بر دیسک دردسترس است، mmd رویکرد ترجیحی برای مدیریت ZRAM است تا پیکربندی آسان‌تر و ویژگی‌های پیشرفته‌ای مثل فشرده‌سازی مجدد ZRAM ارائه دهد.

وقتی راه‌اندازی ZRAM mmd توسط mmd.zram.enabled فعال شده باشد:

• راه‌اندازی ZRAM در پیاده‌سازی swapon_all به یک عملیات بدون اثر تبدیل می‌شود.
• پیکربندی‌های ZRAM موجود مثل config_zramWriteback در فایل رونهاد config.xml و دارایی‌های سیستم بازنویسی ro.zram.* نادیده گرفته می‌شود.

متغیرهای قابل تنظیم نگهداری ZRAM

نگهداری ZRAM باید بدون نیاز به تنظیمات اضافی کار کند و می‌توانید بااستفاده از دارایی‌های سیستم در این بخش آن را بیشتر تنظیم کنید.

زمان‌بندی نگهداری ZRAM

این دارایی‌ها کنترل می‌کنند که وظایف نگهداری ZRAM چگونه و چه زمانی توسط system_server زمان‌بندی شوند.

دارایی	استفاده کردن	پیش‌فرض
mm.zram.maintenance.first_delay_seconds	تأخیر قبل‌از شروع اولین نگهداری ZRAM.	‫3600 (۱ ساعت)
mm.zram.maintenance.periodic_delay_seconds	تأخیر بین زمان‌بندی‌های نگهداری ZRAM بعدی.	‫3600 (۱ ساعت)
mm.zram.maintenance.require_device_idle	تعیین اینکه آیا نگهداری ZRAM فقط زمانی شروع شود که دستگاه در حالت آماده‌به‌کار باشد.	true
mm.zram.maintenance.require_battery_not_low	تعیین می‌کند که آیا قبل‌از شروع تعمیر و نگهداری ZRAM، باتری نباید کم باشد.	true

خط‌مشی بازنویسی ZRAM

پارامترهای زیر کنترل می‌کنند که چه زمانی و چه نوع حافظه‌ای در دستگاه پشتیبان نوشته شود:

دارایی	استفاده کردن	پیش‌فرض
mmd.zram.writeback.backoff_seconds	زمان بازگشت از آخرین عملیات بازنویسی.	‫600 (۱۰ دقیقه)
mmd.zram.writeback.min_idle_seconds	با mmd.zram.writeback.max_idle_seconds ترکیب می‌شود تا سن غیرفعال بودن صفحه برای واجدشرایط بودن بازنویسی براساس کسر استفاده از حافظه محاسبه شود. سن بیکاری محاسبه‌شده به‌صورت نمایی بین دو پارامتر درون‌یابی می‌شود تا کار در زمانی که تحت فشار حافظه نیست به حداقل برسد.	72000 (۲۰ ساعت)
mmd.zram.writeback.max_idle_seconds	حداکثر ثانیه‌های استفاده‌شده برای محاسبه پویا سن صفحه غیرفعال براساس بهره‌وری حافظه.	‫90000 (۲۵ ساعت)
mmd.zram.writeback.huge.enabled	فعال کردن نوشتن مجدد صفحه HUGE.	false
mmd.zram.writeback.idle.enabled	فعال کردن نوشتن مجدد صفحه IDLE.	true
mmd.zram.writeback.huge_idle.enabled	فعال کردن نوشتن مجدد صفحه HUGE_IDLE.	true
mmd.zram.writeback.min_bytes	حداقل بایت‌ها برای بازنویسی در یک دور بازنویسی غیرفعال.	‫5242880 (۵ مگابایت)
mmd.zram.writeback.max_bytes	حداکثر بایت‌هایی که در یک دور بازنویسی در حالت بیکاری بازنویسی می‌شود.	314572800 (۳۰۰ مبی‌بایت)
mmd.zram.writeback.max_bytes_per_day	حداکثر بایت برای بازنویسی در دوره ۲۴ ساعته.	‫25769803776 (۲۴ گیگابایت)
mmd.zram.writeback.limit.enabled	فعال کردن یا نکردن حسابداری حد بودجه بازنویسی روزانه.	true

خط‌مشی فشرده‌سازی مجدد ZRAM

پارامترهای زیر کنترل می‌کنند که چه زمانی و چه نوع حافظه‌ای دوباره فشرده شود:

دارایی	استفاده کردن	پیش‌فرض
mmd.zram.recompression.backoff_seconds	زمان وقفه از آخرین فشرده‌سازی مجدد.	‫1800 (۳۰ دقیقه)
mmd.zram.recompression.min_idle_seconds	با mmd.zram.recompression.max_idle_seconds ترکیب می‌شود تا سن غیرفعال بودن صفحه برای واجدشرایط بودن برای فشرده‌سازی مجدد براساس کسر استفاده از حافظه محاسبه شود. سن محاسبه‌شده در حالت آماده به‌کار به‌صورت نمایی بین دو پارامتر درونیابی می‌شود تا کار درحالی‌که تحت فشار حافظه نیست به حداقل برسد.	7200 (۲ ساعت)
mmd.zram.recompression.max_idle_seconds	حداکثر ثانیه‌های استفاده‌شده برای محاسبه پویای سن صفحه غیرفعال.	‫14400 (۴ ساعت)
mmd.zram.recompression.threshold_bytes	حداقل اندازه برحسب بایت برای صفحه‌های ZRAM که برای فشرده‌سازی مجدد درنظر گرفته می‌شود.	‫1024 (۱ کیلوبایت)
mmd.zram.recompression.huge.enabled	آیا فشرده‌سازی مجدد صفحه HUGE فعال شود.	true
mmd.zram.recompression.idle.enabled	آیا فشرده‌سازی مجدد صفحه IDLE فعال شود.	true
mmd.zram.recompression.huge_idle.enabled	آیا فشرده‌سازی مجدد صفحه HUGE_IDLE فعال شود.	true

ردیابی صفحه آزاد ZRAM

mmd نگهداری ZRAM صفحه‌های ZRAM را براساس مدت زمانی که از آخرین دسترسی به آن‌ها می‌گذرد به‌عنوان غیرفعال علامت‌گذاری می‌کند. برای استفاده از این ویژگی باید پیکربندی‌های هسته CONFIG_ZRAM_TRACK_ENTRY_ACTIME یا CONFIG_ZRAM_MEMORY_TRACKING فعال شود. ‫CONFIG_ZRAM_TRACK_ENTRY_ACTIME به‌طور پیش‌فرض در هسته‌های GKI نسخه ۶.۱۸ و بالاتر فعال است. در هسته‌های قدیمی‌تر، این ویژگی سربار حافظه دارد و به‌طور پیش‌فرض فعال نیست.

اگر پیکربندی هسته فعال نباشد، mmd نگهداری ZRAM به منطق جایگزین نرم‌افزاری برای ردیابی صفحه‌های ZRAM غیرفعال برمی‌گردد:

1. وقتی mmd شروع می‌شود، همه صفحه‌های ZRAM به‌عنوان غیرفعال علامت‌گذاری می‌شود.

2. تا زمانی که دوره احتیاطی لازم سپری نشده است، از نگهداری‌های بعدی ZRAM صرف‌نظر شود.

3. بازنویسی ZRAM یا فشرده‌سازی مجدد صفحه‌های غیرفعال. اگر به‌دلیل محدودیت‌های بازنویسی، صفحه‌های بیکار باقی مانده باشد، mmd در نگهداری بعدی بدون علامت‌گذاری صفحه‌های جدید به‌عنوان بیکار، به بازنویسی صفحه‌ها ادامه می‌دهد (مرحله ۴ رد می‌شود).

4. اگر همه صفحه‌های غیرفعال بازنویسی شدند، همه صفحه‌های ZRAM را دوباره به‌عنوان غیرفعال علامت‌گذاری کنید و به مرحله ۲ برگردید. اگر بازنویسی ZRAM غیرفعال باشد، وقتی فشرده‌سازی مجدد ZRAM پس‌از مدت‌زمان بیکاری فشرده‌سازی مجدد اتفاق می‌افتد، mmd همه صفحه‌های ZRAM را به‌عنوان بیکار علامت‌گذاری می‌کند.

راهنمایی عیب‌یابی و اعتبارسنجی

از مراحل اعتبارسنجی و روش‌های عیب‌یابی زیر برای تأیید و تشخیص عملکرد mmd و ZRAM استفاده کنید.

تأیید درستی راه‌اندازی ZRAM

برای تأیید اینکه mmd درطول راه‌اندازی ZRAM را باموفقیت پیکربندی کرده است:

1. الگوریتم فشرده‌سازی فعال و اندازه دیسک را بررسی کنید:

   cat /sys/block/zram0/comp_algorithm
   cat /sys/block/zram0/disksize
   

2. درستی‌سنجی mmd ویژگی سیستم و وضعیت سرویس درحال اجرا:

   getprop | grep mmd.zram
   dumpsys -l | grep mmd
   

اعتبارسنجی نگهداری و بازنویسی ZRAM

تأیید کنید که وظایف نگهداری بازنویسی و فشرده‌سازی مجدد ZRAM عمل می‌کنند:

1. وضعیت دستگاه بلوک پشتیبان را بررسی کنید:

   cat /sys/block/zram0/bd_stat
   

2. با پایش /sys/block/zram0/mm_stat، کارایی فشرده‌سازی مجدد را بررسی کنید. تغییرات در اندازه‌های داده فشرده باید پس‌از چرخه‌های نگهداری ظاهر شود.

اعتبارسنجی بازنویسی به‌ازای هر فرایند

از موارد زیر می‌توان برای تأیید عملکرد بازنویسی هر فرایند استفاده کرد:

• برای گزارش‌های موفق بازنویسی یا تشخیص خرابی، adb logcat -s mmd را بررسی کنید.

مشکلات رایج و عیب‌یابی

در زیر موقعیت‌های خطای رایجی که کاربر ممکن است با آن‌ها مواجه شود آورده شده است:

• WritebackDailyLimitExceeded: این خطا نشان می‌دهد که mmd.zram.writeback.max_bytes_per_day سهمیه به‌پایان رسیده است. وقتی این اتفاق می‌افتد، mmd بازنویسی غیرفعال را تا زمانی که پنجره ۲۴ ساعته پیش برود موقتاً متوقف می‌کند.
• Process prefetch or writeback failed: این خطا را می‌توان در logcat هنگام ناموفق بودن ioctl مشاهده کرد. علل رایج عبارت‌اند از:
  • EBADF یا ESRCH: فرایند هدف قبل‌از اینکه mmd بتواند pidfd را به هسته ارسال کند، پایان یافت.
  • ‫ENOSPC: پارتیشن فضای ذخیره‌سازی پشتیبان پر است، یا صف دستگاه حلقه تمام شده است.
• ‫ZRAM راه‌اندازی نشد: اگر mmd نتواند ZRAM را در زمان بوت پیکربندی کند، ممکن است به‌دلیل این باشد که اسکریپت‌های اولیه فروشنده یا swapon_all قدیمی /dev/block/zram0 را قبل‌از اینکه mmd بتواند اجرا کند قفل کرده‌اند.