This one time, at band camp, Ronny Adsetts said: > Hi Stephen, > > Quick update on this problem with the latest clamav to keep it on the > radar: > > $ uname -a > Linux allanon 2.6.24-etchnhalf.1-amd64 #1 SMP Mon Jul 21 10:36:02 UTC > 2008 x86_64 GNU/Linux > > $ ps Hu -C clamd > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > clamav 30091 0.0 11.1 264900 230540 ? Ssl Sep05 0:14 > /usr/sbin/clamd > clamav 30091 0.0 11.1 264900 230540 ? Ssl 18:57 0:00 > /usr/sbin/clamd > > So it's still there. Let me know if there's anything I can do to help.
For the bug log, what I understand about what is happening is that at startup, clamd loads a single copy of the database. At the first reload, it loads a second copy of the database, and running threads switch their database pointer to the new version as they become quiescent. This does result in some memory fragmentation, as the following ASCII art will try to show (note - this is a lie, like all descriptions of memory maps are a lie, because of the VM subsystem, but it gives an idea of what userspace sees). At startup, the memory map looks something like: ------------ | | | | | databases | | | | | ------------ | libraries, | | links, etc | ------------ After the first reload, it looks something like: ------------ | | | second | | database | | copy | | | ------------ | | | first | | database | | copy | | | ------------ | libraries, | | links, etc | ------------ And shortly after that, it looks like: ------------ | | | | | database | | | | | ------------ | | | | | unused | | | | | ------------ | libraries, | | links, etc | ------------ So when another reload happens, it is either small enough to fit in the unused space, or it's not, in which case it is appended. After that, the unused space in the middle should be big enough to load subsequent database copies, so memory usage should be roughly stable. Unfortunately, depending on the allocation, it will never quite go back to the starting memory usage, if I understand the problem correctly. If my understanding is correct, I'm afraid this is only going to get worse as the databases get bigger. It can get more efficient, but the underlying problem seems like it is likely to stay the same. -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : [EMAIL PROTECTED] | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
signature.asc
Description: Digital signature
