PDA

View Full Version : Ubuntu Tweaks


FluxGFX
April 28th, 2009, 01:29 PM
Hey Mrkvonic,

Seeing that your pretty much well verse on Linux/Unix environments, you may have pointers for a few of us. I'm no beginer to Unix/Linux but not an expert either.

I was intrigue to see what tweaks, parameters, or anything that could increase performance and just plainly enhance the experience on Ubuntu.

Anything you would like to share on that matter?

-- Arup this also goes for you! ;) I know you have a whole bag of stuff to share.

Cheers,
fluxgfx

Arup
April 28th, 2009, 02:03 PM
Thanks for the heads up, Mrk has way more knowledge than I have, actually Ubuntu and Linux in general is quite quick off the box and unless needed, I generally don't bother much with tweaks, I would rather prefer stability. I do install the latest video drivers from the manufacturer rather than the one in the repos, also I use ext4 to keep my file system fast and that helps out a lot. I also set the OS timeout in grub to 0 to make it boot quick, I don't need the delay as I don't use any other OS. Also since I am jaded person, I have no attraction to any effects so even though Compiz in Linux is the lightest eye candy compared to other OS, I have that turned off and metacity turned on as for me, response is everything.

If you really wish to mildly and safely tweak Ubuntu I suggest you check out Ubuntu tweak at http://ubuntu-tweak.com/

FluxGFX
April 28th, 2009, 02:17 PM
Like I said in one of my previous email chatting with a colleague of mine. I made a backup of my OS and switched the partition to ETX4 and reloaded the OS.

So right there I noticed a nice increase in speed (mind you I'm running of a 10 000RPM disk). I did set the OS timeout to 0. I mean I have enough ressources on this puppy to have all performance, shiny looks and stability, so the visual effects are FULL fledge. I don't anticipate having any issues with the my newly installed GTX 260. Ok I'm only running with 4GB of RAM compared to 8 BLAH!. But mind you at this point, I'm just looking to fiddle with stuff here and there. I made a few modification to my IPtable but most of it is handle by my switch (box, router, firewall) whatever you want to call my little P2 dinosaure running around with nothing more then a 6gb HD with almost nothing.

Thx Arup, yeah well for the times your on MSN and I'm not... I'm working LOL ;)

Mrkvonic
April 28th, 2009, 02:36 PM
Beware that serious tweaks could potentially break the machine!

Here's a nice little bit you can to look at:

/proc/sys/vm

Start playing with parameters - but do read a bit first. The entire kernel is tunable, to such an extent that if you don't know what you're doing, bad things are going to happen.

I recommend against tweaks, in general, on all OS, because 7 months later, you don't really remember what you changed that makes this or that not really work :)

The best way to "tweak" is to compile your own kernel on your own system and turn off everything you don't need. But even I don't bother with something like that. If it works, let it be.

Mrk

chronomatic
April 28th, 2009, 02:48 PM
The biggest thing for me is using relatime or noatime in /etc/fstab. However, I just checked my Ubuntu Jaunty install and it already uses relatime by default. So no need to tweak that if you're using Jaunty. The reason these are important is because of the way Linux updates atime and the disk IO it uses.

Here is an exchange by two kernel hacker extraordinaires on the noatime/relatime benefit:

Linus Torvalds wrote:

-{ Quote: "Yes, that's independent. The fact is, ext3 *sucks* at fsync. I hate hate
hate it. It's totally unusable, imnsho.

The whole point of fsync() is that it should sync only that one file, and
avoid syncing all the other stuff that is going on, and ext3 violates
that, because it ends up having to sync the whole log, or something like
that. So even if vim really wants to sync a small file, you end up waiting
for megabytes of data being written out.

I detest logging filesystems.

Linus" }-


Igno Molnar responded:
-{ Quote: "-{ Quote: "
yeah, it's really ugly. But otherwise i've got no real complaint about
ext3 - with the obligatory qualification that "noatime,nodiratime" in
/etc/fstab is a must. This speeds up things very visibly - especially
when lots of files are accessed. It's kind of weird that every Linux
desktop and server is hurt by a noticeable IO performance slowdown due
to the constant atime updates, while there's just two real users of it:
tmpwatch [which can be configured to use ctime so it's not a big issue]
and some backup tools. (Ok, and mail-notify too i guess.) Out of tens of
thousands of applications. So for most file workloads we give Windows a
20%-30% performance edge, for almost nothing. (for RAM-starved kernel
builds the performance difference between atime and noatime+nodiratime
setups is more on the order of 40%)

Ingo" }-" }-

You can read that whole exchange between Torvalds and Molnar here. (http://kerneltrap.org/node/14148) I should also mention that I am not sure if this "problem" applies to ext4 or not. I have not researched it.

You can also read up on something called "preload" and "readahead." These two options help with speeding up boot. Preload does what SuperFetch does on Vista. Vista's SuperFetch is a copy of Linux's preload (yep, Linux had it first).

FluxGFX
April 28th, 2009, 03:03 PM
-{ Quote: "Beware that serious tweaks could potentially break the machine!

Here's a nice little bit you can to look at:

/proc/sys/vm

Start playing with parameters - but do read a bit first. The entire kernel is tunable, to such an extent that if you don't know what you're doing, bad things are going to happen.

I recommend against tweaks, in general, on all OS, because 7 months later, you don't really remember what you changed that makes this or that not really work :)

The best way to "tweak" is to compile your own kernel on your own system and turn off everything you don't need. But even I don't bother with something like that. If it works, let it be.

Mrk" }-
I'm all up to f*cking it up! I mean thats how you learn but then again I also have a backup of my current state so I'm not worried.

tlu
April 29th, 2009, 12:00 PM
-{ Quote: "The biggest thing for me is using relatime or noatime in /etc/fstab. However, I just checked my Ubuntu Jaunty install and it already uses relatime by default. So no need to tweak that if you're using Jaunty. " }-

Yes, and according to this (http://www.linux-mag.com/id/7271/3/) test ext4 doesn't benefit from other mount options.

Arup
April 29th, 2009, 04:32 PM
Readahead is also implemented in Jaunty.

wj32
May 1st, 2009, 04:05 AM
Any thoughts on Preload (http://www.techthrob.com/2009/03/02/drastically-speed-up-your-linux-system-with-preload/)?

Arup
May 1st, 2009, 05:01 AM
With current Kernel optimizations and file systems like ext4, preload is redundant and hardly shows much improvement, OTOH, it runs as root so not a really good idea as it keeps a list of programs by their access patterns, also it has not been updated for a long while so all in all, not a good idea, readahead is already implemented in Jaunty.

Nick Rhodes
May 1st, 2009, 03:39 PM
-{ Quote: "Any thoughts on Preload (http://www.techthrob.com/2009/03/02/drastically-speed-up-your-linux-system-with-preload/)?" }-

Yes i've run it for over a year without problem.
Eclipse and Open Office load far much quicker first time round after a reboot (and the cache is empty).

Nick Rhodes
May 1st, 2009, 03:47 PM
-{ Quote: "With current Kernel optimizations and file systems like ext4, preload is redundant and hardly shows much improvement, OTOH, it runs as root so not a really good idea as it keeps a list of programs by their access patterns, also it has not been updated for a long while so all in all, not a good idea, readahead is already implemented in Jaunty." }-

Readahead only works on system boot, anything from the session onwards does not benefit.

Why do you think is it not a good idea that preload runs as root ?

Its a very simple little app do I guess it does not need much updating, you can see the change log : http://changelogs.ubuntu.com/changelogs/pool/universe/p/preload/preload_0.4-5/changelog

Arup
May 1st, 2009, 04:07 PM
-{ Quote: "Readahead only works on system boot, anything from the session onwards does not benefit.

Why do you think is it not a good idea that preload runs as root ?

Its a very simple little app do I guess it does not need much updating, you can see the change log : http://changelogs.ubuntu.com/changelogs/pool/universe/p/preload/preload_0.4-5/changelog" }-

I have used preload in past with Hardy and never saw any appreciative speed increase of apps, probably most apps in Linux load quick anyways to begin with. With Jaunty and ext4 its even quicker. Also the fact that its a daemon running with root privildeges just makes me paranoid but its fine if its works for you and others.

wilbertnl
May 2nd, 2009, 01:02 AM
-{ Quote: "The reason these are important is because of the way Linux updates atime and the disk IO it uses." }- Guess what?
-{ Quote: "One might think that the ext3 filesystem, by virtue of being standard on almost all installed Linux systems for some years now, would be reasonably well tuned for performance. Recent events have shown, though, that some performance problems remain in ext3, especially in places where the fsync() system call is used. It's impressive what can happen when attention is drawn to a problem; the 2.6.30 kernel will contain fixes which seemingly eliminate many of the latencies experienced by ext3 users. This article will look at the changes that were made, including a surprising change to the default journaling mode made just before the 2.6.30-rc1 release. " }-
Source (http://lwn.net/Articles/328363/).

Nick Rhodes
May 2nd, 2009, 04:11 AM
OK heres the only tweak I do.... enable laptop mode !

It is disabled by default as various machines do not behave well with it.

https://wiki.ubuntu.com/PowerManagement#How%20to%20get%20disks%20idleing%20correctly%20(without%20excessive%20load%20cycling)

I tweak some of the settings in /etc/laptop-mode/laptop-mode.conf, for example I do not like the readahead settings used.

Its a very straight forward config file to edit - have a read and look at the comments, just make a copy before playing the settings.

FluxGFX
May 2nd, 2009, 05:18 PM
Lets get back on the subject of Ubuntu tweaks.... What else could one do just to spice things up?

Cheer,
fluxgfx

chronomatic
May 2nd, 2009, 05:24 PM
-{ Quote: "Lets get back on the subject of Ubuntu tweaks.... What else could one do just to spice things up?

Cheer,
fluxgfx" }-


Overclock your CPU using liquid Nitrogen. Perhaps you will hit 8GHz which will spice things up nicely. 8)

FluxGFX
May 2nd, 2009, 05:27 PM
Smart AS S! I've already overclocked the Wolfdale E5300 to be a bit more performant then the E8400. I'm working on overclocking the eVGA GTS 250 now :)

LoL

Arup
May 2nd, 2009, 11:55 PM
http://www.debian-administration.org/articles/199

Setting to shell makes Ubuntu use all your cores for boot. I am pretty satisfied with boot speed. You can also disable all the services you are not using via the startup applications tab.

wj32
May 3rd, 2009, 02:47 AM
I've had weird problems with using "shell" - does it account for dependencies?

Arup
May 3rd, 2009, 03:39 AM
-{ Quote: "I've had weird problems with using "shell" - does it account for dependencies?" }-

See the Netbook Remix enables the shell in the init.d but on their regular desktop distro its left untouched.

Nick Rhodes
May 3rd, 2009, 04:06 AM
Will using "shell" make a difference in Jaunty ?

Mrkvonic
May 3rd, 2009, 06:58 AM
What do you mean by using shell ...?
Mrk

Nick Rhodes
May 3rd, 2009, 07:08 AM
-{ Quote: "What do you mean by using shell ...?
Mrk" }-

In /etc/init.d/rc you can set concurrency of init script execution on startup.

Here's the comment from Intrepid:

# Specify method used to enable concurrent init.d scripts.
# Valid options are 'none', 'shell' and 'startpar'. To enable the
# concurrent boot option, the init.d script order must allow for
# concurrency. This is not the case with the default boot sequence in
# Debian as of 2008-01-20. Before enabling concurrency, one need to
# check the sequence values of all boot scripts, and make sure only
# scripts that can be started in parallel have the same sequence
# number, and that a scripts dependencies have a earlier sequence
# number. See the insserv package for a away to reorder the boot
# automatically to allow this.
CONCURRENCY=none


It works by backgrounding the init scripts as they are run (like you can do from any shell).

Mrkvonic
May 3rd, 2009, 08:26 AM
I see what you meant now ... Didn't read the linked page ...

startpar can be useful and you can use it without worry if you did not insert any services manually, so the numbering has been configured beforehand. I've never used shell.

Either way, you can use bootchart to profile the sequences in different modes and see if there are problems, delays or dependencies.

Mrk

FluxGFX
May 3rd, 2009, 10:07 AM
Ok so I might be blond this morning but in /etc/init.d/rc I can't find the "startup $i start", it's not part of my script. Now if I did want to include the following "startup $i start &", were would I include it?

Cheers,
fluxgfx