This is more of an art than a science, but there's certain science-y parts about it.
In the Remedy Admin console, go to the Server Admin page, and add up your total threads under the "Max" column for fast threads. Repeat for list. Keep these numbers handy. Also, it's worth noting that your minimum numbers should be low - most people have it at 2, but some larger installations go higher. My large implementation I am working on is set to 8 for min, 20 for max for fast threads. We have LOTS of server power though. First, to tell if you have ever maxed out, run our AR Log Analyzer for the time period you have logs for. I prefer to use the example #5 for arwklga command, formatting everthing in HTML. Let's assume you did that. When you open the index.html file, go to the "Thread Statistics". Now, count up the # of threads under Fast and repeat for List. These are the threads actually being used by the server. If the number matches your max from your Server Admin, you have maxed out at some time in the log period for that thread type. If it is lower, you did not. That's the answer to your first question. Now, the next obvious question is "When do I care if I did max out?". You care that you maxed out when your minimum idle times are very, very low - like under 0.01 seconds and you have maxed out AND your average idle time is very, very low (under 1-2 seconds). At this point you are probably going to be seeing system problems, lockups, annoyed customers, etc. Keep in mind those are my benchmarks based off of the systems I have worked on. I've definitely seen exceptions. When do you want to raise the max threads? Well, not often. If you are maxing out your thread resources you probably need to investigate why, looking at the longest running SQL queries. 9 times out of 10 there's optimization you can do there which will GREATLY clean up your thread statistics. Case in point: Recently one server group was having problems and locking up occasionally. I did some analysis and found that a field on the HPD:Help Desk form was doing a QBE query of %LIKE% (leading and trailing) when really it just needed to be an exact query. Making this change caused a backlog of 55+ second queries to go down to well under one second. Then we went from maxed out threads to much more idle threads. I could have added threads but that would have resulted in more server resources being used, generally known as "Crashing the server faster". Also, when you add threads you need to know the max number of connections to the database that are allowed. One of ours is 800. Sounds like a lot, right? Now imagine a server group with 10 AR Servers. That's 80 connections each - which isn't all that many when you consider we have 16 list threads, 20 fast threads, 12 private threads, plus all of the other standard ones. It adds up in a hurry. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Jennifer Varkey Sent: Wednesday, July 16, 2014 2:49 AM To: [email protected] Subject: Maxed out List and Fast threads query ** Hello ArsGurus, Can someone please advise on how to identify if the list and fast threads have maxed out? I am using the arloganalyzer for the api and SQL logging. regards, Sonia ________________________________ No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com> Version: 2014.0.4716 / Virus Database: 3986/7832 - Release Date: 07/10/14 _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
