https://wiki.archlinux.org/api.php?action=feedcontributions&user=Rttommy&feedformat=atomArchWiki - User contributions [en]2024-03-28T20:24:57ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Improving_performance&diff=167219Improving performance2011-10-23T18:55:46Z<p>Rttommy: /* Mount options */</p>
<hr />
<div>[[Category:Hardware (English)]]<br />
[[Category:Software (English)]]<br />
{{i18n|Maximizing Performance}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there are some basic indications:<br />
* If the computer becomes slow when big applications, like OpenOffice.org and Firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40MB/s (assuming drive tested while idle) can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. First step would be to verify if direct rendering simply is not enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run lightweight environments and applications.<br />
* Use a [[Window Manager|window manager]] instead of a [[Desktop Environment]]. Choices include [[dwm]], [[wmii]], [[Awesome]], [[Openbox]], [[Fluxbox]] and [[JWM]].<br />
* Choose a minimal Desktop Environment over [[GNOME]] and [[KDE]]. Choices include [[LXDE]] and [[Xfce]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008], [http://bbs.archlinux.org/viewtopic.php?id=78490 2009],[http://bbs.archlinux.org/viewtopic.php?id=88515 2010], and [http://bbs.archlinux.org/viewtopic.php?id=111878 2011].<br />
* Remove unnecessary [[daemons]] and background what daemons you can in {{Filename|/etc/rc.conf}}.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be measured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Patritioning===<br />
The partition layout can influence the system's performance. Sectors at the beginning of the drive (closer to the center of the disk) are faster than those at the end. Also, a smaller partition requires less movements from the drive's head, and so speed up disk operations. Therefore, it is advised to create a small partition (10gb, more or less depending on your needs) only for your system, as near to the beginning of the drive as possible. Other data (pictures, videos) should be kept on a separate partition, and this is usually achieved by separating the home directory (/home/user) from the system (/).<br />
<br />
===Choosing and tuning your filesystem===<br />
Choosing the best filesystem for a specific system is very important because each has its own strengths. The [[Beginner%27s_Guide#Filesystem_types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [[:Category:File systems (English)|here]].<br />
<br />
====Summary====<br />
*XFS: Excellent performance with large files. Low speed with small files. A good choice for /home.<br />
*Reiserfs: Excellent performance with small files. A good choice for /var.<br />
*Ext3: Average performance, reliable.<br />
*Ext4: Great overall performance, reliable, has performance issues with sqlite and some other databases.<br />
*JFS: Good overall performance, very low CPU usage, extremely fast resume after power failure.<br />
*Btrfs: Probably best overall performance (with compression) and lots of features. Still in heavy development and fully supported, but considered as unstable. Do not use this filesystem yet unless you know what you are doing and are prepared for potential data loss.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
The mount options {{Codeline|noatime,nodiratime}} are known for improving performance on almost all file-systems. The former is a superset of the latter (which applies to directories only -- {{Codeline|noatime}} applies to both files and directories). In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option (NB relatime is the default in >2.6.30)<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====Ext4====<br />
See the [[Ext4#Improving performance | Ext4 wiki page]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,lazy-count=1,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. <br />
<br />
#/etc/fstab<br />
LABEL=XFSHOME /home xfs noatime,logbufs=8 0 1<br />
<br />
==== Reiserfs ====<br />
<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is done when creating the filesystem: <br />
<br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data. You can learn more about reiserfs with this [http://www.funtoo.org/en/articles/linux/ffg/2/ article].<br />
<br />
====BTRFS====<br />
See [[Btrfs#Defragmentation|defragmentation]] and [[Btrfs#Compression|compression]].<br />
<br />
===Compressing {{Filename|/usr}}===<br />
{{Note|As of version 3.0 of the linux kernel aufs2 is no longer supported.}}<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress {{Filename|/usr}} in a squashfs file, with a 64k(128k) block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. What this tutorial does is basically to compress the {{Filename|/usr}} folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of {{Filename|/usr}}, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so {{Filename|/usr}} must be re-compressed periodically. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel.<br />
Since the linked guide is for Gentoo the next commands outline the steps especially for Arch. Basically we have got install two packages to get it working:<br />
# pacman -S aufs2 squashfs-tools<br />
This command installs the aufs-modules and some userspace-tools for the squash-filesystem.<br />
Now we need some extra directories where we can store the archive of {{Filename|/usr}} as read-only and another folder where we can store the data changed after the last compression as writeable:<br />
# mkdir -p /squashed/usr/{ro,rw}<br />
Now that we got a rough setup you should perform a complete system-upgrade since every change of content in {{Filename|/usr}} after the compression will be excluded from this speedup. If you use prelink you should also perform a complete prelink before creating the archive. Now it is time to invoke the command to compress {{Filename|/usr}}:<br />
# mksquashfs /usr /squashed/usr/usr.sfs -b 65536<br />
These parameters/options are the ones suggested by the Gentoo link but there might be some room for improvement using some of the options described [http://www.tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html#mksqusing here].<br />
Now to get the archive mounted together with the writeable folder it is necessary to edit {{Filename|/etc/fstab}}:<br />
# nano /etc/fstab<br />
Add the following lines:<br />
/squashed/usr/usr.sfs /squashed/usr/ro squashfs loop,ro 0 0 <br />
usr /usr aufs udba=reval,br:/squashed/usr/rw:/squashed/usr/ro 0 0<br />
Now you should be done and able to reboot. The original Author suggests to delete all the old content of {{Filename|/usr}}, but this might cause some problems if anything goes wrong during some later re-compression. It is more safe to leave the old files in place just to be on the safe side.<br />
<br />
A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate the process of re-compressing (read updating) the archive since the tutorial is meant for Gentoo and some options do not correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
[[SSD#Tips_for_Maximizing_SSD_Performance]]<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel motherboards are notorious for disabling the capacity to overclock.<br />
<br />
A way to modify performance ([http://lkml.org/lkml/2009/9/6/136 ref]) is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler (CFS) with the Brain Fuck Scheduler (BFS).<br />
<br />
Kernel PKGBUILDs that include the BFS patch can be installed from the [[AUR]] or [[Unofficial User Repositories]]. See the respective pages for {{Package AUR|linux-ck}} and [https://wiki.archlinux.org/index.php/Linux-ck linux-ck wiki page], {{Package AUR|linus-bfs}} or {{Package AUR|linux-pf}} for more information on their additional patches.<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.37/2.6.37-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[[Verynice]] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritization greatly improves system responsiveness under heavy load.<br />
<br />
===Ulatencyd===<br />
[[Ulatencyd]] is a daemon that controls how the Linux kernel will spend its resources on the running processes. It uses dynamic cgroups to give the kernel hints and limitations on processes.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recommendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. Intel chipsets users can install [http://www.gmabooster.com/ GMABooster] from [http://aur.archlinux.org/packages.php?ID=28197 AUR]<br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
=== Swappiness ===<br />
<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
<br />
vm.swappiness=20<br />
vm.vfs_cache_pressure=50<br />
<br />
To test and more on why this may work, take a look at this [http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that article].<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache], also known as the zram kernel module, creates a device in RAM and compresses it. If you use for swap means that part of the RAM can hold much more information but uses more CPU. Still, it is much quicker than swapping to a hard drive. If a system often falls back to swap, this could improve responsiveness. Zram is in mainline staging (therefore its not stable yet, use with caution).<br />
<br />
For swap you can try using<br />
<br />
modprobe zram<br />
echo $((50*1024*1024)) > /sys/block/zram0/disksize<br />
mkswap /dev/zram0<br />
swapon -p 60 /dev/zram0<br />
<br />
To make the changes permanent, add zram module to {{Filename|/etc/rc.conf}} and autostart by adding the following lines to {{Filename|/etc/rc.local}}:<br />
<br />
echo $((50*1024*1024)) > /sys/block/zram0/disksize<br />
mkswap /dev/zram0<br />
swapon -p 60 /dev/zram0<br />
<br />
You will have a 50MB swap with higher priority than your regular swap.<br />
<br />
This is also a good way to reduce disk read/write cycles due to swap on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,nodev,nosuid,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
=== Preloading ===<br />
Preloading is the action of putting and keeping target files into the RAM. The practical use is that preloaded applications always start very quickly, because reading from the RAM is always quicker than from the hard drive. However, part of your RAM will be dedicated to this task, but no more than if you kept the application open. Therefore, preloading is best used with heavy, often-used applications, like firefox and openoffice.<br />
==== Go-preload ====<br />
[http://aur.archlinux.org/packages.php?ID=34207 Go-preload] is a small daemon created in the [http://forums.gentoo.org/viewtopic-t-789818-view-next.html?sid=5457cff93039fc7d4a3e445ef90f9821 gentoo forum]. To use it, first run this command in a terminal for each program you want to preload at boot:<br />
# gopreload-prepare program<br />
Then, as instructed, press enter when the program is fully loaded. This will add a list of files needed by the program in {{Filename|/usr/share/gopreload/enabled}}. To load all lists at boot, simply add gopreload to your DAEMONS array in {{Filename|/etc/rc.conf}}. To disable the loading of a program, remove the appropriate list in {{Filename|/usr/share/gopreload/enabled}}, or move it to {{Filename|/usr/share/gopreload/disabled}}.<br />
====Preload====<br />
A more automated, albeit less KISS, approach is used by [[Preload]]. All you have to do is add it to your DAEMONS array in {{Filename|/etc/rc.conf}}. It will monitor the most used files on your system, and with time build its own list of files to preload at boot.<br />
====Readahead====<br />
[[Readahead]] is a tool that can cache files before needed and help you accelerating program loading.<br />
<br />
==Boot time==<br />
You can find tutorials with good tips in the article [[Improve Boot Performance]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The {{Codeline|fastboot}} option usually can take off one second or so. Also, if you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox Tips and Tweaks#Improve rendering by disabling pango |disabling pango]] and [[Firefox Tips and Tweaks#Defragment the profile's SQLite databases|cleaning the sqlite database]]. See also: [[Speed-up Firefox using tmpfs]] and [[Firefox Tips and Tweaks#Turning off anti-phishing|Turning off anti-phishing]].<br />
Firefox in the official repositories is built with the profile guided optimization flag enabled. You may want to use it in your custom build.<br />
To do this append<br />
ac_add_options --enable-profile-guided-optimization<br />
to your mozconfig.<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===LibreOffice===<br />
See [[LibreOffice#Speed up LibreOffice|Speed up LibreOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].<br />
<br />
==Laptops==<br />
See [[Laptop]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Btrfs&diff=167218Btrfs2011-10-23T18:53:55Z<p>Rttommy: /* Compression */</p>
<hr />
<div>[[Category:File systems (English)]]<br />
{{i18n|Btrfs}}<br />
<br />
Btrfs is a new copy on write filesystem for Linux aimed at implementing advanced features while focusing on fault tolerance, repair and easy administration. Initially developed by Oracle, Btrfs is licensed under the GPL and open for contribution from anyone.<br />
<br />
Linux has a wealth of filesystems to choose from, but we are facing a number of challenges with scaling to the large storage subsystems that are becoming common in today's data centers. Filesystems need to scale in their ability to address and manage large storage, and also in their ability to detect, repair and tolerate errors in the data stored on disk.<br />
<br />
Btrfs is under heavy development, but every effort is being made to keep the filesystem stable and fast. As of 2.6.31, they only plan to make forward compatible disk format changes.<br />
<br />
{{Warning|Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that do not handle flush requests correctly. This will be fixed when the fsck tool is ready.}}<br />
<br />
== Installation ==<br />
<br />
To install:<br />
<br />
<pre>pacman -S btrfs-progs-unstable</pre><br />
<br />
There are also [http://aur.archlinux.org/packages.php?ID=22578 btrfs-progs-git] in AUR.<br />
<br />
If using btrfs as your root filesystem, you may also want to install [http://aur.archlinux.org/packages.php?ID=33376 mkinitcpio-btrfs] from AUR. This package will install a mkinitcpio hook intended for those who wish to have a single or multi-drive BTRFS file system as their / (root). The hook will ensure that the chosen root device from the kernel command line is intact and safe to boot. If root is not a BTRFS device, the hook is quietly skipped.<br />
<br />
== Basic Use ==<br />
<br />
To format a device to btrfs<br />
<br />
<pre>mkfs.btrfs [options] dev [dev ...]</pre><br />
<br />
You can select multiple devices to create a raid. Supported raids include raid1, raid0, and raid 10. By default, metadata is mirrored and data is striped.<br />
<br />
=== Subvolumes ===<br />
<br />
One of the features of btrfs is the use of subvolumes. Subvolumes are basically a named btree that holds files and directories. They have inodes inside the tree of tree roots and can have non-root owners and groups. Subvolumes can be given a quota of blocks, and once this quota is reached no new writes are allowed. All of the blocks and file extents inside of subvolumes are reference counted to allow snapshotting. Similar to the dynamically expanding storage of a virtual machine that will only use as much space on a device as needed. Eliminating several half-filled partitions. You can also mount the subvolumes with different mount options giving more flexibility in security. <br />
<br />
To create a subvolume:<br />
<br />
<pre><br />
btrfs subvolume create [<dest>/]<br />
</pre><br />
<br />
For flexibility, you should install your system INTO A DEDICATED SUBVOLUME, and use:<br />
<br />
<pre>rootflags=subvol=<whatever you called the subvol></pre><br />
<br />
in your kernel boot parameters. It makes system rollbacks possible.<br />
<br />
If using for your root partition you'll want to add crc32c to the modules array in your {{Filename|/etc/mkinitcpio.conf}} as well as add {{Filename|btrfs}} to the HOOKS array.<br />
<br />
=== Snapshots ===<br />
<br />
To create a snapshot:<br />
<br />
<pre>btrfs subvolume snapshot <source> [<dest>/]<name></pre><br />
<br />
Snapshots are not recursive, this means that every subvolume inside subvolume will be an empty directory inside the snapshot.<br />
== Defragmentation ==<br />
Btrfs supports online defragmentation. To defragment the whole system, simply do:<br />
sudo btrfs filesystem defragment /<br />
== Compression ==<br />
Btrfs supports transparent compression, which means every file on the partition is automatically compressed. This does not only reduce the size of those files, but also [http://www.phoronix.com/scan.php?page=article&item=btrfs_compress_2635&num=1 improves performance], in particular if using the [http://www.phoronix.com/scan.php?page=article&item=btrfs_lzo_2638&num=1 lzo alogorithm]. Compression is enabled using the compress=gzip or compress=lzo mount options. Only files created or modified after the mount option is added will be compressed, so to fully benefit from compression it should be enabled during installation. After [[Beginners%27_Guide#Prepare_Hard_Drive|preparing the hard drive]], simply switch to another terminal (Ctrl+Alt+number), and run the following command:<br />
sudo mount -o remount,compress=lzo /dev/partition /mnt/target # note: replace /dev/partition by the partition on which you install Arch Linux.<br />
You can verify if compression is enabled with the mount command. After the installation is finished, add compress=lzo to the mount options of the root filesystem in {{Filename|/etc/fstab}}.<br />
<br />
== See also ==<br />
* [[Installing_on_Btrfs_root]]<br />
<br />
== Troubleshooting ==<br />
<br />
=== Problems with operations on files, silent fails of copying ===<br />
Fiemap support was implemented badly in kernels older than mainline '''2.6.38-rc6-git6 kernel''' - which was proved by '''coreutils''' package in version '''8.10''' and it's internal copying function (first with fiemap support).<br />
<br />
The bug exist only if '''compressed btrfs''' volume is present and can cause '''lots of damage''' like the installation of broken packages.<br />
<br />
coreutils 8.10 + kernel<2.6.38-rc6-git6 + compresses btrfs = really bad idea.<br />
<br />
If you are using older kernel either turn btrfs' compression off or downgrade coreutils.<br />
<br />
=== Segfault after power failure upon mounting root ===<br />
<br />
After power failures Btrfs ends up not booting, instead just segfaulting. This can be fixed with <pre>btrfs-zero-log /dev/sdX#</pre>. To build btrfs-zero-log, you need to get it from the git:<br />
<pre>git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git<br />
make <br />
make btrfs-zero-log</pre><br />
<br />
If the build fails with <pre>ctree.c: In function '__btrfs_cow_block':<br />
ctree.c:265:6: error: variable 'generation' set but not used [-Werror=unused-but-set-variable]<br />
</pre>, you need to patch the makefile with -Wno-error to make it ignore errors. <br />
<br />
btrfs-zero-log is also now available in AUR pkg btrfs-progs-git available [http://aur.archlinux.org/packages.php?ID=22578 HERE]<br />
<br />
[http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg08836.html Original thread]<br />
<br />
=== still having trouble ===<br />
<br />
Unfortunately there is still '''no official repair tool''' for btrfs available (although told so often for a long time now). If you still have troubles, it might be worth to experiment (!) with some more tools.<br />
<br />
Try to checkout the next branch of btrfs-progs from git:<br />
<br />
<pre>git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git -b next</pre><br />
<br />
There you find '''newer btrfs tools'''. Also you will find '''btrfs-select-super''' which is reported to solve some issues (try with -s1 as for btrfsck). Also try to play around with btrfs, btrfsctl and other tools you will find in there.<br />
If your kernel oops state anything related to log try to use '''btrfs-zero-log''' and you should be fine. You will loose the last operations on your filesystem (about 30sec before the crash) but you are able to mount and use your device again.<br />
<br />
As of now, it is strongly advised '''not to use 2.6 kernels''' anymore. If you are on a 3.0 kernel, get the most current version of btrfs tools from Hugo's integration-20110805 branch at http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ and do a scrub.<br />
<br />
If you have to boot a '''recovery image''' try to use '''archboot''' and manually (re)install glibc, gcc, gcc-libs, make, gmp, openssl, libarchive, git, file, acl, linux-api-headers, e2fsprogs, coreutils, attr and also util-linux as there are some headers missing in archboot which are needed to compile btrfs-progs-unstable.<br />
<br />
Lets hope that there will be a release of the often announced btrfs repair tools available very soon!<br />
<br />
=== TroubleShooting Links ===<br />
<br />
If you still have issues check the official '''BTRFS Problem FAQ''' in their Wiki at https://btrfs.wiki.kernel.org/index.php/Problem_FAQ<br />
<br />
Also have a look to use '''up to date source code repositories''' for btrfs-progs and kernel, try the integration repositories as well if you still have issues: <br />
https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories<br />
<br />
== Resources ==<br />
<br />
* [https://btrfs.wiki.kernel.org Btrfs Wiki]<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=794046 Arch Forums "Fresh Install with Btrfs"]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=88195 Arch Forums "BTRFS mkinitcpio hook"]<br />
* [https://btrfs.wiki.kernel.org/index.php/Problem_FAQ "Problem FAQ in BTRFS Wiki"]<br />
* [https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories "BTRFS Source Repositories"]</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=167217Improving performance2011-10-23T18:51:39Z<p>Rttommy: /* Storage devices */</p>
<hr />
<div>[[Category:Hardware (English)]]<br />
[[Category:Software (English)]]<br />
{{i18n|Maximizing Performance}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there are some basic indications:<br />
* If the computer becomes slow when big applications, like OpenOffice.org and Firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40MB/s (assuming drive tested while idle) can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. First step would be to verify if direct rendering simply is not enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run lightweight environments and applications.<br />
* Use a [[Window Manager|window manager]] instead of a [[Desktop Environment]]. Choices include [[dwm]], [[wmii]], [[Awesome]], [[Openbox]], [[Fluxbox]] and [[JWM]].<br />
* Choose a minimal Desktop Environment over [[GNOME]] and [[KDE]]. Choices include [[LXDE]] and [[Xfce]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008], [http://bbs.archlinux.org/viewtopic.php?id=78490 2009],[http://bbs.archlinux.org/viewtopic.php?id=88515 2010], and [http://bbs.archlinux.org/viewtopic.php?id=111878 2011].<br />
* Remove unnecessary [[daemons]] and background what daemons you can in {{Filename|/etc/rc.conf}}.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be measured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Patritioning===<br />
The partition layout can influence the system's performance. Sectors at the beginning of the drive (closer to the center of the disk) are faster than those at the end. Also, a smaller partition requires less movements from the drive's head, and so speed up disk operations. Therefore, it is advised to create a small partition (10gb, more or less depending on your needs) only for your system, as near to the beginning of the drive as possible. Other data (pictures, videos) should be kept on a separate partition, and this is usually achieved by separating the home directory (/home/user) from the system (/).<br />
<br />
===Choosing and tuning your filesystem===<br />
Choosing the best filesystem for a specific system is very important because each has its own strengths. The [[Beginner%27s_Guide#Filesystem_types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [[:Category:File systems (English)|here]].<br />
<br />
====Summary====<br />
*XFS: Excellent performance with large files. Low speed with small files. A good choice for /home.<br />
*Reiserfs: Excellent performance with small files. A good choice for /var.<br />
*Ext3: Average performance, reliable.<br />
*Ext4: Great overall performance, reliable, has performance issues with sqlite and some other databases.<br />
*JFS: Good overall performance, very low CPU usage, extremely fast resume after power failure.<br />
*Btrfs: Probably best overall performance (with compression) and lots of features. Still in heavy development and fully supported, but considered as unstable. Do not use this filesystem yet unless you know what you are doing and are prepared for potential data loss.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. The former is a superset of the latter (which applies to directories only -- {{Codeline|noatime}} applies to both files and directories). In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option (NB relatime is the default in >2.6.30)<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====Ext4====<br />
See the [[Ext4#Improving performance | Ext4 wiki page]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,lazy-count=1,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. <br />
<br />
#/etc/fstab<br />
LABEL=XFSHOME /home xfs noatime,logbufs=8 0 1<br />
<br />
==== Reiserfs ====<br />
<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is done when creating the filesystem: <br />
<br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data. You can learn more about reiserfs with this [http://www.funtoo.org/en/articles/linux/ffg/2/ article].<br />
<br />
====BTRFS====<br />
See [[Btrfs#Defragmentation|defragmentation]] and [[Btrfs#Compression|compression]].<br />
<br />
===Compressing {{Filename|/usr}}===<br />
{{Note|As of version 3.0 of the linux kernel aufs2 is no longer supported.}}<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress {{Filename|/usr}} in a squashfs file, with a 64k(128k) block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. What this tutorial does is basically to compress the {{Filename|/usr}} folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of {{Filename|/usr}}, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so {{Filename|/usr}} must be re-compressed periodically. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel.<br />
Since the linked guide is for Gentoo the next commands outline the steps especially for Arch. Basically we have got install two packages to get it working:<br />
# pacman -S aufs2 squashfs-tools<br />
This command installs the aufs-modules and some userspace-tools for the squash-filesystem.<br />
Now we need some extra directories where we can store the archive of {{Filename|/usr}} as read-only and another folder where we can store the data changed after the last compression as writeable:<br />
# mkdir -p /squashed/usr/{ro,rw}<br />
Now that we got a rough setup you should perform a complete system-upgrade since every change of content in {{Filename|/usr}} after the compression will be excluded from this speedup. If you use prelink you should also perform a complete prelink before creating the archive. Now it is time to invoke the command to compress {{Filename|/usr}}:<br />
# mksquashfs /usr /squashed/usr/usr.sfs -b 65536<br />
These parameters/options are the ones suggested by the Gentoo link but there might be some room for improvement using some of the options described [http://www.tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html#mksqusing here].<br />
Now to get the archive mounted together with the writeable folder it is necessary to edit {{Filename|/etc/fstab}}:<br />
# nano /etc/fstab<br />
Add the following lines:<br />
/squashed/usr/usr.sfs /squashed/usr/ro squashfs loop,ro 0 0 <br />
usr /usr aufs udba=reval,br:/squashed/usr/rw:/squashed/usr/ro 0 0<br />
Now you should be done and able to reboot. The original Author suggests to delete all the old content of {{Filename|/usr}}, but this might cause some problems if anything goes wrong during some later re-compression. It is more safe to leave the old files in place just to be on the safe side.<br />
<br />
A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate the process of re-compressing (read updating) the archive since the tutorial is meant for Gentoo and some options do not correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
[[SSD#Tips_for_Maximizing_SSD_Performance]]<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel motherboards are notorious for disabling the capacity to overclock.<br />
<br />
A way to modify performance ([http://lkml.org/lkml/2009/9/6/136 ref]) is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler (CFS) with the Brain Fuck Scheduler (BFS).<br />
<br />
Kernel PKGBUILDs that include the BFS patch can be installed from the [[AUR]] or [[Unofficial User Repositories]]. See the respective pages for {{Package AUR|linux-ck}} and [https://wiki.archlinux.org/index.php/Linux-ck linux-ck wiki page], {{Package AUR|linus-bfs}} or {{Package AUR|linux-pf}} for more information on their additional patches.<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.37/2.6.37-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[[Verynice]] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritization greatly improves system responsiveness under heavy load.<br />
<br />
===Ulatencyd===<br />
[[Ulatencyd]] is a daemon that controls how the Linux kernel will spend its resources on the running processes. It uses dynamic cgroups to give the kernel hints and limitations on processes.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recommendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. Intel chipsets users can install [http://www.gmabooster.com/ GMABooster] from [http://aur.archlinux.org/packages.php?ID=28197 AUR]<br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
=== Swappiness ===<br />
<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
<br />
vm.swappiness=20<br />
vm.vfs_cache_pressure=50<br />
<br />
To test and more on why this may work, take a look at this [http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that article].<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache], also known as the zram kernel module, creates a device in RAM and compresses it. If you use for swap means that part of the RAM can hold much more information but uses more CPU. Still, it is much quicker than swapping to a hard drive. If a system often falls back to swap, this could improve responsiveness. Zram is in mainline staging (therefore its not stable yet, use with caution).<br />
<br />
For swap you can try using<br />
<br />
modprobe zram<br />
echo $((50*1024*1024)) > /sys/block/zram0/disksize<br />
mkswap /dev/zram0<br />
swapon -p 60 /dev/zram0<br />
<br />
To make the changes permanent, add zram module to {{Filename|/etc/rc.conf}} and autostart by adding the following lines to {{Filename|/etc/rc.local}}:<br />
<br />
echo $((50*1024*1024)) > /sys/block/zram0/disksize<br />
mkswap /dev/zram0<br />
swapon -p 60 /dev/zram0<br />
<br />
You will have a 50MB swap with higher priority than your regular swap.<br />
<br />
This is also a good way to reduce disk read/write cycles due to swap on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,nodev,nosuid,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
=== Preloading ===<br />
Preloading is the action of putting and keeping target files into the RAM. The practical use is that preloaded applications always start very quickly, because reading from the RAM is always quicker than from the hard drive. However, part of your RAM will be dedicated to this task, but no more than if you kept the application open. Therefore, preloading is best used with heavy, often-used applications, like firefox and openoffice.<br />
==== Go-preload ====<br />
[http://aur.archlinux.org/packages.php?ID=34207 Go-preload] is a small daemon created in the [http://forums.gentoo.org/viewtopic-t-789818-view-next.html?sid=5457cff93039fc7d4a3e445ef90f9821 gentoo forum]. To use it, first run this command in a terminal for each program you want to preload at boot:<br />
# gopreload-prepare program<br />
Then, as instructed, press enter when the program is fully loaded. This will add a list of files needed by the program in {{Filename|/usr/share/gopreload/enabled}}. To load all lists at boot, simply add gopreload to your DAEMONS array in {{Filename|/etc/rc.conf}}. To disable the loading of a program, remove the appropriate list in {{Filename|/usr/share/gopreload/enabled}}, or move it to {{Filename|/usr/share/gopreload/disabled}}.<br />
====Preload====<br />
A more automated, albeit less KISS, approach is used by [[Preload]]. All you have to do is add it to your DAEMONS array in {{Filename|/etc/rc.conf}}. It will monitor the most used files on your system, and with time build its own list of files to preload at boot.<br />
====Readahead====<br />
[[Readahead]] is a tool that can cache files before needed and help you accelerating program loading.<br />
<br />
==Boot time==<br />
You can find tutorials with good tips in the article [[Improve Boot Performance]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The {{Codeline|fastboot}} option usually can take off one second or so. Also, if you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox Tips and Tweaks#Improve rendering by disabling pango |disabling pango]] and [[Firefox Tips and Tweaks#Defragment the profile's SQLite databases|cleaning the sqlite database]]. See also: [[Speed-up Firefox using tmpfs]] and [[Firefox Tips and Tweaks#Turning off anti-phishing|Turning off anti-phishing]].<br />
Firefox in the official repositories is built with the profile guided optimization flag enabled. You may want to use it in your custom build.<br />
To do this append<br />
ac_add_options --enable-profile-guided-optimization<br />
to your mozconfig.<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===LibreOffice===<br />
See [[LibreOffice#Speed up LibreOffice|Speed up LibreOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].<br />
<br />
==Laptops==<br />
See [[Laptop]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=167215Improving performance2011-10-23T18:39:26Z<p>Rttommy: /* BTRFS */</p>
<hr />
<div>[[Category:Hardware (English)]]<br />
[[Category:Software (English)]]<br />
{{i18n|Maximizing Performance}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there are some basic indications:<br />
* If the computer becomes slow when big applications, like OpenOffice.org and Firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40MB/s (assuming drive tested while idle) can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. First step would be to verify if direct rendering simply is not enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run lightweight environments and applications.<br />
* Use a [[Window Manager|window manager]] instead of a [[Desktop Environment]]. Choices include [[dwm]], [[wmii]], [[Awesome]], [[Openbox]], [[Fluxbox]] and [[JWM]].<br />
* Choose a minimal Desktop Environment over [[GNOME]] and [[KDE]]. Choices include [[LXDE]] and [[Xfce]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008], [http://bbs.archlinux.org/viewtopic.php?id=78490 2009],[http://bbs.archlinux.org/viewtopic.php?id=88515 2010], and [http://bbs.archlinux.org/viewtopic.php?id=111878 2011].<br />
* Remove unnecessary [[daemons]] and background what daemons you can in {{Filename|/etc/rc.conf}}.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be measured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your filesystem===<br />
Choosing the best filesystem for a specific system is very important because each has its own strengths. The [[Beginner%27s_Guide#Filesystem_types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [[:Category:File systems (English)|here]].<br />
<br />
====Summary====<br />
*XFS: Excellent performance with large files. Low speed with small files. A good choice for /home.<br />
*Reiserfs: Excellent performance with small files. A good choice for /var.<br />
*Ext3: Average performance, reliable.<br />
*Ext4: Great overall performance, reliable, has performance issues with sqlite and some other databases.<br />
*JFS: Good overall performance, very low CPU usage, extremely fast resume after power failure.<br />
*Btrfs: Great overall performance (better than ext4), reliable (once it becomes stable). Lots of features. Still in heavy development and considered as unstable. Do not use this filesystem yet unless you know what you are doing and are prepared for potential data loss.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. The former is a superset of the latter (which applies to directories only -- {{Codeline|noatime}} applies to both files and directories). In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option (NB relatime is the default in >2.6.30)<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====Ext4====<br />
See the [[Ext4#Improving performance | Ext4 wiki page]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,lazy-count=1,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. <br />
<br />
#/etc/fstab<br />
LABEL=XFSHOME /home xfs noatime,logbufs=8 0 1<br />
<br />
==== Reiserfs ====<br />
<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is done when creating the filesystem: <br />
<br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data. You can learn more about reiserfs with this [http://www.funtoo.org/en/articles/linux/ffg/2/ article].<br />
<br />
====BTRFS====<br />
See [[Btrfs#Defragmentation|defragmentation]] and [[Btrfs#Compression|compression]].<br />
<br />
===Compressing {{Filename|/usr}}===<br />
{{Note|As of version 3.0 of the linux kernel aufs2 is no longer supported.}}<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress {{Filename|/usr}} in a squashfs file, with a 64k(128k) block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. What this tutorial does is basically to compress the {{Filename|/usr}} folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of {{Filename|/usr}}, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so {{Filename|/usr}} must be re-compressed periodically. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel.<br />
Since the linked guide is for Gentoo the next commands outline the steps especially for Arch. Basically we have got install two packages to get it working:<br />
# pacman -S aufs2 squashfs-tools<br />
This command installs the aufs-modules and some userspace-tools for the squash-filesystem.<br />
Now we need some extra directories where we can store the archive of {{Filename|/usr}} as read-only and another folder where we can store the data changed after the last compression as writeable:<br />
# mkdir -p /squashed/usr/{ro,rw}<br />
Now that we got a rough setup you should perform a complete system-upgrade since every change of content in {{Filename|/usr}} after the compression will be excluded from this speedup. If you use prelink you should also perform a complete prelink before creating the archive. Now it is time to invoke the command to compress {{Filename|/usr}}:<br />
# mksquashfs /usr /squashed/usr/usr.sfs -b 65536<br />
These parameters/options are the ones suggested by the Gentoo link but there might be some room for improvement using some of the options described [http://www.tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html#mksqusing here].<br />
Now to get the archive mounted together with the writeable folder it is necessary to edit {{Filename|/etc/fstab}}:<br />
# nano /etc/fstab<br />
Add the following lines:<br />
/squashed/usr/usr.sfs /squashed/usr/ro squashfs loop,ro 0 0 <br />
usr /usr aufs udba=reval,br:/squashed/usr/rw:/squashed/usr/ro 0 0<br />
Now you should be done and able to reboot. The original Author suggests to delete all the old content of {{Filename|/usr}}, but this might cause some problems if anything goes wrong during some later re-compression. It is more safe to leave the old files in place just to be on the safe side.<br />
<br />
A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate the process of re-compressing (read updating) the archive since the tutorial is meant for Gentoo and some options do not correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
[[SSD#Tips_for_Maximizing_SSD_Performance]]<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel motherboards are notorious for disabling the capacity to overclock.<br />
<br />
A way to modify performance ([http://lkml.org/lkml/2009/9/6/136 ref]) is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler (CFS) with the Brain Fuck Scheduler (BFS).<br />
<br />
Kernel PKGBUILDs that include the BFS patch can be installed from the [[AUR]] or [[Unofficial User Repositories]]. See the respective pages for {{Package AUR|linux-ck}} and [https://wiki.archlinux.org/index.php/Linux-ck linux-ck wiki page], {{Package AUR|linus-bfs}} or {{Package AUR|linux-pf}} for more information on their additional patches.<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.37/2.6.37-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[[Verynice]] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritization greatly improves system responsiveness under heavy load.<br />
<br />
===Ulatencyd===<br />
[[Ulatencyd]] is a daemon that controls how the Linux kernel will spend its resources on the running processes. It uses dynamic cgroups to give the kernel hints and limitations on processes.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recommendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. Intel chipsets users can install [http://www.gmabooster.com/ GMABooster] from [http://aur.archlinux.org/packages.php?ID=28197 AUR]<br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
=== Swappiness ===<br />
<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
<br />
vm.swappiness=20<br />
vm.vfs_cache_pressure=50<br />
<br />
To test and more on why this may work, take a look at this [http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that article].<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache], also known as the zram kernel module, creates a device in RAM and compresses it. If you use for swap means that part of the RAM can hold much more information but uses more CPU. Still, it is much quicker than swapping to a hard drive. If a system often falls back to swap, this could improve responsiveness. Zram is in mainline staging (therefore its not stable yet, use with caution).<br />
<br />
For swap you can try using<br />
<br />
modprobe zram<br />
echo $((50*1024*1024)) > /sys/block/zram0/disksize<br />
mkswap /dev/zram0<br />
swapon -p 60 /dev/zram0<br />
<br />
To make the changes permanent, add zram module to {{Filename|/etc/rc.conf}} and autostart by adding the following lines to {{Filename|/etc/rc.local}}:<br />
<br />
echo $((50*1024*1024)) > /sys/block/zram0/disksize<br />
mkswap /dev/zram0<br />
swapon -p 60 /dev/zram0<br />
<br />
You will have a 50MB swap with higher priority than your regular swap.<br />
<br />
This is also a good way to reduce disk read/write cycles due to swap on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,nodev,nosuid,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
=== Preloading ===<br />
Preloading is the action of putting and keeping target files into the RAM. The practical use is that preloaded applications always start very quickly, because reading from the RAM is always quicker than from the hard drive. However, part of your RAM will be dedicated to this task, but no more than if you kept the application open. Therefore, preloading is best used with heavy, often-used applications, like firefox and openoffice.<br />
==== Go-preload ====<br />
[http://aur.archlinux.org/packages.php?ID=34207 Go-preload] is a small daemon created in the [http://forums.gentoo.org/viewtopic-t-789818-view-next.html?sid=5457cff93039fc7d4a3e445ef90f9821 gentoo forum]. To use it, first run this command in a terminal for each program you want to preload at boot:<br />
# gopreload-prepare program<br />
Then, as instructed, press enter when the program is fully loaded. This will add a list of files needed by the program in {{Filename|/usr/share/gopreload/enabled}}. To load all lists at boot, simply add gopreload to your DAEMONS array in {{Filename|/etc/rc.conf}}. To disable the loading of a program, remove the appropriate list in {{Filename|/usr/share/gopreload/enabled}}, or move it to {{Filename|/usr/share/gopreload/disabled}}.<br />
====Preload====<br />
A more automated, albeit less KISS, approach is used by [[Preload]]. All you have to do is add it to your DAEMONS array in {{Filename|/etc/rc.conf}}. It will monitor the most used files on your system, and with time build its own list of files to preload at boot.<br />
====Readahead====<br />
[[Readahead]] is a tool that can cache files before needed and help you accelerating program loading.<br />
<br />
==Boot time==<br />
You can find tutorials with good tips in the article [[Improve Boot Performance]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The {{Codeline|fastboot}} option usually can take off one second or so. Also, if you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox Tips and Tweaks#Improve rendering by disabling pango |disabling pango]] and [[Firefox Tips and Tweaks#Defragment the profile's SQLite databases|cleaning the sqlite database]]. See also: [[Speed-up Firefox using tmpfs]] and [[Firefox Tips and Tweaks#Turning off anti-phishing|Turning off anti-phishing]].<br />
Firefox in the official repositories is built with the profile guided optimization flag enabled. You may want to use it in your custom build.<br />
To do this append<br />
ac_add_options --enable-profile-guided-optimization<br />
to your mozconfig.<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===LibreOffice===<br />
See [[LibreOffice#Speed up LibreOffice|Speed up LibreOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].<br />
<br />
==Laptops==<br />
See [[Laptop]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Btrfs&diff=167214Btrfs2011-10-23T18:38:30Z<p>Rttommy: Added defragmentation</p>
<hr />
<div>[[Category:File systems (English)]]<br />
{{i18n|Btrfs}}<br />
<br />
Btrfs is a new copy on write filesystem for Linux aimed at implementing advanced features while focusing on fault tolerance, repair and easy administration. Initially developed by Oracle, Btrfs is licensed under the GPL and open for contribution from anyone.<br />
<br />
Linux has a wealth of filesystems to choose from, but we are facing a number of challenges with scaling to the large storage subsystems that are becoming common in today's data centers. Filesystems need to scale in their ability to address and manage large storage, and also in their ability to detect, repair and tolerate errors in the data stored on disk.<br />
<br />
Btrfs is under heavy development, but every effort is being made to keep the filesystem stable and fast. As of 2.6.31, they only plan to make forward compatible disk format changes.<br />
<br />
{{Warning|Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that do not handle flush requests correctly. This will be fixed when the fsck tool is ready.}}<br />
<br />
== Installation ==<br />
<br />
To install:<br />
<br />
<pre>pacman -S btrfs-progs-unstable</pre><br />
<br />
There are also [http://aur.archlinux.org/packages.php?ID=22578 btrfs-progs-git] in AUR.<br />
<br />
If using btrfs as your root filesystem, you may also want to install [http://aur.archlinux.org/packages.php?ID=33376 mkinitcpio-btrfs] from AUR. This package will install a mkinitcpio hook intended for those who wish to have a single or multi-drive BTRFS file system as their / (root). The hook will ensure that the chosen root device from the kernel command line is intact and safe to boot. If root is not a BTRFS device, the hook is quietly skipped.<br />
<br />
== Basic Use ==<br />
<br />
To format a device to btrfs<br />
<br />
<pre>mkfs.btrfs [options] dev [dev ...]</pre><br />
<br />
You can select multiple devices to create a raid. Supported raids include raid1, raid0, and raid 10. By default, metadata is mirrored and data is striped.<br />
<br />
=== Subvolumes ===<br />
<br />
One of the features of btrfs is the use of subvolumes. Subvolumes are basically a named btree that holds files and directories. They have inodes inside the tree of tree roots and can have non-root owners and groups. Subvolumes can be given a quota of blocks, and once this quota is reached no new writes are allowed. All of the blocks and file extents inside of subvolumes are reference counted to allow snapshotting. Similar to the dynamically expanding storage of a virtual machine that will only use as much space on a device as needed. Eliminating several half-filled partitions. You can also mount the subvolumes with different mount options giving more flexibility in security. <br />
<br />
To create a subvolume:<br />
<br />
<pre><br />
btrfs subvolume create [<dest>/]<br />
</pre><br />
<br />
For flexibility, you should install your system INTO A DEDICATED SUBVOLUME, and use:<br />
<br />
<pre>rootflags=subvol=<whatever you called the subvol></pre><br />
<br />
in your kernel boot parameters. It makes system rollbacks possible.<br />
<br />
If using for your root partition you'll want to add crc32c to the modules array in your {{Filename|/etc/mkinitcpio.conf}} as well as add {{Filename|btrfs}} to the HOOKS array.<br />
<br />
=== Snapshots ===<br />
<br />
To create a snapshot:<br />
<br />
<pre>btrfs subvolume snapshot <source> [<dest>/]<name></pre><br />
<br />
Snapshots are not recursive, this means that every subvolume inside subvolume will be an empty directory inside the snapshot.<br />
== Defragmentation ==<br />
Btrfs supports online defragmentation. To defragment the whole system, simply do:<br />
sudo btrfs filesystem defragment /<br />
== Compression ==<br />
Btrfs supports transparent compression, which means every file on the partition is automatically compressed. This does not only reduce the size of those files, but also [http://www.phoronix.com/scan.php?page=article&item=btrfs_compress_2635&num=1 improves performance], in particular if using the [http://www.phoronix.com/scan.php?page=article&item=btrfs_lzo_2638&num=1 lzo alogorithm]. Compression is enabled using the compress=gzip or compress=lzo mount options. Only files created or modified after the mount option is added will be compressed, so to fully benefit from compression it should be enabled during installation. After [[Beginners%27_Guide#Prepare_Hard_Drive|preparing the hard drive]], simply switch to another terminal (Ctrl+Alt+number), and run the following command:<br />
sudo mount -o remount,compress=lzo /dev/partition /mnt/target # note: replace /dev/partition by the partition on which you install Arch Linux.<br />
After the installation is finished, add compress=lzo to the mount options of the root filesystem in {{Filename|/etc/fstab}}.<br />
== See also ==<br />
* [[Installing_on_Btrfs_root]]<br />
<br />
== Troubleshooting ==<br />
<br />
=== Problems with operations on files, silent fails of copying ===<br />
Fiemap support was implemented badly in kernels older than mainline '''2.6.38-rc6-git6 kernel''' - which was proved by '''coreutils''' package in version '''8.10''' and it's internal copying function (first with fiemap support).<br />
<br />
The bug exist only if '''compressed btrfs''' volume is present and can cause '''lots of damage''' like the installation of broken packages.<br />
<br />
coreutils 8.10 + kernel<2.6.38-rc6-git6 + compresses btrfs = really bad idea.<br />
<br />
If you are using older kernel either turn btrfs' compression off or downgrade coreutils.<br />
<br />
=== Segfault after power failure upon mounting root ===<br />
<br />
After power failures Btrfs ends up not booting, instead just segfaulting. This can be fixed with <pre>btrfs-zero-log /dev/sdX#</pre>. To build btrfs-zero-log, you need to get it from the git:<br />
<pre>git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git<br />
make <br />
make btrfs-zero-log</pre><br />
<br />
If the build fails with <pre>ctree.c: In function '__btrfs_cow_block':<br />
ctree.c:265:6: error: variable 'generation' set but not used [-Werror=unused-but-set-variable]<br />
</pre>, you need to patch the makefile with -Wno-error to make it ignore errors. <br />
<br />
btrfs-zero-log is also now available in AUR pkg btrfs-progs-git available [http://aur.archlinux.org/packages.php?ID=22578 HERE]<br />
<br />
[http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg08836.html Original thread]<br />
<br />
=== still having trouble ===<br />
<br />
Unfortunately there is still '''no official repair tool''' for btrfs available (although told so often for a long time now). If you still have troubles, it might be worth to experiment (!) with some more tools.<br />
<br />
Try to checkout the next branch of btrfs-progs from git:<br />
<br />
<pre>git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git -b next</pre><br />
<br />
There you find '''newer btrfs tools'''. Also you will find '''btrfs-select-super''' which is reported to solve some issues (try with -s1 as for btrfsck). Also try to play around with btrfs, btrfsctl and other tools you will find in there.<br />
If your kernel oops state anything related to log try to use '''btrfs-zero-log''' and you should be fine. You will loose the last operations on your filesystem (about 30sec before the crash) but you are able to mount and use your device again.<br />
<br />
As of now, it is strongly advised '''not to use 2.6 kernels''' anymore. If you are on a 3.0 kernel, get the most current version of btrfs tools from Hugo's integration-20110805 branch at http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ and do a scrub.<br />
<br />
If you have to boot a '''recovery image''' try to use '''archboot''' and manually (re)install glibc, gcc, gcc-libs, make, gmp, openssl, libarchive, git, file, acl, linux-api-headers, e2fsprogs, coreutils, attr and also util-linux as there are some headers missing in archboot which are needed to compile btrfs-progs-unstable.<br />
<br />
Lets hope that there will be a release of the often announced btrfs repair tools available very soon!<br />
<br />
=== TroubleShooting Links ===<br />
<br />
If you still have issues check the official '''BTRFS Problem FAQ''' in their Wiki at https://btrfs.wiki.kernel.org/index.php/Problem_FAQ<br />
<br />
Also have a look to use '''up to date source code repositories''' for btrfs-progs and kernel, try the integration repositories as well if you still have issues: <br />
https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories<br />
<br />
== Resources ==<br />
<br />
* [https://btrfs.wiki.kernel.org Btrfs Wiki]<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=794046 Arch Forums "Fresh Install with Btrfs"]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=88195 Arch Forums "BTRFS mkinitcpio hook"]<br />
* [https://btrfs.wiki.kernel.org/index.php/Problem_FAQ "Problem FAQ in BTRFS Wiki"]<br />
* [https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories "BTRFS Source Repositories"]</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=167213Improving performance2011-10-23T18:35:44Z<p>Rttommy: /* Compressing {{Filename|/usr}} */</p>
<hr />
<div>[[Category:Hardware (English)]]<br />
[[Category:Software (English)]]<br />
{{i18n|Maximizing Performance}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there are some basic indications:<br />
* If the computer becomes slow when big applications, like OpenOffice.org and Firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40MB/s (assuming drive tested while idle) can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. First step would be to verify if direct rendering simply is not enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run lightweight environments and applications.<br />
* Use a [[Window Manager|window manager]] instead of a [[Desktop Environment]]. Choices include [[dwm]], [[wmii]], [[Awesome]], [[Openbox]], [[Fluxbox]] and [[JWM]].<br />
* Choose a minimal Desktop Environment over [[GNOME]] and [[KDE]]. Choices include [[LXDE]] and [[Xfce]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008], [http://bbs.archlinux.org/viewtopic.php?id=78490 2009],[http://bbs.archlinux.org/viewtopic.php?id=88515 2010], and [http://bbs.archlinux.org/viewtopic.php?id=111878 2011].<br />
* Remove unnecessary [[daemons]] and background what daemons you can in {{Filename|/etc/rc.conf}}.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be measured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your filesystem===<br />
Choosing the best filesystem for a specific system is very important because each has its own strengths. The [[Beginner%27s_Guide#Filesystem_types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [[:Category:File systems (English)|here]].<br />
<br />
====Summary====<br />
*XFS: Excellent performance with large files. Low speed with small files. A good choice for /home.<br />
*Reiserfs: Excellent performance with small files. A good choice for /var.<br />
*Ext3: Average performance, reliable.<br />
*Ext4: Great overall performance, reliable, has performance issues with sqlite and some other databases.<br />
*JFS: Good overall performance, very low CPU usage, extremely fast resume after power failure.<br />
*Btrfs: Great overall performance (better than ext4), reliable (once it becomes stable). Lots of features. Still in heavy development and considered as unstable. Do not use this filesystem yet unless you know what you are doing and are prepared for potential data loss.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. The former is a superset of the latter (which applies to directories only -- {{Codeline|noatime}} applies to both files and directories). In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option (NB relatime is the default in >2.6.30)<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====Ext4====<br />
See the [[Ext4#Improving performance | Ext4 wiki page]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,lazy-count=1,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. <br />
<br />
#/etc/fstab<br />
LABEL=XFSHOME /home xfs noatime,logbufs=8 0 1<br />
<br />
==== Reiserfs ====<br />
<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is done when creating the filesystem: <br />
<br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data. You can learn more about reiserfs with this [http://www.funtoo.org/en/articles/linux/ffg/2/ article].<br />
<br />
====BTRFS====<br />
See [[Btrfs#Compression|compression]].<br />
<br />
===Compressing {{Filename|/usr}}===<br />
{{Note|As of version 3.0 of the linux kernel aufs2 is no longer supported.}}<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress {{Filename|/usr}} in a squashfs file, with a 64k(128k) block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. What this tutorial does is basically to compress the {{Filename|/usr}} folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of {{Filename|/usr}}, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so {{Filename|/usr}} must be re-compressed periodically. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel.<br />
Since the linked guide is for Gentoo the next commands outline the steps especially for Arch. Basically we have got install two packages to get it working:<br />
# pacman -S aufs2 squashfs-tools<br />
This command installs the aufs-modules and some userspace-tools for the squash-filesystem.<br />
Now we need some extra directories where we can store the archive of {{Filename|/usr}} as read-only and another folder where we can store the data changed after the last compression as writeable:<br />
# mkdir -p /squashed/usr/{ro,rw}<br />
Now that we got a rough setup you should perform a complete system-upgrade since every change of content in {{Filename|/usr}} after the compression will be excluded from this speedup. If you use prelink you should also perform a complete prelink before creating the archive. Now it is time to invoke the command to compress {{Filename|/usr}}:<br />
# mksquashfs /usr /squashed/usr/usr.sfs -b 65536<br />
These parameters/options are the ones suggested by the Gentoo link but there might be some room for improvement using some of the options described [http://www.tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html#mksqusing here].<br />
Now to get the archive mounted together with the writeable folder it is necessary to edit {{Filename|/etc/fstab}}:<br />
# nano /etc/fstab<br />
Add the following lines:<br />
/squashed/usr/usr.sfs /squashed/usr/ro squashfs loop,ro 0 0 <br />
usr /usr aufs udba=reval,br:/squashed/usr/rw:/squashed/usr/ro 0 0<br />
Now you should be done and able to reboot. The original Author suggests to delete all the old content of {{Filename|/usr}}, but this might cause some problems if anything goes wrong during some later re-compression. It is more safe to leave the old files in place just to be on the safe side.<br />
<br />
A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate the process of re-compressing (read updating) the archive since the tutorial is meant for Gentoo and some options do not correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
[[SSD#Tips_for_Maximizing_SSD_Performance]]<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel motherboards are notorious for disabling the capacity to overclock.<br />
<br />
A way to modify performance ([http://lkml.org/lkml/2009/9/6/136 ref]) is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler (CFS) with the Brain Fuck Scheduler (BFS).<br />
<br />
Kernel PKGBUILDs that include the BFS patch can be installed from the [[AUR]] or [[Unofficial User Repositories]]. See the respective pages for {{Package AUR|linux-ck}} and [https://wiki.archlinux.org/index.php/Linux-ck linux-ck wiki page], {{Package AUR|linus-bfs}} or {{Package AUR|linux-pf}} for more information on their additional patches.<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.37/2.6.37-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[[Verynice]] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritization greatly improves system responsiveness under heavy load.<br />
<br />
===Ulatencyd===<br />
[[Ulatencyd]] is a daemon that controls how the Linux kernel will spend its resources on the running processes. It uses dynamic cgroups to give the kernel hints and limitations on processes.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recommendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. Intel chipsets users can install [http://www.gmabooster.com/ GMABooster] from [http://aur.archlinux.org/packages.php?ID=28197 AUR]<br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
=== Swappiness ===<br />
<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
<br />
vm.swappiness=20<br />
vm.vfs_cache_pressure=50<br />
<br />
To test and more on why this may work, take a look at this [http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that article].<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache], also known as the zram kernel module, creates a device in RAM and compresses it. If you use for swap means that part of the RAM can hold much more information but uses more CPU. Still, it is much quicker than swapping to a hard drive. If a system often falls back to swap, this could improve responsiveness. Zram is in mainline staging (therefore its not stable yet, use with caution).<br />
<br />
For swap you can try using<br />
<br />
modprobe zram<br />
echo $((50*1024*1024)) > /sys/block/zram0/disksize<br />
mkswap /dev/zram0<br />
swapon -p 60 /dev/zram0<br />
<br />
To make the changes permanent, add zram module to {{Filename|/etc/rc.conf}} and autostart by adding the following lines to {{Filename|/etc/rc.local}}:<br />
<br />
echo $((50*1024*1024)) > /sys/block/zram0/disksize<br />
mkswap /dev/zram0<br />
swapon -p 60 /dev/zram0<br />
<br />
You will have a 50MB swap with higher priority than your regular swap.<br />
<br />
This is also a good way to reduce disk read/write cycles due to swap on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,nodev,nosuid,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
=== Preloading ===<br />
Preloading is the action of putting and keeping target files into the RAM. The practical use is that preloaded applications always start very quickly, because reading from the RAM is always quicker than from the hard drive. However, part of your RAM will be dedicated to this task, but no more than if you kept the application open. Therefore, preloading is best used with heavy, often-used applications, like firefox and openoffice.<br />
==== Go-preload ====<br />
[http://aur.archlinux.org/packages.php?ID=34207 Go-preload] is a small daemon created in the [http://forums.gentoo.org/viewtopic-t-789818-view-next.html?sid=5457cff93039fc7d4a3e445ef90f9821 gentoo forum]. To use it, first run this command in a terminal for each program you want to preload at boot:<br />
# gopreload-prepare program<br />
Then, as instructed, press enter when the program is fully loaded. This will add a list of files needed by the program in {{Filename|/usr/share/gopreload/enabled}}. To load all lists at boot, simply add gopreload to your DAEMONS array in {{Filename|/etc/rc.conf}}. To disable the loading of a program, remove the appropriate list in {{Filename|/usr/share/gopreload/enabled}}, or move it to {{Filename|/usr/share/gopreload/disabled}}.<br />
====Preload====<br />
A more automated, albeit less KISS, approach is used by [[Preload]]. All you have to do is add it to your DAEMONS array in {{Filename|/etc/rc.conf}}. It will monitor the most used files on your system, and with time build its own list of files to preload at boot.<br />
====Readahead====<br />
[[Readahead]] is a tool that can cache files before needed and help you accelerating program loading.<br />
<br />
==Boot time==<br />
You can find tutorials with good tips in the article [[Improve Boot Performance]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The {{Codeline|fastboot}} option usually can take off one second or so. Also, if you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox Tips and Tweaks#Improve rendering by disabling pango |disabling pango]] and [[Firefox Tips and Tweaks#Defragment the profile's SQLite databases|cleaning the sqlite database]]. See also: [[Speed-up Firefox using tmpfs]] and [[Firefox Tips and Tweaks#Turning off anti-phishing|Turning off anti-phishing]].<br />
Firefox in the official repositories is built with the profile guided optimization flag enabled. You may want to use it in your custom build.<br />
To do this append<br />
ac_add_options --enable-profile-guided-optimization<br />
to your mozconfig.<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===LibreOffice===<br />
See [[LibreOffice#Speed up LibreOffice|Speed up LibreOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].<br />
<br />
==Laptops==<br />
See [[Laptop]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=160619Improving performance2011-09-18T20:13:55Z<p>Rttommy: /* BTRFS */ Linked to compression section.</p>
<hr />
<div>[[Category:Hardware (English)]]<br />
[[Category:Software (English)]]<br />
{{i18n|Maximizing Performance}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there are some basic indications:<br />
* If the computer becomes slow when big applications, like OpenOffice.org and Firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40MB/s (assuming drive tested while idle) can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. First step would be to verify if direct rendering simply is not enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run lightweight environments and applications.<br />
* Use a [[Window Manager|window manager]] instead of a [[Desktop Environment]]. Choices include [[dwm]], [[Openbox]] and [[JWM]].<br />
* Choose a minimal Desktop Environment over [[GNOME]] and [[KDE]]. Choices include [[LXDE]] and [[Xfce]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008], [http://bbs.archlinux.org/viewtopic.php?id=78490 2009],[http://bbs.archlinux.org/viewtopic.php?id=88515 2010], and [http://bbs.archlinux.org/viewtopic.php?id=111878 2011].<br />
* Remove unnecessary [[daemons]] and background what daemons you can in {{Filename|/etc/rc.conf}}.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be measured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your filesystem===<br />
Choosing the best filesystem for a specific system is very important because each has its own strengths. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [[:Category:File systems (English)|here]].<br />
<br />
====Summary====<br />
*XFS: Excellent performance with large files. Low speed with small files. A good choice for /home.<br />
*Reiserfs: Excellent performance with small files. A good choice for /var.<br />
*Ext3: Average performance, reliable.<br />
*Ext4: Great overall performance, reliable, has performance issues with sqlite and some other databases.<br />
*JFS: Good overall performance, very low CPU usage, extremely fast resume after power failure.<br />
*Btrfs: Great overall performance (better than ext4), reliable (once it becomes stable). Lots of features. Still in heavy development and considered as unstable. Do not use this filesystem yet unless you know what you are doing and are prepared for potential data loss.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. The former is a superset of the latter (which applies to directories only -- {{Codeline|noatime}} applies to both files and directories). In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option (NB relatime is the default in >2.6.30)<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====Ext4====<br />
See the [[Ext4#Improving performance | Ext4 wiki page]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,lazy-count=1,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. <br />
<br />
#/etc/fstab<br />
LABEL=XFSHOME /home xfs noatime,logbufs=8 0 1<br />
<br />
==== Reiserfs ====<br />
<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
<br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data. You can learn more about reiserfs with this [http://www.funtoo.org/en/articles/linux/ffg/2/ article].<br />
<br />
====BTRFS====<br />
See [[Btrfs#Compression|compression]].<br />
<br />
===Compressing {{Filename|/usr}}===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress {{Filename|/usr}} in a squashfs file, with a 64k(128k) block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. What this tutorial does is basically to compress the {{Filename|/usr}} folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of {{Filename|/usr}}, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so {{Filename|/usr}} must be re-compressed periodically. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel.<br />
Since the linked guide is for Gentoo the next commands outline the steps especially for Arch. Basically we have got install two packages to get it working:<br />
# pacman -S aufs2 squashfs-tools<br />
This command installs the aufs-modules and some userspace-tools for the squash-filesystem.<br />
Now we need some extra directories where we can store the archive of {{Filename|/usr}} as read-only and another folder where we can store the data changed after the last compression as writeable:<br />
# mkdir -p /squashed/usr/{ro,rw}<br />
Now that we got a rough setup you should perform a complete system-upgrade since every change of content in {{Filename|/usr}} after the compression will be excluded from this speedup. If you use prelink you should also perform a complete prelink before creating the archive. Now it is time to invoke the command to compress {{Filename|/usr}}:<br />
# mksquashfs /usr /squashed/usr/usr.sfs -b 65536<br />
These parameters/options are the ones suggested by the Gentoo link but there might be some room for improvement using some of the options described [http://www.tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html#mksqusing here].<br />
Now to get the archive mounted together with the writeable folder it is necessary to edit {{Filename|/etc/fstab}}:<br />
# nano /etc/fstab<br />
Add the following lines:<br />
/squashed/usr/usr.sfs /squashed/usr/ro squashfs loop,ro 0 0 <br />
usr /usr aufs udba=reval,br:/squashed/usr/rw:/squashed/usr/ro 0 0<br />
Now you should be done and able to reboot. The original Author suggests to delete all the old content of {{Filename|/usr}}, but this might cause some problems if anything goes wrong during some later re-compression. It is more safe to leave the old files in place just to be on the safe side.<br />
<br />
A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate the process of re-compressing (read updating) the archive since the tutorial is meant for Gentoo and some options do not correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
[[SSD#Tips_for_Maximizing_SSD_Performance]]<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel motherboards are notorious for disabling the capacity to overclock.<br />
<br />
A way to modify performance ([http://lkml.org/lkml/2009/9/6/136 ref]) is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler (CFS) with the Brain Fuck Scheduler (BFS).<br />
<br />
Kernel PKGBUILDs that include the BFS patch can be installed from the [[AUR]] or [[Unofficial_User_Repositories]]. See the respective pages for {{Package AUR|linux-ck}} and [https://wiki.archlinux.org/index.php/Linux-ck linux-ck wiki page], {{Package AUR|linus-bfs}} or {{Package AUR|linux-pf}} for more information on their additional patches.<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.37/2.6.37-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[[Verynice]] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritization greatly improves system responsiveness under heavy load.<br />
<br />
===Ulatencyd===<br />
[[Ulatencyd]] is a daemon that controls how the Linux kernel will spend its resources on the running processes. It uses dynamic cgroups to give the kernel hints and limitations on processes.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recommendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. Intel chipsets users can install [http://www.gmabooster.com/ GMABooster] from [http://aur.archlinux.org/packages.php?ID=28197 AUR]<br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
=== Swappiness ===<br />
<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
<br />
vm.swappiness=20<br />
vm.vfs_cache_pressure=50<br />
<br />
To test and more on why this may work, take a look at this [http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that article].<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache], also known as the zram kernel module, creates a swap device in RAM and compresses it. That means that part of the RAM can hold much more information but uses more CPU. Still, it is much quicker than swapping to a hard drive. If a system often falls back to swap, this could improve responsiveness. Zram is in mainline staging (therefore its not stable yet, use with caution).<br />
<br />
modprobe zram<br />
<br />
It is also possible (and recommended) to tell compcache to fall back on the hard drive swap when full. To do this, define a backing swap device in the configuration file. This swap device must not be in use when zram is started, so remove it from your {{Filename|/etc/fstab}}!<br />
<br />
This is also a good way to reduce disk read/write cycles due to swap on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,nodev,nosuid,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
=== Preloading ===<br />
Preloading is the action of putting and keeping target files into the RAM. The practical use is that preloaded applications always start very quickly, because reading from the RAM is always quicker than from the hard drive. However, part of your RAM will be dedicated to this task, but no more than if you kept the application open. Therefore, preloading is best used with heavy, often-used applications, like firefox and openoffice.<br />
==== Go-preload ====<br />
[http://aur.archlinux.org/packages.php?ID=34207 Go-preload] is a small daemon created in the [http://forums.gentoo.org/viewtopic-t-789818-view-next.html?sid=5457cff93039fc7d4a3e445ef90f9821 gentoo forum]. To use it, first run this command in a terminal for each program you want to preload at boot:<br />
# gopreload-prepare program<br />
Then, as instructed, press enter when the program is fully loaded. This will add a list of files needed by the program in {{Filename|/usr/share/gopreload/enabled}}. To load all lists at boot, simply add gopreload to your DAEMONS array in {{Filename|/etc/rc.conf}}. To disable the loading of a program, remove the appropriate list in {{Filename|/usr/share/gopreload/enabled}}, or move it to {{Filename|/usr/share/gopreload/disabled}}.<br />
====Preload====<br />
A more automated, albeit less KISS, approach is used by [[Preload]]. All you have to do is add it to your DAEMONS array in {{Filename|/etc/rc.conf}}. It will monitor the most used files on your system, and with time build its own list of files to preload at boot.<br />
====Readahead====<br />
[[Readahead]] is a tool that can cache files before needed and help you accelerating program loading.<br />
<br />
==Boot time==<br />
You can find tutorials with good tips in the article [[Improve Boot Performance]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The {{Codeline|fastboot}} option usually can take off one second or so. Also, if you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox Tips and Tweaks#Improve rendering by disabling pango |disabling pango]], [[Firefox Tips and Tweaks#Defragment the profile's SQLite databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing|Turning off anti-phishing]].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum has made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===LibreOffice===<br />
See [[LibreOffice#Speed up LibreOffice|Speed up LibreOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].<br />
<br />
==Laptops==<br />
See [[Laptop]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Btrfs&diff=160617Btrfs2011-09-18T20:11:49Z<p>Rttommy: Added compression section</p>
<hr />
<div>[[Category:File systems (English)]]<br />
{{i18n|Btrfs}}<br />
<br />
Btrfs is a new copy on write filesystem for Linux aimed at implementing advanced features while focusing on fault tolerance, repair and easy administration. Initially developed by Oracle, Btrfs is licensed under the GPL and open for contribution from anyone.<br />
<br />
Linux has a wealth of filesystems to choose from, but we are facing a number of challenges with scaling to the large storage subsystems that are becoming common in today's data centers. Filesystems need to scale in their ability to address and manage large storage, and also in their ability to detect, repair and tolerate errors in the data stored on disk.<br />
<br />
Btrfs is under heavy development, but every effort is being made to keep the filesystem stable and fast. As of 2.6.31, they only plan to make forward compatible disk format changes.<br />
<br />
{{Warning|Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that don't handle flush requests correctly. This will be fixed when the fsck tool is ready.}}<br />
<br />
== Installation ==<br />
<br />
To install:<br />
<br />
<pre>pacman -S btrfs-progs-unstable</pre><br />
<br />
There are also [http://aur.archlinux.org/packages.php?ID=22578 btrfs-progs-git] in AUR.<br />
<br />
If using btrfs as your root filesystem, you may also want to install [http://aur.archlinux.org/packages.php?ID=33376 mkinitcpio-btrfs] from AUR. This package will install a mkinitcpio hook intended for those who wish to have a single or multi-drive BTRFS file system as their / (root). The hook will ensure that the chosen root device from the kernel command line is intact and safe to boot. If root is not a BTRFS device, the hook is quietly skipped.<br />
<br />
== Basic Use ==<br />
<br />
To format a device to btrfs<br />
<br />
<pre>mkfs.btrfs [options] dev [dev ...]</pre><br />
<br />
You can select multiple devices to create a raid. Supported raids include raid1, raid0, and raid 10. By default, metadata is mirrored and data is striped.<br />
<br />
=== Subvolumes ===<br />
<br />
One of the features of btrfs is the use of subvolumes. Subvolumes are basically a named btree that holds files and directories. They have inodes inside the tree of tree roots and can have non-root owners and groups. Subvolumes can be given a quota of blocks, and once this quota is reached no new writes are allowed. All of the blocks and file extents inside of subvolumes are reference counted to allow snapshotting. Similar to the dynamically expanding storage of a virtual machine that will only use as much space on a device as needed. Eliminating several half-filled partitions. You can also mount the subvolumes with different mount options giving more flexibility in security. <br />
<br />
To create a subvolume:<br />
<br />
<pre><br />
btrfs subvolume create [<dest>/]<br />
</pre><br />
<br />
For flexibility, you should install your system INTO A DEDICATED SUBVOLUME, and use:<br />
<br />
<pre>rootflags=subvol=<whatever you called the subvol></pre><br />
<br />
in your kernel boot parameters. It makes system rollbacks possible.<br />
<br />
If using for your root partition you'll want to add crc32c to the modules array in your {{Filename|/etc/mkinitcpio.conf}} as well as add {{Filename|btrfs}} to the HOOKS array.<br />
<br />
=== Snapshots ===<br />
<br />
To create a snapshot:<br />
<br />
<pre>btrfs subvolume snapshot <source> [<dest>/]<name></pre><br />
== Compression ==<br />
Btrfs supports transparent compression, which means every file on the partition is automatically compressed. This does not only reduce the size of those files, but also [http://www.phoronix.com/scan.php?page=article&item=btrfs_compress_2635&num=1 improves performance], in particular if using the [http://www.phoronix.com/scan.php?page=article&item=btrfs_lzo_2638&num=1 lzo alogorithm]. Compression is enabled using the compress=gzip or compress=lzo mount options. Only files created or modified after the mount option is added will be compressed, so to fully benefit from compression it should be enabled during installation. After [[Beginners%27_Guide#Prepare_Hard_Drive|preparing the hard drive]], simply switch to another terminal (Ctrl+Alt+number), and run the following command:<br />
sudo mount -o remount,compress=lzo /dev/partition /mnt/target # note: replace /dev/partition by the partition on which you install Arch Linux.<br />
After the installation is finished, add compress=lzo to the mount options of the root filesystem in {{Filename|/etc/fstab}}.<br />
== See also ==<br />
* [[Installing_on_Btrfs_root]]<br />
<br />
== Troubleshooting ==<br />
<br />
=== Problems with operations on files, silent fails of copying ===<br />
Fiemap support was implemented badly in kernels older than mainline '''2.6.38-rc6-git6 kernel''' - which was proved by '''coreutils''' package in version '''8.10''' and it's internal copying function (first with fiemap support).<br />
<br />
The bug exist only if '''compressed btrfs''' volume is present and can cause '''lots of damage''' like the installation of broken packages.<br />
<br />
coreutils 8.10 + kernel<2.6.38-rc6-git6 + compresses btrfs = really bad idea.<br />
<br />
If you are using older kernel either turn btrfs' compression off or downgrade coreutils.<br />
<br />
=== Segfault after power failure upon mounting root ===<br />
<br />
After power failures Btrfs ends up not booting, instead just segfaulting. This can be fixed with <pre>btrfs-zero-log /dev/sdX#</pre>. To build btrfs-zero-log, you need to get it from the git:<br />
<pre>git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git<br />
make <br />
make btrfs-zero-log</pre><br />
<br />
If the build fails with <pre>ctree.c: In function '__btrfs_cow_block':<br />
ctree.c:265:6: error: variable 'generation' set but not used [-Werror=unused-but-set-variable]<br />
</pre>, you need to patch the makefile with -Wno-error to make it ignore errors. <br />
<br />
btrfs-zero-log is also now available in AUR pkg btrfs-progs-git available [http://aur.archlinux.org/packages.php?ID=22578 HERE]<br />
<br />
[http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg08836.html Original thread]<br />
<br />
=== still having trouble ===<br />
<br />
Unfortunately there is still '''no official repair tool''' for btrfs available (although told so often for a long time now). If you still have troubles, it might be worth to experiment (!) with some more tools.<br />
<br />
Try to checkout the next branch of btrfs-progs from git:<br />
<br />
<pre>git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git -b next</pre><br />
<br />
There you find '''newer btrfs tools'''. Also you will find '''btrfs-select-super''' which is reported to solve some issues (try with -s1 as for btrfsck). Also try to play around with btrfs, btrfsctl and other tools you will find in there.<br />
If your kernel oops state anything related to log try to use '''btrfs-zero-log''' and you should be fine. You will loose the last operations on your filesystem (about 30sec before the crash) but you are able to mount and use your device again.<br />
<br />
As of now, it is strongly advised '''not to use 2.6 kernels''' anymore. If you are on a 3.0 kernel, get the most current version of btrfs tools from Hugo's integration-20110805 branch at http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ and do a scrub.<br />
<br />
If you have to boot a '''recovery image''' try to use '''archboot''' and manually (re)install glibc, gcc, gcc-libs, make, gmp, openssl, libarchive, git, file, acl, linux-api-headers, e2fsprogs, coreutils, attr and also util-linux as there are some headers missing in archboot which are needed to compile btrfs-progs-unstable.<br />
<br />
Lets hope that there will be a release of the often announced btrfs repair tools available very soon!<br />
<br />
=== TroubleShooting Links ===<br />
<br />
If you still have issues check the official '''BTRFS Problem FAQ''' in their Wiki at https://btrfs.wiki.kernel.org/index.php/Problem_FAQ<br />
<br />
Also have a look to use '''up to date source code repositories''' for btrfs-progs and kernel, try the integration repositories as well if you still have issues: <br />
https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories<br />
<br />
== Resources ==<br />
<br />
* [https://btrfs.wiki.kernel.org Btrfs Wiki]<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=794046 Arch Forums "Fresh Install with Btrfs"]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=88195 Arch Forums "BTRFS mkinitcpio hook"]<br />
* [https://btrfs.wiki.kernel.org/index.php/Problem_FAQ "Problem FAQ in BTRFS Wiki"]<br />
* [https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories "BTRFS Source Repositories"]</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Ext4&diff=139037Ext42011-05-01T02:19:49Z<p>Rttommy: /* Improving performance */ Added e4rat</p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
[[Category:File systems (English)]]<br />
{{i18n|Ext4}}<br />
[[fr:Ext4]]<br />
<br />
Ext4 is the evolution of the most used Linux filesystem, Ext3. In many ways, Ext4 is a deeper improvement over Ext3 than Ext3 was over Ext2. Ext3 was mostly about adding journaling to Ext2, but Ext4 modifies important data structures of the filesystem such as the ones destined to store the file data. The result is a filesystem with an improved design, better performance, reliability, and features.<br />
<br />
Source: [http://kernelnewbies.org/Ext4 Ext4 - Linux Kernel Newbies]<br />
<br />
==Creating ext4 Partitions From Scratch==<br />
<br />
# Upgrade your system: {{Codeline|pacman -Syu}}<br />
# Format the partition: {{Codeline|mkfs.ext4 /dev/sdxY}} (replace {{Codeline|sdxY}} with the device to format (e.g. {{Codeline|sda1}}))<br />
# Mount the partition<br />
# Add an entry to {{Filename|/etc/fstab}}, using the filesystem 'type' ext4<br />
<br />
{{Tip|See the mkfs.ext4 man page for more options; edit {{Filename|/etc/mke2fs.conf}} to view/configure default options.}}<br />
<br />
==Migrating From ext3 to ext4==<br />
<br />
There are two ways of migrating partitions from ext3 to ext4:<br />
* mounting ext3 partitions as ext4 without converting (compatibility)<br />
* converting ext3 partitions to ext4 (performance)<br />
<br />
These two approaches are described below.<br />
<br />
===Mounting ext3 Partitions as ext4 Without Converting===<br />
<br />
====Rationale====<br />
<br />
A compromise between fully converting to ext4 and simply remaining with ext3 is to mount existing ext3 partitions as ext4.<br />
<br />
'''Pros:'''<br />
* Compatibility (the filesystem can continue to be mounted as ext3) &ndash; This allows users to still read the filesystem from other distributions/operating systems without ext4 support (e.g. Windows with ext3 drivers)<br />
* Improved performance (though not as much as a fully-converted ext4 partition) &ndash; See [http://kernelnewbies.org/Ext4 Ext4 - Linux Kernel Newbies] for details<br />
<br />
'''Cons:'''<br />
* Fewer features of ext4 are used (only those that do not change the disk format such as multiblock allocation and delayed allocation)<br />
<br />
{{Note|Except for the relative novelty of ext4 (which can be seen as a risk), '''there is no major drawback to this technique'''.}}<br />
<br />
====Procedure====<br />
<br />
# Edit {{Filename|/etc/fstab}} and change the 'type' from ext3 to ext4 for any partitions you would like to mount as ext4.<br />
# Re-mount the affected partitions.<br />
# Done.<br />
<br />
===Converting ext3 Partitions to ext4===<br />
<br />
====Rationale====<br />
<br />
To experience the benefits of ext4, an irreversible conversion process must be completed.<br />
<br />
'''Pros:'''<br />
* Improved performance and new features &ndash; See [http://kernelnewbies.org/Ext4 Ext4 - Linux Kernel Newbies] for details<br />
<br />
'''Cons:'''<br />
* Read-only access from Windows can be provided by Ext2Explore, but there is currently no driver for writing data.<br />
* Irreversible (ext4 partitions cannot be 'downgraded' to ext3)<br />
<br />
====Prerequisites====<br />
<br />
The following software is required on the Arch Linux system:<br />
* {{Codeline|1=kernel26 >= 2.6.28}}<br />
* {{Codeline|1=e2fsprogs >= 1.41}}<br />
<br />
If converting one's /boot partition to ext4:<br />
* {{Codeline|1=grub >= 0.97}} (with ext4 patch)<br />
<br />
{{Note|The ext4 patch is included by default with Arch's GRUB package (at the time of writing, but this will likely not change). Otherwise, [[GRUB2]] is required for booting from an ext4 partition.}}<br />
<br />
{{Warning|Booting from an ext4 partition is not 'officially' supported by GRUB, and [[GRUB2]] is still under development. While GRUB does currently work, the 'safe' option is to boot from an ext2 or ext3 /boot partition. '''CONSIDER YOURSELF WARNED!}}<br />
<br />
If converting one's root (/) partition to ext4:<br />
* {{Codeline|1=mkinitcpio >= 0.5.20}}<br />
<br />
If converting one's root (/) partition to ext4, the following software is also needed on a bootable CD/USB drive:<br />
* {{Codeline|1=e2fsprogs >= 1.41}}<br />
<br />
{{Note|1=Using the latest Arch Linux release (2009.02) is recommended. Older Arch Linux images (<= 2008.06) ship with an older version of {{Codeline|e2fsprogs}}, but it is a simple matter to {{Codeline|pacman -S e2fsprogs}} from the live environment after setting up networking. Alternatively, [http://www.sysresccd.org/Download SystemRescueCd >= 1.1.4] contains an appropriate version, and is in itself a handy CD to have.}}<br />
<br />
====Procedure====<br />
<br />
These instructions were adapted from http://ext4.wiki.kernel.org/index.php/Ext4_Howto and http://bbs.archlinux.org/viewtopic.php?id=61602. They have been tested and confirmed by this author as of January 16, 2009.<br />
<br />
* '''UPGRADE!''' Perform a sysupgrade to ensure all required packages are up-to-date: {{Codeline|pacman -Syu}}<br />
* '''[[Backup programs|BACK-UP!]]''' Back-up all data on any ext3 partitions that are to be converted to ext4. Although ext4 is considered 'stable' for general use, it is still a relatively young and untested file system. Furthermore, this conversion process was only tested on a relatively simple setup; it is impossible to test each of the many possible configurations the user may be running.<br />
* Edit {{Filename|/etc/fstab}} and change the 'type' from ext3 to ext4 for any partitions that are to be converted to ext4.<br />
<br />
{{Warning|ext4 is backwards-compatible with ext3 until extents and other new fancy options are enabled. If the user has a partition that is shared with another OS that cannot yet read ext4 partitions, it is possible to mount said partition as ext4 in Arch and still be able to use it as ext3 elsewhere at this point... Not so after the next step! Note, however, that there are fewer benefits to using ext4 if the partition is not fully converted.}}<br />
<br />
* The conversion process with {{Codeline|e2fsprogs}} must be done when the drive is not mounted. If converting one's root (/) partition, the simplest way to achieve this is to boot from some other live medium, as described in the 'Prerequisites' section above.<br />
** Boot the live medium (if necessary).<br />
** For each partition to be converted to ext4:<br />
*** Ensure the partition is '''NOT''' mounted<br />
*** Run {{Codeline|tune2fs -O extents,uninit_bg,dir_index /dev/the_partition}} (where {{Codeline|/dev/the_partition}} is replaced by the path to the desired partition, such as {{Codeline|/dev/sda1}})<br />
*** Run {{Codeline|fsck -fDp /dev/the_partition}}<br />
<br />
{{Note|The user '''MUST''' fsck the filesystem, or it will be unreadable! This fsck run is needed to return the filesystem to a consistent state. '''It WILL find checksum errors in the group descriptors''' -- this is expected. The '-f' parameter asks fsck to force checking even if the file system seems clean. The '-p' parameter asks fsck to 'automatically repair' (otherwise, the user will be asked for input for each error).<br />
You may need to run fsck -f rather than fsck -fp.}}<br />
<br />
* Reboot Arch Linux!<br />
<br />
{{Warning|1=If the user converted their root (/) partition, a kernel panic may be encountered when attempting to boot. If this happens, simply reboot using the 'fallback' initial ramdisk and re-create the 'default' initial ramdisk: {{Codeline|mkinitcpio -p kernel26}}}}<br />
<br />
====Migrating files to extents====<br />
{{warning|Do '''NOT''' use the following method with Mercurial repository that have been cloned locally, as doing so will corrupt the repository. It might also corrupt other hard link in the filesystem.}}<br />
Even though the filesystem is now converted to ext4, all files that have been written before the conversion do not yet take advantage of the new ''extents'' of ext4, which will improve large file performance and reduce fragmentation and filesystem check time. In order to fully take advantage of ext4, all files would have to be rewritten on disk. A utility called ''e4defrag'' is being developed and will take care of this task ; however, it is not yet ready for production.<br />
<br />
Fortunately, it is possible to use the ''chattr'' program, which will cause the kernel to rewrite the file using extents. It is possible to run this command on all files and directories of one partition (e.g. if /home is on a dedicated partition):<br />
(Must be run as root)<br />
find /home -xdev -type f -print0 | xargs -0 chattr +e<br />
find /home -xdev -type d -print0 | xargs -0 chattr +e<br />
It is recommended to test this command on a small number of files first, and check if everything is going all right. It may also be useful to check the filesystem after conversion.<br />
<br />
Using the ''lsattr'' command, it is possible to check that files are now using ''extents''. The letter 'e' should appear in the attribute list of the listed files.<br />
<br />
==Tips and tricks==<br />
===Remove reserved blocks===<br />
<br />
By default 5% of a filesystem will be flagged as reserved for root user. For modern high-capacity disks, this is much higher than necessary - particularly if the partition is not being used for system files. It is generally safe to reduce the percentage of reserved blocks to free up disk space when the partition is either<br />
<br />
*Very large (for example >50 G)<br />
*Not being used for system files<br />
<br />
Use the tune2fs utility to do this. The command below would set the percentage of reserved blocks on the partition /dev/sdXY to 1%:<br />
<br />
tune2fs -m 1 /dev/sdXY<br />
<br />
==Troubleshooting==<br />
<br />
===Kernel Panic===<br />
One problem this author encountered was a kernel panic after converting the root (/) partition to ext4. This is because the initial ramdisk was detecting the partition as 'ext4dev', rather than 'ext4'. It was a simple matter to boot with the 'fallback' initial ramdisk and re-create the 'default' initial ramdisk :<br />
* Remount the root partition in read-write mode; assuming 'XXX' is your root partition :<br />
# mount /dev/XXX / -o remount,rw<br />
* Manually mount the boot partition on /boot if it is on a separate partition.<br />
* Re-create the ramdisk :<br />
# mkinitcpio -p kernel26<br />
<br />
During the creation process, {{Codeline|mkinitcpio}} correctly detected and included ext4 modules in the initial ramdisk.<br />
<br />
===GRUB Error 13===<br />
After a recent kernel update, this author encountered a GRUB error while attempting to boot from an ext4 /boot partition:<br />
Error 13: Invalid or unsupported executable format<br />
<br />
The solution is to boot from the live medium and chroot into the Arch Linux installation:<br />
# mkdir /mnt/arch<br />
# mount -t ext4 /dev/sda1 /mnt/arch<br />
# mount -t proc proc /mnt/arch/proc<br />
# mount -t sysfs sys /mnt/arch/sys<br />
# mount -o bind /dev /mnt/arch/dev<br />
<br />
# chroot /mnt/arch /bin/bash<br />
<br />
If /boot is on a separate partition, this partition must also be mounted:<br />
# mount -t ext4 /dev/sda2 /boot<br />
<br />
Then, the following command should resolve the issue. (Does anyone know why?):<br />
# grub-install --recheck /dev/sda<br />
<br />
===Data Corruption===<br />
Some early adopters of ext4 encountered data corruption after a hard reboot. Please read [http://www.h-online.com/open/Ext4-data-loss-explanations-and-workarounds--/news/112892 Ext4 data loss; explanations and workarounds] for more information.<br />
<br />
Since kernel 2.6.30, ext4 is considered "safe(r)." Several patches improved the robustness of ext4 - albeit at a slight performance cost. A new mount option ({{Codeline|auto_da_alloc}}) can be used to disable this behavior. For more information, please read [http://kernelnewbies.org/Linux_2_6_30#head-329ba44b44a7f58c98ae22b8f2730418cdd6630d Linux 2 6 30 - Filesystems performance improvements].<br />
<br />
For kernel versions earlier than 2.6.30, consider adding {{Codeline|1=rootflags=data=ordered}} to the {{Codeline|kernel}} line in GRUB's {{Filename|menu.lst}} as a preventative measure.<br />
<br />
===Improving performance===<br />
Since kernel 2.6.30, ext4 performance has decreased due to changes that serve to improve data integrity.[http://www.phoronix.com/scan.php?page=article&item=ext4_then_now&num=1] Users can improve performance with the {{Codeline|nobarrier}} option when mounting the disk, but '''this can be dangerous''' and may result in data loss or corruption after power failures. To turn barriers off, add the option {{Codeline|1=barrier=0}} to the desired filesystem in {{Filename|/etc/fstab}}. For example:<br />
<br />
# /dev/sda5 / ext4 noatime,barrier=0 0 1<br />
====E4rat====<br />
[http://e4rat.sourceforge.net/ E4rat] is a preloading application designed for ext4. It monitors files opened during boot, optimizes their placement on the partition to improve access time, and preloads them at the very begining of the boot process. See the [https://bbs.archlinux.org/viewtopic.php?id=115976| forum thread] for instructions. Also note a user [https://bbs.archlinux.org/viewtopic.php?id=117776| improved the preloading code].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=139036Improving performance2011-05-01T02:10:25Z<p>Rttommy: /* Storage devices */ Added Ext4</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{i18n|Maximizing Performance}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there are some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40MB/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. First step would be to verify if direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run lightweight environments and applications.<br />
* Use a [[Window Manager|window manager]] instead of a [[Desktop Environment]]. Choices include [[dwm]], [[Openbox]] and [[JWM]].<br />
* Choose a minimal Desktop Environment over [[GNOME]] and [[KDE]]. Choices include [[LXDE]] and [[Xfce]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008], [http://bbs.archlinux.org/viewtopic.php?id=78490 2009],[http://bbs.archlinux.org/viewtopic.php?id=88515 2010], and [http://bbs.archlinux.org/viewtopic.php?id=111878 2011].<br />
* Remove unnecessary daemons and background what daemons you can in {{Filename|/etc/rc.conf}}.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be measured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your filesystem===<br />
Choosing the best filesystem for a specific system is very important because each has its own strengths. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
<br />
====Summary====<br />
*XFS: Excellent performance with large files. Low speed with small files. A good choice for /home.<br />
*Reiserfs: Excellent performance with small files. A good choice for /var.<br />
*Ext3: Average performance, reliable.<br />
*Ext4: Great overall performance, reliable, has performance issues with sqlite and some other databases.<br />
*JFS: Good overall performance, very low CPU usage.<br />
*Btrfs: Great overall performance (better than ext4), reliable (once it becomes stable). Lots of features. Still in heavy development and considered as unstable. Do not use this filesystem yet unless you know what you are doing and are prepared for potential data loss.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. The former is a superset of the latter (which applies to directories only -- {{Codeline|noatime}} applies to both files and directories). In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option (NB relatime is the default in >2.6.30)<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====Ext4====<br />
See the [[Ext4#Improving performance | Ext4 wiki page]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,lazy-count=1,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. <br />
<br />
#/etc/fstab<br />
LABEL=XFSHOME /home xfs noatime,logbufs=8 0 1<br />
<br />
As its speed when dealing with small files is poor, users of XFS should consider using [[Improve_Pacman_Performance#pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
==== Reiserfs ====<br />
<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
<br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data. You can learn more about reiserfs with this [http://www.funtoo.org/en/articles/linux/ffg/2/ article].<br />
<br />
====BTRFS====<br />
Btrfs is a new filesystem offering online defragmentation, optimized mode for SSDs, writable snapshots, changing size of partition without data loss and many other features. Btrfs is still in active development, and is available in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===== mkinitcpio.conf for btrfs =====<br />
<br />
For non-root btrfs filesystems the btrfs module and dependencies are loaded when required. For a root btrfs filesystem you should ensure the initial ramdisk has the correct modules. There is a dependency of the btrfs module on the libcrc32c module. You can add crc32c to the modules line of /etc/mkinitcpio.conf like so:<br />
<br />
MODULES="crc32c libcrc32c zlib_deflate btrfs"<br />
<br />
This avoids pitfalls like "unknown symbol" errors when loading the btrfs modules.<br />
See also [http://aur.archlinux.org/packages.php?ID=33376 mkinitcpio-btrfs].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k(128k) block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel.<br />
Since the linked guide is for Gentoo the next commands outline the steps especially for Arch. Basically we have got install two packages to get it working:<br />
# pacman -S aufs2 squashfs-tools<br />
This command installs the aufs-modules and some userspace-tools for the squash-filesystem.<br />
Now we need some extra directories where we can store the archive of /usr as read-only and another folder where we can store the data changed after the last compression as writeable:<br />
# mkdir -p /squashed/usr/{ro,rw}<br />
Now that we got a rough setup you should perform a complete system-upgrade since every change of content in /usr after the compression will be excluded from this speedup. If you use prelink you should also perform a complete prelink before creating the archive. Now it is time to invoke the command to compress /usr:<br />
# mksquashfs /usr /squashed/usr/usr.sfs -b 65536<br />
These parameters/options are the ones suggested by the Gentoo link but there might be some room for improvement using some of the options described [http://www.tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html#mksqusing here].<br />
Now to get the archive mounted together with the writeable folder it is necessary to edit fstab:<br />
# nano /etc/fstab<br />
Add the following lines:<br />
/squashed/usr/usr.sfs /squashed/usr/ro squashfs loop,ro 0 0 <br />
usr /usr aufs udba=reval,br:/squashed/usr/rw:/squashed/usr/ro 0 0<br />
Now you should be done and able to reboot. The original Author suggests to delete all the old content of /usr, but this might cause some problems if anything goes wrong during some later re-compression. It is more safe to leave the old files in place just to be on the safe side.<br />
<br />
A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate the process of re-compressing (read updating) the archive since the tutorial is meant for Gentoo and some options don't correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
[[SSD#Tips_for_Maximizing_SSD_Performance]]<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel motherboards are notorious for disabling the capacity to overclock.<br />
<br />
A way to modify performance ([http://lkml.org/lkml/2009/9/6/136 ref]) is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler (CFS) with the Brain Fuck Scheduler (BFS).<br />
<br />
Kernel PKGBUILDs that include the BFS patch can be installed from the [[AUR]] or [[Unofficial_User_Repositories]]. See the respective pages for [http://aur.archlinux.org/packages.php?ID=32877 kernel26-ck], [http://aur.archlinux.org/packages.php?ID=36384 kernel26-bfs] or [http://aur.archlinux.org/packages.php?ID=40191 kernel26-pf] for more information on their additional patches.<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.37/2.6.37-ck1/patches/ ck patches].}}<br />
===[[Verynice]]===<br />
[http://thermal.cnde.iastate.edu/~sdh4/verynice/ Verynice] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritisation greatly improves system responsiveness under heavy load.<br />
<br />
<br />
===[[Ulatencyd]]===<br />
Ulatency is a daemon that controls how the Linux kernel will spend it's resources on the running processes. It uses dynamic cgroups to give the kernel hints and limitations on processes.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. Intel chipsets users can install [http://www.gmabooster.com/ GMABooster] from [http://aur.archlinux.org/packages.php?ID=28197 AUR]<br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
=== Swappiness ===<br />
<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
<br />
vm.swappiness=20<br />
vm.vfs_cache_pressure=50<br />
<br />
To test and more on why this may work, take a look at this [http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that article].<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache], also known as the ramzswap kernel module, creates a swap device in RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available in the [http://aur.archlinux.org/packages.php?ID=40063 AUR].<br />
<br />
It is also possible (and recommended) to tell compcache to fall back on the hard drive swap when full. To do this, define a backing swap device in the configuration file. This swap device must not be in use when compcache is started, so remove it from your /etc/fstab!<br />
<br />
This is also a good way to reduce disk read/write cycles due to swap on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,nodev,nosuid,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
=== Preloading ===<br />
Preloading is the action of putting and keeping target files into the RAM. The practical use is that preloaded applications always start very quickly, because reading from the RAM is always quicker than from the hard drive. However, part of your RAM will be dedicated to this task, but no more than if you kept the application open. Therefore, preloading is best used with heavy, often-used applications, like firefox and openoffice.<br />
==== Go-preload ====<br />
[http://aur.archlinux.org/packages.php?ID=34207 Go-preload] is a small daemon created in the [http://forums.gentoo.org/viewtopic-t-789818-view-next.html?sid=5457cff93039fc7d4a3e445ef90f9821 gentoo forum]. To use it, first run this command in a terminal for each program you want to preload at boot:<br />
# gopreload-prepare program<br />
Then, as instructed, press enter when the program is fully loaded. This will add a list of files needed by the program in {{Filename|/usr/share/gopreload/enabled}}. To load all lists at boot, simply add gopreload to your DAEMONS array in {{Filename|/etc/rc.conf}}. To disable the loading of a program, remove the appropriate list in {{Filename|/usr/share/gopreload/enabled}}, or move it to {{Filename|/usr/share/gopreload/disabled}}.<br />
====Preload====<br />
A more automated, albeit less KISS, approach is used by [[Preload]]. All you have to do is add it to your DAEMONS array in {{Filename|/etc/rc.conf}}. It will monitor the most used files on your system, and with time build its own list of files to preload at boot.<br />
====Readahead====<br />
[[Readahead]] is a tool that can cache files before needed and help you accelerating program loading.<br />
<br />
==Boot time==<br />
You can find tutorials with good tips in the article [[Improve Boot Performance]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The {{Codeline|fastboot}} option usually can take off one second or so. Also, if you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
===Speed Up udev===<br />
<br />
Performance gains can be realized by bypassing the blacklisting logic present in the {{Filename|/lib/udev/load-modules.sh}} script. See [[Speed_Up_udev]] for additional details.<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox Tips and Tweaks#Improve rendering by disabling pango |disabling pango]], [[Firefox Tips and Tweaks#Defragment the profile's SQLite databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing|Turning off anti-phishing]].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum has made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=118737Improving performance2010-10-06T03:03:50Z<p>Rttommy: Removed paragraph about glxgears</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{i18n|Maximizing Performance}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there are some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. First step would be to verify if direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run lightweight environments and applications.<br />
* Use a [[Window Manager|window manager]] instead of a [[Desktop Environment]]. Choices include [[dwm]], [[Openbox]] and [[JWM]].<br />
* Choose a minimal Desktop Environment over [[GNOME]] and [[KDE]]. Choices include [[LXDE]] and [[Xfce]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008], [http://bbs.archlinux.org/viewtopic.php?id=78490 2009], and [http://bbs.archlinux.org/viewtopic.php?id=88515 2010].<br />
* Remove unnecessary daemons and background what daemons you can in {{Filename|/etc/rc.conf}}.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be measured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your filesystem===<br />
Choosing the best filesystem for a specific system is very important because each has its own strengths. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
<br />
====Summary====<br />
*XFS: Excellent performance with large files. Low speed with small files. A good choice for /home.<br />
*Reiserfs: Excellent performance with small files. A good choice for /var.<br />
*Ext3: Average performance, reliable.<br />
*Ext4: Great overall performance, reliable, has performance issues with sqlite and some other databases.<br />
*JFS: Good overall performance, very low CPU usage.<br />
*Btrfs: Great overall performance (better than ext4), reliable (once it becomes stable). Lots of features. Still in heavy development and considered as unstable. Do not use this filesystem yet unless you know what you are doing and are prepared for potential data loss.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. The former is a superset of the latter (which applies to directories only -- {{Codeline|noatime}} applies to both files and directories). In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,lazy-count=1 size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. <br />
<br />
#/etc/fstab<br />
LABEL=XFSHOME /home xfs noatime,logbufs=8 0 1<br />
<br />
As its speed when dealing with small files is poor, users of XFS should consider using [[Improve_Pacman_Performance#pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
==== Reiserfs ====<br />
<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
<br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data. You can learn more about reiserfs with this [http://www.funtoo.org/en/articles/linux/ffg/2/ article].<br />
<br />
====BTRFS====<br />
Btrfs is a new filesystem offering online defragmentation, optimized mode for SSDs, writable snapshots, changing size of partition without data loss and many other features. Btrfs is still in active development, and is available in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===== mkinitcpio.conf for btrfs =====<br />
<br />
For non-root btrfs filesystems the btrfs module and dependencies are loaded when required. For a root btrfs filesystem you should ensure the initial ramdisk has the correct modules. There is a dependency of the btrfs module on the libcrc32c module. You can add crc32c to the modules line of /etc/mkinitcpio.conf like so:<br />
<br />
MODULES="crc32c libcrc32c zlib_deflate btrfs"<br />
<br />
This avoids pitfalls like "unknown symbol" errors when loading the btrfs modules.<br />
See also [http://aur.archlinux.org/packages.php?ID=33376 mkinitcpio-btrfs].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k(128k) block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel.<br />
Since the linked guide is for Gentoo the next commands outline the steps especially for Arch. Basically we have got install two packages to get it working:<br />
$ pacman -S aufs2 squashfs-tools<br />
This command installs the aufs-modules and some userspace-tools for the squash-filesystem.<br />
Now we need some extra directories where we can store the archive of /usr as read-only and another folder where we can store the data changed after the last compression as writeable:<br />
$ mkdir -p /squashed/usr/{ro,rw}<br />
Now that we got a rough setup you should perform a complete system-upgrade since every change of content in /usr after the compression will be excluded from this speedup. If you use prelink you should also perform a complete prelink before creating the archive. Now it is time to invoke the command to compress /usr:<br />
$ mksquashfs /usr /squashed/usr/usr.sfs -b 65536<br />
These parameters/options are the ones suggested by the Gentoo link but there might be some room for improvement using some of the options described [http://www.tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html#mksqusing here].<br />
Now to get the archive mounted together with the writeable folder it is necessary to edit fstab:<br />
$ nano /etc/fstab<br />
Add the following lines:<br />
/squashed/usr/usr.sfs /squashed/usr/ro squashfs loop,ro 0 0 <br />
usr /usr aufs udba=reval,br:/squashed/usr/rw:/squashed/usr/ro 0 0<br />
Now you should be done and able to reboot. The original Author suggests to delete all the old content of /usr, but this might cause some problems if anything goes wrong during some later re-compression. It is more safe to leave the old files in place just to be on the safe side.<br />
<br />
A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate the process of re-compressing (read updating) the archive since the tutorial is meant for Gentoo and some options don't correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
[[SSD#Tips_for_Maximizing_SSD_Performance]]<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel motherboards are notorious for disabling the capacity to overclock.<br />
<br />
A way to modify performance ([http://lkml.org/lkml/2009/9/6/136 ref]) is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler (CFS) with the Brain Fuck Scheduler (BFS).<br />
<br />
You can install [http://aur.archlinux.org/packages.php?ID=32877 kernel26-ck] from the [[AUR]].<br />
<br />
Or, install [http://aur.archlinux.org/packages.php?ID=36384 kernel26-bfs], which just contains the BFS patch.<br />
<br />
Some other kernels in the AUR have the BFS patch included or available as an option.<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[http://thermal.cnde.iastate.edu/~sdh4/verynice/ Verynice] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritisation greatly improves system responsiveness under heavy load.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. Intel chipsets users can install [http://www.gmabooster.com/ GMABooster] from [http://aur.archlinux.org/packages.php?ID=28197 AUR]<br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
=== Swappiness ===<br />
<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
<br />
vm.swappiness=20<br />
vm.vfs_cache_pressure=50<br />
<br />
To test and more on why this may work, take a look at this [http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that article].<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache], also known as the ramzswap kernel module, creates a swap device in RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available in [community].<br />
<br />
It is also possible (and recommended) to tell compcache to fall back on the hard drive swap when full. To do this, define a backing swap device in the configuration file. This swap device must not be in use when compcache is started, so remove it from your /etc/fstab!<br />
<br />
This is also a good way to reduce disk read/write cycles due to swap on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
=== Preloading ===<br />
Preloading is the action of of putting and keeping target files into the RAM. The practical use is that preloaded applications always start very quickly, because reading from the RAM is always quicker than from the hard drive. However, part of your RAM will be dedicated to this task, but no more than if you kept the application open. Therefore, preloading is best used with heavy, often-used applications, like firefox and openoffice.<br />
==== Go-preload ====<br />
[http://aur.archlinux.org/packages.php?ID=34207 Go-preload] is a small daemon created in the [http://forums.gentoo.org/viewtopic-t-789818-view-next.html?sid=5457cff93039fc7d4a3e445ef90f9821 gentoo forum]. To use it, first run this command in a terminal for each program you want to preload at boot:<br />
# gopreload-prepare program<br />
Then, as instructed, press enter when the program is fully loaded. This will add a list of files needed by the program in {{Filename|/usr/share/gopreload/enabled}}. To load all lists at boot, simply add gopreload to your DAEMONS array in {{Filename|/etc/rc.conf}}. To disable the loading of a program, remove the appropriate list in {{Filename|/usr/share/gopreload/enabled}}, or move it to {{Filename|/usr/share/gopreload/disabled}}.<br />
====Preload====<br />
A more automated, albeit less KISS, approach is used by [[Preload]]. All you have to do is add it to your DAEMONS array in {{Filename|/etc/rc.conf}}. It will monitor the most used files on your system, and with time build its own list of files to preload at boot.<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The {{Codeline|fastboot}} option usually can take off one second or so. Also, if you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
===Speed Up udev===<br />
<br />
Performance gains can be realized by bypassing the blacklisting logic present in the {{Filename|/lib/udev/load-modules.sh}} script. See [[Speed_Up_udev]] for additional details.<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum has made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=105241Improving performance2010-05-02T16:20:09Z<p>Rttommy: /* Preloading */ Added preload</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there are some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008], [http://bbs.archlinux.org/viewtopic.php?id=78490 2009], and [http://bbs.archlinux.org/viewtopic.php?id=88515 2010].<br />
* Removing unnecessary daemons in rc.conf.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be measured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your filesystem===<br />
Choosing the best filesystem for a specific system is very important because each has its own strengths. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
<br />
====Summary====<br />
*XFS: Excellent performance with large files. Low speed with small files. A good choice for /home.<br />
*Reiserfs: Excellent performance with small files. A good choice for /var.<br />
*Ext3: Average performance, reliable.<br />
*Ext4: Great overall performance, reliable, has performance issues with sqlite and some other databases.<br />
*JFS: Good overall performance, very low CPU usage.<br />
*Btrfs: Great overall performance (better than ext4), reliable (once it becomes stable). Lots of features. Still in heavy development and considered as unstable. Do not use this filesystem yet unless you know what you are doing and are prepared for potential data loss.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
==== Reiserfs ====<br />
<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
<br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data. You can learn more about reiserfs with this [http://www.funtoo.org/en/articles/linux/ffg/2/ article].<br />
<br />
====BTRFS====<br />
Btrfs is a new filesystem offering online defragmentation, optimized mode for SSDs, writable snapshots, changing size of partition without data loss and many other features. Btrfs is still in active development, and is available in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===== mkinitcpio.conf for btrfs =====<br />
<br />
There is an undocumented dependency of the libcrc32c module required by btrfs. You need to add crc32c to the modules line of /etc/mkinitcpio.conf like so:<br />
<br />
MODULES="atl2 eeepc_laptop squashfs aufs crc32c libcrc32c zlib_deflate btrfs"<br />
<br />
This avoids pitfalls like "unknown symbol" errors when loading the btrfs modules.<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k(128k) block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel.<br />
Since the linked guide is for Gentoo the next commands outline the steps especially for Arch. Basically we have got install two packages to get it working:<br />
$ pacman -S aufs2 squashfs-tools<br />
This command installs the aufs-modules and some userspace-tools for the squash-filesystem.<br />
Now we need some extra directories where we can store the archive of /usr as read-only and another folder where we can store the data changed after the last compression as writeable:<br />
$ mkdir /squashed<br />
$ mkdir /squashed/usr<br />
$ cd /squashed/usr<br />
$ mkdir ro<br />
$ mkdir rw<br />
Now that we got a rough setup you should perform a complete system-upgrade since every change of content in /usr after the compression will be excluded from this speedup. If you use prelink you should also perform a complete prelink before creating the archive. Now it is time to invoke the command to compress /usr:<br />
$ mksquashfs /usr /squashed/usr/usr.sfs -b 65536<br />
These parameters/options are the ones suggested by the Gentoo link but there might be some room for improvement using some of the options described [http://www.tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html#mksqusing here].<br />
Now to get the archive mounted together with the writeable folder it is necessary to edit fstab:<br />
$ nano /etc/fstab<br />
Add the following lines:<br />
/squashed/usr/usr.sfs /squashed/usr/ro squashfs loop,ro 0 0 <br />
usr /usr aufs udba=reval,br:/squashed/usr/rw:/squashed/usr/ro 0 0<br />
Now you should be done and able to reboot. The original Author suggests to delete all the old content of /usr, but this might cause some problems if anything goes wrong during some later re-compression. It is more save to leave the old files in place just to be on the save side.<br />
<br />
A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate the process of re-compressing(read updating) the archive since the tutorial is meant for Gentoo and some options don't correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
See this [http://cptl.org/wp/index.php/2010/03/30/tuning-solid-state-drives-in-linux/ guide] for information on the introduction of online SSD TRIM support in the 2.6.33 kernel.<br />
<br />
If you have the latest Kernel and use ext4 you can simply activate SSD live TRIM support by adding one mount option to your fstab.<br />
discard<br />
example:<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
{{warning| Make sure you have a Kernel and a SSD with latest firmware which are known to support TRIM !<br />
Otherwise you could lose your data, so be sure to always backup beforehand!}}<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel motherboards are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler (CFS) with the Brain Fuck Scheduler (BFS).<br />
<br />
To install a kernel that contains the ck patchset from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
Or a kernel that contains just BFS patch:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
Other kernels that have the BFS patch included or as an option:<br />
<br />
$ yaourt -S kernel26-ice<br />
$ yaourt -S kernel26-zen<br />
$ yaourt -S kernel26zen-git<br />
<br />
{{Note|The PKGBUILD bust be edited to enable BFS in kernel26-ice.}}<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[http://thermal.cnde.iastate.edu/~sdh4/verynice/ Verynice] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritisation greatly improves system responsiveness under heavy load.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
=== Swappiness ===<br />
<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
To test and more on why this may work, take a look at this [http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that article].<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
=== Preloading ===<br />
Preloading is the action of of putting and keeping target files into the RAM. The practical use is that preloaded applications always start very quickly, because reading from the RAM is always quicker than from the hard drive. However, part of your RAM will be dedicated to this task, but no more than if you kept the application open. Therefore, preloading is best used with heavy, often-used applications, like firefox and openoffice.<br />
==== Go-preload ====<br />
[http://aur.archlinux.org/packages.php?ID=34207 Go-preload] is a small daemon created in the [http://forums.gentoo.org/viewtopic-t-789818-view-next.html?sid=5457cff93039fc7d4a3e445ef90f9821 gentoo forum]. To use it, first run this command in a terminal for each program you want to preload at boot:<br />
# gopreload-prepare program<br />
Then, as instructed, press enter when the program is fully loaded. This will add a list of files needed by the program in {{Filename|/usr/share/gopreload/enabled}}. To load all lists at boot, simply add gopreload to your DAEMONS array in {{Filename|/etc/rc.conf}}. To disable the loading of a program, remove the appropriate list in {{Filename|/usr/share/gopreload/enabled}}, or move it to {{Filename|/usr/share/gopreload/disabled}}.<br />
====Preload====<br />
A more automated, albeit less KISS, approach is used by [[Preload]]. All you have to do is add it to your DAEMONS array in {{Filename|/etc/rc.conf}}. It will monitor the most used files on your system, and with time build its own list of files to preload at boot.<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The {{Codeline|fastboot}} option usually can take off one second or so. Also, if you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=105240Improving performance2010-05-02T16:15:07Z<p>Rttommy: Added preloading section</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there are some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008], [http://bbs.archlinux.org/viewtopic.php?id=78490 2009], and [http://bbs.archlinux.org/viewtopic.php?id=88515 2010].<br />
* Removing unnecessary daemons in rc.conf.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be measured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your filesystem===<br />
Choosing the best filesystem for a specific system is very important because each has its own strengths. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
<br />
====Summary====<br />
*XFS: Excellent performance with large files. Low speed with small files. A good choice for /home.<br />
*Reiserfs: Excellent performance with small files. A good choice for /var.<br />
*Ext3: Average performance, reliable.<br />
*Ext4: Great overall performance, reliable, has performance issues with sqlite and some other databases.<br />
*JFS: Good overall performance, very low CPU usage.<br />
*Btrfs: Great overall performance (better than ext4), reliable (once it becomes stable). Lots of features. Still in heavy development and considered as unstable. Do not use this filesystem yet unless you know what you are doing and are prepared for potential data loss.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
==== Reiserfs ====<br />
<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
<br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data. You can learn more about reiserfs with this [http://www.funtoo.org/en/articles/linux/ffg/2/ article].<br />
<br />
====BTRFS====<br />
Btrfs is a new filesystem offering online defragmentation, optimized mode for SSDs, writable snapshots, changing size of partition without data loss and many other features. Btrfs is still in active development, and is available in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===== mkinitcpio.conf for btrfs =====<br />
<br />
There is an undocumented dependency of the libcrc32c module required by btrfs. You need to add crc32c to the modules line of /etc/mkinitcpio.conf like so:<br />
<br />
MODULES="atl2 eeepc_laptop squashfs aufs crc32c libcrc32c zlib_deflate btrfs"<br />
<br />
This avoids pitfalls like "unknown symbol" errors when loading the btrfs modules.<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k(128k) block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel.<br />
Since the linked guide is for Gentoo the next commands outline the steps especially for Arch. Basically we have got install two packages to get it working:<br />
$ pacman -S aufs2 squashfs-tools<br />
This command installs the aufs-modules and some userspace-tools for the squash-filesystem.<br />
Now we need some extra directories where we can store the archive of /usr as read-only and another folder where we can store the data changed after the last compression as writeable:<br />
$ mkdir /squashed<br />
$ mkdir /squashed/usr<br />
$ cd /squashed/usr<br />
$ mkdir ro<br />
$ mkdir rw<br />
Now that we got a rough setup you should perform a complete system-upgrade since every change of content in /usr after the compression will be excluded from this speedup. If you use prelink you should also perform a complete prelink before creating the archive. Now it is time to invoke the command to compress /usr:<br />
$ mksquashfs /usr /squashed/usr/usr.sfs -b 65536<br />
These parameters/options are the ones suggested by the Gentoo link but there might be some room for improvement using some of the options described [http://www.tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html#mksqusing here].<br />
Now to get the archive mounted together with the writeable folder it is necessary to edit fstab:<br />
$ nano /etc/fstab<br />
Add the following lines:<br />
/squashed/usr/usr.sfs /squashed/usr/ro squashfs loop,ro 0 0 <br />
usr /usr aufs udba=reval,br:/squashed/usr/rw:/squashed/usr/ro 0 0<br />
Now you should be done and able to reboot. The original Author suggests to delete all the old content of /usr, but this might cause some problems if anything goes wrong during some later re-compression. It is more save to leave the old files in place just to be on the save side.<br />
<br />
A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate the process of re-compressing(read updating) the archive since the tutorial is meant for Gentoo and some options don't correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
See this [http://cptl.org/wp/index.php/2010/03/30/tuning-solid-state-drives-in-linux/ guide] for information on the introduction of online SSD TRIM support in the 2.6.33 kernel.<br />
<br />
If you have the latest Kernel and use ext4 you can simply activate SSD live TRIM support by adding one mount option to your fstab.<br />
discard<br />
example:<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
{{warning| Make sure you have a Kernel and a SSD with latest firmware which are known to support TRIM !<br />
Otherwise you could lose your data, so be sure to always backup beforehand!}}<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel motherboards are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler (CFS) with the Brain Fuck Scheduler (BFS).<br />
<br />
To install a kernel that contains the ck patchset from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
Or a kernel that contains just BFS patch:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
Other kernels that have the BFS patch included or as an option:<br />
<br />
$ yaourt -S kernel26-ice<br />
$ yaourt -S kernel26-zen<br />
$ yaourt -S kernel26zen-git<br />
<br />
{{Note|The PKGBUILD bust be edited to enable BFS in kernel26-ice.}}<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[http://thermal.cnde.iastate.edu/~sdh4/verynice/ Verynice] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritisation greatly improves system responsiveness under heavy load.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
=== Swappiness ===<br />
<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
To test and more on why this may work, take a look at this [http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that article].<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
=== Preloading ===<br />
Preloading is the action of of putting and keeping target files into the RAM. The practical use is that preloaded applications always start very quickly, because reading from the RAM is always quicker than from the hard drive. However, part of your RAM will be dedicated to this task, but no more than if you kept the application open. Therefore, preloading is best used with heavy, often-used applications, like firefox and openoffice.<br />
==== Go-preload ====<br />
[http://aur.archlinux.org/packages.php?ID=34207 Go-preload] is a small daemon created in the [http://forums.gentoo.org/viewtopic-t-789818-view-next.html?sid=5457cff93039fc7d4a3e445ef90f9821 gentoo forum]. To use it, first run this command in a terminal for each program you want to preload at boot:<br />
# gopreload-prepare program<br />
Then, as instructed, press enter when the program is fully loaded. This will add a list of files needed by the program in {{Filename|/usr/share/gopreload/enabled}}. To load all lists at boot, simply add gopreload to your DAEMONS array in {{Filename|/etc/rc.conf}}. To disable the loading of a program, remove the appropriate list in {{Filename|/usr/share/gopreload/enabled}}, or move it to {{Filename|/usr/share/gopreload/disabled}}.<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The {{Codeline|fastboot}} option usually can take off one second or so. Also, if you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=101222Improving performance2010-03-26T17:48:00Z<p>Rttommy: /* Know your system */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there are some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008], [http://bbs.archlinux.org/viewtopic.php?id=78490 2009], and [http://bbs.archlinux.org/viewtopic.php?id=88515 2010].<br />
* Removing unnecessary daemons in rc.conf.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be measured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strengths. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controversial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
==== Reiserfs ====<br />
<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
<br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data. You can learn more about reiserfs with this [http://www.funtoo.org/en/articles/linux/ffg/2/ article].<br />
<br />
====BTRFS====<br />
Btrfs is a new filesystem offering online defragmentation, optimized mode for SSDs, writable snapshots, changing size of partition without data loss and many other features. Btrfs is still in active development, and is available in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k(128k) block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel.<br />
Since the linked guide is for Gentoo the next commands outline the steps especially for Arch. Basically we have got install two packages to get it working:<br />
$ pacman -S aufs2 squashfs-tools<br />
This command installs the aufs-modules and some userspace-tools for the squash-filesystem.<br />
Now we need some extra directories where we can store the archive of /usr as read-only and another folder where we can store the data changed after the last compression as writeable:<br />
$ mkdir /squashed<br />
$ mkdir /squashed/usr<br />
$ cd /squashed/usr<br />
$ mkdir ro<br />
$ mkdir rw<br />
Now that we got a rough setup you should perform a complete system-upgrade since every change of content in /usr after the compression will be excluded from this speedup. If you use prelink you should also perform a complete prelink before creating the archive. Now it is time to invoke the command to compress /usr:<br />
$ mksquashfs /usr /squashed/usr/usr.sfs -b 65536<br />
These parameters/options are the ones suggested by the Gentoo link but there might be some room for improvement using some of the options described [http://www.tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html#mksqusing here].<br />
Now to get the archive mounted together with the writeable folder it is necessary to edit fstab:<br />
$ nano /etc/fstab<br />
Add the following lines:<br />
/squashed/usr/usr.sfs /squashed/usr/ro squashfs loop,ro 0 0 <br />
usr /usr aufs udba=reval,br:/squashed/usr/rw:/squashed/usr/ro 0 0<br />
Now you should be done and able to reboot. The original Author suggests to delete all the old content of /usr, but this might cause some problems if anything goes wrong during some later re-compression. It is more save to leave the old files in place just to be on the save side.<br />
<br />
A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate the process of re-compressing(read updating) the archive since the tutorial is meant for Gentoo and some options don't correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel motherboards are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler (CFS) with the Brain Fuck Scheduler(BFS).<br />
<br />
To install a kernel that contains the ck patchset from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
Or a kernel that contains just BFS patch:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
Other kernels that have the BFS patch included or as an option:<br />
<br />
$ yaourt -S kernel26-ice<br />
$ yaourt -S kernel26-zen<br />
$ yaourt -S kernel26zen-git<br />
<br />
{{Note|The PKGBUILD bust be edited to enable BFS in kernel26-ice.}}<br />
<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[http://thermal.cnde.iastate.edu/~sdh4/verynice/ Verynice] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritisation greatly improves system responsiveness under heavy load.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
=== Swappiness ===<br />
<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
To test and more on why this may work, take a look at this [http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that article].<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The {{Codeline|fastboot}} option usually can take off one second or so. Also, if you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=101221Improving performance2010-03-26T17:38:14Z<p>Rttommy: /* Kernel boot options */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008], [http://bbs.archlinux.org/viewtopic.php?id=78490 2009], and [http://bbs.archlinux.org/viewtopic.php?id=88515 2010].<br />
* Removing unnecessary daemons in rc.conf.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be measured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strengths. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controversial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
==== Reiserfs ====<br />
<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
<br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data. You can learn more about reiserfs with this [http://www.funtoo.org/en/articles/linux/ffg/2/ article].<br />
<br />
====BTRFS====<br />
Btrfs is a new filesystem offering online defragmentation, optimized mode for SSDs, writable snapshots, changing size of partition without data loss and many other features. Btrfs is still in active development, and is available in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k(128k) block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel.<br />
Since the linked guide is for Gentoo the next commands outline the steps especially for Arch. Basically we have got install two packages to get it working:<br />
$ pacman -S aufs2 squashfs-tools<br />
This command installs the aufs-modules and some userspace-tools for the squash-filesystem.<br />
Now we need some extra directories where we can store the archive of /usr as read-only and another folder where we can store the data changed after the last compression as writeable:<br />
$ mkdir /squashed<br />
$ mkdir /squashed/usr<br />
$ cd /squashed/usr<br />
$ mkdir ro<br />
$ mkdir rw<br />
Now that we got a rough setup you should perform a complete system-upgrade since every change of content in /usr after the compression will be excluded from this speedup. If you use prelink you should also perform a complete prelink before creating the archive. Now it is time to invoke the command to compress /usr:<br />
$ mksquashfs /usr /squashed/usr/usr.sfs -b 65536<br />
These parameters/options are the ones suggested by the Gentoo link but there might be some room for improvement using some of the options described [http://www.tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html#mksqusing here].<br />
Now to get the archive mounted together with the writeable folder it is necessary to edit fstab:<br />
$ nano /etc/fstab<br />
Add the following lines:<br />
/squashed/usr/usr.sfs /squashed/usr/ro squashfs loop,ro 0 0 <br />
usr /usr aufs udba=reval,br:/squashed/usr/rw:/squashed/usr/ro 0 0<br />
Now you should be done and able to reboot. The original Author suggests to delete all the old content of /usr, but this might cause some problems if anything goes wrong during some later re-compression. It is more save to leave the old files in place just to be on the save side.<br />
<br />
A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate the process of re-compressing(read updating) the archive since the tutorial is meant for Gentoo and some options don't correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel motherboards are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler (CFS) with the Brain Fuck Scheduler(BFS).<br />
<br />
To install a kernel that contains the ck patchset from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
Or a kernel that contains just BFS patch:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
Other kernels that have the BFS patch included or as an option:<br />
<br />
$ yaourt -S kernel26-ice<br />
$ yaourt -S kernel26-zen<br />
$ yaourt -S kernel26zen-git<br />
<br />
{{Note|The PKGBUILD bust be edited to enable BFS in kernel26-ice.}}<br />
<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[http://thermal.cnde.iastate.edu/~sdh4/verynice/ Verynice] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritisation greatly improves system responsiveness under heavy load.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
=== Swappiness ===<br />
<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
To test and more on why this may work, take a look at this [http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that article].<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The {{Codeline|fastboot}} option usually can take off one second or so. Also, if you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=98058Improving performance2010-02-23T21:46:53Z<p>Rttommy: </p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009].<br />
* Removing unnecessary daemons in rc.conf.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be measured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strengths. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controversial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
<br />
====BTRFS====<br />
Btrfs is a new filesystem offering online defragmentation, optimized mode for SSDs, writable snapshots, changing size of partition without data loss and many other features. Btrfs is still in active development, and is available in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically. A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate this process since the tutorial is meant for Gentoo and some options don't correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[http://thermal.cnde.iastate.edu/~sdh4/verynice/ Verynice] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritisation greatly improves system responsiveness under heavy load.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=98057Improving performance2010-02-23T21:43:05Z<p>Rttommy: /* Know your system */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009].<br />
* Removing unnecessary daemons in rc.conf.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
<br />
====BTRFS====<br />
Btrfs is a new filesystem offering online defragmentation, optimized mode for SSDs, writable snapshots, changing size of partition without dataloss and many other features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically. A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate this process since the tutorial is meant for Gentoo and some options don't correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[http://thermal.cnde.iastate.edu/~sdh4/verynice/ Verynice] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritisation greatly improves system responsiveness under heavy load.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=96322Improving performance2010-02-11T23:14:27Z<p>Rttommy: Added Verynice</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009].<br />
* Removing unnecessary daemons in rc.conf.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[http://thermal.cnde.iastate.edu/~sdh4/verynice/ Verynice] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritisation greatly improves system responsiveness under heavy load.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=95322Improving performance2010-02-07T06:59:32Z<p>Rttommy: Removed expension template</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009].<br />
* Removing unnecessary daemons in rc.conf.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=95256Improving performance2010-02-06T19:26:42Z<p>Rttommy: /* The first thing to do */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009].<br />
* Removing unnecessary daemons in rc.conf.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=IBM_ThinkPad_X31&diff=95255IBM ThinkPad X312010-02-06T19:17:30Z<p>Rttommy: /* Dri */</p>
<hr />
<div>[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
==Introduction==<br />
The IBM Thinkpad X31 is a wonderful little laptop which contains everything you need for your everyday work, and even some gaming, if you tweak things a little. The X31 is rock solid, light (3.7 lbs), and nowadays very cheap. The only drawback is the lack of internal optical drive.You can see the specs of the X31 on [http://www.thinkwiki.org/wiki/Category:X31 ThinkWiki], a wonderful resource with additional informations.<br />
<br />
==Installation==<br />
A basic Arch Linux installation will do just fine for about everything, so I won't talk about sound or other basic stuff. No custom kernel needed. However, you will need the following particular packages:<br />
* ipw2100-fw and wireless_tools for wireless<br />
* xf86-video-ati for direct rendering (see above)<br />
* uswsusp for hibernation (see above)<br />
<br />
The following useful packages are in the [[AUR]].<br />
* rovclock for boosting direct rendering (see above)<br />
<br />
==Hibernation==<br />
Simply save this script as /usr/bin/hibernation:<br />
#!/bin/bash<br />
modprobe -r ehci_hcd <br />
/usr/sbin/s2ram -rf<br />
modprobe ehci_hcd<br />
<br />
You now just have to run this command whenever you want to suspend to ram:<br />
# hibernation<br />
<br />
To hibernate and resume simply by closing the lid of your laptop, simply run this command:<br />
# echo -e "event=button[ /]lid\naction=/usr/bin/hibernation" > /etc/acpi/events/suspend.conf<br />
It simply tells ACPI to run the command "hibernation" on the "lid closed" event.<br />
<br />
Note for those with resume issues after updating to kernel >=2.6.31: disable kernel modesetting by appending "nomodeset" to your kernel parameters.<br />
--[[User:Tad|Tad]] 05:51, 19 October 2009 (EDT)<br />
<br />
==Xorg and direct rendering==<br />
This section assumes the ATI Radeon Mobility M6 LY video card. This can be verified using:<br />
$ lspci | grep Mobility<br />
Here is a minimal {{Filename|xorg.conf}}, optimized for performance:<br />
{{File|name=/etc/X11/xorg.conf|content=<br />
Section "ServerFlags"<br />
Option "AutoAddDevices" "False"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "ati"<br />
BusID "PCI:1:0:0"<br />
Option "AGPMode" "4"<br />
Option "AGPFastWrite" "on" #Faster than default (off)<br />
Option "SWcursor" "off" #Faster than default (on)<br />
Option "EnablePageFlip" "on" #Faster than default (off)<br />
Option "AccelMethod" "EXA" # or XAA, EXA, XAA more stable, XAA is deafult<br />
Option "DynamicClocks" "on"<br />
Option "BIOSHotkeys" "on"<br />
Option "AGPSize" "32" # default: 8<br />
Option "EnableDepthMoves" "true"<br />
EndSection<br />
<br />
Section "Extensions"<br />
Option "Composite" "Disable"<br />
EndSection<br />
}}<br />
{{Note|This configuration disables compositing to improve performance. If you need this feature, set ''Composite'' to ''Enable''. Also, if you use HAL for managing device, set ''AutoAddDevices'' to ''true''.}}<br />
<br />
===Dri===<br />
You can boost dri rendering performance by using this ~/.drirc:<br />
{{File|name=~/.drirc|content=<br />
<driconf><br />
<device screen="0" driver="radeon"><br />
<application name="Default"><br />
<option name="force_s3tc_enable" value="true" /><br />
<option name="no_rast" value="false" /><br />
<option name="fthrottle_mode" value="2" /><br />
<option name="tcl_mode" value="3" /><br />
<option name="texture_depth" value="0" /><br />
<option name="def_max_anisotropy" value="1.0" /><br />
<option name="no_neg_lod_bias" value="false" /><br />
<option name="texture_units" value="2" /><br />
<option name="dither_mode" value="0" /><br />
<option name="hyperz" value="true" /><br />
<option name="round_mode" value="1" /><br />
<option name="color_reduction" value="0" /><br />
<option name="vblank_mode" value="0" /><br />
<option name="allow_large_textures" value="2" /><br />
</application><br />
</device><br />
</driconf><br />
}}<br />
If you wish to modify your dri configuration, install {{Package Official|driconf}}.<br />
<br />
===Rovclock===<br />
You can also overclock your graphic card. As far as I know, there is no real drawback, but you can play it safe and only use it while running a game or compiz or any application using your graphic card:<br />
# rovclock -c 220 -m 210<br />
Use this command to get back to default settings:<br />
# rovclock -c 144 -m 144<br />
If you what to enable it permanently, you just have to add the first command in your ~/.xinitrc, or use any other way to run it once X is started.<br />
If, however, you barely use your graphic card, you can lower both power usage and temperature slightly by underclocking your graphic card at boot. Add this command to ~/.xinitrc :<br />
# rovclock -c 90 -m 100<br />
<br />
===Dual Screen===<br />
If you want to use an external screen for a presentation or as an extended desktop, you can use xrandr.<br />
For an extended desktop, you should first add one line in your /etc/x11/xorg.conf configuration file at the SubSection "Display" area:<br />
Before:<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1024x768" "800x600" "640x480"<br />
EndSubSection<br />
<br />
After:<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1024x768" "800x600" "640x480"<br />
Virtual 2304 1024<br />
EndSubSection<br />
<br />
The numbers are the total rectangular resolution that you need to use. In this case, I'm using the internal 1024x768 screen and an external 1280x1024 screen on the right. The total resolution is 1024+1280=2304 pixels large and 1024>768=1024 pixels height.<br />
<br />
Note that in 24 bits with this option, the performance is affected for 3D drawing, so you may need to comment it and use only one screen when you need the graphical power.<br />
<br />
Then restart your X server (ctrl-alt-backspace). You can issue this command in a shell:<br />
xrandr --output VGA-0 --right-of LVDS<br />
<br />
To find the exact name of the monitors and the maximum resolution that you set up in the configuration file, you can type just '''xrandr''' without arguments.<br />
<br />
==Powersaving==<br />
Here are various method to save power:<br />
===Laptop-mode===<br />
This will put your screen brightness to the minimum level when on battery and restore it to maximum when on ac power:<br />
# echo -e '#!/bin/bash\necho 0 > /sys/class/backlight/thinkpad_screen/brightness' > /etc/laptop-mode/batt-start/battscript<br />
# chmod 0755 /etc/laptop-mode/batt-start/battscript<br />
# echo -e '#!/bin/bash\necho 7 > /sys/class/backlight/thinkpad_screen/brightness' > /etc/laptop-mode/lm-ac-start/acscript<br />
# chmod 0755 /etc/laptop-mode/lm-ac-start/acscript<br />
# ln -s /etc/laptop-mode/lm-ac-start/acscript /etc/laptop-mode/onlm-ac-start/acscript<br />
It will create scripts, executed by the laptop-mode daemon when switching the power source, that change the brightness of your screen using the thinkpad_acpi module.<br />
===Undervolting===<br />
The X31 CPUs can be undervolted, which means they will offer you the same performance, but with more battery life and a cooler laptop. From personal experience, my CPU temperature,during 100% activity, dropped by 15-20°C just by using this patch. This is extremely easy using the linux-phc patch, but only if you know the proper values to give the CPU. Informations on how to find them is available [http://gentoo-wiki.com/HOWTO_Undervolt_a_Pentium_M_CPU here] or [http://www.thinkwiki.org/wiki/Pentium_M_undervolting_and_underclocking here]. I know it can be hard to find your own values, so here is a table were you can indicate what are the good values for each of the X31 CPUs:<br />
* Pentium-m 1600MHz : 34 26 18 12 8 5<br>Please note you computer may freeze once a month because of those values. If you find more stable ones, please indicate them.<br />
One you have your values, just run:<br />
# echo VALUES > /sys/devices/system/cpu/cpu0/cpufreq/phc_vids<br />
For example:<br />
# echo 34 26 18 12 8 5 > /sys/devices/system/cpu/cpu0/cpufreq/phc_vids<br />
You can add this command to your /etc/rc.local to make the undervolting permanent.<br />
<br />
===Modprobe.conf===<br />
Put those line in your /etc/modprobe.conf:<br />
options usbcore autosuspend=1<br />
options ipw2100 associate=0<br />
options snd_ac97_codec power_save=1<br />
options thinkpad-acpi experimental=1 fan_control=1<br />
The three first lines put some of your devices in power-saving mode, respectively the USB ports, the wireless card and the sound card.<br />
Note that you need the last line in order to control your fan speed (see above)<br />
<br />
===Powertop===<br />
To see additional sources of power drain, install powertop:<br />
# pacman -S powertop<br />
And run it while on battery power.<br />
<br />
===Hard drive dilemna===<br />
As set earlier, the hard drive is on a power-saving mode that can make it spin off and on often. It may reduce its lifetime. You can install the '''smartmontools''' package and issue this command:<br />
# smartctl -A /dev/sda | grep Load_Cycle_Count<br />
If the number is growing too fast, you might want to set off the powersaving mode by issuing: <br />
# hdparm -B 254 /dev/sda<br />
<br />
See the above item rc.local to modify it at boot time.<br />
<br />
==Other==<br />
===Fan-control===<br />
You can use a script from [http://www.thinkwiki.org/wiki/ThinkWiki ThinkWiki] to considerably lower your CPU temperature. Simply download it from [http://www.thinkwiki.org/index.php?title=Code/tp-fancontrol&action=raw&ctype=application/octet-stream here], rename it to tp-fancontrol, and run:<br />
# chmod 0755 tp-fancontrol<br />
# mv tp-fancontrol /usr/bin<br />
To run the script at each boot, add this line to your /etc/rc.local:<br />
tp-fancontrol -d<br />
Also, I suggest changing the first maximum temperature threshold (the CPU one) to 55. Just edit /usr/bin/tp-fancontrol, the file is self-explanatory.<br />
<br />
===Wireless and WPA===<br />
If you have the Cisco neta504 wifi card, it's a bit tricky to use the wpa encryption with it. <br />
Firstofall, remove and blacklist the airo and the airo_cs modules in your /etc/rc.conf<br />
remove the module airo from the kernel<br />
# rmmod airo<br />
# rmmod airo_cs<br />
then install ndiswrapper<br />
# pacman -S ndiswrapper<br />
<br />
download the neta504 driver for windows and unpack it (Be sure that you have unpacked the whole driver !) Then run :<br />
# ndiswrapper -i /path/to/your/dir/netA504.inf<br />
<br />
Save the ndiswrapper conf file :<br />
# ndiswrapper -m<br />
# ndiswrapper -ma<br />
# ndiswrapper -mi<br />
<br />
Now you can add to your kernel the module :<br />
# modprobe ndiswrapper<br />
<br />
and voilà !<br />
I've tried this with wicd and it works flawlessly !<br />
<br />
=== Audio keys ===<br />
To enable the audio keys interfacing with ALSA, add:<br />
event=ibm/hotkey HKEY 00000080 *<br />
action=/etc/acpi/soundkey.sh %e<br />
to /etc/acpi/events/soundkey, and:<br />
#!/bin/bash<br />
<br />
echo here > /tmp/fish<br />
echo $4 >> /tmp/fish<br />
case "$4" in<br />
00001015)<br />
amixer -c 0 set Master playback unmute<br />
amixer -c 0 set Master playback 3%+<br />
;;<br />
00001016)<br />
amixer -c 0 set Master playback unmute<br />
amixer -c 0 set Master playback 3%-<br />
;;<br />
00001017)<br />
amixer -c 0 set Master playback mute<br />
;;<br />
esac<br />
to /etc/acpi/soundkey.sh, and chown 755 it.<br />
<br />
You'll also need to add:<br />
<br />
echo enable,0xffffffff >/proc/acpi/ibm/hotkey<br />
<br />
to /etc/rc.local or somewhere similiar for the events to be recognised.</div>Rttommyhttps://wiki.archlinux.org/index.php?title=IBM_ThinkPad_X31&diff=95254IBM ThinkPad X312010-02-06T19:07:43Z<p>Rttommy: /* Xorg and direct rendering */</p>
<hr />
<div>[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
==Introduction==<br />
The IBM Thinkpad X31 is a wonderful little laptop which contains everything you need for your everyday work, and even some gaming, if you tweak things a little. The X31 is rock solid, light (3.7 lbs), and nowadays very cheap. The only drawback is the lack of internal optical drive.You can see the specs of the X31 on [http://www.thinkwiki.org/wiki/Category:X31 ThinkWiki], a wonderful resource with additional informations.<br />
<br />
==Installation==<br />
A basic Arch Linux installation will do just fine for about everything, so I won't talk about sound or other basic stuff. No custom kernel needed. However, you will need the following particular packages:<br />
* ipw2100-fw and wireless_tools for wireless<br />
* xf86-video-ati for direct rendering (see above)<br />
* uswsusp for hibernation (see above)<br />
<br />
The following useful packages are in the [[AUR]].<br />
* rovclock for boosting direct rendering (see above)<br />
<br />
==Hibernation==<br />
Simply save this script as /usr/bin/hibernation:<br />
#!/bin/bash<br />
modprobe -r ehci_hcd <br />
/usr/sbin/s2ram -rf<br />
modprobe ehci_hcd<br />
<br />
You now just have to run this command whenever you want to suspend to ram:<br />
# hibernation<br />
<br />
To hibernate and resume simply by closing the lid of your laptop, simply run this command:<br />
# echo -e "event=button[ /]lid\naction=/usr/bin/hibernation" > /etc/acpi/events/suspend.conf<br />
It simply tells ACPI to run the command "hibernation" on the "lid closed" event.<br />
<br />
Note for those with resume issues after updating to kernel >=2.6.31: disable kernel modesetting by appending "nomodeset" to your kernel parameters.<br />
--[[User:Tad|Tad]] 05:51, 19 October 2009 (EDT)<br />
<br />
==Xorg and direct rendering==<br />
This section assumes the ATI Radeon Mobility M6 LY video card. This can be verified using:<br />
$ lspci | grep Mobility<br />
Here is a minimal {{Filename|xorg.conf}}, optimized for performance:<br />
{{File|name=/etc/X11/xorg.conf|content=<br />
Section "ServerFlags"<br />
Option "AutoAddDevices" "False"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "ati"<br />
BusID "PCI:1:0:0"<br />
Option "AGPMode" "4"<br />
Option "AGPFastWrite" "on" #Faster than default (off)<br />
Option "SWcursor" "off" #Faster than default (on)<br />
Option "EnablePageFlip" "on" #Faster than default (off)<br />
Option "AccelMethod" "EXA" # or XAA, EXA, XAA more stable, XAA is deafult<br />
Option "DynamicClocks" "on"<br />
Option "BIOSHotkeys" "on"<br />
Option "AGPSize" "32" # default: 8<br />
Option "EnableDepthMoves" "true"<br />
EndSection<br />
<br />
Section "Extensions"<br />
Option "Composite" "Disable"<br />
EndSection<br />
}}<br />
{{Note|This configuration disables compositing to improve performance. If you need this feature, set ''Composite'' to ''Enable''. Also, if you use HAL for managing device, set ''AutoAddDevices'' to ''true''.}}<br />
<br />
===Dri===<br />
You can boost your performance by using this ~/.drirc:<br />
{{File|name=~/.drirc|content=<br />
<driconf><br />
<device screen="0" driver="radeon"><br />
<application name="Default"><br />
<option name="force_s3tc_enable" value="true" /><br />
<option name="no_rast" value="false" /><br />
<option name="fthrottle_mode" value="2" /><br />
<option name="tcl_mode" value="3" /><br />
<option name="texture_depth" value="0" /><br />
<option name="def_max_anisotropy" value="1.0" /><br />
<option name="no_neg_lod_bias" value="false" /><br />
<option name="texture_units" value="2" /><br />
<option name="dither_mode" value="0" /><br />
<option name="hyperz" value="true" /><br />
<option name="round_mode" value="1" /><br />
<option name="color_reduction" value="0" /><br />
<option name="vblank_mode" value="0" /><br />
<option name="allow_large_textures" value="2" /><br />
</application><br />
</device><br />
</driconf><br />
}}<br />
This will massively improve performance. If you wish to play with your dri configuration, install driconf found in [[AUR]].<br />
<br />
===Rovclock===<br />
You can also overclock your graphic card. As far as I know, there is no real drawback, but you can play it safe and only use it while running a game or compiz or any application using your graphic card:<br />
# rovclock -c 220 -m 210<br />
Use this command to get back to default settings:<br />
# rovclock -c 144 -m 144<br />
If you what to enable it permanently, you just have to add the first command in your ~/.xinitrc, or use any other way to run it once X is started.<br />
If, however, you barely use your graphic card, you can lower both power usage and temperature slightly by underclocking your graphic card at boot. Add this command to ~/.xinitrc :<br />
# rovclock -c 90 -m 100<br />
<br />
===Dual Screen===<br />
If you want to use an external screen for a presentation or as an extended desktop, you can use xrandr.<br />
For an extended desktop, you should first add one line in your /etc/x11/xorg.conf configuration file at the SubSection "Display" area:<br />
Before:<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1024x768" "800x600" "640x480"<br />
EndSubSection<br />
<br />
After:<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1024x768" "800x600" "640x480"<br />
Virtual 2304 1024<br />
EndSubSection<br />
<br />
The numbers are the total rectangular resolution that you need to use. In this case, I'm using the internal 1024x768 screen and an external 1280x1024 screen on the right. The total resolution is 1024+1280=2304 pixels large and 1024>768=1024 pixels height.<br />
<br />
Note that in 24 bits with this option, the performance is affected for 3D drawing, so you may need to comment it and use only one screen when you need the graphical power.<br />
<br />
Then restart your X server (ctrl-alt-backspace). You can issue this command in a shell:<br />
xrandr --output VGA-0 --right-of LVDS<br />
<br />
To find the exact name of the monitors and the maximum resolution that you set up in the configuration file, you can type just '''xrandr''' without arguments.<br />
<br />
==Powersaving==<br />
Here are various method to save power:<br />
===Laptop-mode===<br />
This will put your screen brightness to the minimum level when on battery and restore it to maximum when on ac power:<br />
# echo -e '#!/bin/bash\necho 0 > /sys/class/backlight/thinkpad_screen/brightness' > /etc/laptop-mode/batt-start/battscript<br />
# chmod 0755 /etc/laptop-mode/batt-start/battscript<br />
# echo -e '#!/bin/bash\necho 7 > /sys/class/backlight/thinkpad_screen/brightness' > /etc/laptop-mode/lm-ac-start/acscript<br />
# chmod 0755 /etc/laptop-mode/lm-ac-start/acscript<br />
# ln -s /etc/laptop-mode/lm-ac-start/acscript /etc/laptop-mode/onlm-ac-start/acscript<br />
It will create scripts, executed by the laptop-mode daemon when switching the power source, that change the brightness of your screen using the thinkpad_acpi module.<br />
===Undervolting===<br />
The X31 CPUs can be undervolted, which means they will offer you the same performance, but with more battery life and a cooler laptop. From personal experience, my CPU temperature,during 100% activity, dropped by 15-20°C just by using this patch. This is extremely easy using the linux-phc patch, but only if you know the proper values to give the CPU. Informations on how to find them is available [http://gentoo-wiki.com/HOWTO_Undervolt_a_Pentium_M_CPU here] or [http://www.thinkwiki.org/wiki/Pentium_M_undervolting_and_underclocking here]. I know it can be hard to find your own values, so here is a table were you can indicate what are the good values for each of the X31 CPUs:<br />
* Pentium-m 1600MHz : 34 26 18 12 8 5<br>Please note you computer may freeze once a month because of those values. If you find more stable ones, please indicate them.<br />
One you have your values, just run:<br />
# echo VALUES > /sys/devices/system/cpu/cpu0/cpufreq/phc_vids<br />
For example:<br />
# echo 34 26 18 12 8 5 > /sys/devices/system/cpu/cpu0/cpufreq/phc_vids<br />
You can add this command to your /etc/rc.local to make the undervolting permanent.<br />
<br />
===Modprobe.conf===<br />
Put those line in your /etc/modprobe.conf:<br />
options usbcore autosuspend=1<br />
options ipw2100 associate=0<br />
options snd_ac97_codec power_save=1<br />
options thinkpad-acpi experimental=1 fan_control=1<br />
The three first lines put some of your devices in power-saving mode, respectively the USB ports, the wireless card and the sound card.<br />
Note that you need the last line in order to control your fan speed (see above)<br />
<br />
===Powertop===<br />
To see additional sources of power drain, install powertop:<br />
# pacman -S powertop<br />
And run it while on battery power.<br />
<br />
===Hard drive dilemna===<br />
As set earlier, the hard drive is on a power-saving mode that can make it spin off and on often. It may reduce its lifetime. You can install the '''smartmontools''' package and issue this command:<br />
# smartctl -A /dev/sda | grep Load_Cycle_Count<br />
If the number is growing too fast, you might want to set off the powersaving mode by issuing: <br />
# hdparm -B 254 /dev/sda<br />
<br />
See the above item rc.local to modify it at boot time.<br />
<br />
==Other==<br />
===Fan-control===<br />
You can use a script from [http://www.thinkwiki.org/wiki/ThinkWiki ThinkWiki] to considerably lower your CPU temperature. Simply download it from [http://www.thinkwiki.org/index.php?title=Code/tp-fancontrol&action=raw&ctype=application/octet-stream here], rename it to tp-fancontrol, and run:<br />
# chmod 0755 tp-fancontrol<br />
# mv tp-fancontrol /usr/bin<br />
To run the script at each boot, add this line to your /etc/rc.local:<br />
tp-fancontrol -d<br />
Also, I suggest changing the first maximum temperature threshold (the CPU one) to 55. Just edit /usr/bin/tp-fancontrol, the file is self-explanatory.<br />
<br />
===Wireless and WPA===<br />
If you have the Cisco neta504 wifi card, it's a bit tricky to use the wpa encryption with it. <br />
Firstofall, remove and blacklist the airo and the airo_cs modules in your /etc/rc.conf<br />
remove the module airo from the kernel<br />
# rmmod airo<br />
# rmmod airo_cs<br />
then install ndiswrapper<br />
# pacman -S ndiswrapper<br />
<br />
download the neta504 driver for windows and unpack it (Be sure that you have unpacked the whole driver !) Then run :<br />
# ndiswrapper -i /path/to/your/dir/netA504.inf<br />
<br />
Save the ndiswrapper conf file :<br />
# ndiswrapper -m<br />
# ndiswrapper -ma<br />
# ndiswrapper -mi<br />
<br />
Now you can add to your kernel the module :<br />
# modprobe ndiswrapper<br />
<br />
and voilà !<br />
I've tried this with wicd and it works flawlessly !<br />
<br />
=== Audio keys ===<br />
To enable the audio keys interfacing with ALSA, add:<br />
event=ibm/hotkey HKEY 00000080 *<br />
action=/etc/acpi/soundkey.sh %e<br />
to /etc/acpi/events/soundkey, and:<br />
#!/bin/bash<br />
<br />
echo here > /tmp/fish<br />
echo $4 >> /tmp/fish<br />
case "$4" in<br />
00001015)<br />
amixer -c 0 set Master playback unmute<br />
amixer -c 0 set Master playback 3%+<br />
;;<br />
00001016)<br />
amixer -c 0 set Master playback unmute<br />
amixer -c 0 set Master playback 3%-<br />
;;<br />
00001017)<br />
amixer -c 0 set Master playback mute<br />
;;<br />
esac<br />
to /etc/acpi/soundkey.sh, and chown 755 it.<br />
<br />
You'll also need to add:<br />
<br />
echo enable,0xffffffff >/proc/acpi/ibm/hotkey<br />
<br />
to /etc/rc.local or somewhere similiar for the events to be recognised.</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Apache_OpenOffice&diff=95208Apache OpenOffice2010-02-06T07:09:30Z<p>Rttommy: </p>
<hr />
<div>[[Category:Office (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|OpenOffice}}<br />
{{i18n_entry|Italiano|OpenOffice_(Italiano)}}<br />
{{i18n_entry|Ελληνικά|OpenOffice (Ελληνικά)}}<br />
{{i18n_entry|Русский|OpenOffice (Русский)}}<br />
{{i18n_entry|简体中文|OpenOffice.org_(简体中文)}}<br />
{{i18n_entry|Português|OpenOffice_(Português)}}<br />
{{i18n_entry|Türkçe|OpenOffice_(Türkçe)}}<br />
{{i18n_links_end}}<br />
[http://www.openoffice.org/ OpenOffice] is a leading open-source office software suite for word processing, spreadsheets, presentations, graphics, databases and more.<br />
<br />
==OpenOffice in Arch Linux==<br />
Arch offers 4 trees of binary packages for OpenOffice with different package names:<br />
<br />
'''openoffice-base'''<br />
<br />
This will always be the last released stable version of OpenOffice. <br><br />
Current version: 3.1.1 <br><br />
Start it with "soffice" or from a desktop menu, if any <br><br />
<br />
'''openoffice-base-beta'''<br />
<br />
This package will be only present when a new release is not far away. It will be the alpha, beta, and release candidates packages for the next stable release. <br><br />
Current version: 3.1.1_ooo310_m17-1 (way to=3.1.1rcX) (versions branched from DEV300_m40 that will lead to next stable 3.1.x release) <br><br />
Start it with "soffice-beta" or from a desktop menu <br><br />
It is safe to install it together with the stable and devel version. <br><br />
Please test it carefully and report upstream bugs to OpenOffice and packaging bugs in our flyspray. <br><br />
See http://wiki.services.openoffice.org/wiki/OOoRelease311 for roadmap<br />
<br />
'''openoffice-base-devel'''<br />
<br />
This packages will be updated from time to time and is a playground for the packager and for testing latest features. Please test and file upstream issues at http://www.openoffice.org/issues/query.cgi <br><br />
Current version: 3.2_dev300_m55-1 / snapshot DEV300_m55 (snapshots past branching the 3.1 stable tree that will lead to 3.2 release and beyond) <br><br />
Start it with "soffice-dev" or from a desktop menu <br><br />
It is safe to install it together with the stable and beta version. <br><br />
See http://wiki.services.openoffice.org/wiki/OOoRelease32 for roadmap<br />
<br />
'''go-openoffice'''<br />
<br />
In addition, there is a package for go-openoffice also called ooo-build - the "Novell fork" in the extra repository, which includes enhancements and features found in versions of openoffice.org available in Ubuntu, OpenSuSE and other distributions. For users of Arch switching from other distributions go-openoffice may be more familiar to them. It will always be the latest stable release in extra based on the source of openoffice-base pkg. Future beta/devel versions will go to the testing repo. <br><br />
Right now go-openoffice cannot be installed along any other openoffice branch; consider it a replacement.<br />
<br />
{{Note|If you play with more than one openoffice-base version it is highly recommended to always backup your configuration directory, ~/.openoffice{2,3}.}}<br />
<br />
==Installation==<br />
* First, install a Java Runtime Environment (optional, highly recommended). See: [[Java]]<br />
<br />
* Also, make sure that fonts are installed, otherwise you will see only rectangles:<br />
# pacman -S ttf-dejavu artwiz-fonts ttf-ms-fonts (and additionally any other needed for your language)<br />
<br />
* Download the base for stable and/or beta and/or devel and/or go-oo:<br />
# pacman -S openoffice-base openoffice-base-beta openoffice-base-devel go-openoffice<br />
<br />
* Download a language package. The main package contains only en_US files, yet the repository offer every shipped upstream langpack, except for go-openoffice.<br />
# pacman -S openoffice-en-GB openoffice-de ....<br />
<br />
===Extension management and spell checking for OpenOffice 3.x===<br />
The Arch package is now shipped with some dictionaries. Check Extension manager if your language is already there simply by loading up any OO program (Writer for example) and access the Extension Manager from the Tools menu. From there enter the following location to install a spell check dictionary:<br />
<br />
/usr/lib/openoffice/share/extension/install/<br />
<br />
{{Note | If you installed go-openoffice, the path will be /usr/lib/go-openoffice/share/extension/install/ instead. }}<br />
<br />
Alternatively, there are several ways to accomplish this:<br />
<br />
* 1) Use the Extension manager from OOo menu for download and installation - installs only for the user into his ~/.openoffice.org/3/user/uno_packages/cache<br />
* 2) Download the extension and install it using "unopkg add extension" for the user or<br />
* 3) Download the extension and install it using "unopkg add --shared extension" for every user on the system (requires root permission)<br />
<br />
===Set OOo environment variable===<br />
OpenOffice supports to use several toolkits for drawing and integrates into different desktop environments in a clean way. To choose by hand, you need to set the OOO_FORCE_DESKTOP environment variable.<br />
<br />
To run OpenOffice.org in GTK2 mode(this is default and already preset), you can issue (using bash):<br />
# OOO_FORCE_DESKTOP=gnome soffice<br />
To run OpenOffice.org in QT/KDE3 mode, you can issue (using bash):<br />
# OOO_FORCE_DESKTOP=kde soffice<br />
To run OpenOffice.org in QT4/KDE4 mode, you can issue (using bash):<br />
# OOO_FORCE_DESKTOP=kde4 soffice<br />
<br />
{{Note | As KDE look was removed in Openoffice3 it is highly recommended to use the GTK mode for all users. KDE4 integration is in experimental state in go-openoffice and in openoffice-base-devel (starting from m56)}}<br />
<br />
====Configure OOo environment globally====<br />
To configure the look for anytime OpenOffice gets started, you can export the '''<tt>OOO_FORCE_DESKTOP</tt>''' variable in /etc/profile.d/openoffice.sh, or in /usr/bin/soffice, with the value '''<tt>gnome</tt>''', '''<tt>kde</tt>''', or '''<tt>kde4</tt>'''.<br />
<br />
====Environment variable scripts====<br />
If for whatever reason you do not want to configure the look globaly, as a non-GNOME/KDE user you may run into problems when trying to add the environment variable to the command in a *box menu, as such menus do not seem to like environment variables.<br />
<br />
This script will run openoffice using the GTK look while still accepting command line options like -writer.<br />
#!/bin/sh<br />
<br />
#### openoffice-gtk - A script to start openoffice with the GNOME/GTK environment<br />
<br />
OOO_FORCE_DESKTOP=gnome /usr/bin/soffice "$@"<br />
<br />
Just use this script as a command (e.g, /usr/bin/openoffice-gtk) for your menu or whatever other sort of launcher you use.<br />
<br />
{{Note | If you open a file in a filemanager, for example Thunar, the default look will be used, as the file association will not use your personal script. }}<br />
<br />
===KDE4 look and feel for OpenOffice===<br />
OOO_FORCE_DESKTOP=gnome never did the trick for me. A good workaround is to set (as root):<br />
export SAL_GTK_USE_PIXMAPPAINT=1<br />
into /etc/profile.d/openoffice.sh. In KDE4 systemsettings, make sure "use my KDE style in GTK applications" is selected in Appearance > GTK styles and fonts (you must install gtk-qt-engine first).<br />
<br />
====Alternative configuration====<br />
You may wish to set the Xorg server dots-per-inch in the [[KDM]] configuration.<br />
<br />
Do not select "use my KDE style in GTK applications". Instead choose a native syle and font for GTK2 applications.<br />
# pacman -S gtk-chtheme<br />
# pacman -S gtk-engines<br />
<br />
Use gtk-chtheme to select a style (in general different from KDE) and a font (may be the same as your KDE general system font). There are also other GTK engine packages available.<br />
<br />
There are two relevant parts of the OOo options dialog, View and Fonts:<br />
*View<br />
**set scale to 100%<br />
**set use system font OFF (otherwise replacement table will not be used)<br />
**set antialiasing OFF<br />
<br />
*Fonts<br />
**select "Use replacement table"<br />
**replace "Andale Sans UI" (you ''must'' type this in -- it is not in the drop down list) with another font (your KDE system font or another if this looks bad)<br />
**Press the tick symbol to update the list<br />
**Select "always" and "screen only"<br />
**Press OK<br />
<br />
When choosing fonts for OpenOffice note that the poor font rendering engine included in the package may not render a particular font in the same way as other apps on the desktop. Use the {{Filename|kmag}} magnifying glass to examine shape of each letter.<br />
<br />
==Running OpenOffice==<br />
<br />
If you want to run a specific module of OpenOffice.org (instead of the soffice default Startcenter), for example the word processor (Write), spreadsheet application (Calc) or presentation program (Impress), check for the following script front-ends:<br />
<br />
Writer<br />
/usr/bin/soffice -writer<br />
<br />
Calc<br />
/usr/bin/soffice -calc<br />
<br />
Impress<br />
/usr/bin/soffice -impress<br />
<br />
Draw<br />
/usr/bin/soffice -draw<br />
<br />
Math (Formula Editor)<br />
/usr/bin/soffice -math<br />
<br />
Base (Database frontend)<br />
/usr/bin/soffice -base<br />
<br />
Printer Administration (Recommended to run as root)<br />
/usr/bin/spadmin<br />
<br />
==Speed up OpenOffice==<br />
Some settings may improve OpenOffice's loading time and responsiveness. However, some also increase RAM usage, so use them carefully. They can all be accessed under ''Tools > Options''.<br />
*Under ''Memory'':<br />
**Reduce the number of Undo steps to a figure lower than 100, to something like 20 or 30 steps.<br />
**Under Graphics cache, set Use for OpenOffice.org to 128 MB (up from the original 20MB).<br />
**Set Memory per object to 20MB (up from the default 5MB).<br />
**If you use OpenOffice often, check OpenOffice.org Quickstarter.<br />
*Under ''Java'', uncheck Use a Java runtime environment.<br />
==Trouble-shooting==<br />
=== Font substitution ===<br />
These settings can be changed in the OpenOffice.org options. From the drop-down menu, select ''Tools > Options > OpenOffice.org > Fonts''. Check the box that says ''Apply Replacement Table''. Type {{Codeline|Andale Sans UI}} in the font box and choose your desired font for the ''Replace with'' option. When done, click the ''checkmark''. Then choose the ''Always'' and ''Screen only'' options in the box below. Apply the changes, and your menu fonts should look great.<br />
<br />
=== Anti-aliasing ===<br />
Execute<br />
$ echo "Xft.lcdfilter: lcddefault" | xrdb -merge<br />
<br />
To make the change persistent, add "{{Codeline|Xft.lcdfilter: lcddefault}}" to your {{Filename|~/.Xresources}} file. [https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/271283/comments/19].<br />
<br />
If this doesn't work you can also try adding "{{Codeline|Xft.lcdfilter: lcddefault}}" to your {{Filename|~/.Xdefaults}}. If you do not have this file, you will have to create it.<br />
<br />
=== TrueType font detection ===<br />
See [[Font Configuration#Programs can no longer access TrueType fonts]]. To add fonts to those already available in OpenOffice, run {{Codeline|spadmin}}.<br />
<br />
===Qt looks with KDE >4===<br />
OpenOffice has transitioned to Qt 4, and as such the look of the applications can not be set with Qt 3 tools.<br />
<br />
===French dictionary===<br />
As of openoffice 3.0.0-2 the french dictionary is buggy due to a character encoding problem. To solve this problem, first execute the following commands (you will need '''zip''' and '''unzip''' packages):<br />
$ cp /usr/lib/openoffice/share/extension/install/dict-fr.oxt dict-fr.oxt<br />
$ unzip dict-fr.oxt -d dict-fr<br />
$ cd dict-fr<br />
$ iconv -f ISO-8859-15 -t UTF-8 dictionaries.xcu > dictionaries.xcu.utf<br />
$ mv dictionaries.xcu.utf dictionaries.xcu<br />
$ zip ../dict-fr.oxt *<br />
$ cd ../<br />
$ rm -r dict-fr<br />
then go in the openoffice extension manager (Tools menu) and install the dictionary from the new dict-fr.oxt file.<br />
<br />
===Dark GTK themes and gtk-qt-engine===<br />
For a quick fix, see [http://aur.archlinux.org/packages.php?ID=22383 openoffice-dark-gtk-fix] or if you have go-openoffice see [http://aur.archlinux.org/packages.php?ID=28879 go-openoffice-dark-gtk-fix] on the AUR. This also sets 'OOO_FORCE_DESKTOP=gnome'.</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Apache_OpenOffice&diff=95207Apache OpenOffice2010-02-06T07:08:06Z<p>Rttommy: Replaced i18n template</p>
<hr />
<div>[[Category:Office (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Template:i18n}}<br />
[http://www.openoffice.org/ OpenOffice] is a leading open-source office software suite for word processing, spreadsheets, presentations, graphics, databases and more.<br />
<br />
==OpenOffice in Arch Linux==<br />
Arch offers 4 trees of binary packages for OpenOffice with different package names:<br />
<br />
'''openoffice-base'''<br />
<br />
This will always be the last released stable version of OpenOffice. <br><br />
Current version: 3.1.1 <br><br />
Start it with "soffice" or from a desktop menu, if any <br><br />
<br />
'''openoffice-base-beta'''<br />
<br />
This package will be only present when a new release is not far away. It will be the alpha, beta, and release candidates packages for the next stable release. <br><br />
Current version: 3.1.1_ooo310_m17-1 (way to=3.1.1rcX) (versions branched from DEV300_m40 that will lead to next stable 3.1.x release) <br><br />
Start it with "soffice-beta" or from a desktop menu <br><br />
It is safe to install it together with the stable and devel version. <br><br />
Please test it carefully and report upstream bugs to OpenOffice and packaging bugs in our flyspray. <br><br />
See http://wiki.services.openoffice.org/wiki/OOoRelease311 for roadmap<br />
<br />
'''openoffice-base-devel'''<br />
<br />
This packages will be updated from time to time and is a playground for the packager and for testing latest features. Please test and file upstream issues at http://www.openoffice.org/issues/query.cgi <br><br />
Current version: 3.2_dev300_m55-1 / snapshot DEV300_m55 (snapshots past branching the 3.1 stable tree that will lead to 3.2 release and beyond) <br><br />
Start it with "soffice-dev" or from a desktop menu <br><br />
It is safe to install it together with the stable and beta version. <br><br />
See http://wiki.services.openoffice.org/wiki/OOoRelease32 for roadmap<br />
<br />
'''go-openoffice'''<br />
<br />
In addition, there is a package for go-openoffice also called ooo-build - the "Novell fork" in the extra repository, which includes enhancements and features found in versions of openoffice.org available in Ubuntu, OpenSuSE and other distributions. For users of Arch switching from other distributions go-openoffice may be more familiar to them. It will always be the latest stable release in extra based on the source of openoffice-base pkg. Future beta/devel versions will go to the testing repo. <br><br />
Right now go-openoffice cannot be installed along any other openoffice branch; consider it a replacement.<br />
<br />
{{Note|If you play with more than one openoffice-base version it is highly recommended to always backup your configuration directory, ~/.openoffice{2,3}.}}<br />
<br />
==Installation==<br />
* First, install a Java Runtime Environment (optional, highly recommended). See: [[Java]]<br />
<br />
* Also, make sure that fonts are installed, otherwise you will see only rectangles:<br />
# pacman -S ttf-dejavu artwiz-fonts ttf-ms-fonts (and additionally any other needed for your language)<br />
<br />
* Download the base for stable and/or beta and/or devel and/or go-oo:<br />
# pacman -S openoffice-base openoffice-base-beta openoffice-base-devel go-openoffice<br />
<br />
* Download a language package. The main package contains only en_US files, yet the repository offer every shipped upstream langpack, except for go-openoffice.<br />
# pacman -S openoffice-en-GB openoffice-de ....<br />
<br />
===Extension management and spell checking for OpenOffice 3.x===<br />
The Arch package is now shipped with some dictionaries. Check Extension manager if your language is already there simply by loading up any OO program (Writer for example) and access the Extension Manager from the Tools menu. From there enter the following location to install a spell check dictionary:<br />
<br />
/usr/lib/openoffice/share/extension/install/<br />
<br />
{{Note | If you installed go-openoffice, the path will be /usr/lib/go-openoffice/share/extension/install/ instead. }}<br />
<br />
Alternatively, there are several ways to accomplish this:<br />
<br />
* 1) Use the Extension manager from OOo menu for download and installation - installs only for the user into his ~/.openoffice.org/3/user/uno_packages/cache<br />
* 2) Download the extension and install it using "unopkg add extension" for the user or<br />
* 3) Download the extension and install it using "unopkg add --shared extension" for every user on the system (requires root permission)<br />
<br />
===Set OOo environment variable===<br />
OpenOffice supports to use several toolkits for drawing and integrates into different desktop environments in a clean way. To choose by hand, you need to set the OOO_FORCE_DESKTOP environment variable.<br />
<br />
To run OpenOffice.org in GTK2 mode(this is default and already preset), you can issue (using bash):<br />
# OOO_FORCE_DESKTOP=gnome soffice<br />
To run OpenOffice.org in QT/KDE3 mode, you can issue (using bash):<br />
# OOO_FORCE_DESKTOP=kde soffice<br />
To run OpenOffice.org in QT4/KDE4 mode, you can issue (using bash):<br />
# OOO_FORCE_DESKTOP=kde4 soffice<br />
<br />
{{Note | As KDE look was removed in Openoffice3 it is highly recommended to use the GTK mode for all users. KDE4 integration is in experimental state in go-openoffice and in openoffice-base-devel (starting from m56)}}<br />
<br />
====Configure OOo environment globally====<br />
To configure the look for anytime OpenOffice gets started, you can export the '''<tt>OOO_FORCE_DESKTOP</tt>''' variable in /etc/profile.d/openoffice.sh, or in /usr/bin/soffice, with the value '''<tt>gnome</tt>''', '''<tt>kde</tt>''', or '''<tt>kde4</tt>'''.<br />
<br />
====Environment variable scripts====<br />
If for whatever reason you do not want to configure the look globaly, as a non-GNOME/KDE user you may run into problems when trying to add the environment variable to the command in a *box menu, as such menus do not seem to like environment variables.<br />
<br />
This script will run openoffice using the GTK look while still accepting command line options like -writer.<br />
#!/bin/sh<br />
<br />
#### openoffice-gtk - A script to start openoffice with the GNOME/GTK environment<br />
<br />
OOO_FORCE_DESKTOP=gnome /usr/bin/soffice "$@"<br />
<br />
Just use this script as a command (e.g, /usr/bin/openoffice-gtk) for your menu or whatever other sort of launcher you use.<br />
<br />
{{Note | If you open a file in a filemanager, for example Thunar, the default look will be used, as the file association will not use your personal script. }}<br />
<br />
===KDE4 look and feel for OpenOffice===<br />
OOO_FORCE_DESKTOP=gnome never did the trick for me. A good workaround is to set (as root):<br />
export SAL_GTK_USE_PIXMAPPAINT=1<br />
into /etc/profile.d/openoffice.sh. In KDE4 systemsettings, make sure "use my KDE style in GTK applications" is selected in Appearance > GTK styles and fonts (you must install gtk-qt-engine first).<br />
<br />
====Alternative configuration====<br />
You may wish to set the Xorg server dots-per-inch in the [[KDM]] configuration.<br />
<br />
Do not select "use my KDE style in GTK applications". Instead choose a native syle and font for GTK2 applications.<br />
# pacman -S gtk-chtheme<br />
# pacman -S gtk-engines<br />
<br />
Use gtk-chtheme to select a style (in general different from KDE) and a font (may be the same as your KDE general system font). There are also other GTK engine packages available.<br />
<br />
There are two relevant parts of the OOo options dialog, View and Fonts:<br />
*View<br />
**set scale to 100%<br />
**set use system font OFF (otherwise replacement table will not be used)<br />
**set antialiasing OFF<br />
<br />
*Fonts<br />
**select "Use replacement table"<br />
**replace "Andale Sans UI" (you ''must'' type this in -- it is not in the drop down list) with another font (your KDE system font or another if this looks bad)<br />
**Press the tick symbol to update the list<br />
**Select "always" and "screen only"<br />
**Press OK<br />
<br />
When choosing fonts for OpenOffice note that the poor font rendering engine included in the package may not render a particular font in the same way as other apps on the desktop. Use the {{Filename|kmag}} magnifying glass to examine shape of each letter.<br />
<br />
==Running OpenOffice==<br />
<br />
If you want to run a specific module of OpenOffice.org (instead of the soffice default Startcenter), for example the word processor (Write), spreadsheet application (Calc) or presentation program (Impress), check for the following script front-ends:<br />
<br />
Writer<br />
/usr/bin/soffice -writer<br />
<br />
Calc<br />
/usr/bin/soffice -calc<br />
<br />
Impress<br />
/usr/bin/soffice -impress<br />
<br />
Draw<br />
/usr/bin/soffice -draw<br />
<br />
Math (Formula Editor)<br />
/usr/bin/soffice -math<br />
<br />
Base (Database frontend)<br />
/usr/bin/soffice -base<br />
<br />
Printer Administration (Recommended to run as root)<br />
/usr/bin/spadmin<br />
<br />
==Speed up OpenOffice==<br />
Some settings may improve OpenOffice's loading time and responsiveness. However, some also increase RAM usage, so use them carefully. They can all be accessed under ''Tools > Options''.<br />
*Under ''Memory'':<br />
**Reduce the number of Undo steps to a figure lower than 100, to something like 20 or 30 steps.<br />
**Under Graphics cache, set Use for OpenOffice.org to 128 MB (up from the original 20MB).<br />
**Set Memory per object to 20MB (up from the default 5MB).<br />
**If you use OpenOffice often, check OpenOffice.org Quickstarter.<br />
*Under ''Java'', uncheck Use a Java runtime environment.<br />
==Trouble-shooting==<br />
=== Font substitution ===<br />
These settings can be changed in the OpenOffice.org options. From the drop-down menu, select ''Tools > Options > OpenOffice.org > Fonts''. Check the box that says ''Apply Replacement Table''. Type {{Codeline|Andale Sans UI}} in the font box and choose your desired font for the ''Replace with'' option. When done, click the ''checkmark''. Then choose the ''Always'' and ''Screen only'' options in the box below. Apply the changes, and your menu fonts should look great.<br />
<br />
=== Anti-aliasing ===<br />
Execute<br />
$ echo "Xft.lcdfilter: lcddefault" | xrdb -merge<br />
<br />
To make the change persistent, add "{{Codeline|Xft.lcdfilter: lcddefault}}" to your {{Filename|~/.Xresources}} file. [https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/271283/comments/19].<br />
<br />
If this doesn't work you can also try adding "{{Codeline|Xft.lcdfilter: lcddefault}}" to your {{Filename|~/.Xdefaults}}. If you do not have this file, you will have to create it.<br />
<br />
=== TrueType font detection ===<br />
See [[Font Configuration#Programs can no longer access TrueType fonts]]. To add fonts to those already available in OpenOffice, run {{Codeline|spadmin}}.<br />
<br />
===Qt looks with KDE >4===<br />
OpenOffice has transitioned to Qt 4, and as such the look of the applications can not be set with Qt 3 tools.<br />
<br />
===French dictionary===<br />
As of openoffice 3.0.0-2 the french dictionary is buggy due to a character encoding problem. To solve this problem, first execute the following commands (you will need '''zip''' and '''unzip''' packages):<br />
$ cp /usr/lib/openoffice/share/extension/install/dict-fr.oxt dict-fr.oxt<br />
$ unzip dict-fr.oxt -d dict-fr<br />
$ cd dict-fr<br />
$ iconv -f ISO-8859-15 -t UTF-8 dictionaries.xcu > dictionaries.xcu.utf<br />
$ mv dictionaries.xcu.utf dictionaries.xcu<br />
$ zip ../dict-fr.oxt *<br />
$ cd ../<br />
$ rm -r dict-fr<br />
then go in the openoffice extension manager (Tools menu) and install the dictionary from the new dict-fr.oxt file.<br />
<br />
===Dark GTK themes and gtk-qt-engine===<br />
For a quick fix, see [http://aur.archlinux.org/packages.php?ID=22383 openoffice-dark-gtk-fix] or if you have go-openoffice see [http://aur.archlinux.org/packages.php?ID=28879 go-openoffice-dark-gtk-fix] on the AUR. This also sets 'OOO_FORCE_DESKTOP=gnome'.</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=95206Improving performance2010-02-06T07:06:28Z<p>Rttommy: /* Kernel boot options */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=OpenSSH&diff=95205OpenSSH2010-02-06T07:04:46Z<p>Rttommy: Replaced i18n template</p>
<hr />
<div>[[Category:Daemons_and_system_services (English)]]<br />
{{i18n|Template:i18n}}<br />
<br />
= Introduction =<br />
Secure Shell or SSH is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary.<br />
<br />
SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding arbitrary TCP ports and X11 connections; it can transfer files using the associated SFTP or SCP protocols.<br />
<br />
An SSH server, by default, listens on the standard TCP port 22. An ssh client program is typically used for establishing connections to an sshd daemon accepting remote connections. Both are commonly present on most modern operating systems, including Mac OS X, Linux, Solaris and OpenVMS. Proprietary, freeware and open source versions of various levels of complexity and completeness exist.<br />
<br />
= OpenSSH =<br />
<br />
OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the ssh protocol. It was created as an open source alternative to the proprietary Secure Shell software suite offered by SSH Communications Security. OpenSSH is developed as part of the OpenBSD project, which is led by Theo de Raadt.<br />
<br />
OpenSSH is occasionally confused with the similarly-named OpenSSL; however, the projects have different purposes and are developed by different teams, the similar name is drawn only from similar goals.<br />
<br />
== Installing OpenSSH ==<br />
# pacman -S openssh<br />
<br />
== Configuring SSH ==<br />
===Client===<br />
The SSH client configuration file can be found and edited in {{Filename|/etc/ssh/ssh_config}}.<br />
<br />
An example configuration: <br />
<br />
{{File|name=/etc/ssh/ssh_config|content=<br />
<br />
# $OpenBSD: ssh_config,v 1.25 2009/02/17 01:28:32 djm Exp $<br />
<br />
# This is the ssh client system-wide configuration file. See<br />
# ssh_config(5) for more information. This file provides defaults for<br />
# users, and the values can be changed in per-user configuration files<br />
# or on the command line.<br />
<br />
# Configuration data is parsed as follows:<br />
# 1. command line options<br />
# 2. user-specific file<br />
# 3. system-wide file<br />
# Any configuration value is only changed the first time it is set.<br />
# Thus, host-specific definitions should be at the beginning of the<br />
# configuration file, and defaults at the end.<br />
<br />
# Site-wide defaults for some commonly used options. For a comprehensive<br />
# list of available options, their meanings and defaults, please see the<br />
# ssh_config(5) man page.<br />
<br />
Host *<br />
# ForwardAgent no<br />
# ForwardX11 no<br />
# RhostsRSAAuthentication no<br />
# RSAAuthentication yes<br />
# PasswordAuthentication yes<br />
# HostbasedAuthentication no<br />
# GSSAPIAuthentication no<br />
# GSSAPIDelegateCredentials no<br />
# BatchMode no<br />
# CheckHostIP yes<br />
# AddressFamily any<br />
# ConnectTimeout 0<br />
# StrictHostKeyChecking ask<br />
# IdentityFile ~/.ssh/identity<br />
# IdentityFile ~/.ssh/id_rsa<br />
# IdentityFile ~/.ssh/id_dsa<br />
# Port 22<br />
# Protocol 2,1<br />
# Cipher 3des<br />
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc<br />
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160<br />
# EscapeChar ~<br />
# Tunnel no<br />
# TunnelDevice any:any<br />
# PermitLocalCommand no<br />
# VisualHostKey no<br />
HashKnownHosts yes<br />
StrictHostKeyChecking ask}}<br />
<br />
It is recommended to change the Protocol line into this:<br />
Protocol 2<br />
<br />
That means that only Protocol 2 will be used, since Protocol 1 is considered somewhat insecure.<br />
<br />
===Daemon===<br />
The SSH daemon configuration file can be found and edited in {{Filename|/etc/ssh/ssh'''d'''_config}}.<br />
<br />
An example configuration: <br />
<br />
{{File|name=/etc/ssh/sshd_config|content=<br />
<br />
# $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $<br />
<br />
# This is the sshd server system-wide configuration file. See<br />
# sshd_config(5) for more information.<br />
<br />
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin<br />
<br />
# The strategy used for options in the default sshd_config shipped with<br />
# OpenSSH is to specify options with their default value where<br />
# possible, but leave them commented. Uncommented options change a<br />
# default value.<br />
<br />
#Port 22<br />
#Protocol 2,1<br />
ListenAddress 0.0.0.0<br />
#ListenAddress ::<br />
<br />
# HostKey for protocol version 1<br />
#HostKey /etc/ssh/ssh''host''key<br />
# HostKeys for protocol version 2<br />
#HostKey /etc/ssh/ssh''host''rsa_key<br />
#HostKey /etc/ssh/ssh''host''dsa_key<br />
<br />
# Lifetime and size of ephemeral version 1 server key<br />
#KeyRegenerationInterval 1h<br />
#ServerKeyBits 768<br />
<br />
# Logging<br />
#obsoletes ~QuietMode and ~FascistLogging<br />
#SyslogFacility AUTH<br />
#LogLevel INFO<br />
<br />
# Authentication:<br />
<br />
#LoginGraceTime 2m<br />
#PermitRootLogin yes<br />
#StrictModes yes<br />
#MaxAuthTries 6<br />
<br />
#RSAAuthentication yes<br />
#PubkeyAuthentication yes<br />
#AuthorizedKeysFile .ssh/authorized_keys<br />
<br />
# For this to work you will also need host keys in /etc/ssh/ssh''known''hosts<br />
#RhostsRSAAuthentication no<br />
# similar for protocol version 2<br />
#HostbasedAuthentication no<br />
# Change to yes if you don't trust ~/.ssh/known_hosts for<br />
# RhostsRSAAuthentication and HostbasedAuthentication<br />
#IgnoreUserKnownHosts no<br />
# Don't read the user's ~/.rhosts and ~/.shosts files<br />
#IgnoreRhosts yes<br />
<br />
# To disable tunneled clear text passwords, change to no here!<br />
#PasswordAuthentication yes<br />
#PermitEmptyPasswords no<br />
<br />
# Change to no to disable s/key passwords<br />
#ChallengeResponseAuthentication yes<br />
<br />
# Kerberos options<br />
#KerberosAuthentication no<br />
#KerberosOrLocalPasswd yes<br />
#KerberosTicketCleanup yes<br />
#KerberosGetAFSToken no<br />
<br />
# GSSAPI options<br />
#GSSAPIAuthentication no<br />
#GSSAPICleanupCredentials yes<br />
<br />
# Set this to 'yes' to enable PAM authentication, account processing,<br />
# and session processing. If this is enabled, PAM authentication will<br />
# be allowed through the ~ChallengeResponseAuthentication mechanism.<br />
# Depending on your PAM configuration, this may bypass the setting of<br />
# PasswordAuthentication, ~PermitEmptyPasswords, and<br />
# "PermitRootLogin without-password". If you just want the PAM account and<br />
# session checks to run without PAM authentication, then enable this but set<br />
# ChallengeResponseAuthentication=no<br />
#UsePAM no<br />
<br />
#AllowTcpForwarding yes<br />
#GatewayPorts no<br />
#X11Forwarding no<br />
#X11DisplayOffset 10<br />
#X11UseLocalhost yes<br />
#PrintMotd yes<br />
#PrintLastLog yes<br />
#TCPKeepAlive yes<br />
#UseLogin no<br />
#UsePrivilegeSeparation yes<br />
#PermitUserEnvironment no<br />
#Compression yes<br />
#ClientAliveInterval 0<br />
#ClientAliveCountMax 3<br />
#UseDNS yes<br />
#PidFile /var/run/sshd.pid<br />
#MaxStartups 10<br />
<br />
# no default banner path<br />
#Banner /some/path<br />
<br />
# override default of no subsystems<br />
Subsystem sftp /usr/lib/ssh/sftp-server}}<br />
<br />
<br />
To allow access only for some users add this line:<br />
AllowUsers user1 user2<br />
<br />
You might want to change some lines so that they look as following:<br />
<pre><br />
Protocol 2<br />
.<br />
.<br />
.<br />
LoginGraceTime 120<br />
.<br />
.<br />
.<br />
PermitRootLogin no # (put yes here if you want root login)<br />
</pre><br />
<br />
You could also uncomment the BANNER option and edit {{Filename|/etc/issue}} for a nice welcome message.<br />
<br />
{{Tip| You may want to change the default port from 22 to any higher port (see [http://en.wikipedia.org/wiki/Security_through_obscurity security through obscurity]).}} <br />
<br />
Even though the port ssh is running on could be detected by using a port-scanner like nmap, changing it will reduce the number of log entries caused by automated authentication attempts.<br />
===Allowing others in===<br />
{{Box Note | You have to adjust this file to remotely connect to your machine since the file is empty by default}}<br />
<br />
To let other people ssh to your machine you need to adjust {{Filename|/etc/hosts.allow}}, add the following:<br />
<br />
<pre><br />
# let everyone connect to you<br />
sshd: ALL<br />
<br />
# OR you can restrict it to a certain ip<br />
sshd: 192.168.0.1<br />
<br />
# OR restrict for an IP range<br />
sshd: 10.0.0.0/255.255.255.0<br />
<br />
# OR restrict for an IP match<br />
sshd: 192.168.1.<br />
</pre><br />
<br />
Now you should check your {{Filename|/etc/hosts.deny}} for the following line and make sure it looks like this:<br />
ALL: ALL: DENY<br />
<br />
That's it. You can SSH out and others should be able to SSH in :).<br />
<br />
To start using the new configuration, restart the daemon (as root):<br />
# /etc/rc.d/sshd restart<br />
<br />
== Managing SSHD Daemon ==<br />
Just add sshd to the "DAEMONS" section of your {{Filename|/etc/[[rc.conf]]}}:<br />
DAEMONS=(... ... '''sshd''' ... ...)<br />
<br />
To start/restart/stop the daemon, use the following:<br />
# /etc/rc.d/sshd {start|stop|restart}<br />
<br />
==Connecting to the server==<br />
To connect to a server, run:<br />
$ ssh -p port user@server-address<br />
<br />
= Tips and Tricks =<br />
<br />
== Encrypted Socks Tunnel ==<br />
This is highly useful for laptop users connected to various unsafe wireless connections. The only thing you need is an SSH server running at a somewhat secure location, like your home or at work. It might be useful to use a dynamic DNS service like [http://www.dyndns.org/ DynDNS] so you don't have to remember your IP-address.<br />
<br />
=== Step 1: Start the Connection ===<br />
You only have to execute this single command in your favorite terminal to start the connection:<br />
$ ssh -ND 4711 user@host<br />
where {{Codeline|"user"}} is your username at the SSH server running at the {{Codeline|"host"}}. It will ask for your password, and then you're connected! The {{Codeline|"N"}} flag disables the interactive prompt, and the {{Codeline|"D"}} flag specifies the local port on wich to listen on (you can choose any port number if you want).<br />
<br />
One way to make this easier is to put an alias line in your {{Filename|~/.bashrc}} file as following:<br />
alias sshtunnel="ssh -ND 4711 -v user@host"<br />
It's nice to add the verbose {{Codeline|"-v"}} flag, because then you can verify that it's actually connected from that output. Now you just have to execute the {{Codeline|"sshtunnel"}} command :)<br />
<br />
=== Step 2: Configure your Browser (or other programs) ===<br />
<br />
The above step is completely useless if you don't configure your web browser (or other programs) to use this newly created socks tunnel. <br />
<br />
* For Firefox: ''Edit &rarr; Preferences &rarr; Advanced &rarr; Network &rarr; Connection &rarr; Setting'':<br />
: Check the ''"Manual proxy configuration"'' radio button, and enter "localhost" in the ''"SOCKS host"'' text field, and then enter your port number in the next text field (I used 4711 above).<br />
<br />
: Make sure you select SOCKS4 as the protocol to use. This procedure will not work for SOCKS5.<br />
<br />
Enjoy your secure tunnel!<br />
<br />
== X11 Forwarding ==<br />
<br />
To run graphical programs through a SSH connection you can enable X11 forwarding. An option needs to be set in the configuration files on the server and client.<br />
<br />
Install xorg-xauth on the server:<br />
# pacman -S xorg-xauth<br />
<br />
* Enable the '''AllowTcpForwarding''' option in {{Filename|sshd_config}} on the '''server'''.<br />
* Enable the '''X11Forwarding''' option in {{Filename|sshd_config}} on the '''server'''.<br />
* Set the '''X11DisplayOffset''' option in {{Filename|sshd_config}} on the '''server''' to 10.<br />
* Enable the '''X11UseLocalhost''' option in {{Filename|sshd_config}} on the '''server'''.<br />
<br />
<br />
* Enable the '''ForwardX11''' option in {{Filename|ssh_config}} on the '''client'''.<br />
<br />
To use the forwarding, log on to your server through ssh:<br />
# ssh -X -p port user@server-address<br />
If you receive errors trying to run graphical applications try trusted forwarding instead:<br />
# ssh -Y -p port user@server-address<br />
You can now start any X program on the remote server, the output will be forwarded to your local session:<br />
# xclock<br />
<br />
== Speed up SSH ==<br />
Changing the ciphers used by SSH to less cpu-demanding ones can improve speed. In this aspect, the best choices are arcfour and blowfish-cbc. To use them, run SSH with the {{Codeline|"c"}} flag, like this:<br />
# ssh -c arcfour,blowfish-cbc user@server-address<br />
To use them permanently, add this line under the proper host in {{Filename|/etc/ssh/ssh_config}}:<br />
Ciphers arcfour,blowfish-cbc<br />
Another option to improve speed is to enable compression with the {{Codeline|"C"}} flag. A permanent solution is to add this line under the proper host in {{Filename|/etc/ssh/ssh_config}}:<br />
Compression yes<br />
Login time can be shorten by using the {{Codeline|"4"}} flag, which bypasses IPv6 lookup. This can be made permanent by adding this line under the proper host in {{Filename|/etc/ssh/ssh_config}}:<br />
AddressFamily inet<br />
Another way of making these changes permanent is to create an alias in {{Filename|~/.bashrc}}:<br />
alias ssh='ssh -C4c arcfour,blowfish-cbc'<br />
Finally, you can make all sessions to the same host use a single connection, which will greatly speed up subsecent logins, by adding those line under the proper host in {{Filename|/etc/ssh/ssh_config}}:<br />
ControlMaster auto<br />
ControlPath ~/.ssh/socket-%r@%h:%p<br />
<br />
=== Trouble Shooting ===<br />
<br />
make sure your DISPLAY string is resolveable on the remote end:<br />
<br />
ssh -X user@server-address<br />
server$ echo $DISPLAY<br />
localhost:10.0<br />
server$ telnet localhost 6010<br />
localhost/6010: lookup failure: Temporary failure in name resolution <br />
<br />
can be fixed by adding localhost to {{Filename|/etc/hosts}}.<br />
<br />
== Mounting a Remote Filesystem with SSHFS ==<br />
<br />
Install sshfs<br />
# pacman -S sshfs<br />
<br />
Load the Fuse module<br />
# modprobe fuse<br />
Add fuse to the ''modules'' array in {{Filename|/etc/rc.conf}} to load it on each system boot.<br />
<br />
Mount the remote folder using sshfs<br />
# mkdir ~/remote_folder<br />
# sshfs USER@remote_server:/tmp ~/remote_folder<br />
<br />
The command above will cause the folder /tmp on the remote server to be mounted as ~/remote_folder on the local machine. Copying any file to this folder will result in transparent copying over the network using SFTP. Same concerns direct file editing, creating or removing.<br />
<br />
When we’re done working with the remote filesystem, we can unmount the remote folder by issuing:<br />
# fusermount -u ~/remote_folder<br />
<br />
If we work on this folder on a daily basis, it is wise to add it to the {{Filename|/etc/fstab}} table. This way is can be automatically mounted upon system boot or mounted manually (if {{Codeline|noauto}} option is chosen) without the need to specify the remote location each time. Here is a sample entry in the table:<br />
sshfs#USER@remote_server:/tmp /full/path/to/directory fuse defaults,auto 0 0<br />
<br />
=== Keep Alive ===<br />
<br />
Your ssh session will automatically log out if it is idle. To keep the connection active (alive) add this to {{Filename|~/.ssh/config}} or to {{Filename|/etc/ssh/ssh_config}} on the client.<br />
<br />
ServerAliveInterval 5<br />
<br />
This will send a "keep alive" signal to the server every 5 seconds. You can usually increase this interval, and I use 120.<br />
<br />
= Links & References =<br />
*[http://www.soloport.com/iptables.html A Cure for the Common SSH Login Attack]<br />
*[[Using SSH Keys]]<br />
*[http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks]</div>Rttommyhttps://wiki.archlinux.org/index.php?title=OpenSSH&diff=95204OpenSSH2010-02-06T07:03:51Z<p>Rttommy: /* Keep Alive */</p>
<hr />
<div>[[Category:Daemons_and_system_services (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|SSH}}<br />
{{i18n_entry|Italiano|SSH_(Italiano)}}<br />
{{i18n_entry|Русский|SSH_(Русский)}}<br />
{{i18n_entry|简体中文|SSH_(简体中文)}}<br />
{{i18n_links_end}}<br />
<br />
= Introduction =<br />
Secure Shell or SSH is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary.<br />
<br />
SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding arbitrary TCP ports and X11 connections; it can transfer files using the associated SFTP or SCP protocols.<br />
<br />
An SSH server, by default, listens on the standard TCP port 22. An ssh client program is typically used for establishing connections to an sshd daemon accepting remote connections. Both are commonly present on most modern operating systems, including Mac OS X, Linux, Solaris and OpenVMS. Proprietary, freeware and open source versions of various levels of complexity and completeness exist.<br />
<br />
= OpenSSH =<br />
<br />
OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the ssh protocol. It was created as an open source alternative to the proprietary Secure Shell software suite offered by SSH Communications Security. OpenSSH is developed as part of the OpenBSD project, which is led by Theo de Raadt.<br />
<br />
OpenSSH is occasionally confused with the similarly-named OpenSSL; however, the projects have different purposes and are developed by different teams, the similar name is drawn only from similar goals.<br />
<br />
== Installing OpenSSH ==<br />
# pacman -S openssh<br />
<br />
== Configuring SSH ==<br />
===Client===<br />
The SSH client configuration file can be found and edited in {{Filename|/etc/ssh/ssh_config}}.<br />
<br />
An example configuration: <br />
<br />
{{File|name=/etc/ssh/ssh_config|content=<br />
<br />
# $OpenBSD: ssh_config,v 1.25 2009/02/17 01:28:32 djm Exp $<br />
<br />
# This is the ssh client system-wide configuration file. See<br />
# ssh_config(5) for more information. This file provides defaults for<br />
# users, and the values can be changed in per-user configuration files<br />
# or on the command line.<br />
<br />
# Configuration data is parsed as follows:<br />
# 1. command line options<br />
# 2. user-specific file<br />
# 3. system-wide file<br />
# Any configuration value is only changed the first time it is set.<br />
# Thus, host-specific definitions should be at the beginning of the<br />
# configuration file, and defaults at the end.<br />
<br />
# Site-wide defaults for some commonly used options. For a comprehensive<br />
# list of available options, their meanings and defaults, please see the<br />
# ssh_config(5) man page.<br />
<br />
Host *<br />
# ForwardAgent no<br />
# ForwardX11 no<br />
# RhostsRSAAuthentication no<br />
# RSAAuthentication yes<br />
# PasswordAuthentication yes<br />
# HostbasedAuthentication no<br />
# GSSAPIAuthentication no<br />
# GSSAPIDelegateCredentials no<br />
# BatchMode no<br />
# CheckHostIP yes<br />
# AddressFamily any<br />
# ConnectTimeout 0<br />
# StrictHostKeyChecking ask<br />
# IdentityFile ~/.ssh/identity<br />
# IdentityFile ~/.ssh/id_rsa<br />
# IdentityFile ~/.ssh/id_dsa<br />
# Port 22<br />
# Protocol 2,1<br />
# Cipher 3des<br />
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc<br />
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160<br />
# EscapeChar ~<br />
# Tunnel no<br />
# TunnelDevice any:any<br />
# PermitLocalCommand no<br />
# VisualHostKey no<br />
HashKnownHosts yes<br />
StrictHostKeyChecking ask}}<br />
<br />
It is recommended to change the Protocol line into this:<br />
Protocol 2<br />
<br />
That means that only Protocol 2 will be used, since Protocol 1 is considered somewhat insecure.<br />
<br />
===Daemon===<br />
The SSH daemon configuration file can be found and edited in {{Filename|/etc/ssh/ssh'''d'''_config}}.<br />
<br />
An example configuration: <br />
<br />
{{File|name=/etc/ssh/sshd_config|content=<br />
<br />
# $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $<br />
<br />
# This is the sshd server system-wide configuration file. See<br />
# sshd_config(5) for more information.<br />
<br />
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin<br />
<br />
# The strategy used for options in the default sshd_config shipped with<br />
# OpenSSH is to specify options with their default value where<br />
# possible, but leave them commented. Uncommented options change a<br />
# default value.<br />
<br />
#Port 22<br />
#Protocol 2,1<br />
ListenAddress 0.0.0.0<br />
#ListenAddress ::<br />
<br />
# HostKey for protocol version 1<br />
#HostKey /etc/ssh/ssh''host''key<br />
# HostKeys for protocol version 2<br />
#HostKey /etc/ssh/ssh''host''rsa_key<br />
#HostKey /etc/ssh/ssh''host''dsa_key<br />
<br />
# Lifetime and size of ephemeral version 1 server key<br />
#KeyRegenerationInterval 1h<br />
#ServerKeyBits 768<br />
<br />
# Logging<br />
#obsoletes ~QuietMode and ~FascistLogging<br />
#SyslogFacility AUTH<br />
#LogLevel INFO<br />
<br />
# Authentication:<br />
<br />
#LoginGraceTime 2m<br />
#PermitRootLogin yes<br />
#StrictModes yes<br />
#MaxAuthTries 6<br />
<br />
#RSAAuthentication yes<br />
#PubkeyAuthentication yes<br />
#AuthorizedKeysFile .ssh/authorized_keys<br />
<br />
# For this to work you will also need host keys in /etc/ssh/ssh''known''hosts<br />
#RhostsRSAAuthentication no<br />
# similar for protocol version 2<br />
#HostbasedAuthentication no<br />
# Change to yes if you don't trust ~/.ssh/known_hosts for<br />
# RhostsRSAAuthentication and HostbasedAuthentication<br />
#IgnoreUserKnownHosts no<br />
# Don't read the user's ~/.rhosts and ~/.shosts files<br />
#IgnoreRhosts yes<br />
<br />
# To disable tunneled clear text passwords, change to no here!<br />
#PasswordAuthentication yes<br />
#PermitEmptyPasswords no<br />
<br />
# Change to no to disable s/key passwords<br />
#ChallengeResponseAuthentication yes<br />
<br />
# Kerberos options<br />
#KerberosAuthentication no<br />
#KerberosOrLocalPasswd yes<br />
#KerberosTicketCleanup yes<br />
#KerberosGetAFSToken no<br />
<br />
# GSSAPI options<br />
#GSSAPIAuthentication no<br />
#GSSAPICleanupCredentials yes<br />
<br />
# Set this to 'yes' to enable PAM authentication, account processing,<br />
# and session processing. If this is enabled, PAM authentication will<br />
# be allowed through the ~ChallengeResponseAuthentication mechanism.<br />
# Depending on your PAM configuration, this may bypass the setting of<br />
# PasswordAuthentication, ~PermitEmptyPasswords, and<br />
# "PermitRootLogin without-password". If you just want the PAM account and<br />
# session checks to run without PAM authentication, then enable this but set<br />
# ChallengeResponseAuthentication=no<br />
#UsePAM no<br />
<br />
#AllowTcpForwarding yes<br />
#GatewayPorts no<br />
#X11Forwarding no<br />
#X11DisplayOffset 10<br />
#X11UseLocalhost yes<br />
#PrintMotd yes<br />
#PrintLastLog yes<br />
#TCPKeepAlive yes<br />
#UseLogin no<br />
#UsePrivilegeSeparation yes<br />
#PermitUserEnvironment no<br />
#Compression yes<br />
#ClientAliveInterval 0<br />
#ClientAliveCountMax 3<br />
#UseDNS yes<br />
#PidFile /var/run/sshd.pid<br />
#MaxStartups 10<br />
<br />
# no default banner path<br />
#Banner /some/path<br />
<br />
# override default of no subsystems<br />
Subsystem sftp /usr/lib/ssh/sftp-server}}<br />
<br />
<br />
To allow access only for some users add this line:<br />
AllowUsers user1 user2<br />
<br />
You might want to change some lines so that they look as following:<br />
<pre><br />
Protocol 2<br />
.<br />
.<br />
.<br />
LoginGraceTime 120<br />
.<br />
.<br />
.<br />
PermitRootLogin no # (put yes here if you want root login)<br />
</pre><br />
<br />
You could also uncomment the BANNER option and edit {{Filename|/etc/issue}} for a nice welcome message.<br />
<br />
{{Tip| You may want to change the default port from 22 to any higher port (see [http://en.wikipedia.org/wiki/Security_through_obscurity security through obscurity]).}} <br />
<br />
Even though the port ssh is running on could be detected by using a port-scanner like nmap, changing it will reduce the number of log entries caused by automated authentication attempts.<br />
===Allowing others in===<br />
{{Box Note | You have to adjust this file to remotely connect to your machine since the file is empty by default}}<br />
<br />
To let other people ssh to your machine you need to adjust {{Filename|/etc/hosts.allow}}, add the following:<br />
<br />
<pre><br />
# let everyone connect to you<br />
sshd: ALL<br />
<br />
# OR you can restrict it to a certain ip<br />
sshd: 192.168.0.1<br />
<br />
# OR restrict for an IP range<br />
sshd: 10.0.0.0/255.255.255.0<br />
<br />
# OR restrict for an IP match<br />
sshd: 192.168.1.<br />
</pre><br />
<br />
Now you should check your {{Filename|/etc/hosts.deny}} for the following line and make sure it looks like this:<br />
ALL: ALL: DENY<br />
<br />
That's it. You can SSH out and others should be able to SSH in :).<br />
<br />
To start using the new configuration, restart the daemon (as root):<br />
# /etc/rc.d/sshd restart<br />
<br />
== Managing SSHD Daemon ==<br />
Just add sshd to the "DAEMONS" section of your {{Filename|/etc/[[rc.conf]]}}:<br />
DAEMONS=(... ... '''sshd''' ... ...)<br />
<br />
To start/restart/stop the daemon, use the following:<br />
# /etc/rc.d/sshd {start|stop|restart}<br />
<br />
==Connecting to the server==<br />
To connect to a server, run:<br />
$ ssh -p port user@server-address<br />
<br />
= Tips and Tricks =<br />
<br />
== Encrypted Socks Tunnel ==<br />
This is highly useful for laptop users connected to various unsafe wireless connections. The only thing you need is an SSH server running at a somewhat secure location, like your home or at work. It might be useful to use a dynamic DNS service like [http://www.dyndns.org/ DynDNS] so you don't have to remember your IP-address.<br />
<br />
=== Step 1: Start the Connection ===<br />
You only have to execute this single command in your favorite terminal to start the connection:<br />
$ ssh -ND 4711 user@host<br />
where {{Codeline|"user"}} is your username at the SSH server running at the {{Codeline|"host"}}. It will ask for your password, and then you're connected! The {{Codeline|"N"}} flag disables the interactive prompt, and the {{Codeline|"D"}} flag specifies the local port on wich to listen on (you can choose any port number if you want).<br />
<br />
One way to make this easier is to put an alias line in your {{Filename|~/.bashrc}} file as following:<br />
alias sshtunnel="ssh -ND 4711 -v user@host"<br />
It's nice to add the verbose {{Codeline|"-v"}} flag, because then you can verify that it's actually connected from that output. Now you just have to execute the {{Codeline|"sshtunnel"}} command :)<br />
<br />
=== Step 2: Configure your Browser (or other programs) ===<br />
<br />
The above step is completely useless if you don't configure your web browser (or other programs) to use this newly created socks tunnel. <br />
<br />
* For Firefox: ''Edit &rarr; Preferences &rarr; Advanced &rarr; Network &rarr; Connection &rarr; Setting'':<br />
: Check the ''"Manual proxy configuration"'' radio button, and enter "localhost" in the ''"SOCKS host"'' text field, and then enter your port number in the next text field (I used 4711 above).<br />
<br />
: Make sure you select SOCKS4 as the protocol to use. This procedure will not work for SOCKS5.<br />
<br />
Enjoy your secure tunnel!<br />
<br />
== X11 Forwarding ==<br />
<br />
To run graphical programs through a SSH connection you can enable X11 forwarding. An option needs to be set in the configuration files on the server and client.<br />
<br />
Install xorg-xauth on the server:<br />
# pacman -S xorg-xauth<br />
<br />
* Enable the '''AllowTcpForwarding''' option in {{Filename|sshd_config}} on the '''server'''.<br />
* Enable the '''X11Forwarding''' option in {{Filename|sshd_config}} on the '''server'''.<br />
* Set the '''X11DisplayOffset''' option in {{Filename|sshd_config}} on the '''server''' to 10.<br />
* Enable the '''X11UseLocalhost''' option in {{Filename|sshd_config}} on the '''server'''.<br />
<br />
<br />
* Enable the '''ForwardX11''' option in {{Filename|ssh_config}} on the '''client'''.<br />
<br />
To use the forwarding, log on to your server through ssh:<br />
# ssh -X -p port user@server-address<br />
If you receive errors trying to run graphical applications try trusted forwarding instead:<br />
# ssh -Y -p port user@server-address<br />
You can now start any X program on the remote server, the output will be forwarded to your local session:<br />
# xclock<br />
<br />
== Speed up SSH ==<br />
Changing the ciphers used by SSH to less cpu-demanding ones can improve speed. In this aspect, the best choices are arcfour and blowfish-cbc. To use them, run SSH with the {{Codeline|"c"}} flag, like this:<br />
# ssh -c arcfour,blowfish-cbc user@server-address<br />
To use them permanently, add this line under the proper host in {{Filename|/etc/ssh/ssh_config}}:<br />
Ciphers arcfour,blowfish-cbc<br />
Another option to improve speed is to enable compression with the {{Codeline|"C"}} flag. A permanent solution is to add this line under the proper host in {{Filename|/etc/ssh/ssh_config}}:<br />
Compression yes<br />
Login time can be shorten by using the {{Codeline|"4"}} flag, which bypasses IPv6 lookup. This can be made permanent by adding this line under the proper host in {{Filename|/etc/ssh/ssh_config}}:<br />
AddressFamily inet<br />
Another way of making these changes permanent is to create an alias in {{Filename|~/.bashrc}}:<br />
alias ssh='ssh -C4c arcfour,blowfish-cbc'<br />
Finally, you can make all sessions to the same host use a single connection, which will greatly speed up subsecent logins, by adding those line under the proper host in {{Filename|/etc/ssh/ssh_config}}:<br />
ControlMaster auto<br />
ControlPath ~/.ssh/socket-%r@%h:%p<br />
<br />
=== Trouble Shooting ===<br />
<br />
make sure your DISPLAY string is resolveable on the remote end:<br />
<br />
ssh -X user@server-address<br />
server$ echo $DISPLAY<br />
localhost:10.0<br />
server$ telnet localhost 6010<br />
localhost/6010: lookup failure: Temporary failure in name resolution <br />
<br />
can be fixed by adding localhost to {{Filename|/etc/hosts}}.<br />
<br />
== Mounting a Remote Filesystem with SSHFS ==<br />
<br />
Install sshfs<br />
# pacman -S sshfs<br />
<br />
Load the Fuse module<br />
# modprobe fuse<br />
Add fuse to the ''modules'' array in {{Filename|/etc/rc.conf}} to load it on each system boot.<br />
<br />
Mount the remote folder using sshfs<br />
# mkdir ~/remote_folder<br />
# sshfs USER@remote_server:/tmp ~/remote_folder<br />
<br />
The command above will cause the folder /tmp on the remote server to be mounted as ~/remote_folder on the local machine. Copying any file to this folder will result in transparent copying over the network using SFTP. Same concerns direct file editing, creating or removing.<br />
<br />
When we’re done working with the remote filesystem, we can unmount the remote folder by issuing:<br />
# fusermount -u ~/remote_folder<br />
<br />
If we work on this folder on a daily basis, it is wise to add it to the {{Filename|/etc/fstab}} table. This way is can be automatically mounted upon system boot or mounted manually (if {{Codeline|noauto}} option is chosen) without the need to specify the remote location each time. Here is a sample entry in the table:<br />
sshfs#USER@remote_server:/tmp /full/path/to/directory fuse defaults,auto 0 0<br />
<br />
=== Keep Alive ===<br />
<br />
Your ssh session will automatically log out if it is idle. To keep the connection active (alive) add this to {{Filename|~/.ssh/config}} or to {{Filename|/etc/ssh/ssh_config}} on the client.<br />
<br />
ServerAliveInterval 5<br />
<br />
This will send a "keep alive" signal to the server every 5 seconds. You can usually increase this interval, and I use 120.<br />
<br />
= Links & References =<br />
*[http://www.soloport.com/iptables.html A Cure for the Common SSH Login Attack]<br />
*[[Using SSH Keys]]<br />
*[http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks]</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=95203Improving performance2010-02-06T07:02:32Z<p>Rttommy: /* Mounting /tmp to RAM */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=95202Improving performance2010-02-06T07:02:10Z<p>Rttommy: /* Swappiness */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=95201Improving performance2010-02-06T07:01:42Z<p>Rttommy: /* GPU Overclocking */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=95200Improving performance2010-02-06T07:01:17Z<p>Rttommy: /* Xorg.conf configuration */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to ~/.xinitrc. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=OpenSSH&diff=95199OpenSSH2010-02-06T06:56:37Z<p>Rttommy: /* Speed up SSH */</p>
<hr />
<div>[[Category:Daemons_and_system_services (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|SSH}}<br />
{{i18n_entry|Italiano|SSH_(Italiano)}}<br />
{{i18n_entry|Русский|SSH_(Русский)}}<br />
{{i18n_entry|简体中文|SSH_(简体中文)}}<br />
{{i18n_links_end}}<br />
<br />
= Introduction =<br />
Secure Shell or SSH is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary.<br />
<br />
SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding arbitrary TCP ports and X11 connections; it can transfer files using the associated SFTP or SCP protocols.<br />
<br />
An SSH server, by default, listens on the standard TCP port 22. An ssh client program is typically used for establishing connections to an sshd daemon accepting remote connections. Both are commonly present on most modern operating systems, including Mac OS X, Linux, Solaris and OpenVMS. Proprietary, freeware and open source versions of various levels of complexity and completeness exist.<br />
<br />
= OpenSSH =<br />
<br />
OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the ssh protocol. It was created as an open source alternative to the proprietary Secure Shell software suite offered by SSH Communications Security. OpenSSH is developed as part of the OpenBSD project, which is led by Theo de Raadt.<br />
<br />
OpenSSH is occasionally confused with the similarly-named OpenSSL; however, the projects have different purposes and are developed by different teams, the similar name is drawn only from similar goals.<br />
<br />
== Installing OpenSSH ==<br />
# pacman -S openssh<br />
<br />
== Configuring SSH ==<br />
===Client===<br />
The SSH client configuration file can be found and edited in {{Filename|/etc/ssh/ssh_config}}.<br />
<br />
An example configuration: <br />
<br />
{{File|name=/etc/ssh/ssh_config|content=<br />
<br />
# $OpenBSD: ssh_config,v 1.25 2009/02/17 01:28:32 djm Exp $<br />
<br />
# This is the ssh client system-wide configuration file. See<br />
# ssh_config(5) for more information. This file provides defaults for<br />
# users, and the values can be changed in per-user configuration files<br />
# or on the command line.<br />
<br />
# Configuration data is parsed as follows:<br />
# 1. command line options<br />
# 2. user-specific file<br />
# 3. system-wide file<br />
# Any configuration value is only changed the first time it is set.<br />
# Thus, host-specific definitions should be at the beginning of the<br />
# configuration file, and defaults at the end.<br />
<br />
# Site-wide defaults for some commonly used options. For a comprehensive<br />
# list of available options, their meanings and defaults, please see the<br />
# ssh_config(5) man page.<br />
<br />
Host *<br />
# ForwardAgent no<br />
# ForwardX11 no<br />
# RhostsRSAAuthentication no<br />
# RSAAuthentication yes<br />
# PasswordAuthentication yes<br />
# HostbasedAuthentication no<br />
# GSSAPIAuthentication no<br />
# GSSAPIDelegateCredentials no<br />
# BatchMode no<br />
# CheckHostIP yes<br />
# AddressFamily any<br />
# ConnectTimeout 0<br />
# StrictHostKeyChecking ask<br />
# IdentityFile ~/.ssh/identity<br />
# IdentityFile ~/.ssh/id_rsa<br />
# IdentityFile ~/.ssh/id_dsa<br />
# Port 22<br />
# Protocol 2,1<br />
# Cipher 3des<br />
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc<br />
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160<br />
# EscapeChar ~<br />
# Tunnel no<br />
# TunnelDevice any:any<br />
# PermitLocalCommand no<br />
# VisualHostKey no<br />
HashKnownHosts yes<br />
StrictHostKeyChecking ask}}<br />
<br />
It is recommended to change the Protocol line into this:<br />
Protocol 2<br />
<br />
That means that only Protocol 2 will be used, since Protocol 1 is considered somewhat insecure.<br />
<br />
===Daemon===<br />
The SSH daemon configuration file can be found and edited in {{Filename|/etc/ssh/ssh'''d'''_config}}.<br />
<br />
An example configuration: <br />
<br />
{{File|name=/etc/ssh/sshd_config|content=<br />
<br />
# $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $<br />
<br />
# This is the sshd server system-wide configuration file. See<br />
# sshd_config(5) for more information.<br />
<br />
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin<br />
<br />
# The strategy used for options in the default sshd_config shipped with<br />
# OpenSSH is to specify options with their default value where<br />
# possible, but leave them commented. Uncommented options change a<br />
# default value.<br />
<br />
#Port 22<br />
#Protocol 2,1<br />
ListenAddress 0.0.0.0<br />
#ListenAddress ::<br />
<br />
# HostKey for protocol version 1<br />
#HostKey /etc/ssh/ssh''host''key<br />
# HostKeys for protocol version 2<br />
#HostKey /etc/ssh/ssh''host''rsa_key<br />
#HostKey /etc/ssh/ssh''host''dsa_key<br />
<br />
# Lifetime and size of ephemeral version 1 server key<br />
#KeyRegenerationInterval 1h<br />
#ServerKeyBits 768<br />
<br />
# Logging<br />
#obsoletes ~QuietMode and ~FascistLogging<br />
#SyslogFacility AUTH<br />
#LogLevel INFO<br />
<br />
# Authentication:<br />
<br />
#LoginGraceTime 2m<br />
#PermitRootLogin yes<br />
#StrictModes yes<br />
#MaxAuthTries 6<br />
<br />
#RSAAuthentication yes<br />
#PubkeyAuthentication yes<br />
#AuthorizedKeysFile .ssh/authorized_keys<br />
<br />
# For this to work you will also need host keys in /etc/ssh/ssh''known''hosts<br />
#RhostsRSAAuthentication no<br />
# similar for protocol version 2<br />
#HostbasedAuthentication no<br />
# Change to yes if you don't trust ~/.ssh/known_hosts for<br />
# RhostsRSAAuthentication and HostbasedAuthentication<br />
#IgnoreUserKnownHosts no<br />
# Don't read the user's ~/.rhosts and ~/.shosts files<br />
#IgnoreRhosts yes<br />
<br />
# To disable tunneled clear text passwords, change to no here!<br />
#PasswordAuthentication yes<br />
#PermitEmptyPasswords no<br />
<br />
# Change to no to disable s/key passwords<br />
#ChallengeResponseAuthentication yes<br />
<br />
# Kerberos options<br />
#KerberosAuthentication no<br />
#KerberosOrLocalPasswd yes<br />
#KerberosTicketCleanup yes<br />
#KerberosGetAFSToken no<br />
<br />
# GSSAPI options<br />
#GSSAPIAuthentication no<br />
#GSSAPICleanupCredentials yes<br />
<br />
# Set this to 'yes' to enable PAM authentication, account processing,<br />
# and session processing. If this is enabled, PAM authentication will<br />
# be allowed through the ~ChallengeResponseAuthentication mechanism.<br />
# Depending on your PAM configuration, this may bypass the setting of<br />
# PasswordAuthentication, ~PermitEmptyPasswords, and<br />
# "PermitRootLogin without-password". If you just want the PAM account and<br />
# session checks to run without PAM authentication, then enable this but set<br />
# ChallengeResponseAuthentication=no<br />
#UsePAM no<br />
<br />
#AllowTcpForwarding yes<br />
#GatewayPorts no<br />
#X11Forwarding no<br />
#X11DisplayOffset 10<br />
#X11UseLocalhost yes<br />
#PrintMotd yes<br />
#PrintLastLog yes<br />
#TCPKeepAlive yes<br />
#UseLogin no<br />
#UsePrivilegeSeparation yes<br />
#PermitUserEnvironment no<br />
#Compression yes<br />
#ClientAliveInterval 0<br />
#ClientAliveCountMax 3<br />
#UseDNS yes<br />
#PidFile /var/run/sshd.pid<br />
#MaxStartups 10<br />
<br />
# no default banner path<br />
#Banner /some/path<br />
<br />
# override default of no subsystems<br />
Subsystem sftp /usr/lib/ssh/sftp-server}}<br />
<br />
<br />
To allow access only for some users add this line:<br />
AllowUsers user1 user2<br />
<br />
You might want to change some lines so that they look as following:<br />
<pre><br />
Protocol 2<br />
.<br />
.<br />
.<br />
LoginGraceTime 120<br />
.<br />
.<br />
.<br />
PermitRootLogin no # (put yes here if you want root login)<br />
</pre><br />
<br />
You could also uncomment the BANNER option and edit {{Filename|/etc/issue}} for a nice welcome message.<br />
<br />
{{Tip| You may want to change the default port from 22 to any higher port (see [http://en.wikipedia.org/wiki/Security_through_obscurity security through obscurity]).}} <br />
<br />
Even though the port ssh is running on could be detected by using a port-scanner like nmap, changing it will reduce the number of log entries caused by automated authentication attempts.<br />
===Allowing others in===<br />
{{Box Note | You have to adjust this file to remotely connect to your machine since the file is empty by default}}<br />
<br />
To let other people ssh to your machine you need to adjust {{Filename|/etc/hosts.allow}}, add the following:<br />
<br />
<pre><br />
# let everyone connect to you<br />
sshd: ALL<br />
<br />
# OR you can restrict it to a certain ip<br />
sshd: 192.168.0.1<br />
<br />
# OR restrict for an IP range<br />
sshd: 10.0.0.0/255.255.255.0<br />
<br />
# OR restrict for an IP match<br />
sshd: 192.168.1.<br />
</pre><br />
<br />
Now you should check your {{Filename|/etc/hosts.deny}} for the following line and make sure it looks like this:<br />
ALL: ALL: DENY<br />
<br />
That's it. You can SSH out and others should be able to SSH in :).<br />
<br />
To start using the new configuration, restart the daemon (as root):<br />
# /etc/rc.d/sshd restart<br />
<br />
== Managing SSHD Daemon ==<br />
Just add sshd to the "DAEMONS" section of your {{Filename|/etc/[[rc.conf]]}}:<br />
DAEMONS=(... ... '''sshd''' ... ...)<br />
<br />
To start/restart/stop the daemon, use the following:<br />
# /etc/rc.d/sshd {start|stop|restart}<br />
<br />
==Connecting to the server==<br />
To connect to a server, run:<br />
$ ssh -p port user@server-address<br />
<br />
= Tips and Tricks =<br />
<br />
== Encrypted Socks Tunnel ==<br />
This is highly useful for laptop users connected to various unsafe wireless connections. The only thing you need is an SSH server running at a somewhat secure location, like your home or at work. It might be useful to use a dynamic DNS service like [http://www.dyndns.org/ DynDNS] so you don't have to remember your IP-address.<br />
<br />
=== Step 1: Start the Connection ===<br />
You only have to execute this single command in your favorite terminal to start the connection:<br />
$ ssh -ND 4711 user@host<br />
where {{Codeline|"user"}} is your username at the SSH server running at the {{Codeline|"host"}}. It will ask for your password, and then you're connected! The {{Codeline|"N"}} flag disables the interactive prompt, and the {{Codeline|"D"}} flag specifies the local port on wich to listen on (you can choose any port number if you want).<br />
<br />
One way to make this easier is to put an alias line in your {{Filename|~/.bashrc}} file as following:<br />
alias sshtunnel="ssh -ND 4711 -v user@host"<br />
It's nice to add the verbose {{Codeline|"-v"}} flag, because then you can verify that it's actually connected from that output. Now you just have to execute the {{Codeline|"sshtunnel"}} command :)<br />
<br />
=== Step 2: Configure your Browser (or other programs) ===<br />
<br />
The above step is completely useless if you don't configure your web browser (or other programs) to use this newly created socks tunnel. <br />
<br />
* For Firefox: ''Edit &rarr; Preferences &rarr; Advanced &rarr; Network &rarr; Connection &rarr; Setting'':<br />
: Check the ''"Manual proxy configuration"'' radio button, and enter "localhost" in the ''"SOCKS host"'' text field, and then enter your port number in the next text field (I used 4711 above).<br />
<br />
: Make sure you select SOCKS4 as the protocol to use. This procedure will not work for SOCKS5.<br />
<br />
Enjoy your secure tunnel!<br />
<br />
== X11 Forwarding ==<br />
<br />
To run graphical programs through a SSH connection you can enable X11 forwarding. An option needs to be set in the configuration files on the server and client.<br />
<br />
Install xorg-xauth on the server:<br />
# pacman -S xorg-xauth<br />
<br />
* Enable the '''AllowTcpForwarding''' option in {{Filename|sshd_config}} on the '''server'''.<br />
* Enable the '''X11Forwarding''' option in {{Filename|sshd_config}} on the '''server'''.<br />
* Set the '''X11DisplayOffset''' option in {{Filename|sshd_config}} on the '''server''' to 10.<br />
* Enable the '''X11UseLocalhost''' option in {{Filename|sshd_config}} on the '''server'''.<br />
<br />
<br />
* Enable the '''ForwardX11''' option in {{Filename|ssh_config}} on the '''client'''.<br />
<br />
To use the forwarding, log on to your server through ssh:<br />
# ssh -X -p port user@server-address<br />
If you receive errors trying to run graphical applications try trusted forwarding instead:<br />
# ssh -Y -p port user@server-address<br />
You can now start any X program on the remote server, the output will be forwarded to your local session:<br />
# xclock<br />
<br />
== Speed up SSH ==<br />
Changing the ciphers used by SSH to less cpu-demanding ones can improve speed. In this aspect, the best choices are arcfour and blowfish-cbc. To use them, run SSH with the {{Codeline|"c"}} flag, like this:<br />
# ssh -c arcfour,blowfish-cbc user@server-address<br />
To use them permanently, add this line under the proper host in {{Filename|/etc/ssh/ssh_config}}:<br />
Ciphers arcfour,blowfish-cbc<br />
Another option to improve speed is to enable compression with the {{Codeline|"C"}} flag. A permanent solution is to add this line under the proper host in {{Filename|/etc/ssh/ssh_config}}:<br />
Compression yes<br />
Login time can be shorten by using the {{Codeline|"4"}} flag, which bypasses IPv6 lookup. This can be made permanent by adding this line under the proper host in {{Filename|/etc/ssh/ssh_config}}:<br />
AddressFamily inet<br />
Another way of making these changes permanent is to create an alias in {{Filename|~/.bashrc}}:<br />
alias ssh='ssh -C4c arcfour,blowfish-cbc'<br />
Finally, you can make all sessions to the same host use a single connection, which will greatly speed up subsecent logins, by adding those line under the proper host in {{Filename|/etc/ssh/ssh_config}}:<br />
ControlMaster auto<br />
ControlPath ~/.ssh/socket-%r@%h:%p<br />
<br />
=== Trouble Shooting ===<br />
<br />
make sure your DISPLAY string is resolveable on the remote end:<br />
<br />
ssh -X user@server-address<br />
server$ echo $DISPLAY<br />
localhost:10.0<br />
server$ telnet localhost 6010<br />
localhost/6010: lookup failure: Temporary failure in name resolution <br />
<br />
can be fixed by adding localhost to {{Filename|/etc/hosts}}.<br />
<br />
== Mounting a Remote Filesystem with SSHFS ==<br />
<br />
Install sshfs<br />
# pacman -S sshfs<br />
<br />
Load the Fuse module<br />
# modprobe fuse<br />
Add fuse to the ''modules'' array in {{Filename|/etc/rc.conf}} to load it on each system boot.<br />
<br />
Mount the remote folder using sshfs<br />
# mkdir ~/remote_folder<br />
# sshfs USER@remote_server:/tmp ~/remote_folder<br />
<br />
The command above will cause the folder /tmp on the remote server to be mounted as ~/remote_folder on the local machine. Copying any file to this folder will result in transparent copying over the network using SFTP. Same concerns direct file editing, creating or removing.<br />
<br />
When we’re done working with the remote filesystem, we can unmount the remote folder by issuing:<br />
# fusermount -u ~/remote_folder<br />
<br />
If we work on this folder on a daily basis, it is wise to add it to the {{Filename|/etc/fstab}} table. This way is can be automatically mounted upon system boot or mounted manually (if {{Codeline|noauto}} option is chosen) without the need to specify the remote location each time. Here is a sample entry in the table:<br />
sshfs#USER@remote_server:/tmp /full/path/to/directory fuse defaults,auto 0 0<br />
<br />
=== Keep Alive ===<br />
<br />
Your ssh session will automatically log out if it is idle. To keep the connection active (alive) add this to '''~/.ssh/config''' or to '''/etc/ssh/ssh_config''' on the client.<br />
<br />
ServerAliveInterval 5<br />
<br />
This will send a "keep alive" signal to the server every 5 seconds. You can usually increase this interval, and I use 120.<br />
<br />
= Links & References =<br />
*[http://www.soloport.com/iptables.html A Cure for the Common SSH Login Attack]<br />
*[[Using SSH Keys]]<br />
*[http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks]</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=95190Improving performance2010-02-06T01:09:42Z<p>Rttommy: /* Reiserfs */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in /etc/X11/xorg.conf. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to ~/.xinitrc. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=95094Improving performance2010-02-05T05:47:34Z<p>Rttommy: /* Network */ Pointed to General Recommendations</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This can be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in /etc/X11/xorg.conf. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to ~/.xinitrc. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=95091Improving performance2010-02-05T04:58:31Z<p>Rttommy: Added Gcc/Makepkg</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This can be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
See [[IPv6 - Disabling the Module|Disabling IPv6]].<br />
===Speeding up DNS===<br />
By tuning DNS querying, you can noticeably speed up web browsing. See [[Speeding up DNS with dnsmasq]] or [[Pdnsd]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in /etc/X11/xorg.conf. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to ~/.xinitrc. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=95089Improving performance2010-02-05T04:47:26Z<p>Rttommy: /* Network */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See: [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See: [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See: [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see: [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This can be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
See: [[IPv6 - Disabling the Module|Disabling IPv6]].<br />
===Speeding up DNS===<br />
By tuning DNS querying, you can noticeably speed up web browsing. See: [[Speeding up DNS with dnsmasq]] or [[Pdnsd]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in /etc/X11/xorg.conf. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to ~/.xinitrc. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See: [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See: [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See: [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See: [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=OpenSSH&diff=95087OpenSSH2010-02-05T04:42:40Z<p>Rttommy: /* Speed up SSH */</p>
<hr />
<div>[[Category:Daemons_and_system_services (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|SSH}}<br />
{{i18n_entry|Italiano|SSH_(Italiano)}}<br />
{{i18n_entry|Русский|SSH_(Русский)}}<br />
{{i18n_entry|简体中文|SSH_(简体中文)}}<br />
{{i18n_links_end}}<br />
<br />
= Introduction =<br />
Secure Shell or SSH is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary.<br />
<br />
SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding arbitrary TCP ports and X11 connections; it can transfer files using the associated SFTP or SCP protocols.<br />
<br />
An SSH server, by default, listens on the standard TCP port 22. An ssh client program is typically used for establishing connections to an sshd daemon accepting remote connections. Both are commonly present on most modern operating systems, including Mac OS X, Linux, Solaris and OpenVMS. Proprietary, freeware and open source versions of various levels of complexity and completeness exist.<br />
<br />
= OpenSSH =<br />
<br />
OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the ssh protocol. It was created as an open source alternative to the proprietary Secure Shell software suite offered by SSH Communications Security. OpenSSH is developed as part of the OpenBSD project, which is led by Theo de Raadt.<br />
<br />
OpenSSH is occasionally confused with the similarly-named OpenSSL; however, the projects have different purposes and are developed by different teams, the similar name is drawn only from similar goals.<br />
<br />
== Installing OpenSSH ==<br />
# pacman -S openssh<br />
<br />
== Configuring SSH ==<br />
===Client===<br />
The SSH client configuration file can be found and edited in {{Filename|/etc/ssh/ssh_config}}.<br />
<br />
An example configuration: <br />
<br />
{{File|name=/etc/ssh/ssh_config|content=<br />
<br />
# $OpenBSD: ssh_config,v 1.25 2009/02/17 01:28:32 djm Exp $<br />
<br />
# This is the ssh client system-wide configuration file. See<br />
# ssh_config(5) for more information. This file provides defaults for<br />
# users, and the values can be changed in per-user configuration files<br />
# or on the command line.<br />
<br />
# Configuration data is parsed as follows:<br />
# 1. command line options<br />
# 2. user-specific file<br />
# 3. system-wide file<br />
# Any configuration value is only changed the first time it is set.<br />
# Thus, host-specific definitions should be at the beginning of the<br />
# configuration file, and defaults at the end.<br />
<br />
# Site-wide defaults for some commonly used options. For a comprehensive<br />
# list of available options, their meanings and defaults, please see the<br />
# ssh_config(5) man page.<br />
<br />
Host *<br />
# ForwardAgent no<br />
# ForwardX11 no<br />
# RhostsRSAAuthentication no<br />
# RSAAuthentication yes<br />
# PasswordAuthentication yes<br />
# HostbasedAuthentication no<br />
# GSSAPIAuthentication no<br />
# GSSAPIDelegateCredentials no<br />
# BatchMode no<br />
# CheckHostIP yes<br />
# AddressFamily any<br />
# ConnectTimeout 0<br />
# StrictHostKeyChecking ask<br />
# IdentityFile ~/.ssh/identity<br />
# IdentityFile ~/.ssh/id_rsa<br />
# IdentityFile ~/.ssh/id_dsa<br />
# Port 22<br />
# Protocol 2,1<br />
# Cipher 3des<br />
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc<br />
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160<br />
# EscapeChar ~<br />
# Tunnel no<br />
# TunnelDevice any:any<br />
# PermitLocalCommand no<br />
# VisualHostKey no<br />
HashKnownHosts yes<br />
StrictHostKeyChecking ask}}<br />
<br />
It is recommended to change the Protocol line into this:<br />
Protocol 2<br />
<br />
That means that only Protocol 2 will be used, since Protocol 1 is considered somewhat insecure.<br />
<br />
===Daemon===<br />
The SSH daemon configuration file can be found and edited in {{Filename|/etc/ssh/ssh'''d'''_config}}.<br />
<br />
An example configuration: <br />
<br />
{{File|name=/etc/ssh/sshd_config|content=<br />
<br />
# $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $<br />
<br />
# This is the sshd server system-wide configuration file. See<br />
# sshd_config(5) for more information.<br />
<br />
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin<br />
<br />
# The strategy used for options in the default sshd_config shipped with<br />
# OpenSSH is to specify options with their default value where<br />
# possible, but leave them commented. Uncommented options change a<br />
# default value.<br />
<br />
#Port 22<br />
#Protocol 2,1<br />
ListenAddress 0.0.0.0<br />
#ListenAddress ::<br />
<br />
# HostKey for protocol version 1<br />
#HostKey /etc/ssh/ssh''host''key<br />
# HostKeys for protocol version 2<br />
#HostKey /etc/ssh/ssh''host''rsa_key<br />
#HostKey /etc/ssh/ssh''host''dsa_key<br />
<br />
# Lifetime and size of ephemeral version 1 server key<br />
#KeyRegenerationInterval 1h<br />
#ServerKeyBits 768<br />
<br />
# Logging<br />
#obsoletes ~QuietMode and ~FascistLogging<br />
#SyslogFacility AUTH<br />
#LogLevel INFO<br />
<br />
# Authentication:<br />
<br />
#LoginGraceTime 2m<br />
#PermitRootLogin yes<br />
#StrictModes yes<br />
#MaxAuthTries 6<br />
<br />
#RSAAuthentication yes<br />
#PubkeyAuthentication yes<br />
#AuthorizedKeysFile .ssh/authorized_keys<br />
<br />
# For this to work you will also need host keys in /etc/ssh/ssh''known''hosts<br />
#RhostsRSAAuthentication no<br />
# similar for protocol version 2<br />
#HostbasedAuthentication no<br />
# Change to yes if you don't trust ~/.ssh/known_hosts for<br />
# RhostsRSAAuthentication and HostbasedAuthentication<br />
#IgnoreUserKnownHosts no<br />
# Don't read the user's ~/.rhosts and ~/.shosts files<br />
#IgnoreRhosts yes<br />
<br />
# To disable tunneled clear text passwords, change to no here!<br />
#PasswordAuthentication yes<br />
#PermitEmptyPasswords no<br />
<br />
# Change to no to disable s/key passwords<br />
#ChallengeResponseAuthentication yes<br />
<br />
# Kerberos options<br />
#KerberosAuthentication no<br />
#KerberosOrLocalPasswd yes<br />
#KerberosTicketCleanup yes<br />
#KerberosGetAFSToken no<br />
<br />
# GSSAPI options<br />
#GSSAPIAuthentication no<br />
#GSSAPICleanupCredentials yes<br />
<br />
# Set this to 'yes' to enable PAM authentication, account processing,<br />
# and session processing. If this is enabled, PAM authentication will<br />
# be allowed through the ~ChallengeResponseAuthentication mechanism.<br />
# Depending on your PAM configuration, this may bypass the setting of<br />
# PasswordAuthentication, ~PermitEmptyPasswords, and<br />
# "PermitRootLogin without-password". If you just want the PAM account and<br />
# session checks to run without PAM authentication, then enable this but set<br />
# ChallengeResponseAuthentication=no<br />
#UsePAM no<br />
<br />
#AllowTcpForwarding yes<br />
#GatewayPorts no<br />
#X11Forwarding no<br />
#X11DisplayOffset 10<br />
#X11UseLocalhost yes<br />
#PrintMotd yes<br />
#PrintLastLog yes<br />
#TCPKeepAlive yes<br />
#UseLogin no<br />
#UsePrivilegeSeparation yes<br />
#PermitUserEnvironment no<br />
#Compression yes<br />
#ClientAliveInterval 0<br />
#ClientAliveCountMax 3<br />
#UseDNS yes<br />
#PidFile /var/run/sshd.pid<br />
#MaxStartups 10<br />
<br />
# no default banner path<br />
#Banner /some/path<br />
<br />
# override default of no subsystems<br />
Subsystem sftp /usr/lib/ssh/sftp-server}}<br />
<br />
<br />
To allow access only for some users add this line:<br />
AllowUsers user1 user2<br />
<br />
You might want to change some lines so that they look as following:<br />
<pre><br />
Protocol 2<br />
.<br />
.<br />
.<br />
LoginGraceTime 120<br />
.<br />
.<br />
.<br />
PermitRootLogin no # (put yes here if you want root login)<br />
</pre><br />
<br />
You could also uncomment the BANNER option and edit {{Filename|/etc/issue}} for a nice welcome message.<br />
<br />
{{Tip| You may want to change the default port from 22 to any higher port (see [http://en.wikipedia.org/wiki/Security_through_obscurity security through obscurity]).}} <br />
<br />
Even though the port ssh is running on could be detected by using a port-scanner like nmap, changing it will reduce the number of log entries caused by automated authentication attempts.<br />
===Allowing others in===<br />
{{Box Note | You have to adjust this file to remotely connect to your machine since the file is empty by default}}<br />
<br />
To let other people ssh to your machine you need to adjust {{Filename|/etc/hosts.allow}}, add the following:<br />
<br />
<pre><br />
# let everyone connect to you<br />
sshd: ALL<br />
<br />
# OR you can restrict it to a certain ip<br />
sshd: 192.168.0.1<br />
<br />
# OR restrict for an IP range<br />
sshd: 10.0.0.0/255.255.255.0<br />
<br />
# OR restrict for an IP match<br />
sshd: 192.168.1.<br />
</pre><br />
<br />
Now you should check your {{Filename|/etc/hosts.deny}} for the following line and make sure it looks like this:<br />
ALL: ALL: DENY<br />
<br />
That's it. You can SSH out and others should be able to SSH in :).<br />
<br />
To start using the new configuration, restart the daemon (as root):<br />
# /etc/rc.d/sshd restart<br />
<br />
== Managing SSHD Daemon ==<br />
Just add sshd to the "DAEMONS" section of your {{Filename|/etc/[[rc.conf]]}}:<br />
DAEMONS=(... ... '''sshd''' ... ...)<br />
<br />
To start/restart/stop the daemon, use the following:<br />
# /etc/rc.d/sshd {start|stop|restart}<br />
<br />
==Connecting to the server==<br />
To connect to a server, run:<br />
$ ssh -p port user@server-address<br />
<br />
= Tips and Tricks =<br />
<br />
== Encrypted Socks Tunnel ==<br />
This is highly useful for laptop users connected to various unsafe wireless connections. The only thing you need is an SSH server running at a somewhat secure location, like your home or at work. It might be useful to use a dynamic DNS service like [http://www.dyndns.org/ DynDNS] so you don't have to remember your IP-address.<br />
<br />
=== Step 1: Start the Connection ===<br />
You only have to execute this single command in your favorite terminal to start the connection:<br />
$ ssh -ND 4711 user@host<br />
where {{Codeline|"user"}} is your username at the SSH server running at the {{Codeline|"host"}}. It will ask for your password, and then you're connected! The {{Codeline|"N"}} flag disables the interactive prompt, and the {{Codeline|"D"}} flag specifies the local port on wich to listen on (you can choose any port number if you want).<br />
<br />
One way to make this easier is to put an alias line in your {{Filename|~/.bashrc}} file as following:<br />
alias sshtunnel="ssh -ND 4711 -v user@host"<br />
It's nice to add the verbose {{Codeline|"-v"}} flag, because then you can verify that it's actually connected from that output. Now you just have to execute the {{Codeline|"sshtunnel"}} command :)<br />
<br />
=== Step 2: Configure your Browser (or other programs) ===<br />
<br />
The above step is completely useless if you don't configure your web browser (or other programs) to use this newly created socks tunnel. <br />
<br />
* For Firefox: ''Edit &rarr; Preferences &rarr; Advanced &rarr; Network &rarr; Connection &rarr; Setting'':<br />
: Check the ''"Manual proxy configuration"'' radio button, and enter "localhost" in the ''"SOCKS host"'' text field, and then enter your port number in the next text field (I used 4711 above).<br />
<br />
: Make sure you select SOCKS4 as the protocol to use. This procedure will not work for SOCKS5.<br />
<br />
Enjoy your secure tunnel!<br />
<br />
== X11 Forwarding ==<br />
<br />
To run graphical programs through a SSH connection you can enable X11 forwarding. An option needs to be set in the configuration files on the server and client.<br />
<br />
Install xorg-xauth on the server:<br />
# pacman -S xorg-xauth<br />
<br />
* Enable the '''AllowTcpForwarding''' option in {{Filename|sshd_config}} on the '''server'''.<br />
* Enable the '''X11Forwarding''' option in {{Filename|sshd_config}} on the '''server'''.<br />
* Set the '''X11DisplayOffset''' option in {{Filename|sshd_config}} on the '''server''' to 10.<br />
* Enable the '''X11UseLocalhost''' option in {{Filename|sshd_config}} on the '''server'''.<br />
<br />
<br />
* Enable the '''ForwardX11''' option in {{Filename|ssh_config}} on the '''client'''.<br />
<br />
To use the forwarding, log on to your server through ssh:<br />
# ssh -X -p port user@server-address<br />
If you receive errors trying to run graphical applications try trusted forwarding instead:<br />
# ssh -Y -p port user@server-address<br />
You can now start any X program on the remote server, the output will be forwarded to your local session:<br />
# xclock<br />
<br />
== Speed up SSH ==<br />
Changing the ciphers used by SSH to less cpu-demanding ones can improve speed. In this aspect, the best choices are arcfour and blowfish-cbc. To use them, run SSH with the {{Codeline|"c"}} flag, like this:<br />
# ssh -c arcfour,blowfish-cbc user@server-address<br />
To use them permanently, add this line under the proper host in /etc/ssh/ssh_config:<br />
Ciphers arcfour,blowfish-cbc<br />
Another option to improve speed is to enable compression with the {{Codeline|"C"}} flag. A permanent solution is to add this line under the proper host in /etc/ssh/ssh_config:<br />
Compression yes<br />
Login time can be shorten by using the {{Codeline|"4"}} flag, which bypasses IPv6 lookup. This can be made permanent by adding this line under the proper host in /etc/ssh/ssh_config:<br />
AddressFamily inet<br />
Another way of making these changes permanent is to create an alias in ~/.bashrc:<br />
alias ssh='ssh -C4c arcfour,blowfish-cbc'<br />
Finally, you can make all sessions to the same host use a single connection, which will greatly speed up subsecent logins, by adding those line under the proper host in /etc/ssh/ssh_config:<br />
ControlMaster auto<br />
ControlPath ~/.ssh/socket-%r@%h:%p<br />
<br />
=== Trouble Shooting ===<br />
<br />
make sure your DISPLAY string is resolveable on the remote end:<br />
<br />
ssh -X user@server-address<br />
server$ echo $DISPLAY<br />
localhost:10.0<br />
server$ telnet localhost 6010<br />
localhost/6010: lookup failure: Temporary failure in name resolution <br />
<br />
can be fixed by adding localhost to /etc/hosts<br />
<br />
== Mounting a Remote Filesystem with SSHFS ==<br />
<br />
Install sshfs<br />
# pacman -S sshfs<br />
<br />
Load the Fuse module<br />
# modprobe fuse<br />
Add fuse to the ''modules'' array in {{Filename|/etc/rc.conf}} to load it on each system boot.<br />
<br />
Mount the remote folder using sshfs<br />
# mkdir ~/remote_folder<br />
# sshfs USER@remote_server:/tmp ~/remote_folder<br />
<br />
The command above will cause the folder /tmp on the remote server to be mounted as ~/remote_folder on the local machine. Copying any file to this folder will result in transparent copying over the network using SFTP. Same concerns direct file editing, creating or removing.<br />
<br />
When we’re done working with the remote filesystem, we can unmount the remote folder by issuing:<br />
# fusermount -u ~/remote_folder<br />
<br />
If we work on this folder on a daily basis, it is wise to add it to the {{Filename|/etc/fstab}} table. This way is can be automatically mounted upon system boot or mounted manually (if {{Codeline|noauto}} option is chosen) without the need to specify the remote location each time. Here is a sample entry in the table:<br />
sshfs#USER@remote_server:/tmp /full/path/to/directory fuse defaults,auto 0 0<br />
<br />
=== Keep Alive ===<br />
<br />
Your ssh session will automatically log out if it is idle. To keep the connection active (alive) add this to '''~/.ssh/config''' or to '''/etc/ssh/ssh_config''' on the client.<br />
<br />
ServerAliveInterval 5<br />
<br />
This will send a "keep alive" signal to the server every 5 seconds. You can usually increase this interval, and I use 120.<br />
<br />
= Links & References =<br />
*[http://www.soloport.com/iptables.html A Cure for the Common SSH Login Attack]<br />
*[[Using SSH Keys]]<br />
*[http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks]</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=95085Improving performance2010-02-05T04:38:49Z<p>Rttommy: /* Application-specific tips */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See: [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See: [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See: [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see: [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This can be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
<br />
===Speeding up DNS===<br />
By tuning DNS querying, you can noticeably speed up web browsing. See: [[Speeding up DNS with dnsmasq]] or [[Pdnsd]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in /etc/X11/xorg.conf. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to ~/.xinitrc. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See: [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See: [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See: [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See: [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=95084Improving performance2010-02-05T04:37:58Z<p>Rttommy: /* Application-specific tips */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See: [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See: [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See: [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see: [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This can be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
<br />
===Speeding up DNS===<br />
By tuning DNS querying, you can noticeably speed up web browsing. See: [[Speeding up DNS with dnsmasq]] or [[Pdnsd]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in /etc/X11/xorg.conf. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to ~/.xinitrc. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See: [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===Pacman===<br />
See: [[Improve Pacman Performance]].<br />
<br />
===OpenOffice===<br />
See: [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===SSH===<br />
See: [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=95083Improving performance2010-02-05T04:37:35Z<p>Rttommy: /* Application-specific tips */ Added SSH</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See: [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See: [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See: [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see: [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This can be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
<br />
===Speeding up DNS===<br />
By tuning DNS querying, you can noticeably speed up web browsing. See: [[Speeding up DNS with dnsmasq]] or [[Pdnsd]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in /etc/X11/xorg.conf. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to ~/.xinitrc. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See: [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===penOffice<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===Pacman===<br />
See: [[Improve Pacman Performance]].<br />
<br />
===OpenOffice===<br />
See: [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===SSH===<br />
See: [[SSH#Speed up SSH|Speed up SSH]].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=OpenSSH&diff=95082OpenSSH2010-02-05T04:35:51Z<p>Rttommy: /* Tips and Tricks */ Added speed up tips</p>
<hr />
<div>[[Category:Daemons_and_system_services (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|SSH}}<br />
{{i18n_entry|Italiano|SSH_(Italiano)}}<br />
{{i18n_entry|Русский|SSH_(Русский)}}<br />
{{i18n_entry|简体中文|SSH_(简体中文)}}<br />
{{i18n_links_end}}<br />
<br />
= Introduction =<br />
Secure Shell or SSH is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary.<br />
<br />
SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding arbitrary TCP ports and X11 connections; it can transfer files using the associated SFTP or SCP protocols.<br />
<br />
An SSH server, by default, listens on the standard TCP port 22. An ssh client program is typically used for establishing connections to an sshd daemon accepting remote connections. Both are commonly present on most modern operating systems, including Mac OS X, Linux, Solaris and OpenVMS. Proprietary, freeware and open source versions of various levels of complexity and completeness exist.<br />
<br />
= OpenSSH =<br />
<br />
OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the ssh protocol. It was created as an open source alternative to the proprietary Secure Shell software suite offered by SSH Communications Security. OpenSSH is developed as part of the OpenBSD project, which is led by Theo de Raadt.<br />
<br />
OpenSSH is occasionally confused with the similarly-named OpenSSL; however, the projects have different purposes and are developed by different teams, the similar name is drawn only from similar goals.<br />
<br />
== Installing OpenSSH ==<br />
# pacman -S openssh<br />
<br />
== Configuring SSH ==<br />
===Client===<br />
The SSH client configuration file can be found and edited in {{Filename|/etc/ssh/ssh_config}}.<br />
<br />
An example configuration: <br />
<br />
{{File|name=/etc/ssh/ssh_config|content=<br />
<br />
# $OpenBSD: ssh_config,v 1.25 2009/02/17 01:28:32 djm Exp $<br />
<br />
# This is the ssh client system-wide configuration file. See<br />
# ssh_config(5) for more information. This file provides defaults for<br />
# users, and the values can be changed in per-user configuration files<br />
# or on the command line.<br />
<br />
# Configuration data is parsed as follows:<br />
# 1. command line options<br />
# 2. user-specific file<br />
# 3. system-wide file<br />
# Any configuration value is only changed the first time it is set.<br />
# Thus, host-specific definitions should be at the beginning of the<br />
# configuration file, and defaults at the end.<br />
<br />
# Site-wide defaults for some commonly used options. For a comprehensive<br />
# list of available options, their meanings and defaults, please see the<br />
# ssh_config(5) man page.<br />
<br />
Host *<br />
# ForwardAgent no<br />
# ForwardX11 no<br />
# RhostsRSAAuthentication no<br />
# RSAAuthentication yes<br />
# PasswordAuthentication yes<br />
# HostbasedAuthentication no<br />
# GSSAPIAuthentication no<br />
# GSSAPIDelegateCredentials no<br />
# BatchMode no<br />
# CheckHostIP yes<br />
# AddressFamily any<br />
# ConnectTimeout 0<br />
# StrictHostKeyChecking ask<br />
# IdentityFile ~/.ssh/identity<br />
# IdentityFile ~/.ssh/id_rsa<br />
# IdentityFile ~/.ssh/id_dsa<br />
# Port 22<br />
# Protocol 2,1<br />
# Cipher 3des<br />
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc<br />
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160<br />
# EscapeChar ~<br />
# Tunnel no<br />
# TunnelDevice any:any<br />
# PermitLocalCommand no<br />
# VisualHostKey no<br />
HashKnownHosts yes<br />
StrictHostKeyChecking ask}}<br />
<br />
It is recommended to change the Protocol line into this:<br />
Protocol 2<br />
<br />
That means that only Protocol 2 will be used, since Protocol 1 is considered somewhat insecure.<br />
<br />
===Daemon===<br />
The SSH daemon configuration file can be found and edited in {{Filename|/etc/ssh/ssh'''d'''_config}}.<br />
<br />
An example configuration: <br />
<br />
{{File|name=/etc/ssh/sshd_config|content=<br />
<br />
# $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $<br />
<br />
# This is the sshd server system-wide configuration file. See<br />
# sshd_config(5) for more information.<br />
<br />
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin<br />
<br />
# The strategy used for options in the default sshd_config shipped with<br />
# OpenSSH is to specify options with their default value where<br />
# possible, but leave them commented. Uncommented options change a<br />
# default value.<br />
<br />
#Port 22<br />
#Protocol 2,1<br />
ListenAddress 0.0.0.0<br />
#ListenAddress ::<br />
<br />
# HostKey for protocol version 1<br />
#HostKey /etc/ssh/ssh''host''key<br />
# HostKeys for protocol version 2<br />
#HostKey /etc/ssh/ssh''host''rsa_key<br />
#HostKey /etc/ssh/ssh''host''dsa_key<br />
<br />
# Lifetime and size of ephemeral version 1 server key<br />
#KeyRegenerationInterval 1h<br />
#ServerKeyBits 768<br />
<br />
# Logging<br />
#obsoletes ~QuietMode and ~FascistLogging<br />
#SyslogFacility AUTH<br />
#LogLevel INFO<br />
<br />
# Authentication:<br />
<br />
#LoginGraceTime 2m<br />
#PermitRootLogin yes<br />
#StrictModes yes<br />
#MaxAuthTries 6<br />
<br />
#RSAAuthentication yes<br />
#PubkeyAuthentication yes<br />
#AuthorizedKeysFile .ssh/authorized_keys<br />
<br />
# For this to work you will also need host keys in /etc/ssh/ssh''known''hosts<br />
#RhostsRSAAuthentication no<br />
# similar for protocol version 2<br />
#HostbasedAuthentication no<br />
# Change to yes if you don't trust ~/.ssh/known_hosts for<br />
# RhostsRSAAuthentication and HostbasedAuthentication<br />
#IgnoreUserKnownHosts no<br />
# Don't read the user's ~/.rhosts and ~/.shosts files<br />
#IgnoreRhosts yes<br />
<br />
# To disable tunneled clear text passwords, change to no here!<br />
#PasswordAuthentication yes<br />
#PermitEmptyPasswords no<br />
<br />
# Change to no to disable s/key passwords<br />
#ChallengeResponseAuthentication yes<br />
<br />
# Kerberos options<br />
#KerberosAuthentication no<br />
#KerberosOrLocalPasswd yes<br />
#KerberosTicketCleanup yes<br />
#KerberosGetAFSToken no<br />
<br />
# GSSAPI options<br />
#GSSAPIAuthentication no<br />
#GSSAPICleanupCredentials yes<br />
<br />
# Set this to 'yes' to enable PAM authentication, account processing,<br />
# and session processing. If this is enabled, PAM authentication will<br />
# be allowed through the ~ChallengeResponseAuthentication mechanism.<br />
# Depending on your PAM configuration, this may bypass the setting of<br />
# PasswordAuthentication, ~PermitEmptyPasswords, and<br />
# "PermitRootLogin without-password". If you just want the PAM account and<br />
# session checks to run without PAM authentication, then enable this but set<br />
# ChallengeResponseAuthentication=no<br />
#UsePAM no<br />
<br />
#AllowTcpForwarding yes<br />
#GatewayPorts no<br />
#X11Forwarding no<br />
#X11DisplayOffset 10<br />
#X11UseLocalhost yes<br />
#PrintMotd yes<br />
#PrintLastLog yes<br />
#TCPKeepAlive yes<br />
#UseLogin no<br />
#UsePrivilegeSeparation yes<br />
#PermitUserEnvironment no<br />
#Compression yes<br />
#ClientAliveInterval 0<br />
#ClientAliveCountMax 3<br />
#UseDNS yes<br />
#PidFile /var/run/sshd.pid<br />
#MaxStartups 10<br />
<br />
# no default banner path<br />
#Banner /some/path<br />
<br />
# override default of no subsystems<br />
Subsystem sftp /usr/lib/ssh/sftp-server}}<br />
<br />
<br />
To allow access only for some users add this line:<br />
AllowUsers user1 user2<br />
<br />
You might want to change some lines so that they look as following:<br />
<pre><br />
Protocol 2<br />
.<br />
.<br />
.<br />
LoginGraceTime 120<br />
.<br />
.<br />
.<br />
PermitRootLogin no # (put yes here if you want root login)<br />
</pre><br />
<br />
You could also uncomment the BANNER option and edit {{Filename|/etc/issue}} for a nice welcome message.<br />
<br />
{{Tip| You may want to change the default port from 22 to any higher port (see [http://en.wikipedia.org/wiki/Security_through_obscurity security through obscurity]).}} <br />
<br />
Even though the port ssh is running on could be detected by using a port-scanner like nmap, changing it will reduce the number of log entries caused by automated authentication attempts.<br />
===Allowing others in===<br />
{{Box Note | You have to adjust this file to remotely connect to your machine since the file is empty by default}}<br />
<br />
To let other people ssh to your machine you need to adjust {{Filename|/etc/hosts.allow}}, add the following:<br />
<br />
<pre><br />
# let everyone connect to you<br />
sshd: ALL<br />
<br />
# OR you can restrict it to a certain ip<br />
sshd: 192.168.0.1<br />
<br />
# OR restrict for an IP range<br />
sshd: 10.0.0.0/255.255.255.0<br />
<br />
# OR restrict for an IP match<br />
sshd: 192.168.1.<br />
</pre><br />
<br />
Now you should check your {{Filename|/etc/hosts.deny}} for the following line and make sure it looks like this:<br />
ALL: ALL: DENY<br />
<br />
That's it. You can SSH out and others should be able to SSH in :).<br />
<br />
To start using the new configuration, restart the daemon (as root):<br />
# /etc/rc.d/sshd restart<br />
<br />
== Managing SSHD Daemon ==<br />
Just add sshd to the "DAEMONS" section of your {{Filename|/etc/[[rc.conf]]}}:<br />
DAEMONS=(... ... '''sshd''' ... ...)<br />
<br />
To start/restart/stop the daemon, use the following:<br />
# /etc/rc.d/sshd {start|stop|restart}<br />
<br />
==Connecting to the server==<br />
To connect to a server, run:<br />
$ ssh -p port user@server-address<br />
<br />
= Tips and Tricks =<br />
<br />
== Encrypted Socks Tunnel ==<br />
This is highly useful for laptop users connected to various unsafe wireless connections. The only thing you need is an SSH server running at a somewhat secure location, like your home or at work. It might be useful to use a dynamic DNS service like [http://www.dyndns.org/ DynDNS] so you don't have to remember your IP-address.<br />
<br />
=== Step 1: Start the Connection ===<br />
You only have to execute this single command in your favorite terminal to start the connection:<br />
$ ssh -ND 4711 user@host<br />
where {{Codeline|"user"}} is your username at the SSH server running at the {{Codeline|"host"}}. It will ask for your password, and then you're connected! The {{Codeline|"N"}} flag disables the interactive prompt, and the {{Codeline|"D"}} flag specifies the local port on wich to listen on (you can choose any port number if you want).<br />
<br />
One way to make this easier is to put an alias line in your {{Filename|~/.bashrc}} file as following:<br />
alias sshtunnel="ssh -ND 4711 -v user@host"<br />
It's nice to add the verbose {{Codeline|"-v"}} flag, because then you can verify that it's actually connected from that output. Now you just have to execute the {{Codeline|"sshtunnel"}} command :)<br />
<br />
=== Step 2: Configure your Browser (or other programs) ===<br />
<br />
The above step is completely useless if you don't configure your web browser (or other programs) to use this newly created socks tunnel. <br />
<br />
* For Firefox: ''Edit &rarr; Preferences &rarr; Advanced &rarr; Network &rarr; Connection &rarr; Setting'':<br />
: Check the ''"Manual proxy configuration"'' radio button, and enter "localhost" in the ''"SOCKS host"'' text field, and then enter your port number in the next text field (I used 4711 above).<br />
<br />
: Make sure you select SOCKS4 as the protocol to use. This procedure will not work for SOCKS5.<br />
<br />
Enjoy your secure tunnel!<br />
<br />
== X11 Forwarding ==<br />
<br />
To run graphical programs through a SSH connection you can enable X11 forwarding. An option needs to be set in the configuration files on the server and client.<br />
<br />
Install xorg-xauth on the server:<br />
# pacman -S xorg-xauth<br />
<br />
* Enable the '''AllowTcpForwarding''' option in {{Filename|sshd_config}} on the '''server'''.<br />
* Enable the '''X11Forwarding''' option in {{Filename|sshd_config}} on the '''server'''.<br />
* Set the '''X11DisplayOffset''' option in {{Filename|sshd_config}} on the '''server''' to 10.<br />
* Enable the '''X11UseLocalhost''' option in {{Filename|sshd_config}} on the '''server'''.<br />
<br />
<br />
* Enable the '''ForwardX11''' option in {{Filename|ssh_config}} on the '''client'''.<br />
<br />
To use the forwarding, log on to your server through ssh:<br />
# ssh -X -p port user@server-address<br />
If you receive errors trying to run graphical applications try trusted forwarding instead:<br />
# ssh -Y -p port user@server-address<br />
You can now start any X program on the remote server, the output will be forwarded to your local session:<br />
# xclock<br />
<br />
== Speed up SSH ==<br />
Changing the ciphers used by SSH to less cpu-demanding ones can improve speed. In this aspect, the best choices are arcfour and blowfish-cbc. To use them, run SSH with the -c option, like this:<br />
# ssh -c arcfour,blowfish-cbc user@server-address<br />
To use them permanently, add this line under the proper host in /etc/ssh/ssh_config:<br />
Ciphers arcfour,blowfish-cbc<br />
Another option to improve speed is to enable compression with the -C flag. A permanent solution is to add this line under the proper host in /etc/ssh/ssh_config:<br />
Compression yes<br />
Login time can be shorten by using the -4 flag, which bypasses IPv6 lookup. This can be made permanent by adding this line under the proper host in /etc/ssh/ssh_config:<br />
AddressFamily inet<br />
Another way of making these changes permanent is to create an alias in ~/.bashrc:<br />
alias ssh='ssh -C4c arcfour,blowfish-cbc'<br />
Finally, you can make all sessions to the same host use a single connection, which will greatly speed up subsecent logins, by adding those line under the proper host in /etc/ssh/ssh_config:<br />
ControlMaster auto<br />
ControlPath ~/.ssh/socket-%r@%h:%p<br />
<br />
=== Trouble Shooting ===<br />
<br />
make sure your DISPLAY string is resolveable on the remote end:<br />
<br />
ssh -X user@server-address<br />
server$ echo $DISPLAY<br />
localhost:10.0<br />
server$ telnet localhost 6010<br />
localhost/6010: lookup failure: Temporary failure in name resolution <br />
<br />
can be fixed by adding localhost to /etc/hosts<br />
<br />
== Mounting a Remote Filesystem with SSHFS ==<br />
<br />
Install sshfs<br />
# pacman -S sshfs<br />
<br />
Load the Fuse module<br />
# modprobe fuse<br />
Add fuse to the ''modules'' array in {{Filename|/etc/rc.conf}} to load it on each system boot.<br />
<br />
Mount the remote folder using sshfs<br />
# mkdir ~/remote_folder<br />
# sshfs USER@remote_server:/tmp ~/remote_folder<br />
<br />
The command above will cause the folder /tmp on the remote server to be mounted as ~/remote_folder on the local machine. Copying any file to this folder will result in transparent copying over the network using SFTP. Same concerns direct file editing, creating or removing.<br />
<br />
When we’re done working with the remote filesystem, we can unmount the remote folder by issuing:<br />
# fusermount -u ~/remote_folder<br />
<br />
If we work on this folder on a daily basis, it is wise to add it to the {{Filename|/etc/fstab}} table. This way is can be automatically mounted upon system boot or mounted manually (if {{Codeline|noauto}} option is chosen) without the need to specify the remote location each time. Here is a sample entry in the table:<br />
sshfs#USER@remote_server:/tmp /full/path/to/directory fuse defaults,auto 0 0<br />
<br />
=== Keep Alive ===<br />
<br />
Your ssh session will automatically log out if it is idle. To keep the connection active (alive) add this to '''~/.ssh/config''' or to '''/etc/ssh/ssh_config''' on the client.<br />
<br />
ServerAliveInterval 5<br />
<br />
This will send a "keep alive" signal to the server every 5 seconds. You can usually increase this interval, and I use 120.<br />
<br />
= Links & References =<br />
*[http://www.soloport.com/iptables.html A Cure for the Common SSH Login Attack]<br />
*[[Using SSH Keys]]<br />
*[http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks]</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=94860Improving performance2010-02-02T20:00:32Z<p>Rttommy: /* Compcache */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See: [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See: [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See: [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see: [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This can be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
<br />
===Speeding up DNS===<br />
By tuning DNS querying, you can noticeably speed up web browsing. See: [[Speeding up DNS with dnsmasq]] or [[Pdnsd]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in /etc/X11/xorg.conf. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to ~/.xinitrc. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See: [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
<br />
===Pacman===<br />
See: [[Improve Pacman Performance]].<br />
<br />
===OpenOffice===<br />
See: [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=94858Improving performance2010-02-02T19:48:20Z<p>Rttommy: Added reiserfs and JFS, added summary, removed info redundant with beginner's guide</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See: [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance varies from release to release, but speed seems to be good. Still considered as unstable.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See: [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See: [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see: [[Defragmentation XFS]].<br />
<br />
====Reiserfs====<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option inscreases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This can be done when creating the filesystem: <br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data.<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
<br />
===Speeding up DNS===<br />
By tuning DNS querying, you can noticeably speed up web browsing. See: [[Speeding up DNS with dnsmasq]] or [[Pdnsd]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in /etc/X11/xorg.conf. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to ~/.xinitrc. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that allow you put your swap into your RAM and compress it. That means that part of your RAM can hold much more information, at the cost of a little more CPU usage, and is still much quicker than a hard drive swap. If your system falls back to swap every now and then, this can help make your system more responsive. Simply install [http://aur.archlinux.org/packages.php?ID=19248 compcache] from AUR after each kernel upgrade and add it to the DAEMONS array. Your can also tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See: [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
<br />
===Pacman===<br />
See: [[Improve Pacman Performance]].<br />
<br />
===OpenOffice===<br />
See: [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=JFS&diff=94854JFS2010-02-02T19:38:29Z<p>Rttommy: /* Optimizations */</p>
<hr />
<div>[[Category:File systems (English)]]<br />
This article introduces the reader to the JFS file system. In particular, procedures for implementation, maintenance and optimization will be presented along with background information on the file system itself and some cautionary notes on precarious implementations.<br />
<br />
= Background =<br />
The Journaled File System (JFS) is a [http://en.wikipedia.org/wiki/Journaling_file_system journaling file system] that was open-sourced by IBM in 1999 and support for which has been available in the Linux kernel since 2002. <br />
<br />
* In 1990, JFS1, (then simply called JFS), was released for AIX version 3.1. The filesystem was closely tied to its targeted hardware, IBM's AIX line of UNIX servers, being a proprietary design. <br />
* In 1995, heavy development began on improving JFS, focusing on scalability and expanded features. <br />
* In 1997, parallel development began on moving the improved JFS source back to AIX. <br />
* In 1999, the improved JFS design was released for OS/2.<br />
* In 2001, the improved filesystem (newly termed JFS2), was released for AIX 5L. <br />
* The current Linux version is a port based on JFS for OS/2.<br />
<br />
'''NOTE:''' While there are potential issues, JFS file systems for OS/2 and GNU/Linux are inter-operable.[http://72.14.253.104/search?q=cache:xrFItCW2XdUJ:osdir.com/ml/file-systems.jfs.general/2006-02/msg00008.html+jfs+os/2+linux&hl=en&ct=clnk&cd=1&gl=au&client=firefox-a]<br />
<br />
While it is difficult to make general comparisons between JFS and other file systems available on UNIX and UNIX-like operating systems, it is claimed that JFS uses less CPU resources than other GNU/Linux file systems [http://www.debian-administration.org/articles/388]. With certain optimizations, JFS has also been claimed to be faster for certain file operations, as compared to other GNU/Linux file systems (see [http://www.redhat.com/archives/ext3-users/2005-July/msg00018.html],[[JFS_Filesystem#Benchmarks|Benchmarks]]). <br />
<br />
== Linux Development Team ==<br />
The development of the GNU/Linux JFS port is headed by the JFS core team (all currently at IBM)[http://jfs.sourceforge.net/]:<br />
* Dave Kleikamp (shaggy at austin dot ibm dot com)<br />
* Dave Blaschke (blaschke at us dot ibm dot com)<br />
* Steve Best (sbest at us dot ibm dot com)<br />
* Barry Arndt (barndt at us dot ibm dot com)<br />
<br />
== Technical features ==<br />
JFS is a modern file system supporting many features, a few of which are listed here.<br />
* fully 64-bit<br />
* dynamic space allocation for i-nodes, i.e. no running out of i-nodes on file systems with large number of small files<br />
* Directory structures designed for speed and efficiency:<br />
:- directories with eight or fewer entries have their contents storied inline within that directory's i-node.<br />
:- directories with more than eight entries have their contents stored in a [http://en.wikipedia.org/wiki/B%2B_tree B+ tree] keyed on name.<br />
* JFS utilizes extents for allocating blocks for large files.<br />
* Support for extended attributes in additions to standard Unix-style permissions.<br />
* Support for both internal and external logs ([[JFS_Filesystem#External_Journal|see below]])<br />
* Extremely Scalable; Consistent performance from minimum file size up to 4 petabytes.<br />
* Algorithms designed for high performance on very large systems<br />
* Performance tuned for GNU/Linux<br />
* Designed from the ground up to provide Transaction/Log (not an add-on)<br />
* Restarts after a system failure < 1 sec<br />
* Proven Journaling FS technology (10+ years in AIX)<br />
* Original design goals: Performance, Robustness, SMP<br />
* Team members from the original AIX JFS Designed/Developed this File System<br />
* Designed to operate on SMP hardware, with code optimized for at least an 4-way SMP machine<br />
<br />
'''NOTE:''' JFS uses a journal to maintain consistency of metadata ''only''. Thus, only consistency of metadata (and not actual file contents) can be assured in the case of improper shutdown. This is also the case for XFS and ReiserFS. Ext3, on the other hand, does support journaling of ''both'' metadata and data [http://www.upgrade-cepis.org/issues/2001/6/up2-6Galli.pdf], though with a significant performance penalty, and not by default.<br />
<br />
A more comprehensive (and technical) overview of the features in JFS can be found in the [http://www.ibm.com/developerworks/library/l-jfs.html JFS Overview] authored by developer Steve Best.<br />
<br />
= Implementing on GNU/Linux = <br />
Implementing a JFS file system is just like implementing most other file systems under GNU/Linux. JFS was merged into the Linux kernel as of version 2.4 [http://kerneltrap.org/node/385]. The JFS driver is built as a module in the standard Arch kernel packages. If building a custom kernel on a machine that will be (or does) use JFS file systems, be sure to enable JFS in your kernel config:<br />
<br />
File systems<br />
---> [*/M] JFS filesystem support<br />
<br />
If extended attributes are desired, one will also need to enable "JFS POSIX Access Control Lists" and/or "JFS Security Labels"<br />
<br />
File systems<br />
---> [*/M] JFS filesystem support <br />
---> [*] JFS POSIX Access Control Lists<br />
---> [*] JFS Security Labels<br />
<br />
<br />
Next, the JFS utilities package will be needed to perform all file system related tasks:<br />
<br />
pacman -S jfsutils<br />
<br />
Actual creation of a JFS file system can be done with the either <br />
<br />
mkfs.jfs /dev/target_dev<br />
<br />
or <br />
<br />
jfs_mkfs /dev/target_dev<br />
<br />
Both commands are equivalent.<br />
<br />
= Optimizations =<br />
There are several concepts that can be implemented with a JFS filesystem to boost its performance:<br />
* periodic defragmentation of the file system<br />
* using the deadline I/O scheduler<br />
* utilizing an external journal<br />
* attaching the ''noatime'' attribute the the file system in ''/etc/fstab''<br />
<br />
== Defragmenting JFS ==<br />
JFS, like all file systems, will degrade in performance over time due to file fragmentation [http://docs.hp.com/en/5576/JFS_Tuning.pdf]. While there is in-place defragmentation code in the JFS utilities, this is code held over from the OS/2 port and has yet to be implemented [http://www.mail-archive.com/jfs-discussion@lists.sourceforge.net/msg00573.html]. For file systems that can be taken off-line for a time, one can execute a script like the following to defragment their JFS file system<br />
<br />
'''WARNING:''' This script is ''dangerous'' and may result in the wiping of an entire hard disk, if arguments get switched! Doing this type of operation is only recommended for people who have confidence in doing backups and file system operations.<br />
<br />
umount /dev/hdc1<br />
dd bs=4k if=/dev/hdc1 of=/dev/hdj1<br />
jfs_fsck /dev/hdj1<br />
mount -o ro /dev/hdj1 /fs/hdj1<br />
jfs_mkfs /dev/hdc1<br />
mount -o rw /dev/hdc1 /fs/hdc1<br />
(cd /fs/hdj1 && tar -cS -b8 --one -f - .) | (cd /fs/hdc1 && tar -xS -b8 -p -f -)<br />
umount /dev/hdj1<br />
<br />
In this example, ''/dev/hdc1'' is the device with the data that needs backing up and ''/dev/hdj1'' is the device that holds the backup. <br />
<br />
Basically, this script copies the data off the JFS file system to a backup drive, formats the original JFS file system and finally writes back the data from the backup to the freshly formatted drive in a way that JFS will write its allocation trees in a defragmentated way.<br />
<br />
'''WARNING:''' If a VMWare session is sitting on an underlying JFS partition that is highly fragmented, performance of the virtual machine may be significantly degraded.<br />
<br />
== Deadline I/O Scheduler==<br />
JFS seems to perform better when the kernel has been configured to use the ''Deadline I/O Scheduler''. Indeed, JFS's performance seems to exceed that of other GNU/Linux file systems with this particular scheduler being employed [http://www.redhat.com/archives/ext3-users/2005-July/msg00018.html]. There are several ways to utilize this scheduler. One is to recompile with the Deadline I/O scheduler set to the default:<br />
<br />
Block layer<br />
---> I/O Schedulers<br />
---> [*] Deadline I/O scheduler<br />
---> Default I/O scheduler (Deadline) ---><br />
<br />
If you are using a generic Arch package for your kernel, you can simply append ''elevator=deadline'' to the kernel line in your ''/boot/grub/menu.lst'' The kernel entry would look something like:<br />
<br />
# (0) Arch 2.6.22<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 elevator=deadline<br />
initrd /kernel26.img<br />
<br />
It is also possible to enable the Deadline I/O scheduler for specific devices by invoking the following command:<br />
<br />
echo deadline > /sys/block/sda/queue/scheduler <br />
<br />
This sets the Deadline scheduler as the default for /dev/sda (the entire physical device).<br />
<br />
== External Journal ==<br />
'''WARNING:''' As this is a relatively new feature to the GNU/Linux port of JFS, it is recommended to upgrade to the very latest version of jfsutils before attempting to implement an external journal (earlier versions seem to give errors when trying to create the journal device).<br />
<br />
As with any journaled file system, a journal is constantly accessed in accordance with disk activity. Having the journal log on the same device as the its corresponding file system thus can cause a degradation in I/O through put. This degradation can be alleviated by putting the journal log on a separate device all together. <br />
<br />
To make a journal device, first create a partition that is 128MB. Using a partition that is bigger than 128MB results in the excess being ignored, according to mkfs.jfs. You can either create an external log for an already-existing JFS file system by executing the following:<br />
<br />
mkfs.jfs -J journal_dev /dev/external_journal # creates a journal on device /dev/external_journal<br />
mkfs.jfs -J device=/dev/external_journal /dev/jfs_device # attaches the external journal to the existing file <br />
# system on /dev/jfs_device<br />
<br />
or a command can be issued to create both a new external journal and its corresponding JFS file system:<br />
<br />
mkfs.jfs -j /dev/external_journal /dev/jfs_device<br />
<br />
This last command formats BOTH the external journal and the JFS file system.<br />
<br />
'''NOTE:''' Obviously, an external journal is only effective if the journal and its file system exists on separate ''physical'' devices.<br />
<br />
==''noatime'' fstab attribute ==<br />
Every time a file is accessed (read or write) the default for most file systems is to append the metadata associated with that file with an updated access time. Thus, even read operations incur an overhead associated with a write to the file system. This can lead to a significant degradation in performance in some usage scenarios. Appending ''noatime'' to the fstab line for a JFS file system stops this action from happening. As access time is of little importance in most scenarios, this alteration has been widely touted as a fast and easy way to get a performance boost out of one's hardware. Even Linus Torvalds seems to be a proponent of this optimization [http://kerneltrap.org/node/14148].<br />
<br />
'''NOTE:''' One may also specify a ''relatime'' option which updates the atime if the previous atime is older than the mtime or ctime [http://kerneltrap.org/node/14148]. In terms of performance, this will not be as fast as the ''noatime'' mount option, but is useful if using applications that need to know when files were last read (like ''mutt'').<br />
<br />
'''NOTE:''' Using the ''noatime''/''relatime'' option can improve disk performance with any file system, not just JFS.<br />
<br />
Here is an example ''/etc/fstab'' entry with the ''noatime'' tag<br />
<br />
/dev/sdb1 /media/backup jfs rw,users,noauto,noatime 0 0<br />
<br />
One may also mount a file system with the ''noatime'' attribute by invoking something similar to the following:<br />
<br />
mount -o noatime -t jfs /dev/jfs_dev /mnt/jfs_fs<br />
<br />
'''NOTE:''' Access time is NOT the same as the ''last-modified'' time. Disabling access time will still enable you to see when files were last modified by a write operation.<br />
<br />
==Journal Modes==<br />
JFS does not support various journal modes like Ext3. Thus, passing the mount option ''data=writeback'' with ''mount'' or in ''/etc/fstab'' will have no effect on a JFS file system. JFS's current journaling mode is similar to Ext3's default journaling mode: ''ordered'' [http://www.ibm.com/developerworks/linux/linux390/perf/tuning_res_journaling.html].<br />
<br />
==Variable block sizes==<br />
While the OS/2 port of JFS supports block sizes of 512, 1024, 2048, and 4096 bytes, the Linux port of JFS is only able to use 4k blocks. Even though code exists in JFS utilities that correspond to file systems using variable size blocks, this has yet to be implemented [http://osdir.com/ml/file-systems.jfs.general/2003-02/msg00017.html]. As larger block sizes tend to favor performance (smaller ones favor efficient space usage), implementing smaller block sizes for JFS in Linux has been given a low priority for implementation by JFS developers.<br />
<br />
=fsck and recovery=<br />
In the event that the file system does not get properly unmounted before being powered down, one will usually have to run ''fsck'' on a JFS file system in order to be able to remount it. This procedure usually only takes a few seconds, unless the log has been damaged. If running fsck returns an unrecognized file system error, try running ''fsck.jfs'' on the target device. Normally, ''fsck'' is all that is needed.<br />
<br />
If the superblock on your file system gets destroyed, it may be possible to recover some parts of the file system. Currently, the only tool able to do this is a utility called 'jfsrec'. JFSrec is currently available from the AUR and can be installed by using a client such as ''yaourt'' and running the command:<br />
<br />
yaourt -S jfsrec-svn<br />
<br />
There is also an AUR package called ''jfsrec'', but this is merely a placeholder for ''jfsrec-svn'' as JFSrec is currently only in its seventh SVN revision. Once installed, one simply need to type:<br />
<br />
jfsrec<br />
<br />
to get a help menu explaining how to use this utility. <br />
<br />
'''WARNING:''' As stated above, JFSrec is only in its seventh SVN revision; and it is not known how actively the project is maintained. So use JFSrec with caution.<br />
<br />
=Cautionary Notes=<br />
While JFS is very stable in its current stage of development, there are some cautionary notes on using this file system.<br />
<br />
<br />
<br />
==JFS root mounts read only on startup==<br />
Occasionally, a JFS root partition will be unable to mount in normal read-write mode. This is usually due to the fact that the JFS root file system fails it's fsck after an unclean shutdown. It is rare that JFS fails out of fsck, and it's usually due to the JFS log itself being corrupted.<br />
<br />
All that is required in this scenario is to boot your machine with a relatively recent Arch Linux LiveCD. Booting an Arch Linux livecd will give you access to all the JFS utilities and will load a kernel that is able to recognize JFS file systems. After booting the CD simply run ''fsck'' (or possibly ''fsck.jfs'') on your JFS root and it should recover just fine (even though the fsck will probably take longer than normal due to the log probably being damaged). Once the ''fsck'' finishes, you should be able to boot your machine like normal.<br />
<br />
'''NOTE:''' This scenario happens less than 10% of the time in the case of an improper shutdown.<br />
<br />
==JFS and secure deletions==<br />
<br />
'''NOTE:''' This section applies to any journaled file system, not just JFS.<br />
<br />
The effectiveness of deleting files by overwriting their corresponding file system blocks with random data (i.e. using utilities like ''shred'') can not be assured [http://lists.kde.org/?l=kfm-devel&m=105770965822522&w=2]. Given the design of journaled file systems, maintenance issues, and performance liabilities; reliable shredding of files as a deletion method does not sit highly on the priority list for implementation on any journaled file system.<br />
<br />
==Forced fsck on JFS root file system==<br />
One may force a fsck file system check on the root file system by entering:<br />
touch /forcefsck<br />
and rebooting. On Arch linux systems with a JFS root on a partition under control of ''device-mapper'' (i.e. the root device is a ''lvm'' or a LUKS encrypted one), forcing an fsck can sometimes remove the ''/usr/man/man3'' directory. The reason for this issue is not clear, but the problem has been able to be replicated [http://bbs.archlinux.org/viewtopic.php?id=41261]. <br />
<br />
It is suggested to get a list of Arch Packages that use ''/usr/man/man3'' by issuing a command similar to<br />
find /var/lib/pacman/local/ -name files | xargs fgrep /man/man3/ | cut -d: -f1 | sort -u | awk -F/ '{print $6}' > man3_pkg_list<br />
before attempting a forced fsck on a JFS root partition ([http://bbs.archlinux.org/viewtopic.php?id=41261] post #1). If ''/usr/man/man3'' does indeed disappear, simply reinstall all the packages listed in ''man3_pkg_list''.<br />
<br />
'''NOTE:''' If this problem does indeed happen, reinstalling all the packages using ''/usr/man/man3'' does appear to fix the issue ([http://bbs.archlinux.org/viewtopic.php?id=41261] post #4).<br />
<br />
As stated above, the reason for this issue isn't clear at the moment; but it may have something to do with the fact that a forced fsck runs through higher phases of file system checks that only happen when a JFS log gets damaged in an improper dismounting of the partition.<br />
<br />
==JFS losing files==<br />
In JFS; journal writes are indefinitely postponed until there is another trigger such as memory pressure or an unmount operation. This infinite write delay limits reliability, as a crash can result in data loss even for data that was written minutes or hours before.[https://www.usenix.org/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf]<br />
<br />
=Benchmarks=<br />
As benchmarks measuring file system performance tend to be focused at specific types of disk usage, it is difficult to decipher good general comparisons rating how well JFS performs against other files systems. As mentioned before, it has been noted that JFS has a tendency to use less CPU resources than other GNU/Linux file systems and (with the right optimizations) is faster than other GNU/Linux file systems for certain types of file operations. In the references are some links to benchmarks; but as always, it is best to test and see what works best for your own system and work load.<br />
<br />
=Conclusions=<br />
JFS is a stable, feature-rich file system that hasn't been publicized as much as some of the other Linux file systems. With optimizations, JFS is stable, CPU efficient and fast. In particular, VMWare sessions stand to benefit enormously from a properly optimized and defragmented, underlying JFS file system.<br />
<br />
= References =<br />
*A more technical [http://www.ibm.com/developerworks/library/l-jfs.html overview] of JFS<br />
*[http://www.linux.com/feature/119025 30 days with JFS]<br />
*JFS [http://jfs.sourceforge.net/ Sourceforge] page<br />
*Note on [http://www.sabi.co.uk/blog/anno06-2nd.html#060422b defragmenting] JFS file systems<br />
*JFS Recovery [http://sourceforge.net/projects/jfsrec Sourceforge] page<br />
*A [http://www.perl.org/tpc/2002/sessions/best_steve.pdf presentation] on JFS given by Steve Best (pdf)<br />
*[http://www.debian-administration.org/articles/388 Debian file system comparison]</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=94853Improving performance2010-02-02T19:08:00Z<p>Rttommy: Added rough guidelines for filesystems</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See: [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. You can find articles about each of them [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
Usually the default file-system in Linux, ext3 is known for its stability, and has been tested and improved since a decade. However, it is not very fast, and if speed is your priority, you should consider another one. A factor to consider is that a [http://www.fs-driver.org/ driver for Windows] exists, and you can therefore access your partition from any Windows installation. For performance tips, see: [[Ext3 Filesystem Tips]].<br />
<br />
====Ext4====<br />
The [[Ext4]] file-system is relatively new, and is basically an overall improvement over ext3, and that includes speed. It is also the new default for archlinux. Probably the best choice if stability is very important to you.<br />
<br />
====XFS====<br />
XFS offers excellent performance on large files and file-systems. In contrast, its average speed when dealing with large numbers of small files is poor. Therefore, if you choose Xfs, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. Xfs offers [[Defragmentation XFS|on-line defragmentation]] and mounts quickly.<br />
<br />
For optimal speed, create an XFS file-system with:<br />
mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}.<br />
<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
====Summary====<br />
This is a very rough, probably controvertial summary of the main characteristics of each filesystem, considering an average desktop usage. Please take these lightly.<br />
*XFS: Excellent speed with average and large files. Low speed with small ones.<br />
*Reiserfs: Excellent speed, mainly small files.<br />
*Ext3: Average speed, stability, can be accessed from windows.<br />
*Ext4: Good speed, stability.<br />
*JFS: Good speed, low CPU usage.<br />
*Btrfs: Performance still varies from release to release, but speed seems to be good. Stability is undertermined.<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
<br />
===Speeding up DNS===<br />
By tuning DNS querying, you can noticeably speed up web browsing. See: [[Speeding up DNS with dnsmasq]] or [[Pdnsd]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in /etc/X11/xorg.conf. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to ~/.xinitrc. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that allow you put your swap into your RAM and compress it. That means that part of your RAM can hold much more information, at the cost of a little more CPU usage, and is still much quicker than a hard drive swap. If your system falls back to swap every now and then, this can help make your system more responsive. Simply install [http://aur.archlinux.org/packages.php?ID=19248 compcache] from AUR after each kernel upgrade and add it to the DAEMONS array. Your can also tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See: [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
<br />
===Pacman===<br />
See: [[Improve Pacman Performance]].<br />
<br />
===OpenOffice===<br />
See: [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=94631Improving performance2010-01-31T17:43:44Z<p>Rttommy: Added OpenOffice subsection</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See: [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. You can find articles about each of them [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
Usually the default file-system in Linux, ext3 is known for its stability, and has been tested and improved since a decade. However, it is not very fast, and if speed is your priority, you should consider another one. A factor to consider is that a [http://www.fs-driver.org/ driver for Windows] exists, and you can therefore access your partition from any Windows installation. For performance tips, see: [[Ext3 Filesystem Tips]].<br />
<br />
====Ext4====<br />
The [[Ext4]] file-system is relatively new, and is basically an overall improvement over ext3, and that includes speed. It is also the new default for archlinux. Probably the best choice if stability is very important to you.<br />
<br />
====XFS====<br />
XFS offers excellent performance on large files and file-systems. In contrast, its average speed when dealing with large numbers of small files is poor. Therefore, if you choose Xfs, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. Xfs offers [[Defragmentation XFS|on-line defragmentation]] and mounts quickly.<br />
<br />
For optimal speed, create an XFS file-system with:<br />
mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}.<br />
<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
<br />
===Speeding up DNS===<br />
By tuning DNS querying, you can noticeably speed up web browsing. See: [[Speeding up DNS with dnsmasq]] or [[Pdnsd]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in /etc/X11/xorg.conf. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to ~/.xinitrc. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that allow you put your swap into your RAM and compress it. That means that part of your RAM can hold much more information, at the cost of a little more CPU usage, and is still much quicker than a hard drive swap. If your system falls back to swap every now and then, this can help make your system more responsive. Simply install [http://aur.archlinux.org/packages.php?ID=19248 compcache] from AUR after each kernel upgrade and add it to the DAEMONS array. Your can also tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See: [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
<br />
===Pacman===<br />
See: [[Improve Pacman Performance]].<br />
<br />
===OpenOffice===<br />
See: [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Apache_OpenOffice&diff=94630Apache OpenOffice2010-01-31T17:43:08Z<p>Rttommy: New Speed up section</p>
<hr />
<div>[[Category:Office (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|OpenOffice}}<br />
{{i18n_entry|Italiano|OpenOffice_(Italiano)}}<br />
{{i18n_entry|Ελληνικά|OpenOffice (Ελληνικά)}}<br />
{{i18n_entry|Русский|OpenOffice (Русский)}}<br />
{{i18n_entry|简体中文|OpenOffice.org_(简体中文)}}<br />
{{i18n_entry|Português|OpenOffice_(Português)}}<br />
{{i18n_entry|Türkçe|OpenOffice_(Türkçe)}}<br />
{{i18n_links_end}}<br />
[http://www.openoffice.org/ OpenOffice] is a leading open-source office software suite for word processing, spreadsheets, presentations, graphics, databases and more.<br />
<br />
==OpenOffice in Arch Linux==<br />
Arch offers 4 trees of binary packages for OpenOffice with different package names:<br />
<br />
'''openoffice-base'''<br />
<br />
This will always be the last released stable version of OpenOffice. <br><br />
Current version: 3.1.1 <br><br />
Start it with "soffice" or from a desktop menu, if any <br><br />
<br />
'''openoffice-base-beta'''<br />
<br />
This package will be only present when a new release is not far away. It will be the alpha, beta, and release candidates packages for the next stable release. <br><br />
Current version: 3.1.1_ooo310_m17-1 (way to=3.1.1rcX) (versions branched from DEV300_m40 that will lead to next stable 3.1.x release) <br><br />
Start it with "soffice-beta" or from a desktop menu <br><br />
It is safe to install it together with the stable and devel version. <br><br />
Please test it carefully and report upstream bugs to OpenOffice and packaging bugs in our flyspray. <br><br />
See http://wiki.services.openoffice.org/wiki/OOoRelease311 for roadmap<br />
<br />
'''openoffice-base-devel'''<br />
<br />
This packages will be updated from time to time and is a playground for the packager and for testing latest features. Please test and file upstream issues at http://www.openoffice.org/issues/query.cgi <br><br />
Current version: 3.2_dev300_m55-1 / snapshot DEV300_m55 (snapshots past branching the 3.1 stable tree that will lead to 3.2 release and beyond) <br><br />
Start it with "soffice-dev" or from a desktop menu <br><br />
It is safe to install it together with the stable and beta version. <br><br />
See http://wiki.services.openoffice.org/wiki/OOoRelease32 for roadmap<br />
<br />
'''go-openoffice'''<br />
<br />
In addition, there is a package for go-openoffice also called ooo-build - the "Novell fork" in the extra repository, which includes enhancements and features found in versions of openoffice.org available in Ubuntu, OpenSuSE and other distributions. For users of Arch switching from other distributions go-openoffice may be more familiar to them. It will always be the latest stable release in extra based on the source of openoffice-base pkg. Future beta/devel versions will go to the testing repo. <br><br />
Right now go-openoffice cannot be installed along any other openoffice branch; consider it a replacement.<br />
<br />
{{Note|If you play with more than one openoffice-base version it is highly recommended to always backup your configuration directory, ~/.openoffice{2,3}.}}<br />
<br />
==Installation==<br />
* First, install a Java Runtime Environment (optional, highly recommended). See: [[Java]]<br />
<br />
* Also, make sure that fonts are installed, otherwise you will see only rectangles:<br />
# pacman -S ttf-dejavu artwiz-fonts ttf-ms-fonts (and additionally any other needed for your language)<br />
<br />
* Download the base for stable and/or beta and/or devel and/or go-oo:<br />
# pacman -S openoffice-base openoffice-base-beta openoffice-base-devel go-openoffice<br />
<br />
* Download a language package. The main package contains only en_US files, yet the repository offer every shipped upstream langpack, except for go-openoffice.<br />
# pacman -S openoffice-en-GB openoffice-de ....<br />
<br />
===Extension management and spell checking for OpenOffice 3.x===<br />
The Arch package is now shipped with some dictionaries. Check Extension manager if your language is already there simply by loading up any OO program (Writer for example) and access the Extension Manager from the Tools menu. From there enter the following location to install a spell check dictionary:<br />
<br />
/usr/lib/openoffice/share/extension/install/<br />
<br />
{{Note | If you installed go-openoffice, the path will be /usr/lib/go-openoffice/share/extension/install/ instead. }}<br />
<br />
Alternatively, there are several ways to accomplish this:<br />
<br />
* 1) Use the Extension manager from OOo menu for download and installation - installs only for the user into his ~/.openoffice.org/3/user/uno_packages/cache<br />
* 2) Download the extension and install it using "unopkg add extension" for the user or<br />
* 3) Download the extension and install it using "unopkg add --shared extension" for every user on the system (requires root permission)<br />
<br />
===Set OOo environment variable===<br />
OpenOffice supports to use several toolkits for drawing and integrates into different desktop environments in a clean way. To choose by hand, you need to set the OOO_FORCE_DESKTOP environment variable.<br />
<br />
To run OpenOffice.org in GTK2 mode(this is default and already preset), you can issue (using bash):<br />
# OOO_FORCE_DESKTOP=gnome soffice<br />
To run OpenOffice.org in QT/KDE3 mode, you can issue (using bash):<br />
# OOO_FORCE_DESKTOP=kde soffice<br />
To run OpenOffice.org in QT4/KDE4 mode, you can issue (using bash):<br />
# OOO_FORCE_DESKTOP=kde4 soffice<br />
<br />
{{Note | As KDE look was removed in Openoffice3 it is highly recommended to use the GTK mode for all users. KDE4 integration is in experimental state in go-openoffice and in openoffice-base-devel (starting from m56)}}<br />
<br />
====Configure OOo environment globally====<br />
To configure the look for anytime OpenOffice gets started, you can export the '''<tt>OOO_FORCE_DESKTOP</tt>''' variable in /etc/profile.d/openoffice.sh, or in /usr/bin/soffice, with the value '''<tt>gnome</tt>''', '''<tt>kde</tt>''', or '''<tt>kde4</tt>'''.<br />
<br />
====Environment variable scripts====<br />
If for whatever reason you do not want to configure the look globaly, as a non-GNOME/KDE user you may run into problems when trying to add the environment variable to the command in a *box menu, as such menus do not seem to like environment variables.<br />
<br />
This script will run openoffice using the GTK look while still accepting command line options like -writer.<br />
#!/bin/sh<br />
<br />
#### openoffice-gtk - A script to start openoffice with the GNOME/GTK environment<br />
<br />
OOO_FORCE_DESKTOP=gnome /usr/bin/soffice "$@"<br />
<br />
Just use this script as a command (e.g, /usr/bin/openoffice-gtk) for your menu or whatever other sort of launcher you use.<br />
<br />
{{Note | If you open a file in a filemanager, for example Thunar, the default look will be used, as the file association will not use your personal script. }}<br />
<br />
===KDE4 look and feel for OpenOffice===<br />
OOO_FORCE_DESKTOP=gnome never did the trick for me. A good workaround is to set (as root):<br />
export SAL_GTK_USE_PIXMAPPAINT=1<br />
into /etc/profile.d/openoffice.sh. In KDE4 systemsettings, make sure "use my KDE style in GTK applications" is selected in Appearance > GTK styles and fonts (you must install gtk-qt-engine first).<br />
<br />
====Alternative configuration====<br />
You may wish to set the Xorg server dots-per-inch in the [[KDM]] configuration.<br />
<br />
Do not select "use my KDE style in GTK applications". Instead choose a native syle and font for GTK2 applications.<br />
# pacman -S gtk-chtheme<br />
# pacman -S gtk-engines<br />
<br />
Use gtk-chtheme to select a style (in general different from KDE) and a font (may be the same as your KDE general system font). There are also other GTK engine packages available.<br />
<br />
There are two relevant parts of the OOo options dialog, View and Fonts:<br />
*View<br />
**set scale to 100%<br />
**set use system font OFF (otherwise replacement table will not be used)<br />
**set antialiasing OFF<br />
<br />
*Fonts<br />
**select "Use replacement table"<br />
**replace "Andale Sans UI" (you ''must'' type this in -- it is not in the drop down list) with another font (your KDE system font or another if this looks bad)<br />
**Press the tick symbol to update the list<br />
**Select "always" and "screen only"<br />
**Press OK<br />
<br />
When choosing fonts for OpenOffice note that the poor font rendering engine included in the package may not render a particular font in the same way as other apps on the desktop. Use the {{Filename|kmag}} magnifying glass to examine shape of each letter.<br />
<br />
==Running OpenOffice==<br />
<br />
If you want to run a specific module of OpenOffice.org (instead of the soffice default Startcenter), for example the word processor (Write), spreadsheet application (Calc) or presentation program (Impress), check for the following script front-ends:<br />
<br />
Writer<br />
/usr/bin/soffice -writer<br />
<br />
Calc<br />
/usr/bin/soffice -calc<br />
<br />
Impress<br />
/usr/bin/soffice -impress<br />
<br />
Draw<br />
/usr/bin/soffice -draw<br />
<br />
Math (Formula Editor)<br />
/usr/bin/soffice -math<br />
<br />
Base (Database frontend)<br />
/usr/bin/soffice -base<br />
<br />
Printer Administration (Recommended to run as root)<br />
/usr/bin/spadmin<br />
<br />
==Speed up OpenOffice==<br />
Some settings may improve OpenOffice's loading time and responsiveness. However, some also increase RAM usage, so use them carefully. They can all be accessed under ''Tools > Options''.<br />
*Under ''Memory'':<br />
**Reduce the number of Undo steps to a figure lower than 100, to something like 20 or 30 steps.<br />
**Under Graphics cache, set Use for OpenOffice.org to 128 MB (up from the original 20MB).<br />
**Set Memory per object to 20MB (up from the default 5MB).<br />
**If you use OpenOffice often, check OpenOffice.org Quickstarter.<br />
*Under ''Java'', uncheck Use a Java runtime environment.<br />
==Trouble-shooting==<br />
=== Font substitution ===<br />
These settings can be changed in the OpenOffice.org options. From the drop-down menu, select ''Tools > Options > OpenOffice.org > Fonts''. Check the box that says ''Apply Replacement Table''. Type {{Codeline|Andale Sans UI}} in the font box and choose your desired font for the ''Replace with'' option. When done, click the ''checkmark''. Then choose the ''Always'' and ''Screen only'' options in the box below. Apply the changes, and your menu fonts should look great.<br />
<br />
=== Anti-aliasing ===<br />
Execute<br />
$ echo "Xft.lcdfilter: lcddefault" | xrdb -merge<br />
<br />
To make the change persistent, add "{{Codeline|Xft.lcdfilter: lcddefault}}" to your {{Filename|~/.Xresources}} file. [https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/271283/comments/19].<br />
<br />
If this doesn't work you can also try adding "{{Codeline|Xft.lcdfilter: lcddefault}}" to your {{Filename|~/.Xdefaults}}. If you do not have this file, you will have to create it.<br />
<br />
=== TrueType font detection ===<br />
See [[Font Configuration#Programs can no longer access TrueType fonts]]. To add fonts to those already available in OpenOffice, run {{Codeline|spadmin}}.<br />
<br />
===Qt looks with KDE >4===<br />
OpenOffice has transitioned to Qt 4, and as such the look of the applications can not be set with Qt 3 tools.<br />
<br />
===French dictionary===<br />
As of openoffice 3.0.0-2 the french dictionary is buggy due to a character encoding problem. To solve this problem, first execute the following commands (you will need '''zip''' and '''unzip''' packages):<br />
$ cp /usr/lib/openoffice/share/extension/install/dict-fr.oxt dict-fr.oxt<br />
$ unzip dict-fr.oxt -d dict-fr<br />
$ cd dict-fr<br />
$ iconv -f ISO-8859-15 -t UTF-8 dictionaries.xcu > dictionaries.xcu.utf<br />
$ mv dictionaries.xcu.utf dictionaries.xcu<br />
$ zip ../dict-fr.oxt *<br />
$ cd ../<br />
$ rm -r dict-fr<br />
then go in the openoffice extension manager (Tools menu) and install the dictionary from the new dict-fr.oxt file.<br />
<br />
===Dark GTK themes and gtk-qt-engine===<br />
For a quick fix, see [http://aur.archlinux.org/packages.php?ID=22383 openoffice-dark-gtk-fix] or if you have go-openoffice see [http://aur.archlinux.org/packages.php?ID=28879 go-openoffice-dark-gtk-fix] on the AUR. This also sets 'OOO_FORCE_DESKTOP=gnome'.</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=94615Improving performance2010-01-31T08:03:49Z<p>Rttommy: /* Speeding up DNS */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See: [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. You can find articles about each of them [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
Usually the default file-system in Linux, ext3 is known for its stability, and has been tested and improved since a decade. However, it is not very fast, and if speed is your priority, you should consider another one. A factor to consider is that a [http://www.fs-driver.org/ driver for Windows] exists, and you can therefore access your partition from any Windows installation. For performance tips, see: [[Ext3 Filesystem Tips]].<br />
<br />
====Ext4====<br />
The [[Ext4]] file-system is relatively new, and is basically an overall improvement over ext3, and that includes speed. It is also the new default for archlinux. Probably the best choice if stability is very important to you.<br />
<br />
====XFS====<br />
XFS offers excellent performance on large files and file-systems. In contrast, its average speed when dealing with large numbers of small files is poor. Therefore, if you choose Xfs, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. Xfs offers [[Defragmentation XFS|on-line defragmentation]] and mounts quickly.<br />
<br />
For optimal speed, create an XFS file-system with:<br />
mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}.<br />
<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
<br />
===Speeding up DNS===<br />
By tuning DNS querying, you can noticeably speed up web browsing. See: [[Speeding up DNS with dnsmasq]] or [[Pdnsd]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in /etc/X11/xorg.conf. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to ~/.xinitrc. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that allow you put your swap into your RAM and compress it. That means that part of your RAM can hold much more information, at the cost of a little more CPU usage, and is still much quicker than a hard drive swap. If your system falls back to swap every now and then, this can help make your system more responsive. Simply install [http://aur.archlinux.org/packages.php?ID=19248 compcache] from AUR after each kernel upgrade and add it to the DAEMONS array. Your can also tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See: [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
<br />
===Pacman===<br />
See: [[Improve Pacman Performance]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=94614Improving performance2010-01-31T07:44:01Z<p>Rttommy: /* Storage devices */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See: [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. You can find articles about each of them [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
Usually the default file-system in Linux, ext3 is known for its stability, and has been tested and improved since a decade. However, it is not very fast, and if speed is your priority, you should consider another one. A factor to consider is that a [http://www.fs-driver.org/ driver for Windows] exists, and you can therefore access your partition from any Windows installation. For performance tips, see: [[Ext3 Filesystem Tips]].<br />
<br />
====Ext4====<br />
The [[Ext4]] file-system is relatively new, and is basically an overall improvement over ext3, and that includes speed. It is also the new default for archlinux. Probably the best choice if stability is very important to you.<br />
<br />
====XFS====<br />
XFS offers excellent performance on large files and file-systems. In contrast, its average speed when dealing with large numbers of small files is poor. Therefore, if you choose Xfs, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. Xfs offers [[Defragmentation XFS|on-line defragmentation]] and mounts quickly.<br />
<br />
For optimal speed, create an XFS file-system with:<br />
mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}.<br />
<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
<br />
===Speeding up DNS===<br />
By tuning DNS querying, you can noticeably speed up web browsing. See: [[Speeding up DNS with dnsmasq]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in /etc/X11/xorg.conf. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to ~/.xinitrc. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that allow you put your swap into your RAM and compress it. That means that part of your RAM can hold much more information, at the cost of a little more CPU usage, and is still much quicker than a hard drive swap. If your system falls back to swap every now and then, this can help make your system more responsive. Simply install [http://aur.archlinux.org/packages.php?ID=19248 compcache] from AUR after each kernel upgrade and add it to the DAEMONS array. Your can also tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See: [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
<br />
===Pacman===<br />
See: [[Improve Pacman Performance]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].</div>Rttommyhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=94613Improving performance2010-01-31T07:41:58Z<p>Rttommy: /* Firefox */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{Expansion}}<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there is some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insuficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be mesured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See: [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008] and [http://bbs.archlinux.org/viewtopic.php?id=78490 2009]<br />
* Removing unnecessary daemons in rc.conf<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be mesured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
===Choosing and tuning your file-system===<br />
Choosing the best file-system for a specific system is very important because each has its own strenghts. You can find articles about each of them [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
Usually the default file-system in Linux, ext3 is known for its stability, and has been tested and improved since a decade. However, it is not very fast, and if speed is your priority, you should consider another one. A factor to consider is that a [http://www.fs-driver.org/ driver for Windows] exists, and you can therefore access your partition from any Windows installation. For performance tips, see: [[Ext3 Filesystem Tips]].<br />
<br />
====Ext4====<br />
The [[Ext4]] file-system is relatively new, and is basically an overall improvement over ext3, and that includes speed. It is also the new default for archlinux. Probably the best choice if stability is very important to you.<br />
<br />
====XFS====<br />
XFS offers excellent performance on large files and file-systems. In contrast, its average speed when dealing with large numbers of small files is poor. Therefore, if you choose Xfs, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. Xfs offers [[Defragmentation XFS|on-line defragmentation]] and mounts quickly.<br />
<br />
For optimal speed, create an XFS file-system with:<br />
mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}.<br />
<br />
====BTRFS====<br />
Btrfs is a new very promising filesystem in linux world. It shall offer online defragmentation, optimised mode for SSDs, writable snapshots, changing size of partition without dataloss and more features. Btrfs is still in active development, and is avaliable in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel chip-sets are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler(CFS) with the Brain Fuck Scheduler(BFS). To install from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
{{Warning| Currently (20 Dec 2009) you must comment out line 5 and uncomment line 6 of the pkgbuild for the install to work correctly.}}<br />
<br />
Or for just BFS:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
==Network==<br />
<br />
===Speeding up DNS===<br />
By tuning DNS querying, you can noticeably speed up web browsing. See: [[Speeding up DNS with dnsmasq]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in /etc/X11/xorg.conf. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Some settings may stop Xorg from booting, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to ~/.xinitrc. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
===Swappiness===<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to /etc/sysctl.conf:<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=10<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that allow you put your swap into your RAM and compress it. That means that part of your RAM can hold much more information, at the cost of a little more CPU usage, and is still much quicker than a hard drive swap. If your system falls back to swap every now and then, this can help make your system more responsive. Simply install [http://aur.archlinux.org/packages.php?ID=19248 compcache] from AUR after each kernel upgrade and add it to the DAEMONS array. Your can also tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to /etc/fstab and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See: [[Swap on video ram]].<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The fastboot option usually can take off one second or so. If you see a message saying "Waiting 8s for device XXX" at boot, adding rootdelay=1 can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in /boot/grub/menu.lst or /etc/lilo.conf, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
<br />
===Pacman===<br />
See: [[Improve Pacman Performance]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
Many other tips can be found on this [http://www.ubuntu-inside.me/2009/07/howto-optimize-firefox-and-benchmarking.html blog].</div>Rttommy