diff options
Diffstat (limited to 'issues/production-container-mechanical-rob-failure.gmi')
-rw-r--r-- | issues/production-container-mechanical-rob-failure.gmi | 44 |
1 files changed, 25 insertions, 19 deletions
diff --git a/issues/production-container-mechanical-rob-failure.gmi b/issues/production-container-mechanical-rob-failure.gmi index 7839943..a32194e 100644 --- a/issues/production-container-mechanical-rob-failure.gmi +++ b/issues/production-container-mechanical-rob-failure.gmi @@ -63,7 +63,7 @@ Your assistance in bug reporting will enable us to fix this for the next release To report this bug, see https://mariadb.com/kb/en/reporting-bugs We will try our best to scrape up some info that will hopefully help -diagnose the problem, but since we have already crashed, +diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. Server version: 10.5.23-MariaDB-0+deb11u1-log source revision: 6cfd2ba397b0ca689d8ff1bdb9fc4a4dc516a5eb @@ -72,7 +72,7 @@ read_buffer_size=131072 max_used_connections=1 max_threads=2050 thread_count=1 -It is possible that mysqld could use up to +It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4523497 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. @@ -139,23 +139,23 @@ information that should help you find out what is causing the crash. Writing a core file... Working directory at /export/mysql/var/lib/mysql Resource Limits: -Limit Soft Limit Hard Limit Units -Max cpu time unlimited unlimited seconds -Max file size unlimited unlimited bytes -Max data size unlimited unlimited bytes -Max stack size 8388608 unlimited bytes -Max core file size 0 unlimited bytes -Max resident set unlimited unlimited bytes -Max processes 3094157 3094157 processes -Max open files 64000 64000 files -Max locked memory 65536 65536 bytes -Max address space unlimited unlimited bytes -Max file locks unlimited unlimited locks -Max pending signals 3094157 3094157 signals -Max msgqueue size 819200 819200 bytes -Max nice priority 0 0 -Max realtime priority 0 0 -Max realtime timeout unlimited unlimited us +Limit Soft Limit Hard Limit Units +Max cpu time unlimited unlimited seconds +Max file size unlimited unlimited bytes +Max data size unlimited unlimited bytes +Max stack size 8388608 unlimited bytes +Max core file size 0 unlimited bytes +Max resident set unlimited unlimited bytes +Max processes 3094157 3094157 processes +Max open files 64000 64000 files +Max locked memory 65536 65536 bytes +Max address space unlimited unlimited bytes +Max file locks unlimited unlimited locks +Max pending signals 3094157 3094157 signals +Max msgqueue size 819200 819200 bytes +Max nice priority 0 0 +Max realtime priority 0 0 +Max realtime timeout unlimited unlimited us Core pattern: core Kernel version: Linux version 5.10.0-22-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.178-3 (2023-04-22) @@ -216,3 +216,9 @@ Huh, so this was not a code problem. Configured database to allow upgrade of tables if necessary and restarted mariadbd. The problem still persists. + +Note Pjotr: this is likely a mariadb bug with 10.5.23, the most recent mariadbd we use (both tux01 and tux02 are older). The dump shows it balks on creating a new thread: pthread_create.c:478. Looks similar to https://jira.mariadb.org/browse/MDEV-32262 + +10.5, 10.6, 10.11 are affected. so running correlations on production crashes mysqld? I am not trying for obvious reasons ;) the threading issues of mariadb look scary - I wonder how deep it goes. + +We'll test for a different version of mariadb combining a Debian update because Debian on tux04 is broken. |