Jump to content
php.lv forumi

Pārslodzes problēma ar pagaidējo hostingu


Recommended Posts

Sveiki vēlreiz!

 

Paldies visiem par atbildēm.

 

Šobrīd izmantoju DigitalOcean 20$ plānu + Easy Engine setupu (PHP-FPM, Nginx + FastCGI).

 

Šobrīd lapā ir 60 lietotāji online (+/- 10) un šādi izskatās procesi konsolē - http://i9.pixs.ru/storage/7/3/9/asdjpg_7018562_15610739.jpg

 

Vai tas ir normāli, ka palikuši tikai 150+ megabaiti brīvi no RAM?

 

Nekādu bremzēšanu vai citas problēmas nenovēroju, CDN neizmantoju.

 

--------

 

Vēl jautājums par to FastCGI. Laikam neesmu īsti pareizi uzstādījis, bet lieta tāda, ka, pievienojot jaunu rakstu no desktop versijas viss normāli atjaunojas, bet, lai jaunais raksts parādītos mobilajā versijā, vajadzēja purge cache.

 

Vai tā varētu būt theme problēma vai arī nepareizi cache uzstādījumi?

 

(Vai man šim nav jātaisa jauns topiks? :) )

 

Paldies :)

Link to post
Share on other sites

Vai tas ir normāli, ka palikuši tikai 150+ megabaiti brīvi no RAM?

Uz linux/unix tipa sistēmām tas ir normāli, jo OS maksimāli cenšas izmantot visu pieejamo atmiņu procesu paātrināšanai (atstājot nelielu brīvu rezervi) - sajā gadījumā 'top' vat skatīties pie 'cached Mem' t.i. no 2Gb rama 1Gb tiek izmantots failu kešošanai, līdz ar to tev principā brīvi ir 1.1Gb rams, jo, ja kādai aplikācijai/procesam būs nepieciešama papildus atmiņa, linux izsviedīs daļu šī keša un iedos to procesam.

 

 

Vēl jautājums par to FastCGI. Laikam neesmu īsti pareizi uzstādījis, bet lieta tāda, ka, pievienojot jaunu rakstu no desktop versijas viss normāli atjaunojas, bet, lai jaunais raksts parādītos mobilajā versijā, vajadzēja purge cache.

Fastcgi vispār ir protokols.

Vai šajā gadījumā tu domā nginxa fastcgi_cache?

Link to post
Share on other sites

Uz linux/unix tipa sistēmām tas ir normāli, jo OS maksimāli cenšas izmantot visu pieejamo atmiņu procesu paātrināšanai (atstājot nelielu brīvu rezervi) - sajā gadījumā 'top' vat skatīties pie 'cached Mem' t.i. no 2Gb rama 1Gb tiek izmantots failu kešošanai, līdz ar to tev principā brīvi ir 1.1Gb rams, jo, ja kādai aplikācijai/procesam būs nepieciešama papildus atmiņa, linux izsviedīs daļu šī keša un iedos to procesam.

 

 

Nu gluži tā gan nav, jo to ko metīs ārā no RAM'a kontrolē vm.swappiness parametrs, kernelis var sākt paging'u arī pirms viss file cache ir atbrīvots 

Edited by spainis
Link to post
Share on other sites

Nu gluži tā gan nav, jo to ko metīs ārā no RAM'a kontrolē vm.swappiness parametrs, kernelis var sākt paging'u arī pirms viss file cache ir atbrīvots 

Jā pareizi tā ir, bet viņam nav swapa (attiecīgi process novienkāršojas :) )..

 

 

p.s. mūsdienās swapu likt uz serveriem ir diezgan nejedzīgi (vai vismaz minimums ar vm.swapinnes = 0), personīgi pārstāju likt swapu pirms gadiem 10 ..

p.s.2. izņēmums varētu būt zram, kur uz ram izveido disku/partīciju (kompresētu swapu) un tā teorētiski palielina sistēmas (virtuālās) atmiņas ietilpību, bet tā necieš no nesalīdzināmi lēnākās cieto disku darbības. To gan biežāk izmanto desktopos un mobilajās iekārtās.

Edited by Roze
zram
Link to post
Share on other sites

Ja pārāk swapojas, tad protams, swaps ir bezjēdzīgs, pareizāk sakot, iešķiebt pārāk maz atmiņas serverim ir bezjēdzīgi.

Bet tā swaps vispār palīdz. Piemēram, pret temporary pīķiem; vietu, kur nogrūzt neaktīvos aizņemots apgabalus; utmldz. Katrā ziņā, ar swap sistēmas strādā stabilāk.

Link to post
Share on other sites

Piemēram, pret temporary pīķiem; vietu, kur nogrūzt neaktīvos aizņemots apgabalus; utmldz. Katrā ziņā, ar swap sistēmas strādā stabilāk.

Šī gan jau kļust par citu tēmu, bet nepiekritīšu..

 

Sistēmas ar temporāriem pīķiem (kas pārsniedz atmiņas apjomus) nevar saukt par stabilām.

 

Protams, no administratora viedokļa vienkāršāk (un varbūt mazāk galvas sāpju) ir pielikt "kaudzi" ar swapu, taču tā zināmā mērā ir vienaldzība (mums ir tāda programmētāju palama/"otmaska" par datu apjomiem - "Tas jau neko neaizņem").

 

Ja tādi ir, vai nu nav izvērtēti uz servera strādājošo aplikāciju/servisu īpatnības (memory leakings), iespējamie konfigurācijas limiti, nav pienācīgs monitorings vai arī vienkārši izdalītie aparatūras resursi ir nepietiekami, tādējādi sanāk, ka agrāk vai vēlāk var rasties problēmas un pēc Mērfija likuma - tās būs pašā nepiemērotakajā brīdī.

 

Pēc pieredzes un incidentiem vismaz līdz šim 2.4.x/2.6.x sērijas (jaunākie sākot no kāda 3.10.x uzvedās krietni labāk) linux kerneļi ļoti grūti (vai vispār ne) tiek galā ar ar out of memory un out of swap situācijām (pīķu gadījumā pēc vilciena efekta tās parasti seko viena otrai), t.i. rezultāts ir krietni sliktāks - sistēma pilnībā neresponsīva, nekā ja swapa nav.

 

Protams, bezswapa variantā OOM killeris ir nežēlīgs (burtiski "upurē/nogalina bērnus"), lai arī to var konfigurēt un vitāli svarīgos servisus (piem db utt) iezīmēt kā neaiztiekamus, taču pat tad, ja sistēma piespiedu kārtā ir beigusi procesu un tā rezultātā ir, piemēram, notikusi db  (neatgriezeniska) datu korupcija (ar mysql un innodb, kas it kā skaitās acid/crash safe, samērā vienkārši panākams rezultāts (varbūt ir iemesls izvēlēties citu engine?)), ja nav rezerves kopijas  (datu/servisa), scenārija, kā tos atjaunot - arī to nevar saukt par stabilu sistēmu.

 

Sanāk tikai tāda nosacita stabilitātes sajūta ..

Link to post
Share on other sites

Es te nerunāju par out of swap (kā jau minēju savā iepr. postā), kad tas pasākums ir bezjēdzīgs, ja sistēma to vien dara kā swapojas.

 

Tak neviens normāls cilvēks neies tūnēt visus kerneļa un softu parametrus (vai par to maksāt), tur jau tā lieta. Vnk ieslēdz bikiņ swap un vairums problēmu ar out of memory atkrīt. oom killeris arī by default darbojas ciniski - brīvs rams, bet killē tik nost. Tas noteikti ir tūnējams, bet defaultā tas ir nežēlīgs. Ieslēdz swap un killeris uzvedās it kā būtu vairāk ram un killo jau mazāk nežēlīgi.

 

P.S.

Kurš vēl runā par 2.4? :) Nēnu es saprotu kādām legacy sistēmām un tā, bet ne jau php+mysql.

Link to post
Share on other sites

Ja nemaldos, tad 1 GB swaps tiek izmantots. 

 

Paldies par atbildēm. Izmantoju Nginx fastcgi cache - lapa desktop versijā atjaunojas momentāli, mobilajā - nenovēroju, bet, manuprāt, pēc ~stundas. Vai tam iemesls ir fastcgi caching? Jo pirms tam neizmantoju to, un viss bija kārtībā.

Link to post
Share on other sites

Ja nemaldos, tad 1 GB swaps tiek izmantots. 

Tavā 'top' screenshotā ir 0 (var pārliecināties arī piemēram ar 'free -m')

 

Paldies par atbildēm. Izmantoju Nginx fastcgi cache - lapa desktop versijā atjaunojas momentāli, mobilajā - nenovēroju, bet, manuprāt, pēc ~stundas. Vai tam iemesls ir fastcgi caching? Jo pirms tam neizmantoju to, un viss bija kārtībā.

 

Ko un kā keshot nginx kontrolē ar fastcgi_cache_key un fastcgi_cache_bypass  t.i. atkarībā no vides iespējams varbūt mainās kaut kādi url vai cookie parametri. Precīzāk gan varētu pateikt pēc pašas nginx konfigurācijas ..

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...