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"
