Console Hanging During Refresh

Usage and Config Platform
1

(imported topic written by Steve91)

Hi Chaps

We’ve recently upgraded to 7.1.1.315 and we’re having a lot of issues (mainly insufficent memory issues with SQL/FillDB) which I’m getting support for.

But one that has just started happening is my console hanging when it performs it’s refresh

It sits at about 30% CPU usage for over a minute while the refresh takes place.

The hang makes it totally unusable and I have to wait until the refresh has completed.

I’ve got the refresh set to 120 second intervals and it also set to “Keep Partial Cache”

And this hang happens regular as clockwork every 2 minutes

I’ve tried clearing the cache and also removing/re-installing the console.

Any other suggestions?

My PC has Dual Xeons and 4GB Ram

Also,

If anyone has any suggestions about / or has experienced similar to our other issues I’d be grateful for advice.

Brief description:

We installed a DSA server and also migrated our existing master to a new blade.

Although it wasn’t totally smooth we eventually got there and replication seems to be working fine.

We’re using Windows 2003 SP2 (x86) & SQL 2005 SP2 - Cumulative Update 4

I’m getting the following errors in FillDB on a regular basis:

Fri, 19 Dec 2008 15:15:12 +0000 – Encountered error during action results update: Database Error:

Microsoft

ODBC SQL Server Driver

SQL Server

There is insufficient system memory to run this query. (37000:701) (RESULTS LOST)

Fri, 19 Dec 2008 15:49:17 +0000 – Encountered error during action results update: Database Error:

Microsoft

ODBC SQL Server Driver

DBMSLPCN

ConnectionWrite (send()). (01000:10054)

Microsoft

ODBC SQL Server Driver

DBMSLPCN

General network error. Check your network documentation. (08S01:11) (RESULTS LOST)

Fri, 19 Dec 2008 15:49:17 +0000 – Unable to connect to database: Database Error:

Microsoft

ODBC SQL Server Driver

DBMSLPCN

ConnectionWrite (send()). (01000:10054)

As for SQL memory we have AWE enabled and have set max memory to 8gb (and boot with /PAE in boot.ini)

We have 32gb RAM on the blade. What does appear odd is that in task manager the sqlserver process never uses more than 180mb of memory…I would expect a lot more to be in use.

I can’t fathom the connection issue. We don’t use a remote DB but it is on SAN disk which is attached to the server as a mount point.

It may be connection issues to the DSA server during replication, I’ll see if I can pick up any more specific errors from SQL.

This all adds up to constant filldb backlogs, machines not reporting for hours and hours and the inability to consistenly schedule our monthly patch run.

Hopefully we will get this resolved before the Xmas break, but any suggestions would be well received.

Server & Consoles = 7.1.1.312

Relays = 7.1.7

Clients = 7.0.7.96

Cheers

Steve

2

(imported comment written by BenKus)

Hey Steve,

Your SQL Server is using 180 MB of memory? That is horribly, awfully low and it is almost certainly the key to all your problems (and it seems unlikely that either 7.1 or DSA have anything to do with your issue)… Just as a reference point, my BigFix deployment has 20 computers reporting and my SQL Server uses up more than 1GB of memory (and it would use more if I let it)…

Since it appears to be a SQL Server-specific problem, you might need to consult some DBAs or MS itself…

Here is a thought just to double-check (it sounds like you have done this already, but thought I would double-check):

  • Right-click on your database in SQL Server Manager and go to “properties”.
  • Go to “Memory”
  • Do the settings look right?

http://support.bigfix.com/images/miscscreenshots/sqlserver-memory.jpg

Until you get the sqlserver.exe memory up to many GB, I would expect BigFix to be non-functional in all the ways you mention and more (slow console, full bufferdir, slow results update, filldb error messages, etc)…

Ben

3

(imported comment written by Steve91)

Cheers Ben

Yep we’re certain it’s a SQL issue but the memory configuration is correct and the DB Admins can’t figure out the fault.

Probably a good idea to contact our MS rep

Cheers

Steve