
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
21.01.2012, 00:52:12
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
Просто аврал! Очень нужна помощь! На работающем проекте на одном сервере находятся маленькие веб-проекты - десятка 4 страничек с формами. На другом сервере (в локальной сети) находится база. Все как бы работало нормально. Но сейчас что-то случилось и коннект к базе происходит секунд 30-60 (был мгновенный). Раньше могло возникнуть иногда исключение типа такого: java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. Но это было достаточно редко и допускаю, что из-за огромного количества параллельных запросов (коннекшн к базе происходит с каждой странички - jsp-шки, а также из сервлетов) - иногда до 20-30 в секунду. Я их уговарию на переделку проекта - сделать одно соединение с кешем, чтобы через него шли запросы. Но пока ломаются, да и решить проблему надо срочно. Например, на первой же странице код такой: Код: java 1. 2. 3. 4. 5. 6. В чем может быть дело, подскажите. Ну очень нужно - висим! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 01:01:48
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
Ну я бы в первую очередь пошел смотреть performance monitor на серваке, где крутится база, на предмет всякой неведомой херни. Ну а архитектура, конечно, очень печальная, чо уж тут греха таить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 01:06:21
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
IDVsbruck, Нормально у тебя всё. Может, сеть глючит. Надо проверить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 01:10:05
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
Да знаю, что нормально. И все проверено - все как раньше. Но вот каждое соединение до минуты делается - никуда не годится. Там, правда, дата-сервер голимый - старый и в последний раз переставлялся в 2006-ом году. Но ведь еще пару недель назад все работало нормально. Правда, меня смущает, что в панели задач SQL Server кушает почти 2 гига памяти. В чем дело - ума не приложу. P.S. Да, архитектурка криворукая - делалась под одну страничку, а за 2 года их уже 40. Если бы платили за то, что надо - все было бы пучком. Но экономят на этом. Вот и проблемы рисуются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 01:24:17
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
IDVsbruck, Архитектура - тоже нормальная. То есть, совсем обычная, как у всех. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 01:53:38
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
IDVsbruck, 60 сек коннект? - перегрузи весь сервак ночью - очисти диск\корзину - проверь загрузку сервака-проца - исключи сеть проверкой коннекта по удалёнке - ssh из нутри него - очисти логи сервака и бэкапы, обычно они разрастаются и забивают весь диск - .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 10:16:56
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
ShSergeАрхитектура - тоже нормальная. То есть, совсем обычная, как у всех.То есть "все" нынче не знают про такие вещи, как connection poo"? И не знают про закешированные prepared statements? Ну значит печальна нынче ситуация, что уж тут сказать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 10:41:50
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
svenomShSergeАрхитектура - тоже нормальная. То есть, совсем обычная, как у всех.То есть "все" нынче не знают про такие вещи, как connection poo"? И не знают про закешированные prepared statements? Ну значит печальна нынче ситуация, что уж тут сказать да брось ты. Пул нужен для публичных веб приложений - сайтов. А не корпоратива менее 1K-10K коннектов. Не надо заужать Java проекты. Оптимизируют где тонко, а не где светло (с) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 11:28:50
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
Petro123svenomпропущено... То есть "все" нынче не знают про такие вещи, как connection poo"? И не знают про закешированные prepared statements? Ну значит печальна нынче ситуация, что уж тут сказать да брось ты. Пул нужен для публичных веб приложений - сайтов. А не корпоратива менее 1K-10K коннектов. Не надо заужать Java проекты. Оптимизируют где тонко, а не где светло (с) Пул нужен для экономии ресурсов и для контроля того, сколько подключений к базе имеет место быть в конкретный момент времени. Далее, корпоратива на Java на несколько порядков больше, чем публичных сайтов, и подавляющее большинство из них использует пулы и работают через DataSource, который получают у сервера через JNDI. То есть это не то что мнение или рекомендация, это то, как работают с Java почти все трехзвенные приложения. А вы мне тут про какие-то публичные сайты залечиваете Ну опять таки, без обид, но - джависты, включая автора, сразу увидели жесткий косяк в архитектуре, те же, кому ближе C# (ShSerge, Petro123) - считают, что это нормально. Как говориться - без комментариев ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 11:37:18
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
svenom, ты не в том месте бучу затеял. Длинные транзакции - это не косяк с точки зрения Java. Его вопрос уже был на форуме. Сабж топика НЕ в пуле. Это ты понял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 11:38:02
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
svenom, 11944034 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 12:37:00
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
Petro123, Пул коннектов лучше использовать всегда. Пул как раз и решит проблемы, описанные в посте,так как пул держит соединения уже открытыми и осуществляет их валидацию и удаление из пула битых коннектов. Плюс время на установление соединения не влияет на скорость работы приложения. Также по росту пула можно легко понять справляется ли база с нагрузкой или нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 12:59:29
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
dominatorPetro123, Пул коннектов лучше использовать всегда. Пишёл больной и говорит _сегодня_ болит живот, _срочно_ помогите. Вы ему о вреде курения будете? "Курить ВСЕГДА вредно?" IDVsbruckВсе как бы работало нормально. Но сейчас что-то случилось и коннект к базе происходит секунд 30-60 (был мгновенный). я так понял, что ПЕРВЫЙ коннект к БД. Тогда пул не в кассу. ЗЫ У меня (совместная с одним челом) тема про длинные транзакции. Что то там все молчат. Напиши там про пул. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 13:01:02
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
заметь - "коннект был мгновенный" без пула и "начальство не считает необходимым менять архитектуру". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 15:04:34
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
svenom...без комментариев Коннекшин-пул - это такая штука, про которую программист и не должен никогда вспоминать. Потому что реализуется сама собой (прослойками) при коннекте. Даже не важно, что за прослойки: JDBC это, ODBC или ADO. Впрочем, некоторые и "ручками" пишут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 15:43:54
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
Хозяева проекта умеют только считать деньги. Техническая сторона дела их практически не интересует. Из-за меня как разраба они даже уволили техспециалиста с компании (она обслуживала базы и делала репорты). Таким образом, на мне как бы техподдержка их железа и их проектов. Компания в Нью-Йорке, поэтому некоторые вопросы решать сложно. Я им предложил единый проект с динамическими страницами под единой "крышей" - это колоссальный выигрыш по базе, а также единая админка на все подпроекты - и мне кусок работы приличный, и им удобно - администрировать мелочи можно без обращения ко мне, да и репорты со статистикой будут сами смотреть, а не по каждому скрипу обращаться. Но дебаты идут еще с лета. Как бы заказчик "забугорный", проект не совсем мизерный (до 2 месяцев точно), а они экономят и "включают аврал" во время компейна. Таким образом, вопрос о пуле открытый - я поддерживаю и вижу выигрыш, да и правильно это. Их планы - до 400 таких подпроектов на сервере. Если на 40 такие лажи, то больше не потянет точно. В пиковые моменты в секунду заходит около 30 человек, а в каждом подпроектике 4 страницы, на каждой из которых есть коннект к базе, а также 3 сервлета, где также присутствуют коннекты. То есть если человек зашел и находится на сайтике, то он может осуществить до 7 коннектов к базе. Ужасно бестолково - это я и сам понимаю, но надо знать как это начиналось, как делалось и какие вопросы решались. Сделать я хочу, но бесплатно - "нафига козе баян"? А вот проблема присутствует. Думали, что они подключили какие-то views на базу ... нету. Изменения не вносились. Правда, пару недель база сама перешла в монопольный режим ... почему, непонятно. Исправили, перегрузили. Вчера откатили базу на начало декабря. Вроде лучше, но тормоза присутствуют все равно. Место на компе есть точно, беки почистили. Локалка работает нормально - никаких нюансов не замечено, firewall ничего не блокирует. На страницах присутствовали скрипты для гугловской статистики. Но из-за длительности работы скрипта по коннекту к базе не грузятся. Пока повыкидывал их. Та же фигня. Брал первую страничку и комментировал коннект к базе. При обращении к страничке срабатывает мгновенно. Убираю коннект - тормоза. То есть проблема точно локализована - это база. На БД-сервере баз дофига и больше, комп старый, WinServer 2000 и SQL Server 2000 - тоже древний. Но все работало достаточно стабильно и нормально, а тут вдруг такой облом. Главное, что неизвестно что происходит, как решить и как застраховаться на будущее (точнее, понятно - новый сервак и грамотная архитектура). Загрузка памяти высокая, но процы как на веб-сервере, так и на дата-сервере, не загружены - тут все нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 16:19:31
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
IDVsbruck, Раз не платят, толку об архитектуре. Профайлером сиквела посмотри какой Конкретно Запрос тормозит. Обычно причина самая простая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 16:27:08
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
Еще. Как застраховаться? Это работа не разраба а ДБА. Нагрузка в пределах расчетной? Значит эксплуатация. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 16:33:08
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
IDVsbruckТаким образом, вопрос о пуле открытый - я поддерживаю и вижу выигрыш, да и правильно это. Их планы - до 400 таких подпроектов на сервере. Если на 40 такие лажи, то больше не потянет точно. В пиковые моменты в секунду заходит около 30 человек, а в каждом подпроектике 4 страницы, на каждой из которых есть коннект к базе, а также 3 сервлета, где также присутствуют коннекты. То есть если человек зашел и находится на сайтике, то он может осуществить до 7 коннектов к базе. Ужасно бестолково - это я и сам понимаю, но надо знать как это начиналось, как делалось и какие вопросы решались. Сделать я хочу, но бесплатно - "нафига козе баян"? Если меня не подводит склероз, медитации на тему ODBC Connection Pool (как минимум) вполне может справиться с вашей проблемой по использованию пула соединений не особо ковыряясь в приложении. А статистика 30 пользователей хоть и по 7 коннектов на сеанс - копейки даже по состоянию на 10 лет назад IDVsbruckА вот проблема присутствует. Думали, что они подключили какие-то views на базу ... нету. Изменения не вносились. Правда, пару недель база сама перешла в монопольный режим ... почему, непонятно. Исправили, перегрузили. Нанять толкового администратора сервера базы данных пробовали? Впрочем, сетевого администратора, скорее всего, тоже не помешало бы... IDVsbruckВчера откатили базу на начало декабря. Вроде лучше, но тормоза присутствуют все равно. Да, уж... Замечательное решение... Так и будете каждый раз откатывать данные на пару месяцев назад? IDVsbruckБрал первую страничку и комментировал коннект к базе. При обращении к страничке срабатывает мгновенно. Убираю коннект - тормоза. То есть проблема точно локализована - это база. Нет. Проблема до уровня базы никоим образом НЕ локализована. Она локализована на сервере базы данных Если исключить глюки операционной системы сервера, тормозить работу сервера баз данных могут и "железные штучки" - проблемы с дисками, памятью и т.п. IDVsbruckНа БД-сервере баз дофига и больше, комп старый, WinServer 2000 и SQL Server 2000 - тоже древний. Но все работало достаточно стабильно и нормально, а тут вдруг такой облом. Главное, что неизвестно что происходит, как решить и как застраховаться на будущее (точнее, понятно - новый сервак и грамотная архитектура). Загрузка памяти высокая, но процы как на веб-сервере, так и на дата-сервере, не загружены - тут все нормально. Нет понятий "старый комп" и "древний сервер". Есть компьютеры и сервера, которые не обслуживается . Соотвественно, возникшая проблема НЕ находится в архитектуре приложений... На что, собственно и указывает локализация проблемы, которую вам удалось выполниь своими силами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 19:07:32
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
Petro123У меня (совместная с одним челом) тема про длинные транзакции. Что то там все молчат. Напиши там про пул. Вроде бы вам исчерпывающе ответили здесь http://www.javatalks.ru/viewtopic.php?p=143293#143293 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 19:30:27
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
IDVsbruckЯ их уговарию на переделку проекта - сделать одно соединение с кешем, чтобы через него шли запросы. Но пока ломаются, да и решить проблему надо срочно. Чито? Вы предлагаете одну одновременно выполняющаяся транзакция или один одновременный запрос к базе на выборку? Я бы не то что ломался, а просто пристрелил бы вас на месте или выслал бы за вами киллера в Россию, тут достаточно как вам выше уже указали ввести пул соединений, чтобы коннекшн не открывался при каждом запросе, а брался готовый из пула, ну и когда база слишком уж удалена от сервера приложений это тоже не гуд, нужно с этим что-то в дальнейшем делать, например вводить WEB сервисы, потому как JDBC некошерно себя ведёт когда СУБД далеко от сервера приложений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 21:49:48
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
ShSergeIDVsbruck, Нормально у тебя всё. Может, сеть глючит. Надо проверить. Авторитет молвит, усё нормально! А то, что на открытие каждого коннекшена тратятся ресурсы как сервера приложений так и сервера баз данных авторитета месье сержа волнует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 21:54:34
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
vimba, OFF Тянет всё вас на оффтоп и литературу :) Пул, это самый простейший паттерн. Ещё проще чем синглетон. Зачем сводить тему к такой ерунде :). (солидарен с мнением выше мемберов) ------------ про ссылку спс. Почитаю. Слабо верится, что там 4-е решение, которого _не было_ у наших спецов в теме. А у первых 3-х есть недостатки (опять прошу в тему) sphinx_mv +1 проблема НЕ в архитектуре ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 21:56:19
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
vimba, ВАС тянет на офттоп. - сколько байт тратит сервер на коннект? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2012, 22:00:37
|
|||
|---|---|---|---|
Очень длинный коннекшн к удаленной базе |
|||
|
#18+
Petro123vimba, ВАС тянет на офттоп. - сколько байт тратит сервер на коннект? Причем тут байты? Операция открытия соединения (будь то HTTP или к СУБД) достаточно дорогая. И разными приемами ее стараются избежать. Если СУБД - пулы соединений, если HTTP - keep-alive. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=59&tablet=1&tid=2132774]: |
0ms |
get settings: |
14ms |
get forum list: |
21ms |
check forum access: |
6ms |
check topic access: |
6ms |
track hit: |
52ms |
get topic data: |
20ms |
get forum data: |
6ms |
get page messages: |
108ms |
get tp. blocked users: |
3ms |
| others: | 369ms |
| total: | 605ms |

| 0 / 0 |
