Yes it seems another: mysqld: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit #570
Comments
|
try a higher memlock limit. https://github.com/MariaDB/mariadb-docker?tab=readme-ov-file#getting-help |
|
Strangely enough... the issue seems to have resolved itself! (normally I really don't like when things change for reasons unknown to me but after having dealt with this matter for ages I guess I will accept the fact the issue went away WITHOUT changing the memlimit from the config above). Thanks for commenting and perhaps the good will that resolved the issue? (MAY have updated ver as I did try several pulls trying to resolve the issue). Assuming you don't see any reason to keep this open I'll close. 👍 |
|
glad to see the recovery even if by unknown reasons (i'm not a fan of magic solutions, but its better than non-solutions). Thanks for getting back. docker insepct mariadb could show a different image sha256 or maybe the kernel version changed. |
|
We are unfortunately both right to be wary of "magical" thinking..... The issue has returned. I know and I current as data below will show as pull update just this am. Let me start again by saying I know this is a common issue reported by many and clearly called out as insufficient memory available for ring buffer. I honestly have done A LOT of research on this including even potentially esoteric issues like respecting ulimit memlock configurations by different kernels and spawned pid's... In the end I am still stumped. I don't want to spam this post with to much of my diagnostics and risk valuable data being buried or worst yet, just to much time needed for anyone to respond so this is brief but I can provide more if you have ANY questions. High level:I tried to take your advise, and bumping the Memlock several time without seeing any change in the error Error/Warning from log: Diagnostics & Configs:In the interest of diagnostics I installed MySQLTuner-perl. Output of it in verbose mode at thee bottom. For some reason the script is complaining about the version of MariaDB I am running though it appears to me to be current from the MaraDB -V command, however I am still learning the tool so I am guessing this is an unrelated red-herring so I'm not letting it sidetrack me in resolving this issue. Relevant config data below (so you don't have to dig through my previous post). When asking for help or reporting a bug believe burden is non the reporter to at least TRY to make it easy for others to help you Configuration data:Compose MariaDB container: Container Inspect: MariaDB version **mySQLtuner run IN MariaDB container (exec'd into container as ROOT not the normal SQL user that runs MariaDB) ** Docker System info: Apologies for the length but feels better to "show my work" in supporting some of my efforts to address the issue and demonstrate that unfortunately simply increasing XX isn't resolving the issue so in MY case the issue MAY be deeper/something else. Thanks again for any help or even pointers in the right direction to save what little hair I might have left on may head after chasing this issue for months now.... |
|
mysqltuner version saying out of date is their bug major/MySQLTuner-perl#707. 5.10.60 seems a long way behind 5.10.216 (https://kernel.org/) assuming the same numbering scheme. Could check if the copied liburing implementation - axboe/liburing@ea0fd51 at < 5.12 matches the 5.10.60 version somewhere in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/io_uring.c?h=v5.10.60 |
|
Thanks for the reply, and for confirming that the mysqlturner warning is indeed irrelevant. Regarding the kernel version. Yah QNAP is notoriously slow turning updates. Cursory glance seems to show it actually released back on in Aug 2021.... I think I may come across the change commit you referenced which I also think I mentioned earlier (along with another one regrading respect for memory commitment on spawn processes), but both SEEMED at the time like they were made before Aug 21 so I (assumed) it was likely that 5.10.60 had the updates, and thus again a non issue. I am not sure how to conclusively confirm that though from your comment. I don't believe there is a testable component version for liburing that I can use to confirm the commits have been applied, and don't know hoe to diff the change agains source tree you sent. I apologize for being at the limit of my knowledge base. |
|
Yep, it was going to be a hard to confirm that the kernel maths was the same. I didn't see an obvious map, but I didn't want to spend much time on it either. Given the fixes that came later in the kernel on uring and the ioblk layer, its probably safer that its detected as not available due to memory (or any other reason really). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Apologies if this is common knowledge to most. Unfortunately I have tried a number of things and researched here as well..
[mysqld: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit #454]
Getting warning at startup of insufficient memory even AFTER updating ULIMIT (per console msg & related URL)
Clearly I am missing something both simpler and fundamental here, as I can't imagine this is actually effecting EVERYONE as there would be much more on I would have found searching so the most LIKELY source of this issue is my specific deployment. While this realistically belongs in a discussion forum but this repo doesn't have one so I'm going to appeal to you for any assistant you might be able to offer....
Thank you for any assistance. Hopefully this is as simple as it seems (despite the hours of beating my head against the wall)....
Extracted Compose:
Console log with error:
Complete container detail (demonstrating ULIMIT value):
The text was updated successfully, but these errors were encountered: