Здравствуйте.

Программа установлена на 1200 компьютерах. Но, думаю, активно используют ее максимум человек 300-500.

У одного пользователя программа подвисает на простеньком запросе к БД (ADO, MS SQL SERVER 2005). В это же время та же операция, но с моего компьютера, выполняется как всегда быстро. Потом программа опять начинает работать у пользователя нормально (не сказать, что сетевое взаимодействие идет быстро, но хоть работать можно). Потом орять начинает тормозить и т.д. Время между циклами торжения и нормальной работы - примерно пол-дня. Компьютер и сеть проверяли коллеги - сказали, что все нормально. SQL клиент переставляли.

Свой код перечитывал много раз... Нет там ничего такого, что могло бды привести к таким подвисаниям, кроме обращения к БД.

Мистика! Подскажите, пожалуйста, MS SQL SERVER может быть лицеприятен к разным соединениям к нему с разных компьютеров в одно и тоже время под одним и тем же пользователем? Ну и еще: подскажите, пожалуйста, что может быть причиной этой ошибки? Хоть чтобы сказать сетевикам, что проверить, а то ведь они опять скажут, что все работает... а самому поковыряться не дадут... и правильно сделают ;)

Заранее спасибо.

> Компьютер и сеть проверяли коллеги - сказали, что все нормально.

- ну-ну...
Во первых посмотреть системный журнал(eventvwr) - там обычно все написано и помечено красными крестами...
Во вторых обновить антивирус.
В третьих обновить прошивку материнки, драйвер сетевухи.
А дальше SysInternals - procexp, procmon и т.д.

Потом программа опять начинает работать у пользователя нормально

Она у него виснет не на запросе, а на поиске самого сервера перед подключением.

вряд ли тут "тот" случай, из-за периодичности, но единственный раз когда было торможение с ADO + MSSQL в моей программе, был потому, что соединение настроили через ODBC, а в нем (по незнанию/умыслу?) включили логирование... т.е. весь обмен, в виде запросов писался в гигантские текстовые файлы... естественно тормозило. там тормоза были постоянные.

+ на какой системе стоит сервер MSSQL? если на рабочей станции 2000й/xp то там ограничение на количество коннектов к ней = 10, не знаю влияет ли это конкретно на MSSQL но если не серверная операционка то если не это, то возможны другие ограничения.

> Во вторых обновить антивирус.
скорее отключить и посмотреть не он ли сам тому виной...

han_malign, Медвежонок ХМЛ, sniknik
спасибо.

Во время подвисания, почему-то, сильно загружается ЦП (хотя если программа ждет ответа от сервера, по моему, это странно, т.к. ответ - одна небольшая запись).

Сейчас высянил, что, оказывается, иногда тормозит также и еще одна программа (не моя, а купленная), работающая с этим же SQL сервером.

> на какой системе стоит сервер MSSQL?

ОС cерверная - Microsoft Windows Server 2003 (NT 5.2). Сервер сильный (ОЗУ - 32Гб).


> Она у него виснет не на запросе, а на поиске самого сервера
> перед подключением.

Даже после подключения к серверу при старте программы, каждый запрос зависает. Соединение сохраняется во время работы программы. Или провайдер ищет сервер при каждом запросе заново? Кстати, когда программа уже не зависала, первый пинг к серверу БД не дошел, хотя потом все пошло нормально... Подожду следующего зависания и попробую повторить пинг.

а сколько сетевых плат у сервера?

у меня был случай, правда, не с MSSQL, а с самописным сервером.

была организация, у которой сервер был с 3 сетевухами.
сеть была доменная.

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

т.е. комбинация переменных окружения COMPUTERNAME.USERNDSDOMAIN, вместо COMPUTERNAME.

если
> Программа установлена на 1200 компьютерах. .. активно
> используют ..человек 300-500.

значит должны быть админы.

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

> ОС cерверная - Microsoft Windows Server 2003 (NT 5.2). Сервер
> сильный (ОЗУ - 32Гб).

на 2003 Ent отдельно взятая прога все равно не сможет захапать больше 2Гб
С такой оперативой есть смысл переползать на 64 бит

> [5] Дмитрий Тимохов   (01.04.11 10:24)

Карточка одна. Но проверять, как быстро происходит поиск сервера буду, спасибо.

> показать, что программа работает на другой, аналогичной,
> конфигурации нормально. Пусть у них голова болит.

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

"-У нас узкая специализация, я лично пуговицы пришиваю. К пуговицам претензии есть?
-Нет, пришиты намертво, не отдерёшь"

Раздал админам задания, детально их описал. Буду ждать, что они скажут. Пользователь позвонит, как только начнется зависание, запущу тестовые соединения. Все равно причину найду :)

PS: буду рад еще советам, вариантам, предположениям.

> [7] clickmaker ©   (01.04.11 10:40)

Действительно странно... Даже у меня теперь дома 64 битная ОС, т.к. обновил компьютер. Спасибо. Предложу.

> sniknik ©   (01.04.11 09:37) [3]
> если на рабочей станции 2000й/xp то там ограничение на количество
> коннектов к ней = 10

Слышал звон, не понял где он.


> clickmaker ©   (01.04.11 10:40) [7]
> на 2003 Ent отдельно взятая прога все равно не сможет захапать
> больше 2ГбС такой оперативой есть смысл переползать на 64 бит

Ещё один спец.

Как деревенские знахари, все познания по слухам собраны.


> И. Павел ©   (01.04.11 10:49) [10]

Местные бабки-знахарки насоветуют...
Не забудь SQL SERVER тоже 64-битный поставить (ну и соответственную денежку готовь).

> [11] DiamondShark ©   (01.04.11 11:25)

Вот тут неплохо это описано:
http://dynamicsuser.net/blogs/waldo/archive/2007/06/28/sql-server-x64-vs-x86.aspx

Хотя наши даже флажек AWE не удосужились поставить...

> > показать, что программа работает на другой, аналогичной,
> > конфигурации нормально. Пусть у них голова болит.
> У нас "узкая специализация"...

элементарно

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

> OW ©   (01.04.11 12:07) [14]

Угу. А начальник потом пинает тебя: это ж твоя программа тормозит, ты и парься. В лучшем случае, если начальнику больше делать нефиг, он может методом тыка попинать других подчинённых или смежных начальников. Получив отовсюду отписку: "Провели анализ, пришли к выводу, что не наша компетенция" он опять же пнёт тебя.

Плавали, знаем.

>  А начальник потом пинает тебя

может.
Но тогда уже есть официальная отмазка почему баг-репорты без ответа стоят или что план не продвинулся ни на пункт

> Слышал звон, не понял где он.
> если не это, то возможны другие ограничения.

> Как деревенские знахари, все познания по слухам собраны.
когда в поддержке (цто) исчерпываются знания/идеи, зовут меня, и я часто именно по слухам, типа "вроде что то похожее, может связано. надо проверить" нахожу проблему... после найденное систематизируется, записывают в "базу знаний" и... что поразительно, чуть позже полуграмотные цто-шники начинают меня же "попрекать" "че ты этого не знаешь, какие то слухи проверяешь"... ну вот прям как ты сейчас. наверное из тех кто мозги использует только для запоминания.

> И. Павел  (01.04.2011 08:47:00)  [0]

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

> sniknik ©   (01.04.11 13:09) [17]
> если не это, то возможны другие ограничения.

Вот тоже характерная черта: читать не то, что написано. Я ведь не сказал, что ограничений нет.


> когда в поддержке (цто) исчерпываются знания/идеи, зовут меня

Я и говорю: типично знахарское сознание. "Когда медицина бессильна, идут ко мне".
Точно такая же паралогика: если пришли, значит кончились знания, значит они полуграмотные. Тот факт, что "полуграмотные" врачи-убийцы решают сотню проблем в день, а к знахарям приходят раз в месяц, из картины мира выпадает.

Кончают знахари одинаково: ошибка в диагнозе "по чутью", с ориентацией на внешние признаки и смутные ассоциации вместо системных знаний, и -- exitus letalis.
Для знахарей есть вероятность уголовной ответственности.
А технический псевдоспец просто вычеркнет эпизод из памяти и продолжит знахарствовать дальше.

> Вот тоже характерная черта: читать не то, что написано.
именно... у меня ведь написано, что "раз есть это то возможны и другие ограничения". но бревно в своем глазу не так заметно как щепка в чужом, естественно.

пусть автор разберется - там просто сетевые проблемы очевидно есть, а не с БД.

у нас у одного из заказчика трудоустроили одного айтишника по безопасности - наша БД иногда просто лежит.

говорят, что уволили его, опять же по слухам "ваша система стала значительно лучше работать!".

надо изучить вопрос сетевого взаимодействия.

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

> sniknik ©   (01.04.11 15:14) [22]
> кстати еще один "слух" - количество полуоткрытых соединений

Вот в том-то и дело, что это не еще один "слух", а тот же самый слух: ограничение в 10 полуоткрытых исходящих(!) соединений.

На входящие и на полное количество установленных соединений специальных ограничений нет.

---------

Знахарство -- это обрывки (часто искажённые) сведений, фрагментарное мышление, паралогика и ЧСВ over_9000.

> Вот в том-то и дело, что это не еще один "слух", а тот же
> самый слух: ограничение в 10 полуоткрытых исходящих(!) соединений.
>


скажите мне незнающему - о чем речь?

а. Что такое полуоткрытые?
б. Где написан про ограничение на 10 исходящих соединений?

> Дмитрий Тимохов  (01.04.2011 15:41:24)  [24]

Не исходящих, а входящих и не любых, а только не анонимных

Удалено модератором

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

> Anatoly Podgoretsky ©   (01.04.11 16:03) [26]

Онотоле, вы думаете, что наш знахарь настолько запущен?!


> Дмитрий Тимохов  (01.04.2011 15:41:24)  [24]

Теперь я могу восстановить тот извилистый путь, которым шла знахарская мысль.

Знахарь где-то слышал (но сам не видел), что в воркстэйшн-версиях виндос есть какое-то ограничение. Даже магическая цифра 10 в память запала.
Знахарь где-то слышал (или даже видел), что торренты тормозят.
Знахарь где-то слышал (но не помнит, видел ли), что торренты тормозят тоже из-за какого-то ограничения, и вроде бы, там тоже была какая-то цифра (возможно даже, что 10).
Тут сработал знахарский механизм pattern-matching'а: "тормозит", "ограничение", "10", "виндос".
У знахаря готов диагноз!
Потом знахаря щёлкают по носу. Знахарь, конечно, не опускается до такой мелочи, как выяснить, в чем, собственно, содержательные претензии к его диагнозу. Знахарь наскоро отбрёхивается со всей высоты своего ЧСВ, но зерно сомнения уже заронено.
Знахарь глубже копается в той куче огрызков, что называется "Мой Опыт" (а может даже тайком гуглит! тс-с...), и начинает понимать (точнее, догадываться, знахарь никогда ничего не понимает в том смысле, в каком это делают "полуобразованные"), что что-то тут не срастается.
И знахарь дезавуирует свой диагноз, подав его, с целью "сохранения лица", под соусом "кстати, ещё один".

> sniknik ©   (01.04.11 16:26) [28]
> в одном случае сервер, в другом клиент.

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


> ты бы хоть один выдал, такой всезнающий и непогрешимый.

О, "спервадобейся" детектед.

Диагностика по телефону и лечение по фотографии -- это эксклюзивно знахарские технологии. Зачем мне с тобой соревноваться?