|
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
Re: st: Memory, Stata 10, and 32-bit XP
You are really in troubles. If you plan to use large datasets nowadays I
recommend you to get a 64bit machine. There are cheep options today.
If you still want to use your machine and be able to use large datasets
for my experience I would not recommend any windows (taking the
considerations you read in that Stata web page). Linux would fit better.
Well, it can seems to be ridiculous but you gain so much if make a very
good plan to migrate.
Myself I have a lapton Pentium IV (1.8Ghz) with 2Gb of RAM and I can
load datasets with 1600Mb with segmentation troubles (with Stata10 and
Stata9). I use ubuntu 7.10.
Good Luck
Caveman
Sylvain Friederich wrote:
Dear all,
I am running v10 on a desktop under 32-bit XP (SP2),
Xeon dual-core chip, 4 GB of RAM.
I know that more than 2.1 GB can't actually be
addressed under Win XP 32-bit.
I've read
<http://www.stata.com/support/faqs/win/winmemory.html>
so I also know that I may not be able to claim
remotely so much under 32-bit XP.
The peculiarity I am facing is that I can always
request 1004m max, and never more.
-set mem 1005m- always yields an -rc909-. Whether
Stata is the 1st or the 10th application I launch
makes no difference.
I am able to run more instances of Stata 10, and again
claim as much as 1004m and no more. It takes about 7
instances before the OS denies me 1004m.
Therefore it doesn't look like DLLs are fragmenting
memory quite as described in the FAQ above because
that would seem to cause the amount of available RAM
to be random: "You may be surprised to find that a
1.4-GB dataset loaded fine one time but failed to load
later."
In my case a 1.4 GB dataset would never load and I'm
simply never able to claim more than about this fixed
amount of 1004m.
I interpret this as caused by a process occupying the
exact same place in the RAM every time. Presumably it
would be lodging itself there very early on in the
login process. But I'm not at all sure this reasoning
is correct. (Alternatively, it's as if the OS were
"hard set" to never allocate more than 1004m of RAM to
an application. But I don't know how that would be.)
To identify the process causing trouble, I know I can
pull up the list of processes in the Task Manager, try
to kill some of them and see whether that makes a
difference but there's only so many that are not
essential for network connections and stable operation
of the computer. The machine starts playing up
quickly. I'm hoping there is something better to do.
Now yesterday I installed v9 to implement the check
suggested on the FAQ page. The result is that under v9
I can exactly claim 1197m and never 1198. That's about
200 MB more than under v10, so in that sense it checks
but again I seem to come across a hard limit that
never varies.
Other things I've attempted to no avail included
installing the Windows hotfix (from FAQ page) and
trying to run XP in Safe Mode.
I'm told I could use a 'memory profiler' to analyse
how RAM is used by my machine, but before I spend time
and money doing that, I would love to hear from anyone
who had come across this behaviour or knew enough
about memory management in XP to confirm whether my
interpretation above is correct.
Many thanks.
Sylvain
***** More details *****
I said 1004m everywhere above but technically I can
claim slightly more than that:
. forval i = 1028096(1)1029120 {
2. set mem `i'k
3. }
(1028096k)
(1028097k)
(1028098k)
(1028099k)
(1028100k)
.
.
(omitted)
.
.
(1028347k)
(1028348k)
(1028349k)
(1028350k)
(1028351k)
op. sys. refuses to provide memory
r(909);
***************
__________________________________________________________
Sent from Yahoo! Mail.
A Smarter Inbox. http://uk.docs.yahoo.com/nowyoucan.html
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/