Performance issue ( maybe )
glenn.satchell at uniq.com.au
Mon Sep 6 11:19:38 UTC 2010
On 09/06/10 17:01, Tom Schmitt wrote:
>> Von: Bjarne Blichfeldt<bjb at jndata.dk>
>> Betreff: Performance issue ( maybe )
>> During clients startup, the servers takes a very long time ~20-30
>> seconds> to answer a DISCOVER.
> As a first step before you look for the source on the server, I would do a tcpdump on the server interface to make sure that the delay you are experiencing are really originate there and not somewhere else on the network.
Yes, this is a very good idea. If possible, also do a packet capture on
the client. See when the broadcast is received, and the response sent.
Could be osm other part of the network. 20-30 seconds sounds like
something is timing out to me.
>> è Cpu2 : 0.0%us, 0.3%sy, 0.0%ni, 1.3%id, 98%wa, 0.0%hi, 0.0%si,
> So regarding the wait I/O: first step is looging without sync, second step is logging only errors and higher third step is no logging at all (only for a testperiod to see if your problem is going away)
>> The only process really working is kjournald.
> So are ther any other logmessages in high numbers beside the ones from dhcpd?
>> 1) anybody seen something similar ?
>> 2) Good ideas to further investigate ? What about the network
>> topology ? Any gotcha's when sending DISCOVERY through two cisco routers ?
> Shouldn't be an isuue. I do the same without having problems.
> Or did you you just upgrade your IOS?
Do you mean that there are two hops from the dhcp server to the network
where the client is? This should be fine. The ip-helper setting on each
router should specify the dhcp server's IP address. So when the
broadcast request gets to the first router it then gets forwarded to the
> Is the problem occurring on both on your dhcpd-servers at the same time? Or only on one of them?
> And are there any messages in the log which could give you a hint?
>> Also, what would be the consensus of disabling pingcheck ?
>> ping-check false;
>> The ping adds at least one second to every discovery/offer,
> You would win one second, but having other problems. I won't recommend it. Better you find the real problem than working around it.
I agree with this. Does the client have any firewall that might block
>> option option-150 10.11.75.10 ;
>> filename "\\mboot.0" ;
>> next-server 10.2.2.240 ;
> Could it be, that not your server is the source of the problem, but the server 10.2.2.240?
Probably not, the dhcp discover/offer/request/ack cycle has to complete
before the client even tries to contact the tftp server. So even if this
box was really slow, it wouldn't make any difference as far as
responding to the DHCPDISCOVER.
Glenn Satchell | Miss 9: What do you
Uniq Advances Pty Ltd, Sydney Australia | do at work Dad?
mailto:glenn.satchell at uniq.com.au | Miss 6: He just
http://www.uniq.com.au tel:0409-458-580 | types random stuff.
More information about the dhcp-users