Pereiti prie turinio

Ar dedikuoti.lt tik reklaminis triukas?


Rekomenduojami pranešimai

Tai gal tau reikėjo pasiimt pralaidumo daugiau?

 

Kitų resursų pilnai užtenka. Su dedikuoti.lt seniau diskutavom, kad CPU trūkumas, bet čia pačioje pradžioje kai parėjau nuo 4GHZ iki 8GHZ.

 

Esmė tokia, kad šitie resursai konkrečiai kalba eina apie CPU neduoda visiškai jokios naudos, tai kam mokėti daugiau? Dideliems projektams ten manau net nėra ko kišti rankas.

 

Gal reikia tiesiog susitvarkyti naudojamą aplikaciją, kuri gali būti netvarkingai suprogramuota ar su klaidomis.

Sakai turi patirties, tai reikia įvertinti ir kitus resursus ne tik CPU. Gal RAM trūkumas.

Gal susikonfigūruoti reikia serverį kiek kitaip.

 

 

Nėra jokių trukumų, yra pateikiamos visos išsamios statistikos. Naudojamas paprasčiausias wordpress su minimaliai plūginų kuriuos naudoja tūkstančiai žmonių.

 

Būna, kad apkrovos sukylą ir viskas. (RAM pakanka, linija neapkrauta, HDD irgi beveik tuščias).

 

Buvo bandoma įvairūs variantai didinti vienus ar kitus parametrus.

 

Patys dedikuoti.lt serveriai tikrai veikia stabiliai, supportas irgi geras, bet jie nepateisina lūkesčių.

Redagavo Darexs
Nuoroda į pranešimą
Dalintis kituose puslapiuose

O tu jaunuoli lodamas jog tavo "minimalus" wordpress sukasi vos vos, bent jau nustatai koks procesas išnaudoja tokius serverio resursus? Matomi CPU šuoliai, kas juos sukelia? Ot žmonės, prikiša į TVS null'intų modulių, nežiūri jog tinklalapis pilnas .js script'ų ir sulaukia "vos" 3000 lankytojų...

 

Temos autoriui: išmok racionaliai naudoti tiek savo pinigus tiek ir už juos perkamas paslaugas.

Nuoroda į pranešimą
Dalintis kituose puslapiuose

O tu jaunuoli lodamas jog tavo "minimalus" wordpress sukasi vos vos, bent jau nustatai koks procesas išnaudoja tokius serverio resursus? Matomi CPU šuoliai, kas juos sukelia? Ot žmonės, prikiša į TVS null'intų modulių, nežiūri jog tinklalapis pilnas .js script'ų ir sulaukia "vos" 3000 lankytojų...

 

Temos autoriui: išmok racionaliai naudoti tiek savo pinigus tiek ir už juos perkamas paslaugas.

 

Akis prasikrapštyk ir paskaityk temos esmę...

 

Paryškinau pirmą postą, dėl tokių žmonių kaip tu.

Redagavo Darexs
Nuoroda į pranešimą
Dalintis kituose puslapiuose

Šiaip dedikuoti.lt tikrai suką maklę kažkokią. Nuo 5dienio suportas normaliai situacijos mūsų neišaiškino ir nesuteikė jokios infos...išsikraustėm.

 

Beto, dar baisiai įdomiai pas juos QUOTAGUIDLIMIT keistokai jie skaičiuoja vieta_servery *10 +100, tai realiai čia yra LABAI mažai...

Visur kitur duoda pvz 50gb vietos imant apie 2,5milijonus limitą..o čia TIK 600...ir šiaip didelis šnipštas, eilinį kartą nusivyliau...stengiuosi atsisakyti visų paslaugų, nors naudojausi ne vienerius metus.

Nuoroda į pranešimą
Dalintis kituose puslapiuose

Klausyk, tai jei tavo naudojami kreivi script'ai ėda serverį tai tu didink iki CPU galią nors ir iki 32GHz, vistiek serveris bus apkrautas nes tu tą leidi. Esi girdėjęs apie komandą "top" (serverio resursų panaudojimo statistika), programų optimizavimą ar kažką link to?

Tu nemanyk jog puolu, tik gal tu pats klaidingai mastai ir stengiesi suformuoti kitiems tokį mastymą. Įdinga.

Nuoroda į pranešimą
Dalintis kituose puslapiuose

Šita svetainė seniau stovėjo ant hostex.lt ir veikė puikiai, tačiau man reikėjo USA serverio todėl pasirinkau dedikuoti.lt.

 

Dedica tu pats bandai prieš visus suversti kaltę ant manęs ir mano svetainės, nes tu dirbi šitoje įmonėje ir neesi objektyvus.

Redagavo Darexs
Nuoroda į pranešimą
Dalintis kituose puslapiuose

Manau, kad bet kuriuo atveju reikia išsiaiškinti, kur šuo pakastas. Nes nu išeisi tu iš ten, paimsi kitus serverius, ir jeigu ten bus tas pats su 16GHz? Ką tada sakysi dėl minimalaus Wordpress? Žodžiu, turi iš jų supporto išreikalauti išsamios informacijos, kas būtent stabdo ir kada būtent stabdo. Jei procesorius - tal gal koks nors paveiksliukų automatinis generavimas dažnai eina? O gal čia kalta būtent dėl to kad JAV? Faktorių gali būti daug, bet neskubėk kaltinti provaiderio.

 

Man irgi buvo kartą, kad ant didelio apkrovimo projekto (~100 000 per dieną) kažkas pradėjo žiauriai stabdyti, pasakiau adminui kad RAMo pridėtų, o kai pasiaiškinom - pasirodė, kad vienoje DB lentelėje ant vieno svarbaus lauko indekso nebuvo...

 

Taip kad linkiu dasikasti iki esmės :)

Nuoroda į pranešimą
Dalintis kituose puslapiuose

Forumo narys 'Slashas' turi wordpress svetainę su vidutiniu lankytojų srautu, svetainės lankomumas dažnai pakyla. Nėra srauto ir vietos ribojimų (virtualiai). Panaudota buvo daug kešavimo, proxy mechanizmų, nemažai routingo, virtualių tinklų (HA). Šiuo metu tinklalapis sugeba pasiekti realių 3000 lankytojų per sekundę, prie 6000 lankytojų per sekundę prasideda apkrovos, daugiau nei 10000 - lėtesnis darbas (didžiausios apkrovos).

 

Trumpai tariant prie 2000 unikalių lankytojų per dieną, virtualus serveris būna apkrautas 0%, sunaudojamas RAM kiekis 1.8GB (tą patį galima padaryti su 1024mb).

 

Didžiausios apkrovos atititenka pačiam cloud'ui, nes yra bent 3 virtualūs NIC (tinklo kortos), 2% įskaitant ir patį NODE.

 

Viskas yra taip gražiai sudėliota, kad net atliekant uždarbis.lt atsargines kopijas (238GB) ir apkraunant tiek uždarbis.lt tiek naują cloud'ą (800+ mbps srauto) neapsikrauna nei wordpress puslapiai, nei uždarbis.lt, lankytojai to nepajaučia.

 

Pliusai :

  • 'Snapshotindamas' VM galiu dubliuoti juos, užtrunka greičiau nei perkelti informaciją ar atlikti atsarginę kopiją.
  • 1 VM - 1gbps, 16000 lankytojų per sekundę maksimaliai, milionai atvertimų per dieną.
  • 1 VM kaina nepakils daugiau 500 lt/mėn - pigu :)

Minusai :

  • Padidinti atlikti pakeitimus cloude užtruks 1-2 valandas.
  • Nėra vieno recepto visiems 'appsams', sunku realizuoti užtrunka daug laiko.

 

Naudojama varnish konfiguracija optimizuoti wordpress.

 

backend default {
    .host = "localhost";
    .port = "80";
}
acl purge {
       "localhost";
}
sub vcl_recv {
       if (req.request == "PURGE") {
               if (!client.ip ~ purge) {
                       error 405 "Not allowed.";
               }
               return(lookup);
       }
if (req.url ~ "^/$") {
              unset req.http.cookie;
           }
}
sub vcl_hit {
       if (req.request == "PURGE") {
               set obj.ttl = 0s;
               error 200 "Purged.";
       }
}
sub vcl_miss {
       if (req.request == "PURGE") {
               error 404 "Not in cache.";
       }
if (!(req.url ~ "wp-(login|admin)")) {
                       unset req.http.cookie;
               }
if (req.url ~ "^/[^?]+.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)(\?.|)$") {
      unset req.http.cookie;
      set req.url = regsub(req.url, "\?.$", "");
   }
   if (req.url ~ "^/$") {
      unset req.http.cookie;
   }
}
sub vcl_fetch {
       if (req.url ~ "^/$") {
               unset beresp.http.set-cookie;
       }
if (!(req.url ~ "wp-(login|admin)")) {
                       unset beresp.http.set-cookie;
}
}

 

Pradėk nuo varnish, jeigu nenaudoji mod_rewrite - pereik prie nginx-fpm. NENAUDOK eAccelerator, APC, x-cache.

 

Varnish, nginx ir php-fpm tau sumažins apkrovas - 90% :)

 

https://www.varnish-cache.org/

http://nginx.org/

http://php-fpm.org/

Nuoroda į pranešimą
Dalintis kituose puslapiuose

Projekta su tokiu lankomumu galima laisvai laikyt ant 2Ghz, 1GB ram, 100Mbps servo ir nebus jokiu lagu. Cia problema greiciausiai su tavo webu ir taip kaip yra naudojami resursai.

 

Panasu projekta su 2.5k u/v day laikau shared hostinge uz kuri moku 2.06$ per menesi.Ten pat laikau dar du puslapius per kuriuos susidaro dar 1k+ lankytoju per diena.Galutinis rezultatas: 3.5k lankytoju per diena,100+ online per visus puslapius nuo pietu iki vakaro,moku ~6 litus per menesi,uptime galima sakyt 99.99% (buve pora kartu,kad keliom minutem svetaines sukosi letokai),per puse metu negavau nei vieno perpejimo,kad isnaudoju per daug resursu ar pasiulymo kraustytis i vps.+ pamirsau paminet,kad hostinu virs 4k paveiksleliu puslapiuose,per visus puslapius padaroma 40-60k pravertimu per para.

 

P.S.Tiems kas naudoja "google xml sitemap 3.2.6" plugina wordpress'e ir turi sitemap'a su daug nuorodu patarciau isjungt automatini sitemap'o atnaujinima,kadangi sitemap'as atsinaujina kiekviena kart idejus nauja posta ir turint daug nuorodu tai reikalauja nemazai resursu.

Redagavo 8000k
Nuoroda į pranešimą
Dalintis kituose puslapiuose

Nesamonė, kad 16 GHz ir nepaveža svetainės... Pas mane 50 online (taip live zilla rodo) (per abi svetaines, vienos 4-5k unikalių per dieną) tai net nepajaučiau kad naudojamas CPU taip ryškiai... Gal geriau pasididink iš 10 mbps į 50 mbps, ir pastebėk servo aprovą (pvz per vmstat).

Redagavo nontrex
Nuoroda į pranešimą
Dalintis kituose puslapiuose

Laba diena,

 

aš būčiau labiau linkęs padėti išspręsti problemą. Tačiau iš pateikiamo grafiko iš tikrųjų net neaišku ar yra problemos su apkrovomis. Nesimato skaičiukų skalės. Jei ten 1-2, tai kas turėjo pasikeisti pakeitus dažnį? Vienas, du aktyvus procesai yra visiškai normalu tiek 2 branduolių sistemai tiek ir 8 branduolių, ir našumo tai vargu ar stipriai priduotų. Žinoma, jei ten 10-20, tuomet taip, apkrovos teoriškai turėjo sumažėti kokį 50%. Tačiau vėlgi nebūtinai, apkrovos gali laikytis tol, kol branduolių kiekis nebus padidintas iki tiek(galimi ir kiti optimizavimo būdai), kad sugebėtų aptarnauti aktyvius procesus pakankamai greitai, kad nesikauptų jų eilės.

Nuoroda į pranešimą
Dalintis kituose puslapiuose

O įdomu, kodėl eAccelerator ir APC netinkami? Gal būtų galima išsamiau? Ačiū.

 

Todėl kad jie naudoja disko kešavimą. Daliai php funkcijų/objektų yra sukuriamos direktorijos ir cache failai su saugoma skripto informacija. Cache generuojamas gabaliukais, vėliau sudedamas į vieną puslapį.

 

Tikras cache naudotų RAM saugoti informacijai arba generuotų statinius .html failus .

 

eAccelerator/APC/xcache žinoma paspartina darbą, bet tai nėra pats geriausias variantas, net ir naudojant ramdisk (diską RAM atmintyje)

 

Laba diena,

 

aš būčiau labiau linkęs padėti išspręsti problemą. Tačiau iš pateikiamo grafiko iš tikrųjų net neaišku ar yra problemos su apkrovomis. Nesimato skaičiukų skalės. Jei ten 1-2, tai kas turėjo pasikeisti pakeitus dažnį? Vienas, du aktyvus procesai yra visiškai normalu tiek 2 branduolių sistemai tiek ir 8 branduolių, ir našumo tai vargu ar stipriai priduotų. Žinoma, jei ten 10-20, tuomet taip, apkrovos teoriškai turėjo sumažėti kokį 50%. Tačiau vėlgi nebūtinai, apkrovos gali laikytis tol, kol branduolių kiekis nebus padidintas iki tiek(galimi ir kiti optimizavimo būdai), kad sugebėtų aptarnauti aktyvius procesus pakankamai greitai, kad nesikauptų jų eilės.

 

Manau dar galimas variantas, kad stebint disko apkrovas buvo praleista CPU WAIT stadija procesuose (php), jeigu sistema atliekant vienus ar kitus procesus daliai procesų laukia (WAIT) tokiu atveju informacija tarp CPU/RAM nespėjama įrašyti į diskų masyvą (RAID) - tai reiškia, kad apkrovas rodys ne diskų masyvas o CPU, nes CS/US/SY/WA/ST visos stadijos yra įskaičiuojamos į bendrą apkrovą.

 

Kitas variantas padidinti mysql/php threads skaičių, tam kad išnaudotų visus branduolius.

Nuoroda į pranešimą
Dalintis kituose puslapiuose

Panasu jog tiek apache2 tiek mysql labai gerai moka isnaudoti daug branduoliu, tad jei turi 16GHZ, o tai panasu jog 8 ar maziau branduoliu, jiems apkrauti turetu pakakti ir 8 aktyviu lankytoju. Taip viskas priklauso ir nuo kitu serverio parametu. Srauto trukumas turetu kaip tik mazinti serverio procesoriaus ir didinti atminties suvartojima. Disko sparta sunkiausiai prognozuojamas dalykas, nes VPS ar VDS yra ne atskiras serveris ir disko posisteme tenka dalintis su kaimynasi, kuru tarpe gali buti ir "triuksmadariu"...

Tad panasu jog esant dideliam lankytoju kiekiui, daugejant cpu turetu viskas pagreiteti, nebent pats serveris kuriame sukasi vps yra perdaug apkrautas...

Redagavo boileris
Nuoroda į pranešimą
Dalintis kituose puslapiuose

Dėl to pagrindinio grafiko... Aišku, pastabumas ir iškarto pasidalijimas su kitais, tai labai gerai: "sharing is caring" :) Iš karto pasakysiu, nesinaudojau dedikuotų serverių paslauga... Tačiau dar klausimas kaip tas grafikas yra atvaizduojamas, ką jis atvaizduoja? Gal vizualiai atrodo tas pats, o iš tikrųjų CPU užkrovimas yra mažesnis... Nes pagal paveikslėlį, nesuprasi. Reikia mastelio! :)

 

Kitas aspektas susijęs su šia situacija slypi tame, kad gali būt žmonių ir 50 :) Tačiau pvz.: paimkime dedikuotą serverį kur yra kelios svetainės (gal net dešimt), kiekviena iš jų didelio lankomumo neturi. Tačiau kiekviena turi savo turinio valdymo sistemą, su instaliuotais įskiepiais, kurie savo ruožtu ir suvalgo po šiek tiek resursu. Tarp tų svetainių gali būti viena laabai apkraunanti, tiesiog ryjanti serverio resursus, nes kažkuris įskiepis buvo kreivai suprogramintas. O dar jeigu ir daug puslapių (apie 10 000), tai Google-Bot vaikščioja palei svetainę ir indeksuoja puslapius, pvz.: 700 - 1000 į dieną, tai ir atsiranda apkrovimai.

 

P.S. Nedirbu pas serveriai.lt ;) Ir šiaip, galiu klysti

Nuoroda į pranešimą
Dalintis kituose puslapiuose

as toki projekta nei uz ka nedeciau i VPs su openvz :)

kad tau duoda 16 GHZ, tai dar nereiskia kad tu juos turi tikrai 100% :) tokia jau ta openvz technologija... ISP gali sakyt ka nori, kad garantuoja juos ir t.t. bet realybej man labai idomu kaip jis ta garantavima realizuoja? openvz ir yra esme gi, kad turint serveri pvz su dual 3 GHz, kokiais 4 GB ram, tu gali ten laikyti kokius 8 VPS, ir visiems rasyti kad jie gauna po 1 GB RAM ir 1 GHz cpu garantuotu resursu :)

 

siulyciau toki projekta kelti arba i tikrai dedikuota serveri ( o ne dedikuota pagal IV supratima :) arba bent jau i VPs su KVM arba xen virtualizacija, arba ten, kur mazesnis oversellinimas, arba dar, kaip sake, ziureti ir optimizuoti aplikacijas bei servisus ir isnaudoti cache mechanizmus... taciau visi keshavimai irgi naudoja ram ir cpu arba hdd.

 

cia labai sunku is tikro patarti, nes reiktu gilintis i tavo situacija, koks softas, kaip ten kas parasyta, koks turinys ir t.t.

Nuoroda į pranešimą
Dalintis kituose puslapiuose

Prisijunkite prie diskusijos

Jūs galite rašyti dabar, o registruotis vėliau. Jeigu turite paskyrą, prisijunkite dabar, kad rašytumėte iš savo paskyros.

Svečias
Parašykite atsakymą...

×   Įdėta kaip raiškusis tekstas.   Atkurti formatavimą

  Only 75 emoji are allowed.

×   Nuorodos turinys įdėtas automatiškai.   Rodyti kaip įprastą nuorodą

×   Jūsų anksčiau įrašytas turinys buvo atkurtas.   Išvalyti redaktorių

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

Įkraunama...
  • Dabar naršo   0 narių

    Nei vienas registruotas narys šiuo metu nežiūri šio puslapio.

  • Prisijunk prie bendruomenės dabar!

    Uždarbis.lt nariai domisi verslo, IT ir asmeninio tobulėjimo temomis, kartu sprendžia problemas, dalinasi žiniomis ir idėjomis, sutinka būsimus verslo partnerius ir dalyvauja gyvuose susitikimuose.

    Užsiregistruok dabar ir galėsi:

    ✔️ Dalyvauti diskusijose;

    ✔️ Kurti naujas temas;

    ✔️ Rašyti atsakymus;

    ✔️ Vertinti kitų žmonių pranešimus;

    ✔️ Susisiekti su bet kuriuo nariu asmeniškai;

    ✔️ Naudotis tamsia dizaino versija;

    ir dar daugiau.

    Registracija trunka ~30 sek. ir yra visiškai nemokama.

  • Naujausios temos

  • Karštos temos

×
×
  • Pasirinkite naujai kuriamo turinio tipą...