[NTLUG:Discuss] Fwd: [linux-elitists]] Red Hat 9 Optimization]]

[David Simmons]

Just some follow-up from another LUG

> This is a very interesting post; thanks!
> 
> I've wondered about this weird slowdown for a while.  It seems to come
> and go (see #4, below).  If you wade through the chain of bugzilla
> reports, it looks like there are four issues discussed:
> 
> 1) the default bdflush settings
> 2) LANG=en_US.utf8
> 3) "service foo start" is different from "/etc/init.d/foo start" but
> should not be.
> 4) Something's wrong with the way the VM handles cache buffers
> 
> #1 is easy to fix.  "/sbin/sysctl -w vm.bdflush="30 500 0 0 2560 15360
> 60 20 0" does seem to smooth things out a bit (response times aren't so
> jerky).  To make this change permanent, put the part after the -w into
> /etc/sysctl.conf.
> 
> #2 is not fixed, but is easy to get around.  I ran "time grep '^'
> /var/log/messages > /dev/null' with various LANG settings.
> With LANG=en_US.UTF-8, average REAL time was 3.380 seconds.
> With LANG=en_US, average REAL time was 0.003 seconds (YES, THAT'S A
> THOUSAND TIMES SLOWER).
> 
> I've filed a report in Bugzilla; they seem to be working on it.  In the
> meantime, 
> 
> Edit /etc/sysconfig/i18n and change LANG="en_US.utf8" to LANG="en_US". 
> Also move the *.UTF-8* entries in SUPPORTED to the end of the list, like
> this:
> SUPPORTED="en_US:en:en_US.UTF-8"
> 
> 
> 
> #3 is a security problem.  A long, long time ago in a place not far from
> here, I was taught that daemons should always start with a clean
> environment.  "service foo start" does this, but "/etc/init.d/foo start"
> does not.  The bug is in /etc/init.d/functions, in the definition of
> daemon().  This function should call 'env -i' to clear the environment
> before starting a daemon but does not.  RedHat is reluctant to rush a
> fix through because several existing daemons apparently depend on having
> an environment.
> 
> 
> #4 is ugly, plain and simple.  The bdflush trick helps but doesn't solve
> this problem.  RedHat's kernel guys seem to be working with Linus & crew
> to figure out what's wrong; they aren't sure, yet, if it's one of Red
> Hat's patches or something in the kernel.org sources.
> 
> Thanks again for the post!