Named

[Jiri Pavlovsky]

On 14 Aug 1998 21:00:21 +0200, Michal Krause <mike na navrcholu.cz> wrote:
>> On 14 Aug 1998 11:49:42 +0200, Michal Krause <mike na navrcholu.cz> wrote:
>> >Chci se zeptat, jestli je bezne, aby zabiral daemon bind cca 11 MB pameti (je to
>> >primarni NS cca pro 10 domen).
>> >Zda se mi to trochu moc. Neni mozne, ze behem provozu pomalicku roste (nekde
>> >neco neuvolnuje)?
>> 
>> Pokud je ten server hodne vytizeny, tak to klidne jeste muze rust.
>> Videl jsem i named, ktery zabiral >50MB.
>
>No, nechci to precenovat, ale je to urcite jeden z nejvytizenejsich serveru v
>ceskem Internetu. Zkusmo jsem binda restartnul a zacal na 1,3 MB. Za hodinu uz
>mel vice nez 2 MB.

Rust spotreby pameti se po nejake dobe stabilizuje. Na jake hodnote - to zavisi na faktorech,
ktere neznam.
Pro informaci posilam excerpt z FAQ comp.protocols.tcp-ip.domains. Omlouvam se za off-topic...

Jiri Pavlovsky
jirap na bajt.cz

--------------------
Question 2.11. How memory and CPU does DNS use ?

   It can use quite a bit ! The main thing that BIND needs is memory. It uses very little CPU or network bandwidth. The main considerations to keep
   in mind when planning are:
     * How many zones do you have and how large are they ?
     * How many clients do you expect to serve and how active are they ?
       
   As an example, here is a snapshot of memory usage from CSIRO Division of Mathematics and Statistics, Australia
      Named takes several days to stabilize its memory usage.

      Our main server stabalises at ~10Mb. It takes about 3 days to
      reach this size from 6 M at startup. This is under Sun OS 4.1.3U1.

   As another example, here is the configuration of ns.uu.net (from late 1994):
      ns.uu.net only does nameservice.  It is running a version of BIND
      4.9.3 on a Sun Classic with 96 MB of RAM, 220 MB of swap (remember
      that Sun OS will reserve swap for each fork, even if it is not needed)
      running Sun OS 4.1.3_U1.

      Joseph Malcolm, of Alternet, states that named generally hovers at
      5-10% of the CPU, except after a reload, when it eats it all.

Question 2.12. Other things to consider when planning your servers

   When making the plans to set up your servers, you may want to also consider the following issues:
        A) Server O/S limitations/capacities (which tend to be widely
           divergent from vendor to vendor)
        B) Client resolver behavior (even more widely divergent)
        C) Expected query response time
        D) Redundancy
        E) Desired speed of change propagation
        F) Network bandwidth availability
        G) Number of zones/subdomain-levels desired
        H) Richness of data stored (redundant MX records? HINFO records?)
        I) Ease of administration desired
        J) Network topology (impacts reverse-zone volume)

  Assuming a best-possible case for the factors above, particularly (A), (B),
  (C), (F), (G) & (H), it would be possible to run a 1000-node domain
  using a single lowly 25 or 40 MHz 386 PC with a fairly modest amount of RAM
  by today's standards, e.g. 4 or 8 Meg.   However, this configuration would
  be slow, unreliable, and would provide no functionality beyond your basic
  address-to-name and name-to-address mappings.

  Beyond that baseline case, depending on what factors listed above,
  you may want look at other strategies, such splitting up the DNS
  traffic among several machines strategically located, possibly larger ones,
  and/or subdividing your domain itself. There are many options, tradeoffs,
  and DNS architectural paradigms from which to choose.