Výkon disků - VPS vs. fyzicky server

Dobrý den,

mám dotaz ohledně rozdílu výkonu disků u klasického fyziského serveru a VPS. Využíváme jeden web server s disky 500 GB / 7200 ot., který je rozdělen na 2 VPS. Na naší polovině běží 80-90 trafiku na daný server. Téměř veškerý obsah je cachovaný do souborů na disku (desítky tisíc malých souborů s html obsahem).

Nyní přemýšlíme o možnostech, jak urychlit práci se soubory. Uvažovali jsme o zakoupení rychlejších disků, ale náš webhoster nás informoval, že rychlejší disky jsou výrazně dražší a že by výkonu serveru pomohlo přejít z VPS na klasický fyzický server, jelikož se data v případě VPS zapisují na disk přes nějakou softwarovou vrstvu. Vše při zachování disků stejných parametrů.

Je tohle tvrzení pravda? Lze nějak odhadnout, o kolik procent by taková změna mohla urychlit práci se soubory na disku?

Díky moc za odpověď.

disky jsou ted vseobecne vyrazne drazsi vsechny az o 150% zminoval jsem to zde na WT

zamyslete se nad pouzitim SSD

ty cenove o tolik nestoupli a vykonove si pomuzete mnohem vice

otazkou je jak velkou kapacitu potrebujete (500GB v SSD levne nebude)

co se tyce otazky zpomalovani nejakych zapisu ci operaci pri virualizaci, je naprosto zanedbatelna

mnoho nasich klientu ma sve servery na virtualizovane platforme se sdilenim 1:1 jen proto, aby mohli rychle migrovat pri potizich s HW apod.

Pokud jde opravdu o nacachovane soubory s html tak je lepsi moznost cachovat nejakym zpusobem bud rovnou do ramky nebo skladat soubory alespon do ramdisku...

Diky moc za info. Reakci od hostera jsme dostali jeste v dobe pred povodnemi v Asii.

Kazdopadne jsme se ptali i na SSD disky a bylo nam odpovezeno, cituji:

"SSD disky nejsou určeny pro servery, protože mají omezený počet zápisů a vzhledem k tomu, že používáte mimo jiné IO operace i caching, tak by jejich životnost při tomto zatížení nebyla valná."

Zminili se take, ze "Jako rychlejší disky se používají SCSI s 15500 otáčkami. Nicméně jejich cena se pohybuje cca kolem 10000 Kč za 300GB za jeden disk".

Rozhodne nejsem odbornik, ale napr. na alza.cz jsem nasel SAS serverove disky s 15k ot. s kapacitou 300 GB v cene kolem 6 000 Kc bez DPH. SCSI vychazeji v 300 GB provedeni na alza.cz na 16 540 Kc bez DPH.

Aktualne maji vsechny nase weby (skripty + obrazky) kolem 20 GB, takze i disky s kapacitou 160 GB by mohly bohate stacit.

Tak ted nevim no. ;)

---------- Příspěvek doplněn 29.10.2011 v 20:14 ----------

Problem s ukladanim do operacni pameti je ten, ze pri vypadku/restartu serveru, jdou vsechna data do kytek a musi se cachovat znovu, coz je dost problem, protoze jakmile se v jednu chvili zacnou generovat vsechny stranky znovu (a ukladat na disk/ram pro nasledne cteni cache souboru), vyrazne vzroste zatez serveru. Zkouseli jsme to s APC a jeji User Cache. Rychlost byla fajn, ale vzhledem k faktu, ze v prumeru cachujeme stranky s expiraci cca. 1 tyden a server se udajne z provoznich duvodu kazdou pulnoc restartuje, o vsechna data jsme prichazeli a cele kouzlo cachovani html bylo tatam.

Pokud mate typ na technologii, ktera by dokazala ukladat do OP, ale nejakym zpusobem by "zalohovala" data i na disk, sem s ni. ;)

Diky.

Původně odeslal Adam Šitavanc

"SSD disky nejsou určeny pro servery, protože mají omezený počet zápisů a vzhledem k tomu, že používáte mimo jiné IO operace i caching, tak by jejich životnost při tomto zatížení nebyla valná."

SSD v serverech jsou standardne nasazovany dele nez dva roky a zadne vyrazne problemy s tim nikdo nema (stejne jako s mechanickymi HDD)

reci o "zapisech" jsou v tomto pripade neopodstatnene - neco jako kdybyste rekli, ze mechanickemu disku se "zadre" motorek :-)

(tedy pokud do serveru nenacpete nejlevnejsi SSD, urcene napr. do netbooku)

napr. zminene kartove jednotky OCZ RevoDrive (nyni uz snad ve ctvrte generaci vyrobce) nabizeji od pocatku 3-5 let zaruku a prvnich 12 mes. zdarma data recovery v pripade jakekoliv "smrti" disku

SAS nebo SCSI disky sve opodstatneni samozrejme maji, ale do ceny zapocitejte i kvalitni RAID radic, ktery neni uplne zdarma
(nejlevnejsi pouzitelne Areca/Adaptec/3Ware kolem 8tis.)

---

PS napr. tato hracicka je vazne mazec :-)

Nam slo v prve rade o nabidku. Platime si managed server/vps a chteli jsme slyset, ze kdyz budeme pouzivat SAS/SCSI/SSD disk v RAIDu, bude to mesicne cele drazsi o tisicovku (nebo o dve nebo o tri).

V zasade jsme ale dostali odpoved, ze SSD nejdou a SCSI taky ne, protoze jsou drahe (ani nam neudelali nabidku, proste je "nepodporuji"), SAS nenabidli vubec. Jedina reakce byla prechod z virtualizovaneho na fyzicky server. Coz nemusi ocivinde nutne znamenat narust vykonu.

Neradi bychom zbytecne presli na fyzicky server, ktery bude o 50 % drazsi, kdyz na vykonu ziskame 5 %.

Jeste me napadlo jak velky vliv muze byt takova rychlost disku na databazi (postgresql)?

Diky za informace.

Původně odeslal Adam Šitavanc

Jeste me napadlo jak velky vliv muze byt takova rychlost disku na databazi (postgresql)?

pristupova doba a rychlost cteni/zapis ma nejvetsi vliv na jakekoliv typy databazi

co se tyce hlavne pristupove doby u SSD, to Vam de fakto zadny mechanicky disk neni schopen nabidnout

---

jinak na konkretni reseni serveru/ceny se zeptej sveho registratora :-)

Původně odeslal Adam Šitavanc

...server se udajne z provoznich duvodu kazdou pulnoc restartuje

Nechci diskuzi zatahavat jinam, ale tohle by se u zadneho hostera, ktery ma server pod kontrolou nemelo dit (pokud k tomu nema nejakej opravdu padnej duvod tak je to amaterizmus). Asi snad i existuje nejaka reverzni proxy, ktera by se takto nejak dala nastavit, nebo si to holt uskriptovat primo se souborama, ale jednodusi by bylo poresit ty restarty, nebo holt investovat do lepsiho...

Navrhuji v rychlosti:

• revize aplikace, např. slow query, počet souborů v jednom adresáři
• proxy nad http
• přidat RAM, CPU (těžko radit)
• změnit virtualizační technologii (třeba i jen upgrade) - na čem to virtualizuje?
• přechod na vlastní fyzický server
• změna VPS hostera - kdopak to je? (raději případně jen do PM)

Je lepší najít úzké místo, než do toho mlátit větším kladivem...

Původně odeslal toshi

Nechci diskuzi zatahavat jinam, ale tohle by se u zadneho hostera, ktery ma server pod kontrolou nemelo dit (pokud k tomu nema nejakej opravdu padnej duvod tak je to amaterizmus). Asi snad i existuje nejaka reverzni proxy, ktera by se takto nejak dala nastavit, nebo si to holt uskriptovat primo se souborama, ale jednodusi by bylo poresit ty restarty, nebo holt investovat do lepsiho...

Zkusim presneji zjistit, proc se ty restarty (planovane) deji, ale co si matne pamatuju z minula, tak se to tykalo Apache.

Otazka je, zda pomer investovanych prostredku bude korespondovat s narustem vykonu ;)

Původně odeslal Adam Šitavanc

Zkusim presneji zjistit, proc se ty restarty (planovane) deji, ale co si matne pamatuju z minula, tak se to tykalo Apache.

Otazka je, zda pomer investovanych prostredku bude korespondovat s narustem vykonu ;)

To vypada na standartni logrotate, ten je provozne v poradku.

Da se to jeste obejit:
- cronlog - protece nam pres to 25GB logu za den a bez problemu
- zkusit se podivat, jestli apache nepodporuje nejake znovuotevreni logu na jednom ze signalu (treba nginx to ma tusim na SIGUSR1).

Logrote nerestartuje server, ale jen apache.

Kolik máte přístupů že máte takovéto problémy? Statické stránky, to znamená, že se apache úplně vyhne jakémukoli generování obsahu, standardní server dokáže obsloužit stovky za sekundu.

Dejte více info, ať vám tu můžeme poradit.
Mrkněte to topu (nebo ho sem vypište) jak moc máte zátěž na IO operacích a jak jste na tom s cachováním do paměti.

Původně odeslal Michal Kumžák

Logrote nerestartuje server, ale jen apache.

Původně odeslal Adam Šitavanc

ale co si matne pamatuju z minula, tak se to tykalo Apache.

Což docela sedí.

Uplne presne nerozumim frazi "takoveto problemy". Nejedna se momentalne o to, ze by server nezvladal plnit svou funkci. Pouze chceme vykon, resp. rychlost webu, zvysit a do budoucna eliminovat moznost, ze prostredky nebudou dostatecne.

Nemame pristup pres SSH (nikdy jsme jej nepozadovali), takze vami pozadovane udaje bohuzel nemam k dispozici. A co si predstavit pod "jak jste na tom s cachováním do paměti". S cachovanim skriptu nebo dat? Nerozumim Vasi otazce.

Diky.

Pokud jde vylozene o staticky obsah, pak bych mozna apache vymenil za nginx. Pro staticky obsah vykonove velice dobry (prekona apache) a nastavene je taky jednodussi.

(Tim nerikam, ze apache nemuze byt rychle, ale jeho vykonove nastaveni je ponekud vyssi divci :D)

Ono je to "staticky" obsah "jak kdy". Jinak receno, obsah serviruji dynamicke skripty (psano v YII), ktere loaduji data z databaze (PGSQL), po prvnim loadu se data ulozi na disk do souboru a pak uz se serviruje jenom ulozeny HTML vystup (zivotnost cache v radu dnu). Klasicky fullpage file caching.

Kazdopadne nginx, pripadne lighthttpd, jsme jiz drive zaradili do moznych planu na "tuning" serveru. ;)

V tom pripade nechte na pozadi apache a nginx pouzij pouze jako proxy. Melo by to pomoci.

Nebo před apache dejte nějaké cachovací proxy. Pak by hodně požadavků nešlo vůbec do apache.

Když nemáte SSH přístup, tak nám aspoň řekněte o jaké návštěvnosti, počtu zobrazení stránek a trafiku se tu bavíme.

Zrovna dnes jsem posílal odkaz na článek o hostingové architektuře StackExchange, ve které se píše

SSD shouldn't make your machine run faster because you should be running in RAM already.

Cachováním souborů na disk... pořád musíte sahat na disk.

To nemusí být vždy pravda. Třeba u databázového serveru potřebujete skutečné rychlé čtení z disků. Tam sice něco nacachováno je, ale určitě ne dost. Pokud teda tomu serveru nedáte skutečně hodně paměti.

Jak říkám, bez nějakých čísel se nedá příliš poradit.

Je nemožné diskutovat takhle obecně, každopádně databáze mají širokou paletu možností cachovat v paměti - od tabulek, přes indexy a připojení až po výsledky dotazů.
Musíte to ale ušít každé aplikaci na míru a to poskytovatelé VPS z ekonomických důvodů dělat nebudou nebo ani neumí.

A když k tomu z nějakého důvodu není vůle, měl by tazatel aspoň udělat to, co navrhoval Toshi už na začátku - cachovat hotové soubory v RAM, ne na disku.
Prostě chcete sahat na disk co nejméně, i když to je SSD.