Is this good or bad?

A

andben01

New Member
Hi,

our users think the system is slow
when they start in the morning everything works fine, but after some time the system seems to get slower and slower

all users log in with Reflection

The output from R&D looks like this:

12/17/07 Status: Database
09:55:19
Database was started at: 12/15/07 03:50
It has been up for: 54:05:19
atabase state: Open (1)
Database damaged flags: None
Integrity flags: None
Most recent database open: 12/15/07 03:50
Previous database open: 12/15/07 03:50
Local cache file time stamp: 10/31/07 17:45
Database block size: 8192 bytes
Number of blocks allocated: 262141 (0 kb)
Empty blocks: 86889 (33 %)
Free blocks: 82 (0 %)
RM blocks with free space: 12 (0 %)
Last transaction id: 7328682
Highest table number defined: 0
Database version number: 91
Shared memory version number: 9118

File name (KB) (KB)
/usr/opt/appl/Db/PA.db 248 128
/lokal/Bi/PA.b1 32888 512
/usr/opt/appl/Db/PA.d1 3064 128
/usr/opt/appl/Db/PA_7.d1 800120 0
/usr/opt/appl/Db/PA_7.d2 800120 0
/usr/opt/appl/Db/PA_7.d3 24 128
/usr/opt/appl/Db/PA_8.d1 70264 0
/usr/opt/appl/Db/PA_8.d2 70264 0
/usr/opt/appl/Db/PA_8.d3 52728 640
/usr/opt/appl/Db/PA_9.d1 150136 0
/usr/opt/appl/Db/PA_9.d2 150136 0
/usr/opt/appl/Db/PA_9.d3 24 128

12/17/07 Status: Startup Parameters
09:57:50
Maximum clients: 1025
Maximum servers: 4
Maximum clients per server: 0
Lock table size: 20000 entries
Database buffers: 80000 (640000 kb)
APW queue check time: 100 milliseconds
APW scan time: 1 seconds
APW buffers to scan: 133
APW max writes / scan: 25
Spinlock tries before timeout: 50000
Before-image buffers: 100 (800 kb)
Before-image file name: -
After-image file name: -
After-image buffers: 5 (40 kb)

is thereanything special I shall look for?

/anders
 
First of all 9.1D is already old and I think it would be good to go at least to the last servicpack (SP9) since you are now on a clean 9.1D install.

What OS are you on?
Memory?
# of cpu's?

When things get slow, the first thing you should look for is the OS itself. You need to answer the question what causes the performance decrease?
Is it IO, CPU, memory, other processes at the same server, memory leaks, swapping, number of users on the system?
When this is established and the cause is the database then you can look further in that to find the culprit.

Looking at the information given one thing I don't see AI extents, is this because you didn't enable AI? If not you should!!!

How many concurrent users you have during peek time?
It is better to show us also some activity information:
-buffer hits
-checkpoints
-Bi activity
-Ai activity
-performance indicators

Casper.
 
Along with Casper's suggestions you should grab yourself a copy of ProTop.

You should tell us about the server and especially the disk subsystem. And also describe more clearly what precisely is "slow" and how slow it is. Specific measurements of both good and bad times are always very helpful.

I see that you have -n set to 1025 and -Mn set to 4. If you are connecting your users in client/server mode (do your users use -S when they connect?) that would certainly cause things to slow down as more users connect. (Don't just show the PROMON screen -- what are the actual startup parameters for both the server and the clients.)

Is this a commercial application? Or is it homegrown?

No after-imaging? You like living dangerously?

The .st file is very simplistic. For a large active database there are almost certainly significant benefits to be gained by redesigning it.

In general you'd probably save a lot of time and be well served by having a good db consultant come in and work with you for a week or so. But I would say that ;)
 
You must log in or register to reply here.
Back
Top