Re: [ilugd] Stanley Thomas' blog: GNU/Linux Performance Tweaks
Stanley Thomas wrote: http://www.debian-administration.org/articles/388 that seems to be a bit random, do people still use 1990's tech to host servers on ? I mean its been about 7 years into this decade why not upgrade the platform a bit.. Anyway, I shall have a xfs/ext3 test for people in a few days time - I hope to get sometime next weekend and will do some numbers. And Ext4 is just around the bend with even more tuneables :) 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. ok, sorry for not being clear on that one - I meant, what is the performance degradation on the machine with and without the .ko loaded. the clock cycles its going to bite into are trivial at best. but still I'd like to know how you quantified it and exactly how much that was. on a fresh centos 5 installation these were my results using both software raid AND lvm on a partition: why would you want to use mdraid and lvm ? lvm already gives you span and mirror. ok, if you want to use a cheap way of doing hot-swap the newer mdraid might come in handy ( I dont know much about this, have not used it ). /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. you need to basically make sure the drive geometry is identical in both cases, not just the partition size's. also, ext3 is the only filesystem supported by centos-5 at install time :) you need to get xfs post install. Also, things that will make a major difference here are your CPU load levels and the hba being used. Regards, - KB -- Karanbir Singh : http://www.karan.org/ : [EMAIL PROTECTED] ___ ilugd mailinglist -- ilugd@lists.linux-delhi.org http://frodo.hserus.net/mailman/listinfo/ilugd Archives at: http://news.gmane.org/gmane.user-groups.linux.delhi http://www.mail-archive.com/ilugd@lists.linux-delhi.org/
Re: [ilugd] Stanley Thomas' blog: GNU/Linux Performance Tweaks
Hi, Firstly, I dont see any reason to get confrontational here. Stanley Thomas wrote: on ? I mean its been about 7 years into this decade why not upgrade the platform a bit.. does it really matter?? circumstances probably. i mean who cares. hee hee. I am sure more people will care about how systems perform on modern day hardware, using the the platform they are likely to deploy today - rather than what was relevant in the dark ages. I think you yourself made a statement in the first email about using the right build optimisations for the hardware So I would say yes, it does matter. And besides, every admin I know does not go with general good feelings, they work with specifics on the ground. Anyway, I shall have a xfs/ext3 test for people in a few days time - I hope to get sometime next weekend and will do some numbers. And Ext4 is just around the bend with even more tuneables :) all the best. do remeber that benchmarks produce different results in different situations. u suit the one thats more favorable for you. and i do not remember mentioning anything abt ext4. it was abt xfs and ext3 i believe. Absolutely, different environments produce different results and usage scenarios will depend on specific role requirements - but your writing off ext3 across the board was a bit juvenile. Its nice to see you accept that. And w.r.t ext4 - well, I've been meaning to look at that for a while now, this might just be a good chance to do so. Nothing, though, is for free and there is a slight performance and memory penalty associated with kernel modules. There is a little more code that a loadable module must provide and this and the extra data structures take a little more memory. There is also a level of indirection introduced that makes accesses of kernel resources slightly less efficient for modules. from : http://tldp.org/LDP/tlk/modules/modules.html I hope you realise that turning off the sound card in BIOS is not going to drop module support in the kernelif so, this does not related back directly to your statement about disabling sound cards in the bios of a machine... Besides, are you now saying that everyone should rebuild the kernel to remove .ko support and just statically link in everything they need ? Isnt this a bit arcane or even a bit over the top to expect - as you said your doc was for new people - to be able to do ? or even need to do ? not everything is numbers. some things happen because thats the way it is. many unwanted modules or even a few of them depending on your hardware will make you system a little less efficient. more resources used by the kernel and modules gives the user a little less to play around with. any code that is loaded with consume resources. unless you can quantify this, I am going to write your statements off as noise. You are talking about performance tuning a machine and make statements like 'not everything is numbers...' - sounds a bit offbalance, dont you think ? lvm already gives you span and mirror thats news to my ears hee hee. yeah, you might want to go read up on one some of these things, they have, after all, been around for a few years now. i could do swapping with the old mdraid just like i can do with the new one. i dunno what you are hinting at. a suggestion, u shouldnt be speaking about something if you are unsure. I know what I am talking about. You, however, seem confused. My point was that if you do need that capability, mdraid might be something you want to consider. Otherwise lvm should cater directly to your needs. hotswapping a blockdevice with lvm requires more command line flufftery than most people will care about. yes dude. thats the way these tests were conducted. *shrug* ok, just making sure didnt seem clear from what you said. I still cant reproduce the results you posted though. Want to share a bit more info about the hardware behind that ? Also, things that will make a major difference here are your CPU load levels and the hba being used. oh boy... u gotta be kiddin me. ofcouse yes. ugh, no not at all - most of these things depend a lot on the these factors. eg. on a machine with a dmraid setup ( think: the nvraid, ich family, some of the sil setups etc ) you will find its faster to do mdraid setup's than use the underlying h/w fakeraid setup. And given that sort of a requirement you are much better off with an Opteron based solution than a Xeon one - given the same budget, you are going to achieve 10 - 12% highter throughput by not changing anything else - use the same drives, same network cards, chassis etc. ( well, the same budget being the guide ) Perhaps this is beyond the scope of where the conversation started from, just using specifics to give you an idea of whats involved and where. And, we've not even gone into elevator-logic or data layout patterns as yet :) mr.singh i seriously believe that u think that im writting stuff
Re: [ilugd] Stanley Thomas' blog: GNU/Linux Performance Tweaks
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. 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. 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 FilesystemSize 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. 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] ___ ilugd mailinglist -- ilugd@lists.linux-delhi.org http://frodo.hserus.net/mailman/listinfo/ilugd Archives at: http://news.gmane.org/gmane.user-groups.linux.delhi http://www.mail-archive.com/ilugd@lists.linux-delhi.org/
[ilugd] Stanley Thomas' blog: GNU/Linux Performance Tweaks
http://perfector.wordpress.com/ Linux Performance Tweaks Not too long ago my boss and myself came up with a wise idea to make a list of all the linux tweaks usually done to improve the performance of a linux system. The idea has been taken to a higher level and each and every silly possible change that could improve the performance of the system has been added. Of course the actual list would be never ending, but these are a few that I could think of. Do mail me if you think of more that can be added. The first thing to look at a brand new machine is its BIOS. There is a 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 to a lan why leave the on-board lan card enabled. If the system is going to be run in text mode only the shared graphics memory required should not be more than 2MB. All these changes should be done according to requirement. 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. The next most important thing is to use a kernel that's suitable to your processor architecture. For example, if you have a 686 processor use a i686 kernel, if you have a 586 processor use a i586 kernel and if you have multiple processors/cores use the smp kernel. These are the 3 most common kernels provided with any modern distribution. 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. Xfs is by far the fastest filesystem, and if you are dealing with many small files reiserfs is the best. If you have a directory with many different types of files, try to break it up. it definitely will improve performance. Oh, and do use a lighter file manager. Something like Thunar is great. The next thing of course is to disable the services you never use frequently. Services like 'timidity' and 'apache' may very rarely be used by you. Well you can always start them when required. Running services when not required is such a waste of resources. Imagine running a service such as 'postgresql' when all that you are doing with you system is browsing the Internet. 'Prelink drastically speeds up application start-up times. There are a lot of benchmarks done with and without prelink just to prove its superiority. In most modern distributions prelink is very stable and reliable. Avoid using stuff like Kat, Beagle, Evolution etc. etc. At times these apps make the system so unusable. There are much more lighter apps to get your work done. Take for instance, to do a quick word processing job why use 'OpenOffice Writer' when Abiword (which is much more lighter) can do the job just fine. Use a light window manager. My best suggestion WindowMaker. Fluxbox also does a fine job. Well it will take you some time to get used to it. Hey but life is all about changes. I mean, when i started using computers i never knew what linux was. You just adapt to whatever suits you. Well, i know that the above suggestion is not a easy one, but if you are using something like Gnome or KDE avoid using many taskbar applets. Those are real resource hungry. Also wallpapers, icons and files/folders on the desktop consume resources. In linux you have a central storage for each user, so use it for all your files. It keeps your system a lot cleaner, your desktop clear, and you can keep things more organized (atleast i can). My greatest suggestion in this entire article would be to stay abreast with the latest distro. The only way to achieve this is to have a separate /home partition. So the next time you install a new distro, do not format your /home partition but only all the others for the installer to install the required packages and their related files. Packages change over time, Xorg is better than Xfree, Alsa is better than Oss, Udev is better than devfs. Most of all the kernel undergoes major changes, many of which are performance related. Most of the latest distros have packages that are compiled using GCC 3.4 and upwards. GCC 3.4 compiles programs so they run at least 7% faster. Do you really want to miss out on such good performance gains? For ext3 filesystems noatime and data=writeback are good options to have in the '/etc/fstab' file. /dev/hda1 / ext3 defaults,errors=remount-ro,noatime,auto,rw,dev,exec,suid,nouser,data=writeback 0 1 And for reiserfs add the option notail but remove data=writeback /dev/hda7 /boot reiserfs noauto,noatime,notail Six text-mode virtual consoles are absolutely unwanted for a user like me, and considering that each of these virtual consoles consume memory turns me off. Comment out the lines for the unwanted virtual consoles in
