Hi everyone:

I got performance problems with my installation on an Compaq Alpha-Digital using the true64_Unix:

There it goes the details:

Hardware: Compaq AlphaServer 4100
RAM: 1GB
Processors: 2 466MHz processors
O.S.: OSF1 V5.1 R.735
Database: Oracle 8.1.6.0.0
Baan version: Baan IV c4
Porting set: 6.1c.06.02
Concurrent users: 30

db_resource:

dbsinit:01
rds_full:40
ora_init:0111000
ssts_set_rows:3
ora_max_array_insert:25
ora_max_array_fetch:25
bdb_max_session_schedule:7
max_free_cursors:50
retained_cursors:40
lock_retry:0
ora_timeout:{60,60,60,60,60}
two_task:maresa00.com
nls_lang:AMERICAN_AMERICA.UTF8
nls_sort:binary
ora_default_tablespace:datspace
ora_temporary_tablespace:temp
ora_column_format:8
ora_client_home:/oracle/oracle/product/8.1.6


Does anyone has a Dec with Baan? Can you send me the values of the init_BaanIV.ora, db_resource and kernel parameters for this installation, pls?

I have checked the followind documentation:

U7016eus
U7028bus
U7032aus
U7155aus

The thing is that these documents are too old as well as for the oracle version as for the O.S. version.

Thanks in advance
Xavier

:)

Xavier,

Can you please specify in which area's you have problems?

han

Are you using ADFS?

There are some major problem interactions with 8.1.6.0.0 and Tru64 5.1. We have now seen this at several sites especially where ADFS is in use. In one case the customer had to downgrade back to previous version of the OS.

What specific problem are you having?

The problem I describe above manifests itself as very poor performance when more than 30-40 users are on the system, CPU util < 40%, IO occasionally peaks and Oracle is waiting on IO.

-- Jim

Hi Han & Jim:

Thanks for your interest.

We do not have performance problems with the interactive sessions, at least the users don't complaint. :o)

We do have problems with the batch processing sessions. When they are started, besides that they take too long, the system becomes very slow and of course, affects the hole system, even the interactive sessions. The following sessions are the ones we have problems with:

timrp1210m000 - Generate Planned MRP Orders
tisfc0204m000 - Release Production Orders
tisfc0102m000 - Report completed Operations
tisfc0220m000 - Process Backflusing
timrp1250m000 - Transfer Planned MRP Production Orders
timps5260m000 - Transfer Planned MPS Production Orders
tfgld4201m0000 - Integration Transactions to Finance Transaction

These sessions take at least 2 days to complete their processing.

We have problems even with the tools sessions ttiex1485m000 and ttiex1488m000. The session seems to be hunged up and I'm importing just one session.

Jim, if you mean by ADFS, Advanced File system (ADvFS), the answer is yes!!. :o(

Thanks in advance for your help
Xavier

Mke sure that you have this in your sysconfigtab


vfs:
fifo_do_adaptive=0

also, you can upgrade to 8.1.7 and use Direct IO with True64 5.1.

Thanks Naabi0.
Yes, I'm ussing that parameter in the sysconfigtab. :(
Xavier

Please check the following:

- have you analyzed your tables/indexes?
- have you already tried to trace a slow session with ORAPROF=0.0, TT_SQL_TRACE=0200, SQL_TRACE=true?

Do you run in host mode?
What version of Baan are you using?

Rgrds,
Han

Xavier,

Since you have TWO_TASK set you must be running Client/Server (possibly still on the 1 server). It is a good idea to also check some of the network related parameters:

EPC_DISABLED (db_resource/tabledef6.1)
SDU/TDU (listener.ora/tnsnames.ora)
TCP.NODELAY (protocol.ora)

I would definatively also run a trace on some the problem sessions. Since you are running jobs at the same time with the interactive session you may have some concurrency issues in your database.

Hi Han & PATVDV:

I'm running BaanIVc4 in a host mode.

I will check out those network variables in order to disable them
Thanks,
Xavier

Xavier,

You shouldn't all disable them but check corresponding values:
EPC_DISABLED = TRUE
SDU = 8192 (or 16384)
TDU = 8192 (or 16384)
TCP.NODELAY = YES

A few questions:
- Have you compared these times with previous installations?
- Have you done tests with a smaller package size between bshell and driver and driver and database? If not, try to specify:

rds_full:2
ora_max_array_insert:1
ora_max_array_fetch:2

Hope this helps,
Dick

we changed from 2-tier to 3-tier
with same result:
-session start on app.-server faster
-problems with batches and long-running-sessions
30-50 % slower than 2-tier-mode

os:dig-ux4.0f
db:7.3.4

any ideas for reasons ?

thanks a lot

Ah: it is DEC! Have you tried the following:

FIFO-DO-ADDAPTIVE
In Tru64 pipes are optimized for the traditional UNIX piping mechanism. To
change the IPC behavior from tuned for throughput (bandwidth) to low latency
messaging the parameter fifo-do-adaptive has been introduced.
It needs to be disabled (set to zero) for Baan:
vfs:
fifo-do-adaptive = 0

One threads up here you can download the kernel guide. This document contains this and other steps on how to improve performance for a DEC.

Kind regards,
Dick

yes , fifo_do_adaptive is set in the kernel

i tried also to set SDU / TDU to 8192

my last chance ist tcp.nodelay=true

but it seems a baan-problem, because sql-plus has
the same speed, from app-server, and from db-server

Just for grins,

One of my customers in the US experienced much the same problem --- they tried using the Oracle 7 driver and the problem did not show up with the older driver. Now you cannot do this as you have ora_column_format set to 8 which implies that when you upgraded you did a bdbpre/post.

How did you upgrade from 7 to 8?

When you say that fifo-do-adaptive is set do you mean set to zero?

-- Jim

you mean, i should use oracle 8 driver with oracle7- database ?

i did not upgrade to 8 yet, i still use 7.3.4.

i set fifo-do-adaptive=0.