Package: clamav
Version: 0.90.2-1~volatile1
Severity: important
hi,
this bug relates to #420391, though here I'm pointing out the huge scantime
of clamscan with 0.90.x engine. More precisely, the culprit seems in sig.s
DB loading.
"the plain clamscan looks nearly 'not usable'" hence the severity - pls see
below.
I've done some testing, using the 0.84-sarge engine, the 0.90.1 and 0.90.2
engines, backported to sarge to use the same machine.
0.84
- clamd takes a couple s to start, then sits there at RSS ~20MB, CPU 0.0
- clamscan -r takes ~26s to scan a test dir
- clamscan takes ~2.5s to scan a ~100k PDF
- clamdscan takes ~25s on same dir, in a while{...} loop.
0.90.2
- clamd takes *74s* to start, while RSS grows up to ~42MB with CPU at ~98%
- clamscan -r takes *~1m33s* to scan a test dir
- clamscan takes *~1m13s* to scan a ~100k PDF
- clamdscan takes ~23s on same dir, in a while{...} loop
- on long run, RSS, VIRT grow up to ~97MB, ~107MB as reported by others.
That seems a mem.leak, possibly triggered by some filetype.
0.90.1
just same as 0.90.2
In test dir I have
directories: 35
files: 218
data: ~32 MB
file types are (MS-|Open|Star)Office docs, JPEG, ZIP, (tar)*, EXE.
Test machine has 1GB RAM, with 1 CPU:
model name : AMD Athlon(TM) XP 2600+
cpu MHz : 1905.504
cache size : 512 KB
I get ~same results on a P4 1.4G with Etch and 0.90.2.
So the point is, while the clamd memory footprint grow-up can be managed
by a cronjob which checks/restarts clamd, the plain clamscan looks nearly
'not usable' imo: you'd need to wait ~74s to scan even a small text file.
Clearly that's unacceptable for on-access scans, and use of clamd is no more
an option.
thanks
--
paolo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
