--MimeMultipartBoundary
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Hi,
squid has sort of cache for unused fileno's that is fixed at 128. Same sort of cache
and about same size is unused files in filemap.c.
unlinking is expensive, and main squid process does unlink() when any of these
unused-file-caches overflows. sorta bad, I've seen unlink() calls that takes more
than 100mSec to complete, and thats on RAID5 system with 6 disks. When cache is
filled and is working between its high/low watermarks, these unlinks become pretty
usual, especially on a busy cache.
Therefore, I'd suggest to make these arrays that cache recently released filenos
bigger, and resizable during runtime. Perhaps best criteria to chose their size
is balance between max possible number of releases and max possible number of new
allocations - that would be tied to availbale no of FD-s. for NOVM version, I guess,
it would be 1/4 of available FD's.
Reuse of recenlty released files is a performance improvement, as it changes
unlink()-sync-open(wr) into single open(wr|trunc) on a "warm" and OS-cached file/inode.
btw, why unlink at all, why not truncate and leave it there?
and a question.
Can you guys explain me what happens when I ptr=calloc("1 chunk", "of say 16MB")
work on it, then free(). process SIZE does not drop after free(). Feels like libmalloc
sets freed memory aside in hope that it would be reused. What about the case that
malloc of this size never happens again? Would this amount of VM be simply wasted, or
is libmalloc clever enough to reuse this memory for smaller chunks? (eg. gnumalloc?)
Would it be more clever to code it to ptr=calloc("say 2048 chunks","of 8KB each"),
is there any difference? Does libmalloc keep track of such allocation differently?
----------------------------------------------------------------------
Andres Kroonmaa mail: andre@online.ee
Network Manager
Organization: MicroLink Online Tel: 6308 909
Tallinn, Sakala 19 Pho: +372 6308 909
Estonia, EE0001 http://www.online.ee Fax: +372 6308 901
----------------------------------------------------------------------
--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:45 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:31 MST