Webasyst ошибка 1040

Сегодня появилась первый раз ошибка 1040:

Error #1040

Too many connections

Please contact server administrator

С чем это связано и как ее решить? Сайт не работает ((

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

14 ответов

  • популярные
  • новые
  • старые


  • 4

    Ошибка говорит о том, что сервер баз данных на вашем хостинге перегружен. Если используете сторонний хостинг — по этому поводу следует обратиться в службу поддержки хостинга. Если хостинг наш — имеет смысл написать индивидуальный запрос в службу технической поддержки из вашего Центра заказчика:
    webasyst.ru/my/



  • 3

    Периодически повторяется данная ошибка #1040, хостер nic.ru Недлю назад отписали:

    Наши специалисты предприняли все возможные меры, чтобы снизить период недоступности сервисов.
    В настоящее время все сервисы и оборудование хостинга функционируют в штатном режиме.

    Сейчас снова повторяется.. Началось 2 недели назад.



    • +1

      Добрый день! 

      Подскажите как удалось решить проблему ошибка #1040 с хостером nic.ru?

      Последнее время нас достала данная проблема.

      Спасибо



  • 3

    Аналогичная ситуация. Началось примерно пару месяцев назад. Иногда появляется когда админка просто открыта. Хостер уверяет, что с его стороны проблем нет. Хостинг Beget. Подскажите, смог ли кто разобраться с данной проблемой?



    • +1

      1040 в переводе на человеческий — слишком много подключений к базе данных, хостер лукавит



      • +2

        У хостера заявлен лимит в 50. Но почему тогда возникает ошибка и в состоянии простоя просто при открытой админке? И почему несколько лет до этого работало всё нормально %( 

        Если предположить, что это проблема хостера, то есть ли какой способ выявить это и доказать им? Ошибка всегда не предсказуемая, появляется в любой момент и снова всё Ок.



    • +1

      У нас сегодня началось тоже самое и хостинг тот же Beget



  • 1

    Периодически повторяется данная ошибка #1040, хостер nic.ru. 

    Отчего зависит не понятно. Проявляться начала примерно 2 месяца назад. Обращения в хостер nic.ru ни к чему не привели. Типа слишком много подключений к базе данных.

    Главное проявление ее совсем не логично. Может появиться ночью часа в 2, когда нет пользователей. И в тоже время сайт может работать прекрасно во время максимальной нагрузки.

    Может есть какое-то решение. 

    Подскажите. 

    Спасибо!



  • 1

    Здравствуйте,такая же проблема.Кто нибудь нашел решение?



    • +1

      Не решение нужно искать, а нормального хостинга, пользуюсь https://timeweb.com/ru/ — и ни разу не было таких проблем



      • +1

        Вам везет)) Я уже 2 месяца по ночам такое ловлю. Хостер Timeweb ложится все ок)



    • +1

      перейти на нормальный хостинг VDS



      • +1

        и на нормально такое бывает переодически



        • +1

          нет не бывает, т.к. это настраиваемый параметр вашего конфига сервера. Поставьте с запасом.

Добавить ответ

This issue occurs mostly when the maximum allowed concurrent connections to MySQL has exceeded.
The max connections allowed is stored in the gloobal variable max_connections.
You can check it by show global variables like max_connections; in MySQL

You can fix it by the following steps:

Step1:

Login to MySQL and run this command: SET GLOBAL max_connections = 100;

Now login to MySQL, the too many connection error fixed. This method does not require server restart.

Step2:

Using the above step1 you can resolve ths issue but max_connections will roll back to its default value when mysql is restarted.

In order to make the max_connection value permanent, update the my.cnf file.

Stop the MySQL server: Service mysql stop

Edit the configuration file my.cnf: vi /etc/mysql/my.cnf

Find the variable max_connections under mysqld section.

[mysql]

max_connections = 300

Set into higher value and save the file.

Start the server: Service mysql start

Note:
Before increasing the max_connections variable value, make sure that, the server has adequate memory for new requests and connections.

MySQL pre-allocate memory for each connections and de-allocate only when the connection get closed. When new connections are querying, system should have enough resources such memory, network and computation power to satisfy the user requests.

Also, you should consider increasing the open tables limit in MySQL server to accommodate the additional request. And finally. it is very important to close the connections which are completed transaction on the server.

И снова ERROR 1040…

Техподдержка получает много жалоб на эту печально известную ошибку: ERROR 1040: Too many connections — слишком много соединений. Проблема очевидна: приложение или пользователи создают больше соединений, чем допускает сервер, то есть текущее число соединений превышает значение переменной max_connections.

Ситуация уже сама по себе проблема для конечных пользователей, но если еще при этом у вас нет доступа к серверу для диагностики и исправления причины, все становится совсем плохо. Обычно приходится завершать экземпляр и перезапускать его, чтобы восстановить.

Root-пользователь тоже не может подключиться! Почему?!

В правильно настроенной среде пользователь с привилегией SUPER сможет получить доступ к экземпляру и диагностировать причину ошибки 1040, из-за которой не хватает соединений. Это описано в руководстве:

mysqld разрешает max_connections + 1 клиентских соединений. Дополнительное соединение зарезервировано для аккаунтов с привилегиями SUPER. Когда эти привилегии предоставляются администраторам, а не обычным пользователям (которым они и не нужны), администратор, у которого есть еще и привилегия PROCESS, может подключиться к серверу и использовать SHOW PROCESSLIST, чтобы диагностировать проблемы, даже если подключено максимальное число клиентов без привилегий.

Но куча людей дают привилегии SUPER своим пользователям приложения или скрипта — из-за требований приложения (опасно!) или незнания последствий, а потом зарезервированное соединение занимает обычный пользователь, а административный пользователь (обычно root) не может подключиться.

Как гарантировать доступ к экземпляру

Можно использовать хорошо известный хак с GDB, который советовал Ауримас лет 100 назад для ошибки 1040, но теперь есть решения получше. Правда сначала их надо включить.
С Percona Server 5.5.29 и выше и MySQL 8.0.14 и выше можно настроить еще один порт с дополнительным числом соединений. Приложение не будет использовать эти интерфейсы. Они только для администраторов баз данных и агентов мониторинга и проверки работоспособности (см. примечание ниже).

Настройка Percona Server

Начиная с Percona Server 5.5.29 можно просто добавить extra_port в my.cnf, и при следующем перезапуске порт будет доступен и будет ожидать данные по тому же bind_address, что и обычные соединения. Если не настроить переменную extra_port, дополнительного порта по умолчанию не будет.

Еще можно определить extra_max_connections, чтобы задать количество подключений, которое будет обрабатывать этот порт. Количество по умолчанию — 1.

Для примера я занял все подключения к порту обычных пользователей у экземпляра, где уже настроил extra_port и extra_max_connections в my.cnf:

результат

Кстати, extra_port удален в Percona Server 8.0.14 и выше, поскольку в MySQL Community реализован admin_port с теми же функциями. Так что отредактируйте my.cnf при апгрейде до Percona Server 8.0.14 или выше, если вы уже определили extra_port.

Как я уже сказал, для этого нужен MySQL 8.0.14, где применен WorkLog 12138.

Чтобы включить админский интерфейс, нужно определить admin_addres, который должен быть единственным и уникальным (без подстановочных символов) IPv4, IPv6, IPv4-сопоставленным адресом или именем хоста, по которому админский интерфейс будет ожидать передачи данных. Если эта переменная не определена, интерфейс не включен.

Еще можно определить порт, но это не обязательно. По умолчанию это порт 33062. Если этот порт свободен, это значение не нужно настраивать. Если настраиваете, то поместите обе переменные в раздел [mysqld] в my.cnf.

Наконец, можно настроить create_admin_listener_thread (отключено по умолчанию), который создает отдельный поток для обработки входящих соединений. Это может пригодиться в некоторых ситуациях.

Еще одно различие — в документации Oracle сказано, что:

Число административных соединений не ограничено.

(А у нас значение по умолчанию — 1). Не уверен, что это значит, но я бы был осторожен, чтобы случайно не установить 1 млн соединений. Они, конечно, не ограничены, но ресурсы-то все равно потребляют.

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

Удобно, что не только люди могут использовать дополнительный интерфейс или порт в экстренной ситуации, когда мы достигли max_connections. К нему может подключиться система мониторинга и проверки работоспособности прокси/балансировщика нагрузки/обнаружения сервисов.

Скрипты мониторинга смогут извлекать данные для диаграмм, чтобы потом вы разобрались, откуда столько соединений. А скрипты проверки работоспособности будут докладывать об ухудшившемся состоянии сервера, и определенный код может указывать, что соединений много, но сервер справляется (то есть может разобраться сам и лучше чуть дольше подождать до отработки отказа).

Обязательно устанавливайте только по одному соединению за раз для мониторинга и проверки работоспособности, чтобы не забивать extra_max_connections в Percona Server и не создать миллион потоков в MySQL. То есть скрипты не должны подключаться снова, если предыдущий запрос или подключение к базе данных еще активны.

Вот тот же пример, но с MySQL.

Для Percona Server 8.0.14 и выше процесс будет тем же, что и для MySQL Community.

Помогите! Мне нужно войти, но все порты заняты!

Если это та самая причина, по которой вы читаете этот пост, используйте безумный хак с GDB (без обид, Ауримас, просто выглядит рисково :-D) или завершите экземпляр. К счастью, экземпляр почти всегда можно аккуратно завершить с помощью SIGTERM (-15) вместо SIGKILL (-9). Так сервер выполнит чистую остановку, и у потоков будет шанс нормально завершить работу. Просто следуйте инструкциям:

1) Получите PID:

marcos.albe in ~/ pgrep -x mysqld;
650

2) Отправьте SIGTERM в этот PID:

marcos.albe in ~/ kill -15 650;

3) Следите в журнале ошибок, как выполняется завершение работы. Это будет выглядеть примерно так:

2019-07-11T13:43:28.421244Z 0 [Note] Giving 0 client threads a chance to die gracefully
2019-07-11T13:43:28.521238Z 0 [Note] Shutting down slave threads
2019-07-11T13:43:28.521272Z 0 [Note] Forcefully disconnecting 0 remaining clients

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

2019-07-11T13:43:31.292836Z 0 [Note] /opt/percona_server/5.7.26/bin/mysqld: Shutdown complete

This issue occurs mostly when the maximum allowed concurrent connections to MySQL has exceeded.
The max connections allowed is stored in the gloobal variable max_connections.
You can check it by show global variables like max_connections; in MySQL

You can fix it by the following steps:

Step1:

Login to MySQL and run this command: SET GLOBAL max_connections = 100;

Now login to MySQL, the too many connection error fixed. This method does not require server restart.

Step2:

Using the above step1 you can resolve ths issue but max_connections will roll back to its default value when mysql is restarted.

In order to make the max_connection value permanent, update the my.cnf file.

Stop the MySQL server: Service mysql stop

Edit the configuration file my.cnf: vi /etc/mysql/my.cnf

Find the variable max_connections under mysqld section.

[mysql]

max_connections = 300

Set into higher value and save the file.

Start the server: Service mysql start

Note:
Before increasing the max_connections variable value, make sure that, the server has adequate memory for new requests and connections.

MySQL pre-allocate memory for each connections and de-allocate only when the connection get closed. When new connections are querying, system should have enough resources such memory, network and computation power to satisfy the user requests.

Also, you should consider increasing the open tables limit in MySQL server to accommodate the additional request. And finally. it is very important to close the connections which are completed transaction on the server.


How to interpret “MySQL error 1040 – Too many connections ! ” ?

When a client tries to log into MySQL it may sometimes be rejected and receive an error message saying that there are “too many connections“. This means that the maximum number of clients that may be connected to the server has been reached. Either the client will have to wait for another client to log off, or the administrator will have to increase the maximum number of connections allowed.

Information about connections to a server can be found using the SHOW STATUS statement:

SHOW STATUS LIKE 'max_used_connections';

Prerequisite – Few points to remember before working or troubleshooting MySQL ” Too many connections ! ” error

  1. MySQL does not have it’s own thread handling mechanism / implementation and it completely relies on the thread handling implementation of the underlying operating system.
  2. MySQL system variable max_connections control the maximum number of clients the server permits to connect simultaneously,   You may have to increase max_connections if more clients attempt to connect simultaneously then the server is configured to handle (Explained more in detail –  “Too many connections”).
  3. How MySQL connection handling (both connects and disconnects) works  ?
    1. MySQL Clients connects to MySQL Server via a simple and regular TCP-IP connect message though port 3306 on the Server instance
    2. The incoming connection requests are queued and then processed by the receiver thread one by one, All that receiver thread does is create user thread.  It’s actually user thread which handles the client-server protocol for connection management, Which involves allocate and initialize the corresponding THD for user authentication based on credentials stored on THD’s security policies / directories and finally if successfully authorized in the connection phase, the user thread will enter command phase
    3. The  receiver  thread will either create a new OS thread or reuse and existing “free” OS thread if available in the  thread cache. So we strongly recommend increasing  thread cache in  cases where number of  connections fluctuates  between ver few connections  and having  many connections. But there are three things which a thread might need to wait for:  A mutex, a database lock, or IO.
    4. THD basically is a large data structure used for several purposes like connection management, authorization and even unto to query execution, So how  much THD consumes memory is directly proportionate to the query execution complexities and connection traffic.

MySQL error – Too many connections, How to fix ?

Recently one of customers ( among the top 5 largest e-commerce companies in the world ) called us to check how graceful their connection handling works during peak hours of business, They had issues in  the past with ” ERROR 1040: Too many connections “ and that clearly explains the maximum number of clients that may be connected to the server has been reached so either the client will have to wait for another client to log off, or the administrator will have to increase the maximum number of connections allowed. so wanted us to do a detailed health-check on MySQL connection management and address “Too many connections” error proactively, We have explained below on how we could successfully reproduce this issue and recommended the fix:

Goal: Manage  50,000 connections on MySQL 8.0 (Ubuntu)

The default setting for system variable max_connections is “151”and we are benchmarking 50K connections so the first step before benchmarking  is to increase max_connections to 50000. we increased max_connections to 50000 dynamically and what happened after that was not expected, We have copied the results below:

root@MDB1:~# mysql -uroot -pMDB@PassWd2020 -se "select @@max_connections"
@@max_connections
697

We got only 697 connections, Let’s interpret MySQL error log before proceeding to next steps.. We have copied the same below:

2020-01-30T19:52:35.136192Z0 [Warning] Changed limits: max_open_files: 5129 (requested 10000)
2020-01-30T19:54:13.241937Z0 [Warning] Changed limits: max_connections: 4152 (requested 10000)
2020-01-30T19:57:47.51617Z0 [Warning] Changed limits: table_open_cache: 533 (requested 15000)

This is due to open files limitations for MySQL so let’s increase now the number of allowed open files for MySQL, The following steps we did to fix this resource limit issue:

  • Option  1 – Locate the systemd configuration folder for MySQL and create file /etc/systemd/system/mysqld.service.d/override.conf (file can be called anything ending with .conf).
    • Add LimitNOFILE=55000 in the file override.conf
    • Add TasksMax=55000 in the file override.conf
    • Add LimitNPROC=55000 in the file override.conf
  • Option 2 – We can also create/modify the override file by using native systemctl command like: systemctl edit mysql
root@MDB1:~# cat /etc/systemd/system/mysql.service.d/override.conf
[Service]
LimitNOFILE=55000
TasksMax=55000
LimitNPROC=55000

** MySQL uses some files for additional work and we need to set LimitNOFILE, TasksMax and LimitMPROC higher to get 50000 connections, lets set it to 55000 and reload the systemd daemon and restart the MySQL service.

Reload the systmed daemon and restart the MySQL service:

root@MDB1:~# systemctl daemon-reload
root@MDB1:~# systemctl restart mysql

Now let’s check max_connections to confirm the change applied:

root@MDB1:~# mysql -uroot -pMDB@PassWd2020 -se "select @@max_connections"
mysql: [Warning] Using a password on the command line interface can be insecure.
@@max_connections
50000

Conclusion

We have no fixed value recommendations for system variable max_connections, It completely depends on your application load and how your application does connection handling. We advice our customers to avoid too many connections opened concurrently because each thread connected needs memory and there is also resource intensive context switching causing overall performance degradation, Thanks for reading and comments are welcome !

References

  • https://mysqlserverteam.com/mysql-connection-handling-and-scaling/ 
  • http://mysql-nordic.blogspot.com/2019/04/mysql-error-too-many-connections.html 
  • https://dev.mysql.com/doc/refman/5.7/en/using-systemd.html 

Book your appointment for 30 minutes ( absolutely free ) MinervaDB consulting 

— На основе оценок
3

человек

Ошибка Mysql connect error [localhost]: (1040) Too many connections (400) возникает в случае превышения лимита одновременных соединений с базой данных MySQL.

Причины ошибки

Как сказано выше, причина проста — «Много одновременных соединений с БД». Стоит понимать, что имеется ввиду БД с которой работает Битрикс, но с этой БД может и работать другой сайт по удаленному подключению. Причины:

  • Много пользователей на сайте;
  • DDos атака на сайт;
  • DDos атака на сайт, который использует данную БД через удаленное подключение;
  • Ошибка в скрипте сайта (в следствии чего, сайт не может закрывать запросы, при этом образовывается много SLEEP запросов);
  • Ошибка в скрипте сайта, который использует удаленное подключение (в следствии чего, сайт не может закрывать запросы, при этом образовывается много SLEEP запросов);

Методы обнаружения проблемы

Чтобы обнаружить, в чем именно проблема, нужноузнать количество соединений к MySql и проанализировать их (время, какой пользователь делает, с какого IP).
Пример анализа запросов к БД

Как исправить

Есть всего 3 варианта исправления: увеличить количество одновременных соединений (если проблема связанна с большим посещением сайта реальных пользователей ), отражение DDOS атаки, или оптимизацией кода сайта. Как вы понимаете, универсального рецепта нет и быть не может. Если вам не помогло увеличения лимита, и вы не знаете что делать в случае DDOS или как оптимизировать код сайта — обращайтесь к профессионалам.


Вас могут заинтересовать следующие услуги

1

I am getting an erro #1040 on the back end because something is hammering the database — I think it may be to do with live help

2 comments

  • popular
  • newest
  • oldest


  • +1

    this is coding issue of some plugin, that may be not closing the DB connection or keep on opening new connection without using existing connection. So it exhaust the number of connections….

    I can resolve the issue… contact info@srinternet.net



  • +1

    Mike

    Mike


    January 9, 2020 09:20

    #

    If the issue persists, please send a request to our support team—we shall try to help you investigate its cause.

    Posting new comments is disabled for this topic.

    Время на прочтение
    4 мин

    Количество просмотров 16K

    И снова ERROR 1040…

    Техподдержка получает много жалоб на эту печально известную ошибку: ERROR 1040: Too many connections — слишком много соединений. Проблема очевидна: приложение или пользователи создают больше соединений, чем допускает сервер, то есть текущее число соединений превышает значение переменной max_connections.

    Ситуация уже сама по себе проблема для конечных пользователей, но если еще при этом у вас нет доступа к серверу для диагностики и исправления причины, все становится совсем плохо. Обычно приходится завершать экземпляр и перезапускать его, чтобы восстановить.

    Root-пользователь тоже не может подключиться! Почему?!

    В правильно настроенной среде пользователь с привилегией SUPER сможет получить доступ к экземпляру и диагностировать причину ошибки 1040, из-за которой не хватает соединений. Это описано в руководстве:

    mysqld разрешает max_connections + 1 клиентских соединений. Дополнительное соединение зарезервировано для аккаунтов с привилегиями SUPER. Когда эти привилегии предоставляются администраторам, а не обычным пользователям (которым они и не нужны), администратор, у которого есть еще и привилегия PROCESS, может подключиться к серверу и использовать SHOW PROCESSLIST, чтобы диагностировать проблемы, даже если подключено максимальное число клиентов без привилегий.

    Но куча людей дают привилегии SUPER своим пользователям приложения или скрипта — из-за требований приложения (опасно!) или незнания последствий, а потом зарезервированное соединение занимает обычный пользователь, а административный пользователь (обычно root) не может подключиться.

    Как гарантировать доступ к экземпляру

    Можно использовать хорошо известный хак с GDB, который советовал Ауримас лет 100 назад для ошибки 1040, но теперь есть решения получше. Правда сначала их надо включить.
    С Percona Server 5.5.29 и выше и MySQL 8.0.14 и выше можно настроить еще один порт с дополнительным числом соединений. Приложение не будет использовать эти интерфейсы. Они только для администраторов баз данных и агентов мониторинга и проверки работоспособности (см. примечание ниже).

    Настройка Percona Server

    Начиная с Percona Server 5.5.29 можно просто добавить extra_port в my.cnf, и при следующем перезапуске порт будет доступен и будет ожидать данные по тому же bind_address, что и обычные соединения. Если не настроить переменную extra_port, дополнительного порта по умолчанию не будет.

    Еще можно определить extra_max_connections, чтобы задать количество подключений, которое будет обрабатывать этот порт. Количество по умолчанию — 1.

    Для примера я занял все подключения к порту обычных пользователей у экземпляра, где уже настроил extra_port и extra_max_connections в my.cnf:

    результат

    Кстати, extra_port удален в Percona Server 8.0.14 и выше, поскольку в MySQL Community реализован admin_port с теми же функциями. Так что отредактируйте my.cnf при апгрейде до Percona Server 8.0.14 или выше, если вы уже определили extra_port.

    Как я уже сказал, для этого нужен MySQL 8.0.14, где применен WorkLog 12138.

    Чтобы включить админский интерфейс, нужно определить admin_addres, который должен быть единственным и уникальным (без подстановочных символов) IPv4, IPv6, IPv4-сопоставленным адресом или именем хоста, по которому админский интерфейс будет ожидать передачи данных. Если эта переменная не определена, интерфейс не включен.

    Еще можно определить порт, но это не обязательно. По умолчанию это порт 33062. Если этот порт свободен, это значение не нужно настраивать. Если настраиваете, то поместите обе переменные в раздел [mysqld] в my.cnf.

    Наконец, можно настроить create_admin_listener_thread (отключено по умолчанию), который создает отдельный поток для обработки входящих соединений. Это может пригодиться в некоторых ситуациях.

    Еще одно различие — в документации Oracle сказано, что:

    Число административных соединений не ограничено.

    (А у нас значение по умолчанию — 1). Не уверен, что это значит, но я бы был осторожен, чтобы случайно не установить 1 млн соединений. Они, конечно, не ограничены, но ресурсы-то все равно потребляют.

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

    Удобно, что не только люди могут использовать дополнительный интерфейс или порт в экстренной ситуации, когда мы достигли max_connections. К нему может подключиться система мониторинга и проверки работоспособности прокси/балансировщика нагрузки/обнаружения сервисов.

    Скрипты мониторинга смогут извлекать данные для диаграмм, чтобы потом вы разобрались, откуда столько соединений. А скрипты проверки работоспособности будут докладывать об ухудшившемся состоянии сервера, и определенный код может указывать, что соединений много, но сервер справляется (то есть может разобраться сам и лучше чуть дольше подождать до отработки отказа).

    Обязательно устанавливайте только по одному соединению за раз для мониторинга и проверки работоспособности, чтобы не забивать extra_max_connections в Percona Server и не создать миллион потоков в MySQL. То есть скрипты не должны подключаться снова, если предыдущий запрос или подключение к базе данных еще активны.

    Вот тот же пример, но с MySQL.

    Для Percona Server 8.0.14 и выше процесс будет тем же, что и для MySQL Community.

    Помогите! Мне нужно войти, но все порты заняты!

    Если это та самая причина, по которой вы читаете этот пост, используйте безумный хак с GDB (без обид, Ауримас, просто выглядит рисково :-D) или завершите экземпляр. К счастью, экземпляр почти всегда можно аккуратно завершить с помощью SIGTERM (-15) вместо SIGKILL (-9). Так сервер выполнит чистую остановку, и у потоков будет шанс нормально завершить работу. Просто следуйте инструкциям:

    1) Получите PID:

    marcos.albe in ~/ pgrep -x mysqld;
    650

    2) Отправьте SIGTERM в этот PID:

    marcos.albe in ~/ kill -15 650;

    3) Следите в журнале ошибок, как выполняется завершение работы. Это будет выглядеть примерно так:

    2019-07-11T13:43:28.421244Z 0 [Note] Giving 0 client threads a chance to die gracefully
    2019-07-11T13:43:28.521238Z 0 [Note] Shutting down slave threads
    2019-07-11T13:43:28.521272Z 0 [Note] Forcefully disconnecting 0 remaining clients

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

    2019-07-11T13:43:31.292836Z 0 [Note] /opt/percona_server/5.7.26/bin/mysqld: Shutdown complete

    Сегодня появилась первый раз ошибка 1040:

    Error #1040

    Too many connections

    Please contact server administrator

    С чем это связано и как ее решить? Сайт не работает ((

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

    14 ответов

    • популярные
    • новые


    • 4

      Ошибка говорит о том, что сервер баз данных на вашем хостинге перегружен. Если используете сторонний хостинг — по этому поводу следует обратиться в службу поддержки хостинга. Если хостинг наш — имеет смысл написать индивидуальный запрос в службу технической поддержки из вашего Центра заказчика:
      webasyst.ru/my/



    • 3

      Периодически повторяется данная ошибка #1040, хостер nic.ru Недлю назад отписали:

      Наши специалисты предприняли все возможные меры, чтобы снизить период недоступности сервисов.
      В настоящее время все сервисы и оборудование хостинга функционируют в штатном режиме.

      Сейчас снова повторяется.. Началось 2 недели назад.



      • +1

        Добрый день! 

        Подскажите как удалось решить проблему ошибка #1040 с хостером nic.ru?

        Последнее время нас достала данная проблема.

        Спасибо



    • 3

      Аналогичная ситуация. Началось примерно пару месяцев назад. Иногда появляется когда админка просто открыта. Хостер уверяет, что с его стороны проблем нет. Хостинг Beget. Подскажите, смог ли кто разобраться с данной проблемой?



      • +1

        1040 в переводе на человеческий — слишком много подключений к базе данных, хостер лукавит



        • +2

          У хостера заявлен лимит в 50. Но почему тогда возникает ошибка и в состоянии простоя просто при открытой админке? И почему несколько лет до этого работало всё нормально %( 

          Если предположить, что это проблема хостера, то есть ли какой способ выявить это и доказать им? Ошибка всегда не предсказуемая, появляется в любой момент и снова всё Ок.



      • +1

        У нас сегодня началось тоже самое и хостинг тот же Beget



    • 1

      Периодически повторяется данная ошибка #1040, хостер nic.ru. 

      Отчего зависит не понятно. Проявляться начала примерно 2 месяца назад. Обращения в хостер nic.ru ни к чему не привели. Типа слишком много подключений к базе данных.

      Главное проявление ее совсем не логично. Может появиться ночью часа в 2, когда нет пользователей. И в тоже время сайт может работать прекрасно во время максимальной нагрузки.

      Может есть какое-то решение. 

      Подскажите. 

      Спасибо!



    • 1

      Здравствуйте,такая же проблема.Кто нибудь нашел решение?



      • +1

        Не решение нужно искать, а нормального хостинга, пользуюсь https://timeweb.com/ru/ — и ни разу не было таких проблем



        • +1

          Вам везет)) Я уже 2 месяца по ночам такое ловлю. Хостер Timeweb ложится все ок)



      • +1

        перейти на нормальный хостинг VDS



        • +1

          и на нормально такое бывает переодически



          • +1

            нет не бывает, т.к. это настраиваемый параметр вашего конфига сервера. Поставьте с запасом.

    Добавить ответ

    Error 1040 Too many connections — ошибка, которая возникает при превышении максимального количества возможных подключений к серверу баз данных со стороны скриптов сайта.

    Устраняется, как правило, увеличением лимита в конфигурации сервера.

    Обычно превышением количества соединений проявляется как прекративший работать сайт. Ошибку можно увидеть попробовав подключиться к базе данных с реквизитами пользователя, от имени которого работает сайт.

    mysql -u USERNAME -p

    Enter password:

    ERROR 1040 (08004): Too many connections

    От имени суперпользователя подключиться удастся в случае если сайт работает не от root.

    mysql -u root -p

    Лимит существует для пользователя, если сайт работает от root (что именно из-за этого является плохой практикой) и появилась такая ошибка — требуется перезапуск службы MySQL через systemctl restart mysql.

    Если удалось зайти в консоль MySQL проверяем актуальное значение директивы max_user_connection. В данном случае нас интересует прежде всего оно.

    show status like ‘%connected%’;

    +-------------------+-------+
    | Variable_name | Value |
    +-------------------+-------+
    | Threads_connected | 151 |
    +-------------------+-------+
    1 row in set (0.01 sec)
    

    А также действующий лимит

    show global variables like ‘%connections%’;

    +----------------------+-------+
    | Variable_name | Value |
    +----------------------+-------+
    | max_connections | 151 |
    | max_user_connections | 0 |
    +----------------------+-------+
    2 rows in set (0.00 sec)
    

    Лимит достигнут, скрипты при этом продолжают делать запросы. Исправить ситуацию можно добавив в /etc/mysql/my.cnf такую строку

    max_user_connection=500

    Параметр может задавать не только в /etc/mysql/my.cnf, но и в любом файле, который подключается в /etc/mysql/my.cnf. Главное блок, в который добавляются настройки, он должен определяться директивой [mysqld].

    Пример приведен на скриншоте

    Error 1040 Too many connections

    Затем перезапустив MySQL

    systemctl restart mysql

    Без перезапуска того же результата можно добиться установив новое значение глобальной переменной, от имени root в консоли MySQL это делается таким образом:

    set global max_connections = 500;

    Значение будет в силе пока работает процесс MySQL — до следующего перезапуска. Установку глобальной переменной в консоли можно использовать как временное решение. На постоянно изменить значение можно только в конфигурационном файле с последующим перезапуском службы.

    Лимит теперь увеличен и сайт должен вновь стать доступен.

    Часто причиной является большая активность аудитории и длительные запросы на изменение данных. Они протекают с блокировками, если используются таблицы типа MyISAM получить значительное улучшение можно конвертировав их в InnoDB.

    Читайте также про оптимизацию настроек MySQL.

    This issue occurs mostly when the maximum allowed concurrent connections to MySQL has exceeded.
    The max connections allowed is stored in the gloobal variable max_connections.
    You can check it by show global variables like max_connections; in MySQL

    You can fix it by the following steps:

    Step1:

    Login to MySQL and run this command: SET GLOBAL max_connections = 100;

    Now login to MySQL, the too many connection error fixed. This method does not require server restart.

    Step2:

    Using the above step1 you can resolve ths issue but max_connections will roll back to its default value when mysql is restarted.

    In order to make the max_connection value permanent, update the my.cnf file.

    Stop the MySQL server: Service mysql stop

    Edit the configuration file my.cnf: vi /etc/mysql/my.cnf

    Find the variable max_connections under mysqld section.

    [mysql]

    max_connections = 300

    Set into higher value and save the file.

    Start the server: Service mysql start

    Note:
    Before increasing the max_connections variable value, make sure that, the server has adequate memory for new requests and connections.

    MySQL pre-allocate memory for each connections and de-allocate only when the connection get closed. When new connections are querying, system should have enough resources such memory, network and computation power to satisfy the user requests.

    Also, you should consider increasing the open tables limit in MySQL server to accommodate the additional request. And finally. it is very important to close the connections which are completed transaction on the server.

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

    • Недоступность базы данных
    • Повреждены таблицы БД (Table is marked as crashed)
    • Ошибка 2006: MySQL server has gone away
    • Ошибка 1040: Too many connections
    • Ошибка 1292: Incorrect date value

    Недоступность базы данных

    Необходимо подключиться к серверу по SSH и выполнить следующие проверки:

    1. Проверить, запущена ли служба MySQL:

    service mysql status

    Пример вывода для запущенной службы:

    Если в выводе отсутствует слово running, служба не запущена. В этом случае необходимо попытаться ее запустить:

    service mysql start

    После этого надо проверить работу сайта и сделать следующую проверку, если ошибка сохраняется.

    2. Проверить состояние дискового пространства.

    Просмотреть общий и занятый объем на диске командой:

    df -h

    Доступное пространство должно быть на основном разделе. Если свободное пространство закончилось, необходимо освободить место или перейти на тариф выше. Для работы с дисковым пространством можно использовать утилиты ncdu или du.

    Если на диске достаточно свободного места, но ошибка сохраняется, надо проверить состояние inodes.

    Если не удается решить ошибку самостоятельно, то нужно обратиться в техническую поддержку.

    Повреждены таблицы БД (Table is marked as crashed)

    При возникновении ошибок вида «Warning: Table … is marked as crashed» необходимо выполнить восстановление таблиц.

    Если на сервере установлен phpMyAdmin, можно выполнить восстановление с его помощью. Для этого необходимо:

    1. перейти в интерфейс PMA,
    2. выбрать нужную базу данных в меню слева,
    3. отметить в списке таблицы, которые нужно восстановить — то есть таблицы, имена которых фигурируют в ошибках,
    4. в самом низу страницы нажать на выпадающее меню «С отмеченными» и выбрать вариант «Восстановить».

    Без phpMyAdmin можно выполнить необходимые действия при подключении по SSH. Для восстановления одной таблицы нужно выполнить команду:

    mysqlcheck -r имя_базы имя_таблицы -uroot -p

    Для восстановления всех таблиц в базе используется команда:

    mysqlcheck -r имя_базы -uroot -p

    Также можно выполнить проверку всех таблиц в базе с помощью команды:

    mysqlcheck -r -A -uroot -p

    Ошибка 2006: MySQL server has gone away

    Ошибка MySQL server has gone away означает, что сервер закрыл соединение. Это происходит, как правило, в двух случаях: превышение таймаута ожидания или получение сервером слишком большого пакета.

    В обоих случаях для устранения ошибки потребуется внести правки в конфигурационный файл MySQL. Это делается при подключении к серверу по SSH или с помощью веб-консоли в панели управления.

    Конфигурационный файл может располагаться по различным путям, например:

    /etc/my.cnf
    /etc/mysql/my.cnf
    /etc/mysql/mysql.conf.d/mysqld.cnf

    Чтобы определить, в какой файл необходимо вносить изменения, можно использовать команду вида:

    grep -Rl ‘имя_параметра’ /etc/*

    Например:
    grep -Rl ‘wait_timeout’ /etc/*

    или:
    grep -Rl ‘max_allowed_packet’ /etc/*

    С ее помощью можно выяснить, в каких файлах прописан нужный параметр, и изменить в них его значение.

    Таймаут

    Чтобы увеличить таймаут ожидания, необходимо скорректировать значение параметра wait_timeout

    Нужно открыть конфигурационный файл с помощью редактора, обязательно указав корректный путь к файлу:

    nano /etc/mysql/my.cnf

    Далее нужно изменить значение параметра wait_timeout на более высокое. Значение указывается в секундах: чтобы увеличить время ожидания до 10 минут, необходимо указать значение 600:

    wait_timeout = 600

    После перезапустить службу MySQL:

    service mysql restart

    Размер пакетов

    Скорректировать максимально допустимый размер пакетов можно увеличением параметра max_allowed_packet.

    Нужно открыть конфигурационный файл с помощью редактора, обязательно указав корректный путь к файлу:

    nano /etc/mysql/my.cnf

    Дале нужно изменить значение параметра max_allowed_packet на более высокое (значение указывается в мегабайтах):

    max_allowed_packet = 64M

    После перезапустить службу MySQL:

    service mysql restart

    Ошибка 1040: Too many connections

    Ошибка «Too many connections» означает, что исчерпан лимит подключений к базе данных. Ошибка связана с медленными запросами, которые выполняются слишком долго (в этом случае требуется оптимизация кода) либо в числе одновременных подключений. В этом случае можно попробовать решить проблему увеличением лимита подключений (параметр max_connections) в конфигурационном файле MySQL.

    В пункте выше было описано, как определить расположение файла my.cnf.

    Следует открыть конфигурационный файл с помощью редактора, обязательно указав корректный путь к файлу:

    nano /etc/mysql/my.cnf

    И заменить значение параметра на более высокое, например:

    max_connections = 200

    После перезапустить службу MySQL:

    service mysql restart

    Ошибка 1292: Incorrect date value

    При попытке добавить данные в таблицу MySQL без указания даты может выдаваться ошибка:

    ERROR 1292 (22007): Incorrect date value: ‘0000-00-00’ for column ‘columnname’ at row 1

    Из-за этой ошибки может нарушаться работа импорта в 1С.

    Для исправления ошибки необходимо:

    1.Открыть файл /etc/mysql/my.cnf:

    nano /etc/mysql/my.cnf

    2. В строке, начинающейся с sql-mode=, удалить следующие значения:

    NO_ZERO_IN_DATE

    NO_ZERO_DATE

    STRICT_ALL_TABLES

    3. Выполнить перезагрузку mysql-сервера:

    sudo service mysql restart

    Примечание:

    Если строка вида sql-mode= отсутствует, необходимо:

    1. В файл /etc/mysql/my.cnf после параметра [mysqld] добавить строку:

    sql-mode=»ONLY_FULL_GROUP_BY,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION»

    2. Выполнить перезагрузку mysql-сервера:

    sudo service mysql restart
     

    This issue occurs mostly when the maximum allowed concurrent connections to MySQL has exceeded.
    The max connections allowed is stored in the gloobal variable max_connections.
    You can check it by show global variables like max_connections; in MySQL

    You can fix it by the following steps:

    Step1:

    Login to MySQL and run this command: SET GLOBAL max_connections = 100;

    Now login to MySQL, the too many connection error fixed. This method does not require server restart.

    Step2:

    Using the above step1 you can resolve ths issue but max_connections will roll back to its default value when mysql is restarted.

    In order to make the max_connection value permanent, update the my.cnf file.

    Stop the MySQL server: Service mysql stop

    Edit the configuration file my.cnf: vi /etc/mysql/my.cnf

    Find the variable max_connections under mysqld section.

    [mysql]

    max_connections = 300

    Set into higher value and save the file.

    Start the server: Service mysql start

    Note:
    Before increasing the max_connections variable value, make sure that, the server has adequate memory for new requests and connections.

    MySQL pre-allocate memory for each connections and de-allocate only when the connection get closed. When new connections are querying, system should have enough resources such memory, network and computation power to satisfy the user requests.

    Also, you should consider increasing the open tables limit in MySQL server to accommodate the additional request. And finally. it is very important to close the connections which are completed transaction on the server.


    How to interpret “MySQL error 1040 – Too many connections ! ” ?

    When a client tries to log into MySQL it may sometimes be rejected and receive an error message saying that there are “too many connections“. This means that the maximum number of clients that may be connected to the server has been reached. Either the client will have to wait for another client to log off, or the administrator will have to increase the maximum number of connections allowed.

    Information about connections to a server can be found using the SHOW STATUS statement:

    SHOW STATUS LIKE 'max_used_connections';

    Prerequisite – Few points to remember before working or troubleshooting MySQL ” Too many connections ! ” error

    1. MySQL does not have it’s own thread handling mechanism / implementation and it completely relies on the thread handling implementation of the underlying operating system.
    2. MySQL system variable max_connections control the maximum number of clients the server permits to connect simultaneously,   You may have to increase max_connections if more clients attempt to connect simultaneously then the server is configured to handle (Explained more in detail –  “Too many connections”).
    3. How MySQL connection handling (both connects and disconnects) works  ?
      1. MySQL Clients connects to MySQL Server via a simple and regular TCP-IP connect message though port 3306 on the Server instance
      2. The incoming connection requests are queued and then processed by the receiver thread one by one, All that receiver thread does is create user thread.  It’s actually user thread which handles the client-server protocol for connection management, Which involves allocate and initialize the corresponding THD for user authentication based on credentials stored on THD’s security policies / directories and finally if successfully authorized in the connection phase, the user thread will enter command phase
      3. The  receiver  thread will either create a new OS thread or reuse and existing “free” OS thread if available in the  thread cache. So we strongly recommend increasing  thread cache in  cases where number of  connections fluctuates  between ver few connections  and having  many connections. But there are three things which a thread might need to wait for:  A mutex, a database lock, or IO.
      4. THD basically is a large data structure used for several purposes like connection management, authorization and even unto to query execution, So how  much THD consumes memory is directly proportionate to the query execution complexities and connection traffic.

    MySQL error – Too many connections, How to fix ?

    Recently one of customers ( among the top 5 largest e-commerce companies in the world ) called us to check how graceful their connection handling works during peak hours of business, They had issues in  the past with ” ERROR 1040: Too many connections “ and that clearly explains the maximum number of clients that may be connected to the server has been reached so either the client will have to wait for another client to log off, or the administrator will have to increase the maximum number of connections allowed. so wanted us to do a detailed health-check on MySQL connection management and address “Too many connections” error proactively, We have explained below on how we could successfully reproduce this issue and recommended the fix:

    Goal: Manage  50,000 connections on MySQL 8.0 (Ubuntu)

    The default setting for system variable max_connections is “151”and we are benchmarking 50K connections so the first step before benchmarking  is to increase max_connections to 50000. we increased max_connections to 50000 dynamically and what happened after that was not expected, We have copied the results below:

    root@MDB1:~# mysql -uroot -pMDB@PassWd2020 -se "select @@max_connections"
    @@max_connections
    697

    We got only 697 connections, Let’s interpret MySQL error log before proceeding to next steps.. We have copied the same below:

    2020-01-30T19:52:35.136192Z0 [Warning] Changed limits: max_open_files: 5129 (requested 10000)
    2020-01-30T19:54:13.241937Z0 [Warning] Changed limits: max_connections: 4152 (requested 10000)
    2020-01-30T19:57:47.51617Z0 [Warning] Changed limits: table_open_cache: 533 (requested 15000)

    This is due to open files limitations for MySQL so let’s increase now the number of allowed open files for MySQL, The following steps we did to fix this resource limit issue:

    • Option  1 – Locate the systemd configuration folder for MySQL and create file /etc/systemd/system/mysqld.service.d/override.conf (file can be called anything ending with .conf).
      • Add LimitNOFILE=55000 in the file override.conf
      • Add TasksMax=55000 in the file override.conf
      • Add LimitNPROC=55000 in the file override.conf
    • Option 2 – We can also create/modify the override file by using native systemctl command like: systemctl edit mysql
    root@MDB1:~# cat /etc/systemd/system/mysql.service.d/override.conf
    [Service]
    LimitNOFILE=55000
    TasksMax=55000
    LimitNPROC=55000

    ** MySQL uses some files for additional work and we need to set LimitNOFILE, TasksMax and LimitMPROC higher to get 50000 connections, lets set it to 55000 and reload the systemd daemon and restart the MySQL service.

    Reload the systmed daemon and restart the MySQL service:

    root@MDB1:~# systemctl daemon-reload
    root@MDB1:~# systemctl restart mysql

    Now let’s check max_connections to confirm the change applied:

    root@MDB1:~# mysql -uroot -pMDB@PassWd2020 -se "select @@max_connections"
    mysql: [Warning] Using a password on the command line interface can be insecure.
    @@max_connections
    50000

    Conclusion

    We have no fixed value recommendations for system variable max_connections, It completely depends on your application load and how your application does connection handling. We advice our customers to avoid too many connections opened concurrently because each thread connected needs memory and there is also resource intensive context switching causing overall performance degradation, Thanks for reading and comments are welcome !

    References

    • https://mysqlserverteam.com/mysql-connection-handling-and-scaling/ 
    • http://mysql-nordic.blogspot.com/2019/04/mysql-error-too-many-connections.html 
    • https://dev.mysql.com/doc/refman/5.7/en/using-systemd.html 

    Book your appointment for 30 minutes ( absolutely free ) MinervaDB consulting 

    — На основе оценок
    3

    человек

    Ошибка Mysql connect error [localhost]: (1040) Too many connections (400) возникает в случае превышения лимита одновременных соединений с базой данных MySQL.

    Причины ошибки

    Как сказано выше, причина проста — «Много одновременных соединений с БД». Стоит понимать, что имеется ввиду БД с которой работает Битрикс, но с этой БД может и работать другой сайт по удаленному подключению. Причины:

    • Много пользователей на сайте;
    • DDos атака на сайт;
    • DDos атака на сайт, который использует данную БД через удаленное подключение;
    • Ошибка в скрипте сайта (в следствии чего, сайт не может закрывать запросы, при этом образовывается много SLEEP запросов);
    • Ошибка в скрипте сайта, который использует удаленное подключение (в следствии чего, сайт не может закрывать запросы, при этом образовывается много SLEEP запросов);

    Методы обнаружения проблемы

    Чтобы обнаружить, в чем именно проблема, нужноузнать количество соединений к MySql и проанализировать их (время, какой пользователь делает, с какого IP).
    Пример анализа запросов к БД

    Как исправить

    Есть всего 3 варианта исправления: увеличить количество одновременных соединений (если проблема связанна с большим посещением сайта реальных пользователей ), отражение DDOS атаки, или оптимизацией кода сайта. Как вы понимаете, универсального рецепта нет и быть не может. Если вам не помогло увеличения лимита, и вы не знаете что делать в случае DDOS или как оптимизировать код сайта — обращайтесь к профессионалам.


    Вас могут заинтересовать следующие услуги

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

    Недоступность базы данных

    Подключитесь к серверу по SSH и выполните следующие проверки.

    1. Проверьте, запущена ли служба MySQL:
    service mysql status

    Пример вывода для запущенной службы:

    Running (1)

    Если в выводе отсутствует слово running, служба не запущена. В этом случае необходимо попытаться ее запустить:

    service mysql start

    После проверьте работу сайта.

    Если проблема сохраняется, переходите к следующей проверке.

    1. Проверьте состояние дискового пространства.

    В первую очередь выполните команду ниже, чтобы просмотреть общий и занятый объем на диске:

    df -h

    Важно, чтобы доступное пространство было именно на основном разделе. Если пространство исчерпано, необходимо расширить диск или освободить место на нем. Для работы с дисковым пространством рекомендуем использовать утилиты ncdu или du.

    Если на диске достаточно свободного места, но проблема сохраняется, проверьте состояние inodes.

    Свяжитесь с нами, если вам не удается решить проблему самостоятельно.

    Повреждены таблицы БД (Table is marked as crashed)

    При возникновении ошибок вида «Warning: Table … is marked as crashed» необходимо выполнить восстановление таблиц. 

    Если на сервере установлен phpMyAdmin, можно выполнить восстановление с его помощью. Для этого перейдите в интерфейс PMA и кликните на нужную базу данных в меню слева. Отметьте в списке те таблицы, которые нужно восстановить (то есть таблицы, имена которых фигурируют в ошибках). В самом низу страницы нажмите на выпадающее меню «С отмеченными» и выберите вариант «Восстановить».

    Можно обойтись и без phpMyAdmin, выполнив необходимые действия при подключении по SSH.

    Для восстановления одной таблицы выполните команду:

    mysqlcheck -r имя_базы имя_таблицы -uroot -p

    Для восстановления всех таблиц в базе используйте:

    mysqlcheck -r имя_базы -uroot -p

    Вы также можете выполнить проверку всех таблиц в базе с помощью команды:

    mysqlcheck -r -A -uroot -p

    Ошибка 2006: MySQL server has gone away

    Ошибка MySQL server has gone away означает, что сервер закрыл соединение, что происходит, как правило, в двух случаях: превышение таймаута ожидания или получение сервером слишком большого пакета.

    В обоих случаях для решения проблемы потребуется внести правки в конфигурационный файл MySQL. Это можно сделать при подключении к серверу по SSH или с помощью веб-консоли в панели управления.

    Конфигурационный файл может располагаться по различным путям, например:

    /etc/my.cnf
    /etc/mysql/my.cnf
    /etc/mysql/mysql.conf.d/mysqld.cnf

    Чтобы определить, в какой файл необходимо вносить изменения, можно использовать команду вида:

    grep -Rl 'имя_параметра' /etc/*

    Например:

    grep -Rl 'wait_timeout' /etc/* 
    grep -Rl 'max_allowed_packet' /etc/*

    С ее помощью можно выяснить, в каких файлах прописан интересующий нас параметр, и изменить в них его значение.

    Таймаут

    Чтобы увеличить таймаут ожидания, необходимо скорректировать значение параметра wait_timeout.

    Откройте конфигурационный файл с помощью редактора (укажите корректный путь к файлу):

    nano /etc/mysql/my.cnf

    Измените значение параметра wait_timeout на более высокое. Значение указывается в секундах, т.е. чтобы увеличить время ожидания, например, до 10 минут, необходимо указать 600:

    wait_timeout = 600

    После перезапустите службу MySQL. В Debian/Ubuntu:

    service mysql restart

    В CentOS:

    service mysqld restart

    Размер пакетов

    В этом случае можно скорректировать максимально допустимый размер пакетов, увеличив параметр max_allowed_packet.

    Откройте файл конфигурации (укажите корректный путь к файлу):

    nano /etc/mysql/my.cnf

    Измените значение параметра max_allowed_packet на более высокое (значение указывается в мегабайтах):

    max_allowed_packet = 64M

    И перезапустите службу:

    В Debian / Ubuntu:

    service mysql restart

    В CentOS:

    service mysqld restart

    Ошибка 1040: Too many connections

    Появление ошибки «Too many connections» говорит о том, что исчерпан лимит подключений к базе данных. Как правило, проблема либо в медленных запросах, которые выполняются слишком долго (в этом случае требуется оптимизация кода), либо в числе одновременных подключений. В этом случае можно попробовать решить проблему увеличением лимита подключений (параметр max_connections) в конфигурационном файле MySQL. 

    В пункте выше было описано, как определить расположение файла my.cnf.

    После откройте файл в редакторе, указав корректный путь:

    nano /etc/mysql/my.cnf

    И замените значение параметра на более высокое, например:

    max_connections = 200

    После перезапустите службу:

    В Debian / Ubuntu:

    service mysql restart

    В CentOS:

    service mysqld restart

    Ошибка 1292: Incorrect date value

    При попытке добавить данные в таблицу MySQL без указания даты может выдаваться ошибка:

    ERROR 1292 (22007): Incorrect date value: '0000-00-00' for column 'columnname' at row 1

    Из-за этой ошибки может нарушаться работа импорта в 1С.

    Для решения проблемы необходимо:

          1. Открыть файл /etc/mysql/my.cnf:

    nano /etc/mysql/my.cnf

          2. В строке, начинающейся с sql-mode=, удалить следующие значения:

    NO_ZERO_IN_DATE
    NO_ZERO_DATE
    STRICT_ALL_TABLES

         3. Выполнить перезагрузку mysql-сервера:

    sudo service mysql restart

    Примечание:

    Если строка вида sql-mode= отсутствует, необходимо:

    1. В файл /etc/mysql/my.cnf после параметра [mysqld] добавить строку:
    sql-mode="ONLY_FULL_GROUP_BY,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
    1. Выполнить перезагрузку mysql-сервера:
    sudo service mysql restart

    MySQL: ОШИБКА 1040: Слишком много соединений

    В основном это говорит о том, что MySQL обрабатывает максимальное количество подключений одновременно, и по умолчанию он обрабатывает соединения 100 одновременно.

    Следующие причины приводят к тому, что MySQL запускает соединения.

    • Медленные запросы

    • Методы хранения данных

    • Конфигурация Bad MySQL

    Мне удалось преодолеть эти проблемы, выполнив следующие действия.

    Откройте MySQL command line tool и введите

    show variables like "max_connections";
    

    Это вернет вам что-то вроде этого.

    +-----------------+-------+
    | Variable_name   | Value |
    +-----------------+-------+
    | max_connections | 100   |
    +-----------------+-------+
    

    Вы можете изменить настройку, например. 200, выполнив следующую команду без перезагрузки сервера MySQL.

    set global max_connections = 200;
    

    Теперь, когда вы перезапустите MySQL, в следующий раз он будет использовать этот параметр вместо стандартного.

    Имейте в виду, что увеличение количества подключений увеличит объем оперативной памяти, необходимый для запуска MySQL.

    Error 1040 Too many connections — ошибка, которая возникает при превышении максимального количества возможных подключений к серверу баз данных со стороны скриптов сайта.

    Устраняется, как правило, увеличением лимита в конфигурации сервера.

    Обычно превышением количества соединений проявляется как прекративший работать сайт. Ошибку можно увидеть попробовав подключиться к базе данных с реквизитами пользователя, от имени которого работает сайт.

    mysql -u USERNAME -p

    Enter password:

    ERROR 1040 (08004): Too many connections

    От имени суперпользователя подключиться удастся в случае если сайт работает не от root.

    mysql -u root -p

    Лимит существует для пользователя, если сайт работает от root (что именно из-за этого является плохой практикой) и появилась такая ошибка — требуется перезапуск службы MySQL через systemctl restart mysql.

    Если удалось зайти в консоль MySQL проверяем актуальное значение директивы max_user_connection. В данном случае нас интересует прежде всего оно.

    show status like ‘%connected%’;

    +-------------------+-------+
    | Variable_name | Value |
    +-------------------+-------+
    | Threads_connected | 151 |
    +-------------------+-------+
    1 row in set (0.01 sec)
    

    А также действующий лимит

    show global variables like ‘%connections%’;

    +----------------------+-------+
    | Variable_name | Value |
    +----------------------+-------+
    | max_connections | 151 |
    | max_user_connections | 0 |
    +----------------------+-------+
    2 rows in set (0.00 sec)
    

    Лимит достигнут, скрипты при этом продолжают делать запросы. Исправить ситуацию можно добавив в /etc/mysql/my.cnf такую строку

    max_user_connection=500

    Параметр может задавать не только в /etc/mysql/my.cnf, но и в любом файле, который подключается в /etc/mysql/my.cnf. Главное блок, в который добавляются настройки, он должен определяться директивой [mysqld].

    Пример приведен на скриншоте

    Error 1040 Too many connections

    Затем перезапустив MySQL

    systemctl restart mysql

    Без перезапуска того же результата можно добиться установив новое значение глобальной переменной, от имени root в консоли MySQL это делается таким образом:

    set global max_connections = 500;

    Значение будет в силе пока работает процесс MySQL — до следующего перезапуска. Установку глобальной переменной в консоли можно использовать как временное решение. На постоянно изменить значение можно только в конфигурационном файле с последующим перезапуском службы.

    Лимит теперь увеличен и сайт должен вновь стать доступен.

    Часто причиной является большая активность аудитории и длительные запросы на изменение данных. Они протекают с блокировками, если используются таблицы типа MyISAM получить значительное улучшение можно конвертировав их в InnoDB.

    Читайте также про оптимизацию настроек MySQL.

    Понравилась статья? Поделить с друзьями:
  • Wbase83 dll ошибка 1с
  • Webasyst 500 ошибка
  • Weishaupt ошибка f 25h
  • Webasto список ошибок
  • Weishaupt ошибка aeh