I would avoid raid 0 for db usage. One drive failure means you will be doing a restore. If you have a good raid controller, raid 5 is the best bang for the buck. If no raid 1+0 is slightly more expensive, but has the best of all worlds (striping for performance, mirroring for redundancy, and no parity calculation overhead).
Strongly agree with point 3. With trunking, there are several arrangements you can consider, round robin, load balanced, failover, etc. Networks are fun. Axton Grams On 1/25/07, Bradford Bingel <[EMAIL PROTECTED]> wrote:
** Three additional suggestions you might want to investigate further: 1. On your database server, assuming "disk1" is where the database physically resides, *consider using multiple smaller drives with RAID 0 (striping)*. Database performance typically improves -- sometimes significantly -- when the read and write operations are divided among multiple "spindles" (physical drives). RAID 1 (mirroring) won't give you any performance improvement, and RAID 5 (striping with distributed error correction parity) should be avoided for *any* database application. 2. Assuming your (Remedy) application server and database server have multiple NIC's (or a NIC with multiple ports), *consider Ethernet trunking * (or "link aggregation"). Properly tuned, trunking offers the twin advantages of a) improved performance and b) link redundancy (if one of the Ethernet ports fails, the remaining will continue to handle the network traffic). 3. If your server NIC's and switches support it, *considering using "jumbo" Ethernet frames*. Recall that the maximum size for an Ethernet frame remains 1,518 bytes, regardless of the link speed (even gig Ethernet), so even a modest 100Kb data transfer would take dozens of Ethernet frames to complete. Years ago, Alteon Networks (later acquired by Nortel) demonstrated that jumbo frames typically doubled throughput, while cutting processing time in half. Since then, most of the NIC and network manufacturers began offering jumbo frames as an option. I would encourage you to learn more and determine if it makes sense in your environment. -- Bing Bradford Bingel ("Bing") ITM3 California http://www.itm3.com/ [EMAIL PROTECTED] (email) 925-260-6394 (mobile) ------------------------------ *From:* Action Request System discussion list(ARSList) [mailto: [EMAIL PROTECTED] *On Behalf Of *Rick Cook *Sent:* Thursday, January 25, 2007 2:56 PM *To:* arslist@ARSLIST.ORG *Subject:* Re: Reg: Hardware Compactibility ** Well, you'll need to do some research on your own, but essentially you'll want to have some way of moving old, closed tickets out of your main ticket form and into one that could be used for reporting, with the intent being to keep the number of records in your main form relatively small (less than 100k, and preferably less than 10k). The old data will rarely be accessed, but users will insist on being able to get to it anyway, and that's usually what is done with it. To accomplish this, you could use DSO, Remedy's new (in v7) archiving functionality, or workflow of your own. It's not that hard to do, the hard part is getting the users and the bosses to sign off on what you are going to do. Rick On 1/25/07, Pavan Kumar Av (Consultant) <[EMAIL PROTECTED]> wrote: > > ** > > Hi Rick, > > As of now we have no archiving strategy. Let me know how can > we have one and what all it needs. > > *Thanks & Regards, * > > *Pavan Kumar** AV - [Remedy]** > **HCL - AutoDesk** > **Work: 408 416 0170 Extn: 5576** > **Mobile** : +91 98409 95070* > > *Home: +91 44 4359 0919* > > *Mail To: [EMAIL PROTECTED] > ------------------------------ > > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] *On Behalf Of *Rick Cook > *Sent:* Friday, January 26, 2007 4:02 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Reg: Hardware Compactibility > > ** > > That looks quite adequate to me, but at 120k tickets a year, I hope you > have an archiving strategy, or performance even on that hardware will begin > to suffer pretty soon. > > -- > Rick Cook > Cook Enterprises > 253-278-4112 > > On 1/25/07, *Pavan Kumar** Av (Consultant)* <[EMAIL PROTECTED]> > wrote: > > ** > > Hi List, > > As of now my server's are of below configuration. We have gone > live for about two quarters & are working just great. Going forward my > client is expecting ticket load as given below: > > Peak License usage: 100 > > Incident Tickets per year: 120,000 > > Change tickets per Year: 5,000 > > Please assist me if the below Hardware configuration with hold good or > not. If yes, then for how long. Also let me know what other parameters I can > look forward to tune my server to avoid any over loading. Thanks in advance > to all. > > *Server* > > *Windows Version* > > *Model* > > *CPU* > > *Memory* > > *Internal Disks* > > Web Server > > 2003 Server > > DELL > > 8 CPU, Intel Xeon 3.16 Ghz > > 4 GB > > Disk0 - 68.24 GB, Disk1 - 136.48 GB > > Application Server > > 2003 Server > > DELL > > 8 CPU, Intel Xeon 3.16 Ghz > > 4 GB > > Disk0 - 68.24 GB, Disk1 - 136.48 GB > > Database Server > > 2003 Server > > DELL > > 8 CPU, Intel Xeon 3.16 Ghz > > 4 GB > > Disk0 - 68.24 GB, Disk1 - 136.48 GB > > *Note: **No Clustering or load balancer available as of now.** * > > ** > *Thanks & Regards, * > > *Pavan Kumar** AV - [Remedy]** > **HCL - AutoDesk** > **Work: 408 416 0170 Extn: 5576** > **Mobile** : +91 98409 95070* > > *Home: +91 44 4359 0919* > > *Mail To: [EMAIL PROTECTED] > __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"