Уважаемые форумчане,
столкнулся с такой проблемой: после покупки нового сервера (2*Quad Xeon 2.33GHz, 8Gb RAM, RAID 10 300Gb SAS HDD) и переноса баз на него, стал очень медленно формироваться отчет или запрос (я в 1С не разбираюсь, смысл его в заполнении цен для прайса, далее отчет). Фактически скорость упала в 8 раз. Раньше эта база была на другом сервере (2*Quad Xeon 3.0GHz, 4Gb RAM, RAID 5 200Gb SATA HDD). Скорость формирования была 3,3% в мин, сейчас 0,4% в мин. При этом на новом сервере, если запустить локально 25% в мин, на старом 23% в мин. Были проверены все счетчики на серверах (не более 2-3% CPU и HDD, сеть 0,05%), проверена производительность клиентов (3-7% CPU, сеть 0,05%). Не видно причин для таких тормозов. Менялось активное оборудование между клиентами и сервером, подключали клиента напрямую к серверу. Причем сетевые интерфейсы на 1Gbit. Понятно, что дело в сети, раз локально быстро работает, но где копать? В Интернете и на тематических сайтах ответов не нашел. Хоть что-то должно же тормозить формирование отчета!

Спасибо за предложения.
Все, что Вы предложили, было сделано.

1. Все активное сетевое оборудование (свитчи, роутеры и т.д.) менялось. Напрямую через кросс подсоединяли. SQL настроен на использвание 6Gb оперативки (AWE режим). Последние драйверы от HP поставлены (HP Proliant DL380G5). BIOS обновлен.
2. На счет кода 1С скажу, что дело не внем. Если он локально летает в монопольном режиме, он должен по сети либо летать, либо что-то его должно тормозить.

3. На счет сервера приложений. Зачем всех переводить на выделенный терминальный сервер, если такие тормоза через сеть? Я это и хотел сделать, но как увидел, что 1С тормозит, решил сначала разобраться в чем дело.

В чем вся проблема, что не видно признаков торможения НИГДЕ. Если сервер не справляется, тогда он и локально бы тормозил, если код кривой, то тоже локально бы тормозил.

DmitryOrlovУ наших клиентов было - админ поставил контролер домена, но клиентские компы ввел в домен не сразу. При том, что мы перенесли базы и сервер приложений (разговор про БЭСТ-5) на новый сервер, вроде все должно было работать быстрее. Однако скорость упала раз в 10. Я долго его уговаривал сделать нормально КОгда он сделал - ввел клиентские р.м. в домен, все стало нормально.

У нас все клиенты в домене, но удивительно конечно. Я знаком с БЕСТ-5, но там доступ к файлам. А здесь SQL, как могут политики безопасности влиять на SQL запросы. Он же не должен проверять права доступа, если коннект через sa?

Может еще какая-нибудь информация нужна?

Есть один любопытный факт. Есть одна клиентская машина (БыстрКлиентСервер_SQL3) у которой со Cтарым_Cервером_SQL осталась прежняя скорость обработки отчета. Но при попытке запустить этот отчет с Нового_Сервера_SQL, скорость падает в 8 раз. Причем поменять местами клиент и сервера, то скорость остается такой же маленькой. На Новом_Сервере_SQL настроили сетевую карту на подсеть этого "клиента". И скорость с Новым_Сервером_SQL вернулась к прежнему уровню. Опять при попытке поменять местами клиент и сервер, скорость падает.

Вот эта ситуация:
Старый_Сервер_SQL1 -- Новый_Сервер_SQL2
192.168.2.7 0,402%/мин 192.168.2.250

Новый_Сервер_SQL2 -- Старый_Сервер_SQL1
192.168.2.250 0,418%/мин 192.168.2.7

БыстрКлиентСервер_SQL3 -- Новый_Сервер_SQL2
192.168.2.252 3,3%/мин 192.168.2.250

БыстрКлиент_Сервер_SQL3 -- Старый_Сервер_SQL1
192.168.2.252 3,3%/мин 192.168.2.7

Старый_Сервер_SQL1 -- БыстрКлиентСервер_SQL3
192.168.2.7 0,41%/мин 192.168.2.252

Новый_Сервер_SQL2 -- БыстрКлиентСервер_SQL3
192.168.2.250 0,390%/мин 192.168.2.252

Старый_Сервер_SQL1 -- Новый_Сервер_SQL2
10.1.1.33 0,440%/мин 10.1.1.34

Новый_Сервер_SQL2 -- Старый_Сервер_SQL1
10.1.1.34 0,424%/мин 10.1.1.33

БыстрКлиентСервер_SQL3 -- Новый_Сервер_SQL2
192.168.2.252 0,432%/мин 10.1.1.34

БыстрКлиент_Сервер_SQL3 -- Старый_Сервер_SQL1
192.168.2.252 0,4%/мин 10.1.1.33

ВсеОстальные -- Новый_Сервер_SQL2
10.1.1.x 0,4%/мин 10.1.1.34
192.168.2.x 0,4%/мин 192.168.2.250

ВсеОстальные -- Старый_Сервер_SQL2
10.1.1.x 0,4%/мин 10.1.1.33
192.168.2.x 0,4%/мин 192.168.2.7




Из этого я сделал вывод, что на скорость в данном случае не влияют:
1. сетевое активное оборудование
2. база 1С
3. настройка конфигурации 1С
4. подсеть сервера и клиента (кроме единичного случая)
5. железо сервера
6. железо клиента
Вообще не вижу закономерности. Такое чуство, что заточена под конкретный ПК для конкретной сети. Клиентские настройки для БыстрКлиентСервер_SQL3 и Старый_Сервер_SQL2 устанавливал не я.

Shuhardпохожие симптомы бывают при:
- поднятой трассировки ODBC на клиенте
- работе с сиквелом через Named Pipes вместо TCP/IP
диагностика на стороне сиквела - EM(Named Pipes vs TCP/IP), профайлером и планом запросов в QA

P.S. есть много способов "испортить" сиквел при установке по умолчанию, подробности в
http://sql.ru/forum/actualtopics.aspx?bid=1

1. трассировка на клиентах отключена, еслы Вы имеете в виду это - "Параметры трассировки-Пуск трассировки"
2. проверена работа через Named Pipes и через TCP/IP. Результат одинаковый.
3. На стороне SQL ставились и Named Pipes и TCP/IP. Тоже ничего не меняется.

Если посмотреть результаты тестирования выше, то трудно сказать, что это проблемы именно сервера, тогда бы все с ним одинакого работали. Я могу выложить сюда запрос на формирование отчета, но как бы криво он не был бы написан, должно хоть что-то нагружаться.
Хочу на следующей неделе протестировать эту связку в рабочей группе, мало вероятно, но может как-то политики АД влияют. Ума не приложу. В Интернете встретил всего пару вопросов, с такой ситуацией как у меня, но ответов на них не было. Обычно у всех что-нибудь тормозит.

Shuhardмы верно понимаем, один и тот-же запрос запущенный из QA с разными сиквелами работает с одинаковой скоростью, а тот-же запрос из к примеру Access через ODBC работает с существенно разными скоростями?


Запросы из QA не делал и в Access тоже. Я не знаю, какими запросами можно проверить работу SQL-сервера. Пинги везде в норме, нигде нет задержек даже на 1мс. Роутер на базе WS2k3 RRAS. Свитчи compex, d-link, asus.
Ситуация больше смахивает на полтергейст. От любых перестановок, результат не меняется. Вообще такого не бывает. Может у кого были такие странные проблемы с 1С. Может она криво работать по сети из-за какой-нибудь библиотеки или SP?

Вчера на VMware-server установил WS2k3 EE SP1 + SQL2000 SP3 и клиент Windows XP SP2. На все машины поставил VMware Tools.
Соединил их в режиме host-only. Как я понимаю, в данном случае активное сетевое оборудование роли не играет. Вот результаты тестирования:
WS2k3 EE SP1 + SQL2000 SP3 -- Windows XP SP2 (TCP/IP)
10.1.1.20 0.4% 10.1.1.29

WS2k3 EE SP1 + SQL2000 SP3 -- Windows XP SP2 (Именованные каналы)
10.1.1.20 0.4% 10.1.1.29

WS2k3 EE SP1 + SQL2000 SP4 -- Windows XP SP2 (TCP/IP)
10.1.1.20 0.4% 10.1.1.29

WS2k3 EE SP2 + SQL2000 SP3 -- Windows XP SP2 (TCP/IP)
10.1.1.20 0.4% 10.1.1.29

WS2k3 EE SP2 + SQL2000 SP4 -- Windows XP SP2 (TCP/IP)
10.1.1.20 0.4% 10.1.1.29

Загрузка во всех вариантах: диска < 10%, процессора < 10% и сети (1Гбит) < 0.1 %

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

ProvodПривет ! я короче не мега спец но думаю что копать надо Nimed Pipes и вот почему нам на курсах преподаватель рассказывала (не смотрите что женщина она мега спец) так вот рассказывала что однажды в настройках сервера поменяли порядок протоколов тоесть указали что NimedPipes не первый по списку и производительность упала на 30%.А че за RAID сколько дисков и сколько кеш на контроллере ?

Спасибо, я пробовал отключать Nimed Pipes, но это ровным счетом ничего неменяет.
RAID 10 на HP Smart Array P400 512Mb cache.
Независимо от железных и сетевых настроек, результат одинаковый. Очень похоже на принудительную задержку или в каких-то ограничениях в софте.

LunxЯ из всего перечисленного не понял следующее
1) Сколько времени формируется отчет в монопльном режиме с консоли (дайте в сек).
2) Сколько в разделенном с консоли, с сервера приложений (или с произвольной машины). дайте в сек

На новом сервере HP отчет занимает - 278 сек. (Loopback - 6.5 млн байт/сек)
На виртуальной машине с 1 проц. P4 3.0 GHz - 603 сек (Loopback - 3.5 млн. байт/сек)
На любом клиенте около 13200 сек (точно не замерял где-то 3 часа 40 мин)

Lunx Gfer LunxЯ из всего перечисленного не понял следующее
1) Сколько времени формируется отчет в монопльном режиме с консоли (дайте в сек).
2) Сколько в разделенном с консоли, с сервера приложений (или с произвольной машины). дайте в сек

На новом сервере HP отчет занимает - 278 сек. (Loopback - 6.5 млн байт/сек)
На виртуальной машине с 1 проц. P4 3.0 GHz - 603 сек (Loopback - 3.5 млн. байт/сек)
На любом клиенте около 13200 сек (точно не замерял где-то 3 часа 40 мин)
И после этого Вы не знаете что делать и в чем причина ? Ответ - проблема в связке клиент-сервер. Если пользователей не много - установите сервер терминалов на SQL сервер. Если же их много - делайте сервер(а) терминалов на application server. Его по гигабитному каналу вяжите (желательно циской чтобы только с ним) с SQL сервером. Про виртуальную машину я не понимаю - дайте знать, если это важно - стану разбираться. 1С устроена совершенно тупо - тянет данные прямо на клиент, там их обрабатывает, потом если надо тащит результат на сервер - то есть клиент - толстый. Поэтому результат обработки на клиенте станет зависеть от железяк клиента.
В том-то и дело, что терминальный сервер бесполезно соединять с SQL-сервером. Это и планировалось сделать в самом начале. Но как только 1С начинает работать через сеть, скорость падает до фиксированного уровня, который был показан выше.
На виртуальных машинах была проверена связка без всяких посторонних устройств. Установлены чистые системы, в домен не заводились и работали только через виртуальное соединение.
Все это больше смахивает на какую-то тонкую настройку взаимодействия 1С и сетевого интерфейса. Через loopback проходит 3.5 млн. байт/сек, а через сетевую карту нет. Вроде одно и тоже, а какой-то нюанс есть.