Быстродействие (ОперУчет 7.7) в каком направлении двигаться? #108186

ТиС 7.7, dbf, объем базы 2ГБ, Win2003 Server, терминал, 15 пользователей. Сервер P4 3ГГц, 1ГБ оперативки. Транзакция при проведении доков = несколько десятков секунд. В каком направлении решать проблему:переход на SQL, смена железа, оптимизация сервера. Интересует наиболее экономный вариант. Хотелось-бы малой кровью :)

еще плюсом ко всему вышеперечисленному не мешает пересмотреть движения регистров и все лишнее убрать нафиг - порой ускорение проведения раза в 2-3 точно :-)...Просто некоторые не используют все возможности ТиС, значит их можно убрать :-)

Этот вариант экономным никак не назовешь :( Тем более в используют практически все (кроме коммиссии и торгового оборудования)

Самой малой кровью (по усилиям) - памяти добавить до 3Гб и поставитьскази диски Raid 5 или 10.

создание ramdrive и перенос темповых файлов 1С на него поможет? И как это с точки зрения надежности?

без двух процессоров никак не получится

в текущем положении загрузка проца во время транзакции далеко не 100%.Значит ли это - что узкое место не проц?

То 6. Нет, не значит. И вообще процент загрузки проца - это показатель для домохозяек. Не пойму зачем Билли вообще им смущает народ.Нужно запускать perfmon и анализировать показания счетчиков в критических местах.У меня при 15 юзверяз и одном проце была очень занятная очередь запросов к процу - в среднем 18. После установки второго проца она уменьшилась до 2.

Что такое "темповые файлы 1С"? Если это своп-файл Wind-ов, а разве винда разрешает свой своп-файл в ramdrive размещать?Всю базу на ramdrive я бы не перенес, побоялся. Если 2-х проц, то лучше сразу новый сервак покупать. От $4000. Уже не так дешево. Какие счетчики лучше запустить? Сколько их смотреть?

по поводу проца понял. Как насчет вопроса в ?

размещением темповых файлов можно управлять при запуске 1С через параметр -t.

То 9. Очень легко нарваться на ситуацию переполнения диска. 1С часто складывает в темпы большие файлы. Особенно при запросах, оперирующих большими наборами данных. При этом программа просто молча сворачивает тапочки.Если сумеешь создать RAM-диск достаточного объема, то ускорение можно получить. Если нет, то можно получить геморрой.

http://www.1csql.ru/advert.html?id=142

спасибо, я так и подозревал.

Чего-то я не пойму - ещё никто не спросил когда тормозит?(А то может у него операторы на приёме заявок с временным расчетом сидят...)

1GB - очень мало.Раз терминал, поставь время ожидания захвата 0.Основная загрузка проца идет не в транзакции, а приожидании ее (так уж криво сделано)

Два проца.Терминал.На 15 юзеров 1Г памяти хватит.

временного расчета нет, все в ТА если можно - где это время ожидания захвата указывается?

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

Cadet см. , отличный вариант

А мне вот интересно - в 1С8.0 проблемы с транзакцией также актуальны как и в 1С7.7 ???

15 пользователей * 50 Мб на штуку + 256 система + 1/4 базы файловый кеш = 2 Гигов мозгов. Хотя 2 может и хватит, тока винты побыстрее и в Райд поставить.

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

Если есть HT, то обязательно включить.Поставь время ожидания захвата таблиц 0-1 сек. (у Орефкова можно взять дллку)Памяти нужно не меньше 256 +50*К-во юзеров, у тебя уже впритык.RAID массив уже обязателен.Рамдиски для 1с - это убогие костыли и подпорки - мнимое временное "дешевое" решение для тех кто не хочет разбираться в причинах проблемы.А вообще давать советы без цифр глупо, отладчик и perfmon в руки , вперед на баррикады!

(23,15) по поводу времени ожидания захвата таблиц - это где и как? К сожалению не знаком с Орефковым. Что за длл-ка? Можно по-подробней.

(23,15) апну разок. Уважаемые, ну выделите квант времени :)

25) Не делай временный расчет, если ТА = ТекущемуДню и будет тебе счастье

То 26. Не счастье, а геморрой, скандалы, разборки и увольнение.

ТиС типовая ?

2 Так он же пишет - ТиС... там и так есть такоеВот могут проводить будущей датой доки - можно это запретить2http://1csql.ru/index.htmlhttp://effes.fatal.ru/supp/recom/recom011.htmhttp://www.snif.ru/pages/len_1cpp.htm

перевести базу на SQL да действиетльно памяти добавить. Добавить еще сервер - базы данных. Я так понял, этот терминальный сервак играет роль и сервера приложений и сервера базы данных. Их нужно разносить - по любому!

То 30. Написано же - "ТиС 7.7, dbf". Какой на фиг сервер приложений ты разносить собрался? :)

Ну... и сюда кидану...http://www.internet.ru/index.php?itemid=11684http://internet.tehno.ru/news14844.html

27) явно видно, что тебе опыта не хватает29) в типовой такого нет.

2 А это что? (модуль док-та Реализация):.Если ИтогиАктуальны=0 Тогда.ЗЫ. Джинна не зли2 Просвяти, плиз

ИтогиАктуальны возвращает актуальны ли итоги на позицию документа, а не на дату

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

2 А так и нужно, ибо ПозицияТА и ДатаТА (РабочаяДата, еще какая-то) - разные вещи

То 33. Спасибо, ТАКОГО опыта мне даром не нужно. Достаточно чисто теоретического анализа возможных последствий. И созерцания ручек граблей, отполированых лбами сторонних практиков.То 34. На самом деле я белый и пушистый :)

http://openconf.itland.ru/vk/prior

Самый экономный - перейти сразу на 8.0, чем полтора года трахаться с разными примочками, а потом всё равно перейти на 8.0.

39) Про захват таблиц вопрос актуальный! А как длл-ку загружать, куда лучше положить, надо ли регистрировать?

Не проще ли для начала запустить замер производительности при проведении?Мож доработки были, или регистры враскорячку?

А на 41) кто-нить ответит?

Ну, может, вечером кто ответит. А то транзакции достали.

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

Самое дешовое = самое необходимое. Память нарастить. Не вредно для любого варианта, хоть с "восьмеркой" ;) А потому можно применить без долгих раздумий...А там можно посмотреть.

Еще раз спрошу: имеется priorities.dll (с) Орефковв ридми не написано, как ее загружать, кто ее использовал, подскажите, плз, как с помощью этой длл-ки сделать "управление приоритетом выполнения1С а также управление временем ожидания захвата таблиц". Лучше кусок кода, конечно. Для наглядности.

типа, ап.

Поддерживаю ТакиеДела. Отключал временный расчет ВООБЩЕ у нескольких клиентов. Стало не просто быстрее работать а летать, к тому же еще и продажи в минуса исчезли. И НИКАКИХ косяков.

Ой-вей! А как делал то? (+)*(+)

(48,Не бейте Ногами)Положи дллку в бин.Если Константа.УправлениеПриоритетами = Перечисление.Булево.Да Тогда //(49,StackOverflow)Любое редактирование задним числом и твоя схема летит вверх ногами.

51) Спасибо!

Ничего подобного. Без временного расчета работа задним числом осуществляется в большинстве случаев более корректно, чем с временным расчетом.Если сомневаешься, приведи пример, попробуем разобраться.

(+53) Ахтунг ! Все вышесказанное касается только опер учета. К бух учету ввиду отсутствия ТА, схема не применима.

(53,StackOverflow)Явный пример:Пустой склад.Приход Товар1 2 июля,1-ым июля создаю и провожу расходную накладную по этому товару,т.к. на ТА остатки есть.

В большинстве случаев применение временного расчета при работезадним числом и приводит к косякам. Это зло. Мне вот напримерудалось добится работы без временного расчета так, что корректноработает и на ТА, и задним числом.

Как удалось, что сделал?

Отлично ты поймал главный косяк.НО давай сравним :Итак в приведенном тобой примере получается, что нарушена последовательность документов. Т.е. расход раньше прихода. Товар фактически есть на складе.----Теперь возмем ситуацию с временным расчетом. Товар был 1 числа, 3-его его продали, а 2-го числа завели документ и продали еще раз. Т.е. продали товар, вообще отсутсвующий на складе. Сработали в минус.----Получается что при решении работать с временным расчетом или без него вылазит дилемма :либо можно продать задним числом в минус, либо у нас может быть неправильная последовательность документов.Очевидно, что неправильная последовательность документов гораздо более безобидна, чем клиент, которому выписали документы, но прокатили с товаром.----ВСЕ бизнесмены, с которыми я обсуждал эту схему (около 15 человек) без колебаний выбирали вариант без временного расчета. Поскольку без временного расчета НЕВОЗМОЖНО накосячить в минуса реализацией.

А ничего специально делать не нужно. просто отключается временный расчет вообще и все.Единственный тонкий момент - восстановление последовательностей и перепроведение необходимо делать только с движением ТА (иначе говоря либо средствами системы, либо специальной обработкой)

+58Просто надо осознать простое правило - нельзя вчера продать товар,который поступил сегодня. И все встает на свои места.Добавляем измерение в регистр - ДатаПрихода. При списывании выгружаемитоги в тз, удаляем те остатки, у которых ДатаПрихода большеДатаДок. И пролетает. А вот в минуса продать - фиг.

красивый вариант, респект !

Меня мучает вопрос, зачем 1С так упорно пихает временный расчет везде в 7.х, а в 8.0 так и вообще отказалась проверять остатки задним числом ?!

Теперь возмем ситуацию с временным расчетом. Товар был 1 числа, 3-его его продали, а 2-го числа завели документ и продали еще раз. Т.е. продали товар, вообще отсутсвующий на складе. Сработали в минус.да нифига. Нужно сравнивать движения по партиям перед записью (по "ОК" или "Записать") и после перепроведения дока. По отклоненному количеству (если такое есть и если оно увеличилось в расходе или уменьшилось в приходе) в фоне строим ведомость по партиям с разворачиванием по докам и если встречаем минус - вываливаем ведомость и не проводим документ. Минус таким образом ты НИКОГДА НЕ ПОЛУЧИШЬ при корректировке задним числом.

2(60,59) - ситуации разные и проведение задним числом бывает необходимо при работе с 1С.в случае - те же грабли что и у 59. У - что то сразу не пойму вообще смысл - чем отличается от измерения документ прихода? У документа всегда есть дата и мы можем ее добавить в ТЗ?На момент списания (вчера) мы видим итоги сегодняшние а не вчерашние, т.е. один и тот же документ при изменении незначительной детали (такие изменения гораздо чаше) проведется скажем по партиям, взаиморасчетам совершенно по другому.Но восстановление посл. снимает все двусмысленности в этой схеме, как скажем и при работе во временном расчете.

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

Вообще странно, почему так зацепились за временный расчет? Или у автора юзвери 80% всех документов проводят задним числом? Проблема то не в этом, скорее всего.

А двигаться скорее всего вот в каком направлении.1. Самое интересное - дата темы - конец месяца. Т.е. остатки выбираются долго. Вариант - может сменить периодичность хранения остатков?2. Если база периферийная, то попробовать сделать выгрузку/загрузку. Заметил на личном опыте вот что. Если делать восстановление последовательности с большим объемом документов, то при заливке этих данных в периферийную базу она начинает жутко тормозить (видимо при импорте изменений не очищаются строки со старыми движениями). Отлично помогает выгрузка/загрузка.

ДатаПрихода приведена для примера. Конечно, лучше использоватьДокументПрихода. В этом случае можно сравнивать то, что расход позжеприхода вплоть до позиции документов, в рамках одного дня,что бы не ввели документ расхода в тот же день, что и приход, но чутьраньше, тк при восстановлении последовательности со сдвигом ТА на документон может не провестись. То что документ при незначительных измененияхпроведется по другому - это не так. Перед проведением старые движенияочищаются, а тк списание идет четко по ФИФО/ЛИФО, док просто вновьповторит старые движения, за исключением измененных позиций.Конечно, при таком способе ФИФО может нарушиться, но это решаетсявосстановлением последовательности со сдвигом ТА. Просто есть гарантия,что в минуса не уйдет, и при восстановлении не вылезут косяки.Такая схема была отработана мной на предыдущей работе и работаеттам до сих пор. Недавно я туда заглядывал после трехмесячного перерыва,все четко.