AS Temp Files growing large

[Timjr56]

Hello,

I have a question about some files that are being created by Appserver/Progress.

There are files that are being created within the directory of our appserver (C:\OpenEdge\Wrk\<versionNumber>\), and they are starting to grow (what seems to me) excessively large (See chart below). My question is what exactly are these files and why are they not being deleted/trimmed when the broker/agent is finished with them? Is there a certain property that must be set in order to automatically get these files to stay at a reasonable size?

FileName --> Size
DBIO4500 --> 132,928KB
DBIO4824 --> 806,720KB
DBIO5788 --> 721,312KB
DBIO7248 --> 23,620KB
DBIO8560 --> 467,936KB

There are about 5 more files all about 30MB large. To me they seem like agent temp files, but I don't want to make this assumption and I figured I would ask you guys .

Any help would be great!

 

[jongpau]

Hi,

Those files are "work" file of your appserver sessions (normal 4GL clients also create files like these by the way). They are used to store temp-tables and do sorting and all sorts of other beautiful stuff. And nope, as far as I know Progress does not waste any time truncating them, except when your appserver agent stops. Progress sessions always create these files. When just starting they are small and depening on use they get bigger when required. The fact that you have some larger ones there probably means that an appserver session has had to do something with a large quantity of temp-table data. This can be very normal behaviour (for instance if some report data needs to be gathered and sent to the client) but it can also indicate a bit of a problem with your application (maybe some program "sends" way too much data to the client or even some program that sits in some endless loop filling a temp-table. I guess you will just have to monitor if and when this occurs a lot. If you need to get rid of these temp-files, just shut down the appserver agent that is associated to the files and they should be cleaned up. If the files are of appserver sessions that have died you should be able to just delete the files.

 

[comatt1]

Hello,

I have a question about some files that are being created by Appserver/Progress.

There are files that are being created within the directory of our appserver (C:\OpenEdge\Wrk\<versionNumber>\), and they are starting to grow (what seems to me) excessively large (See chart below). My question is what exactly are these files and why are they not being deleted/trimmed when the broker/agent is finished with them? Is there a certain property that must be set in order to automatically get these files to stay at a reasonable size?

FileName --> Size
DBIO4500 --> 132,928KB
DBIO4824 --> 806,720KB
DBIO5788 --> 721,312KB
DBIO7248 --> 23,620KB
DBIO8560 --> 467,936KB

There are about 5 more files all about 30MB large. To me they seem like agent temp files, but I don't want to make this assumption and I figured I would ask you guys .

Any help would be great!

I would agree with jongpau on this, it sounds like a code problem; especially if these exist after the connection is closed.

It may be a good idea to do a Progress debug on the code.

----

However, I would think more information is needed:

Do you see any abnormal BI growth?
How long are these files intact?
Are you running stateless appbrokers?
Does each server agent create a -new- file, or do these continually grow?
Do you encounter this issue all the time?
What version of Progress/OS?

-----

Look at your locking tables to review if the locks are released using the process id. ->Promon R&D 1/4/3 should show activity.

----

There are procedures to trim the appservers to see if the temp-table sessions clear up (without affecting production).

asbman -i <broker> -port <port#> -trim <integer of servers to trim>

check to see if these files still exist - if they do, there is a problem. If the appbroker doesn't respawn those servers do this:

asbman -i <broker> -port <port#> -s <integer of servers to spawn>

You can do all this without having to bring down the appservers.

----

If you are using dynamic temp-tables there can occassionally be issues with marshalling of these temp-tables; however, the code is generally the cause of appbroker issues in my experience.

 

[comatt1]

Also, try turning up your Appserver logging to level 4, this may give you more information to provide us/support/whatever.

 

[Timjr56]

----

However, I would think more information is needed:

Do you see any abnormal BI growth?

How long are these files intact?
They are there til I stop the server agents (and if the server agents are hanging, I have to manually delete them)
Are you running stateless appbrokers?
No, currently I am using a state-aware appserver.
Does each server agent create a -new- file, or do these continually grow?
Yes, each server agent creates its own file.
Do you encounter this issue all the time?
This I can not answer, due to the fact that I really haven't noticed it before.
What version of Progress/OS?
10.1B on a 2003 Windows Server.

-----

If you are using dynamic temp-tables there can occassionally be issues with marshalling of these temp-tables; however, the code is generally the cause of appbroker issues in my experience.

I do use Dynamic temp-tables quite often within my code, so I will look into seeing make sure there are no leaks, as well as making sure all the widget pools are being deleted properly.

Thank you for your help on this one guys.

 

[tamhas]

You also might want to check out this PSDN thread
http://www.psdn.com/library/thread.jspa?threadID=12640&tstart=0
Could be nothing abnormal about it ...

 

[comatt1]

I do use Dynamic temp-tables quite often within my code, so I will look into seeing make sure there are no leaks, as well as making sure all the widget pools are being deleted properly.

Thank you for your help on this one guys.

Here where I work we encountered an issue with superceding products.

Product A -> Product B -> Product A ; the programmers never accounted for our sales staff incorrectly entering superceding products.

----

Since Progress doesn't check for infinite loops, I would check out (in Promon -> 5) the # of

Record Creates
Record Updates
Record Deletes

If they are all the same or similar (within a 1 minute interval), it is most likely an issue of code not breaking somewhere within a procedure and constantly undoing/redoing the same transaction.

 

[TomBascom]

DBI files are the overflow from the -Bt buffer.

PROMON has nothing to do with temp-files. Other than adding debugging statements to your code (and hoping that you get it right) there is no way to determine how much temp-table activity you have.

If you see DBI files larger than their initial size (36k for current releases of OE10) then you know that you are creating more than -Bt blocks. And that is about all that you know. You can (try to) make the DBI files stop growing by increasing -Bt.

 

[comatt1]

DBI files are the overflow from the -Bt buffer.

PROMON has nothing to do with temp-files. Other than adding debugging statements to your code (and hoping that you get it right) there is no way to determine how much temp-table activity you have.

If you see DBI files larger than their initial size (36k for current releases of OE10) then you know that you are creating more than -Bt blocks. And that is about all that you know. You can (try to) make the DBI files stop growing by increasing -Bt.

I apologize, I should not have quoted my previous statement about dynamic temp tables.

I was just trying to give different options to investigate.

- Infinite Loops
- or
- Dynamic Temp Table/Memory Leaks

My post should have been more clear.

 

[TomBascom]

No need to apologize -- I just wanted it to be clear that neither PROMON nor any tool can tell you about temp-table activity. Information about temp-tables is kept in a black hole. Progress needs to fix that. It's a bit of a pet peeve of mine

 

[tamhas]

a pet peeve of mine

Got a little zoo of those pets?

 

[TomBascom]

A regular Arc

 

[Manmohan]

I know this is very old thread but its perfect for my question. If i need to open a new thread on this then please advice I will do so.

Question 1: I restarted the databases using -T parameter but:

1) I cant see the -T value displaying in the DB logs at startup. Dosen't it show up there? Where else I can check its value for the DB?
2) I can still see DBI files created in old dir (/tmp). I also changed "/wrk" parameter value in ubroker.properties, but still i can see DBI files in /tmp. Why? What else should i do?

Question 2: I searched for -Bt value in DB logs and startup script so i think it is set to default. I changed it to 20000 (randomly chose this value) in startup script and restarted the DB. I cant see it in DB logs in startup parameter information. Dosen't it show up there? Where else I can check its value for the DB?

Also, how to determine the correct value of -Bt parameter for my Live DB with no non-live env any close to live in scale/load/capacity? Will it eat more RAM?

Env Info:

Progress Version: 9.1E
OS: Solaris 10

 

[jongpau]

Hi Manmohan,

They are client side parameters and have no meaning when starting a db server. That's why
- you don't see anything in the db log, they are ignored
- your files didn't move to the directory set with -T as your client still puts them where it always has

HTH

Paul

 

[Rob Fitzpatrick]

The DBI file is a client temp file whose location is specified by the value of -T on the client command line (e.g. _progres). However the -T does apply on the server side for SQL server temp files. If you don't use OE SQL then -T has no effect for you on the server side.

The -Bt parameter determines how many temp-table buffers are allocated by a client. As Paul indicated, this parameter is also used on the client side, not the server side. If your clients' DBI files are growing beyond the default size (32 KB for 10.2B, not sure about 9.1E) then you are incurring disk I/O on temp-table access which is a potential performance penalty. The sum of the DBI file size and (-Bt * temp-table block size) is the temp-table space being used by your client application. In 10.2B the temp-table block size is configurable (with -tmpbsize) but I have a feeling it was fixed at 4KB in 9.1E; not sure. Basically, if you want to eliminate temp-table disk I/O (given a certain application test) then increase -Bt until your DBI file size no longer grows beyond the default size.

As -Bt is a per-client setting you may have to take into account where the clients run. For example if they are all server-side clients then the effect of increasing -Bt on memory consumption will be a factor of how many clients receive this new setting. Whereas if the clients run on separate machines (fat client architecture) then the per-machine effect is distributed across multiple machines. If the amount of memory used is too great then you may have to reconsider your application design, e.g. reducing the number of TTs you use or the number of records you store in them.

As for obtaining real-world data in test, this will always be an issue if you test on tiny databases and deploy to large ones. You need to do performance tests against data sets of a meaningful size.

 

[Manmohan]

Hello jongpau and Rob. Thanks for your reply.

As i mentioned, i did change the workdir for all brokers and name server in ubroker.properties file. Does this not help?
When you say change at client side then where should i put these variables?

Yes, my brokers and DB sits on same server. Also other batch jobs run from the same box.

I tried to locate -tmpbsize, -Bt in DB parameters as well as in broker properties files but could not locate it.

Even in 9.1E, Bt can range from 10-50000 and -tmpbsize can be put as either 1MB or 8 MB.

 

[TomBascom]

Ordinary client sessions do not use any of the properties files.

App servers and webspeed use ubroker.properties.

If you look at the documentation for any parameter it will tell you what sort it is.

Client parameters are often specified on the client command line right after the executable name (i.e. _progres or prowin32) or in a parameter file specified by -pf filename.pf or in an INI file (-ininame, INI files might also be found by fishing around in the registry if you are running Windows).

Basically it depends on where the client is started and how. If there is an icon that you click on first look at its properties. That will either show the parameters or perhaps reveal a -pf or -ininame being used.