Новый сервер:
CPU = Два AMD Opteron 6380 2,8GHz (в Windows - 32 ядра).
Mem = 32 Gb
HDD = 4 SAS  дисков,  RAID  10 ? на  контроллере  LSI MR9271-4i, 1Gb Кэша.
ОС:  Windows  Server  2003R2 sp2 Datacenter Edition 32 бит.  

Старый  сервер:
CPU = Два Intel Xeon 5030 2,66ГГц (в Windows - 8 ядер).
Mem = 16 Gb
HDD = Два ultra wide SCSI в зеркале.
ОС:  Windows  Server  2003R2 sp2 Enterprise Edition 32бит.

1С: 7.7, релиз 25, dbf.
Размер базы: 4 Gb.
Пользователей: 56.
Вход: Терминальный.

ПРОБЛЕММА:
На  старом  сервере пользователи работают с базой. Хоть и медленно, но уверенно.
На новом:
1 user работает в 3 раза быстрее.
56 users - Регулярное "ожидание блокировки" работь хуже чем на старом.
при том же дистрибутиве 1С и той же базе.

В 1С используется:
1CPP.dll (2.0.2.1) для раскраски.
Admin1C.dll (1.0.0.0) для таб Пользователей
ROM-Mail.dll (1.3.1.0)
Terminal Sleep от Romix

ВОПРОСы:
Существуют  ли какие-то особенности Datacenter Edition, плохо согласующиеся с 1С 7.7 или доп. DLL?
Или есть особые настройки сервера?..
Посоветуйте что-то, пока меня не заставили выкупить себе Новый сервер (8000$).

(99) NS. Пока все ушли ставил в win галочку "повышенная производительность" и снимал. Результат на одном и том же запросе не поменялся. 1-й вход 140 с, второй (от другого пользователя 1С, но тот же пользователь Win) 120 c.
Запрос 29 раз обращается к таблице РН, спр Клиентов, рег Затрат. Для стравнения результатов 29-и менеджеров по продаже за один и тот же период.

(116) Поддерживаю

(111) Будем пробовать.

(111) Спасибо, попробуем, но это развитие ускорения, а ведь на старом RAM диска нет.

(117) это же кеширование записи, а не чтения.

(121) Значит это отразится на работе, но не на отчетах?

(122) У тебя же проблема с блокировкой. А она возникает во время проведения. При проведении записываются движения документа, и их запись ускорится. Так же ускорится создание временных файлов, но это как указано выше можно сделать при помощи темпов на RAM-диске.

Вопрос еще какая батарейка. Рам, Флэш, или РАМ + Флэш.

(123) "и их запись ускорится", а чтение с кэша будет?

(124) Извини даже вопрос не понял. Но знаю что Физически есть батарейка. При кождом старте отчитывается о своем заряде. Пока 100%. (Серваку 2 месяца от покупки)

(125) Чтение с Кэша в винде есть всегда, оно в параметрах не отключается, отключается только при сетевом доступе.

(126) Речь про кеш на контролере.

(128) Да

(129) Что да? Там Флеш, ОЗУ, или то и другое?
Гиг там ОЗУ? Если Гиг ОЗУ, то рисковать и включать отложенную запись (максимальное ускорение) нет смысла, достаточно сквозной, простого кеширования записи.

Если Гиг флеша, то отложенная запись даст ускорение, но немного повысит риски смерти базы после сбоя.

(127) База на D:\ в IG_trd
стандартные "D$", "Стандартный общий ресурс", имеют значение?

(130) Таких точностей я пока не знаю, но узнаю.

(131) Имеет сам факт подключения сетевых, а не локальных в терминале пользователей.

(131) При подключении второго (и последующего) пользователя к сетевой (не SQL!) базе 1С резко возрастает "торможение" 1С:Предприятие 7.7 при работе по сети. Причем, при отключении второго пользователя торможение сохраняется, до перезагрузки сервера. Это особенность Windows NT/2000 - система не умеет кэшировать (сохранять в памяти) файлы при совместной многопользовательской работе по сети. Проблема описана в статье на диске ИТС (от фирмы 1С).
http://kb.mista.ru/article.php?id=136
Это актуально и при работе в терминале. Если к устройству начнут подключаться сетевые пользователи, виндовое кеширование отключится.

Если убрать шары, то можно себя от этой неприятности гарантированно обезопасить.

(134) "Если к устройству начнут подключаться сетевые пользователи" К диску D: нет. А другие шары на других дисках имеют значение?
На старом срв есть и шары к другим папкам и т. д. Но ведь работает...

(136) Не знаю.

Уточняю, пока вспомнил, остальные шары (на старом срв) физически на других дисках...

(138) Всё равно не знаю. Варианта три
1. Кеш отключается на физическом устройстве (Raid)
2. Кеш отключается на логическом устройстве - диске.
3. Кеш отключается для папок/файлов к которым произошло обращение по сети.

(139) бум гуглить...

(139) По памяти, думаю к физ дивку или к объедененному диску в RAID. Во всяком случае на старом срв есть RAID и доп диски, они то и разшарены и на старом срв таки работают в 4-х базах 56 юзеров

(139) Как минимум есть вариант проверить экспериментально. Отключим все шары с Raid миассива и посмотрим...

(0) Я бы не стал 56 пользователей садить в DBF базу. Я бы перевел базу на SQL. Закупил три сервера: один под SQL, два под RDP.

Два под RDP исходя из следующих соображений:
1. Есть возможность "разруливать" нагрузку. В любом случае среди пользователей есть операторы, задача которых быстро внести информацию, есть пользователи, которые занимаются анализами: формируют отчеты пачками. Можно будет разрулить: операторов отдельно, аналитиков отдельно.

2. Надежность. Допустим у нас один сервер. И допустим он сломался. Вся фирма сидит и нервно курит. В случае двух серваков, при поломке одного из них, можно всех пользователей завести на один сервак. Да, нагрузка возрастет, но работать можно будет. В случае, если падает SQL - разворачиваем его на одном из оставшихся серваков.

3. Обслуживание серверов. В случае нескольких серверов есть возможность поочередного обслуживания.

4. Теперь почему SQL. Надежнее. Нет проблем с ожиданием, когда же база наконец-то переиндексируется. Плюс, появляются дополнительные "плюшки".

+143 Можно задействовать старый сервер. Если как есть - то под RDP. Можно чуток с дисковой покрутить и под SQL настроить.

"Посоветуйте что-то, пока меня не заставили выкупить себе Новый сервер (8000$)." С чего это? Ты закупал или админ?

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

(0) >>>На новом:
1 user работает в 3 раза быстрее.

Ну да, ну да попробуй начать работать 10-тью или 20-тью пользователями :))))


Наивный

(146) Да ему нечего не поможет :)

(93) конечно виноват. Ну админ ясно - тупой, но вы-то? Должны понимать, что серверы практически одинаковые. На старом естественно 7.7 будет работать в 2 раза быстрее, она писалась 15 лет назад.

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

(150) + 100500 такая же мысля пришла. Базу сложить на быстрый независимый носитель. А так правильно заметили узкое место 77 не ликвидируется увеличением ядер.
P.S. Эмоции - серваки на ксеннонах - всегда меня радовали...

(143) Если не ошибаюсь.
Сейчас проблема 7-ку до скуля докупить.
Да и сам скуль вроде только 2005 на клюшках возможен, а его не купить.

(152) Купит  7.7 для скл не проблема, 7.7 работает даже на скл 2014.

(153) обозначь, кто продает  с реганкетой и лицензионным договором? купить на вторичном рынке скульный движок - вообщем можно, но вот есть ли у тебя при этом сублицензионный договора и реганкета?

(154) Прайс на сайте 1С не является публичной оффертой?
http://www.1c.ru/rus/partners/goodlist.jsp?parentKod=1CV77&kod=1CV77

(153) Насчет скл 2014 меня терзают смутные сомнения. Штатно это скл 2000 , с более поздними подружить, это не совсем штатные методы.

"8000$" - как-то дорого для озвученной конфиги?? не?
Переписать конфу (узкие места) на прямые запросы не предлагать? - тогда при таком раскладе
"Размер базы: 4 Gb.
Пользователей: 56.
Вход: Терминальный. " - достаточно будет и половины старого сервака, чтобы забыть про блокировки

а вообще - обсуждалось уже 100500 раз все это: дело не в железе, а в кривом коде конфы.

(157) Вопрос то не в том как оптимизировать код
ВОПРОС: ПОЧЕМУ НА НОВОМ ЖЕЛЕЗЕ ОДНА И ТА ЖЕ БАЗА, НА ТОМ ЖЕ ПО РАБОТАЕТ ХУЖЕ, ЧЕМ НА СТАРОМ?

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

Strip Size = 256 KB
VD has Emulated PD = No
Span Depth = 2
Number of Drives Per Span = 2
Write Cache(initial setting) = WriteThrough
Disk Cache Policy = Enabled
Encryption = None
Data Protection = Disabled
Active Operations = None
Exposed to OS = Yes
Creation Date = 15-06-2013
Creation Time = 04:41:31 PM
Emulation type = None

Сегодняшний тест прошел на ура,
но тест длился 20 мин.
Планируем полный тест, тогда отпишусь...

может кто скажет новые замечания по настройкам контролера?..

Сегодня за 20 мин. работали отчеты как за час на текущем (старом) сервере. При этом блокировок небыло даже без Terminal Sleep

(152) Что за проблема. Все юзают не лицензионное ПО. Поставлю любое, а пока читай пост № 158

(146) От подключения по локале отказались более чем 10лет тому

(137) Еще раз благодарочка!!!!!!!!!!!!!!
Ты хоть и не решил где у нас проблема, но лучше других обяснил, где копать...

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

(159) Вот это

Write Cache(initial setting) = WriteThrough

это сквозная запись.
Попробуйте WriteBack - отложенную запись, должно быть быстрее, контроллер более эффективно очередь записи может построить.

(166)+ Насчет рисков из (130) думаю можно сильно не беспокоится, с батарейкой все нормально должно быть, причем если заряд батарейки опустится ниже некоторого критического уровня, то контроллер автоматом должен отключить отложенную запись.

(0) а почему скуль не используете ?

(166) А кто даст гарантию, что отложенную запись будут читать другие юзеры, а не с харда? Боимся

(169) В смысле? Это совершенно безопасная опция в случае наличия батарейки.

(168) Вопрос не в скуле. Кроме того самый частый запрос рег.Остаток(Товар,Склад). Он на скуле работает в разы медленнее чем да ДБФ. Тестировал не раз. Другие отчеты и правда быстрее на скуле. Но ...

(130) У нас DDR+ батарейка. Сегодня узнал.

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

(172) Ну это стандартный вариант. Насчет (169), никто там ничего не будет читать лишнего или другого, это отложенная запись только для контролера, для пользователя и ПО это обычная запись на диск.

(171) Можно даже не вникая что в коде, сразу сказать что нужно переписывать. У вас слишком маленькая база чтоб тормозило.

(175)+1. Я даже думаю, что там можно и штатными средствами нормально сделать, без извратов с прямыми запросами.
Сильно смутил
"за 20 мин. работали отчеты как за час на текущем (старом) сервере"
меня б наверное уже порвали на куски :)), если б отчет формировался час.

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

(177) Тоже было такое, таки в дбф быстрее. Я правда детальные тесты не делал, но одну базу перевел без предварительного тестирования на скуль, больше одного дня не выдержали :). По замерам производительности в отладчике, таки Рег.Остаток() тормозил.
Плюнул, не стал заморачиваться вернул взад, для 10 пользователей, в моем случае, сомнительное удовольствие мудохаться со скулем.

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


а если просто сравнивать вычисление
Рег.Остаток(Товар, Склад) то и в том и в другом случае
у тебя идет вычисление по индексу и Вы утверждаете
что индекс в dbf лучше организован чем индекс в ms sql
и вычисление по индексу dbf будет быстрее чем по индексу sql?


(178) Опять же простота установки ms sql вовсе не означает что сервер ms sql правильно установлен и оптимально настроен.

(179) Не, перепроведения не было. Тормозили списки где в формулах были Рег.Остаток().
2. Поэтому и не стал заморачиваться со скулем, тем более простора для маневра особо не было, ни в плане ресурсов на той же машине где терминал, ни в плане выноса скуля на отдельную машину.

(180)+ 2 - это к вопросу правильной и оптимальной настройки скуля.

(180) В 171 утверждается что
вычисление Рег.Остаток(Товар, Склад) быстрее в dbf
чем в sql и как ты предполается вычисление по одному товару и одному складу. никакого упоминания о списках в 171 нет.

(180) Я как бы не говорю что ты сделал неправильный выбор формата базы  для своей базы для 10 пользователей,
а говорю что высказывание 171  неверное.

(182) Про списки имел ввиду. В форме списка справочника текстовое поле с формулой Рег.Остаток(ТекущийТовар,НекоторыйСклад).
Я может после выходных ради интереса потестирую одну и ту же базу в разных форматах.

(176) Обясняю, у меня одельно идет хронометраж отчетов. Кто когда и какой запуска, и сколько времени поратил формирование отчета. За 20 мин. на новом сервере потратили 904 с. за тот же день на старом сервере 17000. 17000/8/3(20мин 1/3 от часа)=708. Добавим разницу в процессорах и их времени получится за 20 мин как за час

(177) Я же писал, что результат не в пользу скуля

(171) А ты бы попробовал вначале, а потом говорил что вопрос не в скуле. Ля делов то - на полчаса перегрузить dbf в sql!

И по запросу Рег.Остаток(Товар, Склад) - результат скорости выполнения запроса может в разы отличаться в зависимости от того склад в начале или товар

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

(186) Чего б ему отличаться от порядка измерений, если в таблице итогов кластерный индекс по Период + все измерения . Это к скорости Рег.Остаток().

(184) Теперь понятнее.
отя до конца не понятна формула учета разницы в процессорах, и нафига ее учитывать, ну да ладно.

(176) Я когда-то видел отчет, который формировал документы, а потом использовал их данные
Воистину, неисповедимы пути одинэснегов...

(189) Один и тот же очет. когда 1 на 1 с компом результат в 2-3 раа в +

(190) а клиентов?

(183) все промто тест типа перебор номенклатуры и если негруппа получить остаток. все

(1930 В стандарте работа в ДБФ быстрее чем в СКЛ, если в СКЛ переписать получение остатков на прямой запрос через 1C++ и ODBC, то станет практически поровну

если тупо перебор - так и есть быстрее работает перебор в дбф.

(195) Вовпрос не про перебор, а про скорость работы метода Рег.Остаток() в скуле и дбф. Про перебор было только как способ сравнить скорость работы метода.

(194) А с чем связано различие в скорости ?
Посмотрел в профайлере, Рег.Остаток() через вызов хранимки сделано.
Выше накладные расходы получаются на вызов хранимки?

(197) ну там не только это же... т.е. если использовать только вызов хранимки и обработку результата, то может и быстро было бы, но нет ли у 1С-ки других "накладных" расходов?

Штатно, кэшированием, получение остатков ускоряется во многие-многие разы.

(198) Так в том-то и дело, что хранимка у них с многими телодвижениями вызывается.
Сравнил с подготовленным запросом 1С++, там вроде как тоже хранимка, но вызывается как-то попроще.
И выполнитьСкалярный на подготовленном запросе раза в два быстрее, чем Рег.Остаток().

(200) Вот выполнение скалярного запроса

exec sp_execute 12, '   BJ3   ', '  15TF   '

а вот рег.Остаток()

declare P1 numeric(12,3)
set P1=NULL
declare @P2 numeric(12,3)
set @P2=NULL
declare @P3 numeric(11,2)
set @P3=NULL
exec _1sp_RG5272_Select 'Oct  1 2013 12:00AM', '   BJ3   ', '  15TF   ', P1 output, @P2 output, @P3 output
select P1, @P2, @P3

Ну и сама _1sp_RG5272_Select

Create procedure _1sp_RG1051_Select(@per DATETIME, @p1 CHAR(9), @p2 CHAR(9), @p3 CHAR(9), @p4 CHAR(9), @p5 NUMERIC(12, 3) OUTPUT, @p6 NUMERIC(12, 3) OUTPUT, @p7 NUMERIC(11, 2) OUTPUT, @p8 NUMERIC(11, 2) OUTPUT, @p9 NUMERIC(11, 2) OUTPUT) AS
Select @p5=SP1055,@p6=SP1056,@p7=SP1057,@p8=SP1058,@p9=SP1059 from RG1051 where PERIOD=@per AND SP1855=@p1 AND SP1053=@p2 AND SP1052=@p3 AND SP1054=@p4
GO

Я в этих материях не силен, поэтому и хотелось бы таки понять в чем прикол.

(201) + Текст процедуры от другого регистра, промахнулся, но смысл тот же.

(194)А если в дбф переписать на прямой запрос с условием попадания в индекс..то тут и скуль не обгонит
:))

(203) см. (199), и ничего переписывать не надо.

И небольшой трюк под SQL, увеличивающий скорость в разы.
ВремОстаткиТМЦ.УстановитьЗначениеФильтра("Склад",Константа.ОсновнойСклад,1);
ВремОстаткиТМЦ.УстановитьЗначениеФильтра("Номенклатура", ТекНоменклатура,1);
ВремОстаткиТМЦ.ВыгрузитьИтоги(ВремТаблОстатки,1,1);
ТекОстатки = ВремТаблОстатки.Итог("Количество");

Только не понял почему у меня в третьей строчке оба параметра в единицу.

(206) <ВклФильтр> - необязательный параметр. Число: 1 - в получаемую таблицу включаются измерения, закрепленные фильтром ; 0 - не включаются. Значение по умолчанию  - 0.
<Очищать> - необязательный параметр. Число: 1 - перед выгрузкой таблица значений очищается; 0 - не очищается. Значение по умолчанию - 1.

Так что второй параметр можно в 0 ставить.

(207) Да и третий параметр можно не указывать.

(207) Я знаю.
(208) ?

(209) Третий (очищать) он по умолчанию и так 1 будет.

Или я не понял вопрос в (206).

(211) Я не понял зачем у меня стоят единицы. Но я отлично знаю что делают эти параметры.

(210) Это новая парадигма программирования? Обязательно не указывать параметры по-умолчанию?

(213) Да нет.
Я таки не могу понять в чем вопрос. Как бы из описания параметров можно понять зачем установлены те или иные значения.
Конкретно к куску кода из (205) второй параметр можно в 0 ставить, так как в этом коде нет обращений к колокнам измерений в ВремОстаткиТМЦ.
Зачем там 1 стоит я не знаю.
Может дальше в коде есть обращения к колокнам измерений в ВремОстаткиТМЦ, ХЗ.

(214) Нафига к ним обращаться, если и так известно что там?

Не то обсуждаем.