Stan, thanks for the response.
To my understanding, CONFIG_HZ is a kernel time option. Has that changed? I can certainly rebuild the kernel. How can I check via /proc what my HZ is currently set at? Is there a tool to determine this for me? Removing tasks from cron has helped! We had some weird random tasks starting up at production hours which causes interrupts. This is a notoriously underestimated tip. On Sat, Nov 27, 2010 at 11:49 PM, Stan Hoeppner <s...@hardwarefreak.com> wrote: > Mag Gam put forth on 11/27/2010 11:06 AM: >> Stan, >> >> Correct. On my severs I too have sound cards and USB. I don't really >> need them so I would rather unload them. I suppose I can do a macro >> benchmark and state if it helped or not but I would like to know on a >> micro level to see if it helped. I think one possibility is to do >> "lat_pipe" from lmbench to measure transaction latency of a UNIX pipe. >> >> My goal is to have the most optimal kernel/tuning since our >> application is very latency sensitive. > > In that case modules aren't your worry--the kernel interrupt timer is, > along with scheduled tasks. For latency sensitive apps, you need a > kernel with something like CONFIG_HZ=1000 or greater, which IIRC used to > be the "workstation" default. The "server" default is 250Hz. Also, > IIRC, the current Debian kernels implement tickless timers to allow > better integration as virtual machine guests. For latency sensitive > apps, you'd don't want a tickless timer. > > If you have a latency sensitive app: > > 1. Use a kernel with CONFIG_HZ=1000 (or greater) > > 2. Eliminate all possible cron jobs or schedule them to run at times > when it won't impact the latency of your application. I.e. make sure no > processes fire unexpectedly which may impact the latency of you > application. On today's multicore systems this is less of a problem > than it once was as your application can continue to run on the core > which is executing it while a new process will be fired up on another > core. When/if in doubt, minimize unexpected process execution. > > 3. If the application is disk I/O bound, make sure you have plenty of > write cache, and a stripe (RAID6/10) of a sufficient number of spindles. > RAID10 is optimal for low latency. RAID6 can suffer read-modify-write > cycles which will increase latency. If you have large write cache, and > your app never bursts an amount of data larger than the cache, then > RAID6 may be fine. Testing is your friend here. Also note that the XFS > filesystem offers the "realtime" sub volume which can decrease latency. > It was originally developed for streaming media applications such as > digital broadcast systems that replaced teh traditional tape systems: > http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide//tmp/en-US/html/ch04s09.html > > 4. If the application is sensitive to network latency, use a NIC and > driver that supports TCP offload processing. If the application needs > DNS name resolution of remote systems, consider installing a local > caching resolver such as pdns-recursor, which can reduce lookup latency > considerably for cached results. > > -- > Stan > > > -- > To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/4cf1df5b.6030...@hardwarefreak.com > > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktirznybzotgydd8xeq4smdiu2cv9kstknl...@mail.gmail.com
