Server pro VPS hosting - II. (diskuse)

[kralyk z abclinuxu]

U toho ECC by mě zajímalo, proč je to tak kritický na serveru a proč na desktopu to je prakticky šumák. Je to tím, že na desktopu se obsah RAM mnohem častěji obměňuje (ať už restartem nebo pestrostí činnosti)?

Byla by určitě moc zajímavá nějaká statistika o tom, kolik množsví chyb ECC ve skutečnosti na serveru odhalí a zaloguje za nějakej časovej úsek (měsíc, rok,...). Jsem si vědom, že něco takovýho publikoval google, ale zajímalo by mě, jak to je konkrétně třeba u tebe na VPS nebo na vpsFree kolegy snajpy.

[snajpa]

ECC pameti jsou totalne overrated, to je jedno z enterprise dogmat Ale kdyz chces vic jak 64GB RAM na CPU, tak uz si musis ECC pameti poridit, protoze potrebujes buffered moduly a ty jine nez ECC nesezenes.
Priklad z jednoho nodu z Prahy (ale tak je to na vsech):

[root@node9.prg.vpsfree.cz]
 ~ # edac-util -v
mc0: 0 Uncorrected Errors with no DIMM info
mc0: 0 Corrected Errors with no DIMM info
mc0: csrow0: 0 Uncorrected Errors
mc0: csrow0: CPU_SrcID#0_Channel#0_DIMM#0: 0 Corrected Errors
mc0: csrow1: 0 Uncorrected Errors
mc0: csrow1: CPU_SrcID#0_Channel#0_DIMM#1: 0 Corrected Errors
mc0: csrow2: 0 Uncorrected Errors
mc0: csrow2: CPU_SrcID#0_Channel#1_DIMM#0: 0 Corrected Errors
mc0: csrow3: 0 Uncorrected Errors
mc0: csrow3: CPU_SrcID#0_Channel#1_DIMM#1: 0 Corrected Errors
mc0: csrow4: 0 Uncorrected Errors
mc0: csrow4: CPU_SrcID#0_Channel#2_DIMM#0: 0 Corrected Errors
mc0: csrow5: 0 Uncorrected Errors
mc0: csrow5: CPU_SrcID#0_Channel#2_DIMM#1: 0 Corrected Errors
mc0: csrow6: 0 Uncorrected Errors
mc0: csrow6: CPU_SrcID#0_Channel#3_DIMM#0: 0 Corrected Errors
mc0: csrow7: 0 Uncorrected Errors
mc0: csrow7: CPU_SrcID#0_Channel#3_DIMM#1: 0 Corrected Errors
mc1: 0 Uncorrected Errors with no DIMM info
mc1: 0 Corrected Errors with no DIMM info
mc1: csrow0: 0 Uncorrected Errors
mc1: csrow0: CPU_SrcID#1_Channel#0_DIMM#0: 0 Corrected Errors
mc1: csrow1: 0 Uncorrected Errors
mc1: csrow1: CPU_SrcID#1_Channel#0_DIMM#1: 0 Corrected Errors
mc1: csrow2: 0 Uncorrected Errors
mc1: csrow2: CPU_SrcID#1_Channel#1_DIMM#0: 0 Corrected Errors
mc1: csrow3: 0 Uncorrected Errors
mc1: csrow3: CPU_SrcID#1_Channel#1_DIMM#1: 0 Corrected Errors
mc1: csrow4: 0 Uncorrected Errors
mc1: csrow4: CPU_SrcID#1_Channel#2_DIMM#0: 0 Corrected Errors
mc1: csrow5: 0 Uncorrected Errors
mc1: csrow5: CPU_SrcID#1_Channel#2_DIMM#1: 0 Corrected Errors
mc1: csrow6: 0 Uncorrected Errors
mc1: csrow6: CPU_SrcID#1_Channel#3_DIMM#0: 0 Corrected Errors
mc1: csrow7: 0 Uncorrected Errors
mc1: csrow7: CPU_SrcID#1_Channel#3_DIMM#1: 0 Corrected Errors
[root@node9.prg.vpsfree.cz]
 ~ # uptime
 01:29:49 up 108 days, 23:44,  1 user,  load average: 13.10, 13.43, 15.06

[Dundee5]

To je dost překvapivá informace :) Ještě jsem neviděl žádnou statistiku, která by říkala, že se ECC nevyplatí...

V desktopu se to imho nepoužívá jednak kvůli častějším restartům (chyby se tolik neakumulují) a také prostě proto, že spolehlivost není tak důležitá. Jedna BSOD za rok nikoho nezabije.

[snajpa]

Asi zalezi na prostredi, jak moc do nej pronika kosmicke zareni a podobne. Nicmene u nas v racku ECC pameti moc rozdilu nenadelaji. Na druhou stranu, pokud platim 2500 Kc bez DPH za 16GB DDR3 ECC 1600MHz modul, tak je mi celkem jedno, jestli je to, nebo neni ECC, jsou to celkem smesne penize

[Dundee5]

Kde jsi viděl tak dobrou nabídku? Prošel jsem pár obchodů (alza, atcomp, agem) a nikde jsem tak dobrou nabídku neviděl. Koukal jsem ale na unbuffered ECC paměti.

[snajpa]

Tady, s moji cenovou urovni to dava 3150 s DPH, bez ni 3600, coz porad jde, rekl bych.

[bogo]

Taky se to na desktopu nepouziva proto, ze intel desktopove cpu to vubec nepodporuji (afaik). AMD alespon na socketu AMx ano, na FMx netusim. Plus spousta kiddies co si vsechno pretaktuji...

BTW pro zajimavost, nvidia tesla umi ECC ale ma moznost to vypnout, protoze to spomaluje operace s pameti o nejakych 5% jak je to u cpu ramek ale nevim.

Jinak souhlas se snajpou, ECC je overrated - IMHO to nejvic pomaha zjistit kdy pameti fyzicky zestarnou k nespolehlivosti, coz by melo chvilku trvat... takze by mozna stacilo po dvou letech ramky prodat a koupit nove, nebo rovnou vymenit celej server

[Honza Jaroš]

Sedmičkový Debian, zdá se, nebude OpenVZ podporovat. Počítá s tím Proxmox nějak do budoucna?

[Dundee5]

Ano. Proxmox vůbec nepoužívá OpenVz balíky z Debianu. Kernel používá z RHELu 6 a OpenVz nástroje si kompilují sami ze zdrojáků.

[David Jaša]

4 GB nebo 8 GB RAM pro stroj pro virtualizaci? Tedy, ne, že by to nešlo, ale přijde mi to jako dělat z osobáku kamion. Ono obecně s virtualizací je to obráceně, než u nákupu "klasickýho" železa - čím větší stroj, tím míň si hypervizor ukousne z celkových systémových prostředků, a tím větší šance na efektivní využití jader CPU.

Osobně budu používat OpenVz kontejnery, protože mají velmi malý overhead (cca 3%) a alokují zdroje on-demand (když kontejneru dáte 2GB RAM, neznamená to, že 2GB opravdu ubydou).

Ta tvrzení jsou přinejmenším nepřesná. U KVM se alokují zdroje také on-demand, nicméně pro paměť žádná odboba TRIM neexistuje a když widle při bootu přepíšou celou paměť nulama, holt se celá obsadí. Nicméně to není navždy, jsou dvě možnosti, jak vzít paměť zpět:

• Pokud běží více "stejných" strojů, KSM je schopné samo o sobě srazit využitou paměť na úroveň kontejnerové virtualizace, protože qemu a jádro + OS + aplikace guestů jsou v paměti jen jednou
• pokud ani tohle nestačí, dá se ve volném místě virtuálky nafukovat balón a takto označené místo opět může využívat hypervizor.

[Dundee5]

8GB by mělo stačit pro počáteční rozjezd, kdy tam bude jen pár klientů.

Aha, díky za info. Myslel jsem, že KVM tu paměť celou zarezervuje.