[isp-dns] Re: BIND vs. Sendmail + MIMEDefang/SpamAssassin etc.

["Masood Ahmad Shah" <masood@...>]

Locking a Memory Object
You can lock and unlock a shared-memory segment into physical memory to
eliminate paging. The MCL_FUTURE argument to the mlockall function causes
new shared-memory regions to be locked automatically.
Example  shows how to map a file into the address space of the process and
lock it into memory. When the file is unmapped, the lock on the address is
removed.


/* This program locks the virtual memory address that */
/* was returned from the mmap() function into memory. */

#include <unistd.h>
#include <sys/types.h>
#include <stdio.h>
#include <sys/file.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <errno.h>

main()
{
int fd;
caddr_t pg_addr;

int size = 5000;
int mode =  S_IRWXO|S_IRWXG|S_IRWXU;

     /* Create a file */

fd = shm_open("example", O_RDWR|O_CREAT, mode);
if(fd < 0){
   perror("open error ");
   exit();
}

     /* Set the size */

if((ftruncate(fd, size)) == -1){
     perror("ftruncate failure");
     exit();
}

     /* Map the file into the address space of the process */
pg_addr = (caddr_t) mmap(0, size, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_SHARED,
                         fd, 0);

if(pg_addr == (caddr_t) -1){
  perror("mmap failure");
  exit();
}

     /* Lock the mapped region into memory */

if(mlock(pg_addr,size) != 0){
  perror("mlock failure");
  exit();
}

     /* Unmap of the address region removes the memory lock */
     /* established on the address region by this process   */

if(munmap(pg_addr, size) < 0)
   perror("unmap error");
close(fd);
shm_unlink("example");
exit();
}




Best Regds,
Masood Ahmad Shah
Nexlinx
http://nexlinx.net.pk
http://weblogs.com.pk/jahil


----- Original Message ----- 
From: <wrolf.courtney@...>
To: "Masood Ahmad Shah" <masood@....pk>
Cc: <bind9-users@...>
Sent: Tuesday, May 04, 2004 12:31 AM
Subject: Re: BIND vs. Sendmail + MIMEDefang/SpamAssassin etc.


>
>
>
>
>
> Thanks Masood.
>
> My problem is not that named goes down.
>
> It just does not respond to UDP queries for a while.
>
> My guess is that it is not responding (fast enough) when the system load
is
> high, and swapping activity is high.
>
> Is there anyway that named can be locked into memory, using e.g.
mlockall()
> in Linux?
>
> Wrolf Courtney
>
> "Masood Ahmad Shah" <masood@....pk> wrote on 04/03/2004 01:49:23
> AM:
>
> > spamassassin sendmail and if you have mysql all are memory hungry. if
> named
> > process goes down after sometime and swap exceed. check your ram.
> >
> > you can use DAEMONTOOLS
> http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
> > to run automatically whenever your named process goes down.
> >
> > Best Regds,
> > Masood Ahmad Shah
> > Nexlinx
> > http://nexlinx.net.pk
> > http://weblogs.com.pk/jahil
> >
> >
> > ----- Original Message -----
> > From: <wrolf.courtney@...>
> > To: <bind9-users@...>
> > Cc: <pat.moore@...>
> > Sent: Saturday, May 01, 2004 1:53 AM
> > Subject: BIND vs. Sendmail + MIMEDefang/SpamAssassin etc.
> >
> >
> > >
> > >
> > >
> > >
> > > On two boxes with RedHat 7.2 kernel 2.4.20-28.7 running BIND 9.2.1
> (from
> > > bind-9.2.1-1.7x.2 rpm) and Sendmail, we have the problem that when the
> > > sendmail gets flooded with messages, some swapping occurs, and named
> stops
> > > responding temporarily.
> > >
> > > We can mostly only see this in monitoring software, but occassionally
> it
> > > gives our applications problems.
> > >
> > > The trouble *seems* to be when the load average gets over 15.  The
main
> > > thing going on then is a lot of swapping - I do not know for sure that
> > this
> > > is the problem.
> > >
> > > Is there any way to have named signal that it wants to stay in memory
> all
> > > the time.  E.g.
> > >
> > > #include <unistd.h>
> > > #ifdef _POSIX_MEMLOCK_RANGE
> > > #include <sys/mman.h>
> > > #endif
> > >
> > > ...
> > >         int e;
> > >
> > > #ifdef _POSIX_MEMLOCK_RANGE
> > >         e = mlockall( MCL_CURRENT|MCL_FUTURE);
> > > #endif
> > >
> > > (Before it drops root privileges.)
> > >
> > > Wrolf Courtney
> > > Donovan Data Systems, Inc.
> > > (212) 633-5470
> > >
> > >
> >
> >
>







To unsubscribe via postal mail, please contact us at:
Jupitermedia Corp.
Attn: Discussion List Management
475 Park Avenue South
New York, NY 10016

Please include the email address which you have been contacted with.