Joshua Baker-LePain <[EMAIL PROTECTED]> a écrit sur 20/06/2006 14:07:58 :
> On Tue, 20 Jun 2006 at 9:47am, Cyrille Bollu wrote
>
> > The server is a Dell PowerEdge 2850 with 2 Intel Xeon 3GHz processors and
> > 8GB RAM.
> >
> > I have one big RAID5 array made of 6 Seagate Cheetah ST3300007LC 10Krpm
> > 300GB
> > (http://support.euro.dell.com/support/edocs/storage/p76311sc/intro.htm).
> > All connected to channel 0 of a Dell PowerEdge Expandable RAID Controller
> > 4e/Di (h
> > ttp://support.euro.dell.
> com/support/edocs/storage/RAID/perc4e/en/ug/index.htm).
> > See hereunder for more info.
>
> How much benchmarking/optimization have you done with the array?
Almost none... That's the first time I'm working with such a big filesystem.
I ran "hdparm -t -T" when I received the server and got a transfer rate of around 40MB/s from the array. That satisfied me at that time. But now I'm experiencing a transfer rate of less than half the expected speed. And a tape drive that's shoe-shinning... (BTW is this still so bad for the drive? I could not find anything like this in Dell's documentation. They basically just say "It will be a lot slower").
My idea is to buy that Dell PowerVault 220S (http://support.euro.dell.com/support/edocs/stor%2Dsys/spv22xs/en/ug/index.htm) and move all the data on a RAID50 or RAID5 (whatever gives me the best cost/performance ratio) array that I would create there. That would also separate my OS from my data.
I was also wondering if I would use a reiserFS filesystem or if a tuned ext3fs would do the trick.
Do you have any hint of what I could do to optimize/benchmark my config? Could you eventually point me to some interesting readings?
Ho yes, I also noticed that my processors are waiting for I/O most of their time. But couldn't definitively figure out why. Maybe you will have an idea...
Here's a typical output of "top" when I run "du -sh" on a 20GB folder:
14:50:54 up 19 days, 22:14, 2 users, load average: 0.20, 0.19, 0.10
206 processes: 204 sleeping, 1 running, 1 zombie, 0 stopped
CPU states: cpu user nice system irq softirq iowait idle
total 0.0% 0.0% 0.8% 0.0% 0.0% 198.8% 200.0%
cpu00 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 100.0%
cpu01 0.0% 0.0% 0.9% 0.0% 0.0% 99.0% 0.0%
cpu02 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 100.0%
cpu03 0.0% 0.0% 0.0% 0.0% 0.0% 100.0% 0.0%
Mem: 8203432k av, 8183652k used, 19780k free, 0k shrd, 230488k buff
6302676k actv, 1224260k in_d, 172712k in_c
Swap: 4192956k av, 452468k used, 3740488k free 7548476k cached
And here's a typical output of "top" when I run "tar -cf" on the same folder:
14:56:55 up 19 days, 22:20, 2 users, load average: 0.53, 0.50, 0.27
206 processes: 204 sleeping, 1 running, 1 zombie, 0 stopped
CPU states: cpu user nice system irq softirq iowait idle
total 2.0% 0.0% 18.0% 2.8% 2.0% 182.0% 191.6%
cpu00 0.1% 0.0% 6.7% 0.0% 0.3% 74.1% 18.4%
cpu01 1.5% 0.0% 2.5% 2.1% 1.5% 13.3% 78.6%
cpu02 0.0% 0.0% 4.3% 0.9% 0.1% 78.2% 16.1%
cpu03 0.5% 0.0% 4.3% 0.0% 0.0% 16.3% 78.6%
Mem: 8203432k av, 8184556k used, 18876k free, 0k shrd, 274300k buff
6317820k actv, 1214636k in_d, 182772k in_c
Swap: 4192956k av, 517748k used, 3675208k free 7477412k cached
PID USER PRI NI PAGEIN SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
31885 root 16 0 146 604 604 532 D 13.3 0.0 0:03 tar
11 root 15 0 0 0 0 0 SW 2.9 0.0 121:36 kswapd
27650 domino 15 0 7110 198M 191M 190M S 1.5 2.3 5:26 server
31886 domino 21 0 252 1004 1000 892 S 0.5 0.0 0:00 Y0090751.s
685 root 15 0 0 0 0 0 SW 0.3 0.0 14:32 kjourna
>
> > I'm running Linux RedHat ES 3.3.
>
> That's an awfully old point release. Any reason for that?
a too large "to do list" perhaps? ;-)
Yes, going to kernel 2.6 (and the new megaraid_mbox driver!) was also on my possible-improvement list.
- Re: tar's default block size & shoe-shinning Cyrille Bollu
- Re: tar's default block size & shoe-shinning Joshua Baker-LePain
- Re: tar's default block size & shoe-shinn... Cyrille Bollu
- Re: tar's default block size & shoe-s... Joshua Baker-LePain
- Tunning for performance (was: tar's d... Cyrille Bollu
- RE Tuning for performance Cyrille Bollu
- Re: RE Tuning for performanc... Joshua Baker-LePain