Ubuntu 20, mariadb 10.6.16, fully NVME pcie 4.0, high end server, hundreds databases with hundreds tables

The messages indicate that the innodb_open_files is being exceeded. Have you tried to specify that parameter?

What is your innodb_log_file_size? A larger value may slow down crash recovery (although MDEV-29911 improved that), but it will also reduce the pressure on page flushing. You might also want to specify a nonzero innodb_max_dirty_pages_pct_lwm and apply the fix of MDEV-31939 to make the page flushing rate more stable.

So, it's not bug only "feature" if I understand it well?
I can try increate innodb_open_files, but how can I get the "correct" value? Any hint?
(Now it is 400)

innodb_log_file_size is 1GB.

innodb_max_dirty_pages_pct_lwm is now zero.

Yes, I think that this is more a feature than a bug. I am not familiar enough with the Linux kernel to say what would be an "insane" amount of open file descriptors. I have seen a rule of thumb that innodb_log_file_size should be large enough for about 1 hour of writes to the database (LSN growth over an hour, interpreted as bytes). Currently your log file is only 0.5% of the buffer pool size. Have you thought of increasing it?

Ah :/ I think it's a bug, ok, well. It's better than solving bug. We can try to change this.

We have "low" innodb_log_file_size because of recovery... What size you suggest us? For example, if our DB crashed, we can't wait XX minutes for recover :/ We have busy servers with a hundreds of customers eshops.

But you told me to change "innodb_open_files". What is relation this directive to "innodb_log_file_size"?

In every case, we can try increase "innodb_open_files", but not sure, if try 500, 600 or 2000 or 20000 etc. Can you tell me any "best practices" about this? (already tried documentation and google, but without success).
Of course, I'm just asking for information, without a guarantee from you.

Is it enough to change innodb_open_files or is necessary make innodb_log_file_size higher as well?

Thank you.

We have a separate support forum for paying customers. I suspect that the log checkpoint pressure due to a small log file size is causing bursts of writes to large numbers of data files. You can just ignore the messages or try to increase the number of open files until the messages become more rare. You may also test how long the typical crash recovery time actually is with some different values of innodb_log_file_size.

OK, I understand. Can you share informations about this forum for paying customers?

What's next, should I close this issue now? (Because I think before, it's any type of bug, but as you already wrote, it's feature)

Or leave open now and post here update after we will change values? (maybe it will helps someone else as well)

We changed 3 days ago:
innodb_open_files 400 -> 512
innodb_log_file_size 1GB -> 2GB

But behaviour stayed nearly same, not much changes (tested 3 days, still same).
Every day approximatelly 60-80 logged records with "pending" text.
Before approximatelly 80-100, so its not good change, but maybe it's because now is less traffic (Christmas).. so :/

Any recommendation please?

Should we try again to increase both of these limits?

Btw, we updated to mariabd 10.11, still "same" (approximatelly 50 per day) - but now is low traffic because of holiday.

The warning message merely says that the configured innodb_open_files is being exceeded. Closing and reopening files does incur some overhead, and therefore it would make sense to set innodb_open_files as large as possible. The default value makes me think of old things like FILES=30 in the MS-DOS CONFIG.SYS. https://unix.stackexchange.com/questions/84227/limits-on-the-number-of-file-descriptors mentions the Linux /proc/sys/fs/file-max, which identifies a global limit of file descriptors. On my AMD64 system, that is 2⁶³-1, so it does not look like an accurate limit. The first field of the file /proc/sys/fs/file-nr reflects the number of currently open file descriptors, which is 12,802 on my desktop system, with some 1½ hours of uptime and after some light GUI usage.

I found a definition of the Linux kernel struct file in include/linux/fs.h. I might assume that most of its members are 64 or 128 bits. The member f_path looks a bit suspicious, but it turns out that struct path only encapsulates 2 pointers. There are about 20 data members in struct file in total. It would seem that an open file handle would consume between a couple hundred bytes and a couple kilobytes, depending on the absolute path name lengths, overlay mounts and whatnot. I’m guessing here, but a gigabyte of memory could cover one million open file handles. Based on that, you might considerably increase the innodb_open_files limit.

Again, this system is for reporting bugs in MariaDB products. Support for paying customers is provided by other means.

OK, understand, thank you for detailed explanation.

Should I close this? Or post here update after another increate innodb_open_files?