Jim Dettman
jimdettman at verizon.net
Mon Sep 28 15:21:25 CDT 2009
<<It is unlikely to be swapping which means (implies) code swapping in and out. >> No, that applies to data structures as well, not just code. Your thinking of a process swap. Every process has a working set. That is a number of pages that it can have at one time. If it runs out of pages in it's working set, it puts one on the modified page stack and then grabs a free one. If it needs that first page back, it has to swap another page to the page stack, then can call back that first page. This is a soft fault as the page is still in memory. If enough memory gets consumed to the point where there is little free pages left, the modified page list is written out to the page file. If a process needs a page back and it's out on disk, that is a hard (and expensive fault). On top of that is the process handling, which depends on a number of factors. If the system starts to run out of slots, it may swap out an entire process that is waiting for I/O. That's the reason you check CPU first, then memory, then I/O. Each dovetails into the next. Too little memory and lots of swapping for example can make you think you have an I/O problem when you really don't Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Monday, September 28, 2009 3:29 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] [dba-VB] [dba-SQLServer] HELP,server completely unresponsive It is unlikely to be swapping which means (implies) code swapping in and out. It could be SQL Server thrashing the disk. That still should not lock up the screen though. There is 4 gigs of ram left for the remaining CPU and any applications running on that core. In this instance there is nothing else running other than Windows Explorer. I am simply saying that it is the job of the OS to efficiently manage it's resources. I can see "thrashing" slowing down THAT APPLICATION, however to allow one application to lock the entire computer up is unconscionable. Again this is 2009, and a SERVER OS. It's not like they haven't had 10 years to get this stuff right. The OS is suppose to manage the applications. The applications are NOT suppose to manage the OS. And the USER is not suppose to manage any of this. Obviously they haven't gotten it right. John W. Colby www.ColbyConsulting.com Shamil Salakhetdinov wrote: > Hi John, > > Could that be a swapping issue or trashing (computer science term)? > > http://en.wikipedia.org/wiki/Paging#Performance > <<< > Virtual memory systems work most efficiently when the ratio of the working > set to the total number of pages that can be stored in RAM is low enough to > minimize the number of page faults. A program that works with huge data > structures will sometimes require a working set that is too large to be > efficiently managed by the page system resulting in constant page faults > that drastically slow down the system. This condition is referred to as > thrashing: pages are swapped out and then accessed causing frequent faults. > > http://en.wikipedia.org/wiki/Thrash_(computer_science) > > -- > Shamil > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Monday, September 28, 2009 10:00 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] [dba-VB] [dba-SQLServer] HELP, server completely > unresponsive > > I hear ya. > > My problem with all of this is that Windows should handle this gracefully. > I am not an OS kinda guy > but logically there is just no way that SQL Server tying up the disk drives > (I/O)should freeze up > the screen redraw. I have limited SQL Server to 3/4ths of the memory (12 > gb) and three processors. > > The remaining processor and 4 gigs of ram should be capable of running > pretty much anything. It is > after all now a single core machine with 4 gigs of ram. Why in the world > can't it handle moving the > mouse cursor? This is Windows 2003 for goodness sakes, not Windows 95, AND > this is the year 2009, > not 1995. A quad core 3ghz machine with 16 gigs of ram should NEVER lock > up. EVER! > > And I as a user should not be hunting down why this is happening. > > BTW did you see the notice that XP will not receive any more service packs > and NEITHER WILL WINDOWS > 2003. > > John W. Colby > www.ColbyConsulting.com > > > Jim Dettman wrote: >> Take a look at the memory consumption. >> >> A stalled/un-responsive system is either: >> >> CPU bound >> Memory bound >> I/O bound >> >> A problem with any one of those will cause the same thing. >> >> You've already checked off the top one. Now move down to the next. If > on >> task manager you have plenty of free physical memory left, then take a > look >> at the I/O (Disk Queue length in the performance counters is a good > measure >> if your I/O system is falling behind). >> >> If you don't have any physical memory free, then you system is spending > a >> lot of time swapping processes in and out. >> >> And of course if it's I/O bound, then it's spinning its wheels waiting > for >> I/O to finish and probably servicing a ton of interrupts. >> >> With the size of the databases your working with and the processing your >> doing, my guess will be that your I/O bound. SQL does a fairly decent job >> of tuning itself for memory. >> >> Jim. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com