157-Путевый лист > Минимум нужно проведение по партиям и взаиморасчетам отдать роботу, в интерактивном режиме их не двигать. Функции:
глПолучитьОстатокЦену()
глПолучитьРозничныйОстатокЦену()

переписать на прямых запросах. За точные названия не ручаюсь - уже 4 года как завязал с костылями...

взаиморасчетам возможно и не получится. любят куроводитель смотреть и по взаиморасчетам может приниматься решения о возможности приема заявок вообще (а не только отгрузки).
.
партии - тоже может не получиться. если нужно указание хоть чуток приближенное к реальностив по ГТД в счф.
.
по остаткам/цене - на прямой однозначно.
может пригодиться
[url]http://infostart.ru/public/76287/[/url]
.
также еще ускорение может дать параметризированный запрос (о блин какие я слова знаю)

[quote=Путевый лист;29762868]145 Чучундер. Перевел базу в sql на новом сервере. попробовал просто через "проведение документов" перепровести проведенные с 01.01.2013 - жуткие тормозаЧто за напасть??? [/quote]
Я же тебе десяток раз говорил, что в твоем случае скуль нужно использовать с прямыми запросами, иначе будет тормозить. Мы же с тобой даже тесты делали.

ну хз... по совему общению со скульной базой перепроведение на скуле не так уж сильно отличается от файловой.
.
Аффтар!! смотри внимательно на закрытие регистров. на всякий случай. еще раз.

163 Billi - Да что-то как-то все-таки тормозит. Ну будем воевать. Но пусть все так, но ведь я ТИИ на скулевой базе запустил - идет уже второй день, а ведь я галку на пересчет иотгов не ставил
164 - Вот и мне не верится что такая разница должна быть

У меня до недавнего времени тоже была немаленькая база на ДБФ. 40+ пользователей из них 30 активных, 3000 документов в день, создается 50 тыс. различных элементов справочников. Размер самых больших файлов: 300 - 700 МБ (регулярная обрезка раз в год).

Конечно же терминал. Сервер средненький - Xeon 2.66 ГГц, 4 ядра, 8 ГБ памяти. Временные файлы на RAM-диске. Хороший рейд-контроллер, 2 САС-диска в рейд 1. Ну и самое главное - Windows Server 2008 R2. Проблем с производительностью не было никаких. Но были дедлоки :(((((((( По нескольку раз в день. Причем разрулить их можно только вручную - наобум срубая наиболее активных пользователей до тех пор пока не заработает. Причем это проявляется только на WinSrv2008. На другом сервере с WinSrv2003 и похожей нагрузкой нет никаких проблем. На другом 2008-м тоже есть дедлоки, но там активность пользователей мизерная (в пять раз меньшая) и проблема почти не проявляется.

Намучившись с дедлоками и преследуя повышение сохранности данных решился на переход на SQL. Скачал секретный релиз 27.1, установил SQL Server 2008 R1. Погонял на тестовой базе. Тестирование показало, что формирование отчетов ускорилось десятикратно (отчет за месяц - секунда, за год - несколько секунд). На этом хорошие новости о производительности закончились... Проведение замедлилось в несколько раз. Если раньше в секунду проводилось 100+ документов, то сейчас 20-30. Причина понятна - при проведении активно используется получение цен (а они у меня хранятся в нескольких справочниках). Т.к. конфигурация была оптимизирована именно под ДБФ-вариант, то активно использовался обход справочников через ПолучитьЭлемиент().
Так что кандидат на переписку на ПрямойЗапрос есть.

Следующее огорчение - журналы документов. Если период журнала месяц и больше, то работать почти невозможно - тормозит страшно с невероятной загрузкой SQL-сервера (один человек нагружает одно ядро процессора). Пришлось не откладывая переписать модули журналов почти всех документов. В зависимости от установленного отбора вводится ограничение на период (чем строже отбор (меньше выборка), тем больше разрешенный период). Стало приемлемо. До скорости ДБФ-варианта далеко, но тормозить перестало.

Далее огорчили списки справочников. Есть очень часто используемый справочник на 200+ тысяч элементов. Поиск по первым буквам наименования очень медленный - одна буква в пару секунд. Причем чем дальше первая буква находится в алфавите тем медленнее. На букву Б ищет моментально, буква Ш - запаришься ждать. Причина тормозов пока не выяснена.
В планах провести оптимизацию с помощью прямых запросов и ПоставщикаДанных.

В настоящее время база в боевом режиме на SQL-варианте отработала 2 недели - полет нормальный, ни одного дедлока. Нагрузка на процессор сервера выросла незначительно - средняя загрузка 15%. Памяти, конечно, отъел всю. После обрезки базы размер ДБФ-ов стал 1.5 ГБ. После загрузки в SQL заполнение файла данных стало 3.2 ГБ.

Чучундер - Обнаружил такое дело. Все проведение дополнительно тормозит из-за того что в конце модуля проведения любого документа идет запись в лог. Глобальная процедура записи такая:
//Если ТекущаяИБЦентральная()=1 Тогда
//Если Константа.КонтрольКредитаПолный=1 Тогда
// Тхт=СоздатьОбъект("Текст");
// Если ФС.СуществуетФайл(КаталогИБ()+"log_doc.txt")=0 Тогда
// Тхт.Записать(КаталогИБ()+"log_doc.txt");
// КонецЕсли;
// Тхт.Открыть(КаталогИБ()+"log_doc.txt");
// Стр=""+РабочаяДата()+";"+Конт.ДатаДок+";"+Конт.НомерДок+";"+Конт.Вид()+";"+ВремяНачало+";"+ВремяКонец+";"+ИмяПользователя();
// Тхт.ДобавитьСтроку(Стр);
// Тхт.Записать(КаталогИБ()+"log_doc.txt");
//КонецЕсли;
//КонецЕсли;
[b]Замедление процедуры проведения каждого документа 4-6 секунд
Завтра попробую. Думаю ээфект будет приличный. Но я как-то и не ожидал, что будут такие тормоза!!![/b]

Чучундер - думал, что мне мешает генерация внешнего события, котоорую я вставил в конце модуля проведения чека - ни фига не мешает, а вот запись в лог оказывается и есть приличный тормоз!!!

(168)а чего не журнал регистрации? Убирай эту ерунду, чем больше файл, тем дольше объект "Текст" его открывает, тормоза уже на паре мегабайт заметны.

169 Sasha - ДА фиг бы меня знал, зачем я так сделал. ДАвно очень было. Размре текстового файла на сегодня 29 мегабайт
[b]Завтра попробую - должен быть эффект судя по тому что я на копии сейчас вижу[/b]

169 Sasha - да и смысла мне в лог писать эту инфу давно уже нет. Я и так знаю что у меня документы проводятся внутри секунды!!!

166 Ветер в поле - Все что Вы описываете очень похоже на то что у меня получается на скульной базе!!!
1. Новый Сервак у меня весьма мощный с 6-ю сас дисками, скуль 2005, секретный релиз 1С стоит.
2. Групповое проведение тормозит на реализациях и отчетах ккм. Возможно это связано с четырьмя незакрывающимися регистрами - теперь я их закрою
3. ТИИ шло 2 дня что странно, поскольку ошибок и не нашлось.
4. А вот открытие периодов довольное шустрое и попытка перевести режим остатков на 5-дневный тоже получилось более-менее быстро а дбф-ная база просто зависла насмерть.
[b]Вот пока такие впечатления!!![/b]

169 Sasha - ну да, буду писать начало проведения в журнал регистрации, а конец проведения там и так пишется сам собой

(171) уф!!! я ж грю - все зависит от частностей. никто лучше тебя, не знаю, код твоей базы не разрулит.

[b]Всем Всем всем - База просто летает!!!. [/b]Теперь можно будет работой заняться. Ну надо же так лопухнуться. Получилось что запись в лог информации о проведении документов через текстовый файл - тормозила проведение каждого документа на 4-6 секунд

.



НУ Я ВАС ПОЗДРАВЛЯЮ!!!!


ходить по граблям, которые сам разложил - это типично для одноЭсников

176 - Helen1986 Спасибо. Но зато теперь я твердо уверен что дело не в железе (с ним все нормально), ни в сети (ее скорость приемлема),и не в 1С, а в моих ошибках. И это очень здорово, потому что в своих ошибках я как-нибудь да разберусь!!!

(177) ну не все и не всегда разбираются в своих ошибках

а вообще то если было все нормально - ясно что дело однозначно не в железе (исключение -рейд)

(175) ну, блин, я аж вздохнул свободнее...
вспорминай, я ж говорил тебе - гораздо раньше, что нечему у тебя там тормозить при таком документообороте, ищи всякие свои допрограммирования/транзакции и прочее..
вот и забороли!
.
уфффффффффф

179 Чучундер - сплюнь пожалуйста три раза и постучи по деревяшке. Я вот сегодня себя весь день по голове стучу :(((

(180) посмотри, возможно полезно будет по товей предметке: [url]http://infostart.ru/public/102847/[/url]

181 Чучундер - Спасибо. Поведай как ты эти конфетки находишь!!!

9182) вот ты сейчас дрыхнешь без задних ноя. а я - нет...

(183): а щяс?..

(184) не знаю где ваше щяс, а я по-прежнему - здесь... некоторые дворники, типа меня, не то что встают рано, они - вообще не ложатся..
.
А ктулхи всякие дрыхнут да ибд
.
[img]http://i1.photocentra.ru/images/main35/354793_main.jpg[/img]
.
а мне как роботу впахивать приходится
[img]http://apikabu.ru/img_n/2011-05_7/c0da0e.jpg[/img]
.

!!! Летает база. Офигеть как летает. 40 пользователей, 6 гиг - и все равно летает. Юзеры в шоке :(((

(186) а ты в запое от радости что тебя не убили..?
40 пользователей - нечему там тормозить на твоих объемах - так оно и оказалось!!! а если еще чуток прямыми запросами где надо подшаманишь - все.. про снеговика можно забыть...

(187) а давай путёвого листа прибьём? Чтобы не загордился

(188) не надо! пусть будет счастье чилавегу!

188 Helen1986 - Да нечем мне особенно гордится. Вот радоваться есть чему - я и радуюсь. А так как белка в колесе. Подчас все дико надоедает, но в списке Форбс себя не нахожу - вот и тружусь :(((

187-Чучундер > *хрюкнул*. Вот у меня сейчас в лапах база для доработки напильником - говорят работает невыносимо медленно первую половину дня. Снеговик. УТ 10.3 исписанная 2-мя поколениями фикси больше вкривь, чем вкось. 50ГБ, 8 магазинов полсотни рыл в крейсерском режиме, автозапчасти, только зарегистрированного ассортимента больше 100 000 позиций. И что я вижу - последние рассчитанные итоги в 2010-м году. А этот выкидыш даже шевелится. Понятно, что кроме итогов проблем хватает - уже тут художеств понавырезал. Ща еще платформу обновлю, заведу работу по Shared Memory, итоги пересчитаю, таблички дефрагментирую. Завтра поглядим станет ли легче. А, да, тут еще и партии оперативно списываются. Интересно даже что сталось бы с ТиСом в такой ситуации?

(191) чего то маловато у них номенклатуры. Должно быть раза в три больше только на европейцев. А еще ипонцы прули.
Реальные остатки по рознице + склады - тысяч 50 наименований, количество правда небольшое каждого наименования. Поддержка актуального запаса примерно 8-10 тыс наиболее ходовых деталей на европейцев + ипонцев. Поддержка актуальной системы аналогов. 4 оператора на приходах и поддержке аналогов.

терминал, 2 больших магазина, штук 5 точек с одной кассой и 2-3 компами, розница, позаказная торговля, отдел комплектации своих СТО. В пике набивается до 45-50 человек. Списание партий на лету. цены - деревянные, зелевые и еврики.

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

скуль + терминал локально или через инет
база летает. тормозит инетовский канал (3 провайдера для подстраховки). До 1500 доков в день (разные, от 1 до 50 позиций).

Обслуживание на СТО - другая база тоже в терминале, база единая для всех СТО. Импорт номенклатуры под заказ из первой базы (клиент заказывает детали под заказ, ремонт на СТО. Расчет на СТО).
в СТО-шной базе хранится история ремонтов машин (идентификация не по владельцу, а по win). история
лет за 5 (исторически сто-шная база более древняя)


базы- клюшки

основные проблемы там не 1це
а поиск каталожных номеров деталей которые надо заказать по конкретному win номеру.

также проблема - на больших заказах со своих СТО или стронних - заказ идет к сроку, поставщиков от 2 до 5-6 и все это надо увязать по срокам - чтобы человек мог подогнать машину к определенной дате и отдать 1 раз в ремонт и не ждать поступления.

Это задача решается не в 1це, но часть информации берется из 1це на лету

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

всё не читал. если итог в (167), то ветка грустная.

(191) гони волну в другую сторону. После двух поколений фикси - оно хоть работает. После двух поколений фришников - оно бы давно здохло, знаем вы вас, бегунков...

(192) здоровско!
вот еще на клюшках аналогичная вещь по автозапчастям (там в мультике даже табло на 7.7)
.
[url]http://www.youtube.com/embed/lVAcYXwMJVM?autoplay=1[/url]
[url]http://www.youtube.com/embed/GVA-E2vigNo?autoplay=1[/url]
.

(197) ну до такого уровня фирмешка еще не доросла, но стремится.
главное - директор, он же владелец, развивает свой бизнес и не жлобится на оплате персоналу

195 Зелёный тролль - Понятно что боевики интереснее чем мелодрамы :(((
Но мне теперь куда легче будет работать, поскольку я абсолютно точно знаю, что если что-то опять начнет тупить - то "искать проблемы будем мы в себе!!!"

192-Helen1986 > Петя, ты снова спалился.
Не надо было упоминать про твои эпопеи с автозапчастями, они здесь слишком хорошо известны.