DHCP restart with bulk lease data

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

DHCP restart with bulk lease data

Teja
Hi ,

I have an issue with dhcpd service restart when it handles a bulk lease data. As part of testing I have simulated the dhcp server to lease test using dhcperf tool to check the performance statistics when the dhcpserver handles a huge lease data Ex :300689(3M). It is taking 3 to 4 minutes of duration to start up the service, Is this the expected behaviour when we have a such large lease file ? (FYI: No memory, disk space problem on the system)

 When I restarted dhcpd in the log message I have a seen statement like 
 Wrote 300689 leases to leases file. 
Does the restart dhcpd will rewrite the lease file again? 
I also observed  as new lease file with extension ~ at end like after restart dhcpd
I see two lease file one with dhcpd.leases and other dhcpd.leases~
 If it is not expected behaviour can anyone have any reference tool or steps to check what is taking time to bring the service up 
Thanks in Advance

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Simon Hobson
Surya Teja <[hidden email]> wrote:

> I have an issue with dhcpd service restart when it handles a bulk lease data. As part of testing I have simulated the dhcp server to lease test using dhcperf tool to check the performance statistics when the dhcpserver handles a huge lease data Ex :300689(3M). It is taking 3 to 4 minutes of duration to start up the service, Is this the expected behaviour when we have a such large lease file ? (FYI: No memory, disk space problem on the system)
>
>  When I restarted dhcpd in the log message I have a seen statement like
>  Wrote 300689 leases to leases file.
> Does the restart dhcpd will rewrite the lease file again?
> I also observed  as new lease file with extension ~ at end like after restart dhcpd
> I see two lease file one with dhcpd.leases and other dhcpd.leases~
>  If it is not expected behaviour can anyone have any reference tool or steps to check what is taking time to bring the service up

It is a known issue that the server can take some time to start up when there is a large number of potential addresses in the defined pools. The reason for this being the way the server builds hashing tables internally. It is probably to be expected as well in the situation you've described - it must read the leases file and process each lease in turn, updating the internal structures as it goes.

The leases file is a log file database - nothing is ever changed, only new entries added at the end. Obviously, such a file would grow without bounds over time without some sort of cleanup routine. Periodically, default is every hour, the server will write out a fresh leases file from it's internal structures - this file will contain no duplicate entries. It writes this to a new file, moves the existing lease file to a backup name (the one with "~" on the end), and moves the new file into place as the active leases file. The leases file is ONLY read at server startup and never after that - everything is done from in memory structures. In between cleanups as detailed above, every time anything changes, a new record is appended to the on-disk leases file.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Teja
Hi Simon Thanks for reply,
 Periodically, default is every hour, the server will write out a fresh leases file from it's internal structures  --->
I have a doubt when the server write out a fresh leases file from it's internal structures will the dhcpd service be in off state at this duration?

this file will contain no duplicate entries --->
Hi I have seen the duplicate entry in my server lease file
 sample  snippet:
==============
lease 192.168.2.52 {
  starts 5 2019/09/27 07:21:32;
  ends 5 2019/09/27 08:21:32;

  tstp 5 2019/09/27 08:51:32;
  tsfp 5 2019/09/27 08:21:32;
  cltt 5 2019/09/27 07:21:32;
  binding state active;
  next binding state expired;
  hardware ethernet 70:bb:e9:37:d9:9e;
  uid "\001p\273\3517\331\236";
  set vendor-class-identifier = "android-dhcp-9";
  client-hostname "RedmiNote6Pro";
}
lease 192.168.2.52 {
  starts 5 2019/09/27 07:21:32;
  ends 5 2019/09/27 08:21:32;

  tstp 5 2019/09/27 08:51:32;
  tsfp 5 2019/09/27 08:51:32;
  atsfp 5 2019/09/27 08:51:32;
  cltt 5 2019/09/27 07:21:32;
  binding state active;
  next binding state expired;
  hardware ethernet 70:bb:e9:37:d9:9e;
  uid "\001p\273\3517\331\236";
  set vendor-class-identifier = "android-dhcp-9";
  client-hostname "RedmiNote6Pro";
}
Yes It has same data, I don't see any issue on client side  but want to make sure that, Is this acceptable in lease file ?
or do we need to add any parameter in the config to avoid such duplicates in lease file?

Thanks in Advance.




On Thu, Sep 26, 2019 at 10:35 PM Simon Hobson <[hidden email]> wrote:
Surya Teja <[hidden email]> wrote:

> I have an issue with dhcpd service restart when it handles a bulk lease data. As part of testing I have simulated the dhcp server to lease test using dhcperf tool to check the performance statistics when the dhcpserver handles a huge lease data Ex :300689(3M). It is taking 3 to 4 minutes of duration to start up the service, Is this the expected behaviour when we have a such large lease file ? (FYI: No memory, disk space problem on the system)
>
>  When I restarted dhcpd in the log message I have a seen statement like
>  Wrote 300689 leases to leases file.
> Does the restart dhcpd will rewrite the lease file again?
> I also observed  as new lease file with extension ~ at end like after restart dhcpd
> I see two lease file one with dhcpd.leases and other dhcpd.leases~
>  If it is not expected behaviour can anyone have any reference tool or steps to check what is taking time to bring the service up

It is a known issue that the server can take some time to start up when there is a large number of potential addresses in the defined pools. The reason for this being the way the server builds hashing tables internally. It is probably to be expected as well in the situation you've described - it must read the leases file and process each lease in turn, updating the internal structures as it goes.

The leases file is a log file database - nothing is ever changed, only new entries added at the end. Obviously, such a file would grow without bounds over time without some sort of cleanup routine. Periodically, default is every hour, the server will write out a fresh leases file from it's internal structures - this file will contain no duplicate entries. It writes this to a new file, moves the existing lease file to a backup name (the one with "~" on the end), and moves the new file into place as the active leases file. The leases file is ONLY read at server startup and never after that - everything is done from in memory structures. In between cleanups as detailed above, every time anything changes, a new record is appended to the on-disk leases file.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Simon Hobson
Surya Teja <[hidden email]> wrote:
>
> Hi Simon Thanks for reply,
>  Periodically, default is every hour, the server will write out a fresh leases file from it's internal structures  --->
> I have a doubt when the server write out a fresh leases file from it's internal structures will the dhcpd service be in off state at this duration?

The question is a little ambiguous.
If you mean, will this happen while the server is stopped, no it won't.
If you mean, does the server stop serving clients while it's doing this, AFAIK it continues as normal.

>> this file will contain no duplicate entries --->
> Hi I have seen the duplicate entry in my server lease file
>  sample  snippet:
> ==============
> lease 192.168.2.52 {
>   starts 5 2019/09/27 07:21:32;
>   ends 5 2019/09/27 08:21:32;
>   tstp 5 2019/09/27 08:51:32;
>   tsfp 5 2019/09/27 08:21:32;
>   cltt 5 2019/09/27 07:21:32;
>   binding state active;
>   next binding state expired;
>   hardware ethernet 70:bb:e9:37:d9:9e;
>   uid "\001p\273\3517\331\236";
>   set vendor-class-identifier = "android-dhcp-9";
>   client-hostname "RedmiNote6Pro";
> }
> lease 192.168.2.52 {
>   starts 5 2019/09/27 07:21:32;
>   ends 5 2019/09/27 08:21:32;
>   tstp 5 2019/09/27 08:51:32;
>   tsfp 5 2019/09/27 08:51:32;
>   atsfp 5 2019/09/27 08:51:32;
>   cltt 5 2019/09/27 07:21:32;
>   binding state active;
>   next binding state expired;
>   hardware ethernet 70:bb:e9:37:d9:9e;
>   uid "\001p\273\3517\331\236";
>   set vendor-class-identifier = "android-dhcp-9";
>   client-hostname "RedmiNote6Pro";
> }
> Yes It has same data, I don't see any issue on client side  but want to make sure that, Is this acceptable in lease file ?

The lease file will be clean **immediately** after it's been re-written. Once clients are served, then new records will be appended and there is likely to be more than one record for some clients.
Looking at the above, are you running failover ? If so, then I suspect one of the records is from the partner server making an offer to a client at the same time as this server does.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Teja
If you mean, does the server stop serving clients while it's doing this, AFAIK it continues as normal. --->
Yes Simon, I mean this scenario Thanks for that clarification
 Looking at the above, are you running failover ? If so, then I suspect one of the records is from the partner server making an offer to a client at the same time as this server does.---->
Yes I am running failover. but when the entry is shared from the failover generally the binding state will be like backup right? but here in my case i see both the entries as 
binding state active;  thus I got a doubt about this duplicate. 

On Fri, Sep 27, 2019 at 10:51 PM Simon Hobson <[hidden email]> wrote:
Surya Teja <[hidden email]> wrote:
>
> Hi Simon Thanks for reply,
>  Periodically, default is every hour, the server will write out a fresh leases file from it's internal structures  --->
> I have a doubt when the server write out a fresh leases file from it's internal structures will the dhcpd service be in off state at this duration?

The question is a little ambiguous.
If you mean, will this happen while the server is stopped, no it won't.
If you mean, does the server stop serving clients while it's doing this, AFAIK it continues as normal.

>> this file will contain no duplicate entries --->
> Hi I have seen the duplicate entry in my server lease file
>  sample  snippet:
> ==============
> lease 192.168.2.52 {
>   starts 5 2019/09/27 07:21:32;
>   ends 5 2019/09/27 08:21:32;
>   tstp 5 2019/09/27 08:51:32;
>   tsfp 5 2019/09/27 08:21:32;
>   cltt 5 2019/09/27 07:21:32;
>   binding state active;
>   next binding state expired;
>   hardware ethernet 70:bb:e9:37:d9:9e;
>   uid "\001p\273\3517\331\236";
>   set vendor-class-identifier = "android-dhcp-9";
>   client-hostname "RedmiNote6Pro";
> }
> lease 192.168.2.52 {
>   starts 5 2019/09/27 07:21:32;
>   ends 5 2019/09/27 08:21:32;
>   tstp 5 2019/09/27 08:51:32;
>   tsfp 5 2019/09/27 08:51:32;
>   atsfp 5 2019/09/27 08:51:32;
>   cltt 5 2019/09/27 07:21:32;
>   binding state active;
>   next binding state expired;
>   hardware ethernet 70:bb:e9:37:d9:9e;
>   uid "\001p\273\3517\331\236";
>   set vendor-class-identifier = "android-dhcp-9";
>   client-hostname "RedmiNote6Pro";
> }
> Yes It has same data, I don't see any issue on client side  but want to make sure that, Is this acceptable in lease file ?

The lease file will be clean **immediately** after it's been re-written. Once clients are served, then new records will be appended and there is likely to be more than one record for some clients.
Looking at the above, are you running failover ? If so, then I suspect one of the records is from the partner server making an offer to a client at the same time as this server does.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

sthaug
> Yes I am running failover. but when the entry is shared from the failover
> generally the binding state will be like *backup* right? but here in my
> case i see both the entries as
> *binding state active;*  thus I got a doubt about this duplicate.

If a DHCP binding is active, in a failover configuration, you should
expect to see it as active on *both* servers.

Steinar Haug, Nethelp consulting, [hidden email]
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Teja
Hi all,
While performing the tests with dhcperf tool, I also observed one more lease file getting generated with a random number appending at last of the file name like 
dhcpd.leases.1571736969 ,  I observed this after doing the restart of the dhcpd service,
Deleted the file and perform the test again, after the second restart it again created one more random file
 -rw-r--r-- 1 root root 6795717 Oct 23 13:14 dhcpd.leases
-rw-r--r-- 1 root root 4386656 Oct 23 13:06 dhcpd.leases~
-rw-r--r-- 1 root root 2433024 Oct 23 13:15 dhcpd.leases.1571836505
What does this file mean ? 
I tried online to check about this, but no references where found regarding the file generated like this 
What does this indicates ?

Thanks in Advance  


On Sun, Sep 29, 2019 at 4:11 PM <[hidden email]> wrote:
> Yes I am running failover. but when the entry is shared from the failover
> generally the binding state will be like *backup* right? but here in my
> case i see both the entries as
> *binding state active;*  thus I got a doubt about this duplicate.

If a DHCP binding is active, in a failover configuration, you should
expect to see it as active on *both* servers.

Steinar Haug, Nethelp consulting, [hidden email]

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Sten Carlsen

Looks like a Unix time to me. -> Wednesday, 23 October 2019 at 15.15.05 CEST

On 23-10-2019 15.33, Surya Teja wrote:
Hi all,
While performing the tests with dhcperf tool, I also observed one more lease file getting generated with a random number appending at last of the file name like 
dhcpd.leases.1571736969 ,  I observed this after doing the restart of the dhcpd service,
Deleted the file and perform the test again, after the second restart it again created one more random file
 -rw-r--r-- 1 root root 6795717 Oct 23 13:14 dhcpd.leases
-rw-r--r-- 1 root root 4386656 Oct 23 13:06 dhcpd.leases~
-rw-r--r-- 1 root root 2433024 Oct 23 13:15 dhcpd.leases.1571836505
What does this file mean ? 
I tried online to check about this, but no references where found regarding the file generated like this 
What does this indicates ?

Thanks in Advance  


On Sun, Sep 29, 2019 at 4:11 PM <[hidden email]> wrote:
> Yes I am running failover. but when the entry is shared from the failover
> generally the binding state will be like *backup* right? but here in my
> case i see both the entries as
> *binding state active;*  thus I got a doubt about this duplicate.

If a DHCP binding is active, in a failover configuration, you should
expect to see it as active on *both* servers.

Steinar Haug, Nethelp consulting, [hidden email]

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
-- 
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!" 

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Teja
Looks like a Unix time to me. -> Wednesday, 23 October 2019 at 15.15.05
CEST-->

Sorry I don't understand while this file is being created, when the restart
of the dhcpd was done in general it will create new dhcpd.lease file and old
data or backup data will there in dhcpd.leases~. But I am getting one more
extra file with time appending to it, Is that defines an issues or any
conflicts in lease file ?



--
Sent from: http://isc-dhcp-users.2343191.n4.nabble.com/
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Sten Carlsen

On 24-10-2019 06.28, Teja wrote:
> Looks like a Unix time to me. -> Wednesday, 23 October 2019 at 15.15.05
> CEST-->
>
> Sorry I don't understand while this file is being created, when the restart
> of the dhcpd was done in general it will create new dhcpd.lease file and old
> data or backup data will there in dhcpd.leases~. But I am getting one more
> extra file with time appending to it, Is that defines an issues or any
> conflicts in lease file ?

I don't see this kind of file, I could think it was a filename as part
of the renaming of the leases file used very temporary.

Anyone knows this?

>
>
>
> --
> Sent from: http://isc-dhcp-users.2343191.n4.nabble.com/
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

--
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!"

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Teja
FYI: The file with time appending is observer when I have tested with large bulk load , 
When the test are running with limited load, I have restarted multiple times and didn't observed any such file 
will it generates the multiple backup files when the data is too big?
like dhcpd.lease ----> org file
      dhcpd.leases~ -----> backup1
       dhcpd.leases.<time_stamp> ----> backup2


On Thu, Oct 24, 2019 at 1:10 PM Sten Carlsen <[hidden email]> wrote:

On 24-10-2019 06.28, Teja wrote:
> Looks like a Unix time to me. -> Wednesday, 23 October 2019 at 15.15.05
> CEST-->
>
> Sorry I don't understand while this file is being created, when the restart
> of the dhcpd was done in general it will create new dhcpd.lease file and old
> data or backup data will there in dhcpd.leases~. But I am getting one more
> extra file with time appending to it, Is that defines an issues or any
> conflicts in lease file ?

I don't see this kind of file, I could think it was a filename as part
of the renaming of the leases file used very temporary.

Anyone knows this?

>
>
>
> --
> Sent from: http://isc-dhcp-users.2343191.n4.nabble.com/
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

--
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!"

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Simon Hobson
Surya Teja <[hidden email]> wrote:

> will it generates the multiple backup files when the data is too big?
> like dhcpd.lease ----> org file
>       dhcpd.leases~ -----> backup1
>        dhcpd.leases.<time_stamp> ----> backup2

No. The server writes out a new file, renames the existing one (deleting the old backup in the process), then renames the new one into place.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Glenn Satchell
On 2019-10-29 07:31, Simon Hobson wrote:

> Surya Teja <[hidden email]> wrote:
>
>> will it generates the multiple backup files when the data is too big?
>> like dhcpd.lease ----> org file
>>       dhcpd.leases~ -----> backup1
>>        dhcpd.leases.<time_stamp> ----> backup2
>
> No. The server writes out a new file, renames the existing one
> (deleting the old backup in the process), then renames the new one
> into place.

Hi Surya,

Maybe you need to look at the source code to see the conditions under
which this file is created?

regards,
-glenn
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Teja
Hi, I am not familiar with c code(source code) but I will try to go through, 
The main thing I am facing the issue is when the data is too high like 50-60k leases in the file, the dhcpd service restart is taking more time (nearly 5-6 minutes) some times nearly 10-11 mins, At these duration the network area will be like blackout, no user can connect to network
which is making me panic to perform restarts (I am doing the restarts because If the config is changed like any new statement added then we need to stop and start the dhcpd to get the new changes work)
 I am suspecting writing the data into lease file is taking time (not sure)  
Do we have any suggested techniques which can reduce the time taken by the service to up, or any parameter which controls the behavior of lease file writing


Thanks
Teja

On Tue, Oct 29, 2019 at 9:00 AM <[hidden email]> wrote:
On 2019-10-29 07:31, Simon Hobson wrote:
> Surya Teja <[hidden email]> wrote:
>
>> will it generates the multiple backup files when the data is too big?
>> like dhcpd.lease ----> org file
>>       dhcpd.leases~ -----> backup1
>>        dhcpd.leases.<time_stamp> ----> backup2
>
> No. The server writes out a new file, renames the existing one
> (deleting the old backup in the process), then renames the new one
> into place.

Hi Surya,

Maybe you need to look at the source code to see the conditions under
which this file is created?

regards,
-glenn
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

sthaug
> The main thing I am facing the issue is when the data is too high like
> 50-60k leases in the file, the dhcpd service restart is taking more time
> (nearly 5-6 minutes) some times nearly 10-11 mins

If a dhcpd restart with 50 - 60k leases takes 5-6 minutes or more,
you're doing something wrong. With a decent disk subsystem this is
expected to take a few *seconds* (5 - 10 seconds would be my estimate
based on what we see here with a larger leases file).

Steinar Haug, Nethelp consulting, [hidden email]
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Sten Carlsen


> On 29 Oct 2019, at 11.20, [hidden email] wrote:
>
>> The main thing I am facing the issue is when the data is too high like
>> 50-60k leases in the file, the dhcpd service restart is taking more time
>> (nearly 5-6 minutes) some times nearly 10-11 mins
>
> If a dhcpd restart with 50 - 60k leases takes 5-6 minutes or more,
> you're doing something wrong. With a decent disk subsystem this is
> expected to take a few *seconds* (5 - 10 seconds would be my estimate
> based on what we see here with a larger leases file).

Could there be issues with file permissions?

My guess is that the temporary file written can not be renamed because dhcpd does not have write permissions?

>
> Steinar Haug, Nethelp consulting, [hidden email]
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Teja
you're doing something wrong. With a decent disk subsystem this is expected to take a few *seconds* (5 - 10 seconds would be my estimate ) ---->
Hi  sthaug I don't see any disk subsystem issues, may be I am missing the cases, can you please suggest the areas or commands to cross check if possible?


Thanks Teja

On Tue, Oct 29, 2019 at 5:13 PM Sten Carlsen <[hidden email]> wrote:


> On 29 Oct 2019, at 11.20, [hidden email] wrote:
>
>> The main thing I am facing the issue is when the data is too high like
>> 50-60k leases in the file, the dhcpd service restart is taking more time
>> (nearly 5-6 minutes) some times nearly 10-11 mins
>
> If a dhcpd restart with 50 - 60k leases takes 5-6 minutes or more,
> you're doing something wrong. With a decent disk subsystem this is
> expected to take a few *seconds* (5 - 10 seconds would be my estimate
> based on what we see here with a larger leases file).

Could there be issues with file permissions?

My guess is that the temporary file written can not be renamed because dhcpd does not have write permissions?

>
> Steinar Haug, Nethelp consulting, [hidden email]
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Teja
Could there be issues with file permissions?
My guess is that the temporary file written can not be renamed because dhcpd does not have write permissions?   ------>
Hi Sten, I don't think it is with permission because after few minutes dhcpd is restarting and granting lease, the issue is it is taking long time,
In the isc dhcp forum I observed few options like  dont-use-fsync but it also suggest not recommended until thorough understanding OS 
I have installed the dhcpd on centos7, does any one have used this option? Any experience with it would be much helpful for me     

Thanks in advance

On Tue, Oct 29, 2019 at 6:12 PM Surya Teja <[hidden email]> wrote:
you're doing something wrong. With a decent disk subsystem this is expected to take a few *seconds* (5 - 10 seconds would be my estimate ) ---->
Hi  sthaug I don't see any disk subsystem issues, may be I am missing the cases, can you please suggest the areas or commands to cross check if possible?


Thanks Teja

On Tue, Oct 29, 2019 at 5:13 PM Sten Carlsen <[hidden email]> wrote:


> On 29 Oct 2019, at 11.20, [hidden email] wrote:
>
>> The main thing I am facing the issue is when the data is too high like
>> 50-60k leases in the file, the dhcpd service restart is taking more time
>> (nearly 5-6 minutes) some times nearly 10-11 mins
>
> If a dhcpd restart with 50 - 60k leases takes 5-6 minutes or more,
> you're doing something wrong. With a decent disk subsystem this is
> expected to take a few *seconds* (5 - 10 seconds would be my estimate
> based on what we see here with a larger leases file).

Could there be issues with file permissions?

My guess is that the temporary file written can not be renamed because dhcpd does not have write permissions?

>
> Steinar Haug, Nethelp consulting, [hidden email]
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Sten Carlsen



On 29 Oct 2019, at 13.49, Surya Teja <[hidden email]> wrote:

Could there be issues with file permissions?
My guess is that the temporary file written can not be renamed because dhcpd does not have write permissions?   ------>
Hi Sten, I don't think it is with permission because after few minutes dhcpd is restarting and granting lease, the issue is it is taking long time,

I was thinking that since it leaves the .<time> file present, it may have problems doing the file operations. 
I did some experimenting, whatever way I make the files write protected, dhcpd manages to change them back. The only thing I did not test is SELinux.

In the isc dhcp forum I observed few options like  dont-use-fsync but it also suggest not recommended until thorough understanding OS 
I have installed the dhcpd on centos7, does any one have used this option? Any experience with it would be much helpful for me     

Thanks in advance

On Tue, Oct 29, 2019 at 6:12 PM Surya Teja <[hidden email]> wrote:
you're doing something wrong. With a decent disk subsystem this is expected to take a few *seconds* (5 - 10 seconds would be my estimate ) ---->
Hi  sthaug I don't see any disk subsystem issues, may be I am missing the cases, can you please suggest the areas or commands to cross check if possible?


Thanks Teja

On Tue, Oct 29, 2019 at 5:13 PM Sten Carlsen <[hidden email]> wrote:


> On 29 Oct 2019, at 11.20, [hidden email] wrote:
>
>> The main thing I am facing the issue is when the data is too high like
>> 50-60k leases in the file, the dhcpd service restart is taking more time
>> (nearly 5-6 minutes) some times nearly 10-11 mins
>
> If a dhcpd restart with 50 - 60k leases takes 5-6 minutes or more,
> you're doing something wrong. With a decent disk subsystem this is
> expected to take a few *seconds* (5 - 10 seconds would be my estimate
> based on what we see here with a larger leases file).

Could there be issues with file permissions?

My guess is that the temporary file written can not be renamed because dhcpd does not have write permissions?

>
> Steinar Haug, Nethelp consulting, [hidden email]
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users



_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DHCP restart with bulk lease data

Teja
I was thinking that since it leaves the .<time> file present, it may have problems doing the file operations. 
I did some experimenting, whatever way I make the files write protected, dhcpd manages to change them back. The only thing I did not test is SELinux.
-------> Sten, can you suggest few steps to cross check on how to confirm that would be file operations issues when it has bulk data

On Tue, Oct 29, 2019 at 7:11 PM Sten Carlsen <[hidden email]> wrote:



On 29 Oct 2019, at 13.49, Surya Teja <[hidden email]> wrote:

Could there be issues with file permissions?
My guess is that the temporary file written can not be renamed because dhcpd does not have write permissions?   ------>
Hi Sten, I don't think it is with permission because after few minutes dhcpd is restarting and granting lease, the issue is it is taking long time,

I was thinking that since it leaves the .<time> file present, it may have problems doing the file operations. 
I did some experimenting, whatever way I make the files write protected, dhcpd manages to change them back. The only thing I did not test is SELinux.

In the isc dhcp forum I observed few options like  dont-use-fsync but it also suggest not recommended until thorough understanding OS 
I have installed the dhcpd on centos7, does any one have used this option? Any experience with it would be much helpful for me     

Thanks in advance

On Tue, Oct 29, 2019 at 6:12 PM Surya Teja <[hidden email]> wrote:
you're doing something wrong. With a decent disk subsystem this is expected to take a few *seconds* (5 - 10 seconds would be my estimate ) ---->
Hi  sthaug I don't see any disk subsystem issues, may be I am missing the cases, can you please suggest the areas or commands to cross check if possible?


Thanks Teja

On Tue, Oct 29, 2019 at 5:13 PM Sten Carlsen <[hidden email]> wrote:


> On 29 Oct 2019, at 11.20, [hidden email] wrote:
>
>> The main thing I am facing the issue is when the data is too high like
>> 50-60k leases in the file, the dhcpd service restart is taking more time
>> (nearly 5-6 minutes) some times nearly 10-11 mins
>
> If a dhcpd restart with 50 - 60k leases takes 5-6 minutes or more,
> you're doing something wrong. With a decent disk subsystem this is
> expected to take a few *seconds* (5 - 10 seconds would be my estimate
> based on what we see here with a larger leases file).

Could there be issues with file permissions?

My guess is that the temporary file written can not be renamed because dhcpd does not have write permissions?

>
> Steinar Haug, Nethelp consulting, [hidden email]
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users



_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
12