Re: Process size versus cache size.
On Wed, Jul 23, 2014 at 02:15:34PM -0400, Thomas Schulz wrote: In investigating an out of memory error on a Solaris 8 Sparc machine (compiled as a 32 bit executable), I find that the process size increase due to the cache does not make sense. Over about a week the process size had grown to 257 MB, up from an initial size of 36 MB. But when I dumped the cache with rndc dumpdb -cache, the resulting named_dump.db file was only 6 MB in size. Given the way the file is formatted, I would expect that the in memory version would be smaller than that. But when I did a 'rndc flush', the process stopped growing for about the same number of days that it took to reach 257 MB. That indicates that the increase in process size really is due to the cache. The increase in process size from 36 MB to 257 MB does not make sense given that the cache dump is only 6 MB. What version of BIND is this? And do you use statistics-channel? I'd be interested to see what the memory stats look like on a running server. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. I have tried both BIND 9.9.5-P1 and 9.9.6b1. The figures given above were for 9.9.6b1. I do not have a statistics-channel set up or anything having to do with logging set up. I have since rebuilt BIND as a 64 bit executable, so I expect that I will not have out of memory errors again. But I am seeing the same unexpected increase in process size. The 64 bit named has now run for slightly over 3 weeks without hanging up with an out of memory error (the 32 bit named would die in about 10 days). The process size has grown to 513 MB, up from an initial size of 36 MB, amd is still growing. This time rndc dumpdb -cache produced a 4.8 MB file. I am now redoing my previous experiment with rndc flush to verify that this is really a problem with the cache. If the process size stays the same for 3 weeks and then starts to grow again, then I think that we can conclude that there is something funny going on with the cache. Evan: if there is some debugging you would like me to do, let me know. Preferably something that does not require killing and restarting the process, at least not for a few weeks. The process size was stable at 513 MB for 18 days (not quite 3 weeks) and then started growing again. So it does look like the growth in the process size is mostly due to the cache. The process size is now up to 529 MB. The next thing to do is to just let it run and see if it ever stops growing. I still think that there is something funny going on with the cache. Tom Schulz Applied Dynamics Intl. sch...@adi.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Process size versus cache size.
On Wed, Jul 23, 2014 at 02:15:34PM -0400, Thomas Schulz wrote: In investigating an out of memory error on a Solaris 8 Sparc machine (compiled as a 32 bit executable), I find that the process size increase due to the cache does not make sense. Over about a week the process size had grown to 257 MB, up from an initial size of 36 MB. But when I dumped the cache with rndc dumpdb -cache, the resulting named_dump.db file was only 6 MB in size. Given the way the file is formatted, I would expect that the in memory version would be smaller than that. But when I did a 'rndc flush', the process stopped growing for about the same number of days that it took to reach 257 MB. That indicates that the increase in process size really is due to the cache. The increase in process size from 36 MB to 257 MB does not make sense given that the cache dump is only 6 MB. What version of BIND is this? And do you use statistics-channel? I'd be interested to see what the memory stats look like on a running server. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. I have tried both BIND 9.9.5-P1 and 9.9.6b1. The figures given above were for 9.9.6b1. I do not have a statistics-channel set up or anything having to do with logging set up. I have since rebuilt BIND as a 64 bit executable, so I expect that I will not have out of memory errors again. But I am seeing the same unexpected increase in process size. The 64 bit named has now run for slightly over 3 weeks without hanging up with an out of memory error (the 32 bit named would die in about 10 days). The process size has grown to 513 MB, up from an initial size of 36 MB, amd is still growing. This time rndc dumpdb -cache produced a 4.8 MB file. I am now redoing my previous experiment with rndc flush to verify that this is really a problem with the cache. If the process size stays the same for 3 weeks and then starts to grow again, then I think that we can conclude that there is something funny going on with the cache. Even: if there is some debugging you would like me to do, let me know. Preferably something that does not require killing and restarting the process, at least not for a few weeks. Tom Schulz Applied Dynamics Intl. sch...@adi.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Process size versus cache size.
On Wed, Jul 23, 2014 at 02:15:34PM -0400, Thomas Schulz wrote: In investigating an out of memory error on a Solaris 8 Sparc machine (compiled as a 32 bit executable), I find that the process size increase due to the cache does not make sense. Over about a week the process size had grown to 257 MB, up from an initial size of 36 MB. But when I dumped the cache with rndc dumpdb -cache, the resulting named_dump.db file was only 6 MB in size. Given the way the file is formatted, I would expect that the in memory version would be smaller than that. But when I did a 'rndc flush', the process stopped growing for about the same number of days that it took to reach 257 MB. That indicates that the increase in process size really is due to the cache. The increase in process size from 36 MB to 257 MB does not make sense given that the cache dump is only 6 MB. What version of BIND is this? And do you use statistics-channel? I'd be interested to see what the memory stats look like on a running server. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. I have tried both BIND 9.9.5-P1 and 9.9.6b1. The figures given above were for 9.9.6b1. I do not have a statistics-channel set up or anything having to do with logging set up. I have since rebuilt BIND as a 64 bit executable, so I expect that I will not have out of memory errors again. But I am seeing the same unexpected increase in process size. Tom Schulz Applied Dynamics Intl. sch...@adi.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Process size versus cache size.
In investigating an out of memory error on a Solaris 8 Sparc machine (compiled as a 32 bit executable), I find that the process size increase due to the cache does not make sense. Over about a week the process size had grown to 257 MB, up from an initial size of 36 MB. But when I dumped the cache with rndc dumpdb -cache, the resulting named_dump.db file was only 6 MB in size. Given the way the file is formatted, I would expect that the in memory version would be smaller than that. But when I did a 'rndc flush', the process stopped growing for about the same number of days that it took to reach 257 MB. That indicates that the increase in process size really is due to the cache. The increase in process size from 36 MB to 257 MB does not make sense given that the cache dump is only 6 MB. Tom Schulz Applied Dynamics Intl. sch...@adi.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Process size versus cache size.
On Wed, Jul 23, 2014 at 02:15:34PM -0400, Thomas Schulz wrote: In investigating an out of memory error on a Solaris 8 Sparc machine (compiled as a 32 bit executable), I find that the process size increase due to the cache does not make sense. Over about a week the process size had grown to 257 MB, up from an initial size of 36 MB. But when I dumped the cache with rndc dumpdb -cache, the resulting named_dump.db file was only 6 MB in size. Given the way the file is formatted, I would expect that the in memory version would be smaller than that. But when I did a 'rndc flush', the process stopped growing for about the same number of days that it took to reach 257 MB. That indicates that the increase in process size really is due to the cache. The increase in process size from 36 MB to 257 MB does not make sense given that the cache dump is only 6 MB. What version of BIND is this? And do you use statistics-channel? I'd be interested to see what the memory stats look like on a running server. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
