Mixbus open file limit.

[zimbodel]

It is easy for me to configure the maximum # open files in Linux so you dont have to address that, but just want to know what the default out of the box value of 1048576 open files for MixBus should be increased to, to prevent unexpected overruns, or if it is known, what is the metric by which a user should choose to increase the number of open files. In short what are the caveats and justification of 1048576 chosen.
Thanks

[Dingo]

I think it is the equal of 1 Megabyte.

[zimbodel]

My question is about number of files and not size, unless you say the sum of the filesizes should not exceed 1 Megabyte of open files.
Or do you mean something else.
This is something I always check for any mission critical application as you can get "Too many files open error message" and resultant freeze up in the middle of a session or just an instant crash, if the value is too low. Currently it is set at that number for Mixbus and I want to know what kind of use will exceed the open files.
As an example, is there some model that can give an estimate mixbus # of open files or maybe do you have a facility in mixbus debug to see how many open files currently in use? If not I can do it in Linux and monitor the amount of open files to make sure it never get to that value.

I think it is the equal of 1 Megabyte.

[Dingo]

I was just pointing out the significance of the number: 1048576

1 MB is 1,024 kilobytes, or 1,048,576 (1024x1024) bytes.

[zimbodel]

I know that but the number of open files is not a filesize.

I am clearly talking about the number of files and not fiesize. See my original post.
As an example the debug shows the following for mixbus
"Your system is configured to limit Mixbus to only 1048576 open files"

All I want to know is what are you aware of about the maximum open files mixbus uses under heaviest and normal use by your experience. I ask as I already mentioned that on Linux if that limit per PID is exceeded Mixbus might just crash unexpectedly or a file limit error will display and it may freeze. I am just asking what you found mixbus uses under various conditions.

If you dont know, it is ok, I will just write a script that shows me how many open files mixbus uses when I use it, it is easy enough, that way I will know if I approach a limit and can avoid a freeze-up or crash.
I just thought, that since you must have provided that amount of files as limit (usually by calling ulimit in your install script), you would know the nominal amount of open file uses against channels an plugins used in mixbus etc.

E.g freshly loaded with only the 1818vsl recognised in in mixbus, I get

18 open files
which is a long way to a million.

What I want to know is to your experience how does this grow with a large mix with say 100 tracks or so. I cannot run such large mixes, but you probably did. I just want to see how this scale so I dont have to worry about overruns.

I was just pointing out the significance of the number: 1048576

1 MB is 1,024 kilobytes, or 1,048,576 (1024x1024) bytes.

[x42]

In short what are the caveats and justification of 1048576 chosen.

The short answer: no caveats, just ignore this information

When Mixbus starts, this limit is increased to the maximum allowed (for the given user, on the given system) and the result is printed.

The justification is that Mixbus cannot know what you want to do so the worst case is assumed:
If you use many different sources in MIxbus (e.g. import a lot of samples) and perhaps use some sampler plugins or sfz soundfonts (sampled instruments, one or more file per note or even one per velocity layer), the number of concurrently open files can add up. A couple of thousands can be reached easily -- a million, probably not.

run `prlimit`. On most Linux systems the default is 1024, and a normal non-admin user can increase this limit to 1M. see "NOFILE" in the example below.

Code:

$ prlimit
RESOURCE   DESCRIPTION                             SOFT      HARD UNITS
AS         address space limit                unlimited unlimited bytes
CORE       max core file size                         0 unlimited bytes
CPU        CPU time                           unlimited unlimited seconds
DATA       max data size                      unlimited unlimited bytes
FSIZE      max file size                      unlimited unlimited bytes
LOCKS      max number of file locks held      unlimited unlimited locks
MEMLOCK    max locked-in-memory address space unlimited unlimited bytes
MSGQUEUE   max bytes in POSIX mqueues            819200    819200 bytes
NICE       max nice prio allowed to raise             0         0
NOFILE     max number of open files                1024   1048576 files
NPROC      max number of processes                63357     63357 processes
RSS        max resident set size              unlimited unlimited bytes
RTPRIO     max real-time priority                    95        95
RTTIME     timeout for real-time tasks        unlimited unlimited microsecs
SIGPENDING max number of pending signals          63357     63357 signals
STACK      max stack size                       8388608 unlimited bytes

[zimbodel]

Yes you are right.

Taking the warning at face value does create a false intent though
I think using "only" draws one into believing that it might not be enough.
It is an Ardour message for MixBus so I think they should take out the "only" as it is misleading.

Thanks anyway.
Glad to know there is not a runaway file open problem as it seemingly suggested.

Problem solved.

In short what are the caveats and justification of 1048576 chosen.

The short answer: no caveats, just ignore this information

When Mixbus starts, this limit is increased to the maximum allowed (for the given user, on the given system) and the result is printed.

The justification is that Mixbus cannot know what you want to do so the worst case is assumed:
If you use many different sources in MIxbus (e.g. import a lot of samples) and perhaps use some sampler plugins or sfz soundfonts (sampled instruments, one or more file per note or even one per velocity layer), the number of concurrently open files can add up. A couple of thousands can be reached easily -- a million, probably not.

run `prlimit`. On most Linux systems the default is 1024, and a normal non-admin user can increase this limit to 1M. see "NOFILE" in the example below.