Hello all, Over the past year, there has been a general slowdown on Attain Clients on all PC’s. We use Attain 3.01A. The clients are a mix of Win98, 98SE and 2000 SP4 machines, 300 - 450MHz and 128MB RAM, with IE6SP1 and all windows updates installed.
quote:
Object and DBMS cache = 8000
The server:
quote:
IBM NetFinity x230 Series e-server Windows 2000 SP2 512MB RAM RAID 1 Swap file: 768 - 1536
Currently the Database used is 5899312/7500000 (79%) - I try to keep it from going over 85% by expanding.
quote:
DBMS Cache = 332800 Object Cache = 8000
All NICs are 10/100 3Com 3C90X, and the switch is a 3Com 10/100 SuperStack 3300. Typically no. of connections would range from 16 - 26, a lot of clients running two sessions of Attain at the same time (as we have two companies). The database is spread out over three hard disks as follows:
quote:
D: 500000 E: 500000 F: 6500000
All drives, including C: are NTFS formatted. McAfee NetShield 4.5 SP1 and other updates are also installed. Bar a few other utilities (RAID Manager, Atomic TimeSync, Veritas 8.6), nothing else really is critical on this server. It appears that drive F: is constantly expanding and not increasing the other files proportionately, so most of the activity is happening here, I believe. I was told that if any of the files go over 4GB, then the database is not ‘efficient’. What I want to do is try to optimise the database and caches on both the server and clients. I believe that there is some formula that allows me to select the cache sizes on the server and the clients, based on their hardware and memory configurations. Anyone have any ideas on how I can do this? How can I displace more work on the other drives by expanding those files? I just want to be informed. Regards Stephen
First off, when you expand your database are you clicking the “advanced” button? If you do, you can choose which drives to expand. Also, as far as performance goes, is it all the time or periodic? If its periodic, you should try to track it down while its slow. Somewhere (don’t know if its on this site or another) there is some Navision “freeware” (Navision Objects) called “User Disk Monitor.” It will help you find the culprit(s) slowing things down. I my experience there are two main causes for periodic performance problems. The first is some process has filled the cache (i.e. a batch billing process) or someone is running a report or applying a filter to a screen using a field that is not part of the active key. You might want to add some more RAM and increase the cache for good measure…
Stephen we have very similar system to yours. What did help a lot in terms of performance is to move clients’ OS from Windows 98 to 2000 and now to XP. Clients just stopped complaining. I am also in the middle of converting to 8 hard drives (4x2) RAID-1 system with nothing running on a stand alone Navision server except for OS and Navision (3.01) itself. Search this forum and you will find great recommendations Good luck!
Denis, Why don’t you seize the opportunity and migrate your server/client programs to the latest 3.70 build? Since you will replace/upgrade the server machine, you could also get the benefits of running the most recent executables.
From my experience slow clients (slow connection and/or slow client PC) are in many cases the reason for bad performance of the whole system.
It appears you cn do many things to help your speed-Upgrade your OS, improve the PC’s, But In this case the database is not optimized and spread over 3 drives unevenly
quote:
The database is spread out over three hard disks as follows: D: 500000 E: 500000 F: 6500000
Scenarios: 1. Creating a new database and restoring data. 2. Expanding existing parts of a database 3. Expanding using existing and newly created parts of a database 4. Fixing a ‘non optimized’ database. 1. Creating a new database and restoring data If you create a new database that is spread over several disks, you must close and reopen the database before restoring data. This will recover the ‘List of Free Blocks’ and the restored data will be equally spread over all disks, thus securing the optimal performance. To spread the data equally over the new database, you must follow these steps: Create a new database and expand it with database parts of the same size Close and reopen the database (rebuild ‘List of Free Blocks’) Restore the backup. 2. Expanding existing parts of a database If you expand existing parts of a database that is spread over several disks, you must close and reopen the database before using it again. This will update the ‘List of Free Blocks’ and secure the optimal performance. Expand all database parts with the same size Close and reopen the database (rebuild ‘List of Free Blocks’). 3. Expanding using existing and newly created parts of a database If you expand a database by one or more new database parts on new disk(s), you should follow the correct procedure (D). If you haven’t done so, you must at least close and reopen the database so that Navision recognizes the new disk(s) and starts using it . If you don’t close/reopen, it will continue to use the old ‘List of Free Blocks’ and will take some time before the list wraps around and starts using the new disk(s). The database is now ‘non optimized’, because data is not spread equally over the disks. Procedure (D) tells you how to fully optimize the database. 4. Fixing a ‘non optimized’ database To spread the data equally over all parts of a database, follow these steps: a. Make a Navision backup b. Delete the database c. Create a new database with the required parts of the old database d. Close and reopen the database (rebuild ‘List of Free Blocks’) e. Restore the backup. This procedure is the optimal way of adding a new database part, but it is also the most time consuming.