Maximize Desktop Speed
No Prelink Needed in Ubuntu or Debian?
Recent Ubuntu and Debian distributions include a different mechanism for speeding application loading and a new linking mechanism that speeds up the linking process without using prelink.
To enable the faster startup times, do sudo apt-get install preload, and from that moment on, Linux monitors which applications you run and fetches those binaries and libraries into memory.
For example, if you use Firefox and OpenOffice.org every day, preload will determine that those two are common applications and will keep the needed libraries in RAM. Of course, should you change to Seamonkey and KOffice, preload eventually will detect your change of habits and do the appropriate thing.
Every time you create, modify or simply access a file, Linux dutifully records the current timestamp in its directory structures. In particular, the latter update obviously implies a penalty on file access time. Even if you merely read a file (without changing anything), Linux updates the file's inode (see Resources for more on inodes) with the current timestamp. Because writes obviously require some time, doing away with these updates results in performance gains.
In order to achieve this enhancement, you need to change the way the filesystem is mounted. Working as root, do cat /etc/fstab to get the following:
/dev/hda1 /boot ext2 acl,user_xattr 1 2 /dev/hda2 swap swap defaults 0 0 /dev/hda3 / reiserfs acl,user_xattr 1 1 /dev/hdd1 /media/disk2 reiserfs defaults 1 2 /dev/hdc /media/cdrom udf,iso9660 ro,user,noauto 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 debugfs /sys/kernel/debug debugfs noauto 0 0 usbfs /proc/bus/usb usbfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0
Given this output, the best candidates for the optimization are / and /dev/hdd1; /boot is used only when booting, /swap is out of bounds for you, and the others are not hard disks.
Making the change is simple. With your favorite text editor, add ,noatime to the options in the fourth column. When you are done, issue the mount -a command to remount all partitions, and then issue a plain mount to check whether the changes were done (Listing 2).
Listing 2. Checking the New Parameters with mount
$ mount -a $ mount /dev/hda3 on / type reiserfs (rw,noatime,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) udev on /dev type tmpfs (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/hda1 on /boot type ext2 (rw,acl,user_xattr) /dev/hdd1 on /media/disk2 type reiserfs (rw,noatime)
Notice the noatime parameters in the /dev/hda3 and /dev/hdd1 lines. Those mean you did everything right, and access times are no longer being recorded.
By the way, if you research this on the Web, you may find a reference to another option, nodiratime, which has to do with directories. Do not bother setting this option, because noatime implies nodiratime.
I ran some tests (creating lots of files, and copying them to /dev/null) and timed the results both with and without the noatime option and found some small performance enhancements—every little bit helps.
Now, if you gotten this far, you're ready for the big one: enhancing your kernel.
Data Integrity vs. Speed?
Googling for filesystem performance enhancements, you might come upon a suggestion for ext3 and ReiserFS, involving another mounting option: data=writeback. This option effectively undoes the advantage of those two filesystems by partially disabling their journaling. (Journaling is what ensures that your data won't be lost, even after a system crash.) If you include data=writeback, you'll gain an increase in speed at the cost of having old data show up after a crash. I don't like this kind of risk, so I don't use that option.
All the tweaks we have done so far are just part of the job, and you even can get a bit more speed if you recompile your kernel and adjust it optimally for your specific hardware and needs. Note that even though compiling a full kernel isn't the challenge it used to be (mainly you just have to make a few choices and key in some commands), there still is room for botching things up. Don't try this unless you feel comfortable.
Most distributions usually provide a one-size-fits-all kernel compiled with the most generic options, which should work for everybody. Of course, this won't necessarily fit your specific case. If your box has an Athlon XP CPU (as my laptop does), or many processors, or a certain graphics card, the generic kernel won't take advantage of them. What to do? You can tweak some kernel options and recompile it for optimal performance. Here, I pay specific attention to the options that enhance speed and responsiveness.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Keeping track of IP address
24 min 53 sec ago - Roll your own dynamic dns
5 hours 38 min ago - Please correct the URL for Salt Stack's web site
8 hours 49 min ago - Android is Linux -- why no better inter-operation
11 hours 5 min ago - Connecting Android device to desktop Linux via USB
11 hours 33 min ago - Find new cell phone and tablet pc
12 hours 31 min ago - Epistle
14 hours 32 sec ago - Automatically updating Guest Additions
15 hours 9 min ago - I like your topic on android
15 hours 55 min ago - This is the easiest tutorial
22 hours 31 min ago




Comments
How to get rid of fonts?
OK, so 'xfontsel' shows I have over 10K fonts. Many of the families are clearly foreign languages, that came with install. How do I get rid of some of them? 'apropos font' was no help, and 'adept' indicated I didn't have any font packages installed. I use Kubuntu. 'man apt-get' didn't give me a clue about finding font packages. Suggestions? Thanks.
Wrong information about prelink
The section about prelink is incorrectly stating that...
Using prelink in this way obviously requires more disk space (for there will be a copy of every prelinked library within each executable file), but with the current large disks, this won't even be noticed.
This is complete rubbish ! The author is clearly confusing rewriting the relocation tables with hard-wiring the libraries in executables. The scheme set up by the author would turn all binaries into static linked programs. Nothing is less true ! As a simple peek at the man page (or even Wikipedia) reveals, only the relocation tables are rewritten such that when a library is loaded into memory, it's symbols sits at the right spot in the virtual memory, such that the calculation of the symbol locations no longer needs to be done, but is exactly there where the program expects them.
So prelinking does not use a single byte (apart from the lightweight checksum mechanism) more disk space.
Another blatant fault:
Include the -m option so prelink will try to conserve memory, if you have many libraries in your system (highly likely) and not a very large memory.
This has *nothing* to do with your actual memory, but with the 4GB virtual address space limit on 32bit systems ! It just means that, _if_ each library was used in a single program (and that's what prelink allows without the -m option), you'd exceed the virtual address space limit. The solution is to see which libraries are mutually exclusive linked and let them overlap in virtual memory, as they'll never occur at the same time in the same process.
This article is also quite mediocre in the section about compiling a kernel, you're supposed to know how many RAM your system has. Wrong again. It's perfectly safe/performant to turn on "High Memory Support (4GB)", even if you only got 1GB. And the instructions for compiling a kernel are of the lesser quality I've seen around. You, a daring non-kernel hacking user, should nowadays only install a kernel through your packaging system (like make-kpkg for Debian/Ubuntu) and not using the good old 'make' command, which might as well overwrite your current kernel image and leave your system in an unbootable state (for example, when initrd support has been omitted and your filesystem drivers are compiled as modules.)
This article had good intentions, but the proof reading (if any) clearly missed some faults.