Package: iftop
Version: 1.0~pre2-3
Severity: normal
Dear Maintainer,
since last iftop upgrade (probably iftop:i386 0.17-19 -> 1.0~pre2-2 ), I've
observe that iftop memory usage increase constantly.
I use "iftop" since many years, and I never observe this behaviour.
2 computers are affected (both under testing), and upgradinng iftop:i386
1.0~pre2-2 -> 1.0~pre2-3 (unstable .deb) does not fix issue.
- For first computer (gateway), I run "iftop" under a "screen" terminal: screen
-S iftop sudo iftop -i eth0
here the ~/.iftoprc
<iftoprc>
interface: eth1
dns-resolution: no
port-resolution: yes
show-bars: yes
log-scale: yes
promiscuous: no
port-display: on
use-bytes: yes
line-display: one-line-both
show-totals: yes
filter-code: not udp
sort: 40s
</iftoprc>
<screenshot>
top - 21:13:53 up 10:23, 3 users, load average: 0,65, 0,52, 0,47
Tasks: 183 total, 1 running, 182 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,1 us, 0,5 sy, 1,3 ni, 98,1 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
Kb Mem: 1813880 total, 1532444 used, 281436 free, 29380 buffers
Kb Swap: 524284 total, 1148 used, 523136 free, 856096 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19563 root 30 10 229m 202m 3340 S 0,0 11,4 3:38.77 iftop
</screenshot>
10h uptime, 229m memory used...
<screenshot>
top - 22:14:54 up 1 day, 11:24, 4 users, load average: 0,54, 0,48, 0,54
Tasks: 187 total, 2 running, 185 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,7 us, 1,2 sy, 1,3 ni, 96,8 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
Kb Mem: 1813880 total, 1688600 used, 125280 free, 19692 buffers
Kb Swap: 524284 total, 26152 used, 498132 free, 774016 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19563 root 30 10 466m 435m 3340 S 1,3 24,6 9:08.17 iftop
</screenshot>
1 day after, memory increase to 466m !!!
<screenshot>
top - 22:15:47 up 1 day, 11:25, 4 users, load average: 0,60, 0,52, 0,55
Tasks: 184 total, 1 running, 183 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,7 us, 0,7 sy, 0,6 ni, 97,7 id, 0,2 wa, 0,0 hi, 0,1 si, 0,0 st
Kb Mem: 1813880 total, 1255228 used, 558652 free, 19744 buffers
^^^^^^^^^^^^
Kb Swap: 524284 total, 21136 used, 503148 free, 792936 cached
</screenshot>
After killing iftop process, ~430m are free.
On this tool, a "torrent" client is running (I'm sharing Linux distros), so
this is open/close a lot of connections.
- For the 2nd computer (desktop), I've observe same behaviour, while I
copy/paste gigabyte of files trought NFS server.
2 "iftop" commands are started, one with a "screen" command, and the other
without a "screen"
<screenshot>
top - 21:13:43 up 1 day, 5:30, 7 users, load average: 1,47, 1,46, 1,61
Tasks: 193 total, 2 running, 191 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1,4 us, 0,9 sy, 25,1 ni, 72,5 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
Kb Mem: 4149972 total, 3778404 used, 371568 free, 21336 buffers
^^^^^^^^^^^^
Kb Swap: 3004116 total, 212 used, 3003904 free, 2114636 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16947 root 20 0 433m 406m 3188 S 0,0 10,0 0:36.38 iftop
^^^^ ^^^^
16988 root 20 0 433m 406m 3116 S 0,0 10,0 0:47.74 iftop
^^^^ ^^^^
</screenshot>
2 x 433m memory used after several hour usage
<screenshot>
top - 21:15:49 up 1 day, 5:32, 7 users, load average: 1,45, 1,43, 1,58
Tasks: 194 total, 3 running, 191 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2,3 us, 0,7 sy, 24,9 ni, 72,1 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
Kb Mem: 4149972 total, 3062916 used, 1087056 free, 21600 buffers
^^^^^^^^^^^^
Kb Swap: 3004116 total, 212 used, 3003904 free, 2225892 cached
</screenshot>
After killing "iftop" process, about 800m of memory is free
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (90, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-2-686-pae (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages iftop depends on:
ii libc6 2.13-33
ii libncurses5 5.9-7
ii libpcap0.8 1.2.1-3
ii libtinfo5 5.9-7
iftop recommends no packages.
iftop suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
