| To: | dns@list.cr.yp.to |
|---|---|
| Subject: | Re: 64bit dnscache |
| From: | Jeff King <peff@peff.net> |
| Date: | Sun, 4 Feb 2007 04:22:45 -0500 |
| Delivered-to: | sp-com-lists@consult.net |
| Delivered-to: | gmail-djbdns@securepoint.com |
| Delivered-to: | sp.com.list@gmail.com |
| Delivered-to: | mailing list dns@list.cr.yp.to |
| In-reply-to: | <45C5A0D2.5060005@jeremykister.com> |
| Mail-followup-to: | dns@list.cr.yp.to |
| Mailing-list: | contact dns-help@list.cr.yp.to; run by ezmlm |
| References: | <45C597CE.9060901@jeremykister.com> <20070204084510.GA12679@coredump.intra.peff.net> <45C5A0D2.5060005@jeremykister.com> |
On Sun, Feb 04, 2007 at 04:01:06AM -0500, Jeremy Kister wrote: > but when i bump up the limits, > # grep . DATALIMIT CACHESIZE > DATALIMIT:5368709120 > CACHESIZE:5000000000 > > top shows: > 849 dnscache 1 59 0 675M 674M sleep 0:03 0.00% dnscache > > Any new clues ? Do you know the size of an unsigned int on your machine? The cache size is scanned as an unsigned long, but then is passed to to cache_init (and to alloc) as an unsigned int. It's possible there's some truncation there, so changing those function signatures to unsigned long might help. I don't have such a huge machine to play with, but the cache allocation code is pretty simple. If you can, try stepping through it in the debugger and keeping an eye on size as it is passed around. -Peff |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: 64bit dnscache, Jeremy Kister |
|---|---|
| Next by Date: | Re: 64bit dnscache, Sami Farin |
| Previous by Thread: | Re: 64bit dnscache, Jeremy Kister |
| Next by Thread: | Re: 64bit dnscache, Sami Farin |
| Indexes: | [Date] [Thread] [Top] [All Lists] |