gifts2017

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

Опубликовал pulpik (pulpik) в раздел Администрирование - Оптимизация БД (HighLoad)

При внедрении УПП сталкнулся с проблемой медленного (по мнению участников проекта) перепроведения документов. Решил протестировать перепроведение документов за одинаковый промежуток времени на разных связках 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 в рандоме).

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Сергей Рудаков (fishca) 08.09.11 13:18
Лучше измерять производительность с помощью многопользовательских тестов. При перепроведении 4 проца ты не сможешь задействовать.
2. pulpik (pulpik) 08.09.11 13:50
то что производительность измеряется при многопользовательских тестов я знаю. спасибо за напоминание. Однако, так как при перепроведении все системные ресурсы были заняты на незначительный показатель я подумал что все из-за неправильного подбора связки, после чего я попробовал протестировать именно изменение поведения базы из-за связки Windows + SQL server.
3. Сергей Рудаков (fishca) 08.09.11 13:55
перепроведении все системные ресурсы были заняты на незначительный показатель

Можно перечислить системные ресурсы которые были заняты на этот самый незначительный показатель. Что-то мне подсказывает, что процессор вваливал на все 100% при перепроведении. Или процессор это не системный ресурс?
4. Александр (Aragorn) 08.09.11 13:56
все конечно интересно, автору респект за проведенную работу. Но все же не надо упирать на связки Win+SQL, а рассматривать проблемы кода и настройки самой sql
5. Сергей Рудаков (fishca) 08.09.11 14:01
(4)да, ждем статьи на тему Тестирование скорости перепроведения документов 1С 8.2 на разных связках Linux и SQL серверов 1С УПП 1.3 ;)
6. Ийон Тихий (cool.vlad4) 08.09.11 14:53
Неужели что-то интересное после новшеств на сайте ;) Спс.
7. Епрст (Ёпрст) 08.09.11 14:57
Снеговик мегатормоз.. это полный ПЭ.
20 минут на 300 доков..жесть.
Zapadnaya; hogik; Арчибальд; +3 Ответить 1
8. Сергей Рудаков (fishca) 08.09.11 15:06
(7)это не снеговик, а УПП, а может и то и другое. Насколько я знаю еще никто адекватного сравнения не делал клюшек и снеговика на предмет сравнения производительности, или я ошибаюсь?
9. Александр Рытов (Арчибальд) 08.09.11 15:11
(8) Никто не делал, но оно и так заметно. Рюшечки 8 небесплатны.
10. Сергей Рудаков (fishca) 08.09.11 15:14
(9) за все, к сожалению, приходится чем-то расплачиваться, такова се-ля-ва :)
11. Неран Гкреси (LeaNaeD) 08.09.11 16:22
Самый смак был бы сравнить с файловым вариантом работы. А хотя бы создать новую базу с данными за год, например, или сколько там ваша база в файловом вприанте потянет. И ту же базу в этих ваших серверных связках. От это было бы интересно посмотреть.
12. Сергей Рудаков (fishca) 08.09.11 16:28
(11) файловая база на одном пользователе выиграет, если база будет расположена локально на том же компе :).
13. pulpik (pulpik) 08.09.11 16:32
fishca 08.09.11 13:55 Ссылка Цитата Ник
Цитата
перепроведении все системные ресурсы были заняты на незначительный показатель

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


Процессор 18-25%
Оперативная память по нарастанию (при базе в 6 гигов) от 2 до 4 гигов
Дисковый массив Raid10 - 6 дисков Iscsi - максимум 3,5 MB/Sec рывками при перескокое на след документ (похоже запись по регистра) между этои по нулям.
14. pulpik (pulpik) 08.09.11 16:33
1.
LeaNaeD 08.09.11 16:22 Ссылка Цитата Ник
Самый смак был бы сравнить с файловым вариантом работы. А хотя бы создать новую базу с данными за год, например, или сколько там ваша база в файловом вприанте потянет. И ту же базу в этих ваших серверных связках. От это было бы интересно посмотреть.
Ответили: (12)
[+] [−]


этот вариант не рассматриваю так как планируемый размер базы от 20 гигов
15. Сергей Рудаков (fishca) 08.09.11 16:36
Процессор 18-25%
- при 4 процессорах это и есть загрузка под 100%, что и следовало ожидать.
16. pulpik (pulpik) 08.09.11 16:45
fishca 08.09.11 16:36 Ссылка Цитата Ник
Цитата
Процессор 18-25%
- при 4 процессорах это и есть загрузка под 100%, что и следовало ожидать.
[+] [−]

можно сделать вывод что клиентское приложение работает исключительно как монопроцессное и ничего с этим не поделать.
17. Сергей Рудаков (fishca) 08.09.11 16:47
(16)
можно сделать вывод что клиентское приложение работает исключительно как монопроцессное и ничего с этим не поделать.

это было изначально известно еще при выпуске 8.0, что по сравнению с 7.7 ничего в этом плане не поменялось и думаю не скоро поменяется.
18. Неран Гкреси (LeaNaeD) 08.09.11 17:13
(12)

У нас файловый вариант с эдак 50-60 одновременно работающих юзверей. Работает достаточно шустро за счет следующего:
1) 2 4х-ядерника
2)SSD или даже рейд-массив из SSD
3) База периодически будет обрезаться (раз в год-да), в этом году уже обрезали.
4) Ну и несколько хинтов, навроде переделки ролей пользователей (стандартная роль "Пользователь" ОЧЕНЬ сильно тормозила работу всех юзверей без полных прав, поначалу даже не подозревал, что дело в ней. Другие роли переделал с отключением ограничений доступа к данным по чтению, оставил только на запись + контроль на запись по складам; ограничения на чтение нехило тормозило работу. А вот роль "Пользователь" ушами-то и прохлопал поначалу), переделка универсального отчета на бОльшее быстродействие, взятая с этого сайта. ну и может еще что-то.

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

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

Кто может подскажет полезную статью по такой теме?
19. Неран Гкреси (LeaNaeD) 08.09.11 17:15
(14)

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


Очень жаль, далеко не все фирмы могут себе позволить полляма-лям на переход на скл-версию. См. (18)
20. Сергей Рудаков (fishca) 08.09.11 17:18
(18)
1. в терминалке сидите?
2. размер базы какой?
переход на SQL версию прироста производительности не даст, он обеспечивает только более высокую надежность хранения данных.
21. Сергей Рудаков (fishca) 08.09.11 17:18
(19) скули бывают разные ;) можно и постгрес попробовать
22. Неран Гкреси (LeaNaeD) 08.09.11 17:24
(20)

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

(21)

Стандартный ответ - фуфу, это же бесплатное поделие, то ли дело православный MS SQL, такие-то мощщи. Ну и все в таком же духе.
23. Сергей Рудаков (fishca) 08.09.11 17:28
Стандартный ответ - фуфу, это же бесплатное поделие, то ли дело православный MS SQL, такие-то мощщи. Ну и все в таком же духе.

но ты то понимаешь, что это далеко не так, вот и убеди тех кто не понимает железобетонными аргументами.
24. Неран Гкреси (LeaNaeD) 08.09.11 17:35
(23)

железобетонные аргументы - это тесты-обзоры из авторитетного источника, а не мнения незнамо кого из форумчиков. В этом-то и суть. По клиент-серверному варианту 1С я и сам мало что знаю, разве что изучал когда-то ansi sql, ну и книжка есть по MS SQL серверу от мелкософта же, читал когда-то, да не пригодилось.
25. Алексей Константинов (alexk-is) 08.09.11 18:38
(20)
переход на SQL версию прироста производительности не даст, он обеспечивает только более высокую надежность хранения данных.
Не правда. Так было в 7.7. В 8.х всё иначе. Прирост производительности есть и очень значительный даже при 1 пользователе и особенно при использовании RLS.

Когда у нас база стала останавливаться, то поставили на рабочую станцию с XP 1С:Сервер и IBM DB2. Технические данные у машинки простенькие: RAM 2 Gb, HDD 200 Gb. Без наворотов. Одно рабочее место. РИБ. После перевода на SQL база сразу залетала.
26. Роман Романов (romansun) 08.09.11 19:14
(25)
дополню, что в случае нагруженных пользователями и данными баз и тяжелых отчетов только SQL и работает. Файловые версии тупо не работают даже в виде тестовых у программера - просто тупо зависают или пишут про недостаток памяти.

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

По статье и скорости проведения доков - очень большое значение имеет количество памяти и особенно скорость винтов. Мне кажется, даже более, чем сам проц.
И еще - при проведении доков поставьте замер производительности в 1С, тут, имхо, самое интересное это, ибо 300 доков за 20 минут - это, да, жесть :D

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


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

Но вообще, когда 50-60 одновременно, значит всего в базе зарегено сотня минимум наверное. Это же уже не пивной ларёк - солидная контора, солидная база, много важной инфы
27. Неран Гкреси (LeaNaeD) 08.09.11 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 на кучу юзверей и прочее, прочее.
28. VVV (V_V_V) 08.09.11 21:06
Один момент остался незамеченным, судя по комментариям. А именно - при равных условиях операционка WIN2003 уделала WIN2008. Хоть в приведенных автором данных и несущественно, но именно из-за этого я откатился назад с 2008 на 2003 (SQL остался 2008). У меня прирост получился многократный, при двух процах XEON 5600 (суммарно 12 ядер), памяти 24 ГБ и весе базы в 30 Гиг отчет за 4-е года по всем оборотам с разбивкой по годам и общими итогами на 2008-м строился около получаса - на 2003-м не больше 2-х минут (конфа самописная, управляемые формы 8.2, отчет не изменялся, данные втянуты за прошлые периоды). И там и там загрузка ВСЕХ процов доходила до 95-100%, пользователи на 2008 ощутимо тормозили, на 2003 мало кто заметил неудобства. Для себя сделал вывод - старое не всегда хуже...
29. Сергей Рудаков (fishca) 08.09.11 21:14
(28)
А именно - при равных условиях операционка WIN2003 уделала WIN2008
кстати на эту тему кто-то здесь кажись описывал эксперименты или на партнерском форуме, причем на разных серверах выигрышь 2003 над 2008 либо были либо нет и к общему знаменателю не пришли.
30. Александр Крынецкий (echo77) 08.09.11 22:35
(0) диски как разбиты?
выполните скрипт(VBS) с сервера 2003:
strComputer = "." ' Local Computer
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") 
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 переустановлена на диск на хранилище (не на диск С:)

До этого все тесты проводились на системном разделе?
31. Алексей Новоселов (a-novoselov) 09.09.11 09:30
(18) Файловый вариант в любом случае будет быстрее серверного работать (по крайней мере при измененнии данных), из-за отсутствия двух промежуточных звеньев между клиентом и базой данных. Т.е. файловый: клиент -> БД, серверный: клиент -> сервер предприятия 1С -> SQL сервер -> БД.
При чтении одновременно с несколких таблиц (отчет по 5-6 регистрам, отчет поверх которого RLS накладывается...) SQL даст фору файловому варианту при повторном обращении, из-за оптимизации плана запроса и других внутренних механизмов SQL сервера по улучшению производительности. Плюс кеширование данных сервером 1С при многопользовательском режиме.
Другое дело, что файловый вариант просто не потянет базу больше 50, тем более 100 ГБ. Да и база в 20 ГБ тупо не развернется в файловом варианте, если хотя бы одна таблица превышает размер в 4 ГБ (например тот же регистр ВерсииОбъектов при включенном версионировании всех объектов легко перевалит за такой размер).
32. pulpik (pulpik) 09.09.11 09:32

- не совсем понятно, почему с отключенным версионированием процедура заняла больше времени :-/
- что значит?:
Цитата
5 W2K8R2 + SQL2005 1С 8.2 переустановлена на диск на хранилище (не на диск С


по умолчанию программа ставится на диск С:
в этом случае я ее поставил на диск D: туда же где лежали базы SQL
33. Максим Князев (mad_maksim) 09.09.11 09:38
5 W2K8R2 + SQL2005 1С 8.2 переустановлена на диск на хранилище
Да, мне тоже это непонятно. Если речь именно о файлах базы данных SQL, то они однозначно должны быть на отдельном диске.
Если речь о платформе - не имеет никакого значения, где они.
34. Александр Крынецкий (echo77) 09.09.11 13:13
(31) Я не хочу здесь спорить про то что быстрее файловый вариант или серверный. Но по своему опыту скажу, что многопользовательский файловый вариант(не терминал) с включенным RLS намного тормознее серверного. И не зря в некоторых решениях пишут, что включение ограничения на уровне записей не рекомендуется для баз в файловом варианте.
35. sumixam (sumixam) 09.09.11 15:17
у меня стояла конфа самописка 1с8.2 файловый вариант 10 пользюков номально работала потом пипец ваще загибаться стала, перевел на СКЛ 2005 ваще супер летает 40 юзеров, полет нормальный, правда памяти 4 гига пришлось на сервер добавить))))))
36. FFFF FFF (Gasdrubal) 12.09.11 05:38
Самый смак бло бы сравнить с доступным всем программистам SQL - express edition. по заявлению производителя там должны быть худшие штуки в плане оптимизации плана запросов и прочего. Но действительно ли это хуже будет работать н типовых конфигурациях. Тем более у многих фирм база не достигает 4 гб - типовя бухгалтерия ил торговля ( если своевременно делать выгрзку)
37. Алексей Новоселов (a-novoselov) 14.09.11 15:06
(31) Файловый вариант "не терминал" тормозить будет намного сильнее терминального, там большие потери идут на сеть. Попробуйте файлы базы данных SQL сервера (собственно саму базу) расположить не на самом SQL сервере, а на шаре другого компютера в сети, у вас и серверный вариант тормозить начнет.
38. Captain Nemo (dreamland) 14.09.11 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 минут, красота, доволен, это при учете того, что на серваке крутится шесть баз (и все бухам нужны :D ). В скором будущем планируем переход на УПП, посмотрим, как она себя покажет.
39. Юляша Юляша (yliasha) 21.09.11 11:08
Спасибо большое,за интересную статью. Очень помогла разобраться.
40. Александр Потапов (tiniji) 21.09.11 14:48
А в файловой БД не пробовали? Может быть еще быстрее будет чем SQL ?
41. Олег Крапивный (powerpc) 28.09.11 00:01
у нас Core i7 на VMWare ESXi 5 порвал все серваки Depo, HP. Прирост скорости в 2 раза на файловых базах и в 2,5 раза на SQL. Причем на связке W2K3+SQL2K8R2 оптимальная смесь получилась.
42. timothy 27.10.11 13:25
Подскажите статью, где можно будет прочесть как правильно SQL srv 2008 правильно настроить. а то база тормозит - жуть. а всего 13-15 пользователей.
43. Андрей - (Motor24) 12.12.11 17:14
Присоединяюсь к последнему комментарию - очень интересует вопрос правильной настройки SQL 2008 для работы с платформой 8.2
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа