Shamil Salakhetdinov
shamil at smsconsulting.spb.ru
Mon Sep 28 14:10:45 CDT 2009
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 __________ Information from ESET NOD32 Antivirus, version of virus signature database 4465 (20090928) __________ The message was checked by ESET NOD32 Antivirus. http://www.esetnod32.ru