Timeout expired как исправить или как организовать?

@simply_denis · Регистрация: 31.12.2009

Author24 — интернет-сервис помощи студентам

Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.

ошибка.

Это я сделал хендлер, к нему большое кол-во запросов идет.

C#

1 2	conn = SqlDataAccessProvider.GetConnection(); conn.Open();

C#

     public bool IsReusable
        {
            get { return false; }
        }

как исправить это все? или как организовать?

закрываю коннект вроде везде

более конкретно, запросы идут к нам с других сайтов, по-этому запросов сейчас довольно много.

Я думал может использовать 1 коннект а не каждый раз новый? Но не знаю можно ли это делать.
база mssql 2008

@Alligieri · 10.01.2012, 23:26

Сообщение от simply_denis

Я думал может использовать 1 коннект а не каждый раз новый?

Нет.
а) выжрет всю память
б) один коннект держит только 1 запрос к БД одновременно (1 комманду или транзакцию)

Увеличте число одновременных подключений со стороны СУБД

@simply_denis · 10.01.2012, 23:57 **[ТС]**

Нету на это доступа.

Другие варианты нужны

Добавлено через 7 минут

б) один коннект держит только 1 запрос к БД одновременно (1 комманду или транзакцию)

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

@Alligieri · 11.01.2012, 01:07

Сообщение от simply_denis

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

т.е. это означает если вы выполнили команду на БД и например она заняла достаточно долгий отрезок времени, то другая команда заюзать данный конекшен не сможет - он не свободен.
Были проблемы даже с ORM LinqToSQL когда ограничение подключений было 20 одновременно и низкий таймаут, страницы сыпались как груши

@slawek · 11.01.2012, 01:15

http://msdn.microsoft.com/en-u... meout.aspx

Пробовали увеличить Connection Timeout?

@simply_denis · 11.01.2012, 01:37 **[ТС]**

Сообщение от Alligieri

т.е. это означает если вы выполнили команду на БД и например она заняла достаточно долгий отрезок времени, то другая команда заюзать данный конекшен не сможет - он не свободен.
Были проблемы даже с ORM LinqToSQL когда ограничение подключений было 20 одновременно и низкий таймаут, страницы сыпались как груши

да вот попробывал, сделать на конект 1-2 запроса.

начало летать, правда надеюсь это не из-за того что вечер.

думаю в entity framework тоже самое может быть?

@Alligieri · 11.01.2012, 02:14

Сообщение от simply_denis

думаю в entity framework тоже самое может быть?

думаю вам надо оптимизировать код НАД уровнем ORM, возможно допущены опасные утечки.
Как показала практика - ORM обычно не создает издержек, все проблемы в неправильном его использовании (неряшливом даже).

@simply_denis · 11.01.2012, 11:14 **[ТС]**

Нет, орм пока не волнует, это главные хендлеры, на которых стоит вся система, и мы их писали в ручную.

@Alligieri · 11.01.2012, 12:06

Сообщение от simply_denis

это главные хендлеры, на которых стоит вся система, и мы их писали в ручную.

ну тогда надо смотреть код. конекты открываються внутри хендлеров?

@simply_denis · 11.01.2012, 12:40 **[ТС]**

Сообщение от Alligieri

ну тогда надо смотреть код. конекты открываються внутри хендлеров?

да. система такая:

начала хендлера
открыл коннект
СЕЛЕКТ
закрыл коннект
открыл коннект
ОБНОВИЛ
закрыл коннект
открыл поток*
хендлер закончился

ПОТОК*
открыл коннект
СЕЛЕКТ, ОБНОВИЛ
закрыл коннект

примерно так

@Alligieri · 11.01.2012, 13:10

simply_denis,

я бы как минимум проксю написал бы для работы с БД. Селекты внутри методов хендлера - это жестоко.

@simply_denis · 11.01.2012, 14:12 **[ТС]**

Нет, она есть, правда сейчас в сыром виде. 7 запросов делать её нормальной времени нет.

@slawek · 11.01.2012, 17:45

Как временное решение, MaxPoolSize и ConnectTimeout в connection string должно решить проблему.
Но понятно, что запросы к сайту будут работать с тормозами, но во всяком случае ошибок не будет.

При использовании using (SQLConnection.....) , как бы даже если происходит ошибка, соединение должно закрываться.

Вы тестировали сайт со stress tools?
Мне кажется это единственный путь, забомбить свой сайт и запускать трейсы, где происходят тормоза.
Возможно использование процедур, а не прямых запросов, во всяком случае для сложных запросов, может ускорить обработку запросов.
Индексация таблиц.
Ну и сами хендлеры, тоже неверно с трассировкой, не обрабатываются лишний раз запросы к ним.
И наверно стоит настроить ASP.NET Health Monitoring.

@Alligieri · 11.01.2012, 18:44

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

@simply_denis · 11.01.2012, 18:47 **[ТС]**

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

@Alligieri · 11.01.2012, 18:55

simply_denis, вы в базу пишете статистику? При том синхронно хендлером?

@slawek · 11.01.2012, 19:00

Сообщение от simply_denis

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

Тогда тем более не понятно, почему тормоз.
Я так понимаю, это Insert запрос?
Может действительно вам стоит кэшировать данные, а записывать в базу скажем по закрытии сессии?
Может таблицы не индексированы?
Какое количество запросов у вас, что сервер не успевает обрабатывать?
MSSQL сервер у вас на том же компьютере, что и вебсервер ?

@Alligieri · 11.01.2012, 19:48

Сообщение от slawek

Может действительно вам стоит кэшировать данные, а записывать в базу скажем по закрытии сессии?

я б предложил как минимум записывать асинхроно -
во-первых не будет задержки страницы на ожидание свободного подключения (потому что клиенту якобы пофик что у вас проблемы с БД),
во-вторых можно инкапсулировать запись в блок try...catch и зацыклить извне этот блок до записи (чтоб перехватывать исключение окончания тайм-аута), можно конечно поиграться и построить что-то поэлегантнее типа очереди,
в-третьих пропадут проблемы с ошибками для страницы

@Alligieri CEO 2258 / 1248 / 57 Регистрация: 16.03.2009 Сообщений: 3,588
	11.01.2012, 18:55	16
	simply_denis, вы в базу пишете статистику? При том синхронно хендлером? 0

@Alligieri CEO 2258 / 1248 / 57 Регистрация: 16.03.2009 Сообщений: 3,588
	10.01.2012, 23:26	2
	Сообщение от simply_denis Я думал может использовать 1 коннект а не каждый раз новый? Нет. а) выжрет всю память б) один коннект держит только 1 запрос к БД одновременно (1 комманду или транзакцию) Увеличте число одновременных подключений со стороны СУБД 0

@simply_denis 37 / 32 / 2 Регистрация: 31.12.2009 Сообщений: 349
	10.01.2012, 23:57 [ТС]	3
	Нету на это доступа. Другие варианты нужны Добавлено через 7 минут б) один коннект держит только 1 запрос к БД одновременно (1 комманду или транзакцию) т.е если я к примеру запускаю дополнительный поток для работой с базой, там лучше открыть новый конект, а перед этим закрыть? 0

@Alligieri CEO 2258 / 1248 / 57 Регистрация: 16.03.2009 Сообщений: 3,588
	11.01.2012, 01:07	4
	Сообщение от simply_denis т.е если я к примеру запускаю дополнительный поток для работой с базой, там лучше открыть новый конект, а перед этим закрыть? т.е. это означает если вы выполнили команду на БД и например она заняла достаточно долгий отрезок времени, то другая команда заюзать данный конекшен не сможет - он не свободен. Были проблемы даже с ORM LinqToSQL когда ограничение подключений было 20 одновременно и низкий таймаут, страницы сыпались как груши 0

@slawek 40 / 40 / 3 Регистрация: 08.01.2012 Сообщений: 96
	11.01.2012, 01:15	5
	http://msdn.microsoft.com/en-u... meout.aspx Пробовали увеличить Connection Timeout? 0

@simply_denis 37 / 32 / 2 Регистрация: 31.12.2009 Сообщений: 349
	11.01.2012, 01:37 [ТС]	6
	Сообщение от Alligieri т.е. это означает если вы выполнили команду на БД и например она заняла достаточно долгий отрезок времени, то другая команда заюзать данный конекшен не сможет - он не свободен. Были проблемы даже с ORM LinqToSQL когда ограничение подключений было 20 одновременно и низкий таймаут, страницы сыпались как груши да вот попробывал, сделать на конект 1-2 запроса. начало летать, правда надеюсь это не из-за того что вечер. думаю в entity framework тоже самое может быть? 0

@Alligieri CEO 2258 / 1248 / 57 Регистрация: 16.03.2009 Сообщений: 3,588
	11.01.2012, 02:14	7
	Сообщение от simply_denis думаю в entity framework тоже самое может быть? думаю вам надо оптимизировать код НАД уровнем ORM, возможно допущены опасные утечки. Как показала практика - ORM обычно не создает издержек, все проблемы в неправильном его использовании (неряшливом даже). 0

@simply_denis 37 / 32 / 2 Регистрация: 31.12.2009 Сообщений: 349
	11.01.2012, 11:14 [ТС]	8
	Нет, орм пока не волнует, это главные хендлеры, на которых стоит вся система, и мы их писали в ручную. 0

@Alligieri CEO 2258 / 1248 / 57 Регистрация: 16.03.2009 Сообщений: 3,588
	11.01.2012, 12:06	9
	Сообщение от simply_denis это главные хендлеры, на которых стоит вся система, и мы их писали в ручную. ну тогда надо смотреть код. конекты открываються внутри хендлеров? 0

@simply_denis 37 / 32 / 2 Регистрация: 31.12.2009 Сообщений: 349
	11.01.2012, 12:40 [ТС]	10
	Сообщение от Alligieri ну тогда надо смотреть код. конекты открываються внутри хендлеров? да. система такая: начала хендлера открыл коннект СЕЛЕКТ закрыл коннект открыл коннект ОБНОВИЛ закрыл коннект открыл поток* хендлер закончился ПОТОК* открыл коннект СЕЛЕКТ, ОБНОВИЛ закрыл коннект примерно так 0

@Alligieri CEO 2258 / 1248 / 57 Регистрация: 16.03.2009 Сообщений: 3,588
	11.01.2012, 13:10	11
	simply_denis, я бы как минимум проксю написал бы для работы с БД. Селекты внутри методов хендлера - это жестоко. 0

	11.01.2012, 19:48

@simply_denis 37 / 32 / 2 Регистрация: 31.12.2009 Сообщений: 349
	11.01.2012, 14:12 [ТС]	12
	Нет, она есть, правда сейчас в сыром виде. 7 запросов делать её нормальной времени нет. 0

@slawek 40 / 40 / 3 Регистрация: 08.01.2012 Сообщений: 96
	11.01.2012, 17:45	13
	Как временное решение, MaxPoolSize и ConnectTimeout в connection string должно решить проблему. Но понятно, что запросы к сайту будут работать с тормозами, но во всяком случае ошибок не будет. При использовании using (SQLConnection.....) , как бы даже если происходит ошибка, соединение должно закрываться. Вы тестировали сайт со stress tools? Мне кажется это единственный путь, забомбить свой сайт и запускать трейсы, где происходят тормоза. Возможно использование процедур, а не прямых запросов, во всяком случае для сложных запросов, может ускорить обработку запросов. Индексация таблиц. Ну и сами хендлеры, тоже неверно с трассировкой, не обрабатываются лишний раз запросы к ним. И наверно стоит настроить ASP.NET Health Monitoring. 1

@Alligieri CEO 2258 / 1248 / 57 Регистрация: 16.03.2009 Сообщений: 3,588
	11.01.2012, 18:44	14
	slawek, simply_denis, как вариант - поработать с кешированием данных. возможно хендлеры обрабатывают много однотипных запросов с однаковыми параметрами, незачем лишний раз дергать базу 0

@simply_denis 37 / 32 / 2 Регистрация: 31.12.2009 Сообщений: 349
	11.01.2012, 18:47 [ТС]	15
	Это только один запрос, все остальные на запись идут в базу, а для статистики оно нужно. 0

@slawek 40 / 40 / 3 Регистрация: 08.01.2012 Сообщений: 96
	11.01.2012, 19:00	17
	Сообщение от simply_denis Это только один запрос, все остальные на запись идут в базу, а для статистики оно нужно. Тогда тем более не понятно, почему тормоз. Я так понимаю, это Insert запрос? Может действительно вам стоит кэшировать данные, а записывать в базу скажем по закрытии сессии? Может таблицы не индексированы? Какое количество запросов у вас, что сервер не успевает обрабатывать? MSSQL сервер у вас на том же компьютере, что и вебсервер ? 0

@Alligieri CEO 2258 / 1248 / 57 Регистрация: 16.03.2009 Сообщений: 3,588
	11.01.2012, 19:48	18
	Сообщение от slawek Может действительно вам стоит кэшировать данные, а записывать в базу скажем по закрытии сессии? я б предложил как минимум записывать асинхроно - во-первых не будет задержки страницы на ожидание свободного подключения (потому что клиенту якобы пофик что у вас проблемы с БД), во-вторых можно инкапсулировать запись в блок try...catch и зацыклить извне этот блок до записи (чтоб перехватывать исключение окончания тайм-аута), можно конечно поиграться и построить что-то поэлегантнее типа очереди, в-третьих пропадут проблемы с ошибками для страницы 0