I agree with Patrick. For SQL Server 2008 x64 on Win2K8 x64, you will want more memory than 8 gb, especially since the OS will tie up at least 2 gb.
The SQL Server I will be using for production under ARS 7.5 and all of the 7.6 apps has 24 gb RAM, with SQL Server configured to use up to 20 gb. The ARSystem db with all apps loaded but only sample data and some foundation data is only 4.7 gb right now, so SQL Server is only using 6.5 gb of RAM and the system is using 7.95 gb total. As the db grows and activity goes up the SQL Server usage will rise dramatically. We originally tested 7.5/7.6 against a 12 gb SQL Server 2008 x64 machine, with 10 gb allocated to SQL Server, and ran a process that generated millions of records (the ARSystem db grew to 20-30 gb in size). When it got that big, the 12 gb of ram was completely used up (96%) by SQL Server and the OS together. We decided to buy a newer server with twice the RAM. Even on ARS 7.1 the SQL Server memory utilization can climb dramatically depending on what the AR server is doing. My production database server (SQL Server 2005 x64, 8.6 gb ARSystem db) is currently loafing at 3 gb utilized out of 10 gb total, with the SQL Server using only 2 gb, but the SQL Server process has peaked at 6.3 gb of memory during the current month (since last reboot). When SQL Server runs out of ram and starts swapping memory out to disk, performance will suffer. Two processors is fine as long as they have multiple cores; the machines I have SQL Server 2008 x64 on, one for ARSystem, one for Remedy Knowledge Management and a development ARSystem, have two Intel E5550 or E5520 CPUs respectively, for a total of 16 cores each. Keep in mind that you will need to run ADDM against a different instance of SQL Server, one collated to be case sensitive. If you put it on the same server as the SQL Server hosting the ARSystem db - normally case Insensitive - you will need even more RAM. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of patrick zandi Sent: Wednesday, February 10, 2010 12:16 PM To: [email protected] Subject: Re: OT: Server Sizing ** If it was me, I would change that to 16 gig of ram, and 4 CPU's min 2008 OS is ram worthy, with sqlserver another 2.5 gig min, that is 5 - 6 with 20% overhead gone. Then adding in the ARS 2 gig, and mid-tier 3 gig, that is about 10 gig alone.. and you always add more than you need just because it keeps the os happy. that is just the ars, db, flashboards, mid-tier box (if you have to keep it on one box) Then you will have to have your addm on one box, RKM on another , and BEM/SIM is large as well and that gives you one more box. So 4 boxes with the above settings would be my recommendations up front, without all the details.. but if you are going enterprise, your CMDB Reconciliation engine needs its own box it can be 9 - 12 hours of processing.. my 2Cents. From: Action Request System discussion list(ARSList) [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Philip, Saji L Sent: Wednesday, February 10, 2010 11:16 AM To: [email protected]<mailto:[email protected]> Subject: Server Sizing ** Hello, AR Listers We are currently in preliminary discussions to upgrade our current Remedy platform to 7.6 and adding SLM, RKM, and Change/Release Management. We are also adding some infrastructure products like BEM/SIM and ADDM discovery. We want to fully implement CMDB as well. Question: management is asking me how the infrastructure would look( concentrating on the CMDB side ). We currently have about 4,000 incidents into Remedy, roughly 50 change items, and we are looking at managing about 3,000 CIs in the CMDB. So, I am looking for actual deployments or literature on how to size for the CMDB? I am looking at have a SQL server( possibly 2 cpus and 8 gigs of memory ) running WIN 2008 ( 64bit ), I am not concerned with the storage, because the DB files will be located on a SAN. Is the above SQL Server sufficient enough to handle the above numbers? Or should I consider bumping up the cpus and memory? I think I am ok, but wanted to make sure. Saji _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
