Приветствую.

Если кратко: есть УТ 11.4 с небольшим количеством товаров и продаж.
По поверхностной оценке, количество объектов(документов/записей) меньше десяти тысяч: физ./юр. лиц, товарных позиций, операций покупок/продаж.
Товары без картинок и прочих вложений.
Объем основного файла 6.8 Гб что кажется очень большим при таком небольшом количестве данных.
Даже с локального компьютера работает медленно. Ожидание некоторых базовых операций составляет десятки секунд.

Грешим на КЛАДР затесавшийся со времен УТ 10. Попытки найти меню очистки КЛАДР в 11.4 не увенчались успехом.
В разделе Сервис/Настройка адресного классификатора, нам сообщают что объектов: 92, но кнопки вызывающей форму очистки нет.
В разделе редактирования адреса в карточке физ./юр. лица, доступна только опция загрузки адресного классификатора.
По ощущениям - заглянул во все разделы, но больше вариантов работы с классификатором адресов не нашел.

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

Общая идея: сделать внешнюю обработку которая посчитает количество записей в регистрах сведений и если проблема в них, то очистит адресный классификатор.
Ну и призрачная надежда что просто не нашел в меню пункт в котором можно очистить адреса одним нажатием. Может кто подскажет.

(0)
Арендуйте тестовый сервер в пробном режиме на день-два бесплатно и погоняйте базу там, сравните с вашим железом.
Я думаю что у вас проблема в железе, а именно - в слабом проце.

Ну и платформу рекомендуемую поновее поставьте для общей картины

И попробуйте таки поработать через веб-сервер.
Если пользователей много, то поэкспериментируйте с
http://catalog.mista.ru/public/242527/

(0) Воды много, конкретики нет. На проведение Реализации размер КЛАДРа не влияет.

pavig, спасибо за советы, боюсь проблема не в этом. В УТ пользователь один.
Сильно сомневаюсь что не хватает i5 для работы с 1С.
Узкое место - жесткий диск, на SSD чуть быстрее работает, но это не отменяет большого объема базы при минимальных количествах данных.
Неужели 6.8 Гб база нужна для такого небольшого количества данных?

sqr4, подскажите пожалуйста какая конкретика нужна?
Один пользователь, файловая база, УТ 11.4 объем базы, на мой взгляд, огромен.

Ну так посмотрите размер таблиц в чем дело, обработок море

У тебя проблемы с логикой и построением выводов: по какой-то неведомой причине (скорее из-за недостатка интеллекта) ты связываешь размер данных со скоростью / отзывчивостью / производительностью работы в инфобазе.

(0) Очистка кладра никак не поможет, даже если он закачан. SSD - это как минимум. По сети - через апач.

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

sqr4, копаю в этом направлении. В 1С совсем не ориентируюсь, по этому что очевидно для вас, для меня, увы, не особо.

Попрошу без инсинуаций - Я холоден и рассудителен как никогда )

Есть обработки показывающие размер таблиц базы.

ptiz, вижу производительность в 1С это большая мозоль куда я по незнанию наступил :-)

Если отбросить производительность, может ли база УТ 11.4 с небольшим количеством данных занимать 6.8 Гб?
PS: Ищу обработки для подсчета объема.

Cyberhawk, что вы, никаких инсинуаций, просто проходите мимо :-)

(13) Tool1CD умеет показывать размер.
Из 6.8 Гб половина запросто может быть "пустой", из-за временного расширения базы при обновлениях (при ресструктуризации таблиц).

(13) Ради прикола посмотри сколько абсолютно пустая файловая УТ11.4 весит.

К тому же после ТИИ иногда размер заметно снижается.

(15) Моя демо гиг весит

Ray Zexter, 11.3 пустая, чуть меньше 1 Гб, если мне не изменяет память.
Запустил ТИИ, посмотрю что из этого получится.
Кстати база сжимается до 1.2 Гб что может говорить как о пустых страницах, так и о КЛАДРе(он тоже очень хорошо сжимается).

ptiz, видимо весеннее обострение паранойи. Опасаюсь запускать сторонний экзешник.

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

Может поисковую фразу не правильно составил? Ищу "1с обработка размеры объектов файловой базы"

(18)У вас гугл сбоит.
http://catalog.mista.ru/public/439778/

(10) > объем данных влияет на производительность, не вижу тут логической ошибки.

Ошибки не видите, а она есть.
Ключевой вопрос - КАКИХ данных? Например, от того, что вы в базу загрузите парочку полнометражных немецких фильмов про любовь в HD-качестве объём данных значительно увеличится. Однако на скорости работы (проведение документов, формирование отчетов) это никак не скажется.

(10) > В 1С совсем не ориентируюсь.

Позовите специалиста (с) Не моё.
Дешевле выйдет. А то как бы потом после ваших экспериментов не пришлось базу восстанавливать.

PS Надеюсь, резервная копия предварительно сделана и все манипуляции вы делаете именно на копии, а не на продуктиве.

НаборДанных, спасибо за ссылку, ни Гугл ни Яндекс мне ее не выдавал. Тяжело найти, особенно когда не знаешь как правильно сформулировать поисковый запрос. Именно по этому обратился к людям более компетентным в этой области.

unregistered
>Ключевой вопрос - КАКИХ данных?
Именно. Как было отображено в первом сообщении, КЛАДР это предположение. Как я понимаю, специалисты не разделяют данное предположение в разрезе влияния базы КЛАДР на производительность, по этому идет поиск скрипта для оценки размеров данных в базе и после этого буду пытаться сделать выводы.

>Позовите специалиста (с) Не моё.
Занимаюсь этим вопросом потому что руководство не будет выделять средств на специалиста, тот кто к нам ходит сказал что ничего сделать не может(или это не входит в рамки договоренности), а человека работающего с 1С мне попросту жаль, захотелось помочь.

>PS Надеюсь, резервная копия предварительно сделана и все манипуляции вы делаете именно на копии, а не на продуктиве.
Не извольте беспокоиться :-)

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

Подскажите пожалуйста, это я туплю или для catalog.mista.ru не подходит аккаунт от форума?

Попробуй создать нового пользователя и сравни скорость работы.

(24) Евгений Ваганович, перелогиньтесь :-)

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

(23) это же инфостарт

(26) да что вы говорите

(26) так походу я опять нифига не понял, сори за то что выше

(26) >Террабайтные базы должны встать колом, проводиться документы по году-два.
Если используются данные находящиеся в этих огромных базах, то да, могут возникнуть проблемы с производительностью. В прочем пустой этот диалог. Я так понимаю вы не особо вчитывались в предыдущие сообщения. Я не знаю внутреннюю механику работы 1С. Было высказано предположение: "грешим на КЛАДР". Сейчас акценты сместились на "найдем почему база такая большая" и попробуем ее уменьшить. Если не поможет с производительностью, будем думать дальше.

(27) >это же инфостарт
Я человек простой - вижу в адресе домен mista, сразу предполагаю связь между forum и catalog :-)
Как я уже говорил выше - 1С далек от моей сферы деятельности, отсюда не знание даже элементарных интернет-ресурсов.

(22) "тот кто к нам ходит сказал что ничего сделать не может" Это как раз нормально. Более того вполне возможно его посещения являются причиной.
Между тем у 1С есть целый комплекс специфических знаний и инструментов для обеспечения скорости работы.

(30) Я как понимаю вы не особо вчитываетесь, в то что вам пишут. Вот и хрен то что вы не разбираетесь. Я вам еще раз говорю, размер КЛАДР не влияет на скорость проведения реализации. В 1с используются регистры, виртуальные таблицы и т.д. И будь хоть миллиард документов реализация и поступления, но таблица остатков (если все нормально) сформируется быстро и только по тем документам, которые остатки сделали.

Поэтому вас и спросили, какие базовые операции у вас висят по 10 и более секунд. И только поняв, что где и как можно понять причину этих зависаний и что от них спасет. А вот это - "База слишком большая", похожа на бред вашего полоумного начальника, которому жалко денег на нормального спеца.

(30) " не знаю внутреннюю механику работы 1С"
Пригласить специалиста уже было?
Хочешь разобраться - включи замеры производительности. Не можешь включить - научись. Не можешь научиться - пригласить..Стоп. Это уже было.
...

(23) Оба предположения правильные.

(0) Достаточно посмотреть на объем считанных данных в результате базовой операции и все вопросы отстегнутся.
Типовая УТ11.4, проведение РТУ, 340 Мб считанных данных. Но быстро, так как SSD. Страшно представить как там в HDD

(32) sqr4, дышите глубоко, не волнуйтесь так. Про КЛАДР я не однократно прочитал и неоднократно отвечал. Специально для Вас повторю: параллельно с вопросом производительности пытаюсь понять почему такой размер базы.
>Поэтому вас и спросили, какие базовые операции у вас висят по 10 и более секунд.
Тут я понимаю вы опять (29) Про операции у меня ничего в этом треде не спрашивали или покажите в каком вопросе. Ну да ладно, тоже пустое. Произведу замеры.

(31) Sapiens_bru маловероятно что это его рук дело. Возможно просто нет договоренности с руководством и я его не виню в отказе. Как я уже говорил: инициатива целиком моя, альтруистическая. Руководство пока ситуация не напрягает.

(34) Еще один поклонник творчества Евгения Вагановича, проходите дальше пожалуйста :-)

(35) H A D G E H O G s, читаю про измерение производительности.

(36) Волновать надо тем, у на чьей базе вот такие альтруисты работают. Хотя это все пустое, делайте замеры.

(36) Ключевое в моем сообщении было не то чья вина, а то что в 1С есть способы расследования проблем производительности и исправления этих проблем. Но рядовым 1С программистам эти механизмы не известны и по большей части не нужны.
Именно расследования с точным определением проблем и путей решения, а не гадания но кофейной гуще по размерам баз, маркам процессоров и количеству элементов в таблицах

(37) sqr4, руководство попросило объявить вам благодарность за такую трогательную заботу :-)

(38) Sapiens_bru, эту часть я понял, принял и изучаю. Осталось дело за малым - совместить графики со "страдальцем" что бы он поработал в 1С а я понаблюдал. К сожалению навыков работы в УТ да и вообще в 1С у меня нет.

В общем всем спасибо за ответы. Будем измерять :-)

(39) Вы там что-то свое поняли. Не надо графики совмещать - надо настроить сбор статистики и после сбора её проанализировать. При этом можно с пользователем вообще не пересекатся.

(0) Sql express edition (бесплатный до 10 ГБ) - не предлагать ?
Получите :
1. Многопоточность при проведении
2. Статистику по таблицам и их весу
3. Анализ узких мест производительности.

(0) Проверь есть ли документы введенные будущей датой. Если кто то из бухов ввел документ 2120 годом то база может вырасти до огромных размеров

(40) Sapiens_bru, а вот до этого я еще не дочитал :-) Это было-бы замечательно.
(41) Очевидно, под одного пользователя SQL? Не хотелось бы усложнять. Пока попробую разобраться в том что есть.
(42) Sysanin_1ц, ого! Спасибо, попробую :-)

(41) а сервер 1с к нему тоже бесплатно прилагается?

(44) к сожалению, нет ... прост расследование проблем производительности на файловой БД , типовой УТ, скорее всего ограничится счетчиками Perfmon'а. что даст очень слабую информацию о проблеме ... но дело оно такое, добровольное ...

(45) ТЖ даёт очень сильную информацию, даже в файловой базе. Да и замеры времени работают из стандартной БСП. Трассировку не собрать да.

(0) Размер файловой базы УТ 11.4 в 6.8Гб вполне нормальный, на скорость влиять не должно.
SSD и веб-сервер файловый вариант спасут, никаких работ толстым клиентом по локальной сети.
Плюс легкая оптимизация и параметры железа не озвучены с количеством пользователей и фоновых/регламентных.

Если файловая на виртуальном сервере то тормоза вполне логичны, ссзб.

(0) стучите в почту

(47) Все так. Автор лишь написал, что "i5". И Все. А так да: SSD must-have! И не только под саму базу, но и под кеши/темпы. Оперативки достаточно. Проц чтоб был в "максимальной производительности". И убрать роль Hyper-V на том сервере, если не дай бог, она там есть. А вот дальше уже копать в программную сторону.

О размере базы волноваться не надо: простое обновление УТ 11.3 -> УТ 11.4 увеличило размер на 30%.

Спасибо всем ответившим.
Сделал ТиИ, база ужалась с 6.8 Гб до 1.8 Гб
По отзывам стало чуть быстрее, но это может быть эффект плацебо, по этому держим курс на замер производительности.

PS: Конечно я немного ошарашен тем каким прожорливым и неповоротливым монстром оказалась эта конфигурация.
У меня, как у разработчика, вызывает легкую оторопь рекомендации о необходимом оборудовании, при той минимальной функциональности которая нам нужна и ничтожном объеме данных которые мы используем. Как я понимаю возможности отключить неиспользуемый функционал в конфигурации нет.

(51) У меня легкую оторопь вызывает, что вы разработчик.

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

Хуже только консультанты по 120к на удаленке...

(53) Метнул так метнул)) всех забрызгало 2 предложениями))))

(52) H A D G E H O G s, боюсь вас может повергнуть в шок что в моем послужном списке непосредственное участие в создании платформы отчасти схожей с 1С, но не бухгалтерии а SCADA. Проект конечно был попроще, но представление о том как эффективно использовать вычислительные ресурсы было мной получено сполна.

(53) Garykom, согласен, но это во многих отраслях так.

(0) "Объем основного файла 6.8 Гб что кажется очень большим при таком небольшом количестве данных. "
У меня есть пустая база УТ 11.4.7.114.... ПУСТАЯ !! - ее вес 1.6 Гб.
И еще родная демо-база с небольшим количеством данных - ее вес 1.8 Гб.
Вычитаем 6.8 - 1.6 получаем 4.2 под данные.
После ТИИ и сжатия таблиц возможно уменьшиться на 0.5-1 Гб !

(56) Хм. У вас плохо со знаниями работы движков БД в части хранения данных на дисках.

(57)+ Намекаю при удалении записи не удаляются физически сразу, а только помечаются специальным признаком. Ну как пометка на удаление в 1С ))

Ну еще есть приколы с индексами, особенно полнотекстового поиска ну и мелочи с регистрами в т.ч. сведений. В курсе что update не используется а вместо этого delete и затем insert?

Не знаю как сейчас, но раньше, на сколько я помню, была рекомендация  делать тестирование и исправление базы перед каждым обновлением конфигурации. Мы и сейчас практикуем такую штуку. Почему то в базах на MS SQL и Postgree все с пеной у рта кричат про настройки и регламентное обслуживание для обновления индексов и т.д., а про файловые базы забывают.

(55) в шоке, ага

(57) да... 5.2 Гб :-)

После ТИИ стало:
Пустая 0.8 Гб
Демо 1 Гб

(61) H A D G E H O G s, как я понял, из вашего слегка язвительного комментария, вы приняли на свой личный счет мое недовольство прожорливостью 1С в целом и УТ в частности. Смею заверить ни каких намерений оскорбить чьи-либо чувства у меня не было.
В своем комментарии я специально отметил что мое недовольство касается именно наших условий использования: один пользователь, десять тысяч строк в базе, пусть даже двадцать тысяч, с запасом. Оказалось что 6.8 Гб на диске это норма для такой базы, плюс под это дело советуют отдельный сервер, SSD диски. Даже хочется язвительно предположить сервер с 256 гигабайтами оперативки и рам-диск, для совсем гладкой работы.
Чуть больше десяти лет назад я сталкивался с 1С v7 и не помню что бы у меня были проблемы с производительностью. Мало того, даже помню удивление от скорости парсинга средствами 1С, огромного по тем меркам текста.

(57) Garykom, несомненно, размер данных хранящихся на диске больше чем их полезный объем. Но, по моему мнению, далеко не всегда многократное превышение физического объема над полезным обусловлено необходимостью. Ведь бывает так что это вызвано неграмотным планированием, наследованием старых болячек и прочими недугами больших и длительных проектов.
Я не работал в коллективах, где количество разработчиков превышало десять человек, но чуть-чуть представляю себе что такое большой штат разработчиков, текучка кадров и особенно лидов, поджимающие сроки, костыли разбросанные там и тут.
Мне кажется что текущая прожорливость 1С скорее кроется в том, что практически не возможно содержать столь длительный и многофункциональный проект в идеальной причесанной форме и либо выходит новая версия написанная с нуля, либо проект начинает расплываться.

В общем прошу прощения за старческое брюзжание. Раньше сервера были выше а базы данных зеленее.

(63) Раньше не было такого разброса по быстродействии "серверов", компы были примерно похожи.
Сейчас же пара новых компов или серверов, купленных в одно время могут иметь разницу на порядки для "скорости 1С".
А еще все усугубляется неправильной настройкой 1С 8 УФ (1С 77 в этом плане проще) и/или неправильной эксплуатацией.