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@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Archive: http://lists.debian.org/4CF1DF5B.6030309@xxxxxxxxxxxxxxxxx




--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Archive: http://lists.debian.org/AANLkTiRZNYBZOTgydD8xeQ4smdiu2CV9KSTknLJFt@xxxxxxxxxxxxxx

Relevant Pages