Увеличение производительности 1с7.7+SQL #297551

Всем привет!! Иметься проблема прошу помочь. Имееться: Xeon 2.8/4гб Win2k3+Терминал+1с7.7 25 патч+RBD7702+SQL2000sp3 База на 40 гб ,настроен автообмен, Пользователей 35 ,активно проводят   документы около 16 В часы пик сервер сильно тормозит, загрузка проца постоянно 100%, в логах   автообмена периодически проскакивала ошибка 40001 Установил компонету  от romix "Исправление ошибки 1С:Предприятие  7.7/8.0 - 100% загрузка процессора при ожидании блокировки" версия от 16.08.07 Тормозов стало меньше!! Однако 2 раза было что, вся база вставала. при попытке зайти в 1с, писало "Ошибка   блокировки данных.Возможно данные используються другой задачей" В консоле замечал что автообмен в этот момент висел. Поставил в компоненте игнорирование ошибки 40001. Теперь периодически при попытке провести документ пишет "Запись заблокирована", все остальные пользователи в этот момент повисают, после нажатии на табличке ОК, данный пользователь вылетает с базы, его проводка не сохраняеться, остальные продолжают работу, ошибка похоже возникает также во время обмена.Ошибки 40001 в логах обмена после установки компоненты не замечал. Если не сложно опишите решение проблемы. И вообше как можно увеличить производительность сервера? Всем спасибо за внимание=)

Диски с базой SCSI? Файлы базы данных на отдельных дисках?

+ и вообще SQL сервер на отдельном компе?

.ldf на IDE диске,mdf на рейде 10, все на одном серваке

LDF тоже критичен к скорости диска, даже если модель восстановления Simple

По логам журнала производительности все упираеться в проц, а не диск, насчет компонеты romix-а похоже придеться удалить или кто нить знает в чем проблема? сам romix что то не отвечает

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

сам скуль по логам жрет не более 25 процентов в час пик(обычно 10),больше всего отжирают процессы 1сv7s, на остальные процессы,которые по моему и есть терминальные, приходиться не более 10. Так что особого прироста производительности от разделения по моему не будет,или я ошибаюсь? Есть вариант разделить базу и узеров на две части, однако возникнет проблема оперативного обмена между ними через Центральную базу

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

В смысле не делают документы?Куда убрать? как они с базой будут работать?

локально пусть отчеты формируют

типа, закупить локальных копий 1с? как с базой контакт то будет? Хотя все равно беспанту тем кто не делает все равно нужна оперативная инфа, а не через обмен,и у них стоят тонкие терминалы(без винтов)=) Может тогда создать 2 аналогичную базу чисто для отчетов, где оперативность не столь важна? Однако деление базы на два сервака это уже другой вопрос.Интересует все таки как можно увеличить производительность данного конкретного сервака, например компонента ромика помогает, только вот ошибки сводят плюсы на нет.

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

+1

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

Поподробнее как именно

Проблема с падением 1С видимо связана с автообменом. Если идет автообмен, и одновременно пользователи создают документы, то валится кажется с такой ошибкой. Можно распараллелить эти задачи, например при помощи сигнального файла (чтобы пользователи ждали, и не создавали свои документы, пока идет автообмен). Фирме 1С это сделать было бы проще...

куда уж подробнее... обычно 1С как-то и без терминала работает, но все работают в одной базе ;). И здесь надо сделать так, исключая операторов (их оставить в терминале). p.s. Это не панацея это перенос небольшой части нагрузки с сервера терминалов. У нас на таком объеме (база чуть меньше, пользователей чуть больше) работало 2 двухпроцессорных сервера с дисками SCSI (диск для каждого файла БД - свой).

все ракомендуют только решения за счет увеличения мощьности системы разнесение на разные компы SQL и Терминала и т.д. А почему никто не рекомендует решение на уровне оптимизации самого софта. - проанализировать наиболее узкие места по производительности и исправить их Как правило этого хватает с головой без модернизации железа. Если найти узкое место , как правило это проведение документа , н-р, "РасходнаяНакладная" и более оптимально переписать проведение (1с++, ToySQl)? то можно получить увеличение скорости в 7-10 раз. Модернизацие железа и разнесением никогда не получить этого. Естественно это требует более высокой квалификации специалиста, но оно стоит того.

+ 18 Н-р, если в минуту проводиться (3-4) документа , каждый из которых проводиться 30-40 секунд, то только оптимизация софта приведет к желаемому результату. Железо уже никак не моможет. Хотя возможно для это не актуально :)

+ 18 конечно все советы верные - разнести SQL и терминал на разные машины (возможно покупка нового сервака!) - разнесение файлов данных и лога на разные диски + RAID10 (возможно модернизация рейда) - использовать компоненту romix (бесплатно :)  ) - но сколько на это нужно еще средств (железо) ? - и будет ли тот эффект , которого ты ожидаешь ? Поэтому подумай еще в сторону оптимизации софта: - прямые запросы (1с++, ToySQL) - гибкие блокировки (софтПоинт или сам , если сможешь :)   )

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

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

+ 22 а вообще конечно оптимизация это большая задача. В любом случае нужно сначала понять слабые места системы: - железо (серваки+раб.станции) - сеть - софт а потом уже ставить диагноз и как это лечить :)

16 т.е решение только в установке режима ожидания при обмене?, блин не подходит, покупатели ждать не любят 18 19 Кинь несколько ссылочек на эту тему оптимизации софта. В минуту вполне вероятно до 10 проводок, по наблюдениям в час пик длительность проводки не более 10 сек 21 По моему загружают сервер больше всего проводки и отчеты 22 обмен каждые 15 минут, длиться около минуты, тормоза конечно увеличиваються, но не сильно

прямые запросы к SQL Server из 1с : - компонента 1с++ (бесплатная) ---- сайт разработчиков и форум ( ) - компонента toySQL (платная) ---- сайт разработчика и форум ( )   гибкие блокировки : - сайт компании СофтПоинт ( )

терминал и SQL на одном сервере не есть гуд, даже если устранена проблема с некорректной загрузкой сервера. так что за программную оптимизацию пока рановато браться. надо терминал и SQL Server разделить, под SQL Server можно поставить менее мощный комп. оптимизация софта может только увеличить нагрузку на сервер (SQL). так что для начала надо разобраться с аппаратной частью.

"некорректной загрузкой сервера" - имеется ввиду загрузка процессора при ожидании блокировки конечно.

Всем спасибо за отзывчивость=) Попробую поставить второй сервак чисто для отчетов, если не поможет разделю скуль и терминал. Пользуясь случаем, хочу спросить реиндексация через пакетный режим 1с и использование команд дефрагментации в скуле DBCC INDEXDEFRAG, DBCC DBREINDEX это один и тот же процесс?

>>>По моему загружают сервер больше всего проводки и отчеты отчеты не сильно тормозят базу и уж точно не блокируют ее а именно проведение доков при проведении доков блокируется полностью таблица документов _1SJourn а при ее блокировке при параллельном проведение 1С ждет ее освобождения. в данный момент переделываю систему на 1с++. переделав проведение по логике 1с (то есть каждая строка таблицы документа рассчитывается проверяется и записывается в регистр потом следующая) достигнут прирост в скорости от 2 до 5 раз. но по логике 1С - это тупая логика. при нахождении ошибки в доке он обламывает проведение и как бы откатывает все что сделал представь если это отчет ККМ где 200 строк и например 105 строка отваливается. а потом 106-я 107-я сейчас переделываю так что бы сначала проверялась вся табличная часть на возможность списания, а потом уже проводилось если нет ошибок

вот

",и у них стоят тонкие терминалы(без винтов)=) " - и "они" Ворд-Эксель-ПасьянсКосынка прямо на серваке фотошопают?! Где в это время крутится СКЛ-сервер. М-мм, да..

Болеете?

31 те кто сидит на тонких терминалах, Юзают токо 1с

Народ шринк базы увеличит быстродействие?