Tim

I have been checking the monitor diagnostics in Windows 2008 Server and
realize that the process dbsrvr is reported with almost 1500 memory hard
fault/minutes.

I have checked Microsoft site and encontered this:

The number of hard faults per minute that are currently resulting from the
application instance.

A hard fault (also known as a page fault) occurs when the page of the
referenced address is no longer in physical memory and has been swapped out
or is available from a backing file on disk. It is not an error. However, a
high number of hard faults may explain the slow response time of an
application if it must continually read data back from disk rather than from
physical memory.

The dbsrvr is only accessed by TCP/IP using Cliente/Server model.
DBISAM version: 4.29 build 3
Users connected: 120

Is there something I can do to solve this problems ? Is this a regular
behavior ?

Eduardo

Eduardo [HPro] wrote:

> Is there something I can do to solve this problems ? Is this a
> regular behavior ?

I think a good place to start might be to review and possibly increase
DBISAM buffer/cache sizes.

See the  "Customizing the Engine" section of the manual and
specifically the "Memory Buffer Customizations".

http://www.elevatesoft.com/manual?action=viewtopic&id=dbisam4&product=r&version=2010&topic=Customizing_Engine

Raul

Eduardo,

<< The number of hard faults per minute that are currently resulting from
the application instance. >>

How much memory is on the 2008 Server ?  I would see about increasing the
available memory on that machine, and that will help cut down on the page
faults.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

There is 8Gb in this server.

The configuration of machine is a dual processor DELL with a 15000 rpm hard
disk running Windows 2008 Server SP2 (32 bits).

What Raul has suggested is something I can try but it is a good way ?

Eduardo

> There is 8Gb in this server.
> The configuration of machine is a dual processor DELL with a 15000
> rpm hard disk running Windows 2008 Server SP2 (32 bits).

Unless i'm missing something here this one is not a very optimal config
- you can only address 4GB with a 32bit windows.

You can enable PAE but unless your app is AWE aware they won't see or
use it and DBISAM is not AWE aware AFAIK.

Then again if nothing else is consuming lage amounts of RAM the 4GB
should be adequate.

Raul

Eduardo,

<< There is 8Gb in this server. >>

As Raul indicated, a 32-bit application like DBISAM won't be able to address
that much memory.

How much memory is being consumed (at the peak) by the DBISAM Database
Server process ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim and Raul

I agree that 8Gb is not addressed (this is the user mistake when they bought
Windows 2008 Server 32 bits).

But during the day even with 120 users the peak of use is around 500Mb,
sometimes (very rare) it reaches 1Gb.

Last night I have changed the Engine.TableMax??? in dbsrvr project
mutliplying all values to 8 (eight).

The big question is why this is happening ? I have traced the hard fault and
sometimes during the day it reaches 1000 faults/minute. And it is almost
impossible to discover what happens this time.

BTW
I really apreciate your suggestions.

Eduardo

Eduardo,

> But during the day even with 120 users the peak of use is around
> 500Mb, sometimes (very rare) it reaches 1Gb.

In theory at least there is some overhead still available as user mode
virtual address space on 32bit OS is 2GB.

Other question that i did not ask is how busy is the system otherwise -
specifically what is the overall memory utilization and are there other
processes consuming large amounts of RAM? How about CPU activity?

> The big question is why this is happening ? I have traced the hard
> fault and sometimes during the day it reaches 1000 faults/minute. And
> it is almost impossible to discover what happens this time.

It's happening likely because OS has swapped the DBISAM memory out to
swap file and now that we're accessing it it's reading it back in.

As you saw by the Microsoft info you posted originally this is by no
means an error - however the fact that the OS has to read the pages
back in means there is some performance impact for DBISAM as page is
read from disk and made available to dbsrvr. There is not necessarily
anything you can do about it in DBISAM as this is a OS decision to swap
out.

Some hard faults will happen always but i don't know what "normal"
value here might be.


What i would concentrate on is to see if there is memory pressure by
something else at the same time that forces Windows to swap out DBISAM
from ram.


There is 4GB (most likely only 3.1-3.4GB actually only available) so
are there any other apps with large memory consumption (100+MB)?

My only other suggestions are:

1. Are any other apps/services also getting these hard faults? Assuming
OS is swapping DBISAM data in it must be swappign somethign else out
that likely is needed later again.

2. See if changing the DBISAM cache settings has any effect - either
negative or positive.

3. Can you reduce size of the tables ? (for example by archiving some
data) - less data DBISAM has to access should in theory mean less need
to load and process it. I know you probablyare doing this already.

Raul

Raul

The server is basically used only to DBISAM server. There are other services
like backup but they only run at night when there are no users on.

> 1. Are any other apps/services also getting these hard faults? Assuming
> OS is swapping DBISAM data in it must be swappign somethign else out
> that likely is needed later again.
No, just DBISAM server

> 2. See if changing the DBISAM cache settings has any effect - either
> negative or positive.
So far I can´t see any difference, I have changed the cache multiplying
default values to 8.

> 3. Can you reduce size of the tables ? (for example by archiving some
> data) - less data DBISAM has to access should in theory mean less need
> to load and process it. I know you probablyare doing this already.
Unfortunatelly no.

I have been reading something related with FastMM and multicores. The last
version of FastMM (4.97) has some things related with multicores. Next week
I will update the server with this version.

I will update this thread with the news next week.

Regards
Eduardo

Eduardo,

<< But during the day even with 120 users the peak of use is around 500Mb,
sometimes (very rare) it reaches 1Gb. >>

What memory usage are you looking at ?  The dbsrvr process, the Windows OS,
both ?  Remember, what the process uses is not the end of the memory usage -
Windows will use a significant amount of memory for file system buffering.

<< Last night I have changed the Engine.TableMax??? in dbsrvr project
mutliplying all values to 8 (eight). >>

No, don't do that - you're just going to increase the amount of memory used
per session and probably cause more page faults, not less.

<< The big question is why this is happening ? I have traced the hard fault
and sometimes during the day it reaches 1000 faults/minute. And it is almost
impossible to discover what happens this time. >>

Well, keep in mind, page faults by themselves are not necessarily
bad/abnormal events, especially in a high-memory usage situation.  Also,
looking at the total memory usage does not always reflect memory
fragmentation that can occur in the process address space, which can cause
page faults when contiguous blocks of memory cannot be found in the address
space for allocation.

--
Tim Young
Elevate Software
www.elevatesoft.com