Ich habe mir ein Lenovo-Notebook vor 1 1/2 Jahren gekauft, da läuft gerade WinXP Prof 32bit drauf. Vom Werk aus sind da 2x512MB-Speicherriegel eingebaut. Ich würde gerne den Speicher aufrüsten, bin mir aber nicht sicher wieviel? 2GB sollten mindestens sein, aber ich frage mich, ob ich doch 2x2GB einbauen sollte. Was meint ihr, wieviel Speicher macht eigentlich Sinn?
Mehr als 3 GB machen keinen Sinn (32Bit OS). Würde einen Riegel raus nehmen und einen extra 2GB Riegel dazu stecken. Den anderen 512 MB Riegel bei Ebay verkaufen oder bekannten geben die noch einen Slot frei haben.
Soweit ich weiß kann WinXP gar nicht die vollen 4 Gigabyte nutzen, die bei einem 32-Bitter im Prinzip möglich sind.
Ich würde, der synchronität halber etc, beide raus und 2x 1GB rein...
Wie viel Speicher Sinn ergibt, das interessiert schon lange keine Sau mehr. Sinnvoll für den Bürobedarf sind 250..500MB. Für aufwendigere Sachen (Compilerläufe usw.) auch 1..2GB. Bei Servern auch gern das Zehnfache. Bei Windows kommt die Lachnummer hinzu, dass die Desktopversionen auf 4GB begrenzt sind, auch mit PAE.
Wenn Standardriegel reinpassen mach 4GB rein. Das Windows kann zwar nur 3,5GB nutzen, aber man hat zwei gleiche Riegel. Und die Welt kosten sie auch nicht mehr.
was ich oft sehe, das System hat noch genug RAM zur Verfügung und der Rechner rödelt und rödelt und füttert die Auslagerungsdatei mit Stoff. Macht für mich keinen Sinn, vor allem, wenn Resourcen da sind, und wenn die Auslagerungsdatei ins Spiel kommt, wird das System spührbar langsammer.
2x 2GB ... sofern es DDR2 Ram ist (nehme ich an) bekommt man ja fast geschenkt. Kannst zwar nur 3,2-3,5GB nutzen, aber was solls.
Die Auslagerungsdatei kannst Du ja abschalten. Aber nicht jeder OS-Kernel kann alles von 4GB als Applikationsspeicher zuweisen! Vom PCI-Loch (128 bis 512MB am oberen Ende) mal abgesehen.
Etwas Off-Topic: Wie sieht das da eigentlich mit dem virtuellen Speicher aus? Kann Windows da über die 3 GB hinwegadressieren? Eigentlich sinds ja für die Applikationen die gleichen 32 bit Adressen, da für eine Applikation transparent ist, wo nun das Krams liegt, was es adressiert. Hat also bei 4 GB Ram auf WinXP 32bit eine Auslagerungsdatei überhaupt noch einen Sinn?
Eine einzelne 32-Bit-Anwendung kann nicht mehr als 2GB Adressraum verarbeiten (es gibt spezielle Ausnahmen mit 3GB). Das übersetzt sich in der Praxis in nicht mehr als 1-1,5GB genutzem physikalischem Speicher, da selten alle vergebenen Adressen auch verwendet werden. Der Rest steht nur anderen Anwendungen und dem Plattencache zur Verfügung. Wenn man vorwiegend mit wenig gleichzeitig aktiven grossen Anwendungen arbeitet und keine virtuellen Maschinen verwendet, dann wird man unter XP zwischen 2GB und 4GB RAM (effektiv 3,0-3,7GB) nicht sehr viel Unterschied spüren. Auslagern wird Windows trotzdem.
Windows kann einem einzelnen Prozess maximal 2GB zuteilen. Mehr als 4GB insgesamt verwalten, das geht physikalisch mit PAE und das kann z.B. jedes aktuelle Linux, nur bei Windows ist halt eine künstliche Beschränkung auf 4GB einprogrammiert. Muss man halt eine größere Serverversion kaufen... Irgendwo gabs deshalb mal die Idee, mit irgendwelchen Programmen eine RAMDISK oberhalb der 4GB (...) anzulegen und die Auslagerungsdatei dann auf dieser unterzubringen.
>Hat also bei 4 GB Ram auf WinXP 32bit eine Auslagerungsdatei >überhaupt noch einen Sinn? Ja, auf jeden Fall! Wie A. K. schon schrieb, lagert Windows immer aus. Daher bei 32Bit Systemen PAE aktivieren und dann eine RAM-Disk mit dem übrigen Speicher (bei mir sind es ca. 4,7GB, da 8GB RAM) einrichten. Dorthin dann die Auslagerungsdatei legen und vieles wird spürbar schneller. Es gibt kommerzielle RAM Disks, aber auch kostenlose. Ich nutze letztere, man darf nur nicht sowas wie Suspend-To-Ram machen, das geht schief. Kann beim kommerziellen anders sein.
@A.K. > Eine einzelne 32-Bit-Anwendung kann nicht mehr als 2GB Adressraum > verarbeiten (es gibt spezielle Ausnahmen mit 3GB) doch das geht, der MS-SQL Server in der 32Bit version kann auch mehr als 4GB nutzen. Das ganze wird dann wieder mit eingeblendentet Fenstern gemacht( PAE )
Ein Notebook mit ausreichend RAM hat den kleinen Vorteil, daß es weniger auf der Platte herumrödeln muß. Bei XP: 2x2GB reichen für die nähere Zukunft. Dann ist der Akku krank oder das Display beschädigt...
>Ein Notebook mit ausreichend RAM hat den kleinen Vorteil, daß es weniger >auf der Platte herumrödeln muß. Das stimmt, aber vielleicht nur in der Theorie. Bei mir wird die Auslagerungsdatei gerne vollgeknallt, obwohl noch mehrere Hundert MB zur Verfügung stehen. Auslagerungsdatei in eine RAM-Disk schieben, das hört sich gut an. Werde mal schauen, wie ich das mache. Danke an alle.
Hat nicht "irgendwer" mal behauptet, dass man niemals mehr als 640K brauchen wird!?
Peter schrieb:
> PAE
Kenne ich. Aber das sind extreme Fälle einiger sehr spezieller
Server-Anwendungen und im hier betrachteten Fall eines Notebooks kaum
relevant
Bill G. aus R. schrieb: > Hat nicht "irgendwer" mal behauptet, dass man niemals mehr als 640K > brauchen wird!? War das nicht in Bezug auf Disketten gemeint?
Also 1 GB Ram reichen für weit über 90 % der Anwendungen aus eupp / Berlin
Peter schrieb: > 4GB nutzen. Das ganze wird dann wieder mit eingeblendentet Fenstern > gemacht( PAE ) Das ist allerdings nicht PAE sondern AWE.
> Also 1 GB Ram reichen für weit über 90 % der Anwendungen aus
Weit über 90 % aller Pauschalaussagen treffen zu.
@ A. K. (prx) >Peter schrieb: >> 4GB nutzen. Das ganze wird dann wieder mit eingeblendentet Fenstern >> gemacht( PAE ) >Das ist allerdings nicht PAE sondern AWE. Doch, das ist schon PAE - AWE nutzt PAE, um die Memorypages über 4GB zu verwalten. Grundsätzlich ist es so, daß 4GB eigentlich gar keinen Sinn machen - vielleicht so 3GB mögen noch Sinn machen. Das ist eben desahlb, weil Mr. Gates sich damals so gedacht hat bei 32bit, daß 4GB adressierbar sind. Der wird unterteil in Kernel- (2-4GB) und Userspace (0-2GB). Das war damals sicherlich einfach so mal eine fifty-fifty-Entscheidung, denn weder Kernel- noch Usercode hatte damals vermutlich kaum das Potential, mal so richtig den verfügbaren Space auszunutzen. Wenn jemand also glaubt, seine Programme brauchen viel Platz, dann ebendoch nur bis rund 2GB. Kernelspace wird üblicherweise ohnehin nur zu ein paar 10% ausgenutzt von Windows, so daß eigentlich ohnehin nur 2,5-3GB RAM sinnvoll sind. Sollte doch mehr Userspace nötig sein, wurde der /3GB Switch für die Boot.ini erfunden, welcher zwar bei jeder Windowsversion den Kernelspace auf 1GB (3GB to 4GB) reduziert, aber nur bei den "besseren" Serverversionen wurde auch der Userspace auf 3GB erweitert (war schon bei WinNT erst ab den Extended Editions der Fall). Bei den Desktopversionen dagegen blieb der Raum 2GB to 3GB einfach frei - ist also vergeudeter Memory. Daß bei Desktopversionen überhaupt der Kernelspace mit den /3GB verkleinert werden konnte, wurde wohl mal so begründet, daß Kernel/Driver-Entwickler testen konnten mit nur 1GB Kernelspace. PAE: das ist der Bereich oberhalb 4GB, indem Intel seinen Prozies schon seit Jahren ein paar zusätzliche Adressleitungen spendierte (heutzutage kann es eigentlich jeder noch aktuelle Prozie). Bisher waren die normalen Consumerboard selten in der Lage, mehr als 4GB anzusprechen (idR. eher weniger), aber nun in 64bit-Zeiten werden wohl solche Boards wohl so langsam Massenware (12GB, 24GB ...). In 32bit-Systemen läßt sich der PAE-Bereich aber nicht als Arbeitsspeicher nutzen, sondern nur als reiner Cache. Windows (und wohl auch Linux arbeitet so) können z.B. Prozesse mit ihrem gesamten Adressraum dahin verlagern, wenn solch ein Prozess ohnehin nix zu tun hat (wenn er gerade keine aktive Zeitscheibe bekommt). Dort ist er stillgelegt, während ein/mehreree andere Prozesse gerade im normalen Userspace (<2(3)GB) ihre Rechenzeit verbraten. So ist es eigentlich möglich, daß die Prozesse in Summe anscheinend mehr Speicher im Zugriff haben können, als es eigentlich für 32bit möglich wäre - ein einzelner Prozess sieht aber trotzdem nur 4GB (sehen, nicht nutzen) (geschied transparent für die Prozesse). Ein anderer Weg wäre, daß ein Prozess selbst seine Daten nach PAE verlagern kann - das geht dann über AWE, was eine Win-Schnittstelle zum PAE-Zugriff darstellt. Das ist dann das, was wohl der SQL Server macht, wie bereits erwähnt (es ist aber Quatsch zu sagen, er könne seine Daten in mehr als 4GB bearbeiten - stattdessen werden die Daten dort nur zwischengelagert). ich hoffe, daß es eine einigermaßen eine fehlerfreie Zusammenfassung ist ;-)
Jens G. schrieb: > Doch, das ist schon PAE - AWE nutzt PAE, um die Memorypages über 4GB zu > verwalten. AWE geht zumindest prinzipiell auch ohne PAE, nämlich mit PSE36. > ich hoffe, daß es eine einigermaßen eine fehlerfreie Zusammenfassung ist Nicht ganz, denn du wirbelst virtuelle und physikalische Adressen etwas durcheinander. Der Speicher jenseits der Adresse 0x100000000 (4GB) kann in 32bit Windows XP nur deshalb nicht für aktive Prozesse verwendet werden, weil Microsoft das künstlich beschränkt hat. Mit dem mitgelieferten aaber nicht automatisch aktivem PAE-Kernel wäre es sehr wohl dazu in der Lage, aber MS will eben auch die Enterprise-Versionen für teures Geld verkaufen. Ob Speicher jenseits 4GB überhaupt ohne PAE-Kernel adressiert werden kann weiss ich grad nicht. Im Prinzip geht es, weil PSE36 bereits vor PAE die Möglichkeit dazu bot, d.h. 4MB Pages in 32bit Deskriptoren mit ein paar mehr Adressbits. Das übrigens war die zumindest ursprüngliche Idee hinter AWE. Ein Betriebssystem ohne diese künstliche rein kommerzielle Beschränkung wird den gesamten Speicher für Prozesse verwenden, auch jenseits von 4GB. Dabei ist es egal, ob das Betriebsystem oder ein Prozess 32bittig oder 64bittig ist. Mit aktiven oder inaktiven Prozessen hat das nichts zu tun. Die Beschränkung von 32bit Prozessen auf 2/3/4GB Adressraum (WinXP/WinServer3G/Linux) hat damit wiederum nichts zu tun. Erst wenn man den Speicher jenseits der 4GB-Grenze als RAM-Disk einrichtet, um Microsofts Limit zu umgehen (in Linux logischerweise unnötig), dann gibt es zwischen aktiven Prozessem im Primärspeicher (untere 3-4GB) und ausgelagerten Prozessen im Sekundärspeicher (jenseits 4GB) einen Unterschied.
> Ein Betriebssystem ohne diese künstliche rein kommerzielle > Beschränkung wird den gesamten Speicher für Prozesse verwenden, > auch jenseits von 4GB. Dabei ist es egal, ob das Betriebsystem > oder ein Prozess 32bittig oder 64bittig ist. So scheint es auch das kommerzielle Mac OS zu handhaben. Das hat einen 32-Bit-Kern, auf dem 32-Bit- und 64-Bit-Applikationen munter nebeneinanderherlaufen können. Mag zwar sein, daß das gewisse Performanceunterschiede gegenüber einem 64-Bit-Kern mit sich bringt, aber so benötigt man nur einen OS-Kern und auch nur eine Devicetreiberarchitektur. Und Prozesse, die richtig viel Speicher brauchen, können ihn nutzen. Das erscheint mir ein sinnvollerer Ansatz zu sein als die Windows'sche Unterscheidung in x86- und x64-Editionen.
Rufus t. Firefly schrieb: > Das erscheint mir ein sinnvollerer Ansatz zu sein als die Windows'sche > Unterscheidung in x86- und x64-Editionen. Mir nicht. Die Krücken, die der 32bit-Kernel dann braucht, um den Speicher eines 64bit-Prozesses adressieren zu können, sind nicht wirklich elegant. In AIX lief das ähnlich scheusslich. Dieses permanente Remapping geht auch etwas auf die Performance. Auf Dauer kommt man um einen 64bit-Kernel nicht herum. Der hat genug Adressraum, um den Speicher aller Prozesse gleichzeitig in den Kernel mappen zu können, wie Linux das zeitweilig bei 32bit gemacht hatte. Erspart zeitraumende Manipulationen der page tables mit entsprechenden TLB flushes.
A. K. (prx) > AWE geht zumindest prinzipiell auch ohne PAE, nämlich mit PSE36. Ich gebe zu, bisher noch nicht viel über PSE36 gewußt zu haben (wird das wirklich "massenhaft" benutzt ???). Aber Wiki hat mir mal auf die Sprünge geholfen, so daß ich nun einigermaßen im Bilde bin ;-) Wie auch immer, ich glaube, Win32 benutzt kein PSE36, sondern PAE. >> ich hoffe, daß es eine einigermaßen eine fehlerfreie Zusammenfassung ist >Nicht ganz, denn du wirbelst virtuelle und physikalische Adressen etwas >durcheinander. nicht ganz - es ist mir klar, daß die virtuellen Adressen physikalisch sonstwo liegen können (und wenn es das Pagingfile ist) - ein Prozess glaubt aber trotzdem, nur physikalischen Speicher zu sehen - und der ist beschränkt auf 4GB (SEHEN, nicht NUTZEN bei win32 !!! ;-) >Der Speicher jenseits der Adresse 0x100000000 (4GB) kann in 32bit >Windows XP nur deshalb nicht für aktive Prozesse verwendet werden, weil >Microsoft das künstlich beschränkt hat. Mit dem mitgelieferten aaber ich glaube, das ist keine künstliche Beschränkung, sondern ist erst mal historisch gewachsen - damals, als die "echten" win32-Versionen rauskamen, kannten die Prozies nur 4GB per Definition. PAE und PSE36 kamen später dazu, und sind eigentlich nur Krücken, die nicht wirklich von einem Single-Prozess direkt genutzt werden können (auch bei AIX, Solaris, Linux (je nach HW) u.ä. ... nicht, was aber keine CISC, sondern RISC-Plattform benutzt - also nicht direkt vergleichbar) >nicht automatisch aktivem PAE-Kernel wäre es sehr wohl dazu in der Lage, >aber MS will eben auch die Enterprise-Versionen für teures Geld >verkaufen. logisch - machen aber auch viele ander SW-Schreiber so, um bestimmte Features gegen teures Geld zu verkaufen. >Erst wenn man den Speicher jenseits der 4GB-Grenze als RAM-Disk >einrichtet, um Microsofts Limit zu umgehen (in Linux logischerweise >unnötig), dann gibt es zwischen aktiven Prozessem im Primärspeicher >(untere 3-4GB) und ausgelagerten Prozessen im Sekundärspeicher (jenseits >4GB) einen Unterschied. wieso muß man in MS-Umgebungen RAM-Disks einrichten, und wieso ist das in Linux-Systemen "logischerweise" nicht nötig? Benutzt Linux32 PSE36? Sehen die Prozesse unter Linux mehr als 4GB (ich meine direkt nutzbar)? @ ... (Gast) Wie auch immer - 4GB machen zwar keinen Sinn mehr, aber wenn Du den billig bekommen kannst, dann rein damit. Mußt aber bedenken, daß viele Boards nur eine bestimmte Menge an Speicher verdauen - also mal ins "Boardbuch" schauen, was der Läppi verdauen kann. Mehr als 2GB wirste aber kaum den Programmen real anbieten können. Allerdings scheint Win32 ein bißchen zu schummeln. Allokieren können die Prozesse relativ viel Speicher (sogar mehr als 2GB) - aber wenn dieser Speicher wirklich benutzt werden soll, dann gibt Win32 dann auch auf (ungefähr wie ein überbuchter Flieger - wehe - alle Leute mit Ticket wollen wirklich einsteigen - dann gibt's Probleme)
Jens G. schrieb: > Ich gebe zu, bisher noch nicht viel über PSE36 gewußt zu haben (wird das > wirklich "massenhaft" benutzt ???). Nein, natürlich nicht. AWE auch nicht. PSE36 war eine üble Krücke, um Betriebssystemen, die den signifikanten Umbau zu PAE noch nicht geschafft hatten, den übrigen Speicher immerhin irgendwie ansprechbar zu machen. Und AWE eine ebensolche Krücke für Anwendungen, die eigentlich längst 64bittig sein sollten, es aber mangels günstiger Plattform noch nicht waren. Beides ist im Zeitalter von 64bit Programmen auf günstig erhältlichen 64bit Plattformen hoffnungslos veraltet. > ich glaube, das ist keine künstliche Beschränkung, sondern ist erst mal > historisch gewachsen Seit es Windows-Versionen gibt, die mehr adressieren können, ist diese Beschränkung ausschliesslich kommerzieller Natur. Dass dies bei 32bit manche Server-Versionen sind liegt in der Natur der Sache, aber deren Kernels sind bis auf solche Spässe, etwas Tuning und teils unterschiedliche Release-Dates mit den Workstation-Kernels identisch und folglich im Prizip austauschbar. Insofern war es so lange eine technische Beschränkung bis PAE in die Kernels Einzug hielt. Seit PAE ist das definitiv eine künstliche Beschränkung. XP liefert ja einen PAE-Kernel mit, der aber genauso eingeschränkt ist. Auch die Server-Versionen differenzieren sich massgeblich über den verwendbaren Speicher. Ein technischer Hintergrund besteht indes keiner. > wieso muß man in MS-Umgebungen RAM-Disks einrichten, und wieso ist das > in Linux-Systemen "logischerweise" nicht nötig? Das war nicht als Windows-Bashing gemeint. XP32 schränkt dich auf <4GB physikalischen Speicher ein, Linux nicht. Das "logischerweise" bezieht sich darauf, dass in Linux solche kommerziellen Einschränkungen kaum möglich sind. Folglich musst du in XP32 sowas wie diese RAM-Disks verwenden, um den ggf. übrigen Speicher überhaupt irgendwie verwendenn zu können. In Linux nicht.
Jens G. schrieb: > Solaris, Linux (je nach HW) u.ä. ... nicht, was aber keine CISC, sondern > RISC-Plattform benutzt - also nicht direkt vergleichbar) CISC vs RISC hat mit diesem Thema also wirklich rein garnichts zu tun. Es gibt in AIX zwar einen signifikanten Unterschied in der Art der Speicherverwaltung, aber das liegt an der anderen Umsetzung des virtuellen Speichers infolge der vorgeschalteten Segmentierung der PowerPC-Architektur, nicht an RISC. > Sehen die Prozesse unter Linux mehr als 4GB (ich meine direkt nutzbar)? Jeder einzelne Prozess ist auf 4GB beschränkt. Aber mehrere Prozesse zusammengerechnet können in Linux durchaus mehr als 4GB physikalischen Speichers direkt nutzen, in XP32 nicht. PS: Wikipedia hat mich daran erinnert, dass PAE für das NX-Bit notwendig ist, seither also alle Systeme PAE verwenden, die das NX-Bit unterstützen. Und mit PAE ist die 4GB-Grenze künstlich.
>CISC vs RISC hat mit diesem Thema also wirklich rein garnichts zu tun. Ok, hast schon recht ;-) CISC verbindet sich bei mir immer einfach nur mit Intel, wo ursprünglich eben nur 32bit (4GB) adressierbar waren - für Prozess wie auch für OS (egal, ob Win oder Linux). Das meinte ich übrigens auch mit "nicht-künstlicher" Grenze auf CPU-Level. Du beziehst dich dagegen auf die künstlichen Grenzen der jeweiligen OS bzw. deren Editionen beim Nutzen von PAE, die da höchst unterschiedlich ausfallen. >Jeder einzelne Prozess ist auf 4GB beschränkt. Aber mehrere Prozesse >zusammengerechnet können in Linux durchaus mehr als 4GB physikalischen >Speichers direkt nutzen, in XP32 nicht. ok, dann ist es mit Linux trotzdem sicherlich so wie bei Win32, wenn es eine Serverversion ist, die mehr als 4GB RAM bzw. PAE ansprechen kann.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.