From per@erix.ericsson.se Mon Dec  9 12:54:58 EST 1996
Article: 27547 of news.software.nntp
Path: news.math.psu.edu!news3.cac.psu.edu!howland.erols.net!news-peer.gsl.net!news.gsl.net!news-stkh.gsl.net!news.gsl.net!eru.mt.luth.se!news.algonet.se!eua.ericsson.se!erix.ericsson.se!not-for-mail
From: per@erix.ericsson.se (Per Hedeland)
Newsgroups: news.software.nntp
Subject: Re: Expire taking FOREVER.... (1.5-REL)
Date: 8 Dec 1996 01:43:09 GMT
Organization: Ericsson Telecom, Stockholm, Sweden
Lines: 65
Message-ID: <58d6fd$f8n$1@news.du.etx.ericsson.se>
References: <E1uCxw.7L8@lerami.lerctr.org> <E1y2ry.65I@lerami.lerctr.org> <58bvbf$4qv$1@news.du.etx.ericsson.se> <58chhc$pmf@clark.zippo.com>
NNTP-Posting-Host: super.du.etx.ericsson.se
NNTP-Posting-User: per
Xref: news.math.psu.edu news.software.nntp:27547

In article <58chhc$pmf@clark.zippo.com> kachun@zippo.com (Kachun Lee) writes:
>In article <58bvbf$4qv$1@news.du.etx.ericsson.se>, per@erix.ericsson.se 
>says...
>>Same here, more or less - expire went from 20 minutes with unoff4 to
>>*5 hours* 20 minutes with 1.5. History file is some 150 MB. Solaris
>>2.5.1 on a system that is a bit short on RAM. Using MMAP for dbz -
>>btw, it seems specifying MMAP for active automatically gives you MMAP
>>for dbz too in 1.5 - not sure that is a good idea...
>> [snip]
>
>We are still using 1.4unoffx, but if I used MMAP dbz for expire, it will run 
>very very long also... I never actually wait for one to finished, but it is in 
>the multiples of what you described. So I only used the MMAP dbz for innd and 
>nnrpd, but a non-MMAP dbz for expire. And we are using FreeBSD.

Right on target! I thought I was running with MMAP-dbz in unoff4 too,
after some fiddling to try to improve the performance of innd the week
before upgrading to 1.5 - but I had only installed the new innd, not
expire! This definitely means that ACT_STYLE MMAP causing MMAP to get
#defined in 1.5 as I mentioned above is a really bad idea, and probably
the reason others are getting a slow expire when upgrading - below is
the obvious patch for this.

On a more general note, while the badness of MMAP-dbz for expire
apparently varies depending on your system (e.g. it din't cause
noticeable problems for me on servers with SunOS 4.1.4 and more RAM),
it seems it can never be an advantage - for expire, it should always be
best to build the new .pag in core and not write any part of it out
until finished. I have some patches to allow expire to turn off use of
mmap() while still allowing it for innd and nnrpd, but I guess I should
test them before sharing.:-)

--Per Hedeland
per@erix.ericsson.se

*** include/clibrary.h.ORIG	Thu Dec  5 17:34:17 1996
--- include/clibrary.h	Sat Dec  7 23:51:49 1996
***************
*** 116,129 ****
  extern POINTER		malloc();
  extern POINTER		realloc();
  
! #if	defined(ACT_MMAP)
! #define MMAP
! #endif /* defined(ACT_MMAP) */
! #if	defined(MMAP)
  /* =()<typedef @<MMAP_PTR>@ MMAP_PTR;>()= */
  typedef caddr_t MMAP_PTR;
  extern MMAP_PTR mmap();
! #endif /* defined(MMAP) */	
  
  /* Some backward systems need this. */
  extern FILE	*popen();
--- 116,126 ----
  extern POINTER		malloc();
  extern POINTER		realloc();
  
! #if	defined(ACT_MMAP) || defined(MMAP)
  /* =()<typedef @<MMAP_PTR>@ MMAP_PTR;>()= */
  typedef caddr_t MMAP_PTR;
  extern MMAP_PTR mmap();
! #endif /* defined(ACT_MMAP) || defined(MMAP) */	
  
  /* Some backward systems need this. */
  extern FILE	*popen();