Тестирование скорости перепроведения документов 1С 8.2 на разных связках windows и SQL серверов 1С УПП 1.3

При внедрении УПП сталкнулся с проблемой медленного (по мнению участников проекта) перепроведения документов. Решил протестировать перепроведение документов за одинаковый промежуток времени на разных связках windows и SQL серверов.

Исходные:

1С:Предприятие 8.2 (8.2.14.533)

1С:Управление строительной организацией, редакция 1.3 (1.3.12.4),

документы за 4 года.

Для теста выбраны первые 2 месяца, всего 346 докумнтов (платежные поручения, поступления товаров и услуг, реализация товаров и услуг).

Контрольный замер производительности:

Процессор E5335 2,00GHz шина 1333 4 проца (контрольный замер)

W2K8R2 + SQL2008R2 — 20 минут проц. E5335 2,00GHz шина 1333 4 проца

Процессор E5320 1,86 шина 1000 4 проца

1 W2K8R2 + SQL2008R2 31 мин

2 W2K8R2 + SQL2008 33 мин

3 W2K8R2 + SQL2005 35 мин

4 W2K8R2 + SQL2005 снят режим совместимости 8.2.13 и очищен регистр версий и отключено версинирование 37 мин

5 W2K8R2 + SQL2005 1С 8.2 переустановлена на диск на хранилище (не на диск С:) 31 мин

6 W2k3 + SQL2008R2 30 минут

Процессор X5450 3.00 шина 1333 4 проца

7 W2k8R2 + SQL2008R2 17 мин

Процессор X5450 3.00 шина 1333 8 проца

8 W2k8R2 + SQL2008R2 17 мин

Процессор X5650 2,66 шина 1333 4 проца, память DDR3 шина 800MHz 32Gb

W2K8R2Std SQL2008R2 11 мин

Таким образом, исходя из выше продставленных тестов, можно сделать вывод что:

На скорость перепроведения документов, при одинаковых условиях по железу, разные вырианты компановки операционной системы и SQL сервера большой разницы не имеют. В большинстве случаев несмотря на «тяжеловесность» SQL 2008 R2 именно связка W2k8R2 + SQL2008R2 дает максимальную производительность (хоть и не существенную по приросту). При равных условиях по связке ОС + SQL Сервер на производительность влияет исключительно производная частоты процессора на частоту шины. Существенного пользования ресурсами дисковой подстстемы не обнаружено (3.5 МB в рандоме).

43 Comments

fishca 08.09.2011 at 13:18

Лучше измерять производительность с помощью многопользовательских тестов. При перепроведении 4 проца ты не сможешь задействовать.

Reply ↓
pulpik 08.09.2011 at 13:50

то что производительность измеряется при многопользовательских тестов я знаю. спасибо за напоминание. Однако, так как при перепроведении все системные ресурсы были заняты на незначительный показатель я подумал что все из-за неправильного подбора связки, после чего я попробовал протестировать именно изменение поведения базы из-за связки Windows + SQL server.

Reply ↓
fishca 08.09.2011 at 13:55

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

Можно перечислить системные ресурсы которые были заняты на этот самый незначительный показатель. Что-то мне подсказывает, что процессор вваливал на все 100% при перепроведении. Или процессор это не системный ресурс?

Reply ↓
Aragorn 08.09.2011 at 13:56

все конечно интересно, автору респект за проведенную работу. Но все же не надо упирать на связки Win+SQL, а рассматривать проблемы кода и настройки самой sql

Reply ↓
fishca 08.09.2011 at 14:01

(4)да, ждем статьи на тему Тестирование скорости перепроведения документов 1С 8.2 на разных связках Linux и SQL серверов 1С УПП 1.3 😉

Reply ↓
cool.vlad4 08.09.2011 at 14:53

Неужели что-то интересное после новшеств на сайте 😉 Спс.

Reply ↓
Ёпрст 08.09.2011 at 14:57

Снеговик мегатормоз.. это полный ПЭ.

20 минут на 300 доков..жесть.

Reply ↓
fishca 08.09.2011 at 15:06

(7)это не снеговик, а УПП, а может и то и другое. Насколько я знаю еще никто адекватного сравнения не делал клюшек и снеговика на предмет сравнения производительности, или я ошибаюсь?

Reply ↓
Арчибальд 08.09.2011 at 15:11

(8) Никто не делал, но оно и так заметно. Рюшечки 8 небесплатны.

Reply ↓
fishca 08.09.2011 at 15:14

(9) за все, к сожалению, приходится чем-то расплачиваться, такова се-ля-ва 🙂

Reply ↓
LeaNaeD 08.09.2011 at 16:22

Самый смак был бы сравнить с файловым вариантом работы. А хотя бы создать новую базу с данными за год, например, или сколько там ваша база в файловом вприанте потянет. И ту же базу в этих ваших серверных связках. От это было бы интересно посмотреть.

Reply ↓
fishca 08.09.2011 at 16:28

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

Reply ↓
pulpik 08.09.2011 at 16:32

fishca 08.09.11 13:55 Ссылка Цитата Ник

Цитата

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

Можно перечислить системные ресурсы которые были заняты на этот самый незначительный показатель. Что-то мне подсказывает, что процессор вваливал на все 100% при перепроведении. Или процессор это не системный ресурс?

[+] [−]

Процессор 18-25%

Оперативная память по нарастанию (при базе в 6 гигов) от 2 до 4 гигов

Дисковый массив Raid10 — 6 дисков Iscsi — максимум 3,5 MB/Sec рывками при перескокое на след документ (похоже запись по регистра) между этои по нулям.

Reply ↓
pulpik 08.09.2011 at 16:33

1.

LeaNaeD 08.09.11 16:22 Ссылка Цитата Ник

Самый смак был бы сравнить с файловым вариантом работы. А хотя бы создать новую базу с данными за год, например, или сколько там ваша база в файловом вприанте потянет. И ту же базу в этих ваших серверных связках. От это было бы интересно посмотреть.

Ответили: (12)

[+] [−]

этот вариант не рассматриваю так как планируемый размер базы от 20 гигов

Reply ↓
fishca 08.09.2011 at 16:36

Процессор 18-25%

— при 4 процессорах это и есть загрузка под 100%, что и следовало ожидать.

Reply ↓
pulpik 08.09.2011 at 16:45

fishca 08.09.11 16:36 Ссылка Цитата Ник

Цитата

Процессор 18-25%

— при 4 процессорах это и есть загрузка под 100%, что и следовало ожидать.

[+] [−]

можно сделать вывод что клиентское приложение работает исключительно как монопроцессное и ничего с этим не поделать.

Reply ↓
fishca 08.09.2011 at 16:47

(16)

можно сделать вывод что клиентское приложение работает исключительно как монопроцессное и ничего с этим не поделать.

это было изначально известно еще при выпуске 8.0, что по сравнению с 7.7 ничего в этом плане не поменялось и думаю не скоро поменяется.

Reply ↓
LeaNaeD 08.09.2011 at 17:13

(12)

У нас файловый вариант с эдак 50-60 одновременно работающих юзверей. Работает достаточно шустро за счет следующего:

1) 2 4х-ядерника

2)SSD или даже рейд-массив из SSD

3) База периодически будет обрезаться (раз в год-да), в этом году уже обрезали.

4) Ну и несколько хинтов, навроде переделки ролей пользователей (стандартная роль «Пользователь» ОЧЕНЬ сильно тормозила работу всех юзверей без полных прав, поначалу даже не подозревал, что дело в ней. Другие роли переделал с отключением ограничений доступа к данным по чтению, оставил только на запись + контроль на запись по складам; ограничения на чтение нехило тормозило работу. А вот роль «Пользователь» ушами-то и прохлопал поначалу), переделка универсального отчета на бОльшее быстродействие, взятая с этого сайта. ну и может еще что-то.

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

Жаль тестов нормальных найти не могу, да эдакого авторитетного мнения, чтобы грамотно пояснить это дело. Конфликт блокировок ежели раз в год бывает — это максимум, и то если какя-то тетя запустит отчет за год. А вот в клиент-серверном варианте встречал огогенные конфликты блокировок и то, как документы проводятся минут так под 20.

Кто может подскажет полезную статью по такой теме?

Reply ↓
LeaNaeD 08.09.2011 at 17:15

(14)

этот вариант не рассматриваю так как планируемый размер базы от 20 гигов

Очень жаль, далеко не все фирмы могут себе позволить полляма-лям на переход на скл-версию. См. (18)

Reply ↓
fishca 08.09.2011 at 17:18

(19) скули бывают разные 😉 можно и постгрес попробовать

Reply ↓
fishca 08.09.2011 at 17:18

(18)

1. в терминалке сидите?

2. размер базы какой?

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

Reply ↓
LeaNaeD 08.09.2011 at 17:24

(20)

Да, все сидят в терминале, забыл это упомянуть. База 4,5 где-то, в прошлом году было примерно под 6 (это за полтора-два года работы, но тогда и пользователей было гораздо меньше). Так что где-то раз в год в принципе можно успеть обрезать. Да, был еще хинт. У номенклатуры фирмы (очковые и контактные линзы) есть такая неприятная особенность, как огроменный ассортимент: миллионы, десятки миллионов характеристик номенклатуры. Тут файловая база трещала по швам, но тут тоже сделали хинт ушами, хотя по бОльшей части смахивает на костыль.

(21)

Стандартный ответ — фуфу, это же бесплатное поделие, то ли дело православный MS SQL, такие-то мощщи. Ну и все в таком же духе.

Reply ↓
fishca 08.09.2011 at 17:28

Стандартный ответ — фуфу, это же бесплатное поделие, то ли дело православный MS SQL, такие-то мощщи. Ну и все в таком же духе.

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

Reply ↓
LeaNaeD 08.09.2011 at 17:35

(23)

железобетонные аргументы — это тесты-обзоры из авторитетного источника, а не мнения незнамо кого из форумчиков. В этом-то и суть. По клиент-серверному варианту 1С я и сам мало что знаю, разве что изучал когда-то ansi sql, ну и книжка есть по MS SQL серверу от мелкософта же, читал когда-то, да не пригодилось.

Reply ↓
alexk-is 08.09.2011 at 18:38

(20)

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

Не правда. Так было в 7.7. В 8.х всё иначе. Прирост производительности есть и очень значительный даже при 1 пользователе и особенно при использовании RLS.

Когда у нас база стала останавливаться, то поставили на рабочую станцию с XP 1С:Сервер и IBM DB2. Технические данные у машинки простенькие: RAM 2 Gb, HDD 200 Gb. Без наворотов. Одно рабочее место. РИБ. После перевода на SQL база сразу залетала.

Reply ↓
romansun 08.09.2011 at 19:14

(25)

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

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

По статье и скорости проведения доков — очень большое значение имеет количество памяти и особенно скорость винтов. Мне кажется, даже более, чем сам проц.

И еще — при проведении доков поставьте замер производительности в 1С, тут, имхо, самое интересное это, ибо 300 доков за 20 минут — это, да, жесть 😀

LeaNaeD пишет:

Очень жаль, далеко не все фирмы могут себе позволить полляма-лям на переход на скл-версию. См. (18)

а почему полляма — лям? какой примерно расклад по ценам получается?

Но вообще, когда 50-60 одновременно, значит всего в базе зарегено сотня минимум наверное. Это же уже не пивной ларёк — солидная контора, солидная база, много важной инфы

Reply ↓
LeaNaeD 08.09.2011 at 19:40

(26)

1) 1С:Предприятие 8+MS SQL Server Standard 2008. Клиентская лицензия на 50 рабочих мест 401 800 руб.

2) 1С:Предприятие 8+MS SQL Server Standard 2008. Клиентская лицензия на 10 рабочих мест 82 600 руб.

3) 1С:Предприятие 8.2. Лицензия на сервер(x86-64)+MS SQL Server Standard 2008. Лицензия на 1 процессор 272 000 руб (умножать надо бы эдак на 4-8)

Может еще и отдельный ключ на сервер 1С-Прдприятия нужен? Тогда еще сотенку, после предыдущих карман не отяжелит!

4) 1С:Предприятие 8.2. Лицензия на сервер (x86-64) 72 000 руб

5) собственно сам компьютер-сервер скл, еще 50-100 тыр

6) Возможно дадут скидку при обмене старых ключей, мобыть сотенку и скинут

Короче, дело — табак. Контора мобыть и солидная, но не московская, так что сам понимаешь. Лямы за воздух тратить далеко не каждый себе позволит, тем более, что и так нормально работает. Особенно в свете предыдущих трат на ключи защиты, лицензии за терминальные подключения, лиценции за ms office на кучу юзверей и прочее, прочее.

Reply ↓
V_V_V 08.09.2011 at 21:06

Один момент остался незамеченным, судя по комментариям. А именно — при равных условиях операционка WIN2003 уделала WIN2008. Хоть в приведенных автором данных и несущественно, но именно из-за этого я откатился назад с 2008 на 2003 (SQL остался 2008). У меня прирост получился многократный, при двух процах XEON 5600 (суммарно 12 ядер), памяти 24 ГБ и весе базы в 30 Гиг отчет за 4-е года по всем оборотам с разбивкой по годам и общими итогами на 2008-м строился около получаса — на 2003-м не больше 2-х минут (конфа самописная, управляемые формы 8.2, отчет не изменялся, данные втянуты за прошлые периоды). И там и там загрузка ВСЕХ процов доходила до 95-100%, пользователи на 2008 ощутимо тормозили, на 2003 мало кто заметил неудобства. Для себя сделал вывод — старое не всегда хуже…

Reply ↓
fishca 08.09.2011 at 21:14

(28)

А именно — при равных условиях операционка WIN2003 уделала WIN2008

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

Reply ↓
echo77 08.09.2011 at 22:35
(0) диски как разбиты?

выполните скрипт(VBS) с сервера 2003:
```
strComputer = «.» ‘ Local Computer
Set objWMIService = GetObject(«winmgmts:\» & strComputer & »
ootCIMV2″)
Set colItems = objWMIService.ExecQuery(«SELECT * FROM Win32_DiskPartition»,,48)

For Each objItem in colItems
Wscript.Echo «Disk: » & objItem.DiskIndex & »  Partition: » & objItem.Index & »  StartingOffset: » & objItem.StartingOffset & » Bytes»
Next
```
Показать
лучше из консоли, т.е. командой:
```
cscript скрипт.vbs
```
— не совсем понятно, почему с отключенным версионированием процедура заняла больше времени :-/

— что значит?:

5 W2K8R2 + SQL2005 1С 8.2 переустановлена на диск на хранилище (не на диск С:)

До этого все тесты проводились на системном разделе?

Reply ↓
a-novoselov 09.09.2011 at 09:30

(18) Файловый вариант в любом случае будет быстрее серверного работать (по крайней мере при измененнии данных), из-за отсутствия двух промежуточных звеньев между клиентом и базой данных. Т.е. файловый: клиент -> БД, серверный: клиент -> сервер предприятия 1С -> SQL сервер -> БД.

При чтении одновременно с несколких таблиц (отчет по 5-6 регистрам, отчет поверх которого RLS накладывается…) SQL даст фору файловому варианту при повторном обращении, из-за оптимизации плана запроса и других внутренних механизмов SQL сервера по улучшению производительности. Плюс кеширование данных сервером 1С при многопользовательском режиме.

Другое дело, что файловый вариант просто не потянет базу больше 50, тем более 100 ГБ. Да и база в 20 ГБ тупо не развернется в файловом варианте, если хотя бы одна таблица превышает размер в 4 ГБ (например тот же регистр ВерсииОбъектов при включенном версионировании всех объектов легко перевалит за такой размер).

Reply ↓
pulpik 09.09.2011 at 09:32

— не совсем понятно, почему с отключенным версионированием процедура заняла больше времени :-/

— что значит?:

Цитата

5 W2K8R2 + SQL2005 1С 8.2 переустановлена на диск на хранилище (не на диск С

по умолчанию программа ставится на диск С:

в этом случае я ее поставил на диск D: туда же где лежали базы SQL

Reply ↓
mad_maksim 09.09.2011 at 09:38

5 W2K8R2 + SQL2005 1С 8.2 переустановлена на диск на хранилище

Да, мне тоже это непонятно. Если речь именно о файлах базы данных SQL, то они однозначно должны быть на отдельном диске.

Если речь о платформе — не имеет никакого значения, где они.

Reply ↓
echo77 09.09.2011 at 13:13

(31) Я не хочу здесь спорить про то что быстрее файловый вариант или серверный. Но по своему опыту скажу, что многопользовательский файловый вариант(не терминал) с включенным RLS намного тормознее серверного. И не зря в некоторых решениях пишут, что включение ограничения на уровне записей не рекомендуется для баз в файловом варианте.

Reply ↓
sumixam 09.09.2011 at 15:17

у меня стояла конфа самописка 1с8.2 файловый вариант 10 пользюков номально работала потом пипец ваще загибаться стала, перевел на СКЛ 2005 ваще супер летает 40 юзеров, полет нормальный, правда памяти 4 гига пришлось на сервер добавить))))))

Reply ↓
Gasdrubal 12.09.2011 at 05:38

Самый смак бло бы сравнить с доступным всем программистам SQL — express edition. по заявлению производителя там должны быть худшие штуки в плане оптимизации плана запросов и прочего. Но действительно ли это хуже будет работать н типовых конфигурациях. Тем более у многих фирм база не достигает 4 гб — типовя бухгалтерия ил торговля ( если своевременно делать выгрзку)

Reply ↓
a-novoselov 14.09.2011 at 15:06

(31) Файловый вариант «не терминал» тормозить будет намного сильнее терминального, там большие потери идут на сеть. Попробуйте файлы базы данных SQL сервера (собственно саму базу) расположить не на самом SQL сервере, а на шаре другого компютера в сети, у вас и серверный вариант тормозить начнет.

Reply ↓
dreamland 14.09.2011 at 19:32

Недавно устанавливал 1С БП 2.0 (количество документов 2910, остатки на начало года по 14.09.2011г) на сервак DEPO Storm 2300L2 (Intel® Xeon® E5620, 12ГБ ОЗУ), на VMware три виртуальных сервака (1С Администрирование — 2ГБ ОЗУ, SQL Server 2008 R2 — 2ГБ ОЗУ, Терминал — 3ГБ ОЗУ), на всех ОС — W2K8R2. Время тестирования — 35 минут, красота, доволен, это при учете того, что на серваке крутится шесть баз (и все бухам нужны 😀 ). В скором будущем планируем переход на УПП, посмотрим, как она себя покажет.

Reply ↓
yliasha 21.09.2011 at 11:08

Спасибо большое,за интересную статью. Очень помогла разобраться.

Reply ↓
tiniji 21.09.2011 at 14:48

А в файловой БД не пробовали? Может быть еще быстрее будет чем SQL ?

Reply ↓
powerpc 28.09.2011 at 00:01

у нас Core i7 на VMWare ESXi 5 порвал все серваки Depo, HP. Прирост скорости в 2 раза на файловых базах и в 2,5 раза на SQL. Причем на связке W2K3+SQL2K8R2 оптимальная смесь получилась.

Reply ↓
timothy 27.10.2011 at 13:25

Подскажите статью, где можно будет прочесть как правильно SQL srv 2008 правильно настроить. а то база тормозит — жуть. а всего 13-15 пользователей.

Reply ↓
Motor24 12.12.2011 at 17:14

Присоединяюсь к последнему комментарию — очень интересует вопрос правильной настройки SQL 2008 для работы с платформой 8.2

Reply ↓