[AccessD] CPU and locks

MartyConnelly martyconnelly at shaw.ca
Thu Aug 31 21:19:58 CDT 2006


Are these file locks, record locks or page locks they are looking at?

Tell them to look at the priority of the threads Access is running.
The are all low priority which are immediately relinguished.
If Microsoft Access is just idling, It does work to read ahead on data,
to fill and refresh the cache, to check on potential multi-user issues.
Even just to watch for a keystoke or a mouse move. It also polls
the windows message queues. Access won't peg out at 100%
in an idle state with nothing else running as the kernel is also
doing it's bit.


 From an old MSKB.

Microsoft Access was originally designed to operate in the cooperative
multitasking environment that Microsoft Windows 3.x provided. The idle
processing code built into Microsoft Access was designed to ensure that
Microsoft Access does not begin processing background tasks during brief 
periods
of inactivity, such as when a user pauses between keystrokes. In the 
preemptive
multitasking environment of Microsoft Windows 95 and  Microsoft Windows 
NT, this
idle processing code causes Microsoft Access to use 100 percent of CPU 
resources
briefly during idle time.


Microsoft Access polls its message queues for activity for about the 
first 30
seconds of idle time. During this time, Performance Monitor reports that
Microsoft Access is using 100 percent of CPU resources.


NOTE: Microsoft Access only uses CPU resources that are idle. If your 
computer
has other processes that are ready to run, it will run them. Microsoft 
Access
does not degrade performance of other applications as it polls its message
queues.




Jim Dettman wrote:

>Steve,
>
><<We (our development team) are scratching our heads.  This is normal for
>Access.  It grabs as much resources as it can get to perform data access
>requests.  And I've never heard of a server blowing up from too many
>simultaneous requests.  Windows is designed to handle process threading
>reasonably well, putting things in  order, assigning priorities, reserving
>some CPU for critical processes, etc.>>
>
>  Yup that's normal and as you said, it yields to other processes.  As long
>as there is nothing else, it will take what it can get.  In fact, to back
>this up, there is a MSKB article out there because so many thought is was
>"abnormal" to see Access use 100% of the CPU.
>
>
><<....they note that most of the MS Access item in this view are showing
>large numbers in the "# of Locks" column.  Ranging from 15 to 42 each.  This
>is something I can't explain.  It's a standard FE/BE deployment, so an ldb
>gets generated at both the FE and BE levels.  But what is this huge number
>of locks?  Stranded ldbs?  Some calculus involving the number of
>simultaneous users?  I told them I'd explore what this meant..>>
>
>  Large numbers?  15 to 42 is nothing; it's a database product, it's
>supposed to lock things (and lots of them).
>
>Jim.
>
>
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Capistrant
>Sent: Thursday, August 31, 2006 4:41 PM
>To: Access Developers discussion and problem solving
>Subject: [AccessD] CPU and locks
>
>Dear List,
> 
>We have an Access 2000 app that has been running for years at a customer's
>site, provided to 100 users via Citrix profiles.  In daily practice, there
>are usually 5 to 15 people logged in at any given time.
> 
>The techies running the server are belly-aching about resource utilization.
>They note that CPU utlization per user zips up to 25% or 30% of server
>capacity when they perform routine actions (like applying filter rules to
>search on a form).  It drops down to zero after a second or two.   But they
>say "do the math" -- just 4 users doing stuff is going to completely max out
>our servers.  
> 
>We (our development team) are scratching our heads.  This is normal for
>Access.  It grabs as much resources as it can get to perform data access
>requests.  And I've never heard of a server blowing up from too many
>simultaneous requests.  Windows is designed to handle process threading
>reasonably well, putting things in  order, assigning priorities, reserving
>some CPU for critical processes, etc.
> 
>Nothing's really changed over the years.  Is it just their awareness that
>has changed?  Are these techies just freaking out because they have a new
>Performance Monitoring tool?  
> 
>The other observation they make that might cause overuse of CPU is something
>new to me:  When you look at 
>START > Control Panel > Adminstrative Tools > Computer Management > Shared
>Folders > Open Files....
> 
>....they note that most of the MS Access item in this view are showing large
>numbers in the "# of Locks" column.  Ranging from 15 to 42 each.  This is
>something I can't explain.  It's a standard FE/BE deployment, so an ldb gets
>generated at both the FE and BE levels.  But what is this huge number of
>locks?  Stranded ldbs?  Some calculus involving the number of simultaneous
>users?  I told them I'd explore what this meant..
> 
>Thank you !
> 
>Steve Capistrant
>Symphony Information Services
>scapistrant at symphonyinfo.com
>www.symphonyinfo.com
>Main: 763-391-7400 ext 801
>Toll Free: 888-357-1373 ext 801
>Direct:  612-237-0075
>
>
>  
>

-- 
Marty Connelly
Victoria, B.C.
Canada




More information about the AccessD mailing list