Performance Probs [Log inside]

tentacle · 2007-09-04

Hi,

we have huge performance Problems within our Navision Databases.
E.g. opening an item form may take up to 20 seconds!!

Having a look into the performance monitor I made the following screenshot.

At this moment the requisition worksheet was running over all items to made proposes for purchase.

Does the harddisk queue show that our disks on E: are too slow or is there another problem?

http://i14.tinypic.com/4xm47ko.jpg

Marije_Brummel · 2007-09-04

Try searching the forum. There are issues with NAV and SQL2005 that can cause the issue you describe.

There are kb-artikles by microsoft your partner can use to try and solve the problem.

Luc_VanDyck · 2007-09-04

I suggest you take a look at the flowfields which are used on your item form. Try removing them all and put them on the form again one by one to see which one is responsible for the performance issue.

kine · 2007-09-04

1) If all databases and transaction logs are on E:, than I am no wondering...
2) Page splits can be mark of segmented indexes
3) Full scans can be mark of wrong usage of indexes

The data can lead to the solution, but as you know, it is just indicator that something can be wrong...

tentacle · 2007-09-04

kine wrote:

1) If all databases and transaction logs are on E:, than I am no wondering...

Yes, they are both on E:.
But E: is a logical partition in our huge SAN so I think this should be ok!?

Marije_Brummel · 2007-09-04

Check your file latency to make sure.

Recomendation is to have the Logfile on a dedicated RAID1 and data on Raid10.

Make sure the striping is not shared with other apps and that the connection with the san is dedicated and not shared by other servers.

On partnersource there is a special query released by MS to see if THE bug in SQL2005 is happening on your system. This shows the amount of huge reads in the procedure cache.

kriki · 2007-09-04

tentacle wrote:

kine wrote:

1) If all databases and transaction logs are on E:, than I am no wondering...

Yes, they are both on E:.
But E: is a logical partition in our huge SAN so I think this should be ok!?

Definitely NOT!
RAID5 is the worst you can get for performance.
Like Mark said: separate the DB-file and the log-file.

You might also get a specialist to check all.

But first I would check the Item form and remove all flowfields and check what code is launched when opening the form.

kine · 2007-09-04

tentacle wrote:

kine wrote:

1) If all databases and transaction logs are on E:, than I am no wondering...

Yes, they are both on E:.
But E: is a logical partition in our huge SAN so I think this should be ok!?

huge SAN is not same as "Optimal storage". Huge SAN can be Huge Problems when used in wrong way... (as everything else). Biggest myth is that newest and expansive hardware is warranty of best performance. Everything without correct setup is just heap of screws, heads, wires, metal and other "hardware".

tentacle · 2007-09-07

Only MBS Partners have an account to partnersource, right?

Is there any other way to get that "Sql2005-Bug-Test-Script"?

Marije_Brummel · 2007-09-07

Doesn't your partner want to give it to you?

tentacle · 2007-09-07

I have to ask them.

From my experiences it is easier, faster (and even better

) to do these things on my own.

bbrown · 2007-09-09

tentacle wrote:

I have to ask them.

From my experiences it is easier, faster (and even better ) to do these things on my own.

Based on the contents of this thread, I would have to disagree with that statement.

tentacle · 2007-09-10

hmmm....bbrown, and what do you say if I tell you that our partner already analyzed the performance and neither mentioned this bug nor tested anything in this direction?

kine · 2007-09-10

tentacle wrote:

hmmm....bbrown, and what do you say if I tell you that our partner already analyzed the performance and neither mentioned this bug nor tested anything in this direction?

Than I will say, that they are not reading this forum regularly... 8)

It is problem, that if you do not know about this possibility, you cannot do anything around it. And if they just sent the problem to MS Support, still it is not warranty, that they will answer correctly (it depends on how the problem was described and on the support engineer). But you can tell them - "Hey, I found something about this and this problem, is it possible, that it is our case too?" (show them direction) - and if they will react correctly, than it is ok.

bbrown · 2007-09-10

tentacle wrote:

hmmm....bbrown, and what do you say if I tell you that our partner already analyzed the performance and neither mentioned this bug nor tested anything in this direction?

To which bug are you referring? http://www.mibuso.com/forum/viewtopic.php?t=13154

It took us a bit of "screaming" at Microsoft before they would even admit this problem existed. Even then it probably accounted for less then 1% of the performance issues at this client.

Performance tuning is a complex issue. Rarely is a single issue the cause of all performance problems. Typically it is the combined impact of several issues.

Working with your MS partner should be a partnership. You both need to understand the resources you each bring to the table. Your partner needs to use the resources available to help resolve your issues. This may involve things like this site or partnering with other partners or Microsoft. You also need to understand that it is unrealistic to expect any one person (or partner) to have the answer to every problem you will encounter.

Performance Probs [Log inside]

Comments

Categories