logo       
Google Custom Search
    AddThis Social Bookmark Button
-->

Win2k, Bind 9.2.1, High CPU Usage: msg#00360

Subject: Win2k, Bind 9.2.1, High CPU Usage
Hi there.  I've done some extensive searching through the archives regarding
this problem...and have found only couple posts dating back to 6/14/2002.  I
have attached one of them for refernce below.

My installation of Bind 9.2.1 causes my CPU useage to skyrocket, as stated
in the message below.  I've just installed 9.2.2rc1, and have noticed that
usage is lower...but still active.  I'm curious if, in fact, a fix was put
in place for 9.2.2rc1 (a socket re-write, as mentioned below)...or if I'm
just experiencing a coincidence?

If this has not been addressed, is there any status regarding it?  Thanks
much for any replies...
Al

=======================
ARCHIVED MESSAGE QUOTES
=======================
On Windows 2000 Server (which was running 8.2.x before) the 9.2.1
version immediately raised the cpu usage somewhere between 35 and 75%.
This is a single cpu machine.

Reverted to 9.2.0 as was suggested by some posts here, no more race
condition, but the queries are unexpectedly delayed. A simple dig for a
local host name can answer immediately or with delays varying from
roughly 1/2 sec to 3 or 5 seconds ! I have few straight queries on that
server, so I decided to leave it that way for some days.

DM> This is due to the timeout value on the select function in the socket.c
DM> code that was changed between 9.2.0 and 9.2.1 which is why this was
DM> not a problem on 9.2.0.
DM> <...>
DM> That's why the timeout was changed.  If was too agressive for people
DM> running other things on their machines.  It can be provoked merely by
DM> running clock.avi in Windows Media Player.

I see, thanks for the explanation.

DM> >My questions. From now, what steps should I take to help narrow down
the
DM> >bug and fix them ? We are a team of C++ devs here and might help. Are
DM> >there recommended build procedures for 9.2.1 on Windows ? Is there
DM> >someone in particular to report this problem to ?
DM>
DM> If you running Visual Studio, you can build the code from source by
grabbing
DM> the 9.2.1 source tarball from the ISC Web site. There are build
instructions
DM> in the win32utils directory along with some bat and Perl files.  You do
need
DM> Perl installed on the machine to generate the version information.

Downloaded code in between and found all instructions needed. Build
successfull.

DM> If you go to lib/isc/win32/socket.c and look for the timeout values:
DM> #define MAX_SELECT_SECONDS 0
DM> #define MAX_SELECT_MILLISECONDS 400
DM>
DM> Try changing the second one to 800.  That should reduce the
compute-bound
DM> problem at the cost of somewhat increasing the delays like you saw in
9.2.0.
DM> Then run Buildall.bat from win32utils. You may have to try several
values
DM> until you are happy with the balance between responsiveness and delays.

Hmm. I'll run some tests with various values, for the case.

DM> >Would it be a good idea to switch back to the latest version of the 8.x
DM> >series in between ?
DM> >
DM> >I have not tried yet the various release candidates which were built
DM> >between 9.2.0 release and 9.2.1 release. I can spend some time trying
DM> >those to see from when on the cpu bug appears. But most probably
someone
DM> >else has already done it ?
DM>
DM> The problem will disappear when the socket code is rewritten which will
DM> happen fairly soon.

Glad to read that socket code is about to be rewritten. Had a quick look
at that. Having to do the kind of tweaking as above is certainly not
helping develop confidence in the code. Here is what I did and will do :

o) switched back my server to 8.2.3 code minutes ago (in fact before
reading your message) : runs apparently smoothly with excellent response
times.

o) will re-install 9.2.1 along with dev tools on a spare computer and
will tweak a bit the timing to see if I can really get something
acceptable in between. Hope to train myself a bit on portions of the
code at the same time.

Thank you very much !






<Prev in Thread] Current Thread [Next in Thread>