[bogdan]

lenne egy kerdesem, mert nem egeszen ertem. a hwsw tegnap hozta le a hirt, hogy a Dell bejelenti a Dempsey architekturara epulo szervereit p4 Xeon alapokon:
https://www.hwsw.hu/...31454&count28=1

tehat juniusban lehet megvenni (mar ha jol ertelmeztem) eloszor a Dempsey architekturara, es a 65 nanos DC DP Xeonokra epulo rendszert. es ugyancsak most juniusra varja mindenki a DP Woodcrestet? tehat ennek a termeknek nehany het a termekideje? (az vilagos, hogy egy-az-egyben belemennek majd a woodcrestek, es azt keszitik elo.)

[Vajonész]

Idézet: bogdan - Dátum: 2006. jún. 8., csütörtök - 11:31

lenne egy kerdesem, mert nem egeszen ertem. a hwsw tegnap hozta le a hirt, hogy a Dell bejelenti a Dempsey architekturara epulo szervereit p4 Xeon alapokon:
https://www.hwsw.hu/...31454&count28=1

tehat juniusban lehet megvenni (mar ha jol ertelmeztem) eloszor a Dempsey architekturara, es a 65 nanos DC DP Xeonokra epulo rendszert. es ugyancsak most juniusra varja mindenki a DP Woodcrestet? tehat ennek a termeknek nehany het a termekideje? (az vilagos, hogy egy-az-egyben belemennek majd a woodcrestek, es azt keszitik elo.)

Errõl már úgy emlékszem volt szó. Kevés ideje lesz a Dempsey-nek.
Bár végül is az intel úgy alakítja majd az árakat, hogy legyen vevõ a Dempseyre is.
Az hûtés+táp ami jó a Dempsey-re biztos jó lesz Woodcrestnek is

[SFIJ]

Idézet: Vajonész - Dátum: 2006. jún. 8., csütörtök - 9:31

Ti csak a grafikonokat nézitek vagy olvastok is?
A 9-dik oldalon világosan le van írva mitõl van, hogy a mysql linuxon miért mitõl lassul.

Idézet: anand

So what is going on here? After talking to our MySQL guru (P. Zaitsev), it turns out that in some circumstances, MySQL might cause trouble for the Linux mutex (mutual exclusion) implementation: "mutex ping-pong". The mutex implementation makes sure that two threads cannot access data in the main memory that is locked by another thread.

Innen is latszik, hogy milyen piszok nehez MT programot irni, aminek tobb CPu-core-re is skalazodini kell. Errol Laaa-Yosh hozott egy cikket par honapja.

Szerkesztette: SFIJ 2006. 06. 08. 15:02 -kor

[special]

Idézet: Vajonész - Dátum: 2006. jún. 8., csütörtök - 10:31

Ti csak a grafikonokat nézitek vagy olvastok is?
A 9-dik oldalon világosan le van írva mitõl van, hogy a mysql linuxon miért mitõl lassul.

ééés? hardvert teszteltek, nem szoftvert, ergo kit érdekel a szar szoftver szar gondjai. most jól megmérték a semmit. különben meg ha te tényleg olyan alaposan elolvastad, feltûnhetett volna, egyáltalán nem tudják, mitõl van. valami baj van a mysql-lel, eddig jutottak. ez az egyész egy nagy gagyizás. ebbõl a tesztbõl az derült ki, hogy anand nem tud tesztelni, az architektúrákról semmi.

[SFIJ]

Idézet: special - Dátum: 2006. jún. 8., csütörtök - 15:04

ééés? hardvert teszteltek, nem szoftvert, ergo kit érdekel a szar szoftver szar gondjai.

special. bocs de ez szint alatti. ha a teljesitmeny-csokkenest egy jol definialhato es ismert sw problema okozza, akkor azt nem lehet egy legyintessel elintezni. lasd elozo postom.

Idézet: special - Dátum: 2006. jún. 8., csütörtök - 15:04

különben meg ha te tényleg olyan alaposan elolvastad, feltûnhetett volna, egyáltalán nem tudják, mitõl van.

Idézet: anand

So what is going on here? After talking to our MySQL guru (P. Zaitsev), it turns out that in some circumstances, MySQL might cause trouble for the Linux mutex (mutual exclusion) implementation: "mutex ping-pong". The mutex implementation makes sure that two threads cannot access data in the main memory that is locked by another thread.

Szerkesztette: SFIJ 2006. 06. 08. 15:08 -kor

[special]

Idézet: SFIJ - Dátum: 2006. jún. 8., csütörtök - 16:06

special. bocs de ez szint alatti. ha a teljesitmeny-csokkenest egy jol definialhato es ismert sw problema okozza, akkor azt nem lehet egy legyintessel elintezni. lasd elozo postom.

Idézet: anand

So what is going on here? After talking to our MySQL guru (P. Zaitsev), it turns out that in some circumstances, MySQL might cause trouble for the Linux mutex (mutual exclusion) implementation: "mutex ping-pong". The mutex implementation makes sure that two threads cannot access data in the main memory that is locked by another thread.

szerintem is szint alatti. jól definiálható.

és kit érdekel a mysql vagy a linux problémája? most mit tudtunk meg a (négymagos) hardverrõl a mysql teszttel? semmit, ugyanis gond van a szoftverrel. így még a kétmagos eredmények sem validak, ugyanis miért higgye el bárki is, hogy ott rendben van a skálázódás. ha nem skálázódik a mysql, akkor ki használja 2xDC kiépítésben? senki. mit ér a teszt? semmit. a db2 állítólag jól skálázódik. kaptunk db2 teszteket? nem.

vagy a LAMP teszt csak egy processorra volt állítva? miért?

az angolt hogy bírod egyébként? might


az még tetszett egyébként, hogy a solaris milyen jól beskálázódott négy maggal a kétmagos linuxos eredmény alá.

[Jakuza]

[quote name='special' date='2006. jún. 8., csütörtök - 16:30'] [/QUOTE]
szerintem is szint alatti. jól definiálható.

és kit érdekel a mysql vagy a linux problémája? most mit tudtunk meg a (négymagos) hardverrõl a mysql teszttel? semmit, ugyanis gond van a szoftverrel. így még a kétmagos eredmények sem validak, ugyanis miért higgye el bárki is, hogy ott rendben van a skálázódás. ha nem skálázódik a mysql, akkor ki használja 2xDC kiépítésben? senki. mit ér a teszt? semmit. a db2 állítólag jól skálázódik. kaptunk db2 teszteket? nem.

vagy a LAMP teszt csak egy processorra volt állítva? miért?

az angolt hogy bírod egyébként? might


az még tetszett egyébként, hogy a solaris milyen jól beskálázódott négy maggal a kétmagos linuxos eredmény alá. [/quote]
Erre mar irtam egy jo peldat. (a'la sportolok)
A meres csak akkor hiteles, ha mindket rendszert kulso negativ iranyban nem befolyasolo tenyezok nelkul merik.
Addig hiteltelen az egesz.

[Vajonész]

Idézet: special - Dátum: 2006. jún. 8., csütörtök - 14:04

ééés? hardvert teszteltek, nem szoftvert, ergo kit érdekel a szar szoftver szar gondjai. most jól megmérték a semmit. különben meg ha te tényleg olyan alaposan elolvastad, feltûnhetett volna, egyáltalán nem tudják, mitõl van. valami baj van a mysql-lel, eddig jutottak. ez az egyész egy nagy gagyizás. ebbõl a tesztbõl az derült ki, hogy anand nem tud tesztelni, az architektúrákról semmi.

Hardvert teszteltek, de szoftvereken keresztül, az ilyen jellegû tesztek mindig: hw+os+app együttes tesztje, amelybõl mind a 3 egyaránt befolyásolja a tesztet.
Nem semmit mértek aki mysql használ linuxon annak igen hasznos információ.
Egyébként meg általánosan a szoftver optimalizációban nem lehet felkészülni úgy optimalizálni, hogy a jelenlegi és jövõbeli hardvereken egyarán optimálisan fusson.
Adatbáziskezelõknél pl. a microsoftnak is gondja volt a ht-vel.
Ebbõl a tesztbõl azt következtetni, hogy nem tudnak tesztelni az kicsit meredek.

[Vajonész]

[quote name='special' date='2006. jún. 8., csütörtök - 14:30'] [/QUOTE]
szerintem is szint alatti. jól definiálható.

és kit érdekel a mysql vagy a linux problémája? most mit tudtunk meg a (négymagos) hardverrõl a mysql teszttel? semmit, ugyanis gond van a szoftverrel. így még a kétmagos eredmények sem validak, ugyanis miért higgye el bárki is, hogy ott rendben van a skálázódás. ha nem skálázódik a mysql, akkor ki használja 2xDC kiépítésben? senki. mit ér a teszt? semmit. a db2 állítólag jól skálázódik. kaptunk db2 teszteket? nem.

vagy a LAMP teszt csak egy processorra volt állítva? miért?

az angolt hogy bírod egyébként? might


az még tetszett egyébként, hogy a solaris milyen jól beskálázódott négy maggal a kétmagos linuxos eredmény alá. [/quote]
Elég sok mindent megtudunk pl. hogy most nem érdemes 2xDC hw-re mysql-linuxot felrakni.
A mysql egyébként sem arról nevezetes, hogy mp környezetre van optimalizálva.
Pontos képet csak akkor kapunk, ha megjelenek a szoftverek optimalizált verziói.
Egy db2 kicsit komolyabb összeg, mint a mysql és PostGreSQL

[hvuk]

Idézet: Vajonész - Dátum: 2006. jún. 9., péntek - 7:50

Ebbõl a tesztbõl azt következtetni, hogy nem tudnak tesztelni az kicsit meredek.

Hagyd rá specialra, neki az a véleménye, hogy se Johan, se Hannibal nem ért semmihez és az egyetlen orákulum Paul.

[bogdan]

Idézet: Vajonész - Dátum: 2006. jún. 9., péntek - 6:56

A mysql egyébként sem arról nevezetes, hogy mp környezetre van optimalizálva.

eleg furcsa, amit mondasz. a sikerstoryjaik kozott jopar nem csak hogy mp, de jopar bohom nagy grid is szerepel. vagy az mas lenne?

[Vajonész]

Idézet: bogdan - Dátum: 2006. jún. 9., péntek - 8:06

eleg furcsa, amit mondasz. a sikerstoryjaik kozott jopar nem csak hogy mp, de jopar bohom nagy grid is szerepel. vagy az mas lenne?

a grid/cluster kicsit más, milyen smp/numa van?

[Vajonész]

Elérhetõk az új Unisys ES7000 szerverek(xeon 7041) egész biztató lineáris skálázódás:
8P(16C): 347 854 tpmC
16P(32C):749 839 tpmC

A woodcrest alapú mp veszélyes lesz.

összevetésül a nemrég elérhetõ:
HP Superdome, 64P(64C) Itanium2 csak: 1 231 433 tpmC
míg az IBM p5 570 legfrissebbje, 8P(16C) POWER5+ : 1 025 170 tpmC

[bogdan]

vicces adatok vannak benne:
Availability Date: 05/05/06

e szerint mar tobb, mint egy honapja kaphato..

(persze ertheto, hiszen februar 22-en kuldtek be oket!)

szerk: bocsanat, azt hittem woodcrestekrol van szo. de latom, hogy nem.. raadasul meg csak nem is 65 nanos.

Szerkesztette: bogdan 2006. 06. 09. 10:44 -kor

[bogdan]

hm.. meg egy dolog (sot ketto) lepett meg olvasgatva ezeket az adatokat!
az IBM ugyancsak 16 utas szervereben a 750k helyett 500k-s eredmenyt ert el.. http://www.tpc.org/tpcc/results/tpcc_resul...sp?id=105112201
(ami mar kevesbe fenyes szvsz..)

a masik, hogy mi ez a 16 utas NEM CLUSTER Unisys szerver? (nem csak az IBM gyart 4 processzorosnal nagyobb Xeon gepet?)

Szerkesztette: bogdan 2006. 06. 09. 10:45 -kor

[Vajonész]

Idézet: bogdan - Dátum: 2006. jún. 9., péntek - 9:42

hm.. meg egy dolog (sot ketto) lepett meg olvasgatva ezeket az adatokat!
az IBM ugyancsak 16 utas szervereben a 750k helyett 500k-s eredmenyt ert el.. http://www.tpc.org/tpcc/results/tpcc_resul...sp?id=105112201
(ami mar kevesbe fenyes szvsz..)

a masik, hogy mi ez a 16 utas NEM CLUSTER Unisys szerver? (nem csak az IBM gyart 4 processzorosnal nagyobb Xeon gepet?)

Ebben csak 7040-esek vannak és csak fele annyi memória(de ez nem von le semmit az Unisys eredményébõl).
Nem cluster és nem az idén kezdte, csak sokkal kisebb a hangja, mint az IBM-é

[bogdan]

hogy nem az iden kezdte, azt tudom. ami inkabb erdekelne, hogy akkor ez kinek, milyen chipjere epulhet? az IBM-rol tudjuk, hogy az mi, de errol???

[SFIJ]

[quote name='special' date='2006. jún. 8., csütörtök - 15:30']
és kit érdekel a mysql vagy a linux problémája?
[/quote] elég sokakat, sztenderd infrastruktúrális elem. amikor ma egy tartalomszolgáltatónál tárhelyet veszel, pár dolgot alapból kapsz: php, mysql. milliók használják, kvázi egy olyan commonplace szofrtól beszélhetünk, mint pl az msword...
[quote name='special' date='2006. jún. 8., csütörtök - 15:30']
most mit tudtunk meg a (négymagos) hardverrõl a mysql teszttel? semmit, ugyanis gond van a szoftverrel.[/quote] nincs azzal semmi baj. solaris alatt szépen viselkedik. ellenben itt az ideje, hogy torwaldsék tökére lépjünk
[quote name='special' date='2006. jún. 8., csütörtök - 15:30']
így még a kétmagos eredmények sem validak, ugyanis miért higgye el bárki is, hogy ott rendben van a skálázódás. ha nem skálázódik a mysql, akkor ki használja 2xDC kiépítésben? senki.[quote]az angolt hogy bírod egyébként? might

[quote name='special' date='2006. jún. 8., csütörtök - 15:30']
az még tetszett egyébként, hogy a solaris milyen jól beskálázódott négy maggal a kétmagos linuxos eredmény alá.[/QUOTE] nájgra alatt...

Szerkesztette: SFIJ 2006. 06. 09. 11:51 -kor

[special]

sfij, nem tudom már jobban szájbarágósan mondani, minthogy ez a teszt nem errõl szólt, vagy legalábbis kellett volna, hogy szóljon. ha ebbe az issue-ba beleütköztek, akkor arról írhattak volna egy külön anyagot. a hardverrõl viszont vajmi keveset mondott. a solaris alatt az opteron négy maggal rossabb teljesítmény adott, mint két maggal linux alatt. kisebb szoftverfinomhangolási probléma. szépen viselkedett, igen, valamennyire skálázódott na, ennyit a mysql részrõl.

érdemes beleolvasgatni a kommentekbe egyébként. a teszt nem éri meg, hogy utánabogarásszunk, de láthatóan ezer sebbõl vérzik, normális dokumentálva sincs. az msi opteron lap egybankos, azaz lõtted a numa elõnyének, 6.4 GB/s-en lógott 4 mag, ebbõl 2 még távolabb is.

a woodcrest/bensley gépet 4x1GB FB-DIMM-mel populálták, azaz valószínûleg csatornánként 1-gyel, amellyel a potenciáljának talán 60-70 %-t hozza (az FBD alrendszer minél mélyebb, annál jobb, ha magas a load).

tehát sikerült két sánta lovat részeg zsokékkal megfuttatni, majd véleményt alkotni a tenyészetekrõl.

[Ytse]

Idézet

Mint azt már egy ideje tudjuk, az Intel napokon és heteken belül a teljes frontvonalon (a notebookoktól a szerverekig) ellentámadást indít ellenfelei, elsõsorban az AMD ellen. Az elmúlt évek során a világ legnagyobb chipgyártója teljesen átalakította terméktervét, ennek eredményeként törlésre kerültek korábbi, zsákutcába jutott projektek (pl. Tejas), amelyek a jelenleg kapható Pentium 4 és D mikroarchitektúrájára épültek volna, és fejlesztéseinek új irányt jelölt ki, hogy versenyképes termékeket tudjon a piacra bocsátani.

https://www.hwsw.hu/...kid=999&oldal=1