Re: Thoughts on a large-scale DNS server...

From: Matthew D. Fuller (fullermd_at_over-yonder.net)
Date: 06/29/05

  • Next message: Jon Simola: "Re: Thoughts on a large-scale DNS server..." 
    Date: Tue, 28 Jun 2005 22:55:44 -0500
To: John Von Essen <john@essenz.com>

    Just a few comments...

    On Tue, Jun 28, 2005 at 10:42:59AM -0400 I heard the voice of
    John Von Essen, and lo! it spake thus:
    >
    > The plan is to have 3 core machines. One is the master, and gets its
    > zone files created from local cvs exports. The other two are slaves,
    > and do zone transfers from the master.

    I've converted for most non-trivial configs to using external
    synchronization (rsync or rdist or the like, generally) instead of
    zone transfers. I'd just make them all 'masters' with their own local
    copies; that reduces your failure points (or at least moves them
    around a bit).

    > The first question is, do I have enough CPU/Memory. Keep in mind
    > these machines will nothing but DNS.

    CPU? Sure. Memory? Quite probably. Even if you assume each zone
    will eat 64k of memory (which I think it a terribly high guess; at
    least double what you'd really expect), 11,000 zones will burn less
    than 700 meg. I'd probably be tempted to double the memory, just
    because memory is cheap&easy, but I doubt you'll be hitting a wall on
    it. 

    -- 
Matthew Fuller     (MF4839)   |  fullermd@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.
_______________________________________________
freebsd-isp@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isp
To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org"
  • Next message: Jon Simola: "Re: Thoughts on a large-scale DNS server..."

    Relevant Pages

    • Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 - Summary
      ... With the zone approach, we would just be saying "tune it". ... In the context of hotplug stuff and fragmentation avoidance, ... Just leave that memory plugged ... the patches give a kernel allocator that is as good as ...
      (Linux-Kernel)
    • Re: Commit for mm/page_alloc.c breaks boot process on my machine
      ... Is there any chance that all of your memory is not being properly ... Also the memory zone initialization looks ... The kernel boots fine until loading INIT, if it is compiled with this ... Movable zone start PFN for each node ...
      (Linux-Kernel)
    • [PATCH 23/34] mm: page-replace-documentation.patch
      ... +virtual memory subsystem. ... +which memory pages to evict is called the replacement policy. ... +separately for each zone, therefore "struct zone" embeds the following ...
      (Linux-Kernel)
    • Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 - Summary
      ... where the workload is not using all of physical memory, ... Physical Hotplug remove: Hotplug remove needs to be able to free a large ... New Zone: Add a new zone for easyrclm only allocations. ... Future work for scenario 1 ...
      (Linux-Kernel)
    • Re: High lock spin time for zone->lru_lock under extreme conditions
      ... We noticed high interrupt hold off times while running some memory intensive ... that spin_lock_irq disables interrupts while spinning made matters very bad. ... By buffering the lru pages on a per cpu basis the flush of that buffer ... Streeamline all this by replacing the per cpu buffer with a per zone ...
      (Linux-Kernel)
    • Quantcast