Dear Sirs, I’m writing to you because we have Navision Financials for almost 3 years and since 1 year ago we are having major problems of performance, neither Navision Portugal nor the 3 Navision Solution Centers could help us to go through this situation. We have 50 users working in Wan with 32kb of bandwitch per user. Users computers are above PII 500Mhz with 64MB Ram We have 1 Server Xeon III 600MHz with 4 processors and 2 gb Ram supporting comunications with citrix metaframe We have a P4 1.4ghz with 2 processors and 2 gb Ram supporting the database in Version 2.6 We already tried Sql server , Attain, and its to slow it takes 15 minutes to register an invoice and print it we make per day mor or less 2000 invoices We are desperate our company is almostg stopping and we don´t know what to do with this. As i said Navision Portugal told us they didn´t know what to do. Last week it was working in a reasnable performance, but we were then dealing with the problem of lack of space, Navision told us to go to attain, didn´t work. We got back to 2.6 with a licen ce that allowed us to go to 64gb, didn´t work. now it´s almost stopping. Please Help us! Thanks a lot for your attention Jose Branco
Hi, on how many drives are the database file splitted up to? Are you having any own development in Navision? Or is it a standard 2.60? Regards Daniel
And what about cache settings and commit cahce on the database server? Please give us som more information and we’ll help You /Lars
Is the system slow in general or only when posting invoices? What are the details of the server’s disk hardware? SCSI? RAID?
Like Lars said - you will have provide some more information. You will have to check out wether the problem is - the server - the application - the network - the users - the CITRIX-Server So … Are there modifications, that might cause the problem? Your NSC should be able to check that out, using tools like client monitor, etc … When the performance went bad - was that after an update or import of new objects or was the decrease of performance a slow process ? Is the server well set up ? - cache-size ? - commitcache activated ? - how many phys. Hdds and how many database-files do you have ? - what kind of Hdds ? - what controller or RAID-Levels ? - other programs running on the server ? - how much Hdd-space is available for temp-files on your server How is the network-connection between the citrix-machine and your database-server ? Take a look at the performance-table. Check out the other virtual-tables, when the system is running. Like the session table: from there you will get a idea what the users are doing on the database (do they read or write in chache, how many records are read, modified, deleted, inserted, …). Then the table “database file”: what is the usage of hard-disks ? Do you have often locking-information in your status-line ? Are there many users do filtering in huge tables, maybe without proper sorting ? If you connect directly to the database without CITRIX, how is the performace then ? How long does it take to post an invoice, if you are connected directly ? Is it cleared, that CITRIX is not the Problem (i’m not a CITRIX specialist …) ? How is the performance if you are alone in the system and run a client directly on the server. Do you have other C/S-Software, that you run over CITRIX ? If so - how does that software perform ? What size ist the database ? What percentage is filled with data ? How big are the biggest tables and how many records are in that tables ? Hey - my lunch break is over and i have to stop asking now 
But that list of questions is far from being complete. That are only the points, that first came to my mind when thinking about navision-performance.
Hi, first of all, thanks a lot for answering. The database file is on one volume that has 4 hard drives of 36Gb each. It´s basicly standard version, we only have one developped module, used to import and export files from and to desktops located on remote offices, and some reports, nothing else. Cache size on the server is 4096Mb and the commit cache option is active. The system is slow in general, reports are slow, invoices are slow, everything is slow, the application is almost stopped, it only works fine if we have juts 4 or 5 users working. The hard drives are 36gb size and we have already tried Raid0, Raid1 and Raid 5, the best performance we got is with raid 5. The server itself is ok, we have already tried in 4 diferent and brand new compaq servers and no changes. The Citrix server is not the problem because we already tried with the navision client instaled on a desktop in the same lan where the server is and the performance is equal. The network is ok because the only thing that doesn´t work is navision. Our Nsc like the 2 former Nsc’s we had didn´t know the answer,also Navision Portugal doesn´t know what else to do. There are no other aplications running on the server but, Norton Antivirus. The performance montitor of all the machines doesn´t indicate any problems, no queues. We have our tables blocked constantly, but that we always had and we could deal with it, but now it´s everything mixed, the slowliness and the blocking tables. The database has 40Gb, 25 occupied. The biggest tables we have are, products, clients and suppliers, history of invoices, client and product movements.
Hi. Here’s My personal opinions about You implementation: First of all Your disks is wrong configured. You should never run RAID-5. Especially not with this number of users and amount of data. My suggestion is to use a LOT of 15’K disk’s. You should not go over 2Gb for each file (for performance issues) and with a database of 40Gb that should be 20 files. Since it’s only possible to use 16 files You’ll end up with 16 files at 2,5Gb each. Split the 16 files on 16 mirrored disks = 32 disks for database. Do not use database disks for anything else. So You will need at least to more disks for OS and executables. The above is the most important (and expensive) thing to correct. You must remember the basic rule for C/SIDE DBMS: A lot of very fast disks in RAID 1. With this setup You’ll get a lot of mechanism working and 16 commit caches working for You. Today You only have one since You use 1 big file on RAID-5. Furthermore You don’t need that second processor. It does more harm than good to Your server. You say You have 4Gb cache and 2Gb RAM???. Navision only uses 1Gb for cache at a maximum. Use commit cache as long as You have UPS. Make sure You have write-trough (No write cache) on You’re RAID-controller. You can use write cahce if You’re willing to take the risk and ONLY if You have battery backup on the controller card. But I’m not sure You’ll gain anything. I haven’t seen any difference in performance using write cahce on the controller. Use at least a 2-channel controller (buy an expensive one). Remember that disk speed is King with C/SIDE. Buy some more RAM for You Citrix and make sure You have really good network cards on You Citrix and on the Navision Server. Store the temp-files for clients locally on Your Citrix. There’s more, but I think these were the main issues to think about. There’s normally no problem getting Navision to perform very well on C/SIDE databas as long as the HW is properly configured. Best regards //Lars
I concur with everything Lars has said and would only like to add two observations from our experience - 1. Keep the cache under 800Mb. Whilst the specification says 1Gb one site here that I am familiar with had problems with values between 800Mb and 1Gb. 2. You will now have tables over 800Mb in size and from what I have seen these will never be cached as the cache appears not to handle file fragments ? but I have not seen anything definitive on this so what we observe may be due to issues other than cache ?
quote:
Originally posted by PeterCox
2. You will now have tables over 800Mb in size and from what I have seen these will never be cached as the cache appears not to handle file fragments ?
Is this officialy confirmed? It’s a quite interestning question. //Lars
Another thing to look at: Do you have a hardware cache on the drive controllers that has been turned off? Contrary to Lars’ comment, turning off a hardware cache has disasterous performance consequences. We had a client that was posting over 10,000 invoices/day that decided to turn it off and the performance started to mirror what you described. Since you have a multiprocessor server, are other applications running? Navision will use only one processor, but if you’re running other applications, the processors will use the available RAM.
quote:
Originally posted by Allen Beck
Contrary to Lars’ comment, turning off a hardware cache has disasterous performance consequences. We had a client that was posting over 10,000 invoices/day that decided to turn it off and the performance started to mirror what you described.
What RAID-level was that client using? Navision recommends to turn write cache off (but there should not be any problem as long as it’s secured with battery).
Some time ago one of the guys with Navision Denmark replied to the question of using a controller with battery backup that this is not advisable allthougt the ISM for Navision Server says otherwise. I wont translate all off the reply but the conclusion was something like this translated from danish: “Navision does, as well as Microsoft does with SQL, strongly advise not to use writecache on the controller and cannot guarantee data stability if this feature is activated”
RAID 0 In reality, as long as the cache does have battery backup, it should not pose a problem. The warnings by Navision & Microsoft are standard statements designed to cover their corporate backsides, as they know (especially with SQL), that if the power to the computer is cut off and there is no battery on the controller, the database will most likely corrupt. (The same is true for other datbase publishers). However, since most users have some form of UPS on the CPU, the cache will flush long before the UPS dies. We’ve tested the UPS failure scenario on Compaq and HP equipment and the battery holds up long enough to flush the cache even under significant load. In reality, you are probably more likely to have the disk controller fail and create a corruption than to have the cache create one. While there is an element of risk and it should be disclosed, we have been through the “on/off” wars with numerous IT departments and have always found that the demonstrable performance increase increase is very significant in high transaction systems. Naturally, this is just one person’s observation, but in over five years, we’ve never had a data corruption (I hope I have not cursed us here!).
OK. 10’ invoices a day on RAID 0 should give performance problems (as long as we are talking about C/SIDE DBMS). With that load You should split the database over several disks to get performance and use RAID-1 to get redundancy. In this case the write cahce compensates in some degree that You only have one commitcache, but You should really use RAID-1 Rgds //Lars
The point Navision DK makes in the reply to a question, which by the way originated from problem with a corrupted database on a system with a battery backuped controller cache, is, that if you don’t use the controller cache but use Write-through, the disk-system will report back to the Navison server whether the data were actually written to the disk or not,enabling Navision to take action if something went wrong. If you use cache on the controller,the disk system will report back to Navision that the write operation went well allthough the data is still in the controller cache.Now if a bit flips in the cache, which can happen, then you will have a corrupt write-transaction and Navision can no way do anything about this due to the fact it has allready been told that the transaction went well.
Gentleman, This weekend we solved the problem. The database is working!!! This is what we have done: We reinstalled the database server and configured Raid 1 We backed up data inside navision and performed a restore. Cache size is 820 Mb and comitte cache active. we splitted the database in four mirrored volumes. It´s working better than ever. Thank´s a lot for your contribution. Regards
Glad to hear that! //Lars
Lars - It was RAID 1. Unfortunately, my brain-to-finger synapses were working at RAID 0…
Just to add a little historical data to the reliability issue: In six years of installing and supporting Navision databases, we had two cases of database corruption. In both cases the computer systems’ incoming power lines were stuck by lightening and the corruption occured as the systems fried. In one case we were able to recover the database by dropping a half dozen records and in the other case our NTR (Navision US) was able to recover the database.
We had exactly the same problem on a HP RAID5 system. After moving the DB to a RAID1 volume everything was fast again. It bothers me that Navision still recommends RAID5 in their system installation guide…