21 Aug
2018
21 Aug
'18
9:53 a.m.
Ahojte,
jak asi vite, s Intelovskym hardware to vypada bidne.
Od zacatku roku to mame uz nejmin 5 kritickych bezpecnostnich chyb,
kvuli kterym se mi hodne spatne spi.
To mame spectre, meltdown, ruzny varianty, ted L1TF jako posledni
zabijak...
Abychom nase systemy patchnuli, nezbyde nam, nez vypnout hyperthreading
(HT).
To znamena prijit o cca 30% vykonu.
Aktualni myslenka, kterou mame, je vyhodit vsechny 6ti jadrovy procesory
a nakoupit bazarovy Ivy Bridge E5-2670v2, co je 10 jader @ 2.5 GHz za
150 EUR kus.
To by nam melo umoznit vypnout HT.
Nejvetsi otazkou je, jak dlouho bude jeste Intel vydavat opravy
mikrokodu pro Ivy - zatim to vypada, ze bude + nektery opravy tech chyb
od komunity mikrokody nepotrebuji a fungujou lip (napr. retpolines proti
spectre, pokud to neni na nejnovejsich Intelech).
My mame majoritu systemu jeste Sandy Bridge, vykonem by nam dostacovaly,
pokud bychom nebyli nuceni vypnout HT.
Financne je to jednou z mala funkcnich variant, co mne napada, jak se
proti tomuhle branit a neco s tim delat.
Co si o tom myslite, nemate nekdo lepsi napad?
Bohuzel kupovat novy systemy s AMD ma dve downsides:
1. za chvili je tu EPYC2, takze to bude hned outdated;
2. DDR4 a teda novy pameti obecne jsou aktualne skoro preplaceny zlatem,
jak je jich malo.
Vitam jakykoliv komentare a otazky na tohle tema ;)
Osobne to vidim na upgrade na 2x 10core Ivy Bridge ve vsech masinach
(SNB a IVB maji stejne desky, nastesti) a vypnuti HT.
Otazka je, jaka dalsi spekulace prijde dal a jestli nam to nahodou plan
s Ivy nepolozi...
/snajpa
21 Aug
21 Aug
11:02 a.m.
2018-08-21 11:53 GMT+02:00 Pavel Snajdr <snajpa(a)snajpa.net>et>:
Ahojte,
jak asi vite, s Intelovskym hardware to vypada bidne.
Od zacatku roku to mame uz nejmin 5 kritickych bezpecnostnich chyb, kvuli
kterym se mi hodne spatne spi.
To mame spectre, meltdown, ruzny varianty, ted L1TF jako posledni
zabijak...
Abychom nase systemy patchnuli, nezbyde nam, nez vypnout hyperthreading
(HT).
To znamena prijit o cca 30% vykonu.
Aktualni myslenka, kterou mame, je vyhodit vsechny 6ti jadrovy procesory a
nakoupit bazarovy Ivy Bridge E5-2670v2, co je 10 jader @ 2.5 GHz za 150 EUR
kus.
To by nam melo umoznit vypnout HT.
Nejvetsi otazkou je, jak dlouho bude jeste Intel vydavat opravy mikrokodu
pro Ivy - zatim to vypada, ze bude + nektery opravy tech chyb od komunity
mikrokody nepotrebuji a fungujou lip (napr. retpolines proti spectre, pokud
to neni na nejnovejsich Intelech).
My mame majoritu systemu jeste Sandy Bridge, vykonem by nam dostacovaly,
pokud bychom nebyli nuceni vypnout HT.
Financne je to jednou z mala funkcnich variant, co mne napada, jak se
proti tomuhle branit a neco s tim delat.
Co si o tom myslite, nemate nekdo lepsi napad?
1) zakazat KVM, HT moze ostat zapnuty
2) presunut ludi ktory potrebuju KVM na 1 host a tam vypnut HT
3) nechat HT zapnuty, ale vypnut EPT - co je udajne horsi performance ako
vypnut HT, bude to zavisiet od poctu ludi ktori pouzivaju KVM
Bohuzel kupovat novy systemy s AMD ma dve downsides:
1. za chvili je tu EPYC2, takze to bude hned outdated;
2. DDR4 a teda novy pameti obecne jsou aktualne skoro preplaceny zlatem,
jak je jich malo.
Vitam jakykoliv komentare a otazky na tohle tema ;)
Osobne to vidim na upgrade na 2x 10core Ivy Bridge ve vsech masinach (SNB
a IVB maji stejne desky, nastesti) a vypnuti HT.
Otazka je, jaka dalsi spekulace prijde dal a jestli nam to nahodou plan s
Ivy nepolozi...
/snajpa
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
11:20 a.m.
Bohuzel kupovat novy systemy s AMD ma dve downsides:
1. za chvili je tu EPYC2, takze to bude hned outdated;
2. DDR4 a teda novy pameti obecne jsou aktualne skoro preplaceny zlatem,
jak je jich malo.
Za chvíli outdated je dneska všechno, když na to člověk bere ohled,
nekoupí nikdy nic.
Paměti bych neřešil, bez nich to nejde :-)
12:20 p.m.
On 2018-08-21 13:20, Jirka Bourek wrote:
No neresil :) Ono v situaci, kdy bazarovy DDR3 jsou za hubicku, v
prepoctu na gigabajty a nacachovana data jasne vyhrava bazarovy setup.
To by cena DDR4 musela vyrazne padnout, nekde k pulce ceny ted - coz se
asi stane, ale kdy, to teda tezko rict.
Nevim no, ta cena RAMek je prave dost blocker a kvuli nim ma smysl o tom
bazarovym HW vubec uvazovat...
/snajpa
Bohuzel
kupovat novy systemy s AMD ma dve downsides:
1. za chvili je tu EPYC2, takze to bude hned outdated;
2. DDR4 a teda novy pameti obecne jsou aktualne skoro preplaceny
zlatem, jak je jich malo.
Za chvíli outdated je dneska všechno, když na to člověk bere ohled,
nekoupí nikdy nic.
Paměti bych neřešil, bez nich to nejde :-) _______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
12:30 p.m.
On 21.8.2018 14:20, Pavel Snajdr wrote:
On 2018-08-21 13:20, Jirka Bourek wrote:
No neresil :) Ono v situaci, kdy bazarovy DDR3 jsou za hubicku, v
prepoctu na gigabajty a nacachovana data jasne vyhrava bazarovy setup.
To by cena DDR4 musela vyrazne padnout, nekde k pulce ceny ted - coz se
asi stane, ale kdy, to teda tezko rict.
Nevim no, ta cena RAMek je prave dost blocker a kvuli nim ma smysl o tom
bazarovym HW vubec uvazovat...
Jo takhle, dobrý, nedošlo mi, že v2 ještě mělo DDR3 paměti (plus bazar
hardware používám jenom z vlastních zásob a ideálně jenom pro
active-passive věci, takže jsem možnost nákupu DDR3 vůbec neuvažoval s
tím, že nové jsou dražší než DDR4.)
Bohuzel
kupovat novy systemy s AMD ma dve downsides:
1. za chvili je tu EPYC2, takze to bude hned outdated;
2. DDR4 a teda novy pameti obecne jsou aktualne skoro preplaceny
zlatem, jak je jich malo.
Za chvíli outdated je dneska všechno, když na to člověk bere ohled,
nekoupí nikdy nic.
Paměti bych neřešil, bez nich to nejde :-) 
2:57 p.m.
Ahojte,
chtěl jsem se vlastně zeptat zda je to vlastně vhodné stále dělat na těchto
CPU, tzn jestli není vhodné chvíli počkat, udělat nějakou provizorní
záplatu co řeší L1TF bez vypnutí HT a ještě vydržet. Ano chápu že se to
může rychle proměnit v noční můru. A pokud se však koncem roku objeví Epyc2
a o tom už by se dalo uvažovat či o původním Epyc1 (nebo o Threadripper ale
tam je otázka zda to vydrží). Určitě bych se asi moc neohlížel na starší
technologii, která je v současném stavu jen o trochu lepší než SandyBridge
a stejně problémová.
Mimo to tím souvisí ještě to, zda se blízké budoucnosti, neobjeví
(pravděpodobně ano) další "nový" podobný bezpečností problém, který se opět
bude týkat této architektury.
--
Zdenek <http://www.pripravto.cz>
Dne 21. srpna 2018 14:30 Jirka Bourek <vpsfree-list(a)keroub.cz> napsal(a):
On 21.8.2018 14:20, Pavel Snajdr wrote:
On 2018-08-21 13:20, Jirka Bourek wrote:
Jo takhle, dobrý, nedošlo mi, že v2 ještě mělo DDR3 paměti (plus bazar
hardware používám jenom z vlastních zásob a ideálně jenom pro
active-passive věci, takže jsem možnost nákupu DDR3 vůbec neuvažoval s tím,
že nové jsou dražší než DDR4.)
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
Bohuzel kupovat novy systemy s AMD ma dve
downsides:
No neresil :) Ono v situaci, kdy bazarovy DDR3 jsou za hubicku, v
prepoctu na gigabajty a nacachovana data jasne vyhrava bazarovy setup.
To by cena DDR4 musela vyrazne padnout, nekde k pulce ceny ted - coz se
asi stane, ale kdy, to teda tezko rict.
Nevim no, ta cena RAMek je prave dost blocker a kvuli nim ma smysl o tom
bazarovym HW vubec uvazovat...
1. za chvili je tu EPYC2, takze to bude hned outdated;
2. DDR4 a teda novy pameti obecne jsou aktualne skoro preplaceny
zlatem, jak je jich malo.
Za chvíli outdated je dneska všechno, když na to člověk bere ohled,
nekoupí nikdy nic.
Paměti bych neřešil, bez nich to nejde :-)
3:45 p.m.
Mimo to tím souvisí ještě to, zda se blízké
budoucnosti,
neobjeví (pravděpodobně ano) další "nový" podobný bezpečností
problém, který se opět bude týkat této architektury.
Bingo, protoze uplne to samy muze potkat EPYC, potazmo i EPYC2 - a to
budem dvojnasob nastvani, protoze to bude uplne novej HW...
Neni to jednoznacna situace, nejakej ten HW ale uz potrebujem, takze to
potrebujem na nejakou stranu rozlousknout.
Kdyz se k nejistote s EPYCem pridava cena toho HW vc. RAM, tak
nevim-nevim dvojnasob.
Ono to s tim bazarovym EPYCem sotva bude tak horky, myslim, ze ho dlouho
moc nebude - protoze EPYC poradne neni pokryty ani ted, kdyz uz se vi,
ze bude dvojka - myslim, ze dvojky budou lidi dokupovat a jednicek se
jeste zbavovat nebudou.
Otazky teda jsou dve:
1. co se stavajicim HW? - nahradit vsechno novym nemame jak, rozhodne ne
najednou; nahradit vsemu ale CPU za neco vice-jadrovyho ale ano ->
myslim tedy tady je jasny upgrade na ty 2670v2 a zakazani HT => nebo ma
nekdo lepsi napad?
2. co nakupovat jako dalsi HW na nejblizsi pulrok?
Co nakupovat dal neni ted moc relevantni, protoze resime situaci co s
tim, co mame + co s aktualni nutnou potrebou dalsiho HW. Obmenit muzeme
nejaky kus, ale rozhodne ne vsechno, upgradovat vsemu CPU by ale vyjit
mohlo.
/snajpa
3:58 p.m.
On 21.8.2018 17:45, Pavel Snajdr wrote:
Jde ti o výkon per-cpu, nebo o celkový výkon? Pokud to druhé, tak by šlo
přikoupit nějaký hardware a přestěhovat na něj z každého staršího stroje
něco. Tím bys stávajícím strojům odlehčil, což by vyrovnalo ztrátu
výkonu za vypnutý HT, ale zároveň nemusel nakupovat hromadu nového hardware.
Mimo to tím
souvisí ještě to, zda se blízké budoucnosti,
neobjeví (pravděpodobně ano) další "nový" podobný bezpečností
problém, který se opět bude týkat této architektury.
Bingo, protoze uplne to samy muze potkat EPYC, potazmo i EPYC2 - a to
budem dvojnasob nastvani, protoze to bude uplne novej HW...
Neni to jednoznacna situace, nejakej ten HW ale uz potrebujem, takze to
potrebujem na nejakou stranu rozlousknout.
Kdyz se k nejistote s EPYCem pridava cena toho HW vc. RAM, tak
nevim-nevim dvojnasob.
Ono to s tim bazarovym EPYCem sotva bude tak horky, myslim, ze ho dlouho
moc nebude - protoze EPYC poradne neni pokryty ani ted, kdyz uz se vi,
ze bude dvojka - myslim, ze dvojky budou lidi dokupovat a jednicek se
jeste zbavovat nebudou.
Otazky teda jsou dve:
1. co se stavajicim HW? - nahradit vsechno novym nemame jak, rozhodne ne
najednou; nahradit vsemu ale CPU za neco vice-jadrovyho ale ano ->
myslim tedy tady je jasny upgrade na ty 2670v2 a zakazani HT => nebo ma
nekdo lepsi napad?
2. co nakupovat jako dalsi HW na nejblizsi pulrok?
My momentálně kupujeme Epyc. Jestli si mám za stejné peníze vybrat mezi
děravým Xeonem s 20 jádry nebo míň děravým Epyem s 32 jádry, tak je to
dost jednoduchý výběr.
Co nakupovat dal neni ted moc relevantni, protoze resime situaci co s
tim, co mame + co s aktualni nutnou potrebou dalsiho HW. Obmenit muzeme
nejaky kus, ale rozhodne ne vsechno, upgradovat vsemu CPU by ale vyjit
mohlo.
/snajpa
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
4:11 p.m.
Jde ti o výkon per-cpu, nebo o celkový výkon? Pokud to
druhé, tak by
šlo přikoupit nějaký hardware a přestěhovat na něj z každého staršího
stroje něco. Tím bys stávajícím strojům odlehčil, což by vyrovnalo
ztrátu výkonu za vypnutý HT, ale zároveň nemusel nakupovat hromadu
nového hardware.
To je varianta, pokud to dosedne, viz niz.
2. co nakupovat jako dalsi HW na nejblizsi pulrok?
My momentálně kupujeme Epyc. Jestli si mám za stejné peníze vybrat
mezi děravým Xeonem s 20 jádry nebo míň děravým Epyem s 32 jádry, tak
je to dost jednoduchý výběr.
11:01 p.m.
2. co nakupovat jako dalsi HW na nejblizsi pulrok?
My momentálně kupujeme Epyc. Jestli si mám za stejné peníze vybrat
mezi děravým Xeonem s 20 jádry nebo míň děravým Epyem s 32 jádry, tak
je to dost jednoduchý výběr.
Muzem utratit za HW + doreseni sitovani celkem 1.5M
cca, aby nam to
vyslo OK - z toho potrebuju odlozit cca 0.5M na sitovani, cili mame tak
1M na vyreseni situace s Intelovskym HT + pokryti nejakych 200 dalsich
novych clenu (+ potrebujeme mit nejakou rotacni nodu v obou lokacich pro
migraci na vpsAdminOS.)
22 Aug
22 Aug
1:40 a.m.
2x16c EPYC, 256G RAM, 4x4T 7k2 + 6x960G SSD (všechno
SATA), necelých
300k včetně DPH (z toho 200k jsou disky a paměti.)
Ono mozna s vpsAdminOS nebude od veci se zacit zamejslet nad jeste
vetsima masinama - 2x 24/32 core + 512/768G RAM + n*2T SSD. To by mohlo
davat asi nejlepsi smysl - dost vykonu pro vsechny, s novym kernelem by
melo byt o hodne min bottlenecku - neni to furt native-SMP-based
microkernel, co by se nam hodil nejlip do kramu, ale myslim, ze uz se to
da uvazovat.
Pak bychom na takovy masine myslim mohli pocitat s jeste vetsi agregaci,
aniz by to nekoho bolelo.
Co myslis?
A ostatni? :)
/snajpa
7:41 a.m.
Ahoj,
napadá mě, zkusit poptat nějakého dealera a poptat cenu těch epyců -
více variant. To slabší železo 2x16 a nabušené 2x32 a různé varianty.
Myslím že na netu potom bude možné najít různé performance benchmarky, a
spočítat si, která varianta vyjde nejlépe co se týče cena/výkon
(samozřejmě více slabších mašin zabere víc místa v racku, to je taky
potřeba započítat).
Do této kalkulace samozřejmě lze zahrnout i tu bazarovou variantu...
Disclaimer: servery neprovozuju a nikdy jsem to nedělal, takže pokud
melu nesmysly, prosím nezabíjejte mě :)
Lukáš
On 8/22/18 3:40 AM, Pavel Snajdr wrote:
2x16c EPYC,
256G RAM, 4x4T 7k2 + 6x960G SSD (všechno SATA), necelých
300k včetně DPH (z toho 200k jsou disky a paměti.)
Ono mozna s vpsAdminOS nebude od veci se zacit zamejslet nad jeste
vetsima masinama - 2x 24/32 core + 512/768G RAM + n*2T SSD. To by
mohlo davat asi nejlepsi smysl - dost vykonu pro vsechny, s novym
kernelem by melo byt o hodne min bottlenecku - neni to furt
native-SMP-based microkernel, co by se nam hodil nejlip do kramu, ale
myslim, ze uz se to da uvazovat.
Pak bychom na takovy masine myslim mohli pocitat s jeste vetsi
agregaci, aniz by to nekoho bolelo.
Co myslis?
A ostatni? :)
/snajpa
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list 
7:54 a.m.
Ahoj,
Mohl bych zkusit poptat známého v Abacusu jestli by byl schopny udelat nejake nabidky
kdyby byl zajem
\MM
Odesláno z iPhonu
22. 8. 2018 v 9:41, Lukáš Němec <lu.nemec(a)gmail.com>om>:
Ahoj,
napadá mě, zkusit poptat nějakého dealera a poptat cenu těch epyců - více variant. To
slabší železo 2x16 a nabušené 2x32 a různé varianty. Myslím že na netu potom bude možné
najít různé performance benchmarky, a spočítat si, která varianta vyjde nejlépe co se týče
cena/výkon (samozřejmě více slabších mašin zabere víc místa v racku, to je taky potřeba
započítat).
Do této kalkulace samozřejmě lze zahrnout i tu bazarovou variantu...
Disclaimer: servery neprovozuju a nikdy jsem to nedělal, takže pokud melu nesmysly,
prosím nezabíjejte mě :)
Lukáš
On 8/22/18 3:40 AM, Pavel Snajdr wrote:
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
2x16c
EPYC, 256G RAM, 4x4T 7k2 + 6x960G SSD (všechno SATA), necelých
300k včetně DPH (z toho 200k jsou disky a paměti.)
Ono mozna s vpsAdminOS nebude od veci se zacit zamejslet nad jeste vetsima masinama - 2x
24/32 core + 512/768G RAM + n*2T SSD. To by mohlo davat asi nejlepsi smysl - dost vykonu
pro vsechny, s novym kernelem by melo byt o hodne min bottlenecku - neni to furt
native-SMP-based microkernel, co by se nam hodil nejlip do kramu, ale myslim, ze uz se to
da uvazovat.
Pak bychom na takovy masine myslim mohli pocitat s jeste vetsi agregaci, aniz by to
nekoho bolelo.
Co myslis?
A ostatni? :)
/snajpa
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
9:55 a.m.
Zdarec,
Abacus jedine po soucastkach a postavime si to sami... Osobne variante
Supermicro teda moc nefandim.
Kdyz novy HW, tak od vendora, ktery reaguje, kdyz se neco deje a kde
vyjdou firmwary vcas...
Jinak @ dotaz vyse - 1 rack, tj. 42U, je cca 3500 CZK mesicne, zdaleka
nejvic teda je energie a konektivita, ta samotna vychlazena skrin na
tolik nevyjde, cili bazarovej HW neni na provoz o moc drazsi (krom
efektivity co se spotreby tyce samotny).
/snajpa
On 2018-08-22 09:54, Miroslav Marcišin wrote:
Ahoj,
Mohl bych zkusit poptat známého v Abacusu jestli by byl schopny udelat
nejake nabidky kdyby byl zajem
\MM
Odesláno z iPhonu
22. 8. 2018 v 9:41, Lukáš Němec <lu.nemec(a)gmail.com>om>:
Ahoj,
napadá mě, zkusit poptat nějakého dealera a poptat cenu těch epyců -
více variant. To slabší železo 2x16 a nabušené 2x32 a různé varianty.
Myslím že na netu potom bude možné najít různé performance benchmarky,
a spočítat si, která varianta vyjde nejlépe co se týče cena/výkon
(samozřejmě více slabších mašin zabere víc místa v racku, to je taky
potřeba započítat).
Do této kalkulace samozřejmě lze zahrnout i tu bazarovou variantu...
Disclaimer: servery neprovozuju a nikdy jsem to nedělal, takže pokud
melu nesmysly, prosím nezabíjejte mě :)
Lukáš
On 8/22/18 3:40 AM, Pavel Snajdr wrote:
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list 2x16c
EPYC, 256G RAM, 4x4T 7k2 + 6x960G SSD (všechno SATA), necelých
300k včetně DPH (z toho 200k jsou disky a paměti.)
Ono mozna s vpsAdminOS nebude od veci se zacit zamejslet nad jeste
vetsima masinama - 2x 24/32 core + 512/768G RAM + n*2T SSD. To by
mohlo davat asi nejlepsi smysl - dost vykonu pro vsechny, s novym
kernelem by melo byt o hodne min bottlenecku - neni to furt
native-SMP-based microkernel, co by se nam hodil nejlip do kramu, ale
myslim, ze uz se to da uvazovat.
Pak bychom na takovy masine myslim mohli pocitat s jeste vetsi
agregaci, aniz by to nekoho bolelo.
Co myslis?
A ostatni? :)
/snajpa
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
11:47 a.m.
On 22.8.2018 03:40, Pavel Snajdr wrote:
Jedna potenciální nevýhoda je, že když takové monstrum vytuhne, tak
hodně lidem nepojede hodně věcí :-)
Jinak teoreticky má velká mašina výhodu v tom, že se může potkat
nadprůměrná zátěž víc VPS naráz a furt to nebude problém. Prakticky
záleží na tom, jak se k tomu postaví kernel a jestli bude dost místa na
sběrnicích.
2x16c EPYC,
256G RAM, 4x4T 7k2 + 6x960G SSD (všechno SATA), necelých
300k včetně DPH (z toho 200k jsou disky a paměti.)
Ono mozna s vpsAdminOS nebude od veci se zacit zamejslet nad jeste
vetsima masinama - 2x 24/32 core + 512/768G RAM + n*2T SSD. To by mohlo
davat asi nejlepsi smysl - dost vykonu pro vsechny, s novym kernelem by
melo byt o hodne min bottlenecku - neni to furt native-SMP-based
microkernel, co by se nam hodil nejlip do kramu, ale myslim, ze uz se to
da uvazovat.
Pak bychom na takovy masine myslim mohli pocitat s jeste vetsi agregaci,
aniz by to nekoho bolelo.
Co myslis?
A ostatni? :)
2:54 p.m.
nejakej kontakt bych mel ale nejni cas to resit muzu to predat snajpovi
kdyby chtel...
Dne st 22. 8. 2018 13:48 uživatel Jirka Bourek <vpsfree-list(a)keroub.cz>
napsal:
On 22.8.2018 03:40, Pavel Snajdr wrote:
Jedna potenciální nevýhoda je, že když takové monstrum vytuhne, tak
hodně lidem nepojede hodně věcí :-)
Jinak teoreticky má velká mašina výhodu v tom, že se může potkat
nadprůměrná zátěž víc VPS naráz a furt to nebude problém. Prakticky
záleží na tom, jak se k tomu postaví kernel a jestli bude dost místa na
sběrnicích.
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
2x16c
EPYC, 256G RAM, 4x4T 7k2 + 6x960G SSD (všechno SATA), necelých
300k včetně DPH (z toho 200k jsou disky a paměti.)
Ono mozna s vpsAdminOS nebude od veci se zacit zamejslet nad jeste
vetsima masinama - 2x 24/32 core + 512/768G RAM + n*2T SSD. To by mohlo
davat asi nejlepsi smysl - dost vykonu pro vsechny, s novym kernelem by
melo byt o hodne min bottlenecku - neni to furt native-SMP-based
microkernel, co by se nam hodil nejlip do kramu, ale myslim, ze uz se to
da uvazovat.
Pak bychom na takovy masine myslim mohli pocitat s jeste vetsi agregaci,
aniz by to nekoho bolelo.
Co myslis?
A ostatni? :)
7:57 p.m.
Osobně intuitivně tíhnu spíš k variantě - rozšiřovat o nové stroje (ač z
bazaru) a starým v první fázi odlehčit. Přijde mi neefektivní vyhazovat
nějaká velká množství CPUček a nahrazovat je jinými starými, i když v
lepší konfiguraci. To už raději koupit hafo dalších starejch mašin a
řešit to po vzoru Googlu z počátku věků. Což by teda vlastně asi bylo
přesně opačný řešení než teď navrhoval Snajpa - tj. daleko menší
koncentrace, ale potencionálně hodně levnej HW.
Š.
Dne 22.8.2018 v 13:47 Jirka Bourek napsal(a):
On 22.8.2018 03:40, Pavel Snajdr wrote:
Jedna potenciální nevýhoda je, že když takové monstrum vytuhne, tak
hodně lidem nepojede hodně věcí :-)
Jinak teoreticky má velká mašina výhodu v tom, že se může potkat
nadprůměrná zátěž víc VPS naráz a furt to nebude problém. Prakticky
záleží na tom, jak se k tomu postaví kernel a jestli bude dost místa
na sběrnicích.
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
2x16c
EPYC, 256G RAM, 4x4T 7k2 + 6x960G SSD (všechno SATA), necelých
300k včetně DPH (z toho 200k jsou disky a paměti.)
Ono mozna s vpsAdminOS nebude od veci se zacit zamejslet nad jeste
vetsima masinama - 2x 24/32 core + 512/768G RAM + n*2T SSD. To by
mohlo davat asi nejlepsi smysl - dost vykonu pro vsechny, s novym
kernelem by melo byt o hodne min bottlenecku - neni to furt
native-SMP-based microkernel, co by se nam hodil nejlip do kramu, ale
myslim, ze uz se to da uvazovat.
Pak bychom na takovy masine myslim mohli pocitat s jeste vetsi
agregaci, aniz by to nekoho bolelo.
Co myslis?
A ostatni? :)
9:13 p.m.
On 2018-08-22 21:57, Stepan Liska wrote:
Osobně intuitivně tíhnu spíš k variantě - rozšiřovat o
nové
stroje (ač z bazaru) a starým v první fázi odlehčit. Přijde mi
neefektivní vyhazovat nějaká velká množství CPUček a nahrazovat
je jinými starými, i když v lepší konfiguraci. To už raději
koupit hafo dalších starejch mašin a řešit to po vzoru Googlu z
počátku věků. Což by teda vlastně asi bylo přesně opačný
řešení než teď navrhoval Snajpa - tj. daleko menší koncentrace,
ale potencionálně hodně levnej HW.
Š.
Na levnym HW jsme zacali - a realne jsme poznali obrovskej rozdil, kdyz
jsme potom po par letech nasadili dvouprocesory v ty dobe se 128G RAM.
Cim vic se rozeviraji nuzky mezi realnym HW konfigem masiny a jednou
poskytovanou virtualni jednotkou, tim vic se da pohodlne bez problemu
agregovat. Agregovat na mensich strojich se da, ale obnasi to migrace -
a bez CRIU se ty migrace nedaji udelat pro kontejner transparentne, cili
varianta levny HW (i kdyz treba s custom dohackovanym remote
managementem), trpi na tyhle problemy.
Ad. dokoupit starsi stroje cely vs. vymenit CPUcka - ono vymenit CPUcka
vsem masinam v Praze a v Brne, co maji v1/v2 za ty v2 desetijadra vyjde
jako jedna cela stara masina. Pri tom poctu masin si teda myslim, ze
vymenit CPUcka vyjde lip v prepoctu na jednu aktualne hostovanou VPSku.
To je cca moje myslenkova cesta kudy jsem se dopracoval k tomu, co tu
nadhazuju - zatim asi jediny potencialne lepsi napad je natlacit se vic
smer novy AMDcka s jeste vetsi agregaci. Je pravda, co rikal Trekker, ze
v pripade vypadku to ovlivni vetsi procento clenu v prepoctu na stroj -
no, ale s 4.8+ kernely uz tomu docela verim a soucasne 4.18/4.19 maji
focus jeste spravneji, teda jeste lepsi kontejnerizace a zvladani
vetsich systemu - myslim, ze ackoliv kernel neni jeste uplne idealne
tam, kde bychom ho chteli, uz je cca prostor o vetsich masinach
premyslet a mozna zkusit jednu-dve nakoupit. Kdyz se to neprokaze jako
hned lepsi varianta, budem pokracovat vetsim scale-outem a casem to
muzem zvazit znova.
Do toho teda je potreba taky zminit ten soucasnej ARMovej vyvoj - mame
rozdelany system s 4x Cortex A72 @ 1.8 GHz a 8 GB ECC DDR4 RAM, je to
myslene misto VPSek na seriozni pouziti, kde se neda sdilet RAM/cache.
To by melo vychazet cca na 800-900/mesic - tak mi kdyztak taky rovnou
reknete, jestli je to blbost a nikdo o to nebudete mit zajem. Podle mne
ten system sviha a vpsFree infrastrukturnim vecem (jako clenska
databaze) by to fakt sluselo. A podobny use-cases bych videl pro
vsechno, kdo ma nejaky citlivejsi data... Necitlivy chroustani ve velkym
je na shared HW fajn, ale citlivy veci by si zaslouzily micro-scale-out,
tj. co microservica, to jeji dedikovany miniHW server.
/snajpa
11:28 p.m.
Pokud to je cenově takto, tak samozřejmě nákup celých starších strojů
smysl nedává.
Směr AMD se mi líbí, ale v tomto scalu už jsem úplně mimo co se týče
jakýchkoliv myslitelných komplikací a musím se spolehnout na vaše
vědomosti. Ale hlasoval bych pro, vždycky jsem pro to pořídit novou a
větší hračku ;-)
ARM si dovedu na spoustu věcí představit a kdybych na něj měl projekt,
tak bych to za tu cenu bral. Nicméně teď na to žádný projekt nemám a
přesun z mých VPSek by zatím nebyl rentabilní, je toho tam moc málo.
Š.
Dne 22.8.2018 v 23:13 Pavel Snajdr napsal(a):
Na levnym HW jsme zacali - a realne jsme poznali obrovskej rozdil,
kdyz jsme potom po par letech nasadili dvouprocesory v ty dobe se 128G
RAM. Cim vic se rozeviraji nuzky mezi realnym HW konfigem masiny a
jednou poskytovanou virtualni jednotkou, tim vic se da pohodlne bez
problemu agregovat. Agregovat na mensich strojich se da, ale obnasi to
migrace - a bez CRIU se ty migrace nedaji udelat pro kontejner
transparentne, cili varianta levny HW (i kdyz treba s custom
dohackovanym remote managementem), trpi na tyhle problemy.
Ad. dokoupit starsi stroje cely vs. vymenit CPUcka - ono vymenit
CPUcka vsem masinam v Praze a v Brne, co maji v1/v2 za ty v2
desetijadra vyjde jako jedna cela stara masina. Pri tom poctu masin si
teda myslim, ze vymenit CPUcka vyjde lip v prepoctu na jednu aktualne
hostovanou VPSku.
To je cca moje myslenkova cesta kudy jsem se dopracoval k tomu, co tu
nadhazuju - zatim asi jediny potencialne lepsi napad je natlacit se
vic smer novy AMDcka s jeste vetsi agregaci. Je pravda, co rikal
Trekker, ze v pripade vypadku to ovlivni vetsi procento clenu v
prepoctu na stroj - no, ale s 4.8+ kernely uz tomu docela verim a
soucasne 4.18/4.19 maji focus jeste spravneji, teda jeste lepsi
kontejnerizace a zvladani vetsich systemu - myslim, ze ackoliv kernel
neni jeste uplne idealne tam, kde bychom ho chteli, uz je cca prostor
o vetsich masinach premyslet a mozna zkusit jednu-dve nakoupit. Kdyz
se to neprokaze jako hned lepsi varianta, budem pokracovat vetsim
scale-outem a casem to muzem zvazit znova.
Do toho teda je potreba taky zminit ten soucasnej ARMovej vyvoj - mame
rozdelany system s 4x Cortex A72 @ 1.8 GHz a 8 GB ECC DDR4 RAM, je to
myslene misto VPSek na seriozni pouziti, kde se neda sdilet RAM/cache.
To by melo vychazet cca na 800-900/mesic - tak mi kdyztak taky rovnou
reknete, jestli je to blbost a nikdo o to nebudete mit zajem. Podle
mne ten system sviha a vpsFree infrastrukturnim vecem (jako clenska
databaze) by to fakt sluselo. A podobny use-cases bych videl pro
vsechno, kdo ma nejaky citlivejsi data... Necitlivy chroustani ve
velkym je na shared HW fajn, ale citlivy veci by si zaslouzily
micro-scale-out, tj. co microservica, to jeji dedikovany miniHW server.
/snajpa
23 Aug
23 Aug
7 a.m.
Ahojte,
za mě je např. ta konfigurace nad ARM nedostatečná např. pro Připravto. Pro
naše použití je výkonnější CPU/ paměti výhodnější a i výkonnější disk. V
tuto chvíli je nejčastějším problémem pro naše VPS čekání na IO u disku jak
na NAS tak i na lokálním disku. Pokud bych však chtěl zvyšovat výkon pro
aplikaci, tak potřebuji určitě více CPU / jádro i výkon na jádro. Už máme v
aplikaci možnost, přesunout něco na jinou VPS, ale ne vždy je to dostatečné
a je potřeba synchronizace.
Pokud má uživatel jiné použití pro VPS, tak může mít ARM význam, ale např.
pro nás ne. Chápu, že pro někoho může být soukromí hodně důležité, ale pro
nás je to pouze jedna z častí a nemáme tak jednoduché použití, aby to
dávalo takový význam.
Zdenek
st 22. 8. 2018 v 23:14 odesílatel Pavel Snajdr <snajpa(a)snajpa.net> napsal:
On 2018-08-22 21:57, Stepan Liska wrote:
Osobně intuitivně tíhnu spíš k variantě -
rozšiřovat o nové
stroje (ač z bazaru) a starým v první fázi odlehčit. Přijde mi
neefektivní vyhazovat nějaká velká množství CPUček a nahrazovat
je jinými starými, i když v lepší konfiguraci. To už raději
koupit hafo dalších starejch mašin a řešit to po vzoru Googlu z
počátku věků. Což by teda vlastně asi bylo přesně opačný
řešení než teď navrhoval Snajpa - tj. daleko menší koncentrace,
ale potencionálně hodně levnej HW.
Š.
Na levnym HW jsme zacali - a realne jsme poznali obrovskej rozdil, kdyz
jsme potom po par letech nasadili dvouprocesory v ty dobe se 128G RAM.
Cim vic se rozeviraji nuzky mezi realnym HW konfigem masiny a jednou
poskytovanou virtualni jednotkou, tim vic se da pohodlne bez problemu
agregovat. Agregovat na mensich strojich se da, ale obnasi to migrace -
a bez CRIU se ty migrace nedaji udelat pro kontejner transparentne, cili
varianta levny HW (i kdyz treba s custom dohackovanym remote
managementem), trpi na tyhle problemy.
Ad. dokoupit starsi stroje cely vs. vymenit CPUcka - ono vymenit CPUcka
vsem masinam v Praze a v Brne, co maji v1/v2 za ty v2 desetijadra vyjde
jako jedna cela stara masina. Pri tom poctu masin si teda myslim, ze
vymenit CPUcka vyjde lip v prepoctu na jednu aktualne hostovanou VPSku.
To je cca moje myslenkova cesta kudy jsem se dopracoval k tomu, co tu
nadhazuju - zatim asi jediny potencialne lepsi napad je natlacit se vic
smer novy AMDcka s jeste vetsi agregaci. Je pravda, co rikal Trekker, ze
v pripade vypadku to ovlivni vetsi procento clenu v prepoctu na stroj -
no, ale s 4.8+ kernely uz tomu docela verim a soucasne 4.18/4.19 maji
focus jeste spravneji, teda jeste lepsi kontejnerizace a zvladani
vetsich systemu - myslim, ze ackoliv kernel neni jeste uplne idealne
tam, kde bychom ho chteli, uz je cca prostor o vetsich masinach
premyslet a mozna zkusit jednu-dve nakoupit. Kdyz se to neprokaze jako
hned lepsi varianta, budem pokracovat vetsim scale-outem a casem to
muzem zvazit znova.
Do toho teda je potreba taky zminit ten soucasnej ARMovej vyvoj - mame
rozdelany system s 4x Cortex A72 @ 1.8 GHz a 8 GB ECC DDR4 RAM, je to
myslene misto VPSek na seriozni pouziti, kde se neda sdilet RAM/cache.
To by melo vychazet cca na 800-900/mesic - tak mi kdyztak taky rovnou
reknete, jestli je to blbost a nikdo o to nebudete mit zajem. Podle mne
ten system sviha a vpsFree infrastrukturnim vecem (jako clenska
databaze) by to fakt sluselo. A podobny use-cases bych videl pro
vsechno, kdo ma nejaky citlivejsi data... Necitlivy chroustani ve velkym
je na shared HW fajn, ale citlivy veci by si zaslouzily micro-scale-out,
tj. co microservica, to jeji dedikovany miniHW server.
/snajpa
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
10:39 a.m.
On 2018-08-23 09:00, zd nex wrote:
Ahojte,
za mě je např. ta konfigurace nad ARM nedostatečná např. pro
Připravto. Pro naše použití je výkonnější CPU/ paměti
výhodnější a i výkonnější disk. V tuto chvíli je
nejčastějším problémem pro naše VPS čekání na IO u disku jak
na NAS tak i na lokálním disku. Pokud bych však chtěl zvyšovat
výkon pro aplikaci, tak potřebuji určitě více CPU / jádro i
výkon na jádro. Už máme v aplikaci možnost, přesunout něco na
jinou VPS, ale ne vždy je to dostatečné a je potřeba
synchronizace.
Pokud má uživatel jiné použití pro VPS, tak může mít ARM
význam, ale např. pro nás ne. Chápu, že pro někoho může být
soukromí hodně důležité, ale pro nás je to pouze jedna z častí
a nemáme tak jednoduché použití, aby to dávalo takový význam.
Zdenek
Ahoj,
no, ja se zeptam, nez pokrocime dal, jestli jsi nekdy system s
Cortex-A72 zkousel, nebo proc myslis, ze je to nedostatecne?
Kolik jader CPU potrebujes pravidelne ve spicce?
(Kam tim mirim: pri jednom 300vkovym modulu jsou vzdycky pocitany dve
jadra, ze budes maximalne pouzivat pravidelne, pri vicero uz je to ted
na vic "modulu". Cim chci rict, ze "je vyhodnejsi" muze bejt jenom
otazka doby, nez Aither dodela granularnejsi accounting CPU casu a pak
muzes dojit na to, ze jsi hresil na tu sdilenost a po spravnosti by sis
mel treba prave spis doplatit. Ale k tomu potrebujem vedet, na kolik
jader se ted spolejhas v souctu ve spicce).
Diky,
/snajpa
30 Aug
30 Aug
5:09 a.m.
Ahoj,
no v tuto chvíli nejde ani tak o špičku (u nás lidi chodí různě), jako
spíše o to, že VPS pokud má vše v RAM, tak CPU až na 2-3 případy moc
potřebný není např. pro Připravto. Jde o to, že naše velké úlohy jsou
zhruba 3 v návrhu nábytku (3d model, zpracování konstrukce a hledání
spojů). Pak je to optimalizace nářezových plánů a ta může jet na více
processorů a pak vizualizace a ta je také na více processů. Avšak může tam
být více uživatelů najednou. Tzn * počet uživatelů. To je co se týče
náročnosti na CPU. Ostatní je téměř bez zatížení. No a pak je tam ta věc a
to je DISK > který dle mého sledování většinou nestíhá, když něco není v
RAM. Můžete si jednoduše vyzkoušet, někdy i načtení pár KB souboru zabere
několik sekund a HTOP zobrazuje process v D stavu. Imho jelikož a prostě
většinou je ten disk přetížen - několikrát bylo vidět z grafů a cpu neví co
má dělat. Bohužel jsme teď začali řešit synchronizaci mezi VPS a tam je již
více vidět to přetížení disků. Předminulý týden jsem to musel úplně
zastavit a nastavit větší rozmezí mezi kopírování abych si sám ne zvýšil
load na 4 jen kopírováním. To už jsem vyřešil a prostě to děláme po mnohem
menších částech s větším rozložením do času a jede to.
Tzn tím bych chtěl říci, že pokud je ten HW slabší, tak se více projeví
tyto slabiny. Pokud bychom všichni rozkládali zatížení do většího času, tak
by to samo sebou bylo skvělé, bohužel ne vždy to jde. Tohle je v
současnosti pohled jak to vidím já. Možná pro běžný web je to ok.
Zdenek
čt 23. 8. 2018 v 12:39 odesílatel Pavel Snajdr <snajpa(a)snajpa.net> napsal:
On 2018-08-23 09:00, zd nex wrote:
Ahojte,
za mě je např. ta konfigurace nad ARM nedostatečná např. pro
Připravto. Pro naše použití je výkonnější CPU/ paměti
výhodnější a i výkonnější disk. V tuto chvíli je
nejčastějším problémem pro naše VPS čekání na IO u disku jak
na NAS tak i na lokálním disku. Pokud bych však chtěl zvyšovat
výkon pro aplikaci, tak potřebuji určitě více CPU / jádro i
výkon na jádro. Už máme v aplikaci možnost, přesunout něco na
jinou VPS, ale ne vždy je to dostatečné a je potřeba
synchronizace.
Pokud má uživatel jiné použití pro VPS, tak může mít ARM
význam, ale např. pro nás ne. Chápu, že pro někoho může být
soukromí hodně důležité, ale pro nás je to pouze jedna z častí
a nemáme tak jednoduché použití, aby to dávalo takový význam.
Zdenek
Ahoj,
no, ja se zeptam, nez pokrocime dal, jestli jsi nekdy system s
Cortex-A72 zkousel, nebo proc myslis, ze je to nedostatecne?
Kolik jader CPU potrebujes pravidelne ve spicce?
(Kam tim mirim: pri jednom 300vkovym modulu jsou vzdycky pocitany dve
jadra, ze budes maximalne pouzivat pravidelne, pri vicero uz je to ted
na vic "modulu". Cim chci rict, ze "je vyhodnejsi" muze bejt jenom
otazka doby, nez Aither dodela granularnejsi accounting CPU casu a pak
muzes dojit na to, ze jsi hresil na tu sdilenost a po spravnosti by sis
mel treba prave spis doplatit. Ale k tomu potrebujem vedet, na kolik
jader se ted spolejhas v souctu ve spicce).
Diky,
/snajpa
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
11:21 p.m.
On 2018-08-30 07:09, zd nex wrote:
Ahoj,
no v tuto chvíli nejde ani tak o špičku (u nás lidi chodí
různě), jako spíše o to, že VPS pokud má vše v RAM, tak CPU až
na 2-3 případy moc potřebný není např. pro Připravto. Jde o to,
že naše velké úlohy jsou zhruba 3 v návrhu nábytku (3d model,
zpracování konstrukce a hledání spojů). Pak je to optimalizace
nářezových plánů a ta může jet na více processorů a pak
vizualizace a ta je také na více processů. Avšak může tam být
více uživatelů najednou. Tzn * počet uživatelů. To je co se
týče náročnosti na CPU. Ostatní je téměř bez zatížení. No a
pak je tam ta věc a to je DISK > který dle mého sledování
většinou nestíhá, když něco není v RAM. Můžete si jednoduše
vyzkoušet, někdy i načtení pár KB souboru zabere několik sekund
a HTOP zobrazuje process v D stavu. Imho jelikož a prostě většinou
je ten disk přetížen - několikrát bylo vidět z grafů a cpu
neví co má dělat. Bohužel jsme teď začali řešit synchronizaci
mezi VPS a tam je již více vidět to přetížení disků.
Předminulý týden jsem to musel úplně zastavit a nastavit větší
rozmezí mezi kopírování abych si sám ne zvýšil load na 4 jen
kopírováním. To už jsem vyřešil a prostě to děláme po mnohem
menších částech s větším rozložením do času a jede to.
Tzn tím bych chtěl říci, že pokud je ten HW slabší, tak se
více projeví tyto slabiny. Pokud bychom všichni rozkládali
zatížení do většího času, tak by to samo sebou bylo skvělé,
bohužel ne vždy to jde. Tohle je v současnosti pohled jak to vidím
já. Možná pro běžný web je to ok.
Zdenek
Takze jsme vlastne u toho, ze to vubec neni o procesoru, ale o IO, pokud
Ti ted neco nestaci.
S pis na podporu prosim, kdyz se to deje a kdyz to resis, ne takhle
mimochodem a pri diskuzi, ktera se tyka hlavne procesoru ;)
Tak bychom s tim taky mohli aj neco udelat ;)
/snajpa
31 Aug
31 Aug
5:26 a.m.
Ano, máš pravdu, na to IO narážím častěji. To však neznamená, že CPU stačí
(všichni víme že nikdy nestačí). Chtěl jsem tím říci, že pokud bude
processor na jedno jádro slabší, což předpokládám, že je. Tak to dobré
není, když v tuto chvíli je jedno jádro o tak 10-30% pomalejší než jádro na
mém starém nt T420. Tzn, nerad bych slabší věci - hlavně to budoucna, kdy
nároky bohužel vždy vzrůstají. To co by bylo zajímavější je právě jak jsem
říkal to AMD. Je pravda, že jsem nezkoušel zmíněný CPU, ale pokud nemá
žádnou reálnou přidanou hodnotu, tak je otázkou co to přidá.
Na druhou stranu je potřeba zmínit, že to se snažíš to inovovat, což je
dobrá zpráva a jsem za to opravdu rád:) Popravdě si uvědomuji to množství
času co tomu dáváte.
pá 31. 8. 2018 v 1:22 odesílatel Pavel Snajdr <snajpa(a)snajpa.net> napsal:
On 2018-08-30 07:09, zd nex wrote:
Ahoj,
no v tuto chvíli nejde ani tak o špičku (u nás lidi chodí
různě), jako spíše o to, že VPS pokud má vše v RAM, tak CPU až
na 2-3 případy moc potřebný není např. pro Připravto. Jde o to,
že naše velké úlohy jsou zhruba 3 v návrhu nábytku (3d model,
zpracování konstrukce a hledání spojů). Pak je to optimalizace
nářezových plánů a ta může jet na více processorů a pak
vizualizace a ta je také na více processů. Avšak může tam být
více uživatelů najednou. Tzn * počet uživatelů. To je co se
týče náročnosti na CPU. Ostatní je téměř bez zatížení. No a
pak je tam ta věc a to je DISK > který dle mého sledování
většinou nestíhá, když něco není v RAM. Můžete si jednoduše
vyzkoušet, někdy i načtení pár KB souboru zabere několik sekund
a HTOP zobrazuje process v D stavu. Imho jelikož a prostě většinou
je ten disk přetížen - několikrát bylo vidět z grafů a cpu
neví co má dělat. Bohužel jsme teď začali řešit synchronizaci
mezi VPS a tam je již více vidět to přetížení disků.
Předminulý týden jsem to musel úplně zastavit a nastavit větší
rozmezí mezi kopírování abych si sám ne zvýšil load na 4 jen
kopírováním. To už jsem vyřešil a prostě to děláme po mnohem
menších částech s větším rozložením do času a jede to.
Tzn tím bych chtěl říci, že pokud je ten HW slabší, tak se
více projeví tyto slabiny. Pokud bychom všichni rozkládali
zatížení do většího času, tak by to samo sebou bylo skvělé,
bohužel ne vždy to jde. Tohle je v současnosti pohled jak to vidím
já. Možná pro běžný web je to ok.
Zdenek
Takze jsme vlastne u toho, ze to vubec neni o procesoru, ale o IO, pokud
Ti ted neco nestaci.
S pis na podporu prosim, kdyz se to deje a kdyz to resis, ne takhle
mimochodem a pri diskuzi, ktera se tyka hlavne procesoru ;)
Tak bychom s tim taky mohli aj neco udelat ;)
/snajpa
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
5:32 a.m.
Jen takova poznamka - proc uz nejsi na vlastnim HW, kdyz vykon VPSky
nestaci?
To Ti nevadi potencialne nespokojeni zakaznici?
Ceny pronajateho HW uz nejsou tak likvidacni, jako pred lety (napr,
Hetzner - od 20e / mesic, OVH ~1.000Kc/mes)
Dne 31.8.2018 v 7:26 zd nex napsal(a):
Ano, máš pravdu, na to IO narážím častěji. To však
neznamená, že CPU
stačí (všichni víme že nikdy nestačí). Chtěl jsem tím říci, že pokud
bude processor na jedno jádro slabší, což předpokládám, že je. Tak to
dobré není, když v tuto chvíli je jedno jádro o tak 10-30% pomalejší než
jádro na mém starém nt T420. Tzn, nerad bych slabší věci - hlavně to
budoucna, kdy nároky bohužel vždy vzrůstají. To co by bylo zajímavější
je právě jak jsem říkal to AMD. Je pravda, že jsem nezkoušel zmíněný
CPU, ale pokud nemá žádnou reálnou přidanou hodnotu, tak je otázkou co
to přidá.
Na druhou stranu je potřeba zmínit, že to se snažíš to inovovat, což je
dobrá zpráva a jsem za to opravdu rád:) Popravdě si uvědomuji to
množství času co tomu dáváte.
pá 31. 8. 2018 v 1:22 odesílatel Pavel Snajdr <snajpa(a)snajpa.net
<mailto:snajpa@snajpa.net>> napsal:
On 2018-08-30 07:09, zd nex wrote:
Ahoj,
no v tuto chvíli nejde ani tak o špičku (u nás lidi chodí
různě), jako spíše o to, že VPS pokud má vše v RAM, tak CPU až
na 2-3 případy moc potřebný není např. pro Připravto. Jde o to,
že naše velké úlohy jsou zhruba 3 v návrhu nábytku (3d model,
zpracování konstrukce a hledání spojů). Pak je to optimalizace
nářezových plánů a ta může jet na více processorů a pak
vizualizace a ta je také na více processů. Avšak může tam být
více uživatelů najednou. Tzn * počet uživatelů. To je co se
týče náročnosti na CPU. Ostatní je téměř bez zatížení. No a
pak je tam ta věc a to je DISK > který dle mého sledování
většinou nestíhá, když něco není v RAM. Můžete si jednoduše
vyzkoušet, někdy i načtení pár KB souboru zabere několik sekund
a HTOP zobrazuje process v D stavu. Imho jelikož a prostě většinou
je ten disk přetížen - několikrát bylo vidět z grafů a cpu
neví co má dělat. Bohužel jsme teď začali řešit synchronizaci
mezi VPS a tam je již více vidět to přetížení disků.
Předminulý týden jsem to musel úplně zastavit a nastavit větší
rozmezí mezi kopírování abych si sám ne zvýšil load na 4 jen
kopírováním. To už jsem vyřešil a prostě to děláme po mnohem
menších částech s větším rozložením do času a jede to.
Tzn tím bych chtěl říci, že pokud je ten HW slabší, tak se
více projeví tyto slabiny. Pokud bychom všichni rozkládali
zatížení do většího času, tak by to samo sebou bylo skvělé,
bohužel ne vždy to jde. Tohle je v současnosti pohled jak to vidím
já. Možná pro běžný web je to ok.
Zdenek
Takze jsme vlastne u toho, ze to vubec neni o procesoru, ale o IO,
pokud
Ti ted neco nestaci.
S pis na podporu prosim, kdyz se to deje a kdyz to resis, ne takhle
mimochodem a pri diskuzi, ktera se tyka hlavne procesoru ;)
Tak bychom s tim taky mohli aj neco udelat ;)
2304
days inactive
2314
days old
community-list@lists.vpsfree.cz
24 comments
9 participants
participants (9)
-
Jirka Bourek -
Ján Stanček -
Lukáš Němec -
Miroslav Marcišin -
Ondrej Beranek -
Pavel Snajdr -
Stepan Liska -
Vaclav Dusek -
zd nex