Вопрос по размерам таблиц в файловой БД
 

Всем доброго здоровьичка.
В целях собственного развития, ну и практического применения ради. Я вообще ни разу ни в зуб ногой в эту 1С, посему не судите строго.
Собственно, вопрос следующий. Пытаясь разобраться в структуре файловой БД 1С, обнаружил, что с какого то там года, кодеры этой конторы, наконец, разработали новый формат данных - 8.3.8, который позволяет играться с настраиваемыми размерами страниц от 8К до 64К, в отличии от стандартных 4К в структуре 8.2.14. Что позволяет файлам таблиц разрастаться до 6Гб, супротив 4Гб предыдущей версии.
Исходя из этого пара вопросов, к уважаемому сообществу:
1. Выяснил, что каким то образом можно посмотреть размер таблиц существующей базы данных 1С. Можно подсказку - это делается какими либо утилитами 1С(или через конфигуратор, например), либо только сторонними программами, написанными энтузиастами? Если можно - либо тут описать, либо кинуть ссыль.
2. Кто нибудь уже игрался с размерами таблиц? Какие выводы в части стабильности и производительности? В этих наших рунетах нашёл только один боль-мень подробный разбор полётов(двух летней давности) по конвертации с 8.2.14 на 8.3.8 с размером таблиц равным 32К. При этом, автор тупо написал - я сделал размер 32К, не вдаваясь ни в какие подробности и не отвечая на вопросы о причинах такого выбора.
Исходя из своих опытов, пока никак не связанных с замерами производительности, пришёл к выводу, что каждое увеличение размеров страниц, до следующего по списку, увеличивает размер БД на ~25%(исключение составляет лишь разница между 8К и 16К, там разница не столь велика. Так что нам может дать размер страниц, помимо "распухшей" базы?
Насчёт производительности немного наврал - пока единственный "тест на производительность", который получилось провести, это запуск "Тестирование и исправление" в режиме "тестирование и исправление" с очищением ссылок и удалением объектов:
- на базе объёмом 8,5Гб в варианте 8.2.14, 4 ядерный комп с 24 Гб ОЗУ и базой на ССД выполняет задачу в течении ~24 часов в монопольном режиме - т.е. только и исключительно эта задача;
- на базе объёмом 8,9Гб , в варианте 8.3.8 с размером страниц в 16К, та же самая конфигурация компа справляется за 8,5 часов, при этом, параллельно выполняется несколько других задач.
Есть мысли по этому поводу?
С уважением.

интереснее было бы провести тест
1 одной и той же базы
2 на одинаковой платформе

База одна и та же, в первом случае "родной" вариант, который был создан в 2014-м году, версия 8.2.14, соответственно, размер страниц 4К, во втором случае она же, но переконвертированная в 8.3.8 с размером страниц 16К. Железо одно и тоже. Запустить "мнопольный" тест с переконвертированной базой пока нет возможности.

а нет возможности сделать тест на 8 3 8, но с старым размером страниц?

А для чего?

(4) чтобы убедиться на 100%, что изменение скорости работы не из-за платформы

1. куча на просторах целая, например,
[url]https://infostart.ru/public/176476/?detail=Y[/url]
9Гб файловая имхо жесть. Не пора ли на скуль?

[quote=Фдуч;48263651] (4) чтобы убедиться на 100%, что изменение скорости работы не из-за платформы [/quote]
Убедится в этом не получится. Кстати, речь не о платформе, а о структуре БД. Опытным путём установлено:
- 8.3.8, 4К - "Тестирование и исправление" в режиме "тестирование и исправление" с очищением ссылок и удалением объектов длится ~18 или 19 часов;
- 8.3.8, 8К - ~14 часов.
С новой структурой, получается, база хоть и растёт, но и конкретное задание, выполняется быстрее, равно как и "холодный старт".

[quote=Efreytor;48264782] 1. куча на просторах целая, например, [url]https://infostart.ru/public/176476/?detail=Y[/url][/quote]
Инфостарт жадины, но да Ктулху с ими. Меня больше интересовало, есть ли "родные" утилиты от разработчика.
[quote=Efreytor;48264782] 9Гб файловая имхо жесть. Не пора ли на скуль?[/quote]
На чём основано Ваше "имхо"? Вот, например, помимо этого конкретного случая, в интернетах можно найти информацию о нормально работающих файловых базах объёмом под 18 Гб.

[quote=Шико;48267250]нормально работающих файловых базах объёмом под 18 Гб[/quote]
В большинстве случаев оказывается, что это не размер файла базы 1Cv8.1CD, а размер всего каталога с базой, вместе с логами распухшего ЖР, сканами прикреплённых доков, ЭДО и пр.

8-Шико >Более 20 организаций на поддержке. В среднем по 15 пользователей. Живут нормально на файловых, пока не достигнет порядка 8Гиг. Потом тормоза и соответственно скулеж. Переход на постгрис прекращает жалобы. С одним пользователем может и будет 18 нормально работать, не знаю, не пробовал ))

10-Efreytor >УТ 10.3 10Г, 10 пользователей, Tool показывает, что размеры баз 60% до критической, полет нормальный.

Если хотите прибавки скорости, то в первую очередь подгоните размер кластера диска так, чтобы он был равен размеру страницы. В этом случае страница будет считываться за одну операцию чтения, а не будет раздроблена на несколько кластеров, разбросанных по поверхности диска.
Ну а размер страницы - я думаю, что 8К наиболее подходящий размер для большинства баз. А остальные размеры нужны для тонкой настройки конкретной бд и зависят от множества факторов.

[quote=FuryFox;48267873] В большинстве случаев оказывается, что это не размер файла базы 1Cv8.1CD, а размер всего каталога с базой, вместе с логами распухшего ЖР, сканами прикреплённых доков, ЭДО и пр. [/quote]
Я учитывал это "большинство". Кстати, как решается проблема с распуханием базы, после подключения ЭДО?
[quote=Billi;48268717] Если хотите прибавки скорости, то в первую очередь подгоните размер кластера диска так, чтобы он был равен размеру страницы. В этом случае страница будет считываться за одну операцию чтения, а не будет раздроблена на несколько кластеров, разбросанных по поверхности диска. [/quote]
Ээээ... Какое отношение размер кластера имеет к размеру страницы БД? Я просто, реально, немного не в курсах структуры файловой БД 1С. Там что, каждая странца = отдельный файл спрятанный в авоську *.1CD?
[quote=Billi;48268717]
Ну а размер страницы - я думаю, что 8К наиболее подходящий размер для большинства баз. А остальные размеры нужны для тонкой настройки конкретной бд и зависят от множества факторов. [/quote]
В конкретном случае, хоть выборка и нерепрезентативна, а основывается лишь на задаче "Тестирование и исправление", опытном путём получен размер страницы в 16К. При 32К и 64К, базы увеличиваются, соответственно, на ~25% и ~50% соответственно, от 8К (при 16К всего на ~5%), а время обработки операции уменьшается уже в незначительных пределах - порядка 5% при каждом переходе: 16К, 32К, 64К (или 20-30 минут).

[quote=Шико;48270843]Какое отношение размер кластера имеет к размеру страницы БД? [/quote]
Движок базы данных записывает(считывает) данные на(с) диск(а) постранично, то бишь - единица информации в контексте работы с диском равна одной странице, а система работает с диском кластерами, то бишь - для системы единица работы с диском равна одному кластеру. Ну и отсюда следует, что для оптимальной работы с диском страница должна быть равна кластеру. Иначе операции запись/чтение значительно утяжеляются.
[quote=Шико;48270843]В конкретном случае, хоть выборка и нерепрезентативна, а основывается лишь на задаче "Тестирование и исправление"[/quote]
Вот именно, что "в конкретном случае", в котором происходит [b]последовательное[/b] чтение данных из таблиц. В этом случае, чем больше страница, тем больше [b]последовательных[/b] данных считается с диска в память за одну операцию чтения. Подобная операция не имеет ничего общего с реальной работой бд, в которой присутствует [b]рамдомное[/b] чтение, а особенно [b]запись[/b], данных.