Fok claimt 6GB bij Xeon server

[Verwijderd]

Hoi

Op Fok las ik het bericht dat zij een Xeon server met 6GB geheugen besteld hebben. Specs:

- Dual Xeon 3.06Ghz / 1Mb, 800Mhz FSB
- 6Gb DDR2 (6x 1Gb)

Wat ik mij afvraag:

1. 2GB is de geheugenlimiet van 32-bits processors. Met PAE kan maximaal 4GB geadresseerd worden (maximaal 2GB per proces, though). Klopt?

2. 3.06GHz betekent 533MHz FSB, 3.0GHz is juist 800MHz. Klopt?

Als 1 klopt, hoe kunnen zij dan 6GB geheugen hebben? Een 3.06GHz Xeon zal wel geen Nocona met EM64T zijn, dus zou het een 32-bits processor zijn, die kan door middel van PAE maximaal aan geheugen 4GB adresseren. Zit er waarheid in mijn denkwijze?

[Maverick]

euhm wellicht dat het dual xeon er iets mee te maken heeft?

[holoX]

Mja heb 't ook gelezen. Zowieso beetje overkill. En in de gewone webservers duwen ze IDE harddisks...besteed dan wat meer geld aan fatsoenlijke schijven ipv IDE....

maja..fok

[Verwijderd]

Maverick schreef op donderdag 10 februari 2005 @ 01:19:
euhm wellicht dat het dual xeon er iets mee te maken heeft?

Dus 32-bits procs kunnen 2GB (of 4GB PAE) adresseren per processor? Dus een 8-way Xeon server kan maximaal 16GB (32GB PAE) adresseren?

Dat is dan nieuw voor mij.

[Verwijderd]

]-[Skinlab]-[ schreef op donderdag 10 februari 2005 @ 01:20:
Mja heb 't ook gelezen. Zowieso beetje overkill. En in de gewone webservers duwen ze IDE harddisks...besteed dan wat meer geld aan fatsoenlijke schijven ipv IDE....

maja..fok

SATA is het, en SATA hoeft echt niet zoveel onder te doen dan SCSI hoor (WD Raptor b.v.). Het is de databaseserver die het zwaarst belast zal worden, want nu hebben ze wel 8 webservers ofzo. Zoveel geheugen gebruikt een webserver ook niet; een databaseserver valt bijna niet te load balancen dus daar is een sloot geheugen wel welkom.

Ik had zeker voor de databaseserver een Dual Opteron 250 met minstens 8GB geheugen icm FreeBSD 5.3 AMD64 gekozen.

[ Voor 9% gewijzigd door Verwijderd op 10-02-2005 01:23 ]

[Maverick]

Verwijderd schreef op donderdag 10 februari 2005 @ 01:21:
[...]

Dus 32-bits procs kunnen 2GB (of 4GB PAE) adresseren per processor? Dus een 8-way Xeon server kan maximaal 16GB (32GB PAE) adresseren?

Dat is dan nieuw voor mij.

geen wetmatigheid hoor, misschien zit ik fout, heb er namelijk geen verstand van, maar lijkt mij meer dan logisch, ieder dual bordje dat ik tot nu toe zag had een setje geheugenbankjes voor iedere processor op zich.

[Pascal Saul]

Kijk hier eens voor de databaseserver en hier voor de webserver?

Het is maar een gok, maar kleine kans dat ik ernaast zit

[ Voor 49% gewijzigd door Pascal Saul op 10-02-2005 01:29 ]

[Verwijderd]

Pascal Saul schreef op donderdag 10 februari 2005 @ 01:25:
Kijk hier eens?

Dus wel Nocona's, maar wel 3.0GHz en niet 3.06GHz. Nocona is namelijk altijd 800MHz FSB (en later 1066MHz?).

Maar de procs hebben dus EM64T. Dan heb ik niets gezegd, afgezien van de fout in de nieuwspost van Fok dan.

[ Voor 3% gewijzigd door Verwijderd op 10-02-2005 01:28 ]

[Verwijderd]

Er gaat in dergelijke bordjes voor Xeon DP 3,06 Prestonia B wel meer dan 6GB:
http://www.intel.com/desi...oards/se7320sp2/index.htm (8GB)
http://www.intel.com/desi...oards/se7525gp2/index.htm (8GB)
http://www.intel.com/desi...oards/se7520bd2/index.htm (12GB)
http://www.intel.com/desi...oards/se7520af2/index.htm (16GB)
http://www.intel.com/desi...oards/se7520jr2/index.htm (24GB)
http://www.intel.com/desi...oards/se7320vp2/index.htm (24GB)

Natuurlijk zie je met DOS 2.1 maar 640KB etc, maar dat zijn beperkingen van het OS en je denkt toch echt niet dat ze een bord nemen met 6GB om hem dan vervolgens te cappen (Ze gaan er iig RedHat Linux 3ES op zetten)

Maar om in je denktrend mee te gaan en alleen binnen het Windows platform te kijken:

Met PAE kan maximaal 4GB geadresseerd worden (maximaal 2GB per proces, though). Klopt?

Het steekt iets anders in elkaar:

Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition, provide applications with a flat 32-bit virtual address space that can describe up to 4 gigabytes (GB) of virtual memory. The address space is usually split so that 2 GB of virtual address space is directly accessible to the applications and the other 2 GB is only accessible to the Windows executive software (also known as the kernel). Because of this 2 GB virtual memory limit, applications that are memory intensive and that manage their memory directly through their own caching methods, such as database management systems (DBMS), can experience reduced performance.

4GT makes more of the computer’s virtual memory available to applications by making less virtual memory available to the operating system. By enabling 4GT, applications are able to access 3 GB of virtual memory instead of the 2 GB normally allocated for user mode processes. This is a 50 percent increase in virtual memory, allowing more data to be cached and potentially significantly increasing performance.
Bron: http://www.microsoft.com/...n-us/w2k3tr_4gt_intro.asp

[ Voor 55% gewijzigd door Verwijderd op 10-02-2005 03:27 ]

[Verwijderd]

Maar voor de duidelijkheid: kan een modern OS met 32-bits processors nu wel of niet meer dan 2/4GB adresseren? Zo ja, wat is die hele 2GB boundary dan? Toch geen software-limitatie? Dat is nu juist het grote voordeel van 64-bit waarmee de Opteron wordt aangeprijst: meer dan 4GB geheugen adresseren. Heb ik iets gemist?

[Verwijderd]

Het nadeel is ook dat er een vertaalslag is (virtual adressing) en dat er met PAE een maximum is van 16GB fysiek geheugen.

Even with PAE enabled, the underlying architecture of the system is still based on 32-bit linear addresses. This effectively retains the 2 GB of application space and the 2 GB of kernel mode space because only 4 GB of addresses are available. However, multiple processes can immediately benefit from the increased RAM because they are less likely to encounter physical memory restrictions and begin paging. Additionally, applications can be modified to use the AWE API to allocate memory outside of the applications process space, bypassing the 2-GB limit for applications.

With PAE enabled, the operating system moves from a two-level linear address translation to a three-level address translation. The extra layer of translation is what provides access to physical memory beyond 4 GB. Instead of a linear address being split into three separate fields for indexing into memory tables, it is split into four separate fields; a 2-bit field, two 9-bit fields, and a 12-bit field that corresponds to the page size implemented by Intel Architecture (4 KB).

During a context switch the CR3 register is set by the operating system to point to a Page directory pointer index that is 2-bits wide. The first two bits are used as an index into this table, with the resulting value pointing to a Page directory. The first 9-bit field is then used to index into the Page directory. The indexed value then points to a Page table. The second 9-bit field is an index into the Page table. This value points to the actual page in memory where the desired byte is located. Finding this byte is a simple matter of using the remaining twelve bits of data to index into the page.

Zie ook: http://www.microsoft.com/.../en-us/w2k3tr_4gt_how.asp

[ Voor 80% gewijzigd door Verwijderd op 10-02-2005 02:00 ]

[Verwijderd]

Verwijderd schreef op donderdag 10 februari 2005 @ 01:29:Het steekt iets anders in elkaar:
[...]

Ik kan uit dat verhaal enkel opmaken hoe Windows de PAE-enabled 4GB ruimte verdeelt, niet dat er meer dan 4GB geadresseerd kan worden.

[Verwijderd]

Verwijderd schreef op donderdag 10 februari 2005 @ 01:40:
[...]

Ik kan uit dat verhaal enkel opmaken hoe Windows de PAE-enabled 4GB ruimte verdeelt, niet dat er meer dan 4GB geadresseerd kan worden.

Misschien is deze link dan wat duidelijker voor je: http://support.microsoft....aspx?scid=kb;en-us;283037

16GB totaal adreseerbaar met /PAE
3 GB per userproces met /3GB
1 GB kernelspace met /3GB

4GB totaal adresseerbaar zonder /PAE
2GB per userproces zonder /3GB
2GB kernelspace zonder /3GB

[BalusC]

Maverick schreef op donderdag 10 februari 2005 @ 01:23:
geen wetmatigheid hoor, misschien zit ik fout, heb er namelijk geen verstand van, maar lijkt mij meer dan logisch, ieder dual bordje dat ik tot nu toe zag had een setje geheugenbankjes voor iedere processor op zich.

Je haalt de Xeon en de Opteron ernstig door elkaar heen De Xeon's gebruiken een gedeelde FSB en het geheugencontroller zit nog steeds in de Northbridge, in tegenstelling tot de Opteron.

[TGEN]

Verwijderd schreef op donderdag 10 februari 2005 @ 01:35:
Maar voor de duidelijkheid: kan een modern OS met 32-bits processors nu wel of niet meer dan 2/4GB adresseren? Zo ja, wat is die hele 2GB boundary dan? Toch geen software-limitatie? Dat is nu juist het grote voordeel van 64-bit waarmee de Opteron wordt aangeprijst: meer dan 4GB geheugen adresseren. Heb ik iets gemist?

Elke 386 kan tot 4GB aan fysiek geheugen adresseren. Het zit 'm alleen in dat de address space 32 bits groot is, maar dat OS'en naast t fysieke geheugen ook virtueel geheugen willen aanspreken, bijvoorbeeld voor IO memory maps, paging, etc. Als je je hele address space al aan fysiek geheugen 'verspilt', heb je geen ruimte meer over voor je virtuele bende. Daarvoor is er PSE-36, die de address space naar 36bits uitbreid (maar de fysieke addressbus is nog steeds 32bits breed, dus nog steeds 4GB max). Helaas wordt dat niet al te vaak gebruikt. PAE is afaik alleen relevant als je meer dan 4GB fysiek wil adresseren op 32bits processors.

Die hele 2GB-boundary heeft alleen te maken met het feit dat Windows niet echt een modern OS is . En ja, dat is dus een software limitatie. De hardware, en moderne besturingssystemen ondersteunen t immers wel.

[Femme]

]-[Skinlab]-[ schreef op donderdag 10 februari 2005 @ 01:20:
Mja heb 't ook gelezen. Zowieso beetje overkill. En in de gewone webservers duwen ze IDE harddisks...besteed dan wat meer geld aan fatsoenlijke schijven ipv IDE....

maja..fok

Er is helemaal niets mis met het gebruik van (S)ATA-harde schijven in het type webservers dat Fok! (en Tweakers.net) gebruiken. Die dozen niets anders dan een kleine set statische content en heel veel dynamische pagina's genereren. Daar heb je geen snelle harde schijven voor nodig en betrouwbaarheid is ook geen issue omdat de webservers zelf al redundant zijn. of superbetrouwbare harde schijven voor nodig. RAID 1 zou wel wat mooier zijn maar is niet noodzakelijk.

Het is nogal jammer dat er maar zes schijven in die databasedoos passen. Er zijn alternatieven waarmee je acht schijven in een 2U doos kwijt kunt, zodat er in plaats van drie 73GB 15K disks vijf of zes 36GB schijven gebruikt hadden kunnen worden. Meer spindles is betere performance. IMO had men voor een betere prijs kunnen gaan shoppen bij Melrow of een andere toko die barebones van Appro of Supermicro verkoopt. Aan de andere kant kan ik de keuze voor Dell wel begrijpen gezien de beperkte kennis van hardware bij Fok!.

Verwijderd schreef op donderdag 10 februari 2005 @ 01:22:
[...]

Ik had zeker voor de databaseserver een Dual Opteron 250 met minstens 8GB geheugen icm FreeBSD 5.3 AMD64 gekozen.

Mijn voorkeur zou ook uitgegaan zijn naar Opterons omdat die in de meeste database-benchmarks beter presteren. Of 8GB geheugen nodig is voor Fok! weet ik niet. FreeBSD lijkt me niet handig als de rest van het serverpark op Linux draait en MySQL onder Linux beter presteert dan onder FreeBSD (volgens NewsForge). De ontwikkelingen op Linux-gebied lopen ook veel harder, mede dankzij een voor grotere bijdragen van bedrijven.

[Desolation Angel]

1 woord : EMT64

[TD-er]

TGEN schreef op donderdag 10 februari 2005 @ 21:52:
[...]

Elke 386 kan tot 4GB aan fysiek geheugen adresseren. Het zit 'm alleen in dat de address space 32 bits groot is, maar dat OS'en naast t fysieke geheugen ook virtueel geheugen willen aanspreken, bijvoorbeeld voor IO memory maps, paging, etc. Als je je hele address space al aan fysiek geheugen 'verspilt', heb je geen ruimte meer over voor je virtuele bende. Daarvoor is er PSE-36, die de address space naar 36bits uitbreid (maar de fysieke addressbus is nog steeds 32bits breed, dus nog steeds 4GB max). Helaas wordt dat niet al te vaak gebruikt. PAE is afaik alleen relevant als je meer dan 4GB fysiek wil adresseren op 32bits processors.

Die hele 2GB-boundary heeft alleen te maken met het feit dat Windows niet echt een modern OS is . En ja, dat is dus een software limitatie. De hardware, en moderne besturingssystemen ondersteunen t immers wel.

't kan aan mij liggen, maar een 386 kon toch voor elk proces maximaal 4 GB aan adresruimte gebruiken, redelijk onafhankelijk van het aantal processen...
De kernel moet dan die virtuele adresruimte mappen op het aanwezige fysieke geheugen.
Die verhouding van fysiek geheugen die dan maximaal gebruikt kan worden voor de processen is 3 GB en voor de kernel 1 GB.
Dus het verschil met wat jij zegt zou dan zijn dat er alleen geen grens zit op de virtuele adresruimte, behalve op het virtuele geheugen per proces.

Vanaf ik meen bepaalde serverworks chipsets op P3 (xeon) server boardjes zou het mogelijk moeten zijn om meer dan 4 GB aan fysiek geheugen te gebruiken (PAE 36 bits adressering). Alleen werkt dat via pagina's die in de 4 GB adresspace geschakeld kunnen worden.
Het nadeel met werken met pagina's is dat je of vrij vaak moet wisselen, of data van de enige pagina naar de andere moet kopieren. Dit is dan een aanzienlijk stuk langzamer dan wanneer je wel in een keer de volledige hoeveelheid fysiek geheugen kunt aanspreken.