تبلیغات
مقاله های کامپیوتر - مروری بر تاریخچه محدودیت حافظه مصرفی برنامه های ASP.NET در IIS


 مروری بر تاریخچه محدودیت حافظه مصرفی برنامه های ASP.NET در IIS

زمانیكه اولین نگارش ASP.NET‌ حدود 10 سال قبل منتشر شد،‌ تنها سیستم عاملی كه از آن پشتیبانی می‌كرد، ویندوز سرور 2000 بود، تنها پروسه‌ی اجرایی آن aspnet_wp نام داشت و تنها معماری پشتیبانی شده هم X86 بود. به پروسه‌ی aspnet_wp محدودیت مصرف حافظه‌ای اعمال شده بود كه در حین آغاز آن بر اساس مقدار قابل تغییر processModel memoryLimit محاسبه و اعمال می‌شد (تعریف شده در فایل ماشین كانفیگ).


این عدد به صورت درصدی از ظرفیت RAM فیزیكی سیستم، قابل تعریف و به صورت پیش فرض به 60 درصد تنظیم شده بود. به این ترتیب این پروسه مجاز نبود تا تمام حافظه‌ی فیزیكی مهیا را مصرف كند و در صورت وجود نشتی حافظه‌ای در برنامه‌ای خاص، این پروسه امكان بازیابی مجدد حافظه را پیدا می‌كرد (recycling). همچنین یك مورد دیگر را هم باید در نظر داشت و آن هم وجود قابلیتی است به نام ASP.NET Cache است كه امكان ذخیره سازی مقادیر اشیاء را در حافظه‌ی مصرفی این پروسه مهیا می‌سازد. هر زمان كه میزان این حافظه‌ی مصرفی به حد نزدیكی از محدودیت تعریف شده برسد، این پروسه به صورت خودكار شروع به حذف آن‌ها خواهد كرد.
محدودیت 60 درصدی تعریف شده، برای سیستم‌هایی با میزان RAM كم بسیار مفید بود اما در سیستم‌هایی با میزان RAM بیشتر، مثلا 4 گیگ به 2.4GB حافظه مهیا (60 درصد حافظه فیزیكی سیستم) محدود می‌شد و همچنین باید در نظر داشت كه میزان user mode virtual address space مهیا نیز تنها 2 گیگابایت بود. بنابراین هیچگاه استفاده مؤثری از تمام ظرفیت RAM مهیا صورت نمی‌گرفت و گاها مشاهده می‌شد كه یك برنامه تنها با مصرف 1.5GB RAM می‌توانست پیغام OutOfMemoryException را صادر كند. در این حالت مطابق بررسی‌های صورت گرفته مشخص شد كه اگر مقدار processModel memoryLimit به حدود 800 مگابایت تنظیم شود، بهترین عملكرد را برای سیستم‌های مختلف می‌توان مشاهده كرد.

با ارائه‌ی ویندوز سرور 2003 و همچنین ارائه‌ی نسخه‌ی 1.1 دات نت فریم ورك و ASP.NET ، این وضعیت تغییر كرد. پروسه‌ی جدید در اینجا w3wp نام دارد و این پروسه تعاریف مرتبط با محدودیت حافظه‌ی خود را از تنظیمات IIS دریافت می‌كند (قسمت Maximum Used Memory در برگه‌ی Recycling مربوط به خواص Application Pool مرتبط). متاسفانه این عدد به صورت پیش فرض محدودیتی ندارد و به ظاهر برنامه مجاز است تا حد امكان از حافظه‌ی مهیا استفاده كند. به همین جهت یكی از مواردی را كه باید در نظر داشت، مقدار دهی Maximum Used Memory ذكر شده است. خصوصا اینكه در نگارش 1.1 ، تنظیمات میزان مصرف RAM مرتبط با ASP.NET Cache نیز با برنامه یكی است.

در نگارش 2.0 دات نت فریم ورك، تنظیمات مرتبط با ASP.NET cache از تنظیمات میزان RAM مصرفی یك برنامه‌ی ASP.NET جدا شد و این مورد توسط قسمت cache privateBytesLimit قابل تنظیم و مدیریت است (در فایل IIS Metabase و همچنین فایل web.config برنامه).

نكته!
اگر process memory limit و همچنین cache memory limit را تنظیم نكنید، باز به همان عدد 60 درصد سابق بازخواهیم گشت و این مورد به صورت خودكار توسط IIS محاسبه و اعمال می‌شود. البته محدودیت ذكر شده برای پروسه‌های 64 بیتی در این حالت بسیار بهتر خواهد بود. اگر هر دوی این‌ها را تنظیم كنید، عدد حداقل بكارگرفته شده، مبنای كار خواهد بود و اگر تنها یكی را تنظیم كنید ، این عدد به هر دو حالت اعمال می‌گردد. برای بررسی بهتر می‌توان به مقدار Cache.EffectivePrivateBytesLimit و Cache.EffectivePercentagePhysicalMemoryLimit مراجعه كرد.

و ... اكنون بهتر می‌توانید به این سؤال پاسخ دهید كه «سرور ما بیشتر از 4 گیگ رم دارد و برنامه‌ی ASP.NET من الان فقط 850 مگ رم مصرف كرده (كه البته این هم نشانی از عدم dispose صحیح منابع است یا عدم تعیین تقدم و تاخر و زمان منقضی شدن، حین تعریف اشیاء كش)، اما پیغام out of memory exception را دریافت می‌كنم. چرا؟!»


بنابراین ایجاد یك
Application pool جدید به ازای هر برنامه‌ی ASP.NET امری است بسیار مهم زیرا:
- به این ترتیب هر برنامه‌ی ASP.NET در پروسه‌ای ایزوله از پروسه‌ی دیگر اجرا خواهد شد (این مساله از لحاظ امنیتی هم بسیار مهم است). در اینجا هر برنامه، از پروسه‌ی w3wp.exe مجزای خاص خود استفاده خواهد كرد (شبیه به مرورگرهایی كه هر tab را در یك پروسه جدید اجرا می‌كنند).
- اگر پروسه‌ای به حد بالای مصرف حافظه‌ی خود رسید با تنظیمات انجام شده در قسمت recycling مرتبط با Application pool اختصاصی آن، به صورت خودكار كار بازیابی حافظه صورت می‌گیرد و این امر بر روی سایر برنامه‌ها تاثیر نخواهد داشت (كاربران سایر برنامه‌ها مدام شكایت نمی‌كنند كه سشن‌ها پرید. كش خالی شد. زیرا در حالت وجود application pool اختصاصی به ازای هر برنامه، مدیریت حافظه برنامه‌ها از هم ایزوله خواهند بود)
- كرش صورت گرفته در یك برنامه به دلیل عدم مدیریت خطاها، بر روی سایر برنامه‌ها تاثیر منفی نخواهد گذاشت. (زمانیكه ASP.NET worker process به دلیل استثنایی مدیریت نشده خاتمه یابد بلافاصله و به صورت خودكار مجددا «وهله‌ی دیگری» از آن شروع به كار خواهد كرد؛ یعنی تمام سشن‌های قبلی از بین خواهند رفت؛ كه در صورت ایزوله سازی ذكر شده، سایر برنامه‌ها در امان خواهند ماند؛ چون در پروسه ایزوله‌ی خود مشغول به كار هستند)
- با وجود application pool اختصاصی به ازای هر برنامه، می‌توان برای سایت‌های كم ترافیك و پرترافیك، زمان‌های recycling متفاوتی را اعمال كرد. به این ترتیب مدیریت حافظه‌ی بهتری قابل پیاده سازی می‌باشد. همچنین در این حالت می‌توان مشخص كرد كدام سایت از تعداد worker process بیشتر یا كمتری استفاده كند.
- كاربری كه پروسه‌ی ASP.NET تحت آن اجرا می‌شود نیز همینجا تعریف می‌گردد. بنابراین به این ترتیب می‌توان به برنامه‌ای دسترسی بیشتر و یا كمتر داد، بدون تاثیر گذاری بر روی سایر برنامه‌های موجود.



طبقه بندی: ▼ وب،  مقالات ASP.NET،  مقالات IIS، 

ارسال توسط M3hR
آرشیو مطالب
تبلیغات
صفحات جانبی
پیوند های روزانه