recently i have so much problem with windows 8.1 updated i even re install new one but i still have the problem
my problem is that with even 4 gig of ram my system goes on low ram and force closing chrome or Viber messenger or etc it uses too much page file and disk and it is making me crazy
...
@Mahdi I saw that the other day and all I could think was "15.5GB of 15.9GB committed?!?!?!? Feck me that sounds wrong"
You have something chewing up your memory, your commit should not get that high. What does it look like after a reboot? Not a shutdown and restart, a good old Start menu -> Restart type reboot.
This could be a broken driver. I'd suggest trying to update all your drivers, particularly graphics or wireless drivers. — David SchwartzSep 25 at 18:19
That's quite likely.
@Mahdi You might get a bit more information with RAMMap.
Also, @Mahdi, in Task Manager try going into the details tab, right click on the column header => select columns => tick "commit size" and sort by that
@Bob I disagree. Having page cache on the exact same drive with the exact same performance characteristics is silly. Let's see: to avoid making extra reads from disk, I'll... store stuff I read from disk, on disk! Yeah! Great idea! :D
If programs were having to page out to disk, then we have a problem. But if programs' mapped pages in RAM are pushing page cache out of RAM and making the system forget about those pages completely, oh bloody well -- I'm fine with that. What I'm not fine with is the yo dawg mentality of caching something on the same drive it came from.
@Bob Well, if you have 16 GB or so of page cache in physical RAM, and a program requests a gigabyte via malloc(), what would any sane page cache implementation kick out? the data that's accessed once a day, or the data that's accessed every second?
I'd think it would be worth a bit of defragmentation of RAM (aka shuffling bits around to free up a big block, while culling some unneeded data) to kick out rarely used cached data, while keeping the stuff that's used frequently.
@allquixotic It means that it's no longer possible for the system to swap out rarely-or-never-used application data in favour of frequently accessed disk cache data.
@Bob Oh. Well, when you put it that way..... But still, the latency of my spinning rust array is so high (the RAID doesn't help with latency, I'm sure) that Windows would probably tend to swap out junk a bit too aggressively, so that when I go to maximize some program later, I get to look at a black window for 30 seconds while it loads.
That whole argument is predicated on the fact that you have programs which are holding on to gigabytes of pages of virtual memory, mapped into their address space, not pinned in RAM (you can "pin" pages if you want the OS to not swap them out, to help it optimize, if you know you'll be accessing them all the time) -- and which, for those GBs of wasted pages, the data is rarely, if ever, read/written.
That's probably somewhat true of extremely long-running GC-driven programs like .NET and Java with a max heap size >= 1 GB, but the latest versions of both Java and .NET will eventually clean up their heap by releasing unneeded pages to the operating system.
@Bob Yeah; what I really need is another Samsung 850 Pro -- maybe a 512GB one, since that's a sweet spot between capacity/speed/throughput/affordability for me, and 1 TB is too expensive @ 700 USD -- and stick Readyboost and a huge pagefile on it.
And I'll have space left over to stick my favorite game of the month on there.
Or half of my steamapps\common directory, even ...
heh, everything my SSD is doing is 100% visible to Windows, since Windows is the only thing that does anything with it -- ReadyBoost and the pagefile are both Windows features
> Automatic acoustic management (AAM) is a method for reducing acoustic emanations in AT Attachment (ATA) mass storage devices for computer data storage, such as ATA hard disk drives and ATAPI optical disc drives. AAM is an optional feature set for ATA/ATAPI devices; when a device supports AAM, the acoustic management parameters are adjustable through a software or firmware user interface.
> most drives use power control of the head-positioning servo to reduce vibration induced by the head positioning mechanism
> Previous seek mechanisms used maximum power and acceleration to position the head. This operation induced the familiar clicking vibration emanating from a seeking hard drive.
...I think I'll take faster seek times
then again, this drive utterly fails at that too
> AAM is no longer available for Seagate and Western Digital drives. In 2008, Seagate removed AAM capabilities from all its drives because Convolve alleged that one of its patents, US Patent No. 6,314,473 covers AAM technology. Western Digital began doing the same in 2011, without making any official announcements, nor updating their product documentation.
@allquixotic Then again, something actually needs to set it.
I wonder if Windows is even aware of it.
uhmm
@allquixotic did you hear?
Apparently Threshold is gonna be called Windows 10.
the process control block and a program's call stack have nothing to do with one another; they're just different.
you can write a program that doesn't use a stack at all, and just does its work in registers and/or the heap. the frame pointer (ebp) can be repurposed as a general-purpose register.
but, if you're in userspace and you can't modify the kernel, you aren't going to be running any programs without a process control block, on Windows or any UNIX-alike (Linux, OS X, etc.)
the PCB will be "forced upon" you from on high, but no one's forcing you to use a call stack; that's an implementation detail of your program.
of course you could also write an OS that doesn't have a concept of a PCB, and programs on that OS could either have, or not have, call stacks.
so the two concepts are mostly orthogonal.
and while neither concept is strictly required for turing-complete computing, they are considered to be useful in modern OSes because of the benefits they provide.
so I have no idea what you mean by "rudimentary"
you wouldn't happen to be doing homework, would you?
there's no point trying to compare process usage with mine. I have entirely different processes running. anyway, the high commit usage on your system is likely due to a single culprit, which I am obviously not running.
@Mahdi then check again when your commit usage is high again
But seriously, not all channels are legal everywhere. I think we have channels 1 to 11 over here in NL and I can not select channel 13 while having my locale configure to NL.
Once I change my language/locale in windows then the wifi driver suddenly allows more options.
Which confused the bajesus out of me when I ran into that problem for the first time.
@allquixotic I agree but I'm not speaking in technical terms, I was trying to ask the question in an intuitive way. I found the answer here the thread ...has a stack, which contains the execution history" and a thread has a process control block (which roughly speaking "contains" it), so in that sense I would say a process control block is more fundamental than the stack that holds functions frames.
@Celeritas You're assuming a certain operating principle of an operating system that doesn't have to be, though. In order to speak with such concreteness, you should refer to a specific implementation of an OS, or at least a family.
On something like Linux, certainly a PCB is more "fundamental" than a call stack, since every userspace process must have a PCB, but needn't have a call stack.
@allquixotic And from the other side, a small embedded program running on an AVR micro can have a call stack, but there's no concept of processes at all.
that's why I was so puzzled by his question -- it seems to be assuming that we're talking about some kind of fuzzy-wuzzy definition of a modern operating system
man... I can tell my program is working, but it's taking a long time to process about 25,000 objects... running hairy regexes over many tens of thousands of large strings; adding objects to a directed graph with cycle detection...
wow... memory increased steadily by about 250 KB per minute for ~25 minutes, then suddenly it broke through the performance-bottlenecky area and now it's finishing up at a good pace
nice... Ruby's GC is smart! the heap just shrunk in half (it told the OS that it could reclaim some memory)