none
Проблемы с производительностью Windows 2008R2 + MS SQL 2008 + 1С:Предприятие 8.1, неужели придется возвращаться к 2003R2 + MS SQL 2005?

    Общие обсуждения

  • Всем Доброго Времени Суток!

    Столкнулись с такой проблемой. Прошлым летом купили новый сервер, купили и установили на него Win2008R2 EE + MSSQL2008 + 1С:Предприятие 8.1. Поначалу были проблемы с дисковыми контроллерами, но это всё устаканилось, где-то в середине осени ввели его в эксплуатацию. По началу были проблемы с новой конфигурацией 1С, но их тоже решили. По мере решения со стороны 1С начали появлятся заявления, что производительность нашего сервера несоответствует его аппаратным возможностям. Заказали тестирование на однотипном "железе". Оно выявило:

    а. Производительность связки Win2008R2 EE + MSSQL2008 + 1С:Предприятие 8.1 медленнее Win2003R2 EE + MSSQL2005 + 1С:Предприятие 8.1 в 1.6-2 раза!
    б. Никаких серьёзных нареканий к работе ПО и "железа" не выявлено.

    Тестирование производилось на сервере следующей конфигурации:

    Описание:--:Количество

    Motherboard X8DTL-iF, 2*CPU 55xx, up to QPI 6.4 GT/s, 6*DIMM DDR3(48Gb ECC reg or 24Gb ECC), 1(x8in16),2(x4in8) PCI:--:1

    E 2.0, 1(x4) PCI-E 1.0, 2xPCI33, ICH10R, IPMI, VGA, w/o IDE, ATX

    Coolers For CPU Intel® STS100C, Active / 2U+Passive CPU Heatsink LGA1366 X8 MB, Up to 130W, Fan 4pin PWMI:--:2

    CPU CPU Intel Xeon E5504 2000/4.8GT/4M, LGA1366, 80W (BX80602E5504)I:--:2

    Memory 4GB 1333MHz DDR3 ECC Reg w/Parity DIMM Dual Rank, x4 w/Thermal SensorI:--:6

    SAS RAID Adaptec RAID 5805, 8 internal ch. SAS/SATA, 2xI-Pass(SFF 8087), 512MB on Board, PCI-Ex8, RAIDI:--:1

    BBU Adaptec ABM-800, BBU for Adaptec 3xxx, 5xxx seriesI:--:1

    HDD SAS Hitachi UltraStar 15K300, 147GB, 15000rpm, SAS, cache 16MB (HUS153014VLS300, p/n 0B22131)I:--:4 (использовался RAID 10)

    Cable CBL-0097, I-Pass(SFF 8087) - 4xSATA, 50cm, SAS cableI:--:2

    Supermicro Case CSE-745TQ-800, 8x1" SAS/SATA bays, 3x5.25", 3hot-swap fans, 2hot-swap rear fans, 2x USB Ports, 800WI:--:1

    PWS (PWS-801-1R)

    Результаты теста:
     

    Описание

    Время

    1 запуска

    Время

    2 запуска

    0

    Сервер заказчика

    6:00

    4:50

    1

    Win2003 (32bit) + SQL 2005

    3:30

    2:30

    2

    Win2003 (32bit) + SQL 2005 + оптимизации

    3:30

    2:30

    3

    Win2008R2 + SQL 2008 + 1C x64

    5:30

    4:30

    4

    Win2008R2 + SQL 2008 + 1C x86

    5:30

    4:30

    5

    Win2008R2 + SQL 2005 + 1C x64

    5:20

    4:15

    6

    Win2008R2 + SQL 2005 + 1C x86

    5:20

    4:15

    7

    Win2003 (32bit) + SQL 2005

    3:15

    2:20



    Со стороны 1С мне прокомментировали, что кроме нас есть ещё несколько клиентов у которых 2008R2 и такие же проблемы с производительностью, но 1С не видит претензий к своему продукту.

    Подскажите пожалуйста, что может быть не так или единственный выход перейти на Win2k3? Очень хотелось бы оставить 2008R2, т.к. планировали часть ресурсов выделить в виртуальную машину(ы)...

    24 февраля 2010 г. 12:22

Все ответы

  • Сервер 1С:Предприятий на этой же машине?
    24 февраля 2010 г. 12:26
  • да, весь тест проходил на одной машине, чтоб исключить влияние сети. SQLю запрешено использование двух ядер, чтоб для предприятия были свободные ресурсы. По датчикам ни процессоры ни дисковая система не испытывают нагрузки более 3-5%. Все базы кроме тестируемой переводились в offline. Так же тест проводился на ноутбуке DELL XPS M1730 + XP + 2005DE результат первый прогон около 4мин. второй 2:40.
    24 февраля 2010 г. 12:42
  • 1С сама рекомендует разворачивать сервер 1С:Предприятий и SQL-сервер на разных машинах. Попробуйте, может поможет.
    24 февраля 2010 г. 12:52
  • К данному вопросу это отношение не имеет, т.к. из теста в одинаковых условиях Win2k3 получается в выигрыше до двух раз! А такой фактор уже нельзя игнорировать. Что касается разнесения на разные сервера. Из собственного опыта и опыта коллег максимальная производительность достигается как раз таки при работе всех компонент на одном сервере, если ресурсов сервера достаточно. Что касается данного случая, то подобный эксперемент производился и производительность при разносе 1С:Предприятия и SQL падает ещё где-то в 1,5 - 2 раза.
    24 февраля 2010 г. 13:01
  • Со стороны 1С мне прокомментировали, что кроме нас есть ещё несколько клиентов у которых 2008R2 и такие же проблемы с производительностью, но 1С не видит претензий к своему продукту.

    Подскажите пожалуйста, что может быть не так или единственный выход перейти на Win2k3? Очень хотелось бы оставить 2008R2, т.к. планировали часть ресурсов выделить в виртуальную машину(ы)...
    а через Process Monitor никто не пробовал посмотреть - чем именно занимается продукт 1C при таком долгом запуске как на 2003, так и на 2008? с большой вероятностью это даст верное направление в поисках виновного...
    24 февраля 2010 г. 17:18
  • У нас специалисты смотрели через специальный продукт 1С, называется ЦУП, по нему большая часть времени полное затишье, иногда проскакивают блокировки и взаимоблокировки, но это отдельный вопрос (и замечу блокировок во время теста не наблюдалось). Меня в данном посте интересует в чем может быть причина разницы выполнения одного и того же теста на одном и том же "железе" с единственной разницей в установленной ОС и речь не идет о нескольких процентах! Речь о разнице в 1,6-2 раза!!! И к 1С я претензий как и они сами не вижу, ведь на других "старых" ОС Microsoft тест выполняется значительно быстрее, т.е. вопрос или в настройке Win2008R2 или в самой её архитектуре или каких-то "багах". Причем тест легко повторился у стороннего тестера.
    Думаю если кто-нибудь из читающих этот пост попробует сравнить скорость выполнения некого произвольного набора действий 1С (например проведение одной и той же последовательности документов, загрузка/выгрузка в xml и т.п.) то, имхо, получит схожие результаты. Мы в своём тесте грузили xml-файл размером 2,6 Мб. Причем результаты теста для 2008R2 абсолютно не зависели от того где находится файл и база. Мы сравнивали базу находящуюся на RAID массиве или на одиночном диске подключеном через USB! и файл как расположенный в сети, так и на этих же дисках самого сервера -- разницы по скорости никакой, нагрузка на ресурсы сервера практически нулевая.
    24 февраля 2010 г. 21:43
  • У нас специалисты смотрели через специальный продукт 1С, называется ЦУП, по нему большая часть времени полное затишье, иногда проскакивают блокировки и взаимоблокировки, но это отдельный вопрос (и замечу блокировок во время теста не наблюдалось). Меня в данном посте интересует в чем может быть причина разницы выполнения одного и того же теста на одном и том же "железе" с единственной разницей в установленной ОС и речь не идет о нескольких процентах!
    Коллеги, простите за вольность, но к чёрту ЦУП... посмотрите чем занимается 1С на уровне ОС и именно со стороны ОС... запишите запуск и на 2003 и на 2008 - потратьте 3-4 часа на сравнение, но поймите - ЧЕМ занимается приложение в процессе запуска со стороны ОС... что происходит в системе за эти 2 минуты, что приложение молчит и чего-то ждёт... это может быть драйвер, связанный с защитой приложения, это могут быть попытки достучаться до сервера лицензий... это может быть что угодно - скажет вам Process Monitor...
    25 февраля 2010 г. 5:12
  • это может быть что угодно - скажет вам Process Monitor...

    Имеете ввиду http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx ??? Что-то он у меня постоянно выпадает под R2...
    25 февраля 2010 г. 10:25
  • Имеете ввиду http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx ??? Что-то он у меня постоянно выпадает под R2...
    именно его - каким образом "выпадает"? запускаете как администратор? какие-то ошибки выдаёт?
    25 февраля 2010 г. 12:26
  • ну периодически закрывается не сообщая в чем дело, но мне удалось выцепить, что почему-то 1С на 2008R2 постоянно обращается к серверу предприятия через tcp, чего не наблюдается под 2003:

    15:42:17,4581390 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 34, seqnum: 0, connid: 0
    15:42:17,4592813 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 485, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4607915 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 618, seqnum: 0, connid: 0
    15:42:17,4612642 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 98, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4615399 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 34, seqnum: 0, connid: 0
    15:42:17,4622222 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 150, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4625636 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 134, seqnum: 0, connid: 0
    15:42:17,4628689 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 149, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4630824 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 225, seqnum: 0, connid: 0
    15:42:17,4633488 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 98, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4636188 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 34, seqnum: 0, connid: 0
    15:42:17,4757319 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 2429, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4859574 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 259, seqnum: 0, connid: 0
    15:42:17,4866382 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 98, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4867446 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 34, seqnum: 0, connid: 0
    15:42:17,4869516 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 149, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4871336 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 130, seqnum: 0, connid: 0
    15:42:17,4875375 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 149, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4876934 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 130, seqnum: 0, connid: 0
    15:42:17,4879096 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 161, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4880367 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 49, seqnum: 0, connid: 0
    15:42:17,4882667 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 97, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4883638 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 84, seqnum: 0, connid: 0
    15:42:17,4885366 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 149, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4887006 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 229, seqnum: 0, connid: 0
    15:42:17,4889725 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 149, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4891606 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 229, seqnum: 0, connid: 0
    15:42:17,4894816 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 236, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4896325 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 49, seqnum: 0, connid: 0
    15:42:17,4898287 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 161, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4899528 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 49, seqnum: 0, connid: 0
    15:42:17,4901517 1cv8.exe 7416 TCP Send ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 161, startime: 53913, endtime: 53913, seqnum: 0, connid: 0
    15:42:17,4902742 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 49, seqnum: 0, connid: 0
    25 февраля 2010 г. 12:46
  • ну периодически закрывается не сообщая в чем дело, но мне удалось выцепить, что почему-то 1С на 2008R2 постоянно обращается к серверу предприятия через tcp, чего не наблюдается под 2003:
    15:42:17,4581390 1cv8.exe 7416 TCP Receive ServerR2.none.local:50614 -> ServerR2.none.local:1570 SUCCESS Length: 34, seqnum: 0, connid: 0
    ну вот именно про это я и говорил
    кстати, а пробовали службу Windows Firewall для тестов остановить?
    25 февраля 2010 г. 13:20
  • да, пробовали, если просто выключить firewall в его оснастке, то разницы на производительности никакой, а если полностью остановить службу (через администрирование/службы) то сервер перестаёт пускать входящие соединения, хотя сам сеть видит, почему так я сразу скажу не разбирался и в этом режиме эксперимент не ставил.
    25 февраля 2010 г. 13:27
  • а вот чем занимается rphost:

    17:01:35,5090160 rphost.exe 3268 TCP Receive ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 140, seqnum: 0, connid: 0
    17:01:35,5104271 rphost.exe 3268 TCP Send ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 324, startime: 101493, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5104455 rphost.exe 3268 TCP Receive ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 246, seqnum: 0, connid: 0
    17:01:35,5112853 rphost.exe 3268 TCP Send ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 367, startime: 101493, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5114443 rphost.exe 3268 TCP Receive ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 150, seqnum: 0, connid: 0
    17:01:35,5136126 rphost.exe 3268 TCP Send ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 334, startime: 101493, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5136280 rphost.exe 3268 TCP Receive ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 246, seqnum: 0, connid: 0
    17:01:35,5144785 rphost.exe 3268 TCP Send ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 367, startime: 101493, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5146122 rphost.exe 3268 TCP Receive ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 138, seqnum: 0, connid: 0
    17:01:35,5162303 rphost.exe 3268 TCP Send ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 322, startime: 101493, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5162418 rphost.exe 3268 TCP Receive ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 246, seqnum: 0, connid: 0
    17:01:35,5169917 rphost.exe 3268 TCP Send ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 367, startime: 101493, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5171449 rphost.exe 3268 TCP Receive ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 142, seqnum: 0, connid: 0
    17:01:35,5185438 rphost.exe 3268 TCP Send ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 326, startime: 101493, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5185557 rphost.exe 3268 TCP Receive ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 246, seqnum: 0, connid: 0
    17:01:35,5192710 rphost.exe 3268 TCP Send ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 367, startime: 101493, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5193747 rphost.exe 3268 TCP Receive ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 150, seqnum: 0, connid: 0
    17:01:35,5260852 rphost.exe 3268 TCP Send ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 334, startime: 101493, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5260967 rphost.exe 3268 TCP Receive ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 246, seqnum: 0, connid: 0
    17:01:35,5272291 rphost.exe 3268 TCP Send ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 367, startime: 101493, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5273243 rphost.exe 3268 TCP Receive ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 142, seqnum: 0, connid: 0
    17:01:35,5287193 rphost.exe 3268 TCP Send ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 326, startime: 101493, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5287297 rphost.exe 3268 TCP Receive ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 246, seqnum: 0, connid: 0
    17:01:35,5295449 rphost.exe 3268 TCP Send ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 367, startime: 101493, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5296682 rphost.exe 3268 TCP Receive ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 132, seqnum: 0, connid: 0
    17:01:35,5309910 rphost.exe 2824 TCP Send ServerR2.none.local:1580 -> server.none.local:3185 SUCCESS Length: 39, startime: 101491, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5347563 rphost.exe 3268 TCP Send ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 316, startime: 101493, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5347701 rphost.exe 3268 TCP Receive ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 246, seqnum: 0, connid: 0
    17:01:35,5358526 rphost.exe 3268 TCP Send ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 367, startime: 101493, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5359824 rphost.exe 3268 TCP Receive ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 138, seqnum: 0, connid: 0
    17:01:35,5375897 rphost.exe 3268 TCP Send ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 322, startime: 101493, endtime: 101493, seqnum: 0, connid: 0
    17:01:35,5376005 rphost.exe 3268 TCP Receive ServerR2.none.local:1663 -> server.none.local:1464 SUCCESS Length: 246, seqnum: 0, connid: 0
    17:01:35,5385270 rphost.exe 3268 TCP Send ServerR2.none.local:50881 -> ServerR2.none.local:ms-sql-s SUCCESS Length: 367, startime: 101493, endtime: 101493, seqnum: 0, connid: 0


    Как я понимаю, он с sql общается так же через tcp, хотя в диспетчере конфигурации sql в разделе клиентские протоколы: общая память включена и приоритет у неё 1. Получается memory sharing не работает :( ?
    25 февраля 2010 г. 14:07
  • Кажется с этими обменами по сети немного прояснилось, как сообщают представители 1С это нормальная ситуация и то же самое имеет место в любой 1С на любой платформе (типа мемори шаринг они не используют). А под 2003им у меня не показывает вообще обращений к SQL серверу, даже если он находится на другой машине, что вызывает подозрение в правильности мониторинга.

    Откуда:

    а. Вопрос потери произодительности под R2 получается так и не решен, во что она упирается мне не понятно. Кто-нибудь сталкивался с подобной проблемой (в 1С мне сказали, что кто-то так же на подобное жаловался, но все видимо перешли на 2003 и успокоились).

    б. Почему у меня не показывает под 2003 обмен с сервером SQL в Process Monitor'е?

    1 марта 2010 г. 12:04
  • Может быть хотя бы кто-нибудь из использующих 1С:Предприятие 8.х может с уверенностью сказать, что производительность на платформе 2008R2 у него примерно такая же или лучше чем под Win2k3?
    3 марта 2010 г. 6:48
  • Появились первые сдвиги :)

    1. Оказалось если из сервера убрать пользовательский ключ 1С и выключить сервис HASP License Manager, то время нашего теста под R2 сразу достигло 3:40 при втором замере! Что уже сокращает разницу с 2003 значительно.

    2. Попробовали тот же тест под 8.2 (тоже HASP уже выключен) результат был 2:31, что дает нам альтернативу вместо перехода на 2003 обновиться до 8.2, только список багов этой платформы пока удручает.

    Господа-товарищи у кого-нибудь есть ещё идеи?

    5 марта 2010 г. 14:30
  • 1. Оказалось если из сервера убрать пользовательский ключ 1С и выключить сервис HASP License Manager, то время нашего теста под R2 сразу достигло 3:40 при втором замере! Что уже сокращает разницу с 2003 значительно.

    2. Попробовали тот же тест под 8.2 (тоже HASP уже выключен) результат был 2:31, что дает нам альтернативу вместо перехода на 2003 обновиться до 8.2, только список багов этой платформы пока удручает.

    Господа-товарищи у кого-нибудь есть ещё идеи?
    А какие идеи? обратиться к разработчикам HASP - через 1С или напрямую...
    5 марта 2010 г. 16:48
  • Не hasp мы уже отключили он нам больше не интересен, даже все вирт машины выключили. Всё это позволило обогнать тестовую машину под 2008R2, но мы не достигли времени под 2003 (если использовать 8.1). Т.е. 2008R2 всё ещё значительно медленнее 2003го.

    Вопрос идей, что ещё может cъедать больше минуты под 2008R2.

    PS: 1Сники так же на своём форуме пытаются выяснить, что может тормозить процесс...
    7 марта 2010 г. 13:08
  • Как вариант можно на клиентах в ini файле (точное название не помню, 1с-ники сами правили его)  прописать IP машины на которой стоит License Manager и HASP . У меня была аналогичная проблема с долгим поиском ключа HASP в сети.  


    MCP,MCTS
    9 марта 2010 г. 7:29
  • Файл называется nethasp.ini и находится в каталоге с установленными бинарниками 1С 8.1. Рекомендую в этом файле отключить все протоколы кроме TCPIP (секция файла [NH_TCPIP]). Если у вас в сети действительно имеются проблемы с DNS, NetBIOS и т.д., то для параметра NH_SERVER_ADDR вместо имени лучше использовать IP адрес сервера на котором установлен ключ HASP, в таком случае это может несколько сократить время запуска 1С.
    9 марта 2010 г. 9:06
  • Спасибо за совет, но проверил, на время теста это не влияет. Как я понимаю, 1С находит ключ в момент запуска и дальше во время работы уже "знает" где он, поэтому на тест это не влияет. Так что думаю копать в сторону ключа дальше бесполезно это что-то другое. Ктому же под 2003 никто также как и под 2008 файл nethasp.ini не менял, т.е. по данному параметру они в одинаковых условиях.
    10 марта 2010 г. 7:59
  • Кстати признаюсь, что танцы с бубном вокруг файла nethasp.ini всё-таки улучшили результат. Время выполнения теста сократилось с 3:40 до 3:20 - 3:30. Думаю это произошло из-за того что я разместил подправленный файл ещё и на терминальном сервере, что уменьшило нагрузку на сеть + я добавл в него следующие параметры:

    .....

    NH_SESSION = 600
    NH_SEND_RCV = 600

    .....

    NH_USE_BROADCAST = Disabled

    .....

    Так что огормное спасибо Медведовскому Алексею и Максимову Алексею за дельную мысль.

    PS: Но наш 2008R2 всё ещё проигрывает минуту связке 2003 + SQL 2005, а это 42% потери производительности, а если учесть что под 2008R2 на нашей машине мы уже получаем результат лучше чем на тестовой более чем на минуту, то есть вероятность, что процент потери производительности ещё больше! Так что продолжаю ждать ценных идей....

    Кстати где вы, те у кого под 2008R2 производительность 8.1 хотя бы такая же как под 2003? Или все перешли на 8.2??? Или никто не использует 2008R2??? В ветке отзывов о платформе я видел людей кто доволен. Аууу... поделитесь опытом плизззз...
    11 марта 2010 г. 8:25
  • Вы используете возможность RemoteApp терминального сервера win2008R2? Думаю логичней будет его использовать для запуска 1с у пользователей.


    >Как я понимаю, он с sql общается так же через tcp, хотя в диспетчере конфигурации sql в разделе >клиентские протоколы: общая память включена и приоритет у неё 1. Получается memory sharing не > работает :( ?


    Если запускать в терминальном режиме 1с то на стороне сервера нужно запустить cliconfg и там включить крыжик memory sharing. Тогда точно скорость увеличится вразы. 

    MCP,MCTS
    11 марта 2010 г. 11:13
  • Мы очень хотим использовать RemoteApp для 1С, но к сожалению у нас пока что какие-то проблемы с драйверами принтеров hp - операторы жалуются на медленную печать может быть это схожая проблема, кстати? + в режиме RemoteApp при табуляции соскакивает фокус с сеанса (пробовали под XP SP3) причем не всегда иногда можно долго работать, но нашим операторам соответственно это не подходит, поэтому пока что терминал под win2k3
    11 марта 2010 г. 11:24
  • на самом деле на сервере терминалов не нужно ставить никаких драйверов для принтеров. У 2008\2008r2 есть отличный инструмент TSEasyPrint он пробрасывает локальные принтера клиентов в терминальный сеанс. У меня задержка печати секунды 2-3 после отправки на печать. При условии если net framework 3.5 sp1 установлен на клиентах.  При соскакивание фокуса ничего не могу сказать не сталкивался, проблем таких небыло.


    MCP,MCTS
    11 марта 2010 г. 11:30
  • Хорошо, такой вариант обязательно попробую, спасибо за совет!

    11 марта 2010 г. 11:37
  • ....

    Если запускать в терминальном режиме 1с то на стороне сервера нужно запустить cliconfg и там включить крыжик memory sharing. Тогда точно скорость увеличится вразы. 

    MCP,MCTS
    Как я понимаю это для случая, если сервер предприятия находится отдельно от SQL? В нашем случае все компоненты находятся на ServerR2. Но я поставил галочку и перетянул именованные каналы в правую таблицу, пока что ничего не изменилось... нужна ли перезагрузка или всё-таки в нашем случае это не работает?
    11 марта 2010 г. 13:17
  • это очень хорошо что все на одном сервере.. после запуска нужно перетащить в правую сторону TCP IP и внизу поставить крыжик "Разрешить протокол общей памяти" (это по русски) на английском не помню как звучит если это не локализованный сервер и SQL.

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


    MCP,MCTS
    11 марта 2010 г. 13:46
  • да, я поставил крыжик и перетащил вправо: 

    именованные каналы
    TCP IP

    ничего не изменилось, нужна ли перезагрузка сервера?
    11 марта 2010 г. 14:01
  • Если честно не помню :( Но одно помню точно этот крыжик у меня заработал нормально когда я в SQL поставил динамическое выделение памяти (AWE) и перезапустил службу SQL. Но думаю ребут сервера если возможет в производственной среде, то можно и перезагрузить. 
    MCP,MCTS
    11 марта 2010 г. 14:09
  • AWE под 64 битной средой насколько я знаю не работает, для самого сервера в его диспетчере конфигурации, как я писал, всё уже включено, так что думаю сама перезагрузка SQL тут ничего не решает связка 1С + SQL работает и без клиента SQL -- я его добавлял отдельно, когда смотрел что получится если вынести сервер 1С:Предприятия на отдельную машину.

    Сейчас я поставил галку AWE она свободно ставится, а ночью перезагружу сервер, проверю что получится...

    11 марта 2010 г. 14:22
  • Сервер перезагрузил все настройки остались, по скорости ничего не изменилось время повторного замера 3:26, так что как я и думал 1С, при работе на том же сервере, клиент не использует и видимо впринципе не работает через мемори шаринг.
    12 марта 2010 г. 4:18
  • Странно, у меня работает. У меня пока идей больше нет, так что господа специалисты ждем от Вас еще идей как побороть это. 

    Хотя вот появилась :) А база подключенная к SQL 2008 в каком режиме работает? там есть выбор режим совместимости с SQL 2005 и в режиме 2008. Может с этим поиграться. Ну это так в качестве бреда пришедшего в голову.

    MCP,MCTS
    12 марта 2010 г. 5:56
  • http://www.1c-pro.ru/lofiversion/index.php/t12314.html вот статейка про тормоза 1с. тут правда sql 2005 описывается, но в последнем посте человек пишет о переводе режима базы в режим 2000 и тормоза пропали. Может Вам так же попробовать. 
    MCP,MCTS
    12 марта 2010 г. 7:05
  • Странно, у меня работает. У меня пока идей больше нет, так что господа специалисты ждем от Вас еще идей как побороть это. 

    А как вы определяете, что оно у вас работатет под 2008R2? Я вот смотрю хоть через Process Monitor, хоть через стандартный Монитор ресурсов -- идет обмен через TCP IP.


    Уровень совместимости SQL 2008, 2005 попробую в выходные, но судя из тестов в начале ветки это может дать максимум 5-10 сек. прироста на тесте.

    Мне всё-таки кажется, что ключ проблемы надо искать в различиях между Win2k3 и Win2k8R2, поскольку разница во времени выполнения теста очевидна и меняется именно при смене ОС
    12 марта 2010 г. 7:17
  • У меня даже чисто визуально при загрузке больших объемов данный в 1с при sharing время уменьшается с 20 мин до 7-8. 
    По поводу разницы Win2k3 и Win2k8R2: в R2 по умолчанию не включена служба индексирования например, в компонентах есть отдельный пункт  в роли файловый сервер вроде. Правда не знаю как эта служба может сказаться на производительности 1с.
    MCP,MCTS
    12 марта 2010 г. 7:34
  • Хорошо я попробую и это. Но всё-таки вы можете посмотреть в 2008R2 через Process Monitor есть ли у вас обмены через tcp между сервером предприятия и 1С? Потому что 1Сники мне сказали, что это нормальная картина (имею ввиду посты от 25 февраля)

    И как я уже говорил, мне не понятно почему под 2003 у меня этих обменов данная программа совсем не показывает
    12 марта 2010 г. 12:36
  • Относительно использования EasyPrint, могу добавить, что насколько мне известно, в 2008 R2 в отличие от 2008 отпадает требование .net framework, так как многие механизмы в новой версии RDS (в том числе и EasyPrint) переработаны и доведены до ума.

    Относительно темы обсуждения в целом ... Думаю что вообще не совсем корректно сравнивать производительность отдельно взятого приложения на приниципиально разных по своей архитектуре ОС (Win2003 vs Win2008R2)... Ибо даже не смотря на то что железо одинаковое, вы забываете про драйвера к этому железу, которые тоже могут работать по разному в разных версиях ОС и соответсвенно давать системе в целом разные показатели производительности... В вашем случае сразу может бросится в глаза то что SAS контроллер у вас Adaptec....а где гарантия того что проблема не в драйвере на этот контроллер в среде Win2008R2 ??... Я думаю ход моих мыслей ясен...
    ИМХО беседа может не иметь конструктивного универсального вывода, ибо сам приницип подхода к вопросу таких сравнений мне кажется не совсем правильным.  

    12 марта 2010 г. 13:59
  • Относительно темы обсуждения в целом ... Думаю что вообще не совсем корректно сравнивать производительность отдельно взятого приложения на приниципиально разных по своей архитектуре ОС (Win2003 vs Win2008R2)... Ибо даже не смотря на то что железо одинаковое, вы забываете про драйвера к этому железу, которые тоже могут работать по разному в разных версиях ОС и соответсвенно давать системе в целом разные показатели производительности... В вашем случае сразу может бросится в глаза то что SAS контроллер у вас Adaptec....а где гарантия того что проблема не в драйвере на этот контроллер в среде Win2008R2 ??... Я думаю ход моих мыслей ясен...
    ИМХО беседа может не иметь конструктивного универсального вывода, ибо сам приницип подхода к вопросу таких сравнений мне кажется не совсем правильным.  


    Ничего мы про драйвера не забываем. Как я уже писал, мы ставили эксперимент с выносом базы на внешний USB-диск (т.е. работает совершенно другой драйвер системы), время в этом тесте отличалось от обычного на пару секунд, т.е. сравнимо с погрешностью, откудо понятно, что дисковая система роли не играет. Ктому же, если бы драйвера работали некоректно, показывал бы массив скорость передачи 500 - 900 Мб/с при копировании файлов большого размера?

    А вот показания Iometer (файл 20Гб, 128 I/Os, 32K, 50% read, 100% random) ИМХО приличная нагрузка достойный результат:

    диск c (system): Total 1324 I/Os per Second; Total 41,4 Mb per Second; Average I/O response Time 96,44 ms; Maximum I/O response Time 1560 ms; CPU utilization 3,33%

    диск d (базы данных): Total 4528 I/Os per Second; Total 141 Mb per Second; Average I/O response Time 28,25 ms; Maximum I/O response Time 260,77 ms; CPU utilization 4,23%
    14 марта 2010 г. 8:15
  • По итогам воскресных тестов: Пробовал устновить режим совместимости 2005, так же устанавливал сам SQL2005 и включил службу индексирования ни одно из действий не повлияло на время выполнения теста.
    15 марта 2010 г. 7:19
  • Относительно использования EasyPrint, могу добавить, что насколько мне известно, в 2008 R2 в отличие от 2008 отпадает требование .net framework, так как многие механизмы в новой версии RDS (в том числе и EasyPrint) переработаны и доведены до ума.


    Попробовали EasyPrint, с ним ещё медленнее, чем без него. Например на одном из компов, с EasyPrint печать идет 20 сек, если принтер напрямую, то 1-3 сек. .net framework 3.5 установлен, принтер hp1320.
    15 марта 2010 г. 14:25
  • Приветствую всех, на данных момент похожая ситуация как у автора. Только тесты не проводились еще пока. Куплен новый сервер, на который хотим разместить SQL 2005 - 2008 для нужд 1с 8.1 8.2. Стоит следующая задача - выбрать какая ОС от Microsoft даст лучшие показатели производительности 2003 R2  или 2008 R2. Какую версию MS SQL выбрать 2005 или 2008??
    Сервер 1с размещается на другом физическом сервере под Windows 2003 R2.
    Склонялись к версии 2008 так как она уже "нормально" делает разметку файловой системы и дисковая подсистема от этого может выиграть до 20%. Прочитав текущую ветку прихожу к мысли что спешить не нужно :)
    Пришел ли автор к какому либо ответу в чем причина низкой производительности 1с8 на ОС Windows 2008 R2?
    18 марта 2010 г. 10:27
  • Судя из ветки, данный трабл возникает в единичных случаях. Думаю логичней будет использовать последнюю продуктовую линейку от Microsoft. Если будут проблемы то уже откатиться на win2003 R2+sql 2005. Так как сервер новый думаю время для тестов у вас есть. 


    MCP,MCTS
    19 марта 2010 г. 8:12
  • Так же думаю, что стоит провести тестирование самостоятельно и выложить в эту ветку результаты, поскольку как я понял никто из 1сков особо это не проверял и не сравнивал. То что написано в первом посте ветки проводилось на нашей базе, но вне нашей сети, на практически одинаковом с нами железе и на тех же дистрибутивах ПО (т.е. кроме сетевого окружения всё как у нас) -- и возможно на этот тест влияет наша база (см. через абзац) но я тогда не попросил выполнить тест на типовой УТ а сейчас уже всё заново никто делать не будет :о( Поэтому очень интересны полностью независимые результаты.

    Про свою ситуацию скажу, что в понедельник с сервером что-то случилось и тест начал выполнятся около 8мин. Танцы с бубном и перезагрузка всех серверов в сети дала результат время вернулось к 3:37 - 4:00 мин, но прошлую неделю тест всегда укладывался в 3:40 на втором проходе, откуда капают лишние 20 сек. непонятно (проверял даже ночью, когда нет нагрузки) время плавает больше-меньше.

    Что касается 1С, пока что они вроде признались, что у них есть некие проблемы с управляемыми блокировками (а у нас они в этой тестовой базе как раз включены) но решать они их собираются только относительно 8.2. Проект 8.1 типа закрыт.

    19 марта 2010 г. 10:59
  • Ура! Время теста под 8.1 вернулось к 3:26, т.е. как две недели назад, а вот под 8.2 просадка немного осталась 2:36 вместо 2:21. Интересно, что произошло? Пытаюсь выяснить... Могут ли это быть обновления, например за это время у нас были "Definition Update for Windows Defender" могли ли они так влиять на производительность???

    To pwlkit: Удалось ли произвести сравнительные тесты? Какова разница между платформами???

    25 марта 2010 г. 20:28
  • Вы используете возможность RemoteApp терминального сервера win2008R2? Думаю логичней будет его использовать для запуска 1с у пользователей.


    >Как я понимаю, он с sql общается так же через tcp, хотя в диспетчере конфигурации sql в разделе >клиентские протоколы: общая память включена и приоритет у неё 1. Получается memory sharing не > работает :( ?


    Если запускать в терминальном режиме 1с то на стороне сервера нужно запустить cliconfg и там включить крыжик memory sharing. Тогда точно скорость увеличится вразы. 

    MCP,MCTS

    а можно вот тут поподробнее? где это искать?
    29 марта 2010 г. 10:38
  • Мы очень хотим использовать RemoteApp для 1С, но к сожалению у нас пока что какие-то проблемы с драйверами принтеров hp - операторы жалуются на медленную печать может быть это схожая проблема, кстати? + в режиме RemoteApp при табуляции соскакивает фокус с сеанса (пробовали под XP SP3) причем не всегда иногда можно долго работать, но нашим операторам соответственно это не подходит, поэтому пока что терминал под win2k3

    есть такая проблема у нас, вроде они ее даже признали но чинить не хотят
    29 марта 2010 г. 10:38

  • а можно вот тут поподробнее? где это искать?

    Что именно искать?
    MCP,MCTS
    29 марта 2010 г. 10:40
  • cliconfig и memory sharing
    29 марта 2010 г. 11:02
  • на машине с установленным SQL в коммандной строке вводите cliconfg. Откроется окошко с параметрами. В Правую сторону перенесите (включите)  именованные каналы и TCPIP. и Поставте крыжик "разрешить протокол общей памяти"


    MCP,MCTS
    29 марта 2010 г. 11:39
  • есть, нашел.
    как я понял это должно увеличить производительность? для справки, у нас следующая схема: сервер терминалов/сервер 1с на windows2008r2+отдельный на ней же sql2008
    30 марта 2010 г. 2:40
  • у нас примерно такая же картина.

    Сейчас стоит win2003 с 1С, назовем эталон

    Взяли Новое железо, которое мощнее  чем эталонное

    поставили 2008r2  запустили тесты 1с7.7 и 1с8.0 , тесты показали падение на 30% по отношению к эталону.

    На это же железо установили 2003 r2 x64 .. эти же тесты показали прирост на 30-50%по отношению к эталону.

    БД 1с располагалась на диске SSD. както вот так

    30 марта 2010 г. 3:53
  • Впринципе да, если у Вас все прикручено к одному серверу, то шаринг мемори должен помочЬ. Но судя из постов, помогает не всем

    :(


    MCP,MCTS
    30 марта 2010 г. 5:04
  • у нас примерно такая же картина.

    Сейчас стоит win2003 с 1С, назовем эталон

    Взяли Новое железо, которое мощнее  чем эталонное

    поставили 2008r2  запустили тесты 1с7.7 и 1с8.0 , тесты показали падение на 30% по отношению к эталону.

    На это же железо установили 2003 r2 x64 .. эти же тесты показали прирост на 30-50%по отношению к эталону.

    БД 1с располагалась на диске SSD. както вот так


    Тесты тестами, а Вы пробовали сравнивать скорости при проведении проводок различных, экспортов и импортов в 1с\из 1с.  Та же картина с падением производительности?
    MCP,MCTS
    30 марта 2010 г. 5:05
  • Тест был от самой 1с

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

    если железо одно. тесты одни и те же. 1с тоже такой же.. отличие только в OS. и разница в почти 2 раза.. это не нормально

    возможно проблема в связке 1c+2008r2 но разбираться как то не хочется. потому ставим 2003

    30 марта 2010 г. 5:29
  • ИМХО операции которые независят ни отчего, кроме процессора, например вывод отчета на экран после получения всех данных -- выполняются быстро, потеря идет именно на связке с SQL. Я попробую придумать тест который это проверит (у нас через неделю придет дополнительный сервер, на него мы поставим Win2k3) и я проведу доп. тесты, постараюсь проверить данный фактор.

    31 марта 2010 г. 14:03
  • Добрый день, может немножко не в тему, а кто нибудь замерял производителность 1с, на виртуальной машине?

     

     

    P.S. vkonst Подскажите как удалось поставить 1с 8.1 на ms sql 2008?

     

     

     

    4 апреля 2010 г. 5:07
  • P.S. vkonst Подскажите как удалось поставить 1с 8.1 на ms sql 2008?
    Никаких проблем с установкой не было, 1с 8.1 у нас нормально работает и с sql 2005 и с sql 2008
    5 апреля 2010 г. 6:46
  • Эх опять 1С! Ну у меня все в прошлом ....щас все летает ! А были и независимые эксперты... куча литературы и прочего .... В общем 1С признала свой косяк Ставьте последний релиз 8.2 и все будет летать как на 7ке. У меня щас 60 человек сидят на C2D7500 и все здорово .

    Единственная проблема с которой 1С я просто не навижу это то что Хотя щас выложу вырезку с сайта будет полезно:Вот с этим проблема так проблема.

    Ошибка SDBL в 1С:Предприятие 8.0 и один из методов ее устранения.

     

     

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

     

    1) Сервер 1С в процессе работы потребляет виртуальную память. Особо подчеркиваю - виртуальную. Сюда входит о та часть памяти, которая располагается в ОЗУ, и та часть памяти, которая размещается в свопе. Народ часто при описании ошибки SDBL отслеживает и указывает только количество памяти процесса, размещенного в ОЗУ, а это значение может сильно меняться (у кого-то SDBL наступает  при 1 Гб ОЗУ, а у нас это было при 1,4 Гб - это неважно).

     

    2) У сервера 1С есть врожденный косяк - он писался как традиционное Win32 приложение, а они в стандартной архитектуре Win32 больше 2 Гб виртуальной памяти получить не могут. Конечно, потом MS сделала ключик /3GB, но он требует поддержки также и от самого приложения (т.е. оно должно уметь работать с ним), а 1С дорабатывать сервер под этот ключ не стала. Как результат, даже при использовании ключа /3GB и включения поддержки 3 Гб в настройках сервера 1С в DCOM сам сервер 1С больше 2 Гб виртуальной памяти брать отказывается, что очень обидно :(

     

    3) В сервере 1С есть механизмы управления памятью. 1С над ними работает, улучшая их работу от релиза к релизу. У нас стоит последний релиз 8.0.18.2, и мониторинг потребляемой сервером 1С памяти показал, что в целом он постоянно запрашивает у операционной системы дополнительную виртуальную память, хотя возможны кратковременные отдачи памяти назад в операционную систему. Поскольку в целом он память только потребляет, то с достижением порога в 2 Гб виртуальной памяти, выделенной процессу, начинаются ошибки SDBL. В этот момент сервер приходится перезагружать, чтобы сбросить выделенную процессу память в 0 и начать процесс потребления памяти опять.

     

    4) Т.о., в 32-битной версии сервера 1С диапазон выделенной памяти процессу при любых настройках колеблется от 0 до 2 Гб. Это практический диапазон, в котором возможна бесперебойная эксплуатация сервера.

     

    5) Тут я очень сильно сейчас поругаю 1С. К примеру, 1С 8.х позиционируется компанией 1С как основа для построения промышленных решений, а не просто как бухгалтерия малого предприятия. Базы данных промышленных приложений могут хранить много или очень много данных. В большинстве случаев промышленное приложение без передачи своей базы данных под управление СУБД не может обойтись. Но давайте посмотрим на меры, предпринятые компаний Microsoft к позиционированию своего SQL сервера как промышленной СУБД. Ей также, как и 1С, были разработаны и 32-битная, и 64-битная версии своего продукта. Но, в отличие от 1С, и в 32-битной версии, и в 64-битной версии MS реализовала полную поддержку больших объемов ОЗУ - версия SQL Enterprise поддерживает 64 Гб ОЗУ. Причем это реализовано как в 32-битных версиях SQL (через AWE), так и в 64-битных версих (прямая поддержка больших объемов ОЗУ самой ОС). Более того, 32-битный SQL сервер умеет также работать и с ключом /3GB, позволяя получить для базы данных еще один гигабайт. Подводя итог, получаем такую картину в 32-битной трехзвенной архитектуре 1С (по максимальным объемам ОЗУ):

    Клиент (2 Гб) - Сервер 1С (2 Гб) - SQL сервер (64 Гб). Таким образом, сам Сервер 1С становится узким звеном, поскольку именно на нем должны обрабатываться большие объемы данных, а обработать он их не может, потому что памяти не хватает. Тут какая-то женщина администратор писала, что их СУБД имеет размер 100 Гб, и сервер 1С они вынуждены по нескольку раз в сутки перезапускать. Вот такая вот грустная история получается с внедрением 1С на крупных промышленных предприятиях. Почему я так напираю на 32-битные версии? Потому что пока еще индустрия не перешла на 64-битный софт, и использование 32-битных версий для многих компаний остается еще весьма и весьма актуальной темой. Он отлажен и проверен годами, и в общем-то, кроме пресловутого порога 4 Гб нет другой причины для ухода от него в 64-битные версии, которые появились на рынке относительно недавно.

     

    6) Что же нам предлагает 1С для решения проблемы малого (по промышленным масштабам) объема памяти, выделяемого серверу 1С:

                А) в 32-битной версии включить поддержку 3 Гб памяти, выделяемой процессу. Но так как это не было реализовано программно в самом сервере 1С, должного эффекта это не даст – ошибка SDBL будет появляться при 2 Гб выделенной процессу памяти (виртуальной).

                Б) Заставить программистов найти запросы, возвращающие большие выборки, и переписать их. Однако эта мера, при высоких трудозатратах, не уберет ошибку SDBL, ибо потребление памяти сервером 1С не прекратится совсем, а только замедлится.

                В) Перезапускать сервер 1С. При этом старый процесс, взявший много памяти, закрывается, а его ресурсы (в первую очередь память) возвращаются ОС. Новый экземпляр процесса сервера 1С начинает свою работу с 0 памяти, выделенной процессу. Тоже проблемы не решает, т.к. эта мера не влияет на само свойство сервера 1С потреблять память.

    Г) Перейти на технологическую платформу 8.1. Как заявляет сама 1С, в 8.1 были существенно переработаны механизмы обработки больших выборок. Но, на мой взгляд, все свелось к одному. В 8.0 результаты всех выборок падали в память, а в 8.1 1С разделила их на маленькие, которые по-прежнему падают в память, и большие, которые сливаются во временные файлы на диске. Однако в любом случае свойство сервера потреблять память не убрано, и поскольку в общем-то это та же 8-ка, то 2 Гб порог остался. По некоторым сведениям с форума переход на 8.1 не избавил людей от этой ошибки, хотя другие рапортуют о том, что у них она пропала. Я думаю, что все объясняется просто – принятые 1С в 8.1 меры существенно замедлили скорость роста потребляемой сервером памяти, поэтому те, кто не жалуются, просто еще не достигли порога в 2 Гб, а кому-то даже такое существенное замедление роста не помогло и они достигли предела в 2 Гб.

    Д) Это модернизированный вариант г). Суть в том, что администраторы в компании разворачивают несколько серверов 1С, объединенных в кластер, а программисты раскидывают исполняющиеся задачи по серверам 1С кластера. Удельная нагрузка на одиночный сервер 1С падает, а следовательно отсрочивается и момент достижения 2 Гб предела. Но это фактически означает, что однопоточную конфигурацию какой-нибудь УПП фактически переписать в многопоточную. При этом компания вынуждена идти на существенные финансовые, трудовые затраты и временные затраты – закупка софта и железа, затем переписывание конфигурации (а вы знаете, как в мире сейчас тяжело с обучением программистов многопоточным вычислениям, а ведь это родственные задачи). Да и программисты от такого вряд ли будут в восторге.

    Е) Для тех, кого это уже достало и сил уже больше нет, переход на 64-битный софт. Это 64-битная ОС и 64-битная версия сервера 1С. Тут виртуальной памяти, выделяемой одному процессу столько, что об этом можно забыть на ближайшие 10 лет и на эту тему больше не волноваться. При любых скоростях потребляемой сервером 1С памяти достижение порога, определяемого для процесса, наступит очень-очень не скоро, так что проблема можно сказать исчезает. Скорее сервер будет выключен для прочистки вентиляторов J, а тогда и память сбросится. Вопрос только в том, насколько 64-битные ОС и сам сервер готовы к промышленному режиму эксплуатации. Насколько я знаю, в самих 64-битных ОС еще не всегда можно найти драйвера для оборудования, а на форуме нет еще ни одного отзыва об эксплуатации 64-битной версии сервера 1С.

    Ж) Сама 1С переписывает на системном уровне 32-битную версию сервера 1С, реализовав полную поддержку механизма PAE/AWE, что позволит серверу 1С адресовать до 64 Гб памяти (если его запускать на версиях Windows Server Datacenter Edition). Однако по имеющимся сведениям 1С никогда на это не пойдет, т.к. на рынке уже есть ее 64-битная версия сервера 1С, обеспечивающая использование такого же объема памяти.

     

    7) А вот это метод, который мы сами открыли (на право первенства не претендуем, но на форуме и в инете таких сведений не нашли). Почему-то в рекомендациях 1С о нем ничего не говорится. Поскольку одним из решений является периодический перезапуск сервера, мешающий ему набрать 2 Гб памяти, то это можно делать двумя путями. Первый путь – администратор в заданное время скриптами или чем угодно принудительно закрывает , а затем вновь запускает процесс сервера. Второй путь – штатные средства подсистемы DCOM. В настройках DCOM сервера 1С есть такой параметр "Enable idle shutdown". Суть его в том, что система DCOM отслеживает активность процесса сервера, и если он простаивает, т.е. простаивает без работы и находится в состоянии «idle», то DCOM его закрывает до тех пор, пока сервер 1С кому-нибудь не понадобится. При поступлении запроса к серверу 1С DCOM ставит такой запрос в очередь, а сама запускает сервер 1С. Как только он успешно запущен, система DCOM передает ему для обработки ожидающий запрос. Легко догадаться, что такое поведение лучше, чем простое обрубание сервера, т.к. есть вероятность, что администратор закроет процесс сервера в тот момент, когда он делает важную работу. Теперь внимание! По умолчанию значение параметра "Enable idle shutdown" равно 3 минуты. Мои наблюдения за использованием "Enable idle shutdown" механизма DCOM и нашего сервера 1С показали, что у нас он не срабатывает, видимо потому, что сервер 1С за три минуты не переходит в состояние «idle». Как результат, сервер работает бесконечно, накапливая потихоньку выделенную ему виртуальную память до 2 Гб, после чего отказывается работать, выдавая ошибку SDBL по любому поводу. Но логика подсказывает, что даже если внутри сервера есть механизмы, подобные «keep-alive», все равно ночью процесс сервера должен простаивать (после выполнения всех ночных регламентных работ). Уменьшив интервал таймера с 3 минут до 1, я добился нужного эффекта. При одноминутном интервале наступают моменты, когда сервер 1С простаивает в течение одной минуты. Этого достаточно, чтобы DCOM гасила процесс, освобождая ресурсы сервера 1С и возвращая их операционной системе. На данный момент мониторинг сервера показал, что он действительно сбрасывается под утро. Пока я таким эффектом доволен и предлагаю его попробовать тем, кого достает ошибка SDBL. Возможно, что на 100 Гб базах процесс сервера 1С будет успевать набирать 2 Гб память в течение 2-3 часов рабочего времени и придется сервер сбрасывать принудительно, но пока у нас база 6 Гб, и нас это устраивает. К тому времени, когда она достигнет 100 Гб, возможно уже 64-битный софт будет отлажен и получит повсеместное распространение.

    26 апреля 2010 г. 9:28
  • Да и еще вот : попробуйте у тех у кого еще первая 8 ка. Убрать пользователей или просто всех сделать администраторами ...И вы увидете чудо!!!!! Она летает)))))) В общем друзья юзайте.....Да и у меня все крутится на одной машине SQL итд Разделение на разные сервера не дали результатов

    И тоже на момент внедрения Эксперты из той же 1С приводят примеры предприятий где все просто летало! НА сервере за 500ТЫС руб!!!!!!!!!!+ еще один за 250 ТЫС!!! с 50 пользователями!!! Одуреть ...Я в шоке ...

    Ещебы не летало....

     

    26 апреля 2010 г. 9:34
  • Да и еще вот : попробуйте у тех у кого еще первая 8 ка. Убрать пользователей или просто всех сделать администраторами ...И вы увидете чудо!!!!! Она летает)))))) В общем друзья юзайте.....Да и у меня все крутится на одной машине SQL итд Разделение на разные сервера не дали результатов

    И тоже на момент внедрения Эксперты из той же 1С приводят примеры предприятий где все просто летало! НА сервере за 500ТЫС руб!!!!!!!!!!+ еще один за 250 ТЫС!!! с 50 пользователями!!! Одуреть ...Я в шоке ...

    Ещебы не летало....

     


    Очень забавно слышать оценку производительности сервера по его цене, улыбнуло )
    MCSE since 2004
    26 апреля 2010 г. 15:59
  • Очень забавно слышать оценку производительности сервера по его цене, улыбнуло )
    MCSE since 2004

    Только на одно предложение и хватило сил. а это меня и ..улыбнуло)

    Я не собирался описывать сервера , конфигурации которых я не помню уже.Да и если на то пошло не в конфигурации проблема  а в самой 1С,  если  еще поняли то у меня на C2D 7500\2GB\ 60 полдьзователей не знают проблем.А если ктот  1С8 собирается крутить на 286 или Изотах. Для них специально сьезжу в гостиницу, в которой было установленно оборудование и отпишусь,создадим новую тему и посмеёмся вместе. .

    26 апреля 2010 г. 18:22
  • Спасибо Adminnik за интересный пост, правда мне от него пользы особой в данной ситуации нет, но на заметку возьму :о) (у нас под W2k8R2 стоит 64-битный сервер 1C:Предприятия) А вот в работе непонятные глюки есть (затраиваются движения по разным регистрам при проведении + выбрасывает из базы с разными ошибками) так что возможно 64-битная версия ещё сыровата... но разницы по скорости с 32-битной нет.

    Что касается нас, то 2ой сервак "за 200" пришел. Наш тест с легкостью показал на нем 2:14 из под W2k3R2x64, SQL2008 + 32bit сервером 1C 8.1 -- и это на более слабых процах и с RAID10 из 6 SAS15k винтов (по оценке Iometer данный RAID слабже использованного в нашем первом сервере в ~4 раза)

    Так что за щёт того что мы все базы кроме торговли убрали с первого сервера, производительность торговли стала более-менее. Но тест остался на той отметке что и был.

  • Хм...а 1С 32 битная или 64?SQL 32 или 64? и какого размера база?

    Дело в том что у нас изза того что косяк в том что у нас  32 битная 1С , SQL 64 но проблемы начинаются такие же Ток без торможения. Так вот разбирались с тем кто занимается поддержкой 1С ....наткнулись на то что наша база заработала без ошибок и глюков на 64 биной платформе 1С , 64 бит SQL и естест винде...

    при разборе полетов выяснилось что проблема в 32 битной 1С , я выложил описания выше Ошибка SDBL в 1С:Предприятие 8.0 и один из методов ее устранения

    И еще скажи а после перезагрузки серваков Валятся ли у тебя ошибке и исчезают ли у тебя твои проблемы(хоть на время) ? или нет?

  • На сервере о котором идет речь, всё 64х битное. На новом 2ом серваке мы поставили сервер 1С 32х, т.к. у нас нет 2го 64х ключа (но этот сервер пока вроде работает нормально....)

    Что касается перезагрузки, то помоему она никак не влияет на наши проблемы... сервер под Win2k8R2 мы вообще редко перегружаем (вот в эти праздники я его как раз перегрузил -- у меня начал жудко тормозить конфигуратор, бывает нажмешь правую кнопку на объекте и он - повис.... иногда развисает через минут 20, вобщем надоело мне это и я его перегрузил -- результат -- не помогло. так что это какая-то новая напасть) и вообще щаз у него фаза слабой производительности тест выполняется за 4:41, что больше чем на минуту медленне рекорда для этого сервера. (Но возможно это связано с тем, что сейчас на сервере нет свободной памяти -- после того как мы пустили в строй виртуальную машину терминала, вся свободная память уходит в кэш и как это запретить мне пока непонятно)

  • м..дя не очень...Все странно как то....А на сколько знаю все при организации виртуальной машины можно четко задать пределы используемых ресурсов...Попроуй если это реально перенести сервак 1С на отдельную машинучтоб только 1с крутилась без виртуальных машин... и псмотри ...вообще я еще подумаю скажу....Все как то странно ...Еслиб ты сказал что проблема с 32 биной 1с еще б поверил а так как все 64 бит  ное то ....Подумаю...но не заморачивайся лучше попробуй поднять на отдельной машине пусть не мощьной Пусть тот же комп...

    А скок пользователей у тя крутится на серваке с проблемами?

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

    разделить ресурсы можно с помощью Windows System Resource Manager...

    MCSE since 2004
  • после того как мы пустили в строй виртуальную машину терминала, вся свободная память уходит в кэш и как это запретить мне пока непонятно)

    разделить ресурсы можно с помощью Windows System Resource Manager...

    MCSE since 2004


    А может быть эти ресурсы нужны вирт машинам? После того как мы оставили только торговлю (40 пользователей, 30Гб данных) производительность стала более менее. Что касается времени теста, то вот сейчас свободной памяти полно, никто не работает, а тест выполнялся 4:14 что на минуту медленнее рекорда этого сервера и на две если бы тут был W2k3.

    Меня в этой ветке интересует всего один вопрос. Почему под W2k8R2 1С значительно медленнее (60-100% и более потери) чем под W2k3??? Пока что я понял, что наибольшая зависимость под W2k8R2 от сети (это наличие пользовательского ключа в сервере, настройки nethasp.ini, это же подтверждает и procmon, показывая намного большее количество обменов между 1С и SQL через tcp под w2k8r2)


  • А может быть эти ресурсы нужны вирт машинам?

     

    Меня в этой ветке интересует всего один вопрос. Почему под W2k8R2 1С значительно медленнее (60-100% и более потери) чем под W2k3??? Пока что я понял, что наибольшая зависимость под W2k8R2 от сети (это наличие пользовательского ключа в сервере, настройки nethasp.ini, это же подтверждает и procmon, показывая намного большее количество обменов между 1С и SQL через tcp под w2k8r2)


    1. Я бы исходил из того, что нужно доказать, что ресурсы действительно нужны. Надо обязательно проверить практикой.

    2. Раз Вы умете пользоваться procmon, ну возмите фильтр Duration >0.1 и сравните. У меня был случай http://infostart.ru/forum/messages/forum16/topic29584/message334784/#message334784 , когда 1С резко ускорилась из-за корректировки драйвера жестого диска и управления кэшем записи на диск.

     


    MCSE since 2004
  • Дочитал ветку до вашего бэнчмарка, попробовал у себя (версию 81):

    Испытуемый сервер w2k8R2:

     SQL вариант -- 16 попугаев; файл -- 42 попугая, причем на SQL тесте вылетает при каждом прогоне ошибка:

    {Обработка.TCP_1C_GILV.Форма.Форма(513)}: Ошибка при вызове метода контекста (ConnectAgent): Произошла исключительная ситуация (V81.COMConnector.1): descr=Сервер недоступен (Не отвечает, завершается аварийно или порт занят другим приложением) line=512 file=.\src\RemoteCreatorImpl.cpp

    Аналогичный сервер под W2k3R2 с более слабым RAID:

    SQL вариант -- 33 попугая; файл -- 47 попугаев   никаких ошибок не выскакивает

    Ну вот примерно так у нас дела

     

  • Дочитал ветку до вашего бэнчмарка, попробовал у себя (версию 81):

    Испытуемый сервер w2k8R2:

     SQL вариант -- 16 попугаев; файл -- 42 попугая, причем на SQL тесте вылетает при каждом прогоне ошибка:

    {Обработка.TCP_1C_GILV.Форма.Форма(513)}: Ошибка при вызове метода контекста (ConnectAgent): Произошла исключительная ситуация (V81.COMConnector.1): descr=Сервер недоступен (Не отвечает, завершается аварийно или порт занят другим приложением) line=512 file=.\src\RemoteCreatorImpl.cpp

    Аналогичный сервер под W2k3R2 с более слабым RAID:

    SQL вариант -- 33 попугая; файл -- 47 попугаев   никаких ошибок не выскакивает

    Ну вот примерно так у нас дела

     


    1. Получается, раз файловый вариант одинаковые цифры показывает, что дело не в дисках.

    Для полной уверности можно еще перепроверить http://release.crystaldew.info/CrystalDiskMark .

     

    2. Есть стандартный набор действий вроде

    http://gilev.blogspot.com/2009/12/windows-server-20082003-x64-sql-server.html

    http://www.youtube.com/watch?v=9OgTKJ41LBk&feature=player_embedded

    которые позволяют минимизировать влияние настроек среды.

     

    3. Я все же попрежнему придерживаюсь мнения Процесс монитором заюзать дуратион колонку событий.

     

     


    MCSE since 2004
  • 1. Думаю точно не диски, так как пробовали ставить базу на внешний usb

    2. Изучу....

    3. Могу сделать сейчас, но в ветке вы советовали в спокойное время?

  • 1. Думаю точно не диски, так как пробовали ставить базу на внешний usb

    2. Изучу....

    3. Могу сделать сейчас, но в ветке вы советовали в спокойное время?


    если разница сильная, она будет видна в любое время
    MCSE since 2004
  • ничего с дюрацией больше 0.1 не попадает в фильтр....
  • а вот что-то цепанулось:

    15:24:23,5762555 rphost.exe 5112 QueryStandardInformationFile C:\Users\Администратор\AppData\Local\Temp\v8_4A64_2.tmp SUCCESS AllocationSize: 331 776, EndOfFile: 330 305, NumberOfLinks: 1, DeletePending: False, Directory: False 0.1624854
    15:24:26,2188054 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 32 943 652 864, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.1079274
    15:24:26,2247951 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 32 943 718 400, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.1019281

  • а вот что-то цепанулось:

    15:24:23,5762555 rphost.exe 5112 QueryStandardInformationFile C:\Users\Администратор\AppData\Local\Temp\v8_4A64_2.tmp SUCCESS AllocationSize: 331 776, EndOfFile: 330 305, NumberOfLinks: 1, DeletePending: False, Directory: False 0.1624854
    15:24:26,2188054 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 32 943 652 864, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.1079274
    15:24:26,2247951 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 32 943 718 400, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.1019281

    1. пособирать нужно на обоих серверах, чтобы сравнить длительность операций, можно ослабить фильтр, но осторожно, иначе может захлебнуться в событиях.

    2. C:\Users\Администратор\AppData\Local\Temp\v8_4A64_2.tmp наверно можно перенести на D:, судя по тесту выше там отклик шустрее


    MCSE since 2004
  • Странно что по вашему бэнчу файловые варианты были примерно одинаковы... видимо уперлись в скорость памяти, т.к. SSD от Intel рвут обычные SAS где-то в 4 раза по данным IOMeter
  • Странно что по вашему бэнчу файловые варианты были примерно одинаковы... видимо уперлись в скорость памяти, т.к. SSD от Intel рвут обычные SAS где-то в 4 раза по данным IOMeter

    Если подозрения на память, то можете попробовать конвернуть 8.1 в 8.2 в режиме совместимости. В этом случаи оптимальней используется железо. Но это лирика,

    попрежднему хочется увидеть сравнение дурейшен двух серверов на одних и тех же операция.


    MCSE since 2004
  • Ну вот выпадает procmon часто у нас, целиком за время выполнения отчет дать поэтому не могу но вот например кусок в начале теста (не с самого начала) с дюрацией 0.01:

     

    16:12:09,6731412 rphost.exe 5112 QueryStandardInformationFile C:\Users\Администратор\AppData\Local\Temp\v8_7DED_2.tmp SUCCESS AllocationSize: 491 520, EndOfFile: 487 642, NumberOfLinks: 1, DeletePending: False, Directory: False 0.0945845
    16:12:17,2399051 sqlservr.exe 1768 WriteFile D:\gilev81.mdf SUCCESS Offset: 10 158 080, Length: 106 496, I/O Flags: Non-cached, Priority: Normal 0.0466506
    16:12:21,1482642 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 11 320 049 664, Length: 16 384, I/O Flags: Non-cached, Priority: Normal 0.0238706
    16:12:21,1804645 sqlservr.exe 1768 WriteFile D:\gilev81_log.ldf SUCCESS Offset: 22 789 632, Length: 1 536, I/O Flags: Non-cached, Priority: Normal 0.0375472
    16:12:21,2106892 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 25 830 375 424, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0334989
    16:12:21,2149448 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 22 863 405 056, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0291615
    16:12:21,2232523 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 32 271 761 408, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0234493
    16:12:21,2234477 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 32 271 826 944, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0231748
    16:12:21,2360841 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 32 435 920 896, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0242235
    16:12:21,2499942 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 32 463 912 960, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0371855
    16:12:21,2725969 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 32 620 765 184, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0260949
    16:12:21,2810560 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 32 520 552 448, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0325493
    16:13:23,1197183 Explorer.EXE 4216 FileSystemControl C:\Users\vkonst\Links\RecentPlaces.lnk SUCCESS Control: FSCTL_REQUEST_FILTER_OPLOCK 0.0107127
    16:13:57,2188134 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 604 798 976, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0481578
    16:13:57,2197384 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 34 989 694 976, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0448191
    16:13:57,2226721 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 44 482 191 360, Length: 40 960, I/O Flags: Non-cached, Priority: Normal 0.0212518
    16:13:57,2370936 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 2 849 046 528, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0314500
    16:13:57,2371251 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 2 915 303 424, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0314265
    16:13:57,2371988 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 2 584 018 944, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0305281
    16:13:57,2372315 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 2 650 275 840, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0269001
    16:13:57,2372699 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 2 716 532 736, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0312656
    16:13:57,2385063 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 560 152 576, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0235069
    16:13:57,2387962 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 2 675 802 112, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0297201
    16:13:57,2431617 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 37 170 118 656, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0188665
    16:13:57,2472061 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 20 928 503 808, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0315372
    16:13:57,2513051 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 2 482 110 464, Length: 32 768, I/O Flags: Non-cached, Priority: Normal 0.0156883
    16:13:57,2568675 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 2 458 435 584, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0101359
    16:13:57,2795780 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 9 470 803 968, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0265807
    16:13:57,2833130 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 29 650 010 112, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0293074
    16:13:57,2872204 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 5 270 437 888, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0225762
    16:14:00,8321642 rphost.exe 5112 QueryStandardInformationFile C:\Users\Администратор\AppData\Local\Temp\v8_12F9_2.tmp SUCCESS AllocationSize: 1 179 648, EndOfFile: 1 092 423, NumberOfLinks: 1, DeletePending: False, Directory: False 0.0628865
    16:14:03,0807174 sqlservr.exe 1768 WriteFile D:\ecobalt2009_log.LDF SUCCESS Offset: 5 039 616, Length: 512, I/O Flags: Non-cached, Priority: Normal 0.1213234
    16:14:03,0962248 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 31 734 710 272, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0730708
    16:14:03,1163301 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 35 531 833 344, Length: 16 384, I/O Flags: Non-cached, Priority: Normal 0.0882780
    16:14:03,1490003 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 22 981 320 704, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0609175
    16:14:03,2286149 sqlservr.exe 1768 WriteFile D:\gilev81_log.ldf SUCCESS Offset: 38 220 288, Length: 6 144, I/O Flags: Non-cached, Priority: Normal 0.0259998
    16:14:23,0821811 rphost.exe 5112 QueryStandardInformationFile C:\Users\Администратор\AppData\Local\Temp\v8_7A45_2.tmp SUCCESS AllocationSize: 851 968, EndOfFile: 741 370, NumberOfLinks: 1, DeletePending: False, Directory: False 0.0763066
    16:14:25,1026246 rphost.exe 5112 SetEndOfFileInformationFile C:\Users\Администратор\AppData\Local\Temp\v8_7A75_2.tmp SUCCESS EndOfFile: 1 191 229 0.0703196
    16:14:25,1225679 rphost.exe 5112 CloseFile C:\Users\Администратор\AppData\Local\Temp\v8_8252_1e.tmp SUCCESS  0.0212786
    16:14:44,6747727 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 44 482 166 784, Length: 65 536, I/O Flags: Non-cached, Priority: Normal 0.0197689
    16:14:53,4080861 rphost.exe 5112 QueryStandardInformationFile C:\Users\Администратор\AppData\Local\Temp\v8_F7B3_2.tmp SUCCESS AllocationSize: 425 984, EndOfFile: 424 649, NumberOfLinks: 1, DeletePending: False, Directory: False 0.0471486
    16:14:59,4699957 rphost.exe 5112 QueryStandardInformationFile C:\Users\Администратор\AppData\Local\Temp\v8_E8E_2.tmp SUCCESS AllocationSize: 524 288, EndOfFile: 429 978, NumberOfLinks: 1, DeletePending: False, Directory: False 0.0362751
    16:15:23,7550943 rphost.exe 5112 QueryStandardInformationFile C:\Users\Администратор\AppData\Local\Temp\v8_6CB7_2.tmp SUCCESS AllocationSize: 458 752, EndOfFile: 406 311, NumberOfLinks: 1, DeletePending: False, Directory: False 0.0333595
    16:15:35,9449636 sqlservr.exe 1768 ReadFile D:\ecobalt2009.mdf SUCCESS Offset: 474 480 640, Length: 262 144, I/O Flags: Non-cached, Priority: Normal 0.0101072
    16:15:36,4577394 sqlservr.exe 1768 WriteFile D:\MSSQL10.MSSQLSERVER\MSSQL\DATA\templog.ldf SUCCESS Offset: 204 032 512, Length: 61 440, I/O Flags: Non-cached, Priority: Normal 0.0167431
    16:15:44,0972512 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 29 006 012 416, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0128223
    16:15:44,0972912 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 29 006 069 760, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0422590
    16:15:44,0973257 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 29 006 249 984, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0422076
    16:15:44,1070585 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 28 985 114 624, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0324994
    16:15:44,1085595 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 2 482 110 464, Length: 16 384, I/O Flags: Non-cached, Priority: Normal 0.0309822
    16:15:44,1127975 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 34 989 727 744, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0213097
    16:15:44,1216198 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 2 750 226 432, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0156549
    16:15:44,1380841 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 3 267 960 832, Length: 16 384, I/O Flags: Non-cached, Priority: Normal 0.0238829
    16:15:44,1401081 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 29 650 026 496, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0515095
    16:15:44,1484359 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 1 477 615 616, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0102934
    16:15:44,1512505 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 29 699 686 400, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0748517
    16:15:44,1568547 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 29 316 087 808, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0994330
    16:15:44,1608519 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 8 376 074 240, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0159110
    16:15:44,1610619 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 3 062 988 800, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0632536
    16:15:44,1612812 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 31 724 863 488, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0303744
    16:15:44,1651632 sqlservr.exe 1768 WriteFile D:\ecobalt2009.mdf SUCCESS Offset: 6 218 694 656, Length: 8 192, I/O Flags: Non-cached, Priority: Normal 0.0115817
    16:15:47,5570476 Explorer.EXE 4216 NotifyChangeDirectory C:\Users\vkonst\Documents CANCELLED Filter: FILE_NOTIFY_CHANGE_DIR_NAME 3.5264398
    16:15:47,5578628 Explorer.EXE 4216 NotifyChangeDirectory C:\Users\vkonst\Documents CANCELLED Filter: FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_ATTRIBUTES, FILE_NOTIFY_CHANGE_LAST_WRITE 3.5257456
    16:15:47,5581961 Explorer.EXE 4216 NotifyChangeDirectory C:\Users\Public\Documents CANCELLED Filter: FILE_NOTIFY_CHANGE_DIR_NAME 3.5243513
    16:15:47,5583889 Explorer.EXE 4216 NotifyChangeDirectory C:\Users\Public\Documents CANCELLED Filter: FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_ATTRIBUTES, FILE_NOTIFY_CHANGE_LAST_WRITE 3.5243398

    сейчас попробую посмотреть что будет на втором серваке с этим же параметром...

  • ну вот на втором серваке с первого раза всё выполнилось без выпадания (привожу кусок примерно за то же время целиком форум не даёт разместить):

    16:26:44,6501073 svchost.exe 824 FlushBuffersFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS  0.0631275
    16:26:44,6501394 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS Offset: 0, Length: 65 536, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0247136
    16:26:44,6823712 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS Offset: 0, Length: 65 536, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0112436
    16:26:48,6494540 svchost.exe 824 FlushBuffersFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr0.dat SUCCESS  0.0432089
    16:26:48,6494811 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr0.dat SUCCESS Offset: 0, Length: 65 536, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0164230
    16:26:51,7603583 winlogon.exe 396 NotifyChangeDirectory C:\WINDOWS SUCCESS Filter: FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_DIR_NAME, FILE_NOTIFY_CHANGE_SIZE, FILE_NOTIFY_CHANGE_LAST_WRITE, FILE_NOTIFY_CHANGE_CREATION, FILE_NOTIFY_CHANGE_STREAM_SIZE, FILE_NOTIFY_CHANGE_STREAM_WRITE 53.9938094
    16:27:27,1175246 sqlservr.exe 1368 WriteFile D:\MSSQL10.MSSQLSERVER\MSSQL\DATA\templog.ldf SUCCESS Offset: 6 571 520, Length: 61 440, I/O Flags: Non-cached 0.0130279
    16:27:28,9596104 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 55 316 480, Length: 1 024, I/O Flags: Non-cached 0.0113422
    16:27:33,9105916 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 56 901 120, Length: 1 536, I/O Flags: Non-cached 0.0102279
    16:27:35,6288693 svchost.exe 824 FlushBuffersFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS  0.0414518
    16:27:35,6289051 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS Offset: 0, Length: 65 536, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0159078
    16:27:35,6401959 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 57 431 552, Length: 7 168, I/O Flags: Non-cached 0.0109113
    16:27:35,6501199 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS Offset: 0, Length: 65 536, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0119134
    16:27:38,2622810 klnagent.exe 1328 SetRenameInformationFile C:\Program Files (x86)\Kaspersky Lab\NetworkAgent 8\products\03291ACE1C9261BAEFA5277373D298D4\ess\e2s_temp_sbscr_INF95345fe2-2b4a-4da2-b1af-d5f9b967fc83.ctrl.tmp SUCCESS ReplaceIfExists: False, FileName: C:\Program Files (x86)\Kaspersky Lab\NetworkAgent 8\products\03291ACE1C9261BAEFA5277373D298D4\ess\e2s_temp_sbscr_INF95345fe2-2b4a-4da2-b1af-d5f9b967fc83.ctrl 0.0101081
    16:27:38,7955876 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 58 393 088, Length: 1 024, I/O Flags: Non-cached 0.0136358
    16:27:40,4196467 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 58 924 544, Length: 6 144, I/O Flags: Non-cached 0.0130437
    16:27:41,8239143 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 59 368 448, Length: 1 536, I/O Flags: Non-cached 0.0119525
    16:27:42,7591260 svchost.exe 824 FlushBuffersFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr0.dat SUCCESS  0.0425250
    16:27:42,7591509 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr0.dat SUCCESS Offset: 0, Length: 65 536, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0136162
    16:27:42,7819984 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr0.dat SUCCESS Offset: 0, Length: 65 536, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0137002
    16:27:45,7542186 winlogon.exe 396 NotifyChangeDirectory C:\WINDOWS SUCCESS Filter: FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_DIR_NAME, FILE_NOTIFY_CHANGE_SIZE, FILE_NOTIFY_CHANGE_LAST_WRITE, FILE_NOTIFY_CHANGE_CREATION, FILE_NOTIFY_CHANGE_STREAM_SIZE, FILE_NOTIFY_CHANGE_STREAM_WRITE 47.9944270
    16:27:47,3677780 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 61 038 592, Length: 6 656, I/O Flags: Non-cached 0.0101480
    16:27:47,4481280 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 61 062 656, Length: 1 024, I/O Flags: Non-cached 0.0101009
    16:27:47,6282377 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 61 106 688, Length: 1 024, I/O Flags: Non-cached 0.0118121
    16:27:47,6622971 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 61 109 248, Length: 6 656, I/O Flags: Non-cached 0.0107767
    16:27:47,6808687 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 61 116 928, Length: 1 536, I/O Flags: Non-cached 0.0104713
    16:27:48,1626836 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 61 240 832, Length: 1 024, I/O Flags: Non-cached 0.0101474
    16:27:53,9114568 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 63 027 712, Length: 1 024, I/O Flags: Non-cached 0.0120736
    16:27:53,9259218 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 63 028 736, Length: 1 536, I/O Flags: Non-cached 0.0102569
    16:27:56,4537700 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 6 070 272, Length: 262 144, I/O Flags: Non-cached 0.0122305
    16:27:56,8041401 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 1 015 808, Length: 8 192, I/O Flags: Non-cached 0.0142181
    16:27:56,8042663 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 1 220 608, Length: 8 192, I/O Flags: Non-cached 0.0141987
    16:28:00,3403125 nncron.exe 2368 NotifyChangeDirectory C:\Program Files (x86)\nnCron SUCCESS Filter: FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_DIR_NAME 119.9820538
    16:28:04,7524582 rmngr.exe 4356 QueryStandardInformationFile C:\Program Files (x86)\1cv81\server\reg_1541\545773ad-32f6-4f79-9ad6-3a3c9baad74a\1Cv8FTxt\changes20100506000000.log SUCCESS AllocationSize: 7 274 496, EndOfFile: 3 533 084, NumberOfLinks: 1, DeletePending: False, Directory: False 0.0101874
    16:28:11,7509529 rmngr.exe 4356 QueryStandardInformationFile C:\Program Files (x86)\1cv81\server\reg_1541\545773ad-32f6-4f79-9ad6-3a3c9baad74a\1Cv8FTxt\changes20100506000000.log SUCCESS AllocationSize: 7 274 496, EndOfFile: 3 606 448, NumberOfLinks: 1, DeletePending: False, Directory: False 0.0107872
    16:28:14,9408519 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 4 760 064, Length: 6 144, I/O Flags: Non-cached 0.0147064
    16:28:24,7897935 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 7 846 912, Length: 1 024, I/O Flags: Non-cached 0.0101197
    16:28:24,8023622 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 7 847 936, Length: 1 536, I/O Flags: Non-cached 0.0125983
    16:28:28,8223485 svchost.exe 824 FlushBuffersFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS  0.0367389
    16:28:28,8223749 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS Offset: 0, Length: 65 536, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0135218
    16:28:29,4290089 1cv8.exe 4164 QueryDirectory \\Gate\files\ExchangeWMSUT\WMS\Good\Mess_ExportUTtoWMS_290310_5e539bb9cb8140cca90e99bc6ed9cb90.xml NO SUCH FILE Filter: Mess_ExportUTtoWMS_290310_5e539bb9cb8140cca90e99bc6ed9cb90.xml 0.0454833
    16:28:29,4985797 1cv8.exe 4164 SetRenameInformationFile \\Gate\files\ExchangeWMSUT\WMS\Mess_ExportUTtoWMS_290310_5e539bb9cb8140cca90e99bc6ed9cb90.xml SUCCESS ReplaceIfExists: False, FileName: \\Gate\files\ExchangeWMSUT\WMS\Good\Mess_ExportUTtoWMS_290310_5e539bb9cb8140cca90e99bc6ed9cb90.xml 0.0808695
    16:28:29,6535365 svchost.exe 824 FlushBuffersFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr0.dat SUCCESS  0.0446544
    16:28:29,6535647 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr0.dat SUCCESS Offset: 0, Length: 65 536, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0168146
    16:28:29,8289721 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 9 413 632, Length: 6 144, I/O Flags: Non-cached 0.0144081
    16:28:30,2879232 1cv8.exe 4164 SetRenameInformationFile \\Gate\files\ExchangeWMSUT\WMS\Mess_ExportUTtoWMS_290310_88920aa782524a629423f75e4624ecd9.xml SUCCESS ReplaceIfExists: False, FileName: \\Gate\files\ExchangeWMSUT\WMS\Good\Mess_ExportUTtoWMS_290310_88920aa782524a629423f75e4624ecd9.xml 0.0195868
    16:28:30,7866897 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 9 678 336, Length: 1 024, I/O Flags: Non-cached 0.0157622
    16:28:30,8489875 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 9 688 064, Length: 1 536, I/O Flags: Non-cached 0.0108313
    16:28:33,7486901 winlogon.exe 396 NotifyChangeDirectory C:\WINDOWS SUCCESS Filter: FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_DIR_NAME, FILE_NOTIFY_CHANGE_SIZE, FILE_NOTIFY_CHANGE_LAST_WRITE, FILE_NOTIFY_CHANGE_CREATION, FILE_NOTIFY_CHANGE_STREAM_SIZE, FILE_NOTIFY_CHANGE_STREAM_WRITE 44.9947454
    16:28:40,4856371 winlogon.exe 6812 RegQueryValue HKLM\SOFTWARE\Wow6432Node\KasperskyLab\protected\AVP80\settings\EnableLoginShow SUCCESS Type: REG_DWORD, Length: 4, Data: 1 0.0125090
    16:28:49,7979736 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 15 487 488, Length: 1 024, I/O Flags: Non-cached 0.0105658
    16:28:52,6292786 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 16 342 016, Length: 6 656, I/O Flags: Non-cached 0.0105257
    16:28:57,6187536 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 2 334 720, Length: 8 192, I/O Flags: Non-cached 0.0148829
    16:28:57,6187850 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 2 129 920, Length: 8 192, I/O Flags: Non-cached 0.0195626
    16:28:57,6194887 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 2 506 752, Length: 8 192, I/O Flags: Non-cached 0.0189445
    16:28:59,8426075 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 18 625 536, Length: 1 024, I/O Flags: Non-cached 0.0103498
    16:29:04,8752175 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 20 205 568, Length: 1 536, I/O Flags: Non-cached 0.0144070
    16:29:14,8855495 svchost.exe 824 FlushBuffersFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS  0.0288894
    16:29:18,7434768 winlogon.exe 396 NotifyChangeDirectory C:\WINDOWS SUCCESS Filter: FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_DIR_NAME, FILE_NOTIFY_CHANGE_SIZE, FILE_NOTIFY_CHANGE_LAST_WRITE, FILE_NOTIFY_CHANGE_CREATION, FILE_NOTIFY_CHANGE_STREAM_SIZE, FILE_NOTIFY_CHANGE_STREAM_WRITE 44.9947849
    16:29:19,8226098 sqlservr.exe 1368 WriteFile D:\MSSQL10.MSSQLSERVER\MSSQL\DATA\templog.ldf SUCCESS Offset: 47 935 488, Length: 61 440, I/O Flags: Non-cached 0.0110080
    16:29:24,9214382 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 26 351 616, Length: 1 024, I/O Flags: Non-cached 0.0103628
    16:29:30,8945441 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 28 198 912, Length: 1 536, I/O Flags: Non-cached 0.0131131
    16:29:31,7422025 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 28 448 768, Length: 6 144, I/O Flags: Non-cached 0.0116027
    16:29:34,6109304 svchost.exe 824 FlushBuffersFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr0.dat SUCCESS  0.0508699
    16:29:34,6109583 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr0.dat SUCCESS Offset: 0, Length: 65 536, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0167998
    16:29:34,6277746 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr0.dat SUCCESS Offset: 65 536, Length: 45 056, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0101582
    16:29:34,6477794 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr0.dat SUCCESS Offset: 65 536, Length: 45 056, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0120718
    16:29:35,7930952 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 29 712 896, Length: 1 024, I/O Flags: Non-cached 0.0109052
    16:29:45,7876200 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 32 794 112, Length: 1 536, I/O Flags: Non-cached 0.0107070
    16:29:45,8325279 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 32 801 792, Length: 1 024, I/O Flags: Non-cached 0.0108915
    16:29:45,8672016 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81_log.ldf SUCCESS Offset: 32 804 352, Length: 6 144, I/O Flags: Non-cached 0.0111364
    16:29:57,7476226 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 7 700 480, Length: 32 768, I/O Flags: Non-cached 0.0106380
    16:29:58,0292900 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 18 259 968, Length: 262 144, I/O Flags: Non-cached 0.0105871
    16:29:58,3554201 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 2 506 752, Length: 8 192, I/O Flags: Non-cached 0.0136997
    16:29:58,3554534 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 2 572 288, Length: 8 192, I/O Flags: Non-cached 0.0103173
    16:29:58,3554655 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 2 711 552, Length: 8 192, I/O Flags: Non-cached 0.0138469
    16:29:58,3554780 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 2 727 936, Length: 8 192, I/O Flags: Non-cached 0.0139403
    16:29:58,3555166 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 2 695 168, Length: 8 192, I/O Flags: Non-cached 0.0136996
    16:29:58,3555288 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 2 334 720, Length: 8 192, I/O Flags: Non-cached 0.0134938
    16:29:58,3555528 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 2 129 920, Length: 8 192, I/O Flags: Non-cached 0.0133740
    16:29:58,3555655 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 2 744 320, Length: 8 192, I/O Flags: Non-cached 0.0139152
    16:29:58,3555777 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 2 924 544, Length: 8 192, I/O Flags: Non-cached 0.0139916
    16:30:00,3232862 nncron.exe 2368 NotifyChangeDirectory C:\Program Files (x86)\nnCron SUCCESS Filter: FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_DIR_NAME 119.9838177
    16:30:00,9483817 svchost.exe 824 FlushBuffersFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS  0.0469997
    16:30:00,9484089 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS Offset: 0, Length: 65 536, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0155234
    16:30:00,9700263 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS Offset: 0, Length: 65 536, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0110031
    16:30:00,9810672 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS Offset: 65 536, Length: 45 056, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0132861
    16:30:03,7383052 winlogon.exe 396 NotifyChangeDirectory C:\WINDOWS SUCCESS Filter: FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_DIR_NAME, FILE_NOTIFY_CHANGE_SIZE, FILE_NOTIFY_CHANGE_LAST_WRITE, FILE_NOTIFY_CHANGE_CREATION, FILE_NOTIFY_CHANGE_STREAM_SIZE, FILE_NOTIFY_CHANGE_STREAM_WRITE 45.9946487
    16:30:40,5780490 svchost.exe 824 FlushBuffersFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr0.dat SUCCESS  0.0412851
    16:30:40,5780771 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr0.dat SUCCESS Offset: 0, Length: 65 536, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0121933
    16:30:40,5902893 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr0.dat SUCCESS Offset: 65 536, Length: 45 056, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0100624
    16:30:46,9099758 svchost.exe 824 FlushBuffersFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS  0.0524305
    16:30:46,9100010 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS Offset: 0, Length: 65 536, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0158467
    16:30:46,9258737 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS Offset: 65 536, Length: 45 056, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0116702
    16:30:46,9465601 svchost.exe 824 WriteFile C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader\qmgr1.dat SUCCESS Offset: 65 536, Length: 45 056, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O 0.0112629
    16:30:49,7330017 winlogon.exe 396 NotifyChangeDirectory C:\WINDOWS SUCCESS Filter: FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_DIR_NAME, FILE_NOTIFY_CHANGE_SIZE, FILE_NOTIFY_CHANGE_LAST_WRITE, FILE_NOTIFY_CHANGE_CREATION, FILE_NOTIFY_CHANGE_STREAM_SIZE, FILE_NOTIFY_CHANGE_STREAM_WRITE 45.9947910
    16:30:58,7688459 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 8 617 984, Length: 8 192, I/O Flags: Non-cached 0.0201452
    16:30:58,7690448 sqlservr.exe 1368 WriteFile D:\SQLBASE\gilev81.mdf SUCCESS Offset: 8 241 152, Length: 8 192, I/O Flags: Non-cached 0.0198662

    попытаюсь ещё раз целиком заснять на первом....

  • Могу ещё добавить, что время теста под SQL -- w2k8r2 плавает, максимум получился почти 21 попугай и каждый раз вылезает ошибка:

    {Обработка.TCP_1C_GILV.Форма.Форма(513)}: Ошибка при вызове метода контекста (ConnectAgent): Произошла исключительная ситуация (V81.COMConnector.1): descr=Сервер недоступен (Не отвечает, завершается аварийно или порт занят другим приложением) line=512 file=.\src\RemoteCreatorImpl.cpp
    {Обработка.TCP_1C_GILV.Форма.Форма(513)}: Ошибка при вызове метода контекста (ConnectAgent): Произошла исключительная ситуация (V81.COMConnector.1): descr=Сервер недоступен (Не отвечает, завершается аварийно или порт занят другим приложением) line=512 file=.\src\RemoteCreatorImpl.cpp
    {Обработка.TCP_1C_GILV.Форма.Форма(513)}: Ошибка при вызове метода контекста (ConnectAgent): Произошла исключительная ситуация (V81.COMConnector.1): descr=Сервер недоступен (Не отвечает, завершается аварийно или порт занят другим приложением) line=512 file=.\src\RemoteCreatorImpl.cpp
    {Обработка.TCP_1C_GILV.Форма.Форма(513)}: Ошибка при вызове метода контекста (ConnectAgent): Произошла исключительная ситуация (V81.COMConnector.1): descr=Сервер недоступен (Не отвечает, завершается аварийно или порт занят другим приложением) line=512 file=.\src\RemoteCreatorImpl.cpp

    и больше событий происходит, доходило до 5 млн за время теста (но выкидывает, так что за весь тест не скажу), а под w2k3r2 максимум за время теста около 2 млн

     

  • Могу ещё добавить, что время теста под SQL -- w2k8r2 плавает, максимум получился почти 21 попугай и каждый раз вылезает ошибка:

    {Обработка.TCP_1C_GILV.Форма.Форма(513)}: Ошибка при вызове метода контекста (ConnectAgent): Произошла исключительная ситуация (V81.COMConnector.1): descr=Сервер недоступен (Не отвечает, завершается аварийно или порт занят другим приложением) line=512 file=.\src\RemoteCreatorImpl.cpp
    {Обработка.TCP_1C_GILV.Форма.Форма(513)}: Ошибка при вызове метода контекста (ConnectAgent): Произошла исключительная ситуация (V81.COMConnector.1): descr=Сервер недоступен (Не отвечает, завершается аварийно или порт занят другим приложением) line=512 file=.\src\RemoteCreatorImpl.cpp
    {Обработка.TCP_1C_GILV.Форма.Форма(513)}: Ошибка при вызове метода контекста (ConnectAgent): Произошла исключительная ситуация (V81.COMConnector.1): descr=Сервер недоступен (Не отвечает, завершается аварийно или порт занят другим приложением) line=512 file=.\src\RemoteCreatorImpl.cpp
    {Обработка.TCP_1C_GILV.Форма.Форма(513)}: Ошибка при вызове метода контекста (ConnectAgent): Произошла исключительная ситуация (V81.COMConnector.1): descr=Сервер недоступен (Не отвечает, завершается аварийно или порт занят другим приложением) line=512 file=.\src\RemoteCreatorImpl.cpp

    и больше событий происходит, доходило до 5 млн за время теста (но выкидывает, так что за весь тест не скажу), а под w2k3r2 максимум за время теста около 2 млн

     

    1. эту ошибку можно игнорировать либо попросить кодера подправить слегка код, он видимо сервак 1С не видит по дефолтовым настройкам.

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

    особенно надо профиль C:\Users\Администратор перенсти на D и еще раз процмоном посмотреть

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

    4. зачем у вас на втором сервере ковыряется полнотекстовый поиск, выключите его в 1С (я это определил по C:\Program Files (x86)\1cv81\server\reg_1541\545773ad-32f6-4f79-9ad6-3a3c9baad74a\1Cv8FTxt\changes20100506000000.log )


    MCSE since 2004
  • 2. Ну тут всё объяснимо, у нас в RAID6 оба диска на сервере w2k8r2, т.к. осенью из-за сырых тогда дров при нагрузке вылетало по несколько дисков подряд и не успевало подхватить hotspare...

    3. Что касается кэширования, то оно не ставится из винды -- как я понял не поддерживается драйвером (но на самом контроллере есть батарейка и стоит режим write-back. По данным IOMeter производительность С (RAID6 14xSAS 10k 2,5') = приозводительности массива второго сервера (там с и d на общем RAID10 (6xSAS 15k 3,5')) а d (RAID6 6xIntel SHSSD 2,5') мощнее их где-то в четыре раза.

  • to Гилев Вячеслав:

    4. Что касается 2го сервера, там пока идет внедрение и я его особо не рулю, но я передал им ваше цу :)

    Вообще мы собираемся на одних из ближайших выходных переустановить D наконец-то на RAID10, тогда и учетку админа можно будет попробовать перенести...

    ещё три копейки:

    попробовал на выходных (при свободном сервере) погонять ещё тест, особого прироста не заметил, уровень 17 попугаев. Так же попробовал под 8.2, там получились "те же" 17-18 попугаев, так что проблема остаётся и под 8.2.... Хотя мой первоначальный тест показывал прирост на минуту до уровня 8.1 под win2k3 (т.е. видимо что-то выполняется быстрее, но не всё)

  • to Гилев Вячеслав:

    4. Что касается 2го сервера, там пока идет внедрение и я его особо не рулю, но я передал им ваше цу :)

    Вообще мы собираемся на одних из ближайших выходных переустановить D наконец-то на RAID10, тогда и учетку админа можно будет попробовать перенести...

    ещё три копейки:

    попробовал на выходных (при свободном сервере) погонять ещё тест, особого прироста не заметил, уровень 17 попугаев. Так же попробовал под 8.2, там получились "те же" 17-18 попугаев, так что проблема остаётся и под 8.2.... Хотя мой первоначальный тест показывал прирост на минуту до уровня 8.1 под win2k3 (т.е. видимо что-то выполняется быстрее, но не всё)


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

    если прироста под 8.2 нет, возможно дело просто не в сервере 1С, а субд

    ждем манипуляций с диском

     


    MCSE since 2004

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

    если прироста под 8.2 нет, возможно дело просто не в сервере 1С, а субд

    ждем манипуляций с диском

    Меня больше всего беспокоит, что аналогичные выводы были получены "независимым экспертом" на аналогичном железе но "у себя", причем связка с 2005 SQL дала лишь незначительный прирост. И у меня до сих пор нет никаких результатов теста на другом "железе", так что до сих пор нельзя на 100% исключить и проблемы с драйверами. 

    И очень расстроила аналогичная производительность под 8.2 -- предидущие мои тесты этой платформы давали надежду.

    Как же всё-таки вычислить проблемное место???

    Как я понимаю, замеры procmon дали два вывода:

    1. Операции сервер выполняет достаточно быстро, покрайней мере не хуже чем под win2k3 -- т.е. возможно проблема вообще не уперается в производительность???

    2. Очень много операций обмена между rphost и sqlservr -- может быть корень проблемы тут? Точно ли 1С умеет работать с мемори шаринг??? М.б. оно у нас по непонятной до сих пор причине отключено, но может быть включено??? У кого-нибудь под win2k8r2 вообще работает мемори шаринг SQL - 1С??? Если кто-нибудь уверен что работает напишите в эту ветку плиззз!!!! И заодно результаты теста Гилёва опубликуйте, пжлста!!!!


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

    если прироста под 8.2 нет, возможно дело просто не в сервере 1С, а субд

    ждем манипуляций с диском

    Меня больше всего беспокоит, что аналогичные выводы были получены "независимым экспертом" на аналогичном железе но "у себя", причем связка с 2005 SQL дала лишь незначительный прирост. И у меня до сих пор нет никаких результатов теста на другом "железе", так что до сих пор нельзя на 100% исключить и проблемы с драйверами. 

    И очень расстроила аналогичная производительность под 8.2 -- предидущие мои тесты этой платформы давали надежду.

    Как же всё-таки вычислить проблемное место???

    Как я понимаю, замеры procmon дали два вывода:

    1. Операции сервер выполняет достаточно быстро, покрайней мере не хуже чем под win2k3 -- т.е. возможно проблема вообще не уперается в производительность???

    2. Очень много операций обмена между rphost и sqlservr -- может быть корень проблемы тут? Точно ли 1С умеет работать с мемори шаринг??? М.б. оно у нас по непонятной до сих пор причине отключено, но может быть включено??? У кого-нибудь под win2k8r2 вообще работает мемори шаринг SQL - 1С??? Если кто-нибудь уверен что работает напишите в эту ветку плиззз!!!! И заодно результаты теста Гилёва опубликуйте, пжлста!!!!


    1. Ну давайте все таки дождемся оптимизации дисков и потом сделаем выводы, не будем спешить.

    2. Вообщето процмон как раз показывает замедления на дисках.

    3. Обмен в рамках одного сервера достачно быстрый должен быть, прочти все таки мой пост относительно настройки сервера

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

    Индекс: 56,82
     
    Компьютер:
    CPU: Core 2 Duo E8400 3GHz
    RAM: 2GB Dual Channel PC-6400 non ECC
    HDD: SATA-2 500Gb Seagate ST3500418AS, 7200rpm, кэш 16МБ
    Платформа: 8.1.15.14
    Архитектура: Файловая

    p.s. есть редирект сюда с http://partners.v8.1c.ru/forum/thread.jsp?id=797020

    MCSE since 2004
  • Ну доступа к партнерскому сайту 1С у меня нет, т.к. я обычный программер 1С

    Что касается приведённых результатов, это под win2k8r2 или под win2k3?

    1. Ну я и так опубликовал первый пост 24 февраля ;о)

    2. То что производительность упирается в диски не подтверждается тестами, например я только что попробовал кинуть SQL базу с вашим тестом на отдельный SAS диск и результат тот же 16,8 попугаев -- в файловом же варианте сразу просадка с 42 попугаев на 31. Т.е. в файловом варианте видна зависимость от скорости диска, а в SQL её нет

    3. Это уже "тонкая" настройка её попробую так же с переразбивкой массива провести. Но суть в том что сервер под win2k3 так же её не проходил! Это помоему не правильно один сервер мы подкручиваем изо всех сил, а второй "эталонный" остаётся как был, в него даже пользовательский ключик от алладина воткнут, а он всё равно показывает "хорошие" результаты... и производительность особо не падает.

  • Ну доступа к партнерскому сайту 1С у меня нет, т.к. я обычный программер 1С

    Что касается приведённых результатов, это под win2k8r2 или под win2k3?

    1. Ну я и так опубликовал первый пост 24 февраля ;о)

    2. То что производительность упирается в диски не подтверждается тестами, например я только что попробовал кинуть SQL базу с вашим тестом на отдельный SAS диск и результат тот же 16,8 попугаев -- в файловом же варианте сразу просадка с 42 попугаев на 31. Т.е. в файловом варианте видна зависимость от скорости диска, а в SQL её нет

    3. Это уже "тонкая" настройка её попробую так же с переразбивкой массива провести. Но суть в том что сервер под win2k3 так же её не проходил! Это помоему не правильно один сервер мы подкручиваем изо всех сил, а второй "эталонный" остаётся как был, в него даже пользовательский ключик от алладина воткнут, а он всё равно показывает "хорошие" результаты... и производительность особо не падает.


    Сравнивать файловый вариант с клиент-серверным некорректно. Но я сравнил 42 и 56 по файловому. Т.е. дисковая подсистема у Вас не самая быстрая. И дело возможно не в самих железках, а в драйверах и настройках кэшей ИМХО.

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

    Ждем результатов переразбивки массива. В нашем случаи ПРОБОВАТЬ куда важнее теории имхо.


    MCSE since 2004
  • и наконец, для сравнения простой компьютер за 15000 рублей вот что выдает
    Индекс: 56,82
     
    Компьютер:
    CPU: Core 2 Duo E8400 3GHz
    RAM: 2GB Dual Channel PC-6400 non ECC
    HDD: SATA-2 500Gb Seagate ST3500418AS, 7200rpm, кэш 16МБ
    Платформа: 8.1.15.14
    Архитектура: Файловая

    p.s. есть редирект сюда с http://partners.v8.1c.ru/forum/thread.jsp?id=797020

    MCSE since 2004

    Как я понял это производилось под XP -- на "моем старом" тесте схожие результаты тест на ноуте под XP без RAID выполняется примерно столько же как под Win2k3 с RAID. Помоему "ядро" ОС вносит свой вклад в производительность.

     

    > Кстати, пользовательский ключик (если он локальный) ускоряет работу, так как в этом случаи поиск по сети клиетом 1С уже не выполняется.

    Но если ключик сетевой то все в сети к нему обращаются и это в случае с 2008R2 просаживает сервер.... а в случае win2k3 нет имхо

     > Ждем результатов переразбивки массива. В нашем случаи ПРОБОВАТЬ куда важнее теории имхо.

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

  • Добрый день! Недавно начал заниматься подобными манипуляциями.

    В распоряжении имеется новый сервер HP DL380G6

    Intel Xeon QC 5504 2GHz 2 шт./12 GB RAM/6*10k SAS (RAID 10)

     

    На нем установлена Win2008R2EE + SQL 2008 Standard + 1C 8.1.15

    В виртуальную машину Hyper-V установлена Win2003 Standard x86 + SQL 2000 + 1C 8.1.15

    Запустив тест на реальной машине получен индекс 15.43 балла, на виртуальной машине - 27.78 балла.

    Файловый вариант на виртуальной машине дал 34.25 балла. Переход на файловый вариант не рассматриваем, тест проведен просто для сравнения.

    Планирую в течение блажайшего времени на виртуальной машине протестировать сочетание Win2003EE x64 + SQl 2005 + 1C 8.1.15

    Посоветуйте оптимальное сочетание ПО для обеспечения наивысшей производительности 1С или способы увеличения производительности на базе продуктов 2008 линейки.

    Заранее благодарен за ответы.

     

  • Хорошая мысль, Piw! У нас тоже вирт. машина под Win2k3. Правда SQL на ней не развернут, так что пока попробовал файловый вариант -- 18 попугаев; диск С (массив на котором находится вирт машина) почти так же как и отдельный SAS диск -- 33 попугая и диск D -- 40 попугаев. Если будет время в выхи, то попробую развернуть SQL и сделать и там замер, хотя теоретически он не должен превысить показатель для файлового варианта, но эти тесты выполнены под нагрузкой.... надо посмотреть, что даст тест на свободном сервере.

    • Изменено vkonst 12 мая 2010 г. 14:21
  • было бы еще интересно услышать, а что думают представители доблестного Microsoft

    it would be more interesting to hear what they think the representatives of the valorous Microsoft

    :)


    MCSE since 2004
  • Господа, в последних сообщениях говорится о неком тесте на производительность в 1с ("Запустив тест на реальной машине получен индекс 15.43 балла, на виртуальной машине - 27.78 балла.").

    Подскажите пожалуйста что-за тест такой и где его взять. Хотелось бы  у себя потестировать. У меня есть сейчас свободный сервер 2хЕ5405, мать X7DCL-3, 16Гб памяти, 4 sas в 10-м рейде (15к rpm).

    Стояла на нем win2003ee x32 на отдельном sas диске, 1с сервер и sql2008ee. База торговли 8Гб и 50 пользователей. Клиенты работают по сети и очень жалуются на производительность (долго проводит и долго откр). Сейчас после замены матери (сгорел контроллер) есть возможность погонять 1с под 2003 и 2008 серверами для сравнения производительности. Так же есть esxi на флехе. Хочу так же завиртуалить этот сервер и посмотреть насколько сильна будет деградация производительности.

    Заранее благодарю.

  • Господа, в последних сообщениях говорится о неком тесте на производительность в 1с ("Запустив тест на реальной машине получен индекс 15.43 балла, на виртуальной машине - 27.78 балла.").

    Подскажите пожалуйста что-за тест такой и где его взять. Хотелось бы  у себя потестировать. У меня есть сейчас свободный сервер 2хЕ5405, мать X7DCL-3, 16Гб памяти, 4 sas в 10-м рейде (15к rpm).

    Стояла на нем win2003ee x32 на отдельном sas диске, 1с сервер и sql2008ee. База торговли 8Гб и 50 пользователей. Клиенты работают по сети и очень жалуются на производительность (долго проводит и долго откр). Сейчас после замены матери (сгорел контроллер) есть возможность погонять 1с под 2003 и 2008 серверами для сравнения производительности. Так же есть esxi на флехе. Хочу так же завиртуалить этот сервер и посмотреть насколько сильна будет деградация производительности.

    Заранее благодарю.


    http://www.gilev.ru/1c/tpc/
    MCSE since 2004
  • Уважаемый Вячеслав!

    Хотелось бы услышать от Вас некоторые комментарии по поводу полученных мною индексов. Насколько я понял из ваших предыдущих постов, обычный ПК за 15тыс.руб. дает индекс в файловом варианте порядка 55 баллов.

    Странно, но вчера я провел несколько тестов в файловом варианте. Наибольшая производительность, которую мне удалось достичь - 44.64 балла на обычном ПК с 2 ГБ ОЗУ и С2D и WinXP pro sp2. При этом raid10 на SAS дисках под вин 2008 дал всего 35.71 балла.

    Хотелось бы услышать от Вас какие-нибудь пожелания по тому, в каком сочетании можно обеспечить максимальную производительность 1С?

  • у нас 1Cник проверял на i7-920 /12Gb/SSD x25Intel/
    OS 2003 x64 в файловом варианте показал 56

  • Уважаемый Вячеслав!

    Хотелось бы услышать от Вас некоторые комментарии по поводу полученных мною индексов. Насколько я понял из ваших предыдущих постов, обычный ПК за 15тыс.руб. дает индекс в файловом варианте порядка 55 баллов.

    Странно, но вчера я провел несколько тестов в файловом варианте. Наибольшая производительность, которую мне удалось достичь - 44.64 балла на обычном ПК с 2 ГБ ОЗУ и С2D и WinXP pro sp2. При этом raid10 на SAS дисках под вин 2008 дал всего 35.71 балла.

    Хотелось бы услышать от Вас какие-нибудь пожелания по тому, в каком сочетании можно обеспечить максимальную производительность 1С?


    Ну насчет обычный не знаю, знаю только что человек купил комп за 15 000 руб. , а это не одно и тоже )))

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

    А уж почему та или иная скорость, это уже много факторов. Но чаще всего проц и частота памяти, так как диски редко бывают отстойными. То есть скорость определяется самым узким местом. А этим местом в каждом конкретном случаи бывают разные участки.


    MCSE since 2004
  • Подводя для себя промежуточный итог пришел к выводу что:

    win2008 медленнее работает с 1с в файловом режиме чем win2003 (подтвердилось у меня и моих знакомых на виртуалках)

    win2008 + sql2008 также медленнее чем win2003 + sql2008 при работе с 1с.

    Хотелось бы услышать мнение тех, кто тестил связки win2003 + sql2005, win2003 + sql2000 для выбора наивысшей производительности под 1с 8.1

    Еще такой вопрос:

    нужно ли выравнивать раздел ntfs под виртуалкой? Ибо на физ. сервере это необходимо делать.

    http://msmvps.com/blogs/gladchenko/archive/2008/10/18/1651317.aspx

  • Ибо на физ. сервере это необходимо делать.

    http://msmvps.com/blogs/gladchenko/archive/2008/10/18/1651317.aspx

    На 2008 уже не нужно.
  • дык, это понятно. Я что-то раздумал ставить 2008 ибо производительность не устраивает. В связке с win7 в одной сети не пробовал, так как весь зоопарк на xp сидит, а обгрейдить дорого.

    Решил ставить win2003, а с sql еще думаю какой - 2000 или 2005.

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

  • "выравнивание" это дефрагментация?

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

  • "выравнивание" это дефрагментация?

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


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

    Что касается нас, то сервак переустановили, производительности не прибавилось ни грамму, хотя файловый тест на диске d (который мы преобразовали в RAID10) возрос до 48 попугаев. Хотя по IOmeter'у у нас теперь на нем 20 000 IOPS на database patern -- при RAID6 было 9000 IOPS на этой же настройке. SQL тест всё те же 17-18, а мой старый тест вообще пока ниже 5 мин не опускается...

     

  • Что-то после наших оптимизаций всё ещё хуже ... тест под SQL теперь показывает от 6.68 до 10.29 попугая. Приняли решение возвращаем в следующие выхи ОС из бэкапа... Причем производительность теста "плавно" просела в течении вчерашнего дня. Что влияет на R2 мне так и не понятно и будет ли производительность выше после возвращения из бэкапа тоже пока не ясно. Так же непонятно почему сразу после установки она была прежние 17 попугаев...
  • а не хотите просто юзать Win2003 + SQL 2005?

    MCSE since 2004
  • Вячеслав, вы рекомендуете связку Win2003 + SQL 2005?

    На Win2008 R2 + SQL 2008 вы не делали успешных внедрений?

    От себя могу добавить:

    На  Win2008 R2 + SQL 2008 имели 15 попугаев. Удалось повысить до примерно 17.5 попугаев при помощи отключения файла подкачки и переноса tempdb на отдельный логический диск с размером кластера 64КБ.

    PS информационные базы также разместили на разделы с размером кластера 64КБ

    Уважаемый Вячеслав! Прошу Вас прокомментировать возможные последствия от отключения файла подкачки, а также насколько оправдан размер кластера в 64КБ на разделх, в которых хранятся БД MSSQL?

  • To Гилёв Вячеслав:

    Хочется двигаться вперёд, а не оставаться на месте, нас впринцепе устраивала производительность до переустановки (т.е. до прошлых выходных). И пока что есть шанс вернуть её, загрузив сервер из бэкапа... Мы конечно рассматриваем вариант возвращения к 2003му и это собственно и была первая мысль, но "похороны" 2008R2 пока что затянулись...

    To Микрософт:

    Вот мне кажется что проблема в том, что под 2008R2 не включается мемори шаринг, а под 2003 он работает. А поскольку Платформа 1С и SQL в обоих случаях одинаковы, то моё ИМХО дело в какой-то элементарной настройке винды. Кто имеет глубокое понимание общения через мемори шаринг????? Ау.... отзовитесь наконец. Не верю, что таких спецов нет. Ведь, как я понял, есть люди у кого под Win2k8R2 1С работает нормально, только они не хотят делиться секретом... В конце концов мы ведь на форуме микрософт, форуме разработчика всего этого дела и у нас конкретная проблема и закуплен даже софтваре ашшуранс, а я с февраля не могу получить решения моей проблемы -- неужели колокольчик у моего поста это всё чем эта поддержка ограничивается???

  • Провел 2 дня тестируя разные связки на одном и том же сервере, переустанавливая каждый раз все с форматированием диска С (единственного диска у сервера)

    вот результаты:
           СУБД Значение

    MS Windows Server 2003 Std SP2 X86/MS SQL 2005 Std X86, RAID1 on System disk 15,77

    MS Windows Server 2008 Ent SP2 X86/MS SQL 2005 Std X86, RAID1 on System disk 16,50

    MS Windows Server 2008R2 Ent X64/MS SQL 2005 Std X86, RAID1 on System disk 16,03

    MS Windows Server 2008R2 Ent X64/MS SQL 2008R2 Ent X64, RAID1 on System disk 17,24   


    попугаи замерялись с помощью
    Простой тест интенсивной записи для платформы 1С:Предприятие (1.0.4)
    Гилёв Вячеслав Валерьевич

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

    Никакие компоненты/программы/роли кроме драйверов и SQL сервера не ставились

    В файловом варианте действительно, 2003 - самая быстрая с отрывом.
           СУБД Значение  

    File 2003 51,02  

    File 2008 45,45  

    File 2008 R2 44,64  

  • В связи с вышеуказанными результатами тестирования, стоит рассмотреть файлового варианта 1С.

    Имеем базу на Win2003 32bit+SQL 2000 SP3. Размер базы 2.5 Гб, 25 пользователей. Стандартная бухгалтерия. Посоветуйте, есть ли смысл пробовать переход на файловый вариант?

  • ни в коем случаи, на 25 пользователях не загруженность железа рулит, а количество блокировок

    попробовать то вы конечно сможете, но любое перепроведение задним числом вам повесит базу


    MCSE since 2004
  •        СУБД Значение

    MS Windows Server 2003 Std SP2 X86/MS SQL 2005 Std X86, RAID1 on System disk 15,77

    MS Windows Server 2008 Ent SP2 X86/MS SQL 2005 Std X86, RAID1 on System disk 16,50

    MS Windows Server 2008R2 Ent X64/MS SQL 2005 Std X86, RAID1 on System disk 16,03

    MS Windows Server 2008R2 Ent X64/MS SQL 2008R2 Ent X64, RAID1 on System disk 17,24   

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

    Но самое главное -- вы смотрели через ProcMon есть ли у вас обмен по сети между sqlservr и rphost?

    У нас кстати вернулось к 15 попугаям (один раз было 15,02 один раз 14,79) -- sql почему-то начал наконец-то использовать свободную память под кэш + мы доступность процов ему поставили через ядро, а не кучей.

    Как я понял из эксперемента, пока SQL количеством памяти не задушишь он кэширование не включает, а с ним если есть свободная память производительность выше. А всю прошлую неделю наш SQL как-то особо памяти не жрал и я соответственно её ему не сгонял. Вообще кто-нибудь вкурсе это можно автоматизировать: При достижении MS SQL некотрого объема памяти он принудительно выгружает всё до нижнего порога и начинает заново заполнять память? Как я понимаю в эти моменты (роста) производительность максимальна.

  • только что прогнал тесты на win2008r2. Тестировал следующие sql сервера - 2005, 2005_SP3, 2008, 2008_SP1, 2008R2 все enterprise edition. Железо X7DCL-3, 2*E5405, 2Гб озу, система на 1 sas диске, базы на четырех дисках в десятке. Диск с базами размер страйпа и размер кластера 64Кб. Ключ сервера предприятия воткнут напрямую, лицензии получает по сети с другого компа.

    сервер - балы
    2005 - 21.65
    2005sp3 - 23.36
    2008 - 10.68
    2008sp1 - 10.54
    2008r2 - 10.60

    Судя по результатам 1с не оптимизирован с sql выше 2005. Тесты прогонялись по несколько раз и бралось среднее значение.

    Хочу еще попробовать на sql 2000, но у меня только 32-битная версия. А она боюсь не поставится на win2008r2

    ЗЫ. на другом сервачке стоит win2003r2 и sql2008 - результаты аналогичные - порядка 10 балов.

    PS. протестировал еще sql 2000sp4 правда 32-бит. Все верхние скули были 64-битными.

    2000sp4 - 25.13

    • Изменено Bankir82 24 мая 2010 г. 13:07
  • А через ProcMonitor смотрели во время тестов идут ли сетевые обмены rphost -- sqlservr?

  • procmon-ом не смотрел, но в "Монитор ресурсов" на вкладке "Сеть" rphost показывает Отправлено примерно 240кб постоянно, а rmngr Получено тоже значение.

    sqlsrv там нет в списке. См файл скриншот

    Получается - а черт его знает, что получается. Я в этом не сильно рублю. Вам делать выводы :)

    И тесты на 2000-2005 гораздо быстрее проходят, наверное раза в 2
  • Это у вас при 2008 SQL? Вы какиенибудь специальные настройки делали?

    У нас даже если запретить всё кроме общей памяти, rphost продолжает обращаться к сети, но уже не к sqlservr, т.е. возможно мемори шаринг начинает работать, но на время тестов это никак не играет. Так что работает ли мемори шаринг непонятно.

    to all: может ли быть проблема в том что у нас куплен SQL 2008 Standart, а не Enterprise???

  • Вячеслав, вы рекомендуете связку Win2003 + SQL 2005?

    На Win2008 R2 + SQL 2008 вы не делали успешных внедрений?

    От себя могу добавить:

    На  Win2008 R2 + SQL 2008 имели 15 попугаев. Удалось повысить до примерно 17.5 попугаев при помощи отключения файла подкачки и переноса tempdb на отдельный логический диск с размером кластера 64КБ.

    PS информационные базы также разместили на разделы с размером кластера 64КБ

    Уважаемый Вячеслав! Прошу Вас прокомментировать возможные последствия от отключения файла подкачки, а также насколько оправдан размер кластера в 64КБ на разделх, в которых хранятся БД MSSQL?


    На текущий момент осталось много вопросов. Поэтому я запланировал через месяц нагрузочное тестирование, чтобы окончательно разобраться с этим вопросом. Для этого будет написан специальный тест. Правда замерять я буду 8.2.11.

    MCSE since 2004
  • Ребята, позвольте вклиниться в ваше обсуждение проблемы. Посмотрите пожалуйста вот это:

    http://social.technet.microsoft.com/Forums/ru-RU/wsbsru/thread/2ed3d949-f379-46f7-a307-000ea88ab2ef

    Я не утверждаю, что вам поможет, но чем чёрт не шутит, я себе в своё время весь мозг закипятил когда искал проблему долгого запуска Windows Small Business Server 2008.

    И в придачу: не хочу хаять 1С но их продукт для бюджетных учреждений полное Г... или Х..., кому как будет угодно. Просто сравнивал с тремя другими конкурентными продуктами. Может для не бюджетных учреждений у них и нормально, а здесь... Поклонники 1С пожалуйста не обижайтесь :)

  • предложение исследовать влияние IPv6 понятно

    причем тут бюджетные учреждения и как они влияют на свзяки windows server + sql не понятно


    MCSE since 2004
  • причем тут бюджетные учреждения и как они влияют на свзяки windows server + sql не понятно
    MCSE since 2004

    Я наверное зря это сказал :) Дело в том, что 1С Бюджетные учреждения собственно говоря не является полноценным "SQL Server" вариантом. Даже на достаточно малом размере базы были достаточно существенные проблемы с производительностью.
  • предложение исследовать влияние IPv6 понятно


    MCSE since 2004


    Если я правильно понял эту фразу, то никто ещё не рассматривал предложенный мной вариант? Если так, то интересно будет узнать результат!

    И кстати попутно: если кто будет проверять этот вариант, то сразу хочу рекомендовать использовать автоматически назначаемый IP-адрес. Без знаний IPv6 поверьте на слово это ВАЖНО!

  • Не очень понимаю как может быть связана 1С+SQL в пределах одного сервера с настройками IPv4,v6, но тем не менее попробовал.

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

  • пишем тест http://groups.google.com/group/tpc-1c?hl=ru , который позволит замерить отдельно производительность сервера 1С от связки с субд, тогда будет окончательно понятно, где собака зарыта
    MCSE since 2004
  • Субъективно включение IPv6, особо производительности не добавило, м.б. 1 пункт, но и хуже не стало -- вобщем в пределах погрешности.

  • Кто-нибудь из участников дискуссии устанавливал на сервере с 1С роль "Сервер приложений"?

    Интересен вопрос прибавки производительности при активации данной роли.

  • Провел ряд дополнительных экспериментов. Включал по очереди по одному из протоколов. Как это влияет на производительность не очень понял (была просадка при включенной только общей памяти -- tcp/ip и каналы показали себя одинаково) Основной вывод заметил уменьшение сетевой активности когда включена только общая память (3% всех событий регистрируемых ProcMon сетевые) При tcp/ip до 30% сетевая активность. После эксперимента включил обратно все три.

    Сейчас в рабочее время (все три протокола включены) тест показывает 22.83 попугая (рекорд пока что 24.27). Мой старый тест -- 3мин 5сек (это новый рекорд :о) Кэш в памяти 11Гб SQL держит 19Гб и свободно 2,5Гб %сетевой активности 2-3%

    + есть странный обмен на serverb: 

    10:54:48,5301879 rmngr.exe 2668 TCP Receive serverr2.none.local:1660 -> serverr2.none.local:49176 SUCCESS Length: 5, seqnum: 0, connid: 0 0.0000000
    10:54:48,5302074 rmngr.exe 2928 TCP Receive serverr2.none.local:1760 -> serverr2.none.local:49182 SUCCESS Length: 5, seqnum: 0, connid: 0 0.0000000
    10:54:48,5302359 rmngr.exe 2668 TCP Send serverr2.none.local:49176 -> serverr2.none.local:1660 SUCCESS Length: 5, startime: 969185, endtime: 969185, seqnum: 0, connid: 0 0.0000000
    10:54:48,5302485 rmngr.exe 2928 TCP Send serverr2.none.local:49182 -> serverr2.none.local:1760 SUCCESS Length: 5, startime: 969185, endtime: 969185, seqnum: 0, connid: 0 0.0000000
    10:54:48,5303714 rmngr.exe 2668 TCP Receive serverr2.none.local:1641 -> serverr2.none.local:49170 SUCCESS Length: 247, seqnum: 0, connid: 0 0.0000000
    10:54:48,5307354 rmngr.exe 2668 TCP Send serverr2.none.local:1641 -> serverr2.none.local:49170 SUCCESS Length: 421, startime: 969185, endtime: 969185, seqnum: 0, connid: 0 0.0000000
    10:54:48,5309255 rmngr.exe 2668 TCP Receive serverr2.none.local:1641 -> serverr2.none.local:49170 SUCCESS Length: 247, seqnum: 0, connid: 0 0.0000000
    10:54:48,5311478 rmngr.exe 2668 TCP Send serverr2.none.local:1641 -> serverr2.none.local:49170 SUCCESS Length: 424, startime: 969185, endtime: 969185, seqnum: 0, connid: 0 0.0000000
    10:54:48,5334264 rphost.exe 1532 TCP Send serverr2.none.local:61422 -> serverb:ms-sql-s SUCCESS Length: 258, startime: 969185, endtime: 969185, seqnum: 0, connid: 0 0.0000000
    10:54:48,5334532 rphost.exe 1532 TCP Receive serverr2.none.local:61422 -> serverb:ms-sql-s SUCCESS Length: 440, seqnum: 0, connid: 0 0.0000000
    10:54:48,5352361 rphost.exe 1532 TCP Send serverr2.none.local:61422 -> serverb:ms-sql-s SUCCESS Length: 254, startime: 969185, endtime: 969185, seqnum: 0, connid: 0 0.0000000
    10:54:48,5353132 rphost.exe 1532 TCP Receive serverr2.none.local:61422 -> serverb:ms-sql-s SUCCESS Length: 2771, seqnum: 0, connid: 0 0.0000000
    10:54:48,5374378 rphost.exe 1532 TCP Send serverr2.none.local:61422 -> serverb:ms-sql-s SUCCESS Length: 258, startime: 969185, endtime: 969185, seqnum: 0, connid: 0 0.0000000
    10:54:48,5374643 rphost.exe 1532 TCP Receive serverr2.none.local:61422 -> serverb:ms-sql-s SUCCESS Length: 440, seqnum: 0, connid: 0 0.0000000
    10:54:48,5392253 rphost.exe 1532 TCP Send serverr2.none.local:61422 -> serverb:ms-sql-s SUCCESS Length: 254, startime: 969185, endtime: 969185, seqnum: 0, connid: 0 0.0000000
    10:54:48,5393044 rphost.exe 1532 TCP Receive serverr2.none.local:61422 -> serverb:ms-sql-s SUCCESS Length: 3641, seqnum: 0, connid: 0 0.0000000
    10:54:48,5416539 rphost.exe 1532 TCP Send serverr2.none.local:61422 -> serverb:ms-sql-s SUCCESS Length: 258, startime: 969185, endtime: 969185, seqnum: 0, connid: 0 0.0000000
    10:54:48,5416793 rphost.exe 1532 TCP Receive serverr2.none.local:61422 -> serverb:ms-sql-s SUCCESS Length: 440, seqnum: 0, connid: 0 0.0000000
    10:54:48,5435335 rphost.exe 1532 TCP Send serverr2.none.local:61422 -> serverb:ms-sql-s SUCCESS Length: 254, startime: 969185, endtime: 969185, seqnum: 0, connid: 0 0.0000000
    10:54:48,5435585 rphost.exe 1532 TCP Receive serverr2.none.local:61422 -> serverb:ms-sql-s SUCCESS Length: 1760, seqnum: 0, connid: 0 0.0000000
    10:54:48,5456512 rphost.exe 1532 TCP Send serverr2.none.local:61422 -> serverb:ms-sql-s SUCCESS Length: 258, startime: 969185, endtime: 969185, seqnum: 0, connid: 0 0.0000000
    10:54:48,5456769 rphost.exe 1532 TCP Receive serverr2.none.local:61422 -> serverb:ms-sql-s SUCCESS Length: 440, seqnum: 0, connid: 0 0.0000000

    11 июня 2010 г. 7:39
  • Кажется ожила ветка в разделе SQL2008: http://social.technet.microsoft.com/Forums/ru-RU/sqlru/thread/53a19cef-2242-4f54-9b80-683e98f23eb3

    Вкратце:

    1. У serverb оказалось две разновидности serverb и serverb.none.local

    2. У меня не был уствновлен CU7 на sql2008std SP1 -- установил, жду будет ли повышение / понижение производительности...

    20 июня 2010 г. 18:19
  • Итак, вопрос с serverb закрыт -- это оказался глюк dns. На самом деле под этой маской скрывался вполне безобидный buhserver и отношения к производительности он видимо никакого не имеет. Это означает, что через tcp/ip sqlserv на нашем сервере не работает и видимо пока что все подозрения с него можно снять. Т.е. версия проблемы с ole db драйвером видимо не состоятельна. Может ли это быть обмен внутри процессов 1С, например rphost с rmngr? Сейчас на сервере win2k3 у наc включен обмен только через tcp/ip. Процент сетевой активности зашкаливает за 40% по данным procmon (на сервере win2k8r2 сейчас в районе 15%) но тест под win2k3 всё равно 26,04 против 9,38 на win2k8r2. Т.е. может быть сеть вообще не причем? Я опять в тупике...
    21 июня 2010 г. 10:47
  • Ура! Наконец-то производительность на уровне! По тесту Гилева 26 - 28 (хотя сразу после перезагрузки выдало только 13) Рекорд для старого теста теперь 2мин 26 сек.

  • т.е.  последняя рекомендация улучшила результат  и вопрос закрыт?
    MCSE since 2004
    10 июля 2010 г. 17:10
  • Да, результат улучшился, но производительность всё равно слишком сильно плавает. Например, как я уже писал после одной из перезагрузок было 13. Сейчас три раза подряд 23 с копейками, хотя сервер ничем не нагружен. А в пятницу, в рабочее время было 28... И так же следует учесть, что на соседнем сервере под Win2k3 сейчас производительность 33, а максимум, аж 37! А он слабже и по процам и по дисковой системе, да и такого "плаванья" в результатах на нем не наблюдается...
    10 июля 2010 г. 21:26
  • Добрый день Господа!

    С подобной проблемой боролся один мой знакомый. Победил.

    Пробывали разные варианты решения данной проблемы но решение было совсем рядом, не без вашей помощи.

    связка: 1с 8.1 (8.1.15.14) + Server 2008r2 + SQL 2008 Sp2

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

    2. В самой винде также.

    3. в файрволл была добавлена программа разрешенная для запуска 1С.

    4. Был произведен апдей с SQL 2008 на SQL 2008r2

    5. В 1с сервере прописывайте не имя сервера а его IP

    Итоги: производительность повысылась на типовой конфигурации бухгалтерии на 20%

    Надеюсь вам это тоже поможет.

    24 ноября 2010 г. 17:01
  • Доброго всем чего нибудь.

    Прочитал тему, наставил все галочки, в понедельник теперь по IP попробуем соединение прописать.

    Но есть проблема которой у вас похоже нет:

    Платформа Windows 2008 EE R2 x64, SQL 2008 R2 x64 (высажено на ESX хост в кластере VmWare Sphere), логи и TEMP базы на отдельном логическом диске, диски с базами в режиме paravirtual.

    На сервере поднял 2 сервера приложений 1с - 8.1 32bи 8.2 32b.

    8.2 загрузил в себя выгрузку базы (раньше крутилась на Postgres) и судя по всему нормально работает.

    8.1 загрузку базы делает (раньше крутилась на Postgres), но при попытке эту же базу выгрузить, ругается на контрольные суммы при запросе некоторых страниц в файле базы sql.

    Никто не сталкивался с таким?  Уже и компоненты в SQL поотключал и переставлял, и с бубном прыгал - ситуация та же. В понедельник попробую поднять рядом SQL2005 для пробы.

    18 декабря 2010 г. 15:42
  • 8.1 загрузку базы делает (раньше крутилась на Postgres), но при попытке эту же базу выгрузить, ругается на контрольные суммы при запросе некоторых страниц в файле базы sql.
    а integrity-check уже загруженной в SQL базы проходит?
    19 декабря 2010 г. 9:02
  • Средствами 1С или SQL? 
    19 декабря 2010 г. 20:23
  • Средствами 1С или SQL? 
    минимум - SQL...
    20 декабря 2010 г. 9:07
  • Эх опять 1С! Ну у меня все в прошлом ....щас все летает ! А были и независимые эксперты... куча литературы и прочего .... В общем 1С признала свой косяк Ставьте последний релиз 8.2 и все будет летать как на 7ке.

    Грусно как-то... это единственное оптимистичное высказывание здесь... но на практике...

    На 1Cv8 мы только переходим, тестировать пока не на чем. Поначалу было решено переходить на Win2008R2 + SQL2008 + 1Cv8.2, используя в основном веб и тонкий клиент. Теперь получили под это дело новый сервер, начали тестировать с Win2003х64 (больше для очистки совести), использовали вроде как универсальный тест для 1Cv8.1/8.2, который создает кучу документов в базе, проводить... не вникал в его подробности. Так вот, у Win2003х64 + 1Cv8.1 показатели оказались раза в 1,5 выше (не 2-3 попугая!), чем у Win2008R2 + 1Cv8.2 (SQL2005/2008 примерно одинаковые показатели дают во всех вариантах). Я в шоке, но приняли решение пока работать по старинке: в терминале на Win2003х64 + 1Cv8.1, зная, что 1Cv8.1 с 2011 снимается с поддержки... но цифры упрямая вещь!
    Может все дело в тесте, который вроде, как и универсальный, но изначально заточен под 1Cv8.1, а она - прежде всего под Win2003? Новые редакции конфигураций (УПП1.3, УТ11...) вообще не предназначены для 1Cv8.1, надо бы и тест аналогичный... Может есть у кого под 1Cv8.2, не поделитесь?

    30 декабря 2010 г. 1:01
  • доброго времени суток!

    кто-нибудь решил проблему?

  • доброго дня. данную проблему частично решили установкой SQL Evaluation 2000 (до этого стоял 2008 r2). производительность подросла на 10-15 попугаев. показатели стабильны. ws2008r2x64 1c 8.1

    17 июня 2011 г. 4:14
  • Уважаемые коллеги, а вышедшие SP1 для WS2008R2 и SP1 для SQL2008R2 повлияли хоть как-то на столь печальные показатели производительности или нет, - никто не проверял?

    Аппаратно новый сервер под 1С готов к работе, а вот что делать с программной частью - из-за этой темы теперь не могу определиться, хотя уже настроился и планировал использовать связку "WS2008R2SP1/x64 + SQL2008R2SP1/x64 + 1C82/x64". Однако ж, по ходу, придётся начинать с "WS2003SP2/x64 + SQL2005SP4/x64 + 1C82/x64" (на старом сервере эксплуатируется именно эта связка).

    • Изменено rlan 15 октября 2011 г. 6:59 update
    15 октября 2011 г. 6:57
  • Коллеги, хочу поделится с Вами опытом полученным недавно, после которого и нашел данный форму ;-).

    Совсем в подробности вдаваться не буду опишу лишь суть.

    Купили сервер HP DL 160, 48Gb памяти, RAID 1 из дисков SATA 2. Решили весь домен привести к общему знаменателю 2008 R2.

    В итоге с Windows server 2003 + SQL 2000 с естественно худшим железом чем у нового сервера перенесли базу размером 23Gb на новый сервер с Windows server 2008 R2 + SQL server 2008 R2. 

    Тесты не проводили но в понедельник пользователи стали визжать что все тормозит. По их заявлением скорость работы в базе упала в 3 - 4 раза. Неделю им пришлось помучится - к следующему понедельнику решили вернуть базу на старый сервер с Windows 2003 но там поставили SQL 2008. База работать стала чуть быстрее но все равно пользователи жалуется.

    Как итог планируем купить SAS контроллер и диски, переставим на новом сервере систему (пока мучаюсь WINSERV 2008 64 bit или все же 2003 64 bit) и уже 100% будем 1с ставить на SQL 2003 64 bit если найдем SQL 2000 64 bit будем ставить его.


    24 июля 2012 г. 13:06
  • 1) Ставьте счетчики, а не слушайте пользователей.

    2) Проводите регламентные операции с базой, в вашем случае я бы рекомендовал раз в неделю - две , судя по объему.

    Лог у базы здоровый? Его пробовали оптимизировать?

    24 июля 2012 г. 18:21
  • Вам не удастся поставить MS SQL Server 2000 64-bit на MS Windows Server 2003 Enterprise 64-bit Edition. Для SQL 2000 64-bit нужен Windows Server 2003 for Itanium-based Systems, и соответственно, сервер на итаниуме, а не x64. 

    24 июля 2012 г. 18:43