Posting for Stanley... FN

---------- Forwarded message ----------
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Jun 18, 2007 12:55 PM
You are not allowed to post to this mailing list, and your message has
been automatically rejected.  If you think that your messages are
being rejected in error, contact the mailing list owner at
[EMAIL PROTECTED]

---------- Forwarded message ----------
From: "Stanley Thomas" <[EMAIL PROTECTED]>
To: "Karanbir Singh" <[EMAIL PROTECTED]>
Date: Mon, 18 Jun 2007 12:57:06 +0530
Subject: Re: [ilugd] Stanley Thomas' blog: GNU/Linux Performance Tweaks
Nice to know that there is some traffic coming towards my blog.

On 6/18/07, Karanbir Singh <[EMAIL PROTECTED]> wrote:
> Not meaning to be rude, but a lot of stuff in this email is actually
> misinformation and downright misleading.
>
> Have you actually done any tests to highlight these issues ?
>
> I dont personally have the time to go into most of the things but some of the
> stuff is just hard to swallow. eg. I can physically demonstrate an ext3
> filesystem outperform xfs on a standard  database load.
>


http://www.debian-administration.org/articles/388


> Frederick Noronha [फ्रेडरिक नोरोन्या] wrote:
> > lot of junk in there that you may never require. For example, if the
> > machine is going to be used as a file server the on-board sound card
> > is never going to be used, or if the machine is never to be connected
>
> Would you like to share some numbers to demonstrate how much performance you
> loose with a sound card enabled on the bios, with its .ko not loaded ? 
> oprofile
> reports would be nice to go along with your numbers.
>



You pointed out well "with its .ko not loaded". The above comment was
directed towards people doing a fresh install and who wouldnt know how
to disable the loading of particular modules after installation.


> > During installation do try your best to avoid software raid and lvm
> > unless absolutely required. These are two lovely features but both of
> > 'em degrade performance considerably.
>
> again, how much is 'considerable' in your books ? Here are some numbers from a
> machine I was working on a few minutes back. I actually went through the 
> motions
> of doing 2 stock installs for centos-5/x86_64 one with lvm and the other 
> without
> lvm just for the purpose of bring in specific numbers. Here is what I get 
> with lvm:
>
> [EMAIL PROTECTED] ~]# df -h
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/mapper/VolGroup00-LogVol00
>                        901G  533G  322G  63% /
> /dev/sda1              99M   19M   76M  20% /boot
> tmpfs                 1.7G     0  1.7G   0% /dev/shm
> [EMAIL PROTECTED] ~]# hdparm -tT /dev/mapper/VolGroup00-LogVol00
>
> /dev/mapper/VolGroup00-LogVol00:
>   Timing cached reads:   2444 MB in  2.00 seconds = 1222.07 MB/sec
>   Timing buffered disk reads:  514 MB in  3.01 seconds = 170.64 MB/sec
>
> And here are the numbers without LVM, portioned identically:
> [EMAIL PROTECTED] ~]# hdparm -tT /dev/sda
>
> /dev/sda:
>   Timing cached reads:   2411 MB in  2.00 seconds = 1200.50 MB/sec
>   Timing buffered disk reads:  512 MB in  3.01 seconds = 170.09 MB/sec
>
> this is on a machine with 2 socket, 4 core - AMD Opteron(tm) Processor 285
> and :
> [EMAIL PROTECTED] ~]# lspci | grep RAID
> 0a:0e.0 RAID bus controller: Areca Technology Corp. ARC-1110 4-Port PCI-X to
> SATA RAID Controller
>
> running with the bog standard centos-5 install out of the box.
>


on a fresh centos 5 installation these were my results using both
software raid AND lvm on a partition:
/dev/VolGroup00/Dom0Root:
Timing cached reads:   3932 MB in  2.00 seconds = 1965.86 MB/sec
Timing buffered disk reads:  100 MB in  1.66 seconds =  60.41 MB/sec
/dev/sda1:
Timing cached reads:   4076 MB in  2.00 seconds = 2038.65 MB/sec
Timing buffered disk reads:  190 MB in  3.01 seconds =  63.12 MB/sec

both my partition sizes were identical. Oh and by the way ext3
partitions both of 'em.

> I suppose it would be much more worthwhile to run a bonnie++ test, but ...
>
> > Most of us know that ext2/ext3 is the filesystem that has to be used
> > during installation. No doubt that the ext2/ext3 file system is very
> > reliable but if you are seriously looking forward towards a faster and
> > much more responsive system ext2/ext3 is a bad option.
>
> *cough* not true *cough* :)
>
> While it is nice to see someone take on an initiative of this nature, and 
> please
> dont get me wrong on this - I am not being negative about your email or your 
> post.
>
> Regards,
>
> --
> Karanbir Singh : http://www.karan.org/ : [EMAIL PROTECTED]
>

thanx a lot
warm regards
stan

--
http://perfector.wordpress.com/

-- 
FN: Frederick Noronha
Phone 0091-832-2409490
http://wikiwikiweb.de/MyContacts
_______________________________________________
ilugd mailinglist -- [email protected]
http://frodo.hserus.net/mailman/listinfo/ilugd
Archives at: http://news.gmane.org/gmane.user-groups.linux.delhi 
http://www.mail-archive.com/[email protected]/

Reply via email to