Re: [PERFORM] Hyper threading?

2004-09-23 Thread Greg Copeland
On Tue, 2004-09-21 at 03:54, Mariusz Czuada wrote:
 Hi all,
 
 I searched list archives, but did not found anything about HT of Pentium 
 4/Xeon processors. I wonder if hyperthreading can boost or decrease 
 performance. AFAIK for other commercial servers (msssql, oracle) official 
 documents state something like faster, but not always, so probably slower, 
 unless faster. User opinions are generaly more clear: better swhitch off HT.
 
 Do you have any experiance or test results regarding hyperthreading? Or what 
 additional conditions can make HT useful or pointless?
 

I think you'll find that HT is very sensitive to both the OS and the
application.  Generally speaking, most consider HT to actually slow
things down, unless you can prove that your OS/application combination
is faster with HT enabled.  Last I heard, most vendors specifically
disable HT in the BIOS because the defacto is to expect HT to inflict a
negative performance hit.

IIRC, one of critical paths for good HT performance is an OS that
understands how to schedule processes in a HT friendly manner (as in,
doesn't push processes from a virtual CPU to a different physical CPU,
etc).  Secondly, applications which experience a lot of bad branch
predictions tend to do well.  I don't recall what impact SSE
instructions have on the pipeline; but memory seems to recall that
applications which use a lot of SSE may be more HT friendly.  At any
rate, the notion is, if you are HT'ing, and one application/thread
requires the pipeline to be flushed, the other HT'ing thread is free to
run while the new branch is populating cache, etc.  Thusly, you get a
performance gain for the other thread when the CPU makes a bad guess.

Along these lines, I understand that Intel is planning better HT
implementation in the future, but as a general rule, people simply
expect too much from the current HT implementations.  Accordingly, for
most applications, performance generally suffers because they don't tend
to fall into the corner cases where HT helps.

Long story short, the general rule is, slower unless you having proven
it to be faster.


Cheers,

-- 
Greg Copeland, Owner
[EMAIL PROTECTED]
Copeland Computer Consulting
940.206.8004



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PERFORM] Clarification on some settings

2004-05-13 Thread Greg Copeland
On Thu, 2004-05-13 at 14:42, Doug Y wrote:


 We don't seem to be swapping much:
 

Linux aggressively swaps.  If you have any process in memory which is
sleeping a lot, Linux may actively attempt to page it out.  This is true
even when you are not low on memory.  Just because you see some swap
space being used, does not mean that your actively running processes are
causing your system to swap.

I didn't catch what kernel version you are running, so I'm tossing this
out there.  Depending on the kernel (I believe 2.6+, but there may be
something like it in older kernels) that you are running, you can
attempt to tune this buy setting a value of 0-100 in
/proc/sys/vm/swappiness.  The higher the number, the more aggressive the
kernel will attempt to swap.  Some misc. kernel patches attempt to
dynamically tune this parameter.

For a dedicated DB server, a higher number will probably be better. 
This is because it should result in the most cache being available to
the system.  This, of course means, you may have to wait an tad bit long
when you ssh into the system, assuming sshd was swapped out.  I think
you get the idea.


 Swap: 1052248K av,1092K used, 1051156K free 1465112K cached
 
 looks like at some point it did swap a little, but from running vmstat, I 
 can't seem to catch it actively swapping.
 

Chances are, you have some dormant process which is partially or
completely paged out.

For an interesting read on Linux and swapping, you can find out more
here:  http://kerneltrap.org/node/view/3080.

Cheers!

-- 
Greg Copeland, Owner
[EMAIL PROTECTED]
Copeland Computer Consulting
940.206.8004



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])