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: arslist@ARSLIST.ORG > 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"
