Долгая загрузка данных в РИБ
 

Доброго времени суток уважаемые!
Нужен совет вот по какому вопросу:
Есть распределенка, данные из периферийных баз сливаются в центральную. Из центральной только конфа и некоторые справочники.
Обмен происходит раз в сутки. В одной из периферийных баз перепроводили документы интенсивно, файл выгрузки получился около 650Мб незапакованный. Так вот проблема - при загрузке этого файла, когда начинают загружаться проводки по НУ резко падает скорость. Причем не сразу, несколько сотен проводок загружаются нормально, а потом время между двумя загрузками по 10-15 минут. Это видно в ЖР (могу скрин кинуть). файл такого объема загружаю не первый раз. Раньше таких проблем не наблюдалось. С какого момента возникла эта проблема не отфиксировал, но никаких действий с сервером и софтом не производилось (кроме обновления конфы в 1с, обновления антивируса и установки обновлений на винду).
Конфа - КА последняя редакция, платформа - 8.2.18.61
Сервер - PostgreSQL 9.1.2-1.1C(x64) с оф сайта 1с. настройки типовые по инструкции.
База в файловой версии была около 17Гб. Но на файловой версии очень медленно происходила загрузка как раз проводок по НУ (в принципе все проводки медленно загружались), поэтому перенесли базу на постгри, стало гораздо быстрее работать, пока не возникла проблема.
ТИИ делал - не помогло.

милай, что ж хочешь
это - восьмерка.

правь колеса

нуууу.... попробуй воткнуть флешку и темпы туда перенаправить. только вернуть не забудь потом.

(1) Спасибо за сочувствие, хотелось бы конкретики.
(2) А что, УСБ 2.0 работает быстрее чем винты? или тут дело не в скорости?

я бы наверное попытался понять кто тормозит, сервер 1с, или постгрес

(4) так то да. но чем измерить? особенно на сервере 1С.

Вот ОНО!!!

Вот оно, время смены прокладки между сервером и стулом!!!

(6) Елена у вас ПМС? откуда столько желчи? Поверьте, квалификации у меня хватает, а так же ума не заниматься флудом на форумах.

(5) для начала глянуть, кто сколько процентов процессора ест.

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

если 1с-ка х.з. тогда, тии - может.

8-angro > а при чём тут процессор? математических вычислений кот наплакал при загрузке-то.

(10) он же не только математикой занимается. Вот сделай delete from table where sdfsd= 'dsfsd' - у тебя все ядра напрягаться будут.
Я предполагаю будет видно, или процессы постгресса не таблицы шерстят, либо сервер 1с чем-то занимается

3-Wit > ок, спорить не буду, хотя могу и высказаться - не устраивает USB 3.0, тогда создай виртуальный диск в оперативке. к такому варианту есть вопросы по скорости работы?

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

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

"при загрузке этого файла, когда начинают загружаться проводки по НУ резко падает скорость. [em]Причем не сразу, несколько сотен проводок загружаются нормально, а потом время между двумя загрузками по 10-15 минут.[/em]"

вот это похоже на создание файла подкачки в темпе.

в любом случае, автор, ждём вестей

это "нормально"... вернее с типовым механизмом так и будет... я в таком случае делал единичный обмен через флешку... или через локальный ресурс с ручной выгрузкой на фтп. имей ввиду что при БОЛЬШОМ обмене в загружаемой базе может вылететь ошибка по нехватке памяти (на 32 разрядной ОС с 4 гб озу)... лечится как ни странно 64 бит ОС и памяти 8гб.

Согласен с троллем, тут скорость доступа к дискам более критична чем загрузка ЦП. Конечно идеальное решение - положить базу на ССД диск. :) тока это сильно просто раз, и денег мне на него не дадут это два.
Викинг - эта проблема давно известна и изучена, сервер есс-но х64 и памяти как раз 8. По объемам файла загрузки проблем за два года ни разу не было.

Мониторя журнал регистрации могу следующее рассказать - проблемы начинаются при загрузке записей регистра НУ где регистратор - расчет себестоимости, т.е. с другими типами документов скорость загрузки записей бух регистра НУ такая же как для других объектов. А как только начинается документ расчет себестоимости - все тормозится. причем первый документ загружается 8 минут, потом 15 потом 20 и т.д. 6 или 7 по счету док такого типа загружался час. смотрел эти документы в базе источники проводок в каждом по НУ около 1500. сам документ проводится меньше минуты - причем в файловой базе.

17-Wit > вроде в обмене где-то указывался размер блока объектов, который грузится внутри одной транзакции. попробовать поставить там 2 и посмотреть что будет. хотя таблица регистра могёт и не сбрасываться...
или я с 77 путаю уже?

(18) Есть такая тема. Стоит 5. Как раз оставил на работе, завтра посмотрю поменялось что-то или нет.

19-Wit > а до этого сколько стояло?

Смущают "типовые настройки" PostgreSQL. Баба она капризная, с ней импровизировать надобно. Для точной диагностики нужна картина распределения памяти и активность файла подкачки. Расчет себестоимости может тащить с собой сотни тысяч проводок/движений, объем транзакции скорее всего не умещается в память и начинается жесткий своп, а т.к. для счетчика объектов на транзакцию один регистратор - это один объект, то под него ложатся и последующие документы. Улыбок тебе дед макар.

21-Reaper > ну ты блин выдал на гора. ближе надо быть к народу. не про тебя ли слагает легенды Синегурочка? клиентов тут нет, им тут не интересно.
;-))

22-Зелёный тролль > Я б клиенту в жизни такого не сказал. Мало ли какого слова он не поймет и посчитает его оскорблением?

(20) Когда смотрел время загрузки - стояло 100. В общем обмен завершился. Стало лучше, теперь время не увеличивалось с каждым следующим документом, а примерно было одинаковое. Статистика такая - движения по НУ у 24 документов "расчет себестоимости" загружались 7 часов, 20 минут.
(21) С постгри опыт первый, раньше и 7 и 8 на мс скл сервере настраивал. Все что в инетах нашел про настройку постгри - это покрутить два параметра shared_buffers и effective_cache_size остальное пишут не дает ощутимого прироста. опять же у меня под виндой он поднят, а все статьи про настройку под никсы. В принципе логика рассуждения у меня такая же была как у вас. Смущает одно - почему проводки у этого же документа по БУ загружаются с приемлемой скоростью, а по НУ с тормозами? и там и там бух регистр, количество самих проводок у документа сопоставимое. структура регистров тоже не особо отличается.

(24) ну ты туп... ой, простите - незаточенный!!!

расчет разный?

(24) Аргументируйте. :) Какой расчет и почему разный?

аргументы в кошельке не шуршат

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

Я так понимаю идеи почему тормозит конкретный регистр бухгалтерии при загрузке РИБ у сообщества кончились?

Тогда такой вопрос - есть ли смысл ставить постгри 9.2.1 (который для ознакомления) вместо 9.1.2? Или это обмен шила на мыло?

даже правильно пнутый однаЭсник [img]http://smartysmile.ru/uploads/images/20120825/bc58966ce1f7969e0cb75a055f5bffc2.jpg[/img]
летит куда попало
только не в нужном направлении

(30) я уже заметил что у вас нужное направление - в тупые хамки.

Это в качестве апа..

прикольнА

глупый пингвин громко плачет,
головой трясёт и бьется
ап стену
а ему не помогают
просто дальше посылают

29-Wit > А кто тебе сказал, что тормозит конкретный регистр? Ему достаточно было оказаться на нужном месте в последовательности загружаемых движений, чтобы именно на нем объем транзакции превысил допустимый объем доступной памяти и СУБД начала активное использование файла подкачки...

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

(32) Елена вы бесподобны. :) Если что, я сюда пришел не за помощью, а обсудить с коллегами конкретную ситуацию и услышать мнения других людей. Пятый раз говорю - ваше мнение мне не интересно. :) Идите дальше дельфи ковыряйте, тут взрослые дяди.

делал взрослый дядя, практически - однаЭсник [img]http://altfast.ru/uploads/posts/2012-08/1344121722_2-8.jpg[/img]

Кстати, пользуясь темой, (по теме - надо паковать), почему 1С не масштабируема? Сервера мощные, добавляем мощности, еще и еще, а скорость проведения документов не растет. Я так понимаю, это проблема платформы? С чем это связано? Снимали сканы с серверов - они ничем не занимаются - средняя нагрузка процесора 10% (я полагал, что она тратит время на вычисление на толстом клиенте, котрый на сервере был же и запущен). Чем занимается 1С все это время? Я не знаю зубы чистит, или она просто отдыхает (другие процессы не нагружают сервер), нагрузка на винты - ниже плинтуса. Она просто не масштабируема что-ли, или что с ней делать?

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

37-Моррисон >
[url]http://www.pcweek.ru/ecm/blog/its/4990.php[/url]

Учиться. Нужно всего лишь учиться, а не втыкать в сервер железо по принципу "подороже - авось хорошее".