#mysql #iis #.net-core
#mysql #iis #.net-core
Вопрос:
Автоматическая ежедневная переработка рабочего процесса IIS иногда (каждые 5-10 дней) нарушает способность приложения подключаться к серверу AWS Aurora (MySQL).
После переработки мы получаем эти ошибки. Другие рабочие процессы в том же экземпляре IIS продолжают работать нормально — все настроены аналогичным образом. Затем ошибочный рабочий процесс зависает, и сам IIS должен быть повторно запущен, чтобы устранить проблему.
Oracle MySQL.Data.MySqlClient Библиотека классов .Net Core 8.0.20
MySQL.Data.MySqlClient.Исключение MySqlException (0x80004005): не удается подключиться ни к одному из указанных хостов MySQL. —> MySQL.Data.MySqlClient.Исключение MySqlException (0x80004005): истек срок ожидания. Период ожидания, прошедший до завершения операции, или сервер не отвечает. в MySQL.Data.Обычный.StreamCreator.GetTcpStream(настройки MySqlConnectionStringBuilder) в MySQL.Data.MySqlClient.NativeDriver.Откройте () в MySQL.Data.MySqlClient.NativeDriver.Откройте () в MySQL.Data.MySqlClient.Драйвер.Откройте () в MySQL.Data.MySqlClient.Драйвер.Создайте (настройки MySqlConnectionStringBuilder) в MySQL.Data.MySqlClient.MySqlPool.Создайте новое пустое соединение () в MySQL.Data.MySqlClient.MySqlPool.GetPooledConnection() в MySQL.Data.MySqlClient.MySqlPool.Попробуйте togetdriver() в MySQL.Data.MySqlClient.MySqlPool.getConnection() в MySQL.Data.MySqlClient.MySqlConnection.Открыть () …
Дополнительная информация из журналов… Может показаться, что он обрабатывает первые несколько новых запросов — затем возникают проблемы — так что это может быть случайным — хотя ошибок журнала событий, соответствующих проблеме, нет…
Пул соединений использует значения по умолчанию: максимальный размер пула 100 Время жизни соединения 0
Дополнительная информация: журналы показывают перед полным сбоем, что некоторые выполнения выполняются нормально, другие занимают много секунд вместо менее 100 мс — в том же рабочем потоке. Так что что-то, связанное с пулом, может пойти не так или экземпляр.
Определенно собираюсь скорректировать, когда происходит циклирование.
Комментарии:
1. ДЕЙСТВИТЕЛЬНО странно то, что другая DLL в том же рабочем процессе может подключаться с помощью MySQL и не подвержена проблеме.
2. достаточно ли высокое максимальное соединение, проверьте журнал ошибок для mysql
3. на стороне сервера разрешено 1000 подключений, а мониторинг показывает, что используется не более 150
4. я бы предположил некоторые проблемы с сетью, вы могли бы добавить в свой код некоторое тестирование netwrk, когда это произойдет, чтобы узнать, возможны ли какие-либо другие адреса
5. У MySQL есть свой собственный форум, forums.mysql.com/list.php?38 Вы также можете обратиться за поддержкой к поставщику.
Ответ №1:
После дополнительных исследований я обнаружил, что мы просто позволяли сборке мусора C # обрабатывать объект SqlConnection вместо правильной инкапсуляции объекта в объявлении «using». Это проблема, потому что до тех пор, пока не будет запущена сборка мусора и не будет уничтожен объект SqlConnection, базовое соединение с базой данных не возвращается в пул соединений. И поэтому, когда все особенно занято, мы тупо умираем с голоду, несмотря на наличие склада, полного еды, потому что сборка мусора откладывается, а соединения своевременно не возвращаются в пул.
Современный синтаксис C # допускает это действительно простое объявление, которое немедленно запускает деструктор, когда объект выходит из области видимости. Поэтому, когда объекты покидают область видимости, система немедленно возвращает базовое соединение обратно в пул, предотвращая смерть приложения от голода.
using MySqlConnection z_connection = new MySqlConnection();
...
using MySqlCommand z_command = z_connection.CreateCommand();
...
using MySqlDataReader z_reader = z_command.ExecuteReader();
...