Printing Labels Pegs Database Server At 100% Cpu S’abonner

0
Avatar
Legacy Poster

We're on 10.1 SR1 Automation edition with 80 printers.  The bartender components are installed on one server and the system database is located on our SQL Server 2012 instance.  That SQL server has 4 CPUs and 24 GB of memory.

 

Since going to 10.1, we've noticed that everytime someone prints a label (we print via Commander), the CPUs on the database spike to 100% until the print job finishes.  The normal baseline for the CPUs is around 10%.  See the attached screen shot.  We have confirmed the CPU spike comes from the SQL Server instance that hosts the Bartender system database.  It also hosts about 50 other databases but the traffic is fairly light and when label printing is disabled, we don't see any CPU spikes.  We didn't have this issue when we were on 9.3.

 

Any ideas?  We're having some performance issues with our applications due to these spikes.

 

 

 

 

5 commentaires

0
Avatar
Domingo Rodriguez
Modérateur
Actions pour les commentaires Permalien

There were some performance issues in previous service releases for BT v10.1. Please update to the latest service release and let me know if the problem persists:

http://www.bartenderbarcodesoftware.com/label-software/fixes_101.aspx

 

If it does, please let me know what check boxes are enabled under the "Administer > Log Setup > Database Log" dialog in BarTender.

0
Avatar
Legacy Poster
Actions pour les commentaires Permalien

Domingo -
 
Thanks for your response.  I did install SR2, however the database CPU continues to go to 100% with each label print.  I have attached my log setup as requested.

0
Avatar
Domingo Rodriguez
Modérateur
Actions pour les commentaires Permalien

I take it that the SQL Server 2012 instance is running on the same PC as BarTender... Please confirm. It should be the case as you own an Automation Edition of BarTender, but I would like to get this confirmed.

 

Was the system database in BT v9.3 configured under the same SQL Server 2012 instance?

 

Do you have the same problems when printing some print jobs directly from BarTender (not via Commander)?

0
Avatar
Legacy Poster
Actions pour les commentaires Permalien

The SQL Server 2012 instance is on a different server than Bartender and that is the same as when we had 9.3 installed (we upgraded 9.3).
 
I think the issue here is this query which runs each time a label is printed:
 
SELECT [ChecksumID] FROM [dbo].[BtObjectChecksums] WITH(tablockx,xlock)  WHERE [FormatID]=@1 AND [ObjectNameID]=@2 AND [ObjectTypeStringID]=@3 AND [Value]=@4
 
It’s doing a table lock on this (tablockx) and an exclusive lock (xlock) and there 22,964,112 rows in that table.  Also, none of the columns being searched have indexes on them so we're doing a full table scan.  I can't understand how this sql passed QA.
0
Avatar
Domingo Rodriguez
Modérateur
Actions pour les commentaires Permalien

So you were refering to BarTender reading variable data from a database, rather than BarTender logging print job information to BarTender's system database... I got confused by your initial statement "system database is located on our SQL Server 2012 instance".

 

I take it that you're going to look then at optimizing the SQL query? Other things you could be looking at is at doing the query prompt on a database view rather than a table, and perhaps enable the "Use Client Cursor" under the "Options" tab of BarTender's database connection.

Vous devez vous connecter pour laisser un commentaire.