Click here to Skip to main content
14,489,091 members

Welcome to the Lounge

   

For discussing anything related to a software developer's life but is not for programming questions. Got a programming question?

The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
 
GeneralRe: 8GB no longer enough Pin
enhzflep26-Aug-19 16:47
Memberenhzflep26-Aug-19 16:47 
GeneralRe: 8GB no longer enough Pin
Member 916705725-Aug-19 22:14
MemberMember 916705725-Aug-19 22:14 
GeneralRe: 8GB no longer enough Pin
phil.o25-Aug-19 22:23
mvephil.o25-Aug-19 22:23 
GeneralRe: 8GB no longer enough Pin
Dan Neely26-Aug-19 3:44
MemberDan Neely26-Aug-19 3:44 
GeneralRe: 8GB no longer enough Pin
Member 798912226-Aug-19 0:29
MemberMember 798912226-Aug-19 0:29 
GeneralRe: 8GB no longer enough Pin
raddevus26-Aug-19 1:53
mvaraddevus26-Aug-19 1:53 
GeneralRe: 8GB no longer enough Pin
Dan Neely26-Aug-19 3:51
MemberDan Neely26-Aug-19 3:51 
GeneralRe: 8GB no longer enough Pin
Member 798912226-Aug-19 7:00
MemberMember 798912226-Aug-19 7:00 
It is highly unlikely that paging is "slowing a system to a crawl". Certainly not on a desktop system used for varied tasks, like sw development. You have a real page fault, one that leads to a real, physical disk access, "every now and then". When your system comes to a crawl, have the Resource Monitor running on your system, and take a look at the Disk load. The total data volumen handled by the disk system is shown in the top running display; blow that , the queue length for each disk is shown. If you opwn Storage section in the main display, you can see for each disk the "Active Time (%)".

If the disk can't keep up with the paging requirements, the data volume would approach the transfer rate of your primary disk. A SATA-600 disk could in principle go up to 75 Mbyte/sec; you'll never see a magnetic disk that can do 75 Mbyte/sec, especially not on random accesses. Seing flash disks doing 25 Mbyte/sec is nothing special. The data volume is for all disk combined, and if you have more than one disk controller, the sum could actually go even higher than 75 Mbytes/sec.

Then take a look at the "Active Time" of your paging disk (usually the C-disk). Is it getting close to busy 100% of the time? 50%? Even 10%, over an extended period of time? I doubt it very much! Peaks: yes, of course! When you start up a huge application, thousands of pages must be brought in; that is unavoidable. Those "startup" disk accesses would have to be done no matter how much RAM you've got.

Also, when the disk driver initites a physical disk operation, it will not block the entire system while the transfer is done: The CPU is released for other tasks, and the electronics of the physical disk interface transfers data directly between the disk and RAM. For paging, the thread causing the page fault will be blocked, but no other threads.

No matter how slowly the system is crawling, I have never during this millennium (and we could add another ten years) traced it down to the paging disk being the bottleneck. Practically always, it comes down to resources (in RAM) being locked by one thread (/process), and the queue of other threads for this resource builds up. Lots of developers never analyze their locing of resources, but rather, "to be on the safe side" holds locks throughout lengthy operations, across disk accesses or network interactions, thereby blocking others out. This is the main cause of systems going into a crawl. Besides, you still see lots of programmers running in busyloops waiting for the resource to become released; that certainly doesn't improve the situation!

It certainly is possible to set up demos to "prove" that paging is a problem, such as processing matrices with a few billion floats, in operations addressing every element. If RAM isn't big enough to hold the entire matrix, plus the other matcix or vector that it is multiplied with, then you even have an easily reproducible case - it will always be slow as molasses.

You can set it up "to prove your point". Like proving the Pope to be Catholic. When a systems comes to a crawl is somethng very different, that does not have the same explanations. It is not "probably that it's swapping faster than the drive can keep up with".

This story about applications crashing on page faults, on which OS was that? I haven't met a single OS this millennium that allows a process to be started without allocating memory for all its segments. If a process then asks "give me more! I need it for my heap!", the OS says "Sorry, there isn't that much space left, not even in virtual memory", but the application ignores the error and goes on using an invalid memory address (usually zero), then it causes a segment violation and usually crashes. (If it couldn't handle an out-of-memory condition, it probably couldn't handle a segmentation fault gracefully, either!)

This has nothing to do with delays from the paging mechanism. In your case, a sufficiently large virtual memory and a paging system would problably have solved the problem. Secondary problems might have to to with the OS not doing a proper cleanup (I suppose it is well known that early versions of Unix had an "out of memory" error message that was never displayed - the routine to print it out crashed becase it called new() and there was no memory available...). Most such problems have been solved today, but if two applications share data structures, one of them crashing could easily lead to inconsistencies causing the other one to crash as well. As long as an OS allows applications to share data, there is no way to prevent that!

(One of the main reasons why Unix early got a reputation for being rock stable is that you had no way whatsoever to share data in memory, no semaphores or other synchronization mechanisms that could deadlock - each process lived in its closed container, not that different from the Docker containers we have today.)
GeneralRe: 8GB no longer enough Pin
objectvill27-Aug-19 1:54
Memberobjectvill27-Aug-19 1:54 
GeneralRe: 8GB no longer enough Pin
Member 798912227-Aug-19 5:07
MemberMember 798912227-Aug-19 5:07 
GeneralRe: 8GB no longer enough Pin
Member 798912228-Aug-19 10:04
MemberMember 798912228-Aug-19 10:04 
GeneralRe: 8GB no longer enough Pin
#realJSOP26-Aug-19 0:42
mva#realJSOP26-Aug-19 0:42 
GeneralRe: 8GB no longer enough Pin
raddevus26-Aug-19 1:54
mvaraddevus26-Aug-19 1:54 
GeneralRe: 8GB no longer enough Pin
#realJSOP26-Aug-19 2:30
mva#realJSOP26-Aug-19 2:30 
GeneralRe: 8GB no longer enough Pin
Dan Neely26-Aug-19 3:47
MemberDan Neely26-Aug-19 3:47 
GeneralRe: 8GB no longer enough Pin
AnotherKen26-Aug-19 6:01
professionalAnotherKen26-Aug-19 6:01 
GeneralRe: 8GB no longer enough Pin
Reelix26-Aug-19 7:38
MemberReelix26-Aug-19 7:38 
GeneralRe: 8GB no longer enough Pin
raddevus26-Aug-19 7:47
mvaraddevus26-Aug-19 7:47 
GeneralRe: 8GB no longer enough Pin
Member 289602026-Aug-19 10:12
MemberMember 289602026-Aug-19 10:12 
GeneralRe: 8GB no longer enough Pin
raddevus26-Aug-19 10:35
mvaraddevus26-Aug-19 10:35 
GeneralRe: 8GB no longer enough Pin
Daniel Wilianto26-Aug-19 16:22
MemberDaniel Wilianto26-Aug-19 16:22 
GeneralRe: 8GB no longer enough Pin
Member 1391078329-Aug-19 9:21
MemberMember 1391078329-Aug-19 9:21 
GeneralWin10 Popup seems so fake! Pin
raddevus25-Aug-19 10:51
mvaraddevus25-Aug-19 10:51 
GeneralRe: Win10 Popup seems so fake! Pin
OriginalGriff25-Aug-19 11:05
mveOriginalGriff25-Aug-19 11:05 
GeneralRe: Win10 Popup seems so fake! Pin
raddevus25-Aug-19 11:18
mvaraddevus25-Aug-19 11:18 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.