Error 1436 hy000 thread stack overrun mysql

Форум пользователей MySQL

Задавайте вопросы, мы ответим

Страниц: 1

#1 27.08.2014 00:13:24

Помогите понять ошибку (#1436)

—
— Структура таблицы `test1`
—

CREATE TABLE IF NOT EXISTS `test1` (
`a` int ( 11 ) unsigned NOT NULL AUTO_INCREMENT ,
`b` int ( 11 ) unsigned NOT NULL ,
PRIMARY KEY ( `a` )
) ENGINE = InnoDB DEFAULT CHARSET =utf8mb4 COLLATE =utf8mb4_unicode_ci AUTO_INCREMENT = 334 ;

—
— Дамп данных таблицы `test1`
—

INSERT INTO `test1` ( `a`, `b` ) VALUES
( 111 , 222 ) ,
( 333 , 444 ) ;

—
— Триггеры `test1`
—
DROP TRIGGER IF EXISTS `test_logging`;
DELIMITER //
CREATE TRIGGER `test_logging` BEFORE UPDATE ON `test1`
FOR EACH ROW INSERT INTO `test1_log` ( `c`,`d` )
VALUES ( OLD.a,OLD.b )
//
DELIMITER ;

—
— Структура таблицы `test1_log`
—

CREATE TABLE IF NOT EXISTS `test1_log` (
`c` int ( 10 ) unsigned NOT NULL ,
`d` int ( 10 ) unsigned NOT NULL
) ENGINE = InnoDB DEFAULT CHARSET =utf8mb4 COLLATE =utf8mb4_unicode_ci;

—
— Дамп данных таблицы `test1_log`
—

INSERT INTO `test1_log` ( `c`, `d` ) VALUES
( 555 , 666 ) ,
( 777 , 888 ) ;

Попыталась изменить одну ячейку:

Получила в ответ:

mysql написал:

#1436 — Thread stack overrun: 10128 bytes used of a 131072 byte stack, and 128000 bytes needed. Use ‘mysqld —thread_stack=#’ to specify a bigger stack.

Гугл говорит, что не хватает значения «thread_stack» в настройках MySQL, но у меня в конфиге прописано 128К, как этого может быть мало для такого простого запроса?

Источник

How can we help you today?

Support Portal Categories

How to Configure a Large MySQL thread_stack

Modified on: Wed, 24 Mar, 2021 at 3:44 PM

While on Hypernode you have full admin privileges on your entire MySQL database, it is not possible to change root-owned MySQL related config files. This means that you can configure any runtime setting, but settings that go in the mysqld.conf and need to be defined at start-up time or settings that you don’t want to re-apply every time MySQL is restarted sometimes can’t be set by the unprivileged app user.

To facilitate some type of flexibility regarding these settings anyway we have a set of MySQL related opt-in settings that can be set using the hypernode-api or using the hypernode-systemctl command-line tool (which implements this API).

TABLE OF CONTENTS

Enabling a Larger thread_stack

On a Hypernode you can enable the larger thread_stack by running this command:

You can then check the progress of your change by running:

Once the setting has been activated you will see the configuration file change on disk:

You might need to restart MySQL to load the new configuration:

To check the size of your active thread_stack you can run this MySQL query:

Hypernode Docker

Note that if you want to change this setting in a hypernode-docker instead of on your production Hypernode you will not be able to use the hypernode-systemctl command-line tool, as that tool talks to the hypernode-api which for obvious reasons is not connected to your local Docker environment. If you would like to change this setting in your local Docker as well, you can simply edit /etc/mysql/conf.d/mysql-master.cnf as the root user and add the thread_stack line and restart the services.

Shopware

We’ve noticed that for some larger Shopware installations the default thread_stack size can become an issue. If you have the memory to spare changing the MySQL thread_stack from the default 192K to 512K might be a good solution (or at least quick fix to identify your problem).

In Shopware the search index & keywords tables have been seen to require a larger thread_stack in some configurations. We’ve seen issues where queries on these aggregate tables started to cause issues in shops with north of 40K SKU’s during a search reindexation.

If you encounter these types of errors:

It might be a good idea to enable this feature and see if this setting addresses your issue.

Источник

RTFM.WIKI

Ordnung muß sein. Ordnung über alles (18+)

Инструменты пользователя

Инструменты сайта

Содержание

MySQL — коллекция ошибок и фиксов

Ошибки

Foreign key / Внешние ключи / Ошибка #1217

Теория в другом месте. Только фикс.

Текст ошибки может быть разным

В mysql cli отключаем проверку внешних ключей, делаем нужный запрос, включаем обратно.

можно ещё проще сделать

Run ‘systemctl daemon-reload’ to reload units

Warning: The unit file, source configuration file or drop-ins of mariadb.service changed on disk. Run ‘systemctl daemon-reload’ to reload units.

Can’t init tc log

MySQL “Got an error reading communication packet” errors

#1524 — Plugin ‘unix_socket’ is not loaded

Can’t create a new thread (errno 11)

Ошибка Can’t create a new thread (errno 11); if you are not out of available memory, you can consult the manual for a possible OS -dependent bug

Лимиты установленные для MySQL в файле /etc/security/limits.conf будут переопределены файлом /etc/security/limits.d/90-nproc.conf . Поэтому задавать лимиты нужно в 90-nproc.conf или создать отдельный файл 91-mysql.conf

#1698 — Access denied for user ‘root’@’localhost’

Не работает phpmyadmin под root’ом. Для MySQL 127.0.0.1 и localhost это разные хосты.

Добавляем отдельного пользователя для администрирования

что-то там с sudo и unix_socket, не разбирался пока, но вариант рабочий.

mysqldump: Couldn’t execute ‘show events’

Ошибка mysqldump: Couldn’t execute ‘show events’: Cannot proceed because system tables used by Event Scheduler were found damaged at server start после перехода на MariaDB с MySQL 56 на cPanel сервере

mysql_upgrade по рекомендациям тоже не работает с ошибкой mysqldump: Got error: 1102: Incorrect database name ‘#mysql50#.config’» when selecting the database

И мне помог не cPanel, а Plesk

В /var/lib/mysql/ был каталог с точкой в имени.

Чтобы его найти выполним команду

Решение

Удалить/перенести каталог в другой место, выполнить mysql_upgrade.

#1214 — The used table type doesn’t support FULLTEXT indexes

Индексы FULLTEXT поддерживаются в таблицах InnoDB только начиная с MYSQL 5.6, поэтому попробуйте обновить MYSQL и после этого изменить команду таблицы

Waiting for table metadata lock

No directory, logging in with HOME=/

Подобная ошибка была в Debian с репозиторием dotdeb.

Надо поправить /etc/passwd

Должно быть так

Can’t create thread to kill server (errno= 11)

Скорее всего на сервере недостаточно памяти для выбранных настроек в my.cnf .

Т.е. key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections в итоге получается больше чем RAM на сервере.

Решение — уменьшить max_connections и другие параметры исходя из доступных ресурсов.

Can’t create a new thread (errno 11)

Ошибка похожа на Can’t create thread to kill server и также связана с лимитами.

В данном случае нужно увеличить количество открытых файлов и количество процессов ( nofile и nproc ).

По-умолчанию open files равен 1024.

Проверим, чтобы удостовериться

Добавляем в файл /etc/security/limits.conf

Либо устанавливаем лимит только для mysql

Нашёл рекомендацию добавить лимиты в отдельный файл 99-mysql.conf в каталоге /etc/security/limits.d/

unknown variable ‘default-tmp-storage-engine=MyISAM’

Вот такая ошибка может возникнуть если бездумно копировать из разных блогов советы бывалых админов

default-tmp-storage-engine появился только в MySQL 5.6 и если использовать опцию в версии 5.5, то MySQL не запустится.

Host ‘a.b.c.d’ is blocked because of many connection errors; unblock with ‘myscladmin flush-hosts’

Ошибка возникает после 10 (по-умолчанию) неудачных соединений с базой.

Fatal error: Uncaught exception ‘Exception’ with message ‘Error: Can’t open file: ‘./ocr/oc_product.frm’ (errno: 24)

В логе mariadb.log нечто подобное

Решение — см. запись ниже open-files-limit в MariaDB

Текущее использование открытых файлов можно посмотреть так:

InnoDB: mmap(137363456 bytes) failed; errno 12

Решение — уменьшить innodb_buffer_pool_size или добавить RAM.

Правильный UTF-8

а потом трахбах и deprecated

#1146 — Table ‘data_dictionary.CHARACTER_SETS’ doesn’t exist

И опять убунта. Что за чудо система. Не даёт скучать. Сиди чини её нескончаемые баги. Впрочем ничего нового.

И всё начинает работать. До следующего адового бага. Продакшен реди итиху мать.

/usr/sbin/mysqld: Error on realpath() on ‘/var/lib/mysql-files’ (Error 2)

Баг после апгрейда встретился только в Ubuntu

ЕМНИП нужно просто создать каталог /var/lib/mysql-files

‘ERROR 1214 (HY000) at line 784: The used table type doesn’t support FULLTEXT indexes ‘

FULLTEXT INDEX раньше работал только с MyISAM. С версии 5.6 доступен в InnoDB.

Так что либо апгрейд либо ALTER TABLE `yourtable` ENGINE = MyISAM;

Got an error from unknown thread, /builddir/build/BUILD /storage/myisam/mi_write.c:226

Также в логах может быть что-то вроде Incorrect key file for table ‘xyz.MYI’; try to repair it

Казалось бы следует сделать mysqlrepair –auto-repair . Но обычно это не помогает.

Скорее всего нет инодов или кончилось место или недоступен tmpdir в mysql.

Проверяем df -i и df -h . Также проверяем значение tmpdir в my.cnf

mysqldump: Got error: (Errcode: 24) when using LOCK TABLES

Узнал о крутой утилите perror. По коду ошибки покажет, что не так.

Ну и по ошибке выше — попробуйте добавить опцию —single-transaction к mysqldump

Error Number: 1364

Через tcpdump выловил ошибку в php-fpm

Виной всему старый код и новый (5.7) MySQL.

Быстрый фикс — выключить так называемый strict mode

Для этого нужно добавить в my.cnf

Можно также вынести в отдельный файл /etc/mysql/conf.d/disable_strict_mode.cnf

Проверить sql_mode

#1030 — Got error -1 from storage engine

При попытке выполнить SQL запрос в phpmyadmin получаем ошибку #1030 — Got error -1 from storage engine

Вероятно включен innodb_force_recovery в файле my.cnf .

Проверяем логи. Если есть нечто подобное

то значит так оно и есть. Выключаем innodb_force_recovery и всё снова работает.

error: ‘Access denied for user ‘debian-sys-maint’@’localhost’ (using password: YES)’

Смотрим пароль пользователя debian-sys-maint в файле /etc/mysql/debian.cnf

Выполняем 2 SQL запроса, чтобы вернуть гражданину debian-sys-maint его привилегии

Перезапускаем MySQL сервер

open-files-limit в MariaDB

Systemd самостоятельно контролирует, сколько файлов служба (в нашем случае mariadb-server) может открыть, независимо от того, что вы настроили в /etc/my.cnf или в /etc/security/limits.conf .

И вносим следующие правки

Данные новшества однако документированы. Так что надо просто внимательнее читать release notes и changelog.

Unable to lock ./ibdata1, error: 11

Решение в сети, которое якобы некоторым помогает

увы не помогает.

Бытует мнение, что виной всему Apparmor т.к. нигде кроме Ubuntu ошибка эта не встречалась

Можно попробовать добавить в /etc/apparmor.d/usr.sbin.mysqld

надо проверить

unknown option ‘—skip-locking’

Опцию –skip-locking убрали в MySQL 5.5.

Решение: заменить skip-locking на skip-external-locking

Источник

Ошибка MySQL 1436: переполнение стека потоков с простым запросом

Я делаю очень простое обновление таблицы, которое также запускает очень простой триггер, и это дает мне ошибку

Запрос, который я выполняю:

Поле значения является text полем. Так что теоретически он может стать довольно большим. Что не так в данной ситуации.

Триггер, который выполняется:

Почему эта ошибка показывает? Это не похоже на какой-то тяжелый запрос. Также обратите внимание, что база данных почти пуста, всего 2 строки community_fields_values и нет строк в базе данных. user_field_log

Версия MySQL: 5.1.44

1436 — Переполнение стека потока: использовано 6136 байт из стека размером 131072 байта и необходимо 128000 байт.

Ошибка 1436 соответствует ER_STACK_OVERRUN_NEED_MORE в коде mysql 5.1:

Код, печатающий обнаруженную ошибку, находится в sql/sql_parse.cc, функция check_stack_overrun() :

Судя по увиденным значениям, margin равен 128000, а my_thread_stack_size равен 131072.

Единственный вызов check_stack_overrun(), который пытается зарезервировать 128000 байт, исходит от:

Значение STACK_MIN_SIZE равно 16000:

Пока все работает как положено для сервера:

• код выполняет триггер, реализованный с помощью sp_head::execute.
• среда выполнения MySQL проверяет, что в стеке есть не менее 128000 байтов
• эта проверка не проходит (и правильно), и выполнение триггера завершается с ошибкой.

Объем стека, необходимый для выполнения триггера MySQL, не зависит от сложности самого триггера или содержимого/структуры задействованных таблиц.

В чем реальный вопрос, я думаю, почему thread_stack имеет размер только 128 КБ (131072).

Переменная сервера с именем ‘thread_stack’ реализована в C как ‘my_thread_stack_size’ в sql/mysqld.cc:

1024L*128L — минимальное значение этого параметра. Значение по умолчанию — DEFAULT_THREAD_STACK, которое определено в include/my_pthread.h:

Таким образом, по умолчанию размер стека должен быть 192 КБ (32-битные) или 256 КБ (64-битные архитектуры).

Во-первых, проверьте, как был скомпилирован бинарный файл mysqld, чтобы увидеть значение по умолчанию:

В моей системе я получил 256 КБ на 64-битной платформе.

Если есть разные значения, возможно, кто-то создаст сервер с другими параметрами компиляции, такими как -DDEFAULT_THREAD_STACK (или просто изменил исходный код) . Я бы спросил, откуда в этом случае берется двоичный файл.

Во-вторых, проверьте my.cnf на наличие значений по умолчанию, указанных в самом файле конфигурации. Строка, явно задающая значение thread_stack (и с низким значением), определенно вызовет видимую ошибку.

Наконец, проверьте файл журнала сервера на наличие такой ошибки (см. sql/mysqld.cc):

Код сервера вызывает:

• pthread_attr_setstacksize() для установки размера стека
• pthread_attr_getstacksize(), чтобы проверить, сколько стека действительно есть у потока, и жалуется в журнале, если библиотека pthread использовала меньше.

Короче говоря, ошибка видна из-за того, что thread_stack слишком мал по сравнению со значениями по умолчанию, поставляемыми с сервером. Это может произойти:

• при выполнении кастомных сборок сервера, с разными вариантами компиляции
• при изменении значения по умолчанию в файле my.cnf
• если что-то пошло не так в самой библиотеке pthread (по идее из прочтения кода, сам ни разу не видел).

Надеюсь, это ответ на вопрос.

С уважением, — Марк Альф

Обновление (2014-03-11), чтобы сделать «как исправить» более очевидным.

По всей вероятности, происходит то, что значение по умолчанию для файла thread_stack было изменено в файле my.cnf.

Как это исправить, тогда тривиально, найдите, где thread_stack установлен в файле my.cnf, и либо удалите параметр (доверяя коду сервера, чтобы обеспечить приличное значение по умолчанию, чтобы это не повторилось в следующий раз), либо увеличьте стек размер.

Обновление (2021-04-28), проверьте, откуда берется thread_stack:

Используйте таблицу performance_schema.variables_info , чтобы узнать, откуда берется данная переменная.

Здесь по умолчанию используется заводское значение (скомпилированное в бинарном файле mysqld).

Источник

Создала таблицы:

Попыталась изменить одну ячейку:

Получила в ответ:

mysql написал:

#1436 — Thread stack overrun:  10128 bytes used of a 131072 byte stack, and 128000 bytes needed.  Use ‘mysqld —thread_stack=#’ to specify a bigger stack.

Гугл говорит, что не хватает значения «thread_stack» в настройках MySQL, но у меня в конфиге прописано 128К, как этого может быть мало для такого простого запроса?

Popular posts from this blog