Check the server statistics too. Your queue/thread configuration appears to be sufficient for some load, but the queue blocked items in the server stats will confirm that it's enough. I've been practicing setting the minimum threads to 1 and the max to wherever it needs to be. This lets the arserver create new threads for each pool as needed. The exercise of trying to allocate a thread from a pool and creating a new one if all the threads are occupied is relatively simple and the arserver seems to have implemented it well, so setting a minimum of 1 and letting the server drive the thread count saves resources where it can. The only exception is the escalation queue, which needs the min threads defined at a value greater than 1.
There are 4 servers total. Am I correct in assuming that all servers are in a server group, and all but the admin server are behind a load balancer? I am still curious about the following things, to complete the picture: - server group ranking - rpc program used by each subsystem (e.g., 390621 is used by the approval server; 390624 is used by the mid-tier, etc.) - the server statistics queue blocked count - With this server count, I am curious if the hanging occurs on all servers or just one server at a time Do keep in mind that cache operations can wreak havoc on your servers, because they are all in a server group together. Regards, Axton Grams On Tue, Mar 13, 2012 at 11:45 AM, Chris Wilson <[email protected]> wrote: > ** Hello, > > Here is the thread/queue information for our 7.6.04 SP2 application server > environment: > > Admin Server: > > Private-RPC-Socket: 390601 1 1 > Private-RPC-Socket: 390603 1 4 (Escalations) > Private-RPC-Socket: 390620 12 20 (Fast) > Private-RPC-Socket: 390621 2 20 > Private-RPC-Socket: 390626 2 5 > Private-RPC-Socket: 390635 18 20 (List) > Private-RPC-Socket: 390680 1 4 (Approvals) > Plugin-Loopback-RPC-Socket: 390626 > Approval-RPC-Socket: 390680 > External-Authentication-RPC-Socket: 390695 > > > AR Server 1: > > Private-RPC-Socket: 390601 1 1 > Private-RPC-Socket: 390603 1 1 (Escalations) > Private-RPC-Socket: 390620 4 10 (Fast) > Private-RPC-Socket: 390621 2 8 > Private-RPC-Socket: 390626 2 5 > Private-RPC-Socket: 390635 4 12 (List) > Private-RPC-Socket: 390680 1 4 (Approvals) > Plugin-Loopback-RPC-Socket: 390626 > Approval-RPC-Socket: 390680 > External-Authentication-RPC-Socket: 390695 > > > AR Server 2: > > Private-RPC-Socket: 390601 1 1 > Private-RPC-Socket: 390603 1 1 (Escalations) > Private-RPC-Socket: 390620 4 10 (Fast) > Private-RPC-Socket: 390621 2 8 > Private-RPC-Socket: 390626 2 5 > Private-RPC-Socket: 390635 4 12 (List) > Private-RPC-Socket: 390680 1 4 (Approvals) > Plugin-Loopback-RPC-Socket: 390626 > Approval-RPC-Socket: 390680 > External-Authentication-RPC-Socket: 390695 > > > AR Server 3: > > Private-RPC-Socket: 390601 1 1 > Private-RPC-Socket: 390603 1 1 (Escalations) > Private-RPC-Socket: 390620 4 10 (Fast) > Private-RPC-Socket: 390621 2 8 > Private-RPC-Socket: 390626 2 5 > Private-RPC-Socket: 390635 4 12 (List) > Private-RPC-Socket: 390680 1 4 (Approvals) > Plugin-Loopback-RPC-Socket: 390626 > Approval-RPC-Socket: 390680 > External-Authentication-RPC-Socket: 390695 > > Application Server Specifications: > > Virtual Server > Windows 2008 Enterprise Server R2 64-bit > (6) Intel Xeon X5650 2.67 Ghz Virtual CPUs > 16 GB of RAM > > Thanks, > > Chris > > > > > > From: Axton <[email protected]> > To: [email protected] > Date: 03/12/2012 03:17 PM > Subject: Re: Remedy 7.6.04 - BRIE Timeouts > Sent by: "Action Request System discussion list(ARSList)" > <[email protected]> > > ________________________________ > > > > Turn on cumulative and individual queue server statistics collection > on the servers. Look for queue blocked items in the recorded > statistics. What is your queue/thread configuration on arserver and > what subsystems use which queues? > > Axton Grams > > On Mon, Mar 12, 2012 at 2:34 PM, Chris Wilson > <[email protected]> wrote: >> We are implementing new 7.6.04 SP2 environments and we seem to experience >> BRIE timeouts sporatically on our ARS servers. The timeouts seem to be >> triggered by user activity, however, it does not take much activity to >> activate the timeouts. When timeouts are experieced, current users >> experience an hourglass and new users cannot login. Once the timeouts start, >> we must recycle the application server(s) experiencing the issue to restore >> service. We are experiencing this issue in our DEV, QA and PROD 7.6.04 >> environments. Anyone else experiencing this issue? We are also running ARS >> 7.5 Patch 6 with no timeout issues. >> >> Thanks, >> >> Chris Wilson >> >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
