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
2018-08-21 11:53 GMT+02:00 Pavel Snajdr <snajpa@snajpa.net>:
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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
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 :-)
On 2018-08-21 13:20, Jirka Bourek wrote:
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 :-)
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
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
On 21.8.2018 14:20, Pavel Snajdr wrote:
On 2018-08-21 13:20, Jirka Bourek wrote:
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 :-)
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.)
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@keroub.cz> napsal(a):
On 21.8.2018 14:20, Pavel Snajdr wrote:
On 2018-08-21 13:20, Jirka Bourek wrote:
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 :-)
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.)
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
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
On 21.8.2018 17:45, Pavel Snajdr wrote:
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?
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.
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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
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.
Mel bys pls nejakou cenovou nabidku nebo aspon hruby prepis, co muzes posharovat? Kolik tomu davate RAMky a na kolik to vyjde cely? 20 core Ivy Bridge + 256G RAM + 14x 1T 7k2 + 2x 400G SSD (vsechno SAS2) vyjde na skoro 150k CZK, coz je za hubicku - a kdyz odpocitam ty disky a hodime si tam svoje (minimalne SSDcka), bude to jeste niz. Tak bych to chtel porovnat s necim podobnym, jestli muzem :) 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.) /snajpa
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.
Mel bys pls nejakou cenovou nabidku nebo aspon hruby prepis, co muzes posharovat? Kolik tomu davate RAMky a na kolik to vyjde cely?
20 core Ivy Bridge + 256G RAM + 14x 1T 7k2 + 2x 400G SSD (vsechno SAS2) vyjde na skoro 150k CZK, coz je za hubicku - a kdyz odpocitam ty disky a hodime si tam svoje (minimalne SSDcka), bude to jeste niz.
Tak bych to chtel porovnat s necim podobnym, jestli muzem :)
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.)
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.)
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
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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
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@gmail.com>:
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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
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@gmail.com>:
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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
On 22.8.2018 03:40, 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? :)
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.
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@keroub.cz> napsal:
On 22.8.2018 03:40, 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? :)
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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
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:
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? :)
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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
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
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
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@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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
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
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@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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
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
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@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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
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@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 ;)
participants (9)
-
Jirka Bourek -
Ján Stanček -
Lukáš Němec -
Miroslav Marcišin -
Ondrej Beranek -
Pavel Snajdr -
Stepan Liska -
Vaclav Dusek -
zd nex