Ravenous RAM use.

I am doing a chkdsk on my 1Tb HHD (not the system disk) and I see it's
using 12GB RAM..! The RAM is OCZ DDR3PC312800Inteli7
OCZ3X1600R2LV6GK. Is it normal for a chkdsk to use this much memory?
Peter

Peter Jason wrote:

> I am doing a chkdsk on my 1Tb HHD (not the system disk) and I see it's
> using 12GB RAM..! The RAM is OCZ DDR3PC312800Inteli7
> OCZ3X1600R2LV6GK. Is it normal for a chkdsk to use this much memory?
> Peter

You have 12GB of RAM for any process to consume?

On 05/12/2011 05:59, Peter Jason wrote:
> I am doing a chkdsk on my 1Tb HHD (not the system disk) and I see it's
> using 12GB RAM..! The RAM is OCZ DDR3PC312800Inteli7
> OCZ3X1600R2LV6GK. Is it normal for a chkdsk to use this much memory?
> Peter
>
12 GIGS of RAM? Methinks you have misstyped something.
Although that amount is possible it is unusual what sort of kit you
running? Opinion is divided as to whether this RAM utilisation is by
design or a bug. Unless you are trying to run other things or at the
end of chkdsk it is not releasing this memory what is the problem?

Peter Jason wrote:
> I am doing a chkdsk on my 1Tb HHD (not the system disk) and I see it's
> using 12GB RAM..! The RAM is OCZ DDR3PC312800Inteli7
> OCZ3X1600R2LV6GK. Is it normal for a chkdsk to use this much memory?
>
> Peter

The customer view. At least a few customers aren't happy,
that checking non-C: partitions, chews up all the RAM.

http://social.technet.microsoft.com/...0-289ef813b2e6

The Microsoft view. Say "it's by design", and then blow
smoke up your ass.

http://blogs.msdn.com/b/e7/archive/2...ug-report.aspx

I can't even understand, how holding gobs and gobs of disk structure
is an advantage. If we looked at the size of $MFT for example,
would we need 12GB to hold it ? Or, some smaller amount ?
In a quick check, I see around 275MB for $MFT on my laptop
C: drive (determined with the nfi.exe log I created some time
ago).

The operating system, already has a file cache, which works
transparently, and evicts cached structures whenever the
system is under memory pressure. If you start a program and
it needs RAM, the system simply updates the list of things
it thinks are cached in memory. And doing so, is virtually
instantaneous, and the user doesn't even know a cache is
present. Now, if chkdsk used the regular system file cache,
as structures were being read, there would be no design
problem at all. If instead, they do private allocations,
we'd get the symptoms people are seeing. So the question
would be, "why isn't the regular file cache, good enough?".

If this is "design intent", I don't see the "good design principles"
oozing out of it :-( If the design is really that good,
someone at Microsoft should be able to explain it.
Instead of describing how many engineers they fly around
on airplanes.

And to think that blog entry was written by Steven Sinofsky.

http://en.wikipedia.org/wiki/Steven_Sinofsky

I'd like to hear an opinion from Mark Russinovich. I wonder
what he thinks about this "feature".

Paul

Paul wrote:
> Peter Jason wrote:
>> I am doing a chkdsk on my 1Tb HHD (not the system disk) and I see it's
>> using 12GB RAM..! The RAM is OCZ DDR3PC312800Inteli7
>> OCZ3X1600R2LV6GK. Is it normal for a chkdsk to use this much memory?
> >
>> Peter
>

There is a workaround mentions on dailytech.

"No point delaying. The issue is only on the 64-bit version of Windows 7
and it's not a true memory leak.

The version of chkdsk.exe is the same on both 32-bit and 64-bit installations
of Windows 7, but doesn't seem to be compiled for 64-bit use or being run
through the 32-bit emulator properly. So, when memory is addressed it goes
into a loop and never stops incrementally allocating a memory block. The issue
doesn't happen when using the 32-bit version of command prompt
("C:\Windows\SysWow64\CMD.exe").
"

I think what that poster is suggesting, is that by using a 32 bit environment
for the executable, you can stop it from using more than 2GB of virtual address
space. That's how I interpret that idea as a "win". I don't think it is actually
fixing anything, merely placing a "32 bit road block" in the way.

When this question was asked previously, there was evidence that if
the memory was blocked artificially, chkdsk would stop chewing up the
RAM. But it's unclear to me, whether that is true or not. And nobody
tested my suggestion. You can use the Sysinternals "testlimit" or "testlimit64"
programs, to do your own RAM grabbing, to prevent chkdsk from getting it all.
What is unclear, is when you kill off the testlimit program, whether chkdsk
begins to chew on the freed up RAM. If it was a memory leak, it should do so.

The behavior is a bit puzzling. If it was a leak, I presume swap would
also get chewed up, until the system crashed. And while there are
reports of BSODs happening, that's relatively infrequent. Some people
with 8GB, claim CHKDSK will use 7GB. Which sounds like the program has
measured available physical RAM and stopped there. If the response is
measured, then "it's by design". It implies they designed it that way.

But the behavior is still not acceptable. For example, one poster described
running four copies of CHKDSK at the same time (one running per disk, as such
a process is disk limited and not CPU limited), and the programs would
fight for memory, leaving some of the instances starved for memory,
compared to their peers. And apparently, that was slowing down
all the instances. I'm still not convinced there is a "good design"
hiding in there.

If you do any further testing, and figure out a solution, please post back.
I'm not testing this one... I don't have big enough disks for this, or
good enough setups. (3GB RAM, 320GB disk)

Paul

On Mon, 5 Dec 2011 01:02:11 -0600, VanguardLH <> wrote:

>Peter Jason wrote:
>
>> I am doing a chkdsk on my 1Tb HHD (not the system disk) and I see it's
>> using 12GB RAM..! The RAM is OCZ DDR3PC312800Inteli7
>> OCZ3X1600R2LV6GK. Is it normal for a chkdsk to use this much memory?
>> Peter
>
>You have 12GB of RAM for any process to consume?

Yes; the motherboard (GA-X58A-UD7-2) had all the RAM slots, so I
filled them up. The only other application using lots of RAM is the
Adobe Premiere Pro which used 40% when finalizing a movie.

I am test the HDDs because two of them disappeared completely from
Windows Explorer and Computer Management. One subsequently
re-appeared on a reboot so I did a chkdsk on it. (no problems found).
The other HDD is still hiding. The rest is mystery. Still, the
missing disk(s) are active mechanically; I can feel them buzzing
and burping.

On Mon, 05 Dec 2011 06:04:21 -0500, Paul <> wrote:

>Paul wrote:
>> Peter Jason wrote:
>>> I am doing a chkdsk on my 1Tb HHD (not the system disk) and I see it's
>>> using 12GB RAM..! The RAM is OCZ DDR3PC312800Inteli7
>>> OCZ3X1600R2LV6GK. Is it normal for a chkdsk to use this much memory?
>> >
>>> Peter
>>
>
>There is a workaround mentions on dailytech.
>
> "No point delaying. The issue is only on the 64-bit version of Windows 7
> and it's not a true memory leak.
>
> The version of chkdsk.exe is the same on both 32-bit and 64-bit installations
> of Windows 7, but doesn't seem to be compiled for 64-bit use or being run
> through the 32-bit emulator properly. So, when memory is addressed it goes
> into a loop and never stops incrementally allocating a memory block. The issue
> doesn't happen when using the 32-bit version of command prompt
> ("C:\Windows\SysWow64\CMD.exe").
> "
>
>I think what that poster is suggesting, is that by using a 32 bit environment
>for the executable, you can stop it from using more than 2GB of virtual address
>space. That's how I interpret that idea as a "win". I don't think it is actually
>fixing anything, merely placing a "32 bit road block" in the way.
>
>When this question was asked previously, there was evidence that if
>the memory was blocked artificially, chkdsk would stop chewing up the
>RAM. But it's unclear to me, whether that is true or not. And nobody
>tested my suggestion. You can use the Sysinternals "testlimit" or "testlimit64"
>programs, to do your own RAM grabbing, to prevent chkdsk from getting it all.
>What is unclear, is when you kill off the testlimit program, whether chkdsk
>begins to chew on the freed up RAM. If it was a memory leak, it should do so.
>
>The behavior is a bit puzzling. If it was a leak, I presume swap would
>also get chewed up, until the system crashed. And while there are
>reports of BSODs happening, that's relatively infrequent. Some people
>with 8GB, claim CHKDSK will use 7GB. Which sounds like the program has
>measured available physical RAM and stopped there. If the response is
>measured, then "it's by design". It implies they designed it that way.
>
>But the behavior is still not acceptable. For example, one poster described
>running four copies of CHKDSK at the same time (one running per disk, as such
>a process is disk limited and not CPU limited), and the programs would
>fight for memory, leaving some of the instances starved for memory,
>compared to their peers. And apparently, that was slowing down
>all the instances. I'm still not convinced there is a "good design"
>hiding in there.
>
>If you do any further testing, and figure out a solution, please post back.
>I'm not testing this one... I don't have big enough disks for this, or
>good enough setups. (3GB RAM, 320GB disk)
>
> Paul

Mine is a 64bit system. I'll chkdsk another disk later today.

On 05/12/2011 21:03, Peter Jason wrote:
> On Mon, 5 Dec 2011 01:02:11 -0600, VanguardLH<> wrote:
>
>> Peter Jason wrote:
>>
>>> I am doing a chkdsk on my 1Tb HHD (not the system disk) and I see it's
>>> using 12GB RAM..! The RAM is OCZ DDR3PC312800Inteli7
>>> OCZ3X1600R2LV6GK. Is it normal for a chkdsk to use this much memory?
>>> Peter
>>
>> You have 12GB of RAM for any process to consume?
>
> Yes; the motherboard (GA-X58A-UD7-2) had all the RAM slots, so I
> filled them up. The only other application using lots of RAM is the
> Adobe Premiere Pro which used 40% when finalizing a movie.
>
> I am test the HDDs because two of them disappeared completely from
> Windows Explorer and Computer Management. One subsequently
> re-appeared on a reboot so I did a chkdsk on it. (no problems found).
> The other HDD is still hiding. The rest is mystery. Still, the
> missing disk(s) are active mechanically; I can feel them buzzing
> and burping.

Does Windows recognise it to any degree at all?
Does it make the ding-dong sound when you plug it in? Any sign in the
lower pane of Disk Management? Anything under USB in Device Management?

If you can rule all those out, then it will look very much like a
hardware thing; dodgy cable connection, or failed innards of the drive
itself.

Trying it on another computer will be a great help.

Ed

On Tue, 06 Dec 2011 08:03:58 +1100, Peter Jason <> wrote:

>On Mon, 5 Dec 2011 01:02:11 -0600, VanguardLH <> wrote:
>
>>Peter Jason wrote:
>>
>>> I am doing a chkdsk on my 1Tb HHD (not the system disk) and I see it's
>>> using 12GB RAM..! The RAM is OCZ DDR3PC312800Inteli7
>>> OCZ3X1600R2LV6GK. Is it normal for a chkdsk to use this much memory?
>>> Peter
>>
>>You have 12GB of RAM for any process to consume?
>
>Yes; the motherboard (GA-X58A-UD7-2) had all the RAM slots, so I
>filled them up.

I guess you're lucky they didn't sell you a server motherboard that
can handle 64 GB of RAM because you probably would have filled that
up, too. :-)

--

Char Jackson

Peter Jason <> écrivait
news::

<snip>

>
> I am test the HDDs because two of them disappeared completely from
> Windows Explorer and Computer Management. One subsequently
> re-appeared on a reboot so I did a chkdsk on it. (no problems found).
> The other HDD is still hiding. The rest is mystery. Still, the
> missing disk(s) are active mechanically; I can feel them buzzing
> and burping.

I've had a similar issue; my computer had a side panel removed and had
hard drives power wires outside the case, when my foot touched the outside
wires, 2 of the HDs would disappear (fortunately, not the system drive);
it's a 4 HDs system. I've put back the outside wires inside the case and
no issue since then (the side panel is still ... off).

So, in your case, it could be wiring or power supply issues?...