Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Медленная работа УТ 11.4 файловая база 6.8 Гб с небольшим количеством данных

Медленная работа УТ 11.4 файловая база 6.8 Гб с небольшим количеством данных
Я
   Teapot
 
25.03.19 - 12:37
Приветствую.

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

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

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

Общая идея: сделать внешнюю обработку которая посчитает количество записей в регистрах сведений и если проблема в них, то очистит адресный классификатор.
Ну и призрачная надежда что просто не нашел в меню пункт в котором можно очистить адреса одним нажатием. Может кто подскажет.
 
 
   pavig
 
1 - 25.03.19 - 12:48
(0)
Арендуйте тестовый сервер в пробном режиме на день-два бесплатно и погоняйте базу там, сравните с вашим железом.
Я думаю что у вас проблема в железе, а именно - в слабом проце.
   pavig
 
2 - 25.03.19 - 12:49
Ну и платформу рекомендуемую поновее поставьте для общей картины
   pavig
 
3 - 25.03.19 - 12:51
И попробуйте таки поработать через веб-сервер.
Если пользователей много, то поэкспериментируйте с
http://catalog.mista.ru/public/242527/
   sqr4
 
4 - 25.03.19 - 12:56
(0) Воды много, конкретики нет. На проведение Реализации размер КЛАДРа не влияет.
   Teapot
 
5 - 25.03.19 - 12:57
pavig, спасибо за советы, боюсь проблема не в этом. В УТ пользователь один.
Сильно сомневаюсь что не хватает i5 для работы с 1С.
Узкое место - жесткий диск, на SSD чуть быстрее работает, но это не отменяет большого объема базы при минимальных количествах данных.
Неужели 6.8 Гб база нужна для такого небольшого количества данных?
   Teapot
 
6 - 25.03.19 - 13:00
sqr4, подскажите пожалуйста какая конкретика нужна?
Один пользователь, файловая база, УТ 11.4 объем базы, на мой взгляд, огромен.
   sqr4
 
7 - 25.03.19 - 13:01
Ну так посмотрите размер таблиц в чем дело, обработок море
   Cyberhawk
 
8 - 25.03.19 - 13:01
У тебя проблемы с логикой и построением выводов: по какой-то неведомой причине (скорее из-за недостатка интеллекта) ты связываешь размер данных со скоростью / отзывчивостью / производительностью работы в инфобазе.
   ptiz
 
9 - 25.03.19 - 13:08
(0) Очистка кладра никак не поможет, даже если он закачан. SSD - это как минимум. По сети - через апач.
   Teapot
 
10 - 25.03.19 - 13:08
Cyberhawk, эк Вас, батенька, припекло. С первого комментария и сразу оскорбления. Дышите глубже, проходите дальше :-)
И да, объем данных влияет на производительность, не вижу тут логической ошибки.

sqr4, копаю в этом направлении. В 1С совсем не ориентируюсь, по этому что очевидно для вас, для меня, увы, не особо.
   Cyberhawk
 
11 - 25.03.19 - 13:09
Попрошу без инсинуаций - Я холоден и рассудителен как никогда )
   vis_tmp
 
12 - 25.03.19 - 13:11
Есть обработки показывающие размер таблиц базы.
   Teapot
 
13 - 25.03.19 - 13:12
ptiz, вижу производительность в 1С это большая мозоль куда я по незнанию наступил :-)

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

Cyberhawk, что вы, никаких инсинуаций, просто проходите мимо :-)
   ptiz
 
14 - 25.03.19 - 13:22
(13) Tool1CD умеет показывать размер.
Из 6.8 Гб половина запросто может быть "пустой", из-за временного расширения базы при обновлениях (при ресструктуризации таблиц).
   Ray Zexter
 
15 - 25.03.19 - 13:22
(13) Ради прикола посмотри сколько абсолютно пустая файловая УТ11.4 весит.
   Ray Zexter
 
16 - 25.03.19 - 13:24
К тому же после ТИИ иногда размер заметно снижается.
   sqr4
 
17 - 25.03.19 - 13:24
(15) Моя демо гиг весит
   Teapot
 
18 - 25.03.19 - 14:11
Ray Zexter, 11.3 пустая, чуть меньше 1 Гб, если мне не изменяет память.
Запустил ТИИ, посмотрю что из этого получится.
Кстати база сжимается до 1.2 Гб что может говорить как о пустых страницах, так и о КЛАДРе(он тоже очень хорошо сжимается).

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

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

Может поисковую фразу не правильно составил? Ищу "1с обработка размеры объектов файловой базы"
   НаборДанных
 
19 - 25.03.19 - 14:17
(18)У вас гугл сбоит.
http://catalog.mista.ru/public/439778/
   unregistered
 
20 - 25.03.19 - 14:28
(10) > объем данных влияет на производительность, не вижу тут логической ошибки.

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

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

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

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

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

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

Для начала хочу разобраться с размером базы, а потом посмотреть какое это окажет влияние на производительность.
   Teapot
 
23 - 25.03.19 - 15:06
Подскажите пожалуйста, это я туплю или для catalog.mista.ru не подходит аккаунт от форума?
   papiruso
 
24 - 25.03.19 - 15:06
Попробуй создать нового пользователя и сравни скорость работы.
   Teapot
 
25 - 25.03.19 - 15:11
(24) Евгений Ваганович, перелогиньтесь :-)
   timurhv
 
26 - 25.03.19 - 15:15
(10) >объем данных влияет на производительность, не вижу тут логической ошибки
Террабайтные базы должны встать колом, проводиться документы по году-два.
   Вафель
 
27 - 25.03.19 - 15:15
(23) это же инфостарт
   sqr4
 
28 - 25.03.19 - 15:19
(26) да что вы говорите
   sqr4
 
29 - 25.03.19 - 15:20
(26) так походу я опять нифига не понял, сори за то что выше
   Teapot
 
30 - 25.03.19 - 15:30
(26) >Террабайтные базы должны встать колом, проводиться документы по году-два.
Если используются данные находящиеся в этих огромных базах, то да, могут возникнуть проблемы с производительностью. В прочем пустой этот диалог. Я так понимаю вы не особо вчитывались в предыдущие сообщения. Я не знаю внутреннюю механику работы 1С. Было высказано предположение: "грешим на КЛАДР". Сейчас акценты сместились на "найдем почему база такая большая" и попробуем ее уменьшить. Если не поможет с производительностью, будем думать дальше.

(27) >это же инфостарт
Я человек простой - вижу в адресе домен mista, сразу предполагаю связь между forum и catalog :-)
Как я уже говорил выше - 1С далек от моей сферы деятельности, отсюда не знание даже элементарных интернет-ресурсов.
 
 
   Sapiens_bru
 
31 - 25.03.19 - 15:36
(22) "тот кто к нам ходит сказал что ничего сделать не может" Это как раз нормально. Более того вполне возможно его посещения являются причиной.
Между тем у 1С есть целый комплекс специфических знаний и инструментов для обеспечения скорости работы.
   sqr4
 
32 - 25.03.19 - 15:39
(30) Я как понимаю вы не особо вчитываетесь, в то что вам пишут. Вот и хрен то что вы не разбираетесь. Я вам еще раз говорю, размер КЛАДР не влияет на скорость проведения реализации. В 1с используются регистры, виртуальные таблицы и т.д. И будь хоть миллиард документов реализация и поступления, но таблица остатков (если все нормально) сформируется быстро и только по тем документам, которые остатки сделали.

Поэтому вас и спросили, какие базовые операции у вас висят по 10 и более секунд. И только поняв, что где и как можно понять причину этих зависаний и что от них спасет. А вот это - "База слишком большая", похожа на бред вашего полоумного начальника, которому жалко денег на нормального спеца.
   МимохожийОднако
 
33 - 25.03.19 - 15:41
(30) " не знаю внутреннюю механику работы 1С"
Пригласить специалиста уже было?
Хочешь разобраться - включи замеры производительности. Не можешь включить - научись. Не можешь научиться - пригласить..Стоп. Это уже было.
...
   МимохожийОднако
 
34 - 25.03.19 - 15:43
(23) Оба предположения правильные.
   H A D G E H O G s
 
35 - 25.03.19 - 15:47
(0) Достаточно посмотреть на объем считанных данных в результате базовой операции и все вопросы отстегнутся.
Типовая УТ11.4, проведение РТУ, 340 Мб считанных данных. Но быстро, так как SSD. Страшно представить как там в HDD
   Teapot
 
36 - 25.03.19 - 16:27
(32) sqr4, дышите глубоко, не волнуйтесь так. Про КЛАДР я не однократно прочитал и неоднократно отвечал. Специально для Вас повторю: параллельно с вопросом производительности пытаюсь понять почему такой размер базы.
>Поэтому вас и спросили, какие базовые операции у вас висят по 10 и более секунд.
Тут я понимаю вы опять (29) Про операции у меня ничего в этом треде не спрашивали или покажите в каком вопросе. Ну да ладно, тоже пустое. Произведу замеры.

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

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

(35) H A D G E H O G s, читаю про измерение производительности.
   sqr4
 
37 - 25.03.19 - 16:37
(36) Волновать надо тем, у на чьей базе вот такие альтруисты работают. Хотя это все пустое, делайте замеры.
   Sapiens_bru
 
38 - 25.03.19 - 16:46
(36) Ключевое в моем сообщении было не то чья вина, а то что в 1С есть способы расследования проблем производительности и исправления этих проблем. Но рядовым 1С программистам эти механизмы не известны и по большей части не нужны.
Именно расследования с точным определением проблем и путей решения, а не гадания но кофейной гуще по размерам баз, маркам процессоров и количеству элементов в таблицах
   Teapot
 
39 - 25.03.19 - 17:45
(37) sqr4, руководство попросило объявить вам благодарность за такую трогательную заботу :-)

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

В общем всем спасибо за ответы. Будем измерять :-)
   Sapiens_bru
 
40 - 25.03.19 - 17:48
(39) Вы там что-то свое поняли. Не надо графики совмещать - надо настроить сбор статистики и после сбора её проанализировать. При этом можно с пользователем вообще не пересекатся.
   Очевидно
 
41 - 25.03.19 - 17:52
(0) Sql express edition (бесплатный до 10 ГБ) - не предлагать ?
Получите :
 1. Многопоточность при проведении
 2. Статистику по таблицам и их весу
3. Анализ узких мест производительности.
   Sysanin_1ц
 
42 - 25.03.19 - 17:55
(0) Проверь есть ли документы введенные будущей датой. Если кто то из бухов ввел документ 2120 годом то база может вырасти до огромных размеров
   Teapot
 
43 - 25.03.19 - 17:56
(40) Sapiens_bru, а вот до этого я еще не дочитал :-) Это было-бы замечательно.
(41) Очевидно, под одного пользователя SQL? Не хотелось бы усложнять. Пока попробую разобраться в том что есть.
(42) Sysanin_1ц, ого! Спасибо, попробую :-)
   Timon1405
 
44 - 25.03.19 - 18:06
(41) а сервер 1с к нему тоже бесплатно прилагается?
   Очевидно
 
45 - 25.03.19 - 18:10
(44) к сожалению, нет ... прост расследование проблем производительности на файловой БД , типовой УТ, скорее всего ограничится счетчиками Perfmon'а. что даст очень слабую информацию о проблеме ... но дело оно такое, добровольное ...
   Sapiens_bru
 
46 - 25.03.19 - 19:26
(45) ТЖ даёт очень сильную информацию, даже в файловой базе. Да и замеры времени работают из стандартной БСП. Трассировку не собрать да.
   Garykom
 
47 - 25.03.19 - 19:38
(0) Размер файловой базы УТ 11.4 в 6.8Гб вполне нормальный, на скорость влиять не должно.
SSD и веб-сервер файловый вариант спасут, никаких работ толстым клиентом по локальной сети.
Плюс легкая оптимизация и параметры железа не озвучены с количеством пользователей и фоновых/регламентных.

Если файловая на виртуальном сервере то тормоза вполне логичны, ссзб.
   cons24
 
48 - 26.03.19 - 09:27
(0) стучите в почту
   Turku
 
49 - 26.03.19 - 09:44
(47) Все так. Автор лишь написал, что "i5". И Все. А так да: SSD must-have! И не только под саму базу, но и под кеши/темпы. Оперативки достаточно. Проц чтоб был в "максимальной производительности". И убрать роль Hyper-V на том сервере, если не дай бог, она там есть. А вот дальше уже копать в программную сторону.
   Turku
 
50 - 26.03.19 - 09:45
О размере базы волноваться не надо: простое обновление УТ 11.3 -> УТ 11.4 увеличило размер на 30%.
   Teapot
 
51 - 26.03.19 - 16:32
Спасибо всем ответившим.
Сделал ТиИ, база ужалась с 6.8 Гб до 1.8 Гб
По отзывам стало чуть быстрее, но это может быть эффект плацебо, по этому держим курс на замер производительности.

PS: Конечно я немного ошарашен тем каким прожорливым и неповоротливым монстром оказалась эта конфигурация.
У меня, как у разработчика, вызывает легкую оторопь рекомендации о необходимом оборудовании, при той минимальной функциональности которая нам нужна и ничтожном объеме данных которые мы используем. Как я понимаю возможности отключить неиспользуемый функционал в конфигурации нет.
   H A D G E H O G s
 
52 - 26.03.19 - 16:41
(51) У меня легкую оторопь вызывает, что вы разработчик.
   Garykom
 
53 - 26.03.19 - 16:44
Да сейчас модно себя разработчиками и внедренцами называть, хотя даже программистами не научились быть.

Хуже только консультанты по 120к на удаленке...
   palsergeich
 
54 - 26.03.19 - 16:47
(53) Метнул так метнул)) всех забрызгало 2 предложениями))))
   Teapot
 
55 - 26.03.19 - 17:32
(52) H A D G E H O G s, боюсь вас может повергнуть в шок что в моем послужном списке непосредственное участие в создании платформы отчасти схожей с 1С, но не бухгалтерии а SCADA. Проект конечно был попроще, но представление о том как эффективно использовать вычислительные ресурсы было мной получено сполна.

(53) Garykom, согласен, но это во многих отраслях так.
   Rovan
 
56 - 26.03.19 - 17:52
(0) "Объем основного файла 6.8 Гб что кажется очень большим при таком небольшом количестве данных. "
У меня есть пустая база УТ 11.4.7.114.... ПУСТАЯ !! - ее вес 1.6 Гб.
И еще родная демо-база с небольшим количеством данных - ее вес 1.8 Гб.
Вычитаем 6.8 - 1.6 получаем 4.2 под данные.
После ТИИ и сжатия таблиц возможно уменьшиться на 0.5-1 Гб !
   Garykom
 
57 - 26.03.19 - 17:55
(56) Хм. У вас плохо со знаниями работы движков БД в части хранения данных на дисках.
   Garykom
 
58 - 26.03.19 - 17:56
(57)+ Намекаю при удалении записи не удаляются физически сразу, а только помечаются специальным признаком. Ну как пометка на удаление в 1С ))
   Garykom
 
59 - 26.03.19 - 18:01
Ну еще есть приколы с индексами, особенно полнотекстового поиска ну и мелочи с регистрами в т.ч. сведений. В курсе что update не используется а вместо этого delete и затем insert?
   edem911
 
60 - 26.03.19 - 18:04
Не знаю как сейчас, но раньше, на сколько я помню, была рекомендация  делать тестирование и исправление базы перед каждым обновлением конфигурации. Мы и сейчас практикуем такую штуку. Почему то в базах на MS SQL и Postgree все с пеной у рта кричат про настройки и регламентное обслуживание для обновления индексов и т.д., а про файловые базы забывают.
   H A D G E H O G s
 
61 - 26.03.19 - 18:13
(55) в шоке, ага
   Rovan
 
62 - 26.03.19 - 18:17
(57) да... 5.2 Гб :-)

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

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

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


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.