Превишаване на ограничението за използване на системни ресурси
Съдържание
- какво е претоварване?
- защо блокиране?
- откъде идват?
- анализ на претоварване?
- как да се справим с тях?
Основният принцип на виртуалния хостинг или по-правилно: “споделен” (от англ. гл. share - споделям, shared - споделен) е предоставянето на безплатни ресурси без никакви ограничения за всеки процес в системата.
Процес в системата може да бъде всяка работеща програма, извикан скрипт, заявка към базата данни, ftp връзка, изпратено получено писмо и много повече, така че всичко в системата е представено като процеси, всеки от които консумира определено количество ресурси от централния процесор(и) на сървъра, както и RAM, честотна лента на канала и, което е важно, честотна лента на дисковата подсистема (вход / изход). В същото време процесите обикновено се нуждаят от различни ресурси, например един процес може да чака данните да бъдат прочетени от дискове, докато другият се изчислява от процесора (CPU), третият е напълно заспал в очакване на действия отвън, този подход на работа ви позволява да поставите повече от един потребител на сървъра, което значително намалява крайната цена за клиентите, поради което споделеният хостинг е многократно по-евтин от VPS и специализираните сървъри и затова ресурсите не могат да бъдат насилствено ограничени.
Какво е претоварване?
Претоварването е състояние на системата, при което има надпревара за свободни ресурси между процесите. Най-общо претоварването изглежда като монополно изземване на наличните ресурси от един или повече процеси за дълго време, в резултат на коетоостаналите процеси са принудени да се подредят, тогава всичко прилича на лавина или снежна топка, тъй като системните процеси също попадат в опашката, което в резултат забавя цялата система, освен това, ако не се намесвате по никакъв начин, тогава е възможна ситуация, когато системата напълно спре да отговаря на заявки.
Ето защо е толкова важно да не допускате тези претоварвания, тъй като не само пречат на другите, но и като цяло имат пагубен ефект върху производителността.
Защо се прилага блокирането?
Има няколко вида блокиране:
Автоматично блокиране на уебсайтове.
Въпреки факта, че винаги се опитваме първо да изпратим известия с подробности, докато ситуацията все още е поправима, но за съжаление това не винаги е възможно поради следните причини:
- потребителят не реагира навреме и претоварването продължава
- продължителен характер на претоварвания
- генерираното претоварване е много силно и съществува заплаха за стабилността на системата
В случай на пълно блокиране, трябва да се свържете с нашата служба за техническа поддръжка чрез доверен имейл или виртуален офис. В този случай може да ви бъде предоставен достъп до ftp/cPanel, за да елиминирате причините за претоварването.
Откъде идват претоварванията?
Има много причини за появата на претоварвания, основно това са:
- Лошо качество на кода, лоша архитектура на двигателя, неоптимизирани скриптове, тежки заявки към база данни.
- Повишена активност на търсачки, ботове и др.
- Висока посещаемост
Първият случай е най-често срещаният, за съжаление, количеството код, наличен за анализ, оставя много да се желае, това важи дори за търговски CMS, тъй като такива системи изобщо не са фокусирани върху производителността, алекота на използване, скорост на внедряване и добавяне на съдържание, за което трябва да платите с допълнителни ресурси.
Вторият случай също е много често срещан, тъй като сайтовете са обществено достояние и редовно се индексират от различни търсачки, сканират се от вирусни ботове в търсене на уязвимости на страниците, атакуват се от тях за различни цели, напълно се отразяват от многопоточни програми за изтегляне и накрая се посещават от обикновени посетители.
Третият случай е по-рядък и с изключение на първите два е факт на липса на ресурси.
Анализ на претоварване?
Показва потреблението на ресурси на процесора(ите) и се измерва в%, докато общата стойност на натоварването на процесора може да надвишава 100%, т.к. В техническите сайтове могат да се използват многоядрени и многопроцесорни системи, така че задача, изпълнявана на 2-ядрен процесор, може да отнеме 200% и дори 800% в случай на 4-процесорни 2-ядрени системи.
Обозначава консумацията на RAM и се измерва в%, като цяло превишаването на RAM е рядко явление.
Показва консумацията на честотна лента на диска и се измерва в %
Както и редица параметри, които носят допълнителна информация:
rss - размер на процеса в RAM, измерен в байтове exe - Изпълним файл cmd - Команден ред cwd - Текуща директория на процеса
За PHP процесите също има статистика за честотата на техните извиквания и изглежда така:
В края на всеки детайл се изисква печат за време:
Въз основа на анализирания детайл можем да заключим, че претоварването е причинено от честото стартиране на скрипта banner.xml.php, но какво би било по-дълбокоза да разберете причината, трябва да погледнете в „необработените регистрационни файлове за достъп“ чрез cPanel, като анализирате откъде е извикан такъв скрипт, както и да разгледате изходния код на сайта / двигателя. В допълнение към подробностите, дадени в тази статия, могат да бъдат посочени и други параметри:
- Заявки към уеб сървъра:
- MySQL заявки:
Как мога сам да разбера текущото натоварване?
След това трябва да създадете условия за правилното стартиране на скрипта:
- Разрешенията за файлове трябва да са 755, могат да се променят чрез файловия мениджър cPanel или ftp клиент, който поддържа chmod
- В папката, където се намира скриптът, трябва да е разрешено стартирането на CGI.За целта файлът .htaccess трябва да има запис:
Как да се справим с претоварването?
Преди да посочите начини за справяне с претоварванията, е необходимо да разсеете един често срещан мит - трафикът на сайта не е индикатор за натоварването, което създава, в някои ситуации само 1 скрипт, стартиран чрез планировчика на cron, може да причини претоварване, докато на сайта ще има 0 посетители и 0 посещения на броячите, има и случаи, когато лошо написана заявка към базата данни може да причини претоварване, съизмеримо със сайтове с трафик от 5000 уникални ip и т.н.
Тъй като няма единен начин за справяне с претоварването, ние изброяваме само няколко от тях:
Оптимизация на изходния код.
Не се опитвайте сами да оптимизирате изходния код, тъй като това изисква много опит и още повече практика по този въпрос. Понякога, за да се подобри ситуацията, е достатъчно да се коригира тромава функция и понякога дори напълно да се откажат от модули / двигатели / скриптове, имаше случаи, когато професионалистите откриха скриптове, които предизвикаха циклична рекурсия, в резултат на което скриптът спряреагира, като изразходва все повече и повече ресурси, а замяната му с аналог даде положителни резултати както по отношение на скоростта, така и по отношение на интензивността на ресурсите.
Оптимизиране на структурата на базата данни и заявките към нея.
Също така, опитен програмист с познания по SQL може да намери пречка в заявките и да я разреши, като изгради успешни индекси за базата данни или като пренапише самите заявки, за да намали времето им за изпълнение, има случаи, когато избирането на определени заявки без индекси отне повече от 100 секунди време, а след изграждане на индекси, това време беше намалено до 3-5 секунди.
кеширане.
Този тип контрол на задръстванията е нож с две остриета, от една страна, кеширането може да помогне за намаляване на натоварването на процесора, тъй като няма да е необходимо да се генерира един и същ код стотици пъти, но от друга страна, ако кешът се намира на диска, това може да причини натоварване на дисковата подсистема или обратното, ако кешът се намира в RAM, това може значително да увеличи потреблението му. Използвайте кеширането пестеливо там, където наистина имате нужда.
Генериране на статично съдържание.
Ако вашият сайт получава голям брой заявки от един и същи тип, разумно решение би било да прехвърлите някои от страниците, които посещавате, в статични, например показването на главната страница на сайта с помощта на PHP съдържа редица заявки към база данни (например извеждане на новини), извикване на различни видове PHP функции, изразходване на процесорни ресурси за изчисления, както и зареждане на различни библиотеки в RAM, докато връщането на статична страница е стотици пъти по-бързо и спестява ресурси, тъй като изисква само една операция за четене от диска и малко време на уеб сървъра, за да го даде на браузъра.
За да може статичната страница да се актуализира редовно, можетедобавете задание към планировчика на cron, което ще генерира статика от динамичен скрипт веднъж на всеки 5-10 минути, което обикновено е повече от достатъчно. Както показва практиката: сайт с трафик от само 50-70 души на ден на обикновена CMS трудно би могъл да се справи с инвазията на търсачките и след генериране на статична страница сайтът може да обслужва до 7000 посетители, без да надвишава ограниченията, но разбира се не всеки сайт може да бъде прехвърлен на статичен, тъй като всичко зависи от неговата специфика и естеството на заявките към него.
Отървете се от всичко излишно.
Намалена активност на ботовете.
Атаки с отказ на услуга.
В този случай нашата компания няма да може да ви помогне, тъй като защитата срещу подобни атаки е много скъпо решение и по правило DDoS атаките се провокират от поставянето на незаконно или политическо съдържание. Единственото решение за това претоварване може да бъде само преминаване към хостинг със защита от DDoS атаки или отказ от публикуване на провокативно съдържание.
CGI скриптове.
Отделно и рядко срещано явление е претоварването с CGI скриптове (perl / python / shell), в този случай е възможно да се изпълняват с по-нисък приоритет чрез командата nice. Също така има смисъл да се намали интензивността на изпълнение на cron задания, ако има такива.