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

героев мало. проще отп...дить чувака :-)

TopSpaceно памяти должно хватать
ну вот опять. к чему эти предположения, которые основываются просто на том, что "20 гиг - это вроде много памяти" ?

у вас же сервер работает. значит ему памяти или хватает, или не хватает.
TopSpaceclassic менее предпочтительна, чем super-server?
еще одно совершенно дикое предположение. "Менее предпочтителен" почему?

TopSpaceраз ее хватает, то видимо, выбор нормальный.
а ее хватает? допустим, если размер одного процесса классика 150 мегабайт, то 200 процессов потребуют 30 гиг памяти. А у вас там 20 гиг. 20 гиг хватит только на 130 процессов по 150 мб. Остальное поедет в виртуальную память, и если все эти 200 коннектов действительно загружены работой, то ОС и будет "заикаться" с таймаутами на коннект.

TopSpaceобщих рекомендаций я не смог найти.
с этим наверняка к автору .Net драйвера.

TopSpaceА от чего зависит размер процесса на классике?
от много чего, админу нужно смотреть сколько на сервере реально эти процессы занимают.

TopSpaceСнизится скорость, от этого не должен ведь падать клиент, и тем более сервер.
блин. ну например - дофига процессов, память занята. Клиент говорит серверу - открой мне еще коннект. Сервер пытается запустить еще процесс, выкидывает что-то в виртуал, и т.д., это происходит медленно, и клиент получает отлуп по таймауту.

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

TopSpaceИ еще наверно sql-кэш раздувает, или он на диске хранится?
я извиняюсь, вы меня утомили подобными вопросами, они очень примитивные :-)
sql-кэша в ФБ нет, есть кэш БД, он в памяти процесса. Купите книжку Хелен Борри по ФБ 1.5, что-ли.

TopSpaceЕсли бы сегодня не был последний день на реализацию этой задачи (из области, в которой я никогда не работал, а главное - и не собираюсь в будущем)
ну и нафиг тогда. в любом случае, тут авторов драйвера .Net нет. А консультировать не-админа сервера по ФБ не вижу смысла. Тем более, что такие вещи обычно делаются за деньги.

miwaonlineВот как явно провокационную ложь назвать явно провокационной ложью
не совсем ложь. Ожидание на чтении может возникнуть в транзакции с параметрами
wait read_committed no_rec_version
если в других транзакциях читаемые данные вставлены, обновлены, или удалены.
Так что, такая ситуация возможна, если Иржи до сих пор не поменял умолчательный ReadCommitted. Еще в Люксембурге в 2012 году я с ним на эту тему поругался. Его ответ был - "кому надо, пусть указывают свои параметры транзакции".

Про это я уже писал в этом топике. Какие параметры ReadCommitted по умолчанию сейчас стоят в свежем .Net драйвере, и как эти параметры менять - мне неинтересно. Что мог, я уже сделал.

Мимопроходящий,

скорее всего это описка. потому что я не знаю СУБД, в которых блокируется конкурирующее чтение. Но если он в такое верит, то да, "ну цЭ вжЭ вобшЭ!".