Re: [lttng-dev] Large number of stream files in CTF trace -- too many file handles

2020-03-16 Thread Jonathan Rajotte-Julien via lttng-dev
Hi,

> If this is not the right approach, how should I proceed?  E.g., should the
> source-ctf-fs manage a limited pool of file handles?  I would think this
> would be pretty inefficient as you would need to constantly open/close
> files--expensive.

I would probably start looking at the soft and hardlimit for the babeltrace2
process in terms of open file:

On my machine:

joraj@~[]$ ulimit -Sn
1024

joraj@~[]$ ulimit -Hn
1048576

That is a lot of headspace.

I might have a setting somewhere increasing the base hardlimit but
in any case you will see how much room you have.

Based on the number of streams you have, I would say that you will
need more than 2000 as a base soft limit for this trace.

We do have a FD pooling system in place in another project we maintain
(lttng-tools[1] GPL-2.0) that might be pertinent for babeltrace2 at some point
in time. As for the overhead that would occur in a scenario with not enough FD
available, I think it is a good compromise between either reading a trace or
not reading it at all. A warning informing the user that we reached
the limit of the pool might be a good start in such case.

[1] https://github.com/lttng/lttng-tools/tree/master/src/common/fd-tracker

Cheers

-- 
Jonathan Rajotte-Julien
EfficiOS
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev


Re: [lttng-dev] [PATCH lttng-modules] Add UDP and ICMP packet header information to the tracepoint:

2020-03-16 Thread Mathieu Desnoyers via lttng-dev
Hi Florian,

Sorry, I could not apply this patch due to line-wrapping performed
by your email client. Please use git send-email.

Thanks,

Mathieu

- On Mar 13, 2020, at 7:32 AM, lttng-dev lttng-dev@lists.lttng.org wrote:

> * UDP transport header
> * ICMP transport header
> 
> (Correct indentation for switch/case)
> (Fix white space for switch and correct struct type (icmphdr))
> 
> Signed-off-by: Florian Walbroel 
> ---
>  instrumentation/events/lttng-module/net.h | 166 --
>  1 file changed, 153 insertions(+), 13 deletions(-)
> 
> diff --git a/instrumentation/events/lttng-module/net.h
> b/instrumentation/events/lttng-module/net.h
> index bfa14fc..8e6ee29 100644
> --- a/instrumentation/events/lttng-module/net.h
> +++ b/instrumentation/events/lttng-module/net.h
> @@ -11,6 +11,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -85,6 +87,53 @@ static struct lttng_event_field tcpfields[] = {
>   },
>  };
> 
> +static struct lttng_event_field udpfields[] = {
> + [0] = {
> + .name = "source_port",
> + .type = __type_integer(uint16_t, 0, 0, 0,
> + __BIG_ENDIAN, 10, none),
> + },
> + [1] = {
> + .name = "dest_port",
> + .type = __type_integer(uint16_t, 0, 0, 0,
> + __BIG_ENDIAN, 10, none),
> + },
> + [2] = {
> + .name = "len",
> + .type = __type_integer(uint16_t, 0, 0, 0,
> + __BIG_ENDIAN, 10, none),
> + },
> + [3] = {
> + .name = "check",
> + .type = __type_integer(uint16_t, 0, 0, 0,
> + __BIG_ENDIAN, 10, none),
> + },
> +};
> +
> +static struct lttng_event_field icmpfields[] = {
> + [0] = {
> + .name = "type",
> + .type = __type_integer(uint8_t, 0, 0, 0,
> + __BIG_ENDIAN, 10, none),
> + },
> + [1] = {
> + .name = "code",
> + .type = __type_integer(uint8_t, 0, 0, 0,
> + __BIG_ENDIAN, 10, none),
> + },
> + [2] = {
> + .name = "checksum",
> + .type = __type_integer(uint16_t, 0, 0, 0,
> + __BIG_ENDIAN, 10, none),
> + },
> + [3] = {
> + .name = "gateway",
> + .type = __type_integer(uint32_t, 0, 0, 0,
> + __BIG_ENDIAN, 10, none),
> + },
> +};
> +
> +
>  static struct lttng_event_field transport_fields[] = {
>   [0] = {
>   .name = "unknown",
> @@ -102,13 +151,57 @@ static struct lttng_event_field transport_fields[] = {
>   .u._struct.fields = tcpfields,
>   },
>   },
> + [2] = {
> + .name = "udp",
> + .type = {
> + .atype = atype_struct,
> + .u._struct.nr_fields = ARRAY_SIZE(udpfields),
> + .u._struct.fields = udpfields,
> + },
> + },
> + [3] = {
> + .name = "icmp",
> + .type = {
> + .atype = atype_struct,
> + .u._struct.nr_fields = ARRAY_SIZE(icmpfields),
> + .u._struct.fields = icmpfields,
> + },
> + },
>  };
> 
>  enum transport_header_types {
>   TH_NONE = 0,
>   TH_TCP = 1,
> + TH_UDP = 2,
> + TH_ICMP = 3,
>  };
> 
> +static inline enum transport_header_types
> __get_transport_header_type_ip(struct sk_buff *skb)
> +{
> + switch (ip_hdr(skb)->protocol) {
> + case IPPROTO_TCP:
> + return TH_TCP;
> + case IPPROTO_UDP:
> + return TH_UDP;
> + case IPPROTO_ICMP:
> + return TH_ICMP;
> + }
> + return TH_NONE;
> +}
> +
> +static inline enum transport_header_types
> __get_transport_header_type_ipv6(struct sk_buff *skb)
> +{
> + switch (ipv6_hdr(skb)->nexthdr) {
> + case IPPROTO_TCP:
> + return TH_TCP;
> + case IPPROTO_UDP:
> + return TH_UDP;
> + case IPPROTO_ICMP:
> + return TH_ICMP;
> + }
> + return TH_NONE;
> +}
> +
>  static inline enum transport_header_types
> __get_transport_header_type(struct sk_buff *skb)
>  {
>   if (__has_network_hdr(skb)) {
> @@ -123,13 +216,13 @@ static inline enum transport_header_types
> __get_transport_header_type(struct sk_
>* header's data. This method works both for
>* sent and received packets.
>*/
> - if ((skb->protocol == htons(ETH_P_IP) &&
> - ip_hdr(skb)->protocol == IPPROTO_TCP) ||
> - (skb->protocol == htons(ETH_P_IPV6) &&
> - ipv6_hdr(skb)->nexthdr == IPPROTO_TCP))
> - return TH_TCP;
> + if (s

Re: [lttng-dev] Large number of stream files in CTF trace -- too many file handles

2020-03-16 Thread Rocky Dunlap via lttng-dev
Jonathan,

Increasing the soft FD limit worked great, both for the command line and
the Python script.  Thanks for the help!

Rocky

On Mon, Mar 16, 2020 at 8:51 AM Jonathan Rajotte-Julien <
jonathan.rajotte-jul...@efficios.com> wrote:

> Hi,
>
> > If this is not the right approach, how should I proceed?  E.g., should
> the
> > source-ctf-fs manage a limited pool of file handles?  I would think this
> > would be pretty inefficient as you would need to constantly open/close
> > files--expensive.
>
> I would probably start looking at the soft and hardlimit for the
> babeltrace2
> process in terms of open file:
>
> On my machine:
>
> joraj@~[]$ ulimit -Sn
> 1024
>
> joraj@~[]$ ulimit -Hn
> 1048576
>
> That is a lot of headspace.
>
> I might have a setting somewhere increasing the base hardlimit but
> in any case you will see how much room you have.
>
> Based on the number of streams you have, I would say that you will
> need more than 2000 as a base soft limit for this trace.
>
> We do have a FD pooling system in place in another project we maintain
> (lttng-tools[1] GPL-2.0) that might be pertinent for babeltrace2 at some
> point
> in time. As for the overhead that would occur in a scenario with not
> enough FD
> available, I think it is a good compromise between either reading a trace
> or
> not reading it at all. A warning informing the user that we reached
> the limit of the pool might be a good start in such case.
>
> [1] https://github.com/lttng/lttng-tools/tree/master/src/common/fd-tracker
>
> Cheers
>
> --
> Jonathan Rajotte-Julien
> EfficiOS
>
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev