|
|
12
|
|
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
|
|
|
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
|
|
|
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.
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
|
|
|
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
|
|
|
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.
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
|
|
|
> 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
|
|
|
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. 1571836505What 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
> 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
|
|
|
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
>
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
|
|
|
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
|
|
|
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
|
|
|
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 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
|
|
|
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
|
|
|
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
|
|
|
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 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
|
|
|
> 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
|
|
|
> 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
|
|
|
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 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
|
|
|
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 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 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
|
|
|
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 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 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
|
|
|
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
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 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 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
|
Locked
