Thanks Misi. I've already read the whitepaper and verified all the "normal" stuff and our network guys verified the connection should be 1GB so I'm leaning towards bad code at this point.
I'll check out your guide and start digging through the logs. Craig Carter -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Misi Mladoniczky Sent: Tuesday, January 15, 2008 9:27 AM To: [email protected] Subject: Re: Server Configuration Recommendations Hi Craig, I would suggest looking at your applications and how they are designed before throwing more money at your hardware. As suggested, the API+SQL+FLTR+ESCL-logs will show where your server is spending it's energy. It may be a few really bad select-statements that fail to utilize your indexes, but it can just as well be a lot of semi-bad-statements. It is often easy to fix, but may sometimes require significant redesign of your applications. You will find a few key things to look for in the performance tuning presentation I did at UKRUG in 2006: http://rrr.se/doc/rrrukrug2006.pdf Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. * RRR|Translator - Manage and automate your language translations. Find these products, and many free tools and utilities, at http://rrr.se. > We've ran over 600 concurrent users on a 2x1.4 GHz with 1 GB of memory > without any issues. And that's a system with millions of tickets and > over 50,000 emails sent each day on only 20 fast, 20 list, plus some > private threads. We have two of these so one doesn't normally carry that > load, but it has at times. So I don't think it's the size of your > server. > > > > Ordinarily I would suggest you split the database out onto its own > server. But given how big your current hardware is, and how small your > current user base is, I see no need for that just yet. You seem to have > plenty of hardware for that size of a system. > > > > I would use something like BMC Log Analyzer to analyze your API and SQL > logs from a slowdown. That will tell you if you've got long running SQL > or API calls, if you have little or no idle time on some threads > (queuing), etc. It's available on the BMCDN last time I checked. I > believe Misi has a log analysis tool as well at www.rrr.se > <http://www.rrr.se/> , but I haven't used it myself. If you see that > your API calls are big, and your SQL calls are big, you've got a problem > with your database. In that case, look at database metrics or hardware > metrics to see if you have disk contention problems. Once we tuned our > AR Server almost all of our bottlenecks were in the database, and mainly > with disk contention. > > > > Chad Hall > (501) 342-2650 > > ________________________________ > > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Craig Carter > Sent: Tuesday, January 15, 2008 8:41 AM > To: [email protected] > Subject: Q: Server Configuration Recommendations > > > > All, > > > > We're running into some performance problems recently. I upgraded the > server a few days ago (operating system, database, CPUs, memory, queues, > etc, and it hasn't helped much. Basically, it takes longer to search > and create tickets as more and more people log in (as expected) but the > server has plenty of available CPU, plenty of memory, and plenty of > bandwidth so it appears there is a bottleneck somewhere. > > > > 8 CPUs > > 16GB Memory > > Windows Server 2003 Enterprise > > SQL Server 2005 Enterprise > > ARS v7.0.1 P5 (CSS and custom apps-no ITSM) > > 24 Fast, 40 List > > > > It flies with about 40 people, becomes sluggish with 80, and gets real > slow with 100. I would expect this system to be able to handle a much > larger load. Since the running CPU usage and disk usage is fairly low, > I'm looking for advice. > > > > Everything is currently installed on the same server and on the same > drive (although these are raid drives). Is it possible we're seeing > contention over disk resources and I/O? Any advice on determining where > the bottleneck is or from people administering a large number of users? > How much advantage would be gained by running the AR Server on another > drive or box separate from the database? Is it reasonable to expect to > only get 100 concurrent users (using the WUT) on a server of this size? > > > > Looking in the docs and whitepapers but any advice would be helpful > since this is impacting us now. > > > > Craig Carter > > > > > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ > ************************************************************************ * > The information contained in this communication is confidential, is > intended only for the use of the recipient named above, and may be > legally privileged. > > If the reader of this message is not the intended recipient, you are > hereby notified that any dissemination, distribution or copying of this > communication is strictly prohibited. > > If you have received this communication in error, please resend this > communication to the sender and delete the original message or any copy > of it from your computer system. > > Thank you. > ************************************************************************ * > > ________________________________________________________________________ _______ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > > -- > This message was scanned by ESVA and is believed to be clean. > > ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
