К списку форумов К списку тем
Регистрация    Правила    Главная форума    Поиск   
Имя: Пароль:
Рекомендовать в новости

Обрезать базу ЗУП, нужен совет

Гость
0 - 31.10.2014 - 12:30
Всем привет!
Работаем в базе ЗУП много лет (1С 8.2, SQL).
Работников очень много, порядка 15 тысяч действующих. А в справочнике сотрудников их около 35 тысяч, в т.ч. давно уволенных.
При проведении расчетных документов в 2 тысячи строк всё очень надолго зависает, никто ничего не может сделать. Справочник сотрудников тоже долго открывается. Если много пользователей работают с базой, то тоже тормоза то тут, то там. Вобщем пользователи жалуются, а начальство требует решения.
Сначала занимались этим сисадмины, сделали по железу всё что могли. Единственное говорят, что ключ сейчас 32-битный, надо мол ещё 64-битный сервер 1С попробовать. Но отчитались, что в остальном сделали всё что могли, мол железо тянет без проблем, сервер по процессору, очереди диска, оперативной памяти слабо загружен.
В итоге теперь требуют от программистов (от меня) максимально обрезать базу ЗУП, чтобы с нового года начать работу в новой базе. При этом должны быть перенесены все работающие сотрудники с их кадровой информацией, а также необходимые данные для расчета среднего.
В общем получается, что мне нужно как-бы начать работать в новой базе, но перенести туда все необходимые данные из прошлой, как например делался переход из ЗИК 7.7 на ЗУП.
Честно говоря, я не верю, что это поможет, ведь в документах как было по 2 тыщи строк, так и останется. Я не думаю, что прошлые данные в ЗУПе могут создавать сильные тормоза. Но теперь уже выхода нет, мне нужно обрезать базу, и либо доказать, что лучше не стало, либо в самом деле обрадоваться улучшению.

Прошу совета, может кто переходил на новую базу из 8.2 на 8.2 с целью избавится от прошлых периодов и ненужных сотрудников.
Кто чем пользовался, какой алгоритм.
Всех работников наверное нужно постараться перенести стандартной 1С-ной обработкой загрузки/выгрузки базы (со всеми сопутствующими справочниками). Ну а потом надо как-то все сальда подтянуть, и базу для среднего заработка.
Может есть уже механизмы, чтоб велосипед не изобретать?



Гость
1 - 31.10.2014 - 12:47
15 тыс сотров в одной базе!? да ещё небось одним доком зп начисляете, все сорок расчетчиков
ЗЫ это вам к доктору надо, ну или хотя бы к аналитеку, адынеснеги то тут при чем?
Гость
2 - 31.10.2014 - 12:58
а по свертке ключевое слово - числящиеся сотрудники, работающие в периоде не канает
ЗЫ но я бы распределил базы, хотя бы по 1-ой на два расчетчика - учет труда и расчет зп вообще-то разные вещи
Гость
3 - 31.10.2014 - 13:18
1-vah1 > Да, все в одной базе. Но начисления делаются не одним документом. Как я уже писал, в документе порядка 2 тысяч строк.
"адынеснеги то тут при чем" - дак не причем. Я и есть 1С-ник, сейчас надо что-то решать.

2-vah1 > "по свертке ключевое слово - числящиеся сотрудники, работающие в периоде не канает"
Не понял этого выражения

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

"учет труда и расчет зп вообще-то разные вещи" - это понятно, к чему это сказали?
Гость
4 - 31.10.2014 - 13:31
как-то центролизовывал расчет зп, дык учет труда легче по местам мести - слив только административно назначить, ну и унифицировать - это уж к одинеснегам (закачка их экселя в новый док по подразделениям, например)
5 - 31.10.2014 - 13:39
(3) Ты на ваху не смотри, его речь как покойного Черномырдина надо в рамочку вставлять и объяснять что "так писАть не следует".
Гость
6 - 31.10.2014 - 13:49
5-Секвестр > на меня-то фикли смотреть, дайте пиво в пятницу попить
ЗЫ да. и пристрелите потом, плиз что б не мучался
7 - 31.10.2014 - 13:57
(3) Ну вот видишь? Нужны какие либо объяснения ещё? (см. (6) )
8 - 31.10.2014 - 13:58
А вообще, на просторах инета есть "обрезаловка". Но те кто пользовался ею, пишут что "надо работать потом напильником".
9 - 31.10.2014 - 14:57
Ну, можно потерпеть ещё полгодика, а потом перейти на 3.0. При переносе все уволенные и обрежутся, начисления останутся за 2 года.
Если попробовать делать начисления на 20-30 сотрудников в документе скорость обработки увеличивается?
Гость
10 - 31.10.2014 - 16:04
9-GSokolov > "Если попробовать делать начисления на 20-30 сотрудников в документе скорость обработки увеличивается?"
Я уже предлагал разбить на более мелкие подразделения, чтобы в документе было хотя бы 500 сотрудников. Чтобы попробовать, будет ли быстрее. Но им удобно делать именно по большим подразделениям.
Гость
11 - 31.10.2014 - 16:05
9-GSokolov > "Ну, можно потерпеть ещё полгодика, а потом перейти на 3.0."

Дак вроде уже можно. Правда не изучал тему, мне кажется ещё глюков много.
12 - 31.10.2014 - 20:28
Цитата:
Сообщение от Antikvar Посмотреть сообщение
мне кажется ещё глюков много.
Потому и предложил подождать, хотя, основное уже есть. И тормоза в тройке не слабые, в начислении зарплаты при заполнении сразу и расчет производится, в т.ч. и страховых взносов.
Гость
13 - 12.11.2014 - 00:07
Обнаружил сегодня, что строк в документах начисления зарплаты около 4 тысяч, а не 2 тысячи как расчетчики говорили. Это они имели ввиду 2 тысячи сотрудников, а строк то получается около 4 тысяч.
А документ начисления страховых взносов вообще один по организации делается, там 10 тысяч строк только во кладке взносов, 22 тысячи строк во вкладке основных начислений и т.д.
Это вообще нормально, документы с таким кол-вом строк держать? Как думаете? У 1С нет рекомендаций по максимальному кол-ву строк в документах, никто не в курсе?
Что-то мне кажется это вообще перебор, надо разбивать на несколько.
14 - 12.11.2014 - 00:54
охохонюшки...
ну а вы же исследовали, что на самом деле происходит, когда зависает, тормозит и т.п.? какие операции выполняются, где узкое место?
15 - 12.11.2014 - 02:20
т.е. ни чтения, ни записи, ни работы с оперативной памятью, ни работы процессора во время тормозов не наблюдается?...
а компьютер вообще включен?
какие конкретно занчения каких показателей приводят сисадмины? чисто ради интереса.
16 - 12.11.2014 - 10:01
И никто не спросил, а скуль-то какой? Поди мелкомягкий? Переползай на Оракл, там все будет быстрее и намного.
17 - 12.11.2014 - 10:43
да дайте наконец уже человеку кряк на 1С:Сервер 64-х. Пусть памяти воткнет по максимуму и попробует.
:)

(0) имхается, заблуждаются твои админы. при таких объемах и 32-х сервере не может не быть проблем с нехваткой памяти. Точнее - оперативной памяти.

Тебе что мешает всё перевести на 64 бит (всё - это значит всё, начиная с оси) и попробовать? Только необходимость докупить пару планок? Не, я ни в коем случае не предлагаю работать на пиратских версиях, но попробовать то можно и на пиратке/триале? Понравится - купишь, не понравится - будешь искать другие способы.
18 - 12.11.2014 - 10:46
При таких объёмах клиент и сервер 64бита обязательны.
Гость
19 - 12.11.2014 - 10:58
14-Пудель > Я удаленно работаю и подключение у меня к базе вечером, когда никто уже не работает :) Но со слов пользователей исследовал. Когда очень много пользователй в базе (а их одновременно около 50 штук сидит), то периоды массово
Гость
20 - 12.11.2014 - 11:03
сорвалось...
Когда очень много пользователй в базе (а их одновременно около 50 штук сидит), то в периоды массовой работы с документами висит всё. Не могут ничего провести и ничего расчитать, ни начисление ЗП, ни бальниные, ни командировки... А именно вылезают транзакции. Вечером, когда никого нет, документ в 4 тыщи строк за 3 минуты проводится (если первый раз). Перепроводится же за 1 минуту, т.е. SQL оптимизирует выполнение повторных операций.
Гость
21 - 12.11.2014 - 11:06
15-Зелёный тролль > Вот что мне сообщил сисадмин (это я его попросил посмотреть в тот момент, когда все юзеры висели):
"Посмотрел нагрузку на железный sqlserver, и на нем же сервер 1с. Он не нагружен. Очередь диска иногда подскакивает 0.01 в целом 0.00. Оперативки полно, 25% всего лишь занято. Процессор 2-8% нагружен. Думаю тут вопрос не в скорости железа сервера. Вообще ms sql может всю базу себе в оперативку при желании положить. Оперативки 128 гигабайт, а база всего 44 гб."

Вот такой ответ был.
Гость
22 - 12.11.2014 - 11:10
16-shotsdv2008 > да, скуль мелкомягкий
Но я такие вопросы не решаю. Конечно, если это точно бы помогло, то я бы возможно мог убедить, но нет у меня такой уверенности.
Гость
23 - 12.11.2014 - 11:18
Цитата:
Сообщение от Блондинка в шок Посмотреть сообщение
Тебе что мешает всё перевести на 64 бит
Мне мешает то, что у меня доступ только к серверу 1С, я работаю удаленно, чисто как программист. Для таких дел там есть сисадмины.
Но проблему с ключом 64-бит всё-таки пропихнули :) Как раз вчера был первый день работы с новым 64-битным ключом. Наконец-то его купили и админ поставил. Ось на сервере тоже 64-разрядная.
Памяти как писал выше 128 Гб, куда уж больше в самом то деле.
Пока пользователи ничего не поняли, сильных тормозов не было, но и массовой работы не наблюдалось. Посмотрим дальше.
24 - 12.11.2014 - 12:11
23-Antikvar > странно, что при ОЗУ в 128 Гб и базе в 44 Гб потребление памяти, по твоим словам - 25% всего лишь занято. т.е. всего лишь 32 Гб.
Немножко странно, я, конечно, с такими большими базами не работала (так.. максимум 6-8 Гб), у меня обычно SQL со временем стремился отожрать как можно больше, больше, чем вся база весит.
Может, админы max server memory ограничили?
25 - 12.11.2014 - 12:29
А приложение 1С какой разрядности?
Гость
26 - 12.11.2014 - 12:32
Цитата:
Сообщение от Блондинка в шок Посмотреть сообщение
Может, админы max server memory ограничили?
Не знаю, спасибо за предположение, уточню у админов. Но они говорят, что памяти всегда очень много свободной. Может в самом деле, вот бы хорошо :)
Гость
27 - 12.11.2014 - 12:52
Цитата:
Сообщение от Секвестр Посмотреть сообщение
А приложение 1С какой разрядности?
Не совсе понял?
Сервер 1С поставили тоже 64-разрядный. А сама платформа 8.2 последней версии, она одна на сайте, но платформа может вообще у пользователя стоять.
28 - 12.11.2014 - 13:00
26-Antikvar > ага. спроси.
и еще. А сколько у тебя процессов rphost было (когда был 32-х 1С:Сервер)? на 50 то юзеров?
они то тоже должны были память отжирать.. каждый..
а то больно много у тебя памяти свободной.. :)

зы: на 1С:64-х, как говорят, достаточно всего два rphost, один из них - резервный.
29 - 12.11.2014 - 13:05
Цитата:
Сообщение от Antikvar Посмотреть сообщение
сама платформа 8.2 последней версии,
Открой прайс лист 1С http://www.1c.ru/rus/partners/pricelst.jsp
И посмотри позиции
4601546081315
4601546081322
Как ты думаешь, это одно и тоже?
30 - 12.11.2014 - 13:30
29-Секвестр >Как ты думаешь, это одно и тоже?
хм.. для юзера (клиента), который подключается к серверу 1С и у которого рядовая рабочая станция WIN ХР с двумя ГБ на борту, абсолютно одно и тоже.

В свете (27) но платформа может вообще у пользователя стоять - я так понимаю, работают не в терминале?

Разница, я так понимаю, будет заметна если либо всех в терминал загнать, либо (если не терминал, а просто клиент-сервер) каждому юзеру-клиенту на рабочей станции поставить WIN 64-х и ОЗУ больше 4-х ГБ?
Гость
31 - 12.11.2014 - 14:32
Цитата:
Сообщение от Блондинка в шок Посмотреть сообщение
А сколько у тебя процессов rphost было (когда был 32-х 1С:Сервер)? на 50 то юзеров?
Было распараллелено на 6 процессов. Сейчас на 64-битном админ сделал 4 процесса
Гость
32 - 12.11.2014 - 14:37
29-Секвестр > "Блондинка в шок" правильно описала в (30). Я честно говоря даже не знаю как пользователи подключаются. Я то удаленно из другого города, поэтому через удаленный доступ захожу на сервер, там мне доступен только мой каталог, на этом сервере запускаю 1С, но это обычный запуск, не в терминале.
Есть и удаленные пользователи, однозначно. Но расчетчики точно все местные и у них наверное своя 1С установлена у каждого, но не уточнял.
33 - 12.11.2014 - 14:57
Вот и я думаю, какой сервер 1С развёрнут в клиент-серверном варианте? Сама ОС может быть и 64х разрядной, а вот какой сервак 1С развёрнут?
Гость
34 - 12.11.2014 - 15:18
Хмммм...
Дано: 15000 активных записей на 50 операторов. Т.е., по 300 записей в одну морду. На 22 рабочих дня, заметим. По 8 часов в каждом. Для ввода изменений в кадровой информации, внутренних перемещений, и прочей инфы, нужной для финишного (в конце месяца) расчета.
Т.о., на обработку каждого сотрудника (в среднем) приходится ((22-2)*8*60)/300=32 минуты (2 дня выкинуты на финишный расчет).
Полчаса.
А потом финишный расчет (итого начислено, итого удержано, итого выплачено, НДФЛ, пФР...) - всего 6 документов, в каждом из которых помещается 2000 рыл.
Информация по каждому тщательнейшим образом отшлифована в течении получаса.

Вы правда полагаете, что проблема в "железе"?
35 - 12.11.2014 - 15:21
VZ, да я знаю что "разруха в головах", но ведь это Россия...
Гость
36 - 12.11.2014 - 15:36
Цитата:
Сообщение от Секвестр Посмотреть сообщение
Сама ОС может быть и 64х разрядной, а вот какой сервак 1С развёрнут?
Дак я написал в (27), что сервер 1С 64-разрядный

Цитата:
Сообщение от Секвестр Посмотреть сообщение
Вы правда полагаете, что проблема в "железе"?
Лично я полагаю, что не в нем. Просто здесь меня спрашивают конкретику, я отвечаю.
Гость
37 - 12.11.2014 - 20:53
имхо, тут был самый хороший совет - подождите немного, потом переходите на 3.0
38 - 12.11.2014 - 21:33
Антиквар - это несерьёзный подход к исследованию проблемы. На основании устного опроса, даже без анализа журнала регистрации, Вы собираетесь принимать решение!
Вы даже не знаете, какая проблема является основной - транзакционные блокировки или медленное выполнение запросов.
Фу таким быть :)
Гость
39 - 12.11.2014 - 21:56
38-Пудель > Ну устный опрос в реальном времени дал понять, что выскакивают именно сообщения о транзакциях и ничего не проводится из-за этого и не расчитывается. Т.е. не медленно выполняется запрос, а вообще не выполняется. Практически сразу вылетает сообщение о транзакции.
А чем поможет журнал регистрации? Там хрен чего найдешь, одну минуту можно минутами листать :)


К списку вопросов
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск




Copyright ©, Все права защищены