Error 1040 webasyst - Исправление ошибок и поиск оптимальных решений проблем

Сегодня появилась первый раз ошибка 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
      
      нет не бывает, т.к. это настраиваемый параметр вашего конфига сервера. Поставьте с запасом.

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

Источник

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

+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

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

Add comment

Источник

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

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

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

mysql -u USERNAME -p

Enter password:

ERROR 1040 (08004): Too many connections

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

mysql -u root -p

Лимит существует для пользователя, если сайт работает от root (что именно из-за этого является плохой практикой) и появилась такая ошибка — требуется перезагрузка 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

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

/etc/init.d/mysql restart

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

set global max_connections = 500;

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

Источник

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:

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.

Источник

Содержание

Mysql connect error [localhost]: (1040) Too many connections (400)
Причины ошибки
Методы обнаружения проблемы
Как исправить
Подключение MySQL после ошибки 1040: слишком много соединений
И снова ERROR 1040…
Root-пользователь тоже не может подключиться! Почему?!
Как гарантировать доступ к экземпляру
Настройка Percona Server
Настройка в MySQL Community
Использование для мониторинга и проверок работоспособности
Помогите! Мне нужно войти, но все порты заняты!
Подключение MySQL после ошибки 1040: слишком много соединений
И снова ERROR 1040…
Root-пользователь тоже не может подключиться! Почему?!
Как гарантировать доступ к экземпляру
Настройка Percona Server
Настройка в MySQL Community
Использование для мониторинга и проверок работоспособности
Помогите! Мне нужно войти, но все порты заняты!
Preventing MySQL Error 1040: Too Many Connections
Accurately Tune the max_connections Parameter
Avoiding Common Scenarios Resulting in Overuse of Connections
Safeguard Yourself From Being Locked Out
Use a Proxy
Limits Per User

Mysql connect error [localhost]: (1040) Too many connections (400)

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

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

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

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

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

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

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

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

Источник

Подключение MySQL после ошибки 1040: слишком много соединений

И снова 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. То есть скрипты не должны подключаться снова, если предыдущий запрос или подключение к базе данных еще активны.

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

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

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

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

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

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

Источник

Подключение MySQL после ошибки 1040: слишком много соединений

И снова ERROR 1040…

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

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

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

Настройка Percona Server

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

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

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

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

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

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

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

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

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

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

Источник

Preventing MySQL Error 1040: Too Many Connections

One of the most common errors encountered in the MySQL world at large is the infamous Error 1040:

What this means in practical terms is that a MySQL instance has reached its maximum allowable limit for client connections. Until connections are closed, no new connection will be accepted by the server.

I’d like to discuss some practical advice for preventing this situation, or if you find yourself in it, how to recover.

Accurately Tune the max_connections Parameter

This setting defines the maximum number of connections that a MySQL instance will accept. Considerations on “why” you would want to even have a max number of connections are based on resources available to the server and application usage patterns. Allowing uncontrolled connections can crash a server, which may be considered “worse” than preventing further connections. Max_connections is a value designed to protect your server, not fix problems related to whatever is hijacking the connections.

Each connection to the server will consume both a fixed amount of overhead for things like the “thread” managing the connection and the memory used to manage it, as well as variable resources (for instance memory used to create an in-memory table. It is important to measure the application’s resource patterns and find the point at which exceeding that number of connections will become dangerous.

Percona Monitoring and Management (PMM) can help you find these values. Look at the memory usage patterns, threads running, and correlate these with the number of connections. PMM can also show you spikes in connection activity, letting you know how close to the threshold you’re coming. Tune accordingly, keeping in mind the resource constraints of the server.

Seen below is a server with a very steady connection pattern and there is a lot of room between Max Used and Max Connections.

Avoiding Common Scenarios Resulting in Overuse of Connections

Having worked in the Percona Managed Services team for years, I’ve had the first-hand opportunity to see where many businesses get into “trouble” from opening too many connections. Conventional wisdom says that it will usually be a bad code push where an application will behave badly by not closing its open connections or by opening too many quickly for frivolous reasons.

There are other scenarios that I’ve seen that will cause this too even if the application is performing “as expected”. Consider an application stack that utilizes a cache. Over time the application has scaled up and grown. Now consider the behavior under load if the cache is completely cleared. The workers in the application might try to repopulate the cache in mass generating a spike that will overwhelm a server.

It is important to consider the systems that use the MySQL server and prevent these sorts of edge case behaviors or it might lead to problems. If possible, it is a good idea to trap errors in the application and if you run into “Too many connections” have the application back off and slip for a bit before a retry to reduce the pressure on the connection pool.

Safeguard Yourself From Being Locked Out

MySQL actually gives you “breathing” room from being locked out. In versions 5.xx the SUPER user has a +1 always available connection and in versions 8.xx there is a +1 for users with CONNECTION_ADMIN privileges. However, many times a system has lax privilege assignments and maybe an application user is granted these permissions and consumes this extra emergency connection. It is a good idea to audit users and be sure that only true administrators have access to these privileges so that if a server does consume all its available connections, an administrator can step in and take action. There are other benefits to being strict on permissions. Remember that the minimum privilege policy is often a best practice for good reason! And not always just “security”.

MySQL 8.0.14+ also allows us to specify admin_address and admin_port to provide for a completely different endpoint, bypassing the primary endpoint and establishing a dedicated admin connection. If you’re running a lower version but are using Percona Server for MySQL, you’ll have the option of using extra_port and extra_max_connections to achieve another way of connecting.

If you are able to log in as an admin account, you may be able to kill connections, use pt-kill to kill open connections, adjust timeouts, ban offending accounts, or raise the max_connections to free up the server.

If you are unable to log in, you may try to adjust the max_connection value on the fly as a last resort. Please see Too many connections? No problem!

Use a Proxy

Another way to alleviate connection issues (or move the issue to a different layer in the stack), is to adopt the user of a proxy server, such as ProxySQL to handle multiplexing. See Multiplexing (Mux) in ProxySQL: Use Case.

Limits Per User

Another variable that MySQL can use to determine if a connection should be allowed is max_user_connections. By setting this value, it puts a limit on the number of connections for any given user. If you have a smaller number of application users that can stand some limit on their connection usage, you can set this value appropriately to prevent total server connection maximum.

For instance, if we know we have 3 application users and we expect those 3 users to never individually exceed 300 connections, we could set max_user_connections to 300. Between the 3 application users, only a total of 900 connections would be allowed. If max_connections was set to 1000, we’d still have 100 open slots.

Another approach in this same vein that is even more granular is to limit connections PER USER account. To achieve this you can create an account like this:

Источник

И снова ERROR 1040…

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

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

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

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

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

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

Настройка 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:

результат

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

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

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

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

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

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

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

Вот тот же пример, но с 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

Источник

<<<
Назад

ERROR 1040 (HY000): Too many connections
pi@majordomo:~$ ERROR 1040 (HY000): Too many connections

перезапуск базы данных
sudo systemctl restart mysql

запускаем консоль бд с админскими правами

sudo mysql

смотрим текущие значения счетчиков соединений

show status like ‘%onn%’;

Если вам нужно увеличить MySQL Connections без перезапуска MySQL, сделайте, как показано ниже, также, если вы не знаете файл конфигурации, ниже используйте mysqlworkbench или phpmyadmin или командную строку для запуска запросов ниже.

mysql> SET GLOBAL max_connections = 250;
Query OK, 0 rows affected (0.00 sec)

Для постоянных изменений добавьте строку ниже в my.cnf и перезапустите MySQL.

max_connections = 151
выходим

Если ошибка через какое-то время повторится — ищем, кто лезет в базу и не рвет соединения.

Обсуждение (1)

(3)

Источник