Windows Server 2003
4 gig memory
dbisam 4.25 Build 5

I have a client that received this error message: DBISAM Engine Error # 11279 An unknown error ('Access violation at address 004CA103 in
module 'dbsrvr.exe'. Read of Address 00000008') occurred with the connection to the database server at ... please check the server log.

In the log:

4/17/2008 2:42:43 PM [ERROR] Engine error [Access violation at address 004CA103 in module 'dbsrvr.exe'. Read of address 00000008] [Client
Version: 4.25
4/17/2008 2:45:03 PM [ERROR] Engine error [Access violation at address 004CA103 in module 'dbsrvr.exe'. Read of address 00000008] [Client
Version: 4.25
4/17/2008 2:45:47 PM [ERROR] Engine error [Out of memory] [Client Version: 4.25 User Name: XXX Address: XXX.XXX.XXX.XXX Encrypted: No
Request: REQUEST_OPENCURSOR Thread: 4064 Session: 1448970248]

Several more out of memory and Access violations referencing the same address.

Recently, the application is streaming blobs which have increased memory consumption. However, when this occurred, the dbsrvr was consuming
around 1,044,388 K. The server has 4 gig of memory and at the time of error was consuming less than 2 gig total (I believe).

I am not an os guru. I have tried to read about memory utilization by windows server 2003 and I am a bit confused on what the actual limits are.
I am aware of the 4 gig limit on a 32 bit os, which this is. I have seen references to 2 gig application limits without a 3gb switch set, etc... In the
end, I just need to know if the above is an honest out of memory error or not, and either way, is there a solution.

This has happened several times in the last few weeks. My next step was to try 4.26 since it has FastMM built in and see if that helps.

Any help would be appreciated.

Vincen,

<< I am not an os guru. I have tried to read about memory utilization by
windows server 2003 and I am a bit confused on what the actual limits are. I
am aware of the 4 gig limit on a 32 bit os, which this is. I have seen
references to 2 gig application limits without a 3gb switch set, etc... In
the end, I just need to know if the above is an honest out of memory error
or not, and either way, is there a solution.

This has happened several times in the last few weeks. My next step was to
try 4.26 since it has FastMM built in and see if that helps. >>

I would start with trying FastMM and see if that helps the situation.  It
sounds like you've got an address space fragmentation issue, which FastMM
may be able to help with in ways that the old DBISAM memory manager might
not have been able to do.

--
Tim Young
Elevate Software
www.elevatesoft.com

I have tried using 426b2, what I found was interesting. As more users logged in, at some point, the application slowed considerably. I cannot
pinpoint a certain # of users nor memory usage (although memory usage was relatively low). But it slowed considerably. After several reboots
and restarts, we still saw the same problem. Eventually, we moved back to 4.25 b5 and the slowdown went away, everything is running back at
normal speed. Both DBISAM servers are straight out of the box.

I am going to try again tomorrow with 4.26 b2 and see if we get the same results.

Back to the original message, which included access violations:

4/17/2008 2:42:43 PM [ERROR] Engine error [Access violation at address 004CA103 in module 'dbsrvr.exe'. Read of address 00000008] [Client
Version: 4.25
4/17/2008 2:45:03 PM [ERROR] Engine error [Access violation at address 004CA103 in module 'dbsrvr.exe'. Read of address 00000008] [Client
Version: 4.25

Do you believe these to be caused by possible memory fragmentation?

Could this have resulted in corruption? This particular site has historically had more corruption than most of the others. All clients run in c/s mode.

Could any of this be related to the pinging issue that was corrected in 4.25
b6? We do have pinging turned on.

Vincent,

<< Could any of this be related to the pinging issue that was corrected in
4.25 b6? We do have pinging turned on. >>

Not that I can see, no.

--
Tim Young
Elevate Software
www.elevatesoft.com

Vincent,

<< I have tried using 426b2, what I found was interesting. As more users
logged in, at some point, the application slowed considerably. I cannot
pinpoint a certain # of users nor memory usage (although memory usage was
relatively low). But it slowed considerably. After several reboots and
restarts, we still saw the same problem. Eventually, we moved back to 4.25
b5 and the slowdown went away, everything is running back at normal speed.
Both DBISAM servers are straight out of the box. >>

The only difference I can see is that 4.26 is using FastMM4 instead of the
DBISAM memory manager.  You could test to see if this is related by
re-compiling the 4.25 server with FastMM4 instead.  However, I don't think
you'll see worse performance with FastMM4 - it should be quite a bit faster
than the DBISAM memory manager.

Back to the original message, which included access violations:

<< Do you believe these to be caused by possible memory fragmentation? >>

They would be if a memory allocation fails.

<< Could this have resulted in corruption? This particular site has
historically had more corruption than most of the others. All clients run in
c/s mode. >>

AVs won't cause corruption unless they occur during a critical portion of an
insert/update/delete or commit.  If they do occur in that area of the code,
then yes, they could cause issues.

Do you have the full server logs for these errors ?  I can't see any request
information in the two lines that you included.

--
Tim Young
Elevate Software
www.elevatesoft.com

We started the client on 4.26 b2 again last night so that this morning everyone would be using it and was told by some users that it was "slow"
from when they first logged in. By this, they mean things such as searches, not necessarily the actual act of logging in.

Within a couple of hours, we had to revert back to 4.25 b5. No speed problems reported as of yet. I did notice in the log that there were several
Error # 10227's that showed up. I looked at an older log from 4.25 b5 and could not find any 10227 in it, that log covered 3 days. So far, I know
of at least 2 times that 10227's showed up within a hour or two when using 4.26 b2.

I have no idea if this information would help in diagnosing why the response appears to be slower on this version or not. I was able to log into the
application and see the slow response times on one of our searches, at least 3-5 times slower, up to 9 seconds. This is not a query, rather tables
using setranges, etc...

This could be coincidence, however, with each "test" of using 4.26, the results have been the same, eventual (if not immediate) slowdown. When I
run our application on my pc using 4.26 b2, I see no speed problems, and I am not sure if they really do either until the number of users goes up.
The number of users can range up to 70.

Vincent,

<< We started the client on 4.26 b2 again last night so that this morning
everyone would be using it and was told by some users that it was "slow"
from when they first logged in. By this, they mean things such as searches,
not necessarily the actual act of logging in.

Within a couple of hours, we had to revert back to 4.25 b5. No speed
problems reported as of yet. I did notice in the log that there were several
Error # 10227's that showed up. I looked at an older log from 4.25 b5 and
could not find any 10227 in it, that log covered 3 days. So far, I know of
at least 2 times that 10227's showed up within a hour or two when using 4.26
b2. >>

There shouldn't be any difference with respect to any 10227 errors between
4.25 and 4.26.  The number of changes between the two versions are extremely
small, and you can see them here:

http://www.elevatesoft.com/incident?action=reported&category=dbisam&release=4.25&type=F
http://www.elevatesoft.com/incident?action=addressed&category=dbisam&release=4.26&type=F

Are you sure that nothing external has changed at all ?

<< I have no idea if this information would help in diagnosing why the
response appears to be slower on this version or not. I was able to log into
the application and see the slow response times on one of our searches, at
least 3-5 times slower, up to 9 seconds. This is not a query, rather tables
using setranges, etc... >>

You're saying that a SetRange in 4.26 is taking 9 seconds, whereas in 4.25
it's fine ?

<< This could be coincidence, however, with each "test" of using 4.26, the
results have been the same, eventual (if not immediate) slowdown. When I run
our application on my pc using 4.26 b2, I see no speed problems, and I am
not sure if they really do either until the number of users goes up. The
number of users can range up to 70. >>

Did you try compiling the 4.25 server with FastMM4 ?  That is the only thing
that changed in 4.26 that could possibly account for such an issue, but I
would need to have you try it because I can't replicate your environment
here.

--
Tim Young
Elevate Software
www.elevatesoft.com

<<There shouldn't be any difference with respect to any 10227 errors between
4.25 and 4.26.  The number of changes between the two versions are extremely
small, and you can see them here:

http://www.elevatesoft.com/incident?action=reported&category=dbisam&release=4.25&type=F
http://www.elevatesoft.com/incident?action=addressed&category=dbisam&release=4.26&type=F

Are you sure that nothing external has changed at all ?
>>

I have looked at the above links before and  could not see anything that would lead me to believe
that there was anything different that would cause the issues we are seeing either.

As far as anything changing, if you recall, we are able to switch back and forth between the 2 servers
and see the problem with 4.26 vs 4.25 (At least what currently appears to be a problem).
To the best of my knowledge, when this switch happens, that is the only change being made to the
environment.

<<You're saying that a SetRange in 4.26 is taking 9 seconds, whereas in 4.25
it's fine ?
>>

Not necessarily just a setrange. The search involves a setrange and then findkeys on other tables that
together are used to populate a memory table. In addition, the slow down
did not appear to me at first. When the 4.26 server is first started, the speed is fine. It is only
after some time (and/or an additional 30+ users) that the slowdown is observed.

<<Did you try compiling the 4.25 server with FastMM4 ?  That is the only thing
that changed in 4.26 that could possibly account for such an issue, but I
would need to have you try it because I can't replicate your environment
here.>>

I just did but will not be able to put it in place until tomorrow. This should at least
rule in or out FastMM having anything to do with the issue.

Thanks for your help.

Vincent,

<< As far as anything changing, if you recall, we are able to switch back
and forth between the 2 servers and see the problem with 4.26 vs 4.25 (At
least what currently appears to be a problem).  To the best of my knowledge,
when this switch happens, that is the only change being made to the
environment. >>

Yeah, I knew that you were only changing the server, but I sometimes have to
ignore certain things and ask again just to be sure.

<< I just did but will not be able to put it in place until tomorrow. This
should at least rule in or out FastMM having anything to do with the issue.
>>

Yes, that would be very much appreciated.  Please let me know what you find
out.

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com