v7: Ускорить расчет зарплаты в ЗиК 7.7 #639523

База SQL больше 1,7Гб, в том числе журнал расчетов Зарплата больше 500 000 строк, Kladr+SocrBase+Street почти 1,2 миллиона строк. Еще и CJ4891 (не нашла в словаре, что за ЖР) размером за 400 000 строк. На сегодня получила 2 совета - терминал и DBF (но это было до уточнения размеров базы), либо RAM-диск. Есть ли еще идеи или выбирать одну из этих?

обрезать и перевести на ДБФ

а чо, таблицы КЛАДРа как-то влияют на быстродействие ЗиК?...

Упомянуты для оценки размера базы.

Существует ли более или менее стандартная обработка обрезки ЗиК? Для меня это задача непростая.

А вот не надо было все регионы грузить

- 1С++ загрузить при старте (ускоряет создание многочисленных СЗ и ТЗ и тп) - разогнать процессор допобольше гигагерц - само собой работать в терминале, не по сети в дбф

или монопольно

"Kladr+SocrBase+Street" вычистить нафиг, загрузить только нужный (нужные)регион. "журнал расчетов Зарплата" - есть такая штука Метла ЖР - вычистить лишние (ненужные) записи. пустые (ненужные) записи в ЖР возникают, когда в документ "Начисление зарплаты" заполняют всем без разбора (в том числе и давно уволенными). Аналогично в журнале по страховым взносам. 1.7 Гб всего на SQL (включая полный Кладр) - это ни о чем. если выгрузить в dbf - сколько будет весить самый большой dbf-ник ?

какой мутак пустил тупую сукульницу зикерить?

детский размер. счас открыл CJ447.dbf - 237000 записей,   весит всего 31 Мб.

+100 скуль и ЗиК - вещи несовместимые. а тем более, у автора такие детские размеры.

о, нашел другую базу в архиве. CJ447.dbf - 475376 записей - размер 61 846 160 байт. твои "500 000 строк" в dbf будут весить меньше 70 Мб. Не смеши тапочки своими "большими" размерами.

Завтра выложу размеры. ЗиКу в SQL выложили давно, я пришла позже. Но знаю ЗиК слабо, поэтому буду благодарна за любой совет).

потрахаться не забудь ЗЫ про за любой совет :))

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

ладно, не пишите больше

(не нашла в словаре, что за ЖР) ЗЫ что четал челевек?

что то миста обыдливается, сезонное надеюсь

Смотрела в DD, не нашла там сперва журнал Страховые взносы СтраховыеВзносы, сейчас нашла. Без иронии никак? Буквы "и " и "о" на клавиатуре западают?

Еще погуглила - создается впечатление, что в 7.7 простых средств для ускорения нет? Стандартная обработка с ИТС чистит ЖР, но практически не ускоряет расчет зарплаты, судя по отзывам. Сложную обработку написать я не смогу, предметная область знакома слабо. 1С++ загрузить при старте - единственный полезный совет, имхо... Но не знаю, насколько 1С++ стабильно работает... Ну, и посмотрю, потянет ли DBF-я база по размеру после чистки Kladr и чистки ЖР... Спасибо всем, кто дал советы!) Успехов вам и хорошего настроения!!!)

Сколько у вас сотрудников, что сильно тормозит?

Всех уволить. ЗИКа летать начнет.

Около 3000 человек.

Пятница через 25 минут, раздел другой).

Все, до завтра и еще раз спасибо ответившим!)

сколько по времени длится расчет? щитаю что 2-2,5 часа на такое количество терпимо. хотя могу что-то позабыть. 4 года за зик не брался.

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

Если не ошибаюсь на софтпойте была статья по этому поводу. Поищите. И опять таки если не изменяет память, самое узкое место в методе ВыбратьПоЗначению в процедуре расчета.

самое узкое место в ЗиК - это сами расчеты...

Самое узкое место в ЗиК это работа с большими таблицами значений (функция глПроводкиЗаПериод) ну и само собой выборки по ЖР. Выборки по ЖР переписываются на прямые запросы без проблем а по глПроводки тоже от Vaicartana есть решение - правда под новые релизы надо под себя точить. Основными показателями нагрузки на базу являются: - количество постоянных видов расчетов и их вид (фиксированной суммой, процентом от базы) - количество переменных видов расчетов (в месяц сколько разовых начислений) - правка данных об НДФЛ в карточках (страдают же этим некоторые) - методика отражения в БУ (для анализа производительности формирования свода проводок) После предоставления этих сведений можно будет далее предметно разговаривать. Также желательно предоставить характеристику сервера SQL - аппаратные характеристики (частота процессора, шины, размер оперативной памяти, конфигурация дисковой подсистемы - кол-во дисков; контроллер; уровень массива; включен ли кэш обратной записи) - программные характеристики - ОС (разрядность), версия SQL (select @@version), настройки AWE и PAE если SQL x32, производится ли обслуживание базы (обновление статистики, переиндексация).

Ускорить всегда можно, остается все переписать на прямые запросы :)

забить. С 1 января ЗиКа начнет считать ощутимо быстрее. :))) К концу года опять будет тормозить. Это циклическое :))) В январе ЗиК "пробегает" при расчете по человеку 1 раз (1 месяц), в декабре - 12 раз (12 месяцев)...

Данные уточню в понедельник. Сразу: разовых начислений много, активно начисляются премии фиксированной суммой. Вопрос: переход на 8.2 решит проблему или тормоза будут большие по-прежнему? Сейчас расчет идет так, что расчетчики перед зарплатой сидят ночами.

Дополняю: "методика отражения в БУ" - шаблоны проводок не заполнены, выгрузки в Бухгалтерию на сегодня нет, если Вы об этом.

занимался как-то ускорением ЗИК под СКЛ. мутота. КЛАДР там вообще ни при делах.

Странно.. 2500 человек ЗиКа десять лет назад на пеньке с 1Гб памяти считала часа полтора... притом там совсем замутные расчеты были у бригад.. что-то не то в консерватории.. и слезайте со скуля..

dbf,ssd,терминал,ram диск все уже ясно, что еще?

Не работает ЗиК на SQL. Ужасно тормозит. Решение одно, резать + Переводить на DBF. Если людей больше 400, то завести несколько зиков. Ибо ЗиК, это решение для малого бизнеса :) ... Если не устраивает много баз и все же хочется SQL, то вам нужен ЗуП, на 8-ке :)

Все в топку, не поможет.

+Если начнешь переписывать на прямые запросы, то будь готова это делать при каждом обновлении :) Ибо ЗиК обновляется с такой же скоростью, с которой у нас в стране пишутся Законы. Т.е. всегда... :)

Нечего странного, все дело в SQL, зик криво отрабатывает запросы. Походу, когда 1С переходила на SQL, то поленилась по человечески написать запросы :)

Обратимся к классикам "Часто на форуме задается вопрос «а сколько сотрудников реально рассчитывать в программе ЗиК»? Отвечаю: вполне реально рассчитывать 6-7 тыс человек, практически без переделок, с переделками еще больше. Только нужно грамотно разделять ввод и отчетную информацию - при такой численности все отчеты следует получать на «вчерашней» копии, общий расчет зарплаты ставить на ночь, а всю первичку вынести в отдельную базу и настроить односторонний обмен. 2-3 тысячи человек программа отработает вообще безо всяких вопросов. "(С)

как всех уволить! а расстрелять?

видел зику на две тыры человек, дык и то в распреленных базах

Сказочник... ну вы продолжайте :)

Очень осторожно с метлой. Можно удалить записи, которые являются первичными, и тогда могут пропасть записи, которые не собирались удалять. Можно убыстрить ЗиК. Из своего опыта: 12000 сотрудников - проведение документа "Начисление зарплаты" и следом расчет зарплаты длился меньше часа. 1. ДБФ и Терминал (естественно хорошее железо: проц и память) 2. 1CPP.dll 3. SSD диск 4. Избавится от ПолучитьСтрокуПоНомеру 5. Ежедневные копии

А из практических советов - распараллеливайте. Зик по другому эффективно не ускоряется.

расчет зп в ЗиК 1с 7.7 только в монопольном режиме!!! Скорость выполнения на порядок выше! Не спрашивай почему.

Неправильное утверждение, не спрашивайте почему:) А если серьезно это только справедливо для DBF да и то не на порядок а в разы. Происходит из за системы файлового кеширования в монопольном режиме.

а какие затраты на это там не написано? Сколько времени и денег потрачено. Хотя в приведет к такой же скорости работы.