Раздули одни клиенты Бухгалтерию 3.0 сильно за 20 гигов. База файловая, пользователи работают из-под Apache. И вот плановое обновление пошло не так. Пишет "Недостаточно памяти". Вопрос старый, ответов на него много, но вот какое но:
1. Операционка 64-битная
2. Физической памяти нарастили с 4-х до 8 Гб.
3. Адресного пространства приложениям через bcdedit добавили аж до 7Гб.
4. chdbfl-ом лечили.
5. Тестирование-исправление делали.
И все равно не хватает... Можно что-то еще сделать? Скоро месяц, как обновиться пытаемся...

(0) Типовая?

(0) пора на скуль переходить

что такое "плановое обновление" и в какой момент пишет "Недостаточно памяти" ?

(0)
> Вопрос старый, ответов на него много, но вот какое но:
Отличная форма подачи. Ответов, дескать много, а у нас вот такой конфиг. Ичо?

> 3. Адресного пространства приложениям через bcdedit добавили аж до 7Гб
Это 32х битному клиенту-то? Ну да, ну да...

Вылет по памяти файловой базы обычно происходит из-за невозможности SDBL движка выполнить действие при реструктуризации на больших объемах. Запрос на уникальность значений измерений регистров, коды справочников/ПВХ и тыпы.

Читайте найденные ответы, которых много, ищите, чистите данные, переходите на SQL.

(1) Практически. Пара косметических правок
(2) Знаю, денег пока нет. А левым образом очково
(3) Обычное очередное обновление. Пишет после нескольких часов работы.
(4) А что не так с формой подачи? Ответов много, я перечислил свои действия на все найденные ответы. Пишу сюда - может еще какой-то ответ будет, которого я не нашел.

Не помню,а в файловом варианте ТЖ фурычит?

(5) Поставьте 64битного клиента.

(5) ну на 20-ти гектарах и без скуля, как на минном поле - никогда не знаешь после какой транзакции она скажет что устала и уходит от вас навсегда

(5) В общем памяти скорее всего не хватает в какой нибудь таблице. Попробуй на копии сделать реструктуризацию таблиц потом реиндексацию

(5) Если есть много помеченных на удаление объектов, то грохни их, потом реструктуризацию таблиц, чтобы уменьшить физический размер таблиц.

(7) Ок, попробую, спасибо.
(9)(10) Делал уже, не помогло.

(0) Физической памяти то достаточно? Там где переменные среды определены.

(11) Формат файла базы и размер страниц какой? Если 8.2.14 и 4кб сконвертируй в новый, хотя 20гб размер большой до этого уперлись бы наверно...

(11) а версия клиента какая?

(13) 64 битный клиент решит все его проблемы.

Ох, упрется одна из таблиц регистра бухгалтерии или еще какая-нить в макс.размер таблицы 4Гб (ну или 6Гб, если 8.3.8 и выше, да и то с бубном) и будет счастье - дальше без скуля уже будет никак )

(16) Из статьи на инфостарте - при размере стр. 64К размер файла - 16Тб
http://catalog.mista.ru/public/536343/

Мне кажется это уже лень а не вопрос.

1) - Обнови не на 10 релизов сразу а по одному
2) - Перейди на более мощный комп и там обнови раз такой уникальный случай
3) - Перейди на x64
4) - Перейди на скуль
5) - Разумным будет посмотреть какая таблица раздута да и почистить её?

Можно выполнить одно из этих действий, а желательно сразу все.

6) - Поставь последнюю платформу

(21) "Вопрос старый, ответов на него много, но вот какое но:" (:

(22) Да уж... Это просто - л.е.н.ь.

(15) Не решит, есть база файловая. Нужно обязательно переходить на файл-серверную.

(15) => Прав: (24)

(15) (24) А даже если коем то образом и "Проскочит" за счёт каких то оптимизаций в новых платформах по использованию памяти в моменты реструктуризации - база в самый "подходящий" момент может грохнуться, не стоит рисковать чужими данными.

...запятые я что то забыл)

(18) а из документации на 8.3.8 - 8.3.10 "с размером страницы 8 192, 16 384, 32 768 и 65 536 байт – 6 Гбайт."
Дальше не едет.

(28) -> (17)

Переходи на PostgreSQL. Сейчас 9.6.5 последняя, скоро ожидается 10, там новые плюшки для 1С реализовали. Под Linux воткнуть - можно протестировать без серверного ключа.

(30) Это любителям особых приключений?) 24 символа после запятой починили?)

(28) Ну да, ограничение явно указано на итс. У меня скульная бп в 36 гб спокойно загрузилась в файловую, вот и думал что ограничений нет. Надо попробовать 100 гиговую загрузить)))

(30) Ее назад в статус беты вернули или я чего не знаю? "Без ключа" же давно прикрыли.

(32) Ты немножко не понимаешь, ограничение не ВСЕГО размера базы, а размера ОДНОЙ таблички в ней. Т.е. у ТС какая то таблица (видимо хранилище файлов) раздуто сильно. Вот и лезет ошибка.

(32) т.е. если у тебя размер 590 гб и там 100 таблиц по 5.9 гб - то база загрузится из ДТ =) Только если комп не сгорит :D

(33) На 1С она в тесте и не появлялась, вроде как. Зато на Про лежит именно 9.6.5. По ключу не знал, хотя если так, то жаль.

(34) Да я и говорил про размер "внутреннего файла", так 1с таблицы называет. Кстати таблица может состоять из 4х файлов (разного назначения), так что там больше 6ти выйдет. Видать по этому и не напоролся на ограничение..

(36) Она пока в продакшн не вышла, можно было до 10ти пользователей без ключа. А теперь усе..

(37) Мне кажется, что 1С изначально заглушку на размер таблицы оставили. Я в свое время пытался в файловую на 64битно клиенте под Linux выгрузить - не получилось.

(37) о как, ну да =) Верно. ТС по любому чистить базу надо если у него база в ДТ уже не выгружается (но это не точно).

Только сейчас прочитал что пытаются уже месяц.... Видимо не очень то ему и надо) Расходимся :D

(39) Об этом остаётся только догадываться, заглушке много лет. Может это связано с тем что потом сильно блокировки мешают, управляемые блокировки работают в файловой базе?

(41) Упр. блокировки работают и в файловой но там все равно блокируется таблица целиком, толку от них мало. А ограничение наложено специально, шанс похерить большую файловую бд оч. высок. Она не защищена ничем.

(42) понял) Спасибо

(32) У нас было такое, что скульная база, за несколько лет работы раздувшаяся до >100Гб отказалась загружаться из dt в файловую. Налоговики долго возмущались - "эт нам чо, теперь скл на нотбуке разворачивать?" XD

Все получилось. 64-х битный клиент помог, всем спасибо.