<div dir="ltr">Jonathan,<div><br></div><div>Increasing the soft FD limit worked great, both for the command line and the Python script.  Thanks for the help!</div><div><br></div><div>Rocky</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 16, 2020 at 8:51 AM Jonathan Rajotte-Julien <<a href="mailto:jonathan.rajotte-julien@efficios.com">jonathan.rajotte-julien@efficios.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
> If this is not the right approach, how should I proceed?  E.g., should the<br>
> source-ctf-fs manage a limited pool of file handles?  I would think this<br>
> would be pretty inefficient as you would need to constantly open/close<br>
> files--expensive.<br>
<br>
I would probably start looking at the soft and hardlimit for the babeltrace2<br>
process in terms of open file:<br>
<br>
On my machine:<br>
<br>
joraj@~[]$ ulimit -Sn<br>
1024<br>
<br>
joraj@~[]$ ulimit -Hn<br>
1048576<br>
<br>
That is a lot of headspace.<br>
<br>
I might have a setting somewhere increasing the base hardlimit but<br>
in any case you will see how much room you have.<br>
<br>
Based on the number of streams you have, I would say that you will<br>
need more than 2000 as a base soft limit for this trace.<br>
<br>
We do have a FD pooling system in place in another project we maintain<br>
(lttng-tools[1] GPL-2.0) that might be pertinent for babeltrace2 at some point<br>
in time. As for the overhead that would occur in a scenario with not enough FD<br>
available, I think it is a good compromise between either reading a trace or<br>
not reading it at all. A warning informing the user that we reached<br>
the limit of the pool might be a good start in such case.<br>
<br>
[1] <a href="https://github.com/lttng/lttng-tools/tree/master/src/common/fd-tracker" rel="noreferrer" target="_blank">https://github.com/lttng/lttng-tools/tree/master/src/common/fd-tracker</a><br>
<br>
Cheers<br>
<br>
-- <br>
Jonathan Rajotte-Julien<br>
EfficiOS<br>
</blockquote></div>