سئو برای زندگی

joomla layout overridesسواپ را بررسی کنید! پیش از این که به بررسی موضوع بپردازیم، اجازه بدهید در مورد سواپ توضیحاتی ارائه دهیم ...

سواپ (Swap) در اصطلاح سرور، فضای هارد دیسک است که برای استفاده به عنوان حافظه پشتیبان (بک آپ) در مواردی که رم به طور کامل مورد استفاده قرار گرفته است، توسط سیستم ذخیره میشود. همین که سرور شروع به استفاده از حافظه سواپ میکند، متوجه ضعیف شدن عملکرد آن میشوید چون همیشه رم خیلی خیلی سریعتر از هارد دیسک است. هارد دیسکهای SSD زمانی که سیستم از سواپ استفاده میکند، خیلی بهتر کار میکنند. یک وبسایت مسابقه ای بسیار بزرگ (بر پایه جوملا) بارگذاری بسیار سنگینی را در تعطیلات آخر هفته گذشته تجربه کرد. این وب سایت در نهایت هنگ کرد و متوقف شد. اگر چه این وب سایت به خاطر مسابقات بزرگ، رکورد بیشترین تعداد بازدید را به دست آورده بود اما پیش از این کاملا بهینه سازی شده بود و این توقف وب سایت کمی عجیب به نظر میرسید بنابراین مدیر سایت برای حل این مشکل از ما کمک خواست.

وقتی یک وب سایت بزرگ، هنگ میکند، مراحل زیر را انجام میدهیم:

با SSh سرور سایت به عنوان ریشه (روت) وصل شدیم، مای اس کیو ال و سپس اپاچی (Apache ) را با اجرای دستورات زیر در شل (shell)، متوقف کردیم:

/etc/init.d/mysql stop
/etc/init.d/apache2 stop

در ابتدای فایل .htaccess file (که زیر دایرکتوری ریشه وب سایت قرار گرفته است) مطلب زیر را اضافه کردیم:

deny from all

allow from <Our IP Address>

آپاچی و مای اس کیو ال را با استفاده از دستورات زیر، ریستارت کردیم:

/etc/init.d/apache2 start
/etc/init.d/mysql start

با انجام مراحل بالا، از دو چیز مطمئن شدیم: اول این که منحصرا ما به وب سایت دسترسی داریم و دوم این که دیگر بار مربوط به وب سایت، وجود ندارد
بنابراین پس از انجام این اقدامات، لاگ کوئری کند را بررسی کرده و متوجه شدیم هیچ چیز با اهمیتی در این بخش وجود ندارد. لاگ کوئری کند، بسیار کوچک بود (چند صد کیلو بایت بود و هفته ها کوئریهای کند را جمع آوری میکرد...)

سپس فضای در دسترس دیسک، در هارد دیسک را با وارد کردن دستور df –m در شل بررسی کردیم (شاید فضای دیسک تمام شده بود):

در این مورد هم سرور، فضای دیسک بسیار زیادی در همه بخشها داشت بنابراین مشکل فضای دیسک هم مطرح نبود.

سپس حافظه ای که به سرور اختصاص داده شده بود را با دستور free –g بررسی کردیم تا ببینیم آیا مشکلی در این مورد وجود دارد یا خیر:

در اینجا مشخص شد:

 total       total      used       free
Mem:       16         12          4
Swap:       4           4           0

بله، مشکل از سواپ سیستم بود. نه تنها این، بلکه به دلایلی سواپ اختصاص داده شده به سیستم، به نوعی قفل شده بود و این به معنای عدم توانایی استفاده جوملا از آن در هنگام بار سنگین بود. بنابراین با خاموش کردن سواپ، آن را آزاد کردیم و سپس دوباره با دو فرمان زیر آن را روشن کردیم:

swapoff –a
swapon –a

سپس deny را از کل خطی که به فایل  .htaccess اضافه شده بود، حذف کردیم تا به همه اجازه دسترسی به وب سایت را بدهیم. همین که این کار انجام شد، بار را بررسی کردیم، مشکل رفع شده بود اما میدانستیم که دوباره همین مشکل اتفاق خواهد افتاد... چرا؟

به دو علت:

الف- اگر سواپ سیستم پر شود، به این معنی است که حافظه آن تمام شده بنابراین حافظه، دیگر برای این وب سایت بزرگ کافی نیست (این وب سایت حدود دو میلیون بازدید کننده در هر ماه دارد و در فهرست ده وب سایت پر بازدید امریکا قرار دارد)

ب- حتی اگر این واقعیت را بپذیریم که سیستم باید با سواپ ارتباط داشته باشد، سواپ اختصاص یافته بسیار کوچک است. در واقع فکر میکنیم که مقدار سواپ روی سرور باید به اندازه رم باشد بنابراین اگر 16 گیگا بایت رم در سرور دارید، باید 16 گیگا بایت هم سواپ داشته باشید.

بنابراین برای حل مسئله در بلند مدت چه باید کرد؟

ما مشکل را خیلی سریع حل کردیم:

1- از میزبان (هاست) خواستیم رم سرور را به 32 گیگا بایت ارتقا دهد و 2- از هاست خواستیم مقدار سواپ را به 32 گیگا بایت افزایش دهد. با انجام این اقدامات مطمئن شدیم که وب سایت در بلند مدت نیز چنین مشکلی نخواهد داشت.

اگر وب سایت شما اغلب بلافاصله پس از بار سنگین هنگ میکند، سواپ سرور را بررسی کنید. اگر میبینید که سواپ پر است، احتمالا حافظه سرور شما دیگر کافی نیست و باید آن را افزایش دهید (و همچنین سواپ را افزایش دهید). اگر فکر میکنید همه اینها که گفتیم، اصلا در مورد شما صادق نیست، با ما تماس بگیرید.

5 1 1 1 1 1 1 1 1 1 1 Rating 100% (1 Vote)
sd-logos-part1
sd-logos-part2

منتخب از مشتریان با ارزش ما

مشتریان ما سرمایه ما
themeforest-logo
codecanyon--logo
graphicriver-logo
audiojungle-logo
photodune-logo
activeden--logo