| 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
| Цитата:
| | ||
| 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-бит всё-таки пропихнули :) Как раз вчера был первый день работы с новым 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
| Цитата:
| | ||
| 27
- 12.11.2014 - 12:52
| Цитата:
Сервер 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
| Цитата:
И посмотри позиции 4601546081315 4601546081322 Как ты думаешь, это одно и тоже? | | ||
| 30
- 12.11.2014 - 13:30
|
29-Секвестр >Как ты думаешь, это одно и тоже? хм.. для юзера (клиента), который подключается к серверу 1С и у которого рядовая рабочая станция WIN ХР с двумя ГБ на борту, абсолютно одно и тоже. В свете (27) но платформа может вообще у пользователя стоять - я так понимаю, работают не в терминале? Разница, я так понимаю, будет заметна если либо всех в терминал загнать, либо (если не терминал, а просто клиент-сервер) каждому юзеру-клиенту на рабочей станции поставить WIN 64-х и ОЗУ больше 4-х ГБ? | | ||
| 31
- 12.11.2014 - 14:32
| Цитата:
| | ||
| 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
| Цитата:
Цитата:
| | ||
| 37
- 12.11.2014 - 20:53
| имхо, тут был самый хороший совет - подождите немного, потом переходите на 3.0 | | ||
| 38
- 12.11.2014 - 21:33
|
Антиквар - это несерьёзный подход к исследованию проблемы. На основании устного опроса, даже без анализа журнала регистрации, Вы собираетесь принимать решение! Вы даже не знаете, какая проблема является основной - транзакционные блокировки или медленное выполнение запросов. Фу таким быть :) | | ||
| 39
- 12.11.2014 - 21:56
|
38-Пудель > Ну устный опрос в реальном времени дал понять, что выскакивают именно сообщения о транзакциях и ничего не проводится из-за этого и не расчитывается. Т.е. не медленно выполняется запрос, а вообще не выполняется. Практически сразу вылетает сообщение о транзакции. А чем поможет журнал регистрации? Там хрен чего найдешь, одну минуту можно минутами листать :) | |
Интернет-форум Краснодарского края и Краснодара |
