Re: unloading unnecessary modules
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 <stan@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-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 4CF1DF5B.6030309@hardwarefreak.com">http://lists.debian.org/[🔎] 4CF1DF5B.6030309@hardwarefreak.com
>
>
Reply to: