Mana vietne ir lēna/CPU noslodze ir pārāk augsta/Procesu skaits
Iespējams, ka esat saņēmuši no mums paziņojumu, ka Jūsu tīmekļa vietne pārāk noslogo CPU (procesorus serveros) vai izmanto pārāk daudz procesu. Tas var būt vienkārši liela apmeklētāju skaita dēļ, taču 99,9% gadījumu iemesls nav tas.
Dažām lielām/smagām tīmekļa vietnēm (piemēram, interneta veikaliem) jau normālā lietošanā vajadzīga lielāka skaitļošanas jauda nekā citām vietnēm; ja esat pārliecināti, ka vietne darbojas pareizi, tālāk minētais uz Jums neattiecas. Tādā gadījumā viena no iespējām ir pāriet uz jaudīgāku hostinga paketi ar lielāku skaitļošanas jaudu. Mūsu hostinga paketes skatiet šeit.
Tālāk īsi izklāstīsim, kas var būt augstas CPU noslodzes cēloņi. Ja pārmērīgu CPU noslodzi nenovērš (laikus), Jūsu konts/vietne var tikt (automātiski) ierobežota. Tiklīdz CPU noslodze atkal ir normas robežās, Jūsu vietne automātiski atkal tiek ieslēgta. Taču, ja tas īsā laikā atkārtojas, galu galā tā vairs netiks ieslēgta automātiski
Šie pasākumi vajadzīgi, lai aizsargātu serverus no pārslodzes. Novēršot pārslodzi, Jūs ne tikai samazināt CPU noslodzi, bet arī Jūsu vietne kļūst ievērojami ātrāka un tātad daudz patīkamāka apmeklētājiem.
Lēna tīmekļa vietne un spraudņi
Tīmekļa vietnes, kas izveidotas, piemēram, ar WordPress vai Joomla, mēdz būt lēnas. Gandrīz vienmēr cēlonis ir spraudņi, kas nedarbojas pareizi vai ir vienkārši slikti izstrādāti. Ja vietne ir lēna, ieteicams uz brīdi izslēgt visus spraudņus un pārbaudīt, vai tad vietne ir ātra. Ja tā ir, ieslēdziet spraudņus atpakaļ pa vienam un katru reizi pārbaudiet, vai vietne joprojām ir ātra, līdz vainīgais ir atrasts.
Lēna tīmekļa vietne daudzu datubāzes ierakstu dēļ
Cits lēnuma iemesls var būt tas, ka datubāzē ir sakrājies tik daudz ierakstu (dažkārt redzam pat daudzus miljonus ierakstu), ka vietne no tā cieš. Bieži tās ir statistikas tabulas vai tabulas, kurās tiek kaut kas reģistrēts. Parasti tam nevajadzētu radīt problēmas, taču, ja datubāzes tabula nav labi izstrādāta un meklēšana notiek lielā datu apjomā bez pareiza indeksa, tas var radīt lielu lēnumu.
Jūsu pārlūkprogrammas kešatmiņa
Regulāri gadās, ka lēns ir nevis serveris, bet Jūsu pārlūkprogramma, jo tās kešatmiņa ir pārpildīta. Iztīriet kešatmiņu un/vai izmēģiniet citu pārlūkprogrammu, lai redzētu, vai arī tur ir lēni. Skatiet, piemēram, http://www.ehow.com/how_8618453_fix-slow-firefox-ie8-browsers.html
Apache žurnālfaili / Procesu saraksts
Ja saņēmāt no mums paziņojumu par CPU, iespējams, šīs e-pasta vēstules beigās ir redzams procesu un IP adrešu saraksts. No šī saraksta, iespējams, var kaut ko secināt, taču var būt arī tā, ka saraksta nav vai tajā nav daudz informācijas. Šādos gadījumos, iespējams, palīdzēs žurnālfaili. Tajos atradīsiet informāciju par visiem Jūsu vietnes apmeklētājiem un to, kurus failus viņi kurā brīdī pieprasīja. Ir lietderīgi izpētīt šos failus ap paziņojuma laiku, tas var dot labu priekšstatu par iespējamām problēmām. Šo informāciju atradīsiet tā sauktajos Apache žurnālfailos. Tos varat apskatīt vadības panelī, Site Summary / Statistics / Logs un tad Full Error Log/Usage Log šodienas žurnālfailam. Iepriekšējo dienu žurnālfailus atradīsiet sadaļā Saved Apache Logs. Žurnālfailus varat apskatīt arī ar FTP vai failu pārvaldnieku mapē /domains/domens.xx/logs. Ņemiet vērā, ka apakšdomēniem apakšdomēnu izvēlnē ir atsevišķi žurnālfaili.
Vai man jāuztraucas?
Ne uzreiz. Tikai tad, ja šos brīdinājumus saņemat ļoti regulāri, visticamāk, ir kāda strukturāla problēma. Viltus paziņojumi parasti nav, taču apstākļi katrā brīdī atšķiras. Piemēram, skripts vai vaicājums, kas nav labi uzrakstīts, parasti var darboties bez problēmām, bet brīdī, kad attiecīgajā serverī ir lielāka slodze, tas var izraisīt brīdinājumu.
Iespējamie pārmērīgas CPU noslodzes cēloņi
- Jūsu tīmekļa vietnē ir fotoalbums, un fotoattēlu mazās versijas vietā tajā ir pilnizmēra versijas. Kad fotoattēls tiek parādīts, CPU vispirms jāsamazina oriģinālais fotoattēls, kas dažkārt ir daudzus MB liels. Ja to vienlaikus dara vairāki apmeklētāji, tas var radīt lielu CPU noslodzi.
- Iespējamie risinājumi: ievietojiet savā vietnē tikai samazinātus fotoattēlus un, kas ir vissvarīgāk, nodrošiniet, lai izmērs, kādā fotoattēlus rādāt, atbilstu fotoattēlu īstajam izmēram, tad serverim nekas nav jāsamazina, bet tikai jāparāda. Ja nepieciešams, ievietojiet vietnē vairākas versijas; lielāks diska vietas patēriņš ir mazāk kaitīgs nekā lielāka CPU noslodze.
- Turpinot pirmo iemeslu: fotoattēlu rādīšana ar PHP programmu (straumēšana) ir daudzkārt lēnāka nekā tieša fotoattēla URL iekļaušana.
- Iespējamie risinājumi: iekļaujiet tiešo URL uz fotoattēliem, attēliem u. tml. un nelaidiet to caur PHP programmu. Tas ir lēnāk un nevajadzīgi noslogo CPU.
- Jūs piedāvājat apmeklētājiem iespēju komentēt rakstu, fotoattēlu vai ko citu. Ja to neaizsargājat ar tā saukto captcha vai neierobežojat tikai reģistrētiem lietotājiem, surogātpasta sūtītāji var to ļaunprātīgi izmantot, un rezultātā CPU noslodze var (ārkārtīgi) pieaugt.
- Jūs liekat tīmekļa lapai ik pēc X sekundēm automātiski pārlādēties / atsvaidzināties (refresh), tāpēc CPU tiek nevajadzīgi noslogots.
- Iespējamie risinājumi: noņemiet atsvaidzināšanu no lapas. Parasti tā ir galvenē vai, iespējams, JavaScript kodā.
- Jūs savai tīmekļa vietnei izmantojat datubāzi. Tad ir svarīgi, lai šī datubāze būtu pilnībā optimizēta. Ar to īpaši domāts, ka ir pietiekami daudz un pareizu indeksu. Datubāze ar dažiem (desmitiem) tūkstošiem ierakstu/rindu, ja ir daži apmeklētāji un slikta indeksācija vai tās nav vispār, var ļoti ātri radīt veiktspējas problēmas.
- Iespējamie risinājumi: optimizējiet savu datubāzi. ARĪ tad, ja tā ir standarta datubāze. Ja, piemēram, izmantojat OScommerce ar dažiem ierakstiem, nekas slikts nenotiek. Taču ar daudziem ierakstiem optimizācija tomēr būs nepieciešama. Ar to ne tikai ievērojami samazinās CPU noslodze, bet arī Jūsu vietne kļūst ievērojami ātrāka un tātad patīkamāka apmeklētājiem.
- Jūsu vietne ilgu laiku darbojās bez problēmām, un pēkšņi tā kļūst lēna un saņemat paziņojumus par CPU.
- Iespējamie risinājumi: visticamāk, problēma meklējama datubāzē. Laika gaitā tajā nonāk arvien vairāk ierakstu/rindu, un tad ātri nonākam pie iepriekšējā punkta, ka datubāze nav labi indeksēta. Ir svarīgi datubāzi labi optimizēt.
- Jums ir tīmekļa vietne ar ļoti daudz atsevišķiem failiem. Ja DirectAdmin atverat failu pārvaldnieku, visticamāk, pat saņemsiet noildzi (timeout), jo tas vispirms grib nolasīt visu mapju struktūru, un tas aizņem pārāk ilgu laiku. Tādā gadījumā DA failu pārvaldnieku nevarat izmantot un esat atkarīgi no FTP. Taču glabāt vairāk nekā 1.000 failu vienā mapē nekad nav ieteicams. Operētājsistēmai ar to ātri rodas grūtības, rezerves kopēšana kļūst lēna, failu atvēršana kļūst lēna utt.
- Iespējamie risinājumi: kur iespējams, izmantojiet ZIP vai RAR failus; izveidojiet apakšmapes, katrā mapē ne vairāk kā 500 līdz 1.000 failu. Taču patiesībā tīmekļa vietnei vislabāk ir izvairīties no ārkārtīgi lielām failu struktūrām.
- Iespējams, ka noteiktas tabulas Jūsu datubāzē nemanāmi ir izaugušas. Ir labi ik pa laikam apskatīt datubāzi ar phpMyAdmin un pārbaudīt, vai ierakstu skaits katrā tabulā atbilst Jūsu gaidām.
- Ja ir tabulas ar daudz ierakstiem, pārbaudiet, vai tas tiešām ir nepieciešams, un, kur iespējams, iztīriet tabulas. Ja tas nav iespējams, pārbaudiet, vai datubāzi var optimizēt.
Procesi
Tīmekļa serveris vienlaikus var apstrādāt noteiktu procesu skaitu (procesu skaitam nav nekāda sakara ar apmeklētāju skaitu). Tīmekļa servera procesa īpatnība ir tā, ka tas vienmēr ir aktīvs ļoti īsu brīdi. Tas nogādā lapu lietotājam un pēc tam ir beidzis darbu. Parasti tas notiek sekundes daļās, dažkārt, ja lapas ir lielas, nedaudz ilgāk. Tādā veidā viens process var piegādāt lapas lietotājiem ļoti daudzām tīmekļa vietnēm / apmeklētājiem. Ja procesi paliek atvērti, tie vairs netiek pārstrādāti, un ar laiku servera atmiņa pārpildīsies un serveris kļūs nepieejams, īpaši, ja vienlaikus pieaug arī apmeklētāju skaits. Tātad nevēlama un neparasta situācija. Pirms tas notiek, mēs automātiski iejaucamies, un attiecīgā vietne tiek deaktivizēta.
Iespējamie pārāk liela procesu skaita cēloņi
- Jums ir skripts/programma, kas sazinās ar citu serveri, piemēram, ar curl, šī saziņa neizdodas, un Jūsu programma turpina gaidīt. Ja tā notiek vairākiem lietotājiem, ātri var rasties problēma.
- Nodrošiniet, lai katram izsaukumam vienmēr būtu noildze (timeout). Nekad ne vairāk kā 1 vai 2 sekundes, jo, ja lietotājam jāgaida ilgāk, viņš tik un tā aiziet.
- Jūsu vietne tiek 'leeched'. Tas nozīmē, ka kaut kas vai kāds automātiski mēģina nokopēt Jūsu vietni. Visas daļas, fotoattēlus utt.
- Mēģiniet Apache žurnālfailā atrast IP adreses, kas to izraisa, un mēģiniet tās bloķēt. Rakstu par IP adrešu bloķēšanu skatiet mūsu BUJ.
- Katru reizi, kad lapa tiek atsvaidzināta, Jūs nolasāt citas vietnes RSS plūsmu. Tas nav saprātīgi, viss kļūst nevajadzīgi lēns, un tas var radīt arī šīs problēmas.
- Nolasiet RSS plūsmas tikai ik pēc X minūtēm un tikai tad, ja ir apmeklētāji. Nodrošiniet arī, lai, nolasot šīs plūsmas, darbotos noildze.