فهرست برنامه‌های آغاز به کار را بارها کوتاه کرده بودم و حتی Autoruns را خط‌به‌خط بررسی کرده بودم. بااین‌همه، هیچ‌یک از این ابزارها به‌درستی توضیح نمی‌دادند که چرا لپ‌تاپم تا مدت‌ها پس از نمایش صفحه ورود همچنان سخت مشغول کار است.
این بار تصمیم گرفتم به‌جای ادامه دادن حدس‌وگمان‌ها، با Windows Performance Toolkit مایکروسافت که همراه Windows ADK ارائه می‌شود، کل فرایند راه‌اندازی را ضبط کنم. ردگیری به‌دست‌آمده فعالیت‌هایی را آشکار کرد که ابزارهای معمول مدیریت آغاز به کار نشان نمی‌دهند و این تجربه نگاهم را به کندی راه‌اندازی تغییر داد.
برنامه‌های آغاز به کار فقط ظاهر ماجرا بودند
ردگیری، زمان‌بندی پنهان را آشکار کرد
نخستین چیزی که وادارم کرد درنگ کنم، گزارش آماده‌سازی سرویس‌ها بود. دیدم آماده‌سازی چند سرویس بسیار بیشتر از آنچه گمان می‌کردم طول کشیده است. جالب‌تر اینکه پیش‌تر هرگز به ذهنم نرسیده بود بیشتر آن‌ها را بررسی کنم.
برای ثبت ردگیری راه‌اندازی از xbootmgr استفاده کردم و سپس با xperf گزارش‌ها را از آن بیرون کشیدم. ویندوز ظرف حدود ۲۵ ثانیه به میزکار رسید، اما ردگیری نشان داد که پس از آن نیز حجم چشمگیری از پردازش‌ها ادامه داشته‌اند.
در لپ‌تاپ Core i5 من با 8GB حافظه، حجم پرونده ردگیری به حدود ۱.۰۷ GB رسید و داده‌های فراوانی برای بررسی پیش رویم گذاشت. این پنج مورد بیش از همه جلب توجه کردند:
| سرویس | بازه زمانی | کارکرد |
|---|---|---|
| HNS (اچ‌ان‌اس) | ۹.۶۴۸ ثانیه | شبکه‌سازی مجازی |
| DellClientManagementService (سرویس مدیریت کارخواه دل) | ۶.۹۰۶ ثانیه | ابزار مدیریتی Dell |
| IntelAudioService (سرویس صوتی اینتل) | ۵.۶۴۱ ثانیه | پردازش صدا |
| DusmSvc (سرویس داسم) | ۵.۵۷۴ ثانیه | ردگیری مصرف داده |
| BITS (بیتس) | ۴.۷۵۷ ثانیه | بارگیری‌های پس‌زمینه |
ازآنجاکه این بازه‌ها معمولاً با یکدیگر هم‌پوشانی دارند، نمی‌توان آن‌ها را جمع زد و زمان کل راه‌اندازی را به دست آورد. هر عدد به‌تنهایی نشان نمی‌دهد یک سرویس چه مدت رسیدن به میزکار را به تأخیر انداخته است؛ بلکه تنها مدت‌زمان آماده‌سازی همان سرویس را نشان می‌دهد.
این موضوع تفاوت میان ردگیری و فهرست آغاز به کار را به‌روشنی نشان می‌دهد. Autoruns مواردی را نمایش می‌دهد که برای اجرا هنگام راه‌اندازی تنظیم شده‌اند؛ همان چیزی که در مقاله‌ام درباره Autoruns شرح داده بودم. اما ردگیری نشان می‌دهد سرویس‌ها چه زمانی آماده شده‌اند و فعالیتشان چگونه با یکدیگر هم‌پوشانی داشته است.
سرویس‌ها همه ماجرا نبودند
فضای ذخیره‌سازی و سخت‌افزار نیز درگیر بودند
سپس گزارش تأخیر درایورها را اجرا کردم. این گزارش امکان می‌داد به‌جای مشاهده صرف سرویس‌ها به‌صورت یکپارچه، تک‌تک رخدادها را ببینم. جالب اینکه بزرگ‌ترین تأخیرها ارتباط چندانی با نرم‌افزارهای پرزرق‌وبرق شرکت‌های دیگر نداشتند.
| مؤلفه | زمان تقریبی رخداد | لایه |
|---|---|---|
| FLTMGR.SYS (مدیر پالایه) | ۷۹۹ میلی‌ثانیه | پالایش سامانه پرونده‌ها |
| FLTMGR.SYS (مدیر پالایه) | ۵۵۲ میلی‌ثانیه | پالایش سامانه پرونده‌ها |
| پرونده‌های سامانهٔ FLTMGR.SYS / Ntfs.sys ($Mft) | ۴۱۵ میلی‌ثانیه | ثبت و سامان‌دهی اطلاعات سامانهٔ فایل |
| راه‌انداز storport.sys | ۲۹۵ میلی‌ثانیه | پشتهٔ ذخیره‌سازی |
| راه‌انداز pci.sys | ۲۶۸ میلی‌ثانیه | گذرگاه سخت‌افزاری |
اینجا نیز همان نکتهٔ احتیاطی صدق می‌کند. این‌ها عملیات هم‌پوشانی بودند، نه بازه‌های مستقل چندمیلی‌ثانیه‌ای که بتوان آن‌ها را به‌سادگی با هم جمع کرد و به زمان راه‌اندازی افزود. سه مورد نخست به پشتهٔ سامانهٔ فایل مربوط بودند؛ از جمله عملیاتی مرتبط با $Mft در NTFS، یعنی جدول اصلی فایل که فراداده‌های فایل‌ها و پوشه‌ها را نگه می‌دارد. دو مؤلفهٔ دیگر نیز پشتهٔ ذخیره‌سازی و زیرساخت گذرگاه PCI بودند.
در آزمایش‌هایم ACPI.sys را هم دیدم؛ مؤلفه‌ای سطح‌پایین که در مدیریت انرژی و پیکربندی سخت‌افزار نقش دارد. مشتاق بودم مظنونان همیشگی را ببینم: Netwtw08.sys برای وای‌فای، TbtBusDrv.sys برای تاندربولت و RtsPer.sys برای کارت‌خوان. بااین‌حال، این‌ها فقط در قالب رویدادهایی بسیار کوچک‌تر ظاهر شدند و در ردگیری من هیچ‌یک از راه‌اندازهای شخص ثالث به‌طور ویژه جلب توجه نکرد.
می‌توانستم ببینم که فعالیت‌ها هم‌زمان در چندین لایه جریان دارند.
ردگیری من یک مقصر مشخص نشان نداد
راه‌اندازی آن روند منظم و ساده‌ای نبود که تصور می‌کردم
وقتی این ردگیری را آغاز کردم، مطمئن بودم سرانجام به لحظه‌ای می‌رسم که بگویم: «خودش است!» فکر می‌کردم یک سرویس یا راه‌انداز مشخص پیدا می‌شود که بتوانم به آن اشاره کنم، از کار بیندازمش و مشکل را حل کنم. اما چنین لحظه‌ای هرگز فرا نرسید.
واقعیت، مجموعه‌ای از مقداردهی‌های اولیهٔ هم‌پوشان برای سرویس‌ها بود، در کنار رویدادهای مربوط به راه‌اندازها و ذخیره‌سازی که در سراسر ردگیری پراکنده بودند.
حتی سرویس‌هایی که دیدم نیز به‌شکل مجموعه‌ای مرتب ظاهر نشدند. BITS را پایین‌تر در گزارش یافتم و DellClientManagementService را هم بسیار دیرتر دیدم. ردگیری کمتر به پیمودن یک فهرست راه‌اندازی از سوی ویندوز شباهت داشت و بیشتر مانند چندین گروه کاری بود که در زمان‌های گوناگون مقداردهی اولیه می‌شدند و روی هم می‌افتادند.
در اینجا چند مفهوم وجود دارد که به‌آسانی ممکن است با یکدیگر اشتباه گرفته شوند. بااین‌حال، باید توجه داشت که بازه‌ای طولانی، رویدادی طولانی و ظاهرشدن دیرهنگام سه چیز متفاوت‌اند و هیچ‌کدام به‌تنهایی ثابت نمی‌کنند که نمایش میزکار با تأخیر انجام شده است.
این گزارش‌ها نشان می‌دادند چه اتفاقی در چه زمانی افتاده است، اما به‌تنهایی مشخص نمی‌کردند کدام رویدادها باعث تأخیر پس از ورود شده‌اند. WPA داده‌های مراحل راه‌اندازی را در اختیار می‌گذارد و می‌تواند زمان مقداردهی اولیهٔ Explorer را نشان دهد؛ بااین‌حال، من هر رویداد طولانی مربوط به سرویس یا راه‌انداز را علت آن تأخیر تلقی نکردم.
در عمل، در پی فرایندی گشته بودم که تقصیر را به گردنش بیندازم، اما در نهایت با انبوهی از کارهای هم‌پوشان روبه‌رو شدم که نماهای معمول راه‌اندازی زمانشان را اندازه نمی‌گیرند. بااین‌همه، این نتیجه از یافتن یک مقصر واحد سودمندتر بود.
عددها محل بررسی را نشان دادند، نه آنچه باید غیرفعال شود
مهم بود که عدد بزرگ را سرنخ بدانم، نه حکم نهایی. صرفاً چون HNS در صدر جدول قرار گرفته است، آن را خودکار غیرفعال نمی‌کنم. این مؤلفهٔ شبکه‌ای ویندوز برای قابلیت‌هایی مانند شبکه‌های مجازی‌سازی‌شده و کانتینری به کار می‌رود؛ بنابراین طولانی‌بودن زمان مقداردهی اولیه، به‌تنهایی دلیلی برای خاموش‌کردنش نیست.
اگر سرویسی را فقط به‌دلیل رتبهٔ بالایش غیرفعال کنید، ممکن است به‌سادگی قابلیت مهمی را از کار بیندازید که بعداً به آن نیاز خواهید داشت. همین نکته دربارهٔ راه‌اندازها نیز صدق می‌کند. فقط به این دلیل که رویداد بزرگی کنار FLTMGR.SYS دیده می‌شود، لازم نیست آن را حذف یا تعمیر کنم.
اما نکتهٔ اصلی این بود که آموختم پرسش دیگری مطرح کنم. پیش‌تر تمرکزم بر برنامه‌ای بود که رایانه‌ام را کند می‌کرد؛ اکنون بیشتر می‌خواهم بدانم کدام لایه به بررسی دقیق‌تر نیاز دارد: سرویس‌ها، ذخیره‌سازی یا سخت‌افزار.
منبع: این مطلب ترجمه و بومی‌سازی مقاله‌ای از MakeUseOf به قلم Afam Onyimadu است. مشاهده مقاله اصلی