I've run it on the original 10G file (70M packets). It can't process all of
them. At around 30M packets memory consumption is about 3.7G.
It's a good improvement anyway!
Thanks
Dario.
On Fri, Aug 30, 2013 at 3:35 AM, Evan Huus eapa...@gmail.com wrote:
On Thu, Aug 29, 2013 at 11:07 AM, Dario
On Thu, Aug 29, 2013 at 5:32 AM, Dario Lombardo dario.lombardo...@gmail.com
wrote:
On Wed, Aug 28, 2013 at 3:45 PM, Evan Huus eapa...@gmail.com wrote:
Also, just as a useful reference point: if you run your normal tshark
command (no valgrind) on the 1GB subset, what does memory usage of the
Running the same command as before (I mean without valgrind) with -n, I get
1.5G of memory consumption, as without -n.
That's quite useful actually: it looks like the majority of the memory is
being used to store address-resolution data from all of the DNS packets so
that if those IP addresses
On Thu, Aug 29, 2013 at 10:30 AM, Dario Lombardo
dario.lombardo...@gmail.com wrote:
Running the same command as before (I mean without valgrind) with -n, I
get 1.5G of memory consumption, as without -n.
That's expected.
That's quite useful actually: it looks like the majority of the
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Evan Huus
Sent: den 29 augusti 2013 15:21
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Memory consumption in tshark
On Thu, Aug 29, 2013 at 5:32 AM, Dario Lombardo
On Thu, Aug 29, 2013 at 4:35 PM, Evan Huus eapa...@gmail.com wrote:
Basically, but it's also more. If your capture contains a DNS packet
resolving a name in a certain way, and the system name resolver gives a
different answer, we prefer the DNS packet in the capture (since presumably
the
On Thu, Aug 29, 2013 at 11:07 AM, Dario Lombardo
dario.lombardo...@gmail.com wrote:
On Thu, Aug 29, 2013 at 4:35 PM, Evan Huus eapa...@gmail.com wrote:
Basically, but it's also more. If your capture contains a DNS packet
resolving a name in a certain way, and the system name resolver gives a
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Dario Lombardo
Sent: den 29 augusti 2013 17:07
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Memory consumption in tshark
On Thu, Aug 29, 2013 at 4:35 PM, Evan Huus
eapa
Anders Broman skrev 2013-08-29 17:20:
*From:*wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] *On Behalf Of *Dario Lombardo
*Sent:* den 29 augusti 2013 17:07
*To:* Developer support list for Wireshark
*Subject:* Re: [Wireshark-dev] Memory consumption in tshark
On Thu, Aug 29, 2013 at 11:07 AM, Dario Lombardo
dario.lombardo...@gmail.com wrote:
On Thu, Aug 29, 2013 at 4:35 PM, Evan Huus eapa...@gmail.com wrote:
Basically, but it's also more. If your capture contains a DNS packet
resolving a name in a certain way, and the system name resolver gives a
On Tue, Aug 27, 2013 at 04:37:27PM -0400, Evan Huus wrote:
We already discard a great deal of state in (single-pass) tshark that we
keep around in Wireshark (or two-pass tshark).
Really? I'm not so sure about that 'great deal' I think right now
we are only freeing protocol frame data list.
On Tue, Aug 27, 2013 at 06:17:13PM -0400, Evan Huus wrote:
As Anders says, this is because we have no way right now to selectively
discard it: much of the data is stored in a way that we can only get rid of
all of it, or none.
I'm not sure why we want to do selectvely discard, I'm fan of 'get
On Tue, Aug 27, 2013 at 05:09:19PM -0400, Evan Huus wrote:
We already do reassembly and a lot of other stateful work in single-pass
mode. The only thing two-pass mode provides is the ability to see the
future (for example, saying: this request has a response 5 packets later).
We need two pass
On Tue, Aug 27, 2013 at 10:38 PM, Evan Huus eapa...@gmail.com wrote:
We already discard a great deal of state in (single-pass) tshark that we
keep around in Wireshark (or two-pass tshark). We do need to keep some,
though. It's only a bug if we're keeping more than we actually need, and
that's
On 2013-08-28, at 1:22 AM, Anders Broman a.bro...@bredband.net wrote:
Evan Huus skrev 2013-08-28 00:17:
On Tue, Aug 27, 2013 at 6:02 PM, Anders Broman a.bro...@bredband.net wrote:
Joerg Mayer skrev 2013-08-27 23:24:
On Tue, Aug 27, 2013 at 05:09:19PM -0400, Evan Huus wrote:
IIRC, two-pass
On 2013-08-28, at 2:42 AM, Jakub Zawadzki darkjames...@darkjames.pl wrote:
On Tue, Aug 27, 2013 at 04:37:27PM -0400, Evan Huus wrote:
We already discard a great deal of state in (single-pass) tshark that we
keep around in Wireshark (or two-pass tshark).
Really? I'm not so sure about that
On 2013-08-28, at 2:47 AM, Jakub Zawadzki darkjames...@darkjames.pl wrote:
On Tue, Aug 27, 2013 at 06:17:13PM -0400, Evan Huus wrote:
As Anders says, this is because we have no way right now to selectively
discard it: much of the data is stored in a way that we can only get rid of
all of it,
On 2013-08-28, at 3:24 AM, Dario Lombardo dario.lombardo...@gmail.com wrote:
On Tue, Aug 27, 2013 at 10:38 PM, Evan Huus eapa...@gmail.com wrote:
We already discard a great deal of state in (single-pass) tshark that we
keep around in Wireshark (or two-pass tshark). We do need to keep some,
On Wed, Aug 28, 2013 at 9:31 AM, Dario Lombardo dario.lombardo...@gmail.com
wrote:
On Wed, Aug 28, 2013 at 1:29 PM, Evan Huus eapa...@gmail.com wrote:
It's dependant on platform and setup, but I'll assume a from-source build
on Linux. In theory all you have to do is prefix your normal
Also, just as a useful reference point: if you run your normal tshark
command (no valgrind) on the 1GB subset, what does memory usage of the
process peak at?
Thanks,
Evan
On Wed, Aug 28, 2013 at 9:41 AM, Evan Huus eapa...@gmail.com wrote:
On Wed, Aug 28, 2013 at 9:31 AM, Dario Lombardo
Hi list
I've run this command on a 10G pcap file.
./tshark -r traffic.all -Y dns.qry.name.len 50 -w longnames.pcap
Used memory grows continuously, up to over 3GB of ram. At this point my pc
goes thrashing and I must kill tshark.
That's not what I expected. I expected the memory to grow up to a
to split the file up in more suitable slices of say 1 G
Regards
Anders
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Dario Lombardo
Sent: den 27 augusti 2013 10:09
To: Developer support list for Wireshark
Subject: [Wireshark-dev] Memory consumption
Hi,
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Dario Lombardo
I've run this command on a 10G pcap file.
./tshark -r traffic.all -Y dns.qry.name.len 50 -w longnames.pcap
Used memory grows continuously, up to over 3GB of ram. At
On Tue, Aug 27, 2013 at 06:53:01PM +0200, Jakub Zawadzki wrote:
./tshark -r traffic.all -Y dns.qry.name.len 50 -w longnames.pcap
Used memory grows continuously, up to over 3GB of ram. At this point my pc
goes thrashing and I must kill tshark.
That's not what I expected. I expected the
We already discard a great deal of state in (single-pass) tshark that we
keep around in Wireshark (or two-pass tshark). We do need to keep some,
though. It's only a bug if we're keeping more than we actually need, and
that's not determinable from the information we have here. Dario, if you
could
We already discard a great deal of state in (single-pass) tshark that we
keep around in Wireshark (or two-pass tshark). We do need to keep some,
though. It's only a bug if we're keeping more than we actually need, and
that's not determinable from the information we have here. Dario, if you
could
On Tue, Aug 27, 2013 at 04:38:08PM -0400, Evan Huus wrote:
We already discard a great deal of state in (single-pass) tshark that we
keep around in Wireshark (or two-pass tshark). We do need to keep some,
though. It's only a bug if we're keeping more than we actually need, and
that's not
On Tue, Aug 27, 2013 at 5:01 PM, Joerg Mayer jma...@loplof.de wrote:
On Tue, Aug 27, 2013 at 04:38:08PM -0400, Evan Huus wrote:
We already discard a great deal of state in (single-pass) tshark that we
keep around in Wireshark (or two-pass tshark). We do need to keep some,
though. It's only
On Tue, Aug 27, 2013 at 05:09:19PM -0400, Evan Huus wrote:
IIRC, two-pass allows for most/all of the reassembly/request-response
stuff,
which we want to do sometimes. Any ideas why we have to keep some
information
indefinitely?
Two-pass requires us to keep *all* the state around
Joerg Mayer skrev 2013-08-27 23:24:
On Tue, Aug 27, 2013 at 05:09:19PM -0400, Evan Huus wrote:
IIRC, two-pass allows for most/all of the reassembly/request-response
stuff,
which we want to do sometimes. Any ideas why we have to keep some
information
indefinitely?
Two-pass requires us to keep
On Tue, Aug 27, 2013 at 6:02 PM, Anders Broman a.bro...@bredband.netwrote:
Joerg Mayer skrev 2013-08-27 23:24:
On Tue, Aug 27, 2013 at 05:09:19PM -0400, Evan Huus wrote:
IIRC, two-pass allows for most/all of the reassembly/request-response
stuff,
which we want to do sometimes. Any ideas
Evan Huus skrev 2013-08-28 00:17:
On Tue, Aug 27, 2013 at 6:02 PM, Anders Broman a.bro...@bredband.net
mailto:a.bro...@bredband.net wrote:
Joerg Mayer skrev 2013-08-27 23:24:
On Tue, Aug 27, 2013 at 05:09:19PM -0400, Evan Huus wrote:
IIRC, two-pass allows for
32 matches
Mail list logo
