|
|
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
Здрасьте! Сразу к делу. Есть оптовое торговое предприятие. Работают на УТ8 допиленной(мобильную торговлю туда прикрутили). 25 пользователей всего, примерно 15-20 одновременных коннектов к базе. База файловая 5+ гигов. Со временем ессно, у них стали медленно проводиться документы. Реализация 10 позиций номенклатуры при сумме от 100тр проводится секунд 10 при одном пользователе. А если много, то админ местный говорил что там дело на минуты шло. Вот и попросил помочь. Ну мы дали им системник свой(с лучшими чем у местного сервака характеристиками) и поставили скуль 2008 конвертнули базу - и пусть он тестирует. В итоге высянилось, что файловая база работает быстрее(!!!) клиент-серверной. Я никак не ожидал такого поворота событий. Не подскажете в чем может быть проблема если кто сталкивался? Или куда копать? Win Server 2003 R2, SQL Server 2008, 4 гига оперативы и проц двухъядерный(если критично указать модель - напишу) Пока в качестве решения проблемы производительности предложили им сервак за 400к.))) З.Ы. Да, замер производительности я делал, особо критичных мест в коде не обнаружил. Все более менее равномерно работает. Может быть сеть? В общем жду ваших комментариев и кусочка опыта. =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 13:39 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
Если в терминальном режиме и база на том же серваке, то файловая и будет быстрее на таких маленьких объемах. В многопользовательском режиме уже должно сказываться то, что в файловом режиме используется более высокая гранулярность блокировок, и соответственно пользователям приходится больше ждать друг-друга. Поэтому тестировать желательно в многопользовательском режиме, и иметь достаточно мощное железо для работы клиент-серверного варианта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 14:36 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
Нет региЕсли в терминальном режиме и база на том же серваке, то файловая и будет быстрее на таких маленьких объемах. В многопользовательском режиме уже должно сказываться то, что в файловом режиме используется более высокая гранулярность блокировок, и соответственно пользователям приходится больше ждать друг-друга. Поэтому тестировать желательно в многопользовательском режиме, и иметь достаточно мощное железо для работы клиент-серверного варианта. Так тестирование и производилось в многопользовательском режиме. На него и был сделан упор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 16:44 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
http://www.gilev.ru/1c/81/opt.htm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 16:48 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
Со временем ессно, у них стали медленно проводиться документы. Реализация 10 позиций номенклатуры при сумме от 100тр проводится секунд 10 при одном пользователе. А если много, то админ местный говорил что там дело на минуты шло. Вот и попросил помочь. З.Ы. Да, замер производительности я делал, особо критичных мест в коде не обнаружил. кстати этого не может быть. что-то вы не то намеряли. совершенно очевидно должно быть критическое место при проведении - это взятие сальдо (может быть не одно место, но их немного). Думаю тут вам самый банальный и обыкновенный админ sql нужен чтоб поизучать чо кого. Но раз его у вас нету - гадать в чём проблема - это реально вилами по воде. Интуитивно при таком количестве пользователей sql версия должна быть реально в разы быстрее, учитывая что почти вся база помещается в памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 20:50 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
ПаляИнтуитивно при таком количестве пользователей sql версия должна быть реально в разы быстрее, учитывая что почти вся база помещается в памяти.Из пояснений вроде очевидно, что у автора сиквел и 1С стоят на одном "сервере", потому быстрее ну никак не может быть, и в памяти и подавно не поместится. Да и 4Гб - это ... хм... У меня на рабочей машине столько, мне мало. Автор, предлагать "сервак за 400к" - чушь. Это что-то из разряда "либо миллион, либо на нетбуке". 2 сервера за 100к вполне объективнее, да и лучше по производительности, вероятно. Для такой в общем-то небольшой БД и этого не требуется. Надо не "тестировать скорость проведения документов", а хотя бы проанализировать очередь запросов ввода-вывода и потребление памяти, для начала. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2010, 11:17 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
авторИз пояснений вроде очевидно, что у автора сиквел и 1С стоят на одном "сервере", потому быстрее ну никак не может быть, и в памяти и подавно не поместится. Да и 4Гб - это ... хм... У меня на рабочей машине столько, мне мало. Я брал рекомендации по выбору оборудования от сюда . А там написано в частности следующее: Заметный эффект от размещения сервера 1С:Предприятия 8 и MS SQL Server на разных компьютерах начинает проявляться начиная с некоторого количества активных пользователей. Например, на основе результатов проведенных исследований ( http://www.v8.1c.ru/tests/ ), можно сделать вывод, что при количестве одновременно работающих пользователей больше 70, становится целесообразным размещение сервера 1С:Предприятия 8 и MS SQL Server на разных компьютерах. Однако в конкретных ситуациях эта цифра может отличаться в зависимости от интенсивности работы пользователей и используемого прикладного решения. По этому я сознательно не разносил на два разных компа эти серверы. Ибо между ними похоже нужна гигабитная сеть, иначе все будет ещё медленнее работать как раз из-за сети. автор2 сервера за 100к вполне объективнее, да и лучше по производительности, вероятно. Для такой в общем-то небольшой БД и этого не требуется. Я думал об этом варианте, но опять же - сомневаюсь в эффективности двух серверов из-за сети между ними. авторНадо не "тестировать скорость проведения документов", а хотя бы проанализировать очередь запросов ввода-вывода и потребление памяти, для начала. Согласен. Но когда было само тестирование я просто был уверен в том, что скуль поднимет хоть как-то именно скорость проведения документов. И вообще это основной тормоз всей системы, так как там все операторы почти круглосуточно занимаются только тем что вбивают и проводят документы. А получилось что стало ещё медленней. авторhttp://www.gilev.ru/1c/81/opt.htm Спасибо за ссылку. авторкстати этого не может быть. что-то вы не то намеряли. совершенно очевидно должно быть критическое место при проведении - это взятие сальдо (может быть не одно место, но их немного). Я просто проводил "средних размеров" документ и смотрел в результатах, есть ли какие-то особо длинные по времени операции и их не обнаружил. Весь код выполняется "одинаково медленно", что ли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2010, 13:04 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
tema32Я думал об этом варианте, но опять же - сомневаюсь в эффективности двух серверов из-за сети между ними.А что не так с сетью? Если возможности приобрести копеечное оборудование нет, то есть кросс-патч, в конце концов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2010, 15:06 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
WildSerytema32Я думал об этом варианте, но опять же - сомневаюсь в эффективности двух серверов из-за сети между ними.А что не так с сетью? Если возможности приобрести копеечное оборудование нет, то есть кросс-патч, в конце концов. Скорость обмена данными между сервером 1С и сервером СУБД по сети будет медленнее, нежели чем если они будут на одной машине данные гонять. Или это не так? О_о ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2010, 16:34 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
микросекунды экономим? а отсутствие свопинга? если нет конкретного узкого места - можешь начинать перепроектироваться под MS SQL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2010, 16:43 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
ScareCrowмикросекунды экономим? а отсутствие свопинга? если нет конкретного узкого места - можешь начинать перепроектироваться под MS SQL Эээ... не совсем понятно словосочетание "перепроектироваться под"... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2010, 17:06 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
Сервер 1С и сервер сиквела однозначно разделять; отслеживать косяки в коде/тестировать производительность - чудес не бывает, где то они есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2010, 19:57 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
tema32, Это с чего такое утверждение? Даже если оба сервера работают на одной машине данные между ними гоняются через сетевуху, с той скоростью, которая выставлена на сетевухе. Дело в том, что сервер 1с не умеет использовать для своей работы ничего, кроме сетевого протокола TCP (или UDP, точно не помню). Проверено на себе... :) А вот эффекта от перехода может не быть, если после конвертации средствами MS SQL не были проделаны регламентные работы (переиндексация, обновление статистки и т.п.). Для баз SQL-я это очень важно и очень критично. Как сделать - ищи на том же сайте, ссылку на котороый тут уже была. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2010, 07:56 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
Igor Glushaevtema32, Это с чего такое утверждение? Даже если оба сервера работают на одной машине данные между ними гоняются через сетевуху, с той скоростью, которая выставлена на сетевухе. Дело в том, что сервер 1с не умеет использовать для своей работы ничего, кроме сетевого протокола TCP (или UDP, точно не помню). Проверено на себе... :) А вот эффекта от перехода может не быть, если после конвертации средствами MS SQL не были проделаны регламентные работы (переиндексация, обновление статистки и т.п.). Для баз SQL-я это очень важно и очень критично. Как сделать - ищи на том же сайте, ссылку на котороый тут уже была. Спасибо за развернутый ответ! Я повторюсь - читал на оф. сайте 1С, что не имеет смысла разделять сервера при менее 70 пользователях. Видимо там неправильная инфа. Буду пробовать! Благодарю!) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2010, 11:40 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
tema32 Спасибо за развернутый ответ! Я повторюсь - читал на оф. сайте 1С, что не имеет смысла разделять сервера при менее 70 пользователях. Видимо там неправильная инфа. Буду пробовать! Благодарю!) Информация на оф.сайте - это одно, для идеального железа на идеальной конфигурации. А вот жизнь - это другое. Мы ощутили прирост скорости при переходе на SQL даже при 5 одновременно работающих пользователях, три из которых активно пишут в базу. Кроме того, такой объем базы (5+ гигов) для файлового варианта - это бомба, которая рванет в любой момент. Так что у Вас по любому альтернативы нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2010, 12:04 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
Igor Glushaevtema32 Спасибо за развернутый ответ! Я повторюсь - читал на оф. сайте 1С, что не имеет смысла разделять сервера при менее 70 пользователях. Видимо там неправильная инфа. Буду пробовать! Благодарю!) Информация на оф.сайте - это одно, для идеального железа на идеальной конфигурации. А вот жизнь - это другое. Мы ощутили прирост скорости при переходе на SQL даже при 5 одновременно работающих пользователях, три из которых активно пишут в базу. Кроме того, такой объем базы (5+ гигов) для файлового варианта - это бомба, которая рванет в любой момент. Так что у Вас по любому альтернативы нет. Итоги: 1. Разделить сервер 1С и сервер СУБД на два компьютера. 2. Конвертнуть базу в скуль версию. 3. Сделать оптимизацию и настройку этого самого скуля. А по железу есть какой-нибудь "нижний порог"? Про верхний не говорю, так как понятно, что чем круче железо тем лучше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2010, 12:30 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
tema32, Дисковая подсистема на Вашем сервере какая ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2010, 12:53 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
авторСделать оптимизацию и настройку этого самого скуля. очень было бы интересно посмотреть на эту оптимизацию и настройку. ибо там настраивать особо нечего, lol ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2010, 14:30 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
Ну как минимум настроить план обслуживания БД - реиндексакция индексов, обновление статистик. Разнести базу, Логи и tempdb по разным дисковым массивам, отключить параллелизм запросов в случае необходимости, определится с типом логирования от simple до Full, в общем стандартные действия которые нужно сделать при установке скуля. А вообще нужно смотреть счетчики, по ним легко определить чего недостаточно системе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2010, 15:16 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
авторНу как минимум настроить план обслуживания БД - реиндексакция индексов, обновление статистик. и что - правда помогает? авторРазнести базу, Логи и tempdb по разным дисковым массивам и что вы правда вручную разнесете нагрузку по дискам лучше чем контроллер? и это вся оптимизация? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2010, 15:55 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
tema32 Итоги: 1. Разделить сервер 1С и сервер СУБД на два компьютера. 2. Конвертнуть базу в скуль версию. 3. Сделать оптимизацию и настройку этого самого скуля. А по железу есть какой-нибудь "нижний порог"? Про верхний не говорю, так как понятно, что чем круче железо тем лучше. По итогам да, так оно и есть. По 3 пункту - в зависимости от выбранной операционки, может понадобиться правильная разбивка диска. Как сделать там же на сайте Гилева есть. (просто не сохранилис конкретные ссылки). А по железу - в принципе все зависит от количества пользователей в базе. У меня под базу в которой работают те самые 5 юзверей стоит дуал коре 2.66 с 4 гигами памяти, два винта по 300 гигов в зеркале. Ну сервера для них совмещены на одной машине. Другая база, где работает порядка 20 чеовек - сервера разделены, под 1с - Соре И7, 8 гигов памяти, 2 диска по 300 в зеркале, по SQL - HP-ный сервер, на базе Ксеона, 26 гигов памяти, 6 Сасовких дисков по 300 гигов в рейде. Вообще-то эти сервера обслуживают 5 баз, со средней нагрузкой в 15 пользователей на базу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2010, 16:04 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
ScareCrowавторНу как минимум настроить план обслуживания БД - реиндексакция индексов, обновление статистик. и что - правда помогает? авторРазнести базу, Логи и tempdb по разным дисковым массивам и что вы правда вручную разнесете нагрузку по дискам лучше чем контроллер? и это вся оптимизация? Не поверишь - помогает... В предыдущем посте - железо на серверах, производство, довольно сложное, время от времени, процедура закрытия затягивается с 10-12 часов до 20-30 часов. Лечиться только переиндексацией и обновлением статистик на сервере. По поводу распределения дисковой нагрузки по разным дисковым массивам - не поверишь - тоже помогает, а еще если для 2003 сервера, на дисках под базу выравнять смещение - так результат вообще фантастический. Все что пишу - проверено на себе... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2010, 16:10 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
человек кагбэ подводит всех к мысли "1ц г.вно"... а вы сопротивляетесь... файлы по разделам тусите ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2010, 16:14 |
|
||
|
проблемы с производительностью
|
|||
|---|---|---|---|
|
#18+
автора еще если для 2003 сервера моя плакает. автор26 гигов памяти зачем там еще и диски???? авторна дисках под базу выравнять смещение чего сделать? размер кластера ? размер страйпа? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2010, 17:04 |
|
||
|
|

start [/forum/topic.php?fid=28&msg=36813464&tid=1522072]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
230ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
91ms |
get tp. blocked users: |
2ms |
| others: | 243ms |
| total: | 615ms |

| 0 / 0 |
