Bartender Crashing - CPU pegged at 100%
We have been using "Bartender 10.1 SR 4" for about 8 months. Well about a month ago it started crashing and nothing has changed. We were getting a lot of "Failed to create document" and "An unknown error has been encountered" errors in the bartender logs. I contacted support and we changed a few settings.
1. Restart Process after every command
2. Changed the Desktop Heap to 1024KB
Well it's been solid for about three weeks but it crashed earlier this morning. The CPU was pegged at 100% for about 2 hours until I was notified (There were two Bartender 32-bit processes). There are no errors in the bartender or commander logs but I see a few in the Windows Event viewer. It referenced some HDMP & MDMP files.
I've contacted support and are waiting to hear back but I wanted to see if anyone has come across this issue.
VMware VM
2 vCPU
4GB Memory
Example:
Fault bucket , type 0
Event Name: BEX
Response: Not available
Cab Id: 0
Problem signature:
P1: CmdrSrv.exe
P2: 10.1.4.2961
P3: 545e7923
P4: MSVCR90.dll
P5: 9.0.30729.8387
P6: 51ea24a5
P7: 0006ccd5
P8: c0000417
P9: 00000000
P10:
Attached files:
C:\Users\plh-lbl-02_sa\AppData\Local\Temp\WERF674.tmp.appcompat.txt
C:\Users\plh-lbl-02_sa\AppData\Local\Temp\WERF9A1.tmp.WERInternalMetadata.xml
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_CmdrSrv.exe_289b28aa459a861536b0ba848fa97dc4a4e33b6_bc7942e9_cab_8583f9ce\memory.hdmp
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_CmdrSrv.exe_289b28aa459a861536b0ba848fa97dc4a4e33b6_bc7942e9_cab_8583f9ce\minidump.mdmp
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_CmdrSrv.exe_289b28aa459a861536b0ba848fa97dc4a4e33b6_bc7942e9_cab_8583f9ce
Analysis symbol:
Rechecking for solution: 0
Report Id: 4cbc3249-6392-11e6-80db-0050568b37f3
Report Status: 4
Hashed bucket:
-
Just wanted to point out we are using Commander as a service and Win 2012 R2
0 -
Make sure that the below Windows update issue isn't the cause of your new problems:
https://support.seagullscientific.com/hc/en-us/articles/225047808
0 -
Yeah I didn't install any updates.
0 -
I hate to say me too, but.. Me too.
I've spoken with support several times regarding this problem and we've made several changes including increasing desktop heap, changing the detection method from immediate to polling every 500 milliseconds, adding a third CPU to the VM, and limiting the number of documents processed at once. To me, it appears to be a resource issue as it seems to happen every time a big job (1400 labels or so) is processed. Have you noticed any consistency in timing when your CPU is pegged vs. when a specific job or size of job is run? I will be testing in our development environment today to determine if we can repeat the problem. Ultimately, if it is a resource issue, I would like an answer as to what kind of resources we need to throw at a problem like this or how much we need to limit our output.
I'll keep you updated with what I find. If you find a solution, please keep me posted!
1 -
Hello Kyle,
That's interesting that you say large jobs cause issues with your label server. We have two label servers for load balancing which use TCP/IP Socket for the source. We have had issues with both servers since introducing them into our environment. One of the servers we have print large batches (1500-3000 labels) which had issues from the start. I worked with support and we changed "Restart process every hour" which seemed to fix the issue. It's running on VMware with 2 vCPU's & 4GB of memory.
As far as the other one, it's printing about 1 label every 10 seconds. It was solid for about 6 months and then started crashing with "Failed to create document" error messages. We changed the Desktop Heap to 1024KB and Restart process every command. It was good for about 3 weeks but it crashed the other night at 2AM. However, this time there were no errors in Bartender & Commander logs. I could only see the errors in the windows event viewer. I've sent everything to support and waiting to hear back. This VM has the same specs as the other one and it's printing less labels.
1 -
Some general comments:
- In general for BarTender version 10.1, 2CPUs and 4GB should be sufficient. In larger environments and higher volume doing several thousand print requests or more, most of those customers are running some type of quad core with 8GB of system memory.
- The default Command handler settings in Commander usually work for many people. I just want to note that the "Restart process every hour" option not the most efficient option because it actually closes and restarts the bartender process for every print job which takes extra time to load up BarTender process running in the background. Setting the desktop heap setting to separate is highly recommend and 1024kb is fine. Limiting the number of open documents in the document caching in Commander and handler settings can also help with resource and memory usage.
- I would also recommend for large print jobs that you have printer optimizations are enabled. Can be fond under file->print dialog->performance tab in Bartender, all should be enabled except graphic and template caching. In the object method tab of the print dialog as well, true type text should be set to text output and everything else should be set to auto. In general, if you are using a printer with supported Seagull driver with BarTender, performance optimizations supported and enabled by default. Also try to use printer fonts in your BarTender documents. This should help with printing large documents and print jobs.
- Also double check your BarTender documents are opening and printing efficiently from Bartender directly. It can be possible that a document is saved with a network printer that no longer exist causing BarTender to take long time to open to find the printer, just something to check.
1 -
Jason,
I assume you mean "Restart process after every command" is not efficient? Should I change it back to Every hour? Should I set a limit to the document caching? We are printing single labels but every 15 seconds or so.
0 -
Yes, if the frequency of printing is high, then a BT process restart of every command is not a good idea. A restart of every hour is generally best.
0 -
I have made several changes that you guys have suggested and so far it's been stable. Appreciate the help!!!
0
Please sign in to leave a comment.
Comments
9 comments