| 0
- 22.03.2013 - 16:02
|
1С 7.7 ТИС База ДБФ 6 ГБ на терминальном сервере windows 2003, юзеры все в своих папках. стоит патч убирающий 100% загрузки процессора от Кернел37. Антивирус убран, кеширование работает!!! Блокировки 1cjornal идут очень часто. Причем день на день не приходится. Например во вторник все было практически без проблем. Но вот сегодня прямо с утра какой-то кошмар. 1. Был выключен комп, на котором находится один из принтеров, подключенных к юзерам на терминальном сервере - это фишка известна - вот только как с ней быть??? 2. При создании платежек (которые ведь вообще не проводятся) путем копирования старых возникает ожидание блокировки, хотя вылета не происходит 3. При изменении фирмы в платежке (то есть при изменении номера документа (префикс ИБ+префикс фирмы)тоже идет ожидание. 4. При создании документа счет-фактуры кнопкой в проведенной накладной опять ожидание блокировки и вот тут начинаются вылеты по истечению времени, отпущенного для ожидания блокировок 5. Ну и т.д. НО ВОПРОС У МЕНЯ ТАКОЙ: возможно в моей переписанной ТИС много операций типа Док.Новый, Док.НайтиПоНОмеру, всякие автоперемещения и пр. Док.ВыбратьДокументы ну и т.д. ЧТО НЕЖЕЛАТЕЛЬНО ИСПОЛЬЗОВАТЬ??? В КАКОМ СЛУЧАЕ ПЕРЕМЕННЫЕ НАДО ОЧИЩАТЬ??? ПРОСТО ХОТЬ КАК-ТО СОСТАВИТЬ ПЛАН ПОСЛЕДОВАТЕЛЬНОГО НАСТУПЛЕНИЯ НА ЭТИ ПРОБЛЕМЫ И С ТОЧКИ ЗРЕНИЯ ЗАГРУЖЕННОСТИ СЕТИ И С ТОЧКИ ЗРЕНИЯ ОПТИМИЗАЦИИ РАБОТЫ В 1С. Я ГОТОВ НОЧИ И ДНИ СИДЕТЬ И КРОПОТЛИВО ЭТО ДЕЛАТЬ!!!     | | |
| 1
- 22.03.2013 - 16:12
| пункт забыл: сервант от батареи отодвинуть | | |
| 2
- 22.03.2013 - 16:28
|
"ДБФ 6 ГБ" - мусьё знает толк в извращениях... обрезание базе сделать не вариант? | | |
| 3
- 22.03.2013 - 16:39
|
Что о можно сделать: 1. Тестирование и исправление 2. Обрезка базы 3. Режим открытия объектов "Просмотр" 4. Уменьшить время "Период опроса изменений базы данных" 5. Увеличить "Время ожидания захвата таблиц" 6. Убрать(оптимизировать) алгоритмы проведения документов - добиться быстрого проведения, переход на прямые запросы и т.д. 7. Не нарушать границу последовательности, проводить документы оперативно со сдвигом ТА 8. Переделать интерфейс основных документов и списков справочников на ТП + поставщик данных 9. Переписать отчеты на прямых запросах 10. Перейти на SQL 11. Почистить историю периодических элементов 12. Обрезать базу 13. Уменьшить число юзеров ;) Насчет извращений - попадалась мне база 15 Гб на DBF - тяжеловато, но работала | | |
| 4
- 22.03.2013 - 16:44
|
Еще забыл 14. Перейти на снеговика | | |
| 5
- 22.03.2013 - 16:47
|
(3) "Насчет извращений - попадалась мне база 15 Гб на DBF - тяжеловато, но работала" ога, если одному монопольно работать) | | |
| 6
- 22.03.2013 - 16:55
| туповатых юзеров расстрелять уже было? | | |
| 7
- 22.03.2013 - 17:47
| из 3-ёх: быстро, качественно, недорого — выбирайте любые два пункта.. | | |
| 8
- 22.03.2013 - 17:50
| Путевый лист, упустил из виду: размер самого большого DBF и CDX? | | |
| 9
- 22.03.2013 - 19:05
|
Продолжаю!!! 1. База обрезана в конце 2012 года на начало 2010 года. Три периферийных базы + магазин на 8-ке с постоянным обменом с ТИС. 2. ТИИ ничего не показывает 3. Документы проводятся достаточно шустро. Скорее долго работают процедуры ПриЗаписи. 4. Граница сбита. Вот тут пока ничего не поделаешь. Думаю над этим 5. Почистить периодические реквизиты - такая мысль приходила в голову, хотя цены почищены при свертке. 6. Удаленно в базе работают менеджеры с магазинов. Делают перемещения к себе и т.д. 7. Юзеры работают в терминале!!! Время ожидания захвата таблиц баз данных = 10 И такое же время периода опроса!!! 8. Максимальный размер файла - RA328 - 1,025 ГБ, следубщий за ним RA2351 - 455 МБ. 9. Довольно большой размер журнала регистрации - 345 МБ 10. Я просто видел буквально от 18 марта на мисте похожую ветку | | |
| 10
- 22.03.2013 - 19:11
| По симптомам видно что блокировка идет в момент создания и выделения новых номеров. рыть в этом направлении. | | |
| 11
- 22.03.2013 - 19:12
| (5) Кста, на Исе есть толковая статья на тему убирания записей с нулевыми итогами. похудание базы при этом - весьма приличное. | | |
| 12
- 22.03.2013 - 19:24
|
10-Чучундер - как рыть??? Ума не приложу пока что И дай ссылку на ИСУ пожалуйста Просто раньше я в-основном занимался учетом. А теперь надо чтобы учет был оптимизирован с точки зрения работы с базой данных Может быть у меня сетка перегружена??? Как понять это??? | | |
| 13
- 22.03.2013 - 19:36
|
(12) http://forum.infostart.ru/forum24/topic81618/ и комменты там почитай | | |
| 14
- 22.03.2013 - 19:41
| 13 - Чучундер. Ну да, только это для 8-ки да еще как я понял скульный вариант, а у меня ДБФ и 1С 7.7 | | |
| 15
- 22.03.2013 - 19:42
|
хз.. смотри алгоритмы - может у тебя там при активном листании юзерами общего журнала - какие-нить выборки считаются, показ подчиненных документов и прочее..??? и что-то "лочит" журнал..??? . запости копию ветки на мисту - там Епрст и КонецЦикла часто сидят - они могут подсказать. . на Исе напиши в личку hogik - он может толково помочь (ну по крайней мере диагностировать проблему поточнее) - если захочет/заинтересуется конечно. . при том документеобороте который у тебя там генериться - ну нечему там активно держать таблицы. . при активном УРБД, который возможно у тебя регулярно грузится/выгружается - должна же обеспечиваться целостность данных в файлах обмена - выгрузка/загрузка идет в транзакции (наверное?) - попытки сделать онлайнбазу из УРБД с мегаактивными обменами + накладывается иногда активность юзеров - плюс стопудово регулярные исправления заявок/перемещений задним числом - вот и получаешь. Убирай нафиг псведоонлайн и проведения задним числом максимально уменьшить (толькол для исправления уже после отгрузок по рекламациям клиентов, при оперативной работе - закрыть!!!!) | | |
| 16
- 22.03.2013 - 19:43
|
(14) а) читай ветку на ИСЕ б) читай комменты - там четко сказано что и для 1С и файлового варианта это точно также примменимо. . БУДЬ ПЕРДЕЛЬНО БЗДИТЕЛЕН | | |
| 17
- 22.03.2013 - 19:43
| 10 - Чучундер (По симптомам видно что блокировка идет в момент создания и выделения новых номеров. рыть в этом направлении.) Как с этим сбороться. Я думаю что из-за всех этих префиксов у меня таблица содержащая номера - замусорена!!! | | |
| 18
- 22.03.2013 - 19:48
|
16- Чучундер А в какой таблице посмотреть мои номера и что с ними творится??? По поводу работы задним числом и кучи обменов согласен - но вот начальство хочет все в таком режиме видеть. Мне кажется, что дело все-таки еще и в неоптимальных методах которые я использую, в очень частом обращении к Константа.ПрефиксИБ. А все-таки в константах как я понял - сидит вообще вся периодика - таблица 1SBConst | | |
| 19
- 22.03.2013 - 19:49
| 16 - Чучундер. И еще. Документооборот за день примерно одинаковый по дням. Но вот бывают всплески нехорошие. КАК ОТСЛЕДИТЬ ИХ ПРИЧИНУ??? | | |
| 20
- 22.03.2013 - 19:59
| (17) я вот про это и думаю.. но тут моих знаний не хватает. возможно надо посмотреть на таблицу последних использованных номеров в части отсутсвия "конфликтов" по префиксам и базам...? проверить чтобы нигде не было разных ПБ с одинаоквыми префмиками... я не спец - НАПИШИ НА МИСТУ - там поболее активных по этой части. | | |
| 21
- 22.03.2013 - 20:00
| (19) это не показатель. смотреть надо "пиковые" нагрузки | | |
| 22
- 22.03.2013 - 20:14
|
21 - Чучундер. Да смотрел я на мисту твою ветку http://www.forum.mista.ru/topic.php?id=639769 Но так ничего точно для себя и не вынес. Поэтому хотя бы пока довольствоваться тем что возможно. А уже потом что необходимо!!! Все-таки работа с ссылками созданными через СоздатьОбъект("Справочник или документ") насколько тормозит работу??? И какие методы в наибольшей степени ее тормозят. База-то живаяя и распределенная. Очень стремно программую систему коверкать!!! | | |
| 23
- 22.03.2013 - 20:16
| 21 - Чучундер. Вот если мы написали ДокБУхт=СоздатьОбъект("Документ.ДВижениеБухт) и потом используем ее на протяжении длинной процедуры, что будет если другой пользователь (работа же в сети) обратится к этой же процедуре??? | | |
| 24
- 22.03.2013 - 20:19
| И что делать когда с тура выключены компы на которых стоят принтеры, прописанные у терминального пользователя??? Это же жуткие тормоза создает. | | |
| 25
- 22.03.2013 - 20:51
| (24) принтеры перевести на принт-серверы. | | |
| 26
- 22.03.2013 - 20:53
| Вот ты утомил. Твои ощущения, не подшиваемые к делу уже достали. Где статистика по продолжительности транзакций и вкладу видов документов в ожидания? где замеры производительности? Объясняю - первое что нужно сделать это разработать структуру csv, которые будут писаться в папки пользователей и грузиться в excel для анализа. На входе в системную транзакцию записи документа фиксируешь время начала с точностью до миллисекунды используя wsh. На выходе фиксируешь время окончания и продолжительность и сбрасываешь все в csv. Подключаешь сие ко всем документам. Ставишь время ожидания на блокировках в ноль и неделю терпишь звездюли от всех пользователей. Потом стопоришь сбор логов и возвращаешь на место время ожидания. Берешь логи, грузишь в excel и вдумчиво изучаешь. Продолжительности транзакций в разрезе дней, часов, общие пики, частные пики чтобы выделить транзакции с наибольшей продолжительностью. Получаешь первый список - документов требующих оптимизации в порядке убывания их вклада в общую беду. Выбираешь из списка документы, дающие 80% нагрузки. После этого берешь первый документ, берешь отладчик и начинаешь нудную работу по уменьшению времени его записи. Потом второй. И так по всем тяжелым. Потом вливаешь в базу и начинаешь мониторинг заново. И так крутишься пока не заработает, или не поймешь, что пора уже отправить клюшки туда, где им место. | | |
| 27
- 22.03.2013 - 20:53
|
(23) пользователю пофиг процедуры исполняющиеся у другого пользователя. Каждый пользователь работает со своей копий программного кода, который исполняется в его "адресном пространстве". . Если сделал создать объект - то хз.. ничего не будет - читать и писать через объект могут каждый пользователь у себя. а вот если такая хрень написана ВНУТРИ ТРАНЗАКЦИИ - ну тут наверное блокируется вся таблица этого объекта метаданных.. и что там будет в итоге - хз... | | |
| 28
- 22.03.2013 - 20:55
| (22) не надо смотреть мою ветку, она вообще немного по другому вопросу. сабж в (0) продублируй на мисте - там больше спецов и вероятность получить полезный совет гораздо выше чем я тут один не особо спец корячусь. | | |
| 29
- 22.03.2013 - 21:02
|
26 - reaper у меня логи проведения документов пишутся. Правда не через wsh. Но речь идет о моменте когда срабатывает УстановитьНовыйНомер(Константа.ПрефиксИБ+ПрефиксДо кументтов по нужной фирме). Вот здесь у меня что-то не так - чувствую чувствительным местом :((( На входе в системную транзакцию записи документа фиксируешь время начала с точностью до миллисекунды используя wsh ТЫ ИМЕЕШЬ В ВИДУ ОБРАБОТКУ ПРОВЕДЕНИЯ??? | | |
| 30
- 22.03.2013 - 21:13
|
29-Путевый лист > При анализе производительности не нужно чувствовать. Есть точные показатели выраженные в цифрах. Пока ты их не приведешь - не о чем разговаривать. Цитата:
| | |
| 31
- 22.03.2013 - 21:20
|
30 Reaper Тогда вопрос: так в каких местах надо ставить запись в логи??? Во всех предопределенных процедурах??? На входе в системную транзакцию записи документа - так где этот вход??? ПриЗаписи и в ОбработкеПроведения и в УстановитьНовыйНомер()??? И все-таки как проверить что у меня творится в номерах документов??? Что абсолютно точно - так это то что УстановитьНовыйНомер тормозит. Создание с/ф на основании реализации тоже частенько просто выбивает транзакцию. Ну там идет проверка через Журнал подчиненных. | | |
| 32
- 22.03.2013 - 21:33
| Цитата:
| | |
| 33
- 22.03.2013 - 21:45
|
(31) Сделай как Столбик говорит. Поставь запись в логи в обработках проведения на входе и во всех точках выхода (это конечно грубо будет, потому как объект блокируется в момент первого обращеняи к нему, но для начала сойдет). И поставь запись в лог до и после установить новый номер. . И ПОСТАВЬ ВОПРОС НА МИСТУ. те что - лень там зарегится? | | |
| 34
- 22.03.2013 - 21:46
|
(31) Сделай как Столбик говорит. Поставь запись в логи в обработках проведения на входе и во всех точках выхода (это конечно грубо будет, потому как объект блокируется в момент первого обращеняи к нему, но для начала сойдет). И поставь запись в лог до и после установить новый номер. Ну и не забудь в явных транзакциях то же самое. . ПриЗаписи() никаких транзакций в самой процедуре - не порождает. . И ПОСТАВЬ ВОПРОС НА МИСТУ. те что - лень там зарегится? | | |
| 35
- 22.03.2013 - 21:54
| Цитата:
| | |
| 36
- 22.03.2013 - 21:55
|
34 - Чучундер. Да зареген я на мисте даынм давно. Просто как-то привык к Т1С. А где найти входы выходы в транзакции - это уж, извини, твоя забота. Изучай документацию, качай скиллы по работе с данными на физическом уровне. Если бы еще знать что изучать и что такое скиллы | | |
| 37
- 22.03.2013 - 22:04
|
SKILL - уровень владения чем либо. Показатель мастерства и крутости. . Вот у меня по горным лыжам (не профессионалы и не люди зарабатывающие этим) - скилл где-то в районе 6 из 7 балльной шкалы. | | |
| 38
- 22.03.2013 - 22:04
|
Начни с чего-нить такого: http://citforum.ru/database/dblearn/dblearn10.shtml Как въедешь в общую теорию ищи описания логики работы клюшек с этими механизмами. Я на форуме 1cpp в свое время нахватался. Не знаю как сейчас. После этого ты хотя бы сможешь понять как начать экспериментировать с платформой, чтобы определить точки входа/выхода блокирующих транзакций в обработчиках событий встроенного языка. И сразу говорю - одной статьи мало. Волшебной таблетки не существует. | | |
| 39
- 22.03.2013 - 22:05
| (35) разуй глаза ;-) !!!_В процедуре_!! ПРИЗАПИСИ() - ничего не блокируется. | |
Интернет-форум Краснодарского края и Краснодара |
