webhosting   Cheap Reseller Hosting   links    free hosting by fateback   hosting reseller   100WebSpace offers 100MB Web Space 
Free Links
Free Image Hosting, Web Hosting, Architectural Projects in Bulgaria, Famous People & Celebrity Search, Web Page Hosting




    Tuning A GNU/Linux Box

    Network Tuning

    General Network Tips :


  • Most tunable values in the Linux are found under the /proc directory of your file system.
    In the domain of network tuning, there are many tunables, and you should leave most of
    them alone. In /proc/ sys/net, especially the subdirectories ipv4 and core, there are a number of files that, when read, reveal current kernel networking values and, when written to, let you change those networking values.
    (These files are documented in the file Documentation/networking/ip-sysctl.txt in the kernel source-code distribution.) It is better to use 100BTX instead of 10BTX. Even if we are limited to 10 by some kind of thing like an IPath, we can see more than 10% better performance in transfer speeds on 100. Also 2 10's isn't really all that great because we can really only do about 63 to 65% utilization before you get too many collisions. Always try on a switch. Bridges can kill your performance, for obvious reasons.

    • NB: You can find some configuration files in the directory of /proc and /proc/sys/net/ipv4

  • Definitely have "Allow large windows" enabled (it is by default). If you're going to be building a router, make sure to check the "Optimize as router" box in the kernel configuration. Also, consider "Fast switching".Apparently this only works with the "Tulip" drivers (DEC based cards).More useful is the option to "Allow Large Windows." This controls how big the send and receive buffers will be on TCP/IP socket connections before the other end must acknowledge receipt. On long-distance high-speed links (where bandwidth is large, but so is delay), this control lets you take advantage of your high-capacity network. You should have at least 16 MB of RAM to do this. To determine if a kernel is enabled with large windows, simply read the file /proc/ sys/net/core/rmem_max (or /proc/sys/net/core/wmem_max). If the value is 65535, it is enabled. Otherwise, you can enable it by writing a new value into that file: echo 65535 > /proc/sys/net/core/ rmem_max. (Do the same for /proc/sys/net/core/wmem _max, /proc/sys/net/core/ rmem_default and /proc/sys/net/core/wmem_default.)


  • ip_frag_low_thresh and ip_frag_high_thresh (those files are in /proc/sys/net/ipv4)should be increased in some situations. Especially NFS and Samba servers. This will allow your server to take far more connections and put them together in memory before having to
    ditch their fragments. You can safely increase these to several megabytes
    without any problems.


  • tcp_fin_timeout (those files are in /proc/sys/net/ipv4)can be decreased below the default 180 seconds. This may help you if you seem to be having too many connections in FIN_WAIT2 (as reported by netstat). This probably shouldn't be a problem, as 180 is pretty low (the RFC
    says unlimited) but I know that it still helps us sometimes.

  • ip_no_pmtu_disc is a switch to turn path MTU discovery on and off. This is good for servers that don't know who they might be talking to, so they might have some crazy SLIP link in the middle. If that was the case, all the packets would get fragmented, and that's a big performance hit. However, if you know that all your clients are going to be on local ethernet, then you can probably just turn it off, since everyone is going to have an MTU of 1500. Speaking of MTU's, in W.R.Stevens' TCP/IP Illustrated, he mentions that low MTU's can actually have higher throughput, as well as lower latency. This is quite different from the more commonly accepted belief that the higher your MTU, the better. This is definitely a more efficient model, since you reduce your overhead, but your end-to-end time for each packet is longer, which may affect some protocols. Anyone have any real figures on that?
    All I have are some theoretical calculations. Might be worth trying to set your maximum MTU to 576. On a 20 minute sample of our network traffic, 40% of all non-SYN/ACK traffic had a packet length of 576 anyway. This is really only applicable to LFN pipes
    (Long Fat Network -- big bandwidth, high end-to-end time or latency) AFAIK.

  • Default Packet Sizes

    • NFS:

    The rsize and wsize mount options (specifyable in /etc/fstab) increase
    the packet sizes used by NFS clients, and usually increase performance. Try
    mount -o rsize=8192,wsize=8192 -t nfs host:/dir /mnt/point


    SMB:

    A similar gain can be achieved with the Samba server by setting the
    following in smb.conf:

    socket options = SO_SNDBUF=4096 SO_RCVBUF=4096

  • Filesystem Tuning

    • Block sizes

    For filesystems dedicated to serving fairly large files, adopting a larger than default
    1024 byte block size may yield significant performance gains.
    Recent transactions on the Linux list suggest that setting the block sizein an
    ext2 file system to 4096 instead of the default 1024 will result in less file
    fragmentation, faster fsck's, faster deletes and faster raw read speed, due to the
    reduced number of seeks.

    Unfortunately this cannot be changed on the fly. Only a reformat will make this so. The
    command to format a file system with 4096 byte blocks is:

    mke2fs -b 4096 /dev/whatever

    Additionally, on any filesystems except those used for logfiles, the default of 5%
    reserved for root use is excessive for large file systems, so the command to make
    the filesystem can be augmented to

    mke2fs -b 4096 -m 1 /dev/whatever

    to set the reserved fraction to 1 percent.

    Anything that speeds up the filesystem will speed up its file serving capabilities
    correspondingly.
    However, use some judgment when considering this suggestion. The performance gain is at
    the expense of being less space efficient. And if the filesystem in question is
    dedicated to small files, such as for a news server or mail server, going to 4096
    byte blocks will have an amplified cost in terms of disk space. For these, you might
    want to stick with 1024 byte blocks. For example, the average size of the 9250 files
    currently in our comp.os.linux.hardware is 2145 bytes, with many smaller and
    obviously many larger than that. So going to a 4096 byte block would mean the
    average file would use 4096-2145=1951 too much. At 1024, there'd be two full 1024
    byte blocks and a third block to get the remaining 97 bytes. Third block would be
    927 bytes empty, on average. Going to a 512 byte block, there'd be 415 bytes wasted,
    on average.

  • Not using the atime attribute

    • In addition to the information about when files were created and last modified,filesystem
    also records when a file was last accessed. This information is not particularly
    useful, and there is a cost associated with recording it. The ext2 filesystem allows
    the superuser to mark individual files such that their last access time is not
    recorded. This may lead to significant performance improvements when running find,
    and may also be useful on often accessed frequently changing files such as the
    contents of /var/spool/news.
    To set the attribute, use

    chattr +A filename

    For a whole directory tree, do something like:

    chattr -R +A /var/spool

    Additionally, entire partitions can be mounted with no access time updating, again, news
    spools are a prime example. The man page for mount lists the following option:

    noatime
    Do not update inode access times on this
    file system (e.g., for faster access on the
    news spool to speed up news servers).
    The syntax to do this automagically is to edit the /etc/fstab, adding in the noatime
    option to the options column, separated by a comma. e.g.:
    # device mount point type options dump frequency fsck pass number
    /dev/sdb1 /var/spool/news ext2 defaults,noatime 1 2

  • Filesystem Specific Tuning

    • With the arrival of the mid 2.4.x kernels, more filesystem choices are available in the
    standard kernel (these have been previously available in the form of patches by the
    filesystem authors and various distributions as well). The ones that are meant as
    replacements to ext2fs are: ext3, resierfs, xfs (from SGI) and jfs (from IBM). All
    of these filesystems provide speed improvements especially on directories with large
    number of files in addition to their journaling capabilities. So if available in
    your preferred distribution, try out and test using these new available file systems
    to use as the underlying filesystem for NFS or Samba network file serving.

  • Disk/IO Tuning

    • The disk subsystem of the Linux is very conservative with your data. When not completely sure if a certain disk or controller reliably handles a certain setting (such as using Ultra DMA or IDE Block Mode to transfer more sectors on a single interrupt or 32-bit bus transfers), it will default to the setting least likely to cause data corruption. Using a tool called hdparm, you can change the settings and evaluate their robustness before using them in a production environment. (Actually, hdparm primarily affects IDE systems. It affects only a very limited number of items on SCSI disks.) On our test computer, by enabling Ultra DMA (using the command hdparm -d1 /dev/hda), we sped up data-read transfers from 2.17 MB per second to 11.19 MB per second. Write transfers will see a similar increase in speed. On a significantly older machine, there was no change in speed.

    The only drawback to enabling this setting is the remote possibility that very old hardware will not properly implement Ultra DMA.

    The use of IDE Block Mode (also known as Multiple Sector Mode) via the command
    hdparm -m16 /dev/hdX Where(X = a ,c ,d .. so on)
    enabling 32-bit bus transfers with
    hdparm -c1 /dev/hdX
    and enabling the DMA with
    hdparm -d1 /dev/hdX can resulted a notable increase in speed .Combinedly we can also use the command
    hdparm -c1 -d1 -k1 /dev/hdX
    See the documentation for hdparm (man hdparm) for more information. ---------------------------------------------------------------------------------

    New Journaling File System

  • Choosing elevator settings

    • The ext3 file system acts a bit differently than the ext2 file system, and the
    differences can appear in various ways. Advanced users may choose to tune the file
    system and I/O system for performance. This is an introduction to some of the more
    common tuning that advanced users may wish to try. All tuning, of course, needs to
    be done in the context of performance testing of specific applications; there is no
    "one size fits all" approach to tuning. This is, however, intended to provide some
    generally useful information.


    Most of the block device drivers use a generic tunable "elevator" algorithm for
    scheduling block I/O. The /sbin/elvtune program can be used to trade off between
    throughput and latency. Given similar loads, the ext3 file system may require
    smaller latency numbers as provided to the /sbin/elvtune program in order to provide
    similar results to the ext2 file system.

    In some cases, attempting to tune for maximum throughput at the expense of latency
    (in this case, large read latency (-r) and write latency (-w) numbers used with the
    /sbin/elvtune program) can actually decrease throughput while increasing latency.
    This effect is more pronounced with the ext3 file system for a variety of reasons.

    With the ext2 file system, writes are scheduled every 30 seconds; with the ext3 file
    system, writes are scheduled every 5 seconds. This keeps journal transactions from
    having a noticeable impact on system throughput and also keeps data on disk more
    up-to-date.


    The ext3 file system, by journaling all metadata changes, can magnify the effect of
    atime changes significantly. You can mount a file system with the noatime flag in
    order to disable atime updates. While this is not the only source of metadata
    updates, on many systems, particularly highly-accessed servers with lots of accessed
    files, atime updates can be responsible for the majority of metadata updates, and on
    these systems, turning off atime updates may noticeably reduce latency and increase
    throughput.
    In order to tune for our default file system choice of ext3, Red Hat has reduced the
    default read and write latency numbers to half of the default values (from 8192
    read, 16384 write to 4096 read, 8192 write). We expect that in general use, you will
    not have to change these numbers; we hope we have already done this for you. Our
    changed default values have produced good results in our tests. However, in order to
    tune for specific applications, we suggest benchmarking your applications with a
    variety of values, testing interactive response during some runs if interactive
    response is important to you. In general, we recommend that you set read latency
    (-r) to half of write latency (-w).

    For example, you might run: /sbin/elvtune -r 1024 -w 2048 /dev/sdd to change the
    elevator settings for the device /dev/sdd (including all the partitions on
    /dev/sdd). Changes to the elevator settings for a partition will apply to the
    elevator for the device the partition is on; all partitions on a device share the
    same elevator.

    Once you have found elvtune settings that give you your most satisfactory mix of latency
    and throughput for your application set, you can add the calls to the /sbin/elvtune
    program to the end of your /etc/rc.d/rc.local script so that they are set again to
    your chosen values at every boot.

  • Choosing journaling mode


    • There are some characteristic loads that show very significant speed improvement with
    the data=writeback option, which provides lower data consistency guarantees. In
    those cases, the data consistency guarantees are essentially the same as the ext2
    file system; the difference is that the file system integrity is maintained
    continuously during normal operation (this is the journaling mode used by most other
    journaling file systems). One of these cases involves heavy syncronous writes. Other
    cases involve creating and deleting large numbers of small files heavily, such as
    delivering a very large flow of small email messages. If you switch from ext2 to
    ext3 and find that your application performance drops substantially, the
    data=writeback option is likely to give you a significant amount of performance
    back; you will still have some of the availability benefits of ext3 (file system is
    always consistent) even if you do not have the more expensive data consistency
    guarantees.

    Red Hat is continuing to work on several performance enhancements to ext3, so you can
    expect several of these cases to improve in the future. This means that if you
    choose data=writeback now, you may want to retest the default data=journal with
    future releases to see what changes have been made relative to your workload.

  • Data integrity

    • In most cases, users write data by extending off the end of a file. Only in a few cases
    (such as databases) do users ever write into the middle of an existing file. Even
    overwriting an existing file is done by first truncating the file and then extending
    it again.

    If the system crashes during such an extend in data=ordered mode, then the data blocks
    may have been partially written, but the extend will not have been, so the
    incompletely-written data blocks will not be part of any file.

    The only way to get mis-ordered data blocks in data=ordered mode after a crash is if a
    program was overwriting in the middle of an existing file at the time of the crash.
    In such a case there is no absolute guarantee about write ordering unless the
    program uses fsync() or O_SYNC to force writes in a particular order.

  • SAMBA SERVER


    • This might be relevant to Client Tuning. I have been trying various methods of getting win95 to talk to Samba quicker. The results I have come up with are:

    1. Install the W2setup.exe file from www.microsoft.com. This is an update for the winsock stack and utilities which improve performance.

    2. Configure the win95 TCPIP registry settings to give better perfomance. I use a program called MTUSPEED.exe which I got off the net. There are various other utilities of this type freely available. The setting which give the best performance for me are:

    (i) MaxMTU Remove
    (ii) RWIN Remove
    (iii) MTUAutoDiscover Disable
    (iv) MTUBlackHoleDetect Disable
    (v) Time To Live Enabled
    (vi) Time To Live - HOPS 32
    (vii) NDI Cache Size 0

    3. I tried virtually all of the items mentioned in the document and the only one which made a difference to me was the socket options. It turned out I was better off without any!!!!!

    In terms of overall speed of transfer, between various win95 clients and a DX2-66 20MB server with a crappy NE2000 compatible and old IDE drive (Kernel 2.0.30). The transfer rate was reasonable for 10 baseT.

    The figures are: Put Get
    P166 client 3Com card: 420-440kB/s 500-520kB/s
    P100 client 3Com card: 390-410kB/s 490-510kB/s
    DX4-75 client NE2000: 370-380kB/s 330-350kB/s

    I based these test on transfer two files a 4MB text file and a 16MB textfile. The results arn't bad considering the hardware Samba is running on.
    The updates mentioned in 1 and 2 brought up the transfer rates from just over 100kB/s in some clients.

    A new client is a P333 connected via a 100MB/s card and hub. The transfer rates from this were good: 450-500kB/s on put and 600+kB/s on get.

    Looking at standard FTP throughput, Samba is a bit slower (100kB/s upwards). I suppose there is more going on in the samba protocol, but if it could get up to the rate of FTP the perfomance would be quite staggering.
    _______________________________________________

    I have tried to mention some resources on tuning a GNU/Linux OS to reach the highest levels of performance. The tuning tips provided here are merely the collection of all information gathered from the Net and some of my experiences which I have got during my brush with the GNU/Linux world. It is recommended to backup all your data before tuning your GNU/Linux box, because tuning may induce some changes which may not be compatible with you current setup.

    * I have tried these tunings on Intel P-III and Intel P-IV platforms with 128 MB RAM.

    More on http://linuxperf.nl.linux.org/