Имя: Пароль:
1C
1С v8
"Неисправимая ошибка" при свертке базы
, , ,
0 soulectro
 
16.01.20
15:40
Платформа 8.3.13.1690, конфа УТАП 11.4.9.83

При свертке базы во время выполнения второго пункта 1С отваливается с ошибкой: "Невосстановимая ошибка Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm по причине:" и всё на этом.а
1 soulectro
 
16.01.20
15:44
База весит 100Гб, оперативной памяти на сервере 64Гб, в настройках кластера снимал ограничение(-1) про максимальный объем памяти, не помогло.
2 Очевидно
 
16.01.20
16:21
... может тех. журнал глянуть ?
3 soulectro
 
16.01.20
16:49
(2) смотрел, никаких подробностей
4 soulectro
 
18.01.20
17:52
up. Попробовал обновить сервер и платформу до 8.3.14.1976, не помогло, та же самая ошибка.
5 Фрэнки
 
18.01.20
20:25
(4) но памяти не хватает.
Может у тебя клиент, с которого свертку запускаешь, она на 32-бит, т.е. ошибка не на сервере, а на клиенте?
6 AAA
 
18.01.20
21:06
а зачем свертка http запросы делает ?
7 soulectro
 
19.01.20
03:00
(5) Всё x64, свертку запускаю прямо на сервере. Есть подозрение конечно, что тупо памяти не хватает, в процессах рождаются rphost в количестве 7 штук, один основной отъедает 1,4Гб оперативы, другие по 300-500Мб, разрешено памяти на один процесс до 20Гб, после какого-то времени 1С падает с ошибкой и эти процессы сокращаются.
8 Фрэнки
 
19.01.20
10:00
(7) А есть статистика, что этот рпхост перед падением доходит до предела памяти?

Понятно, что ошибка сформулирована именно в таком сообщении, которое отсылает к проверке памяти, но действительно ли в памяти проблема...

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

А может быть, с учетом того, что базу надо изнасиловать, обеспечить этому событию абсолютную монопольность на сервере?
Ну и убрать при этом любые ограничения на использование памяти, конечно.

Вообще, Заказчику в подобной ситуации нужно понимать, что одного сервера для нормальной работы в режиме 24/7 при таком размере баз и процессов уже не хватит.
И если КОРП версию 1С покупать по стоимости просто неадекватно, то может быть имеет смысл купить просто еще одну лицензию на сервер 1С
и запускать всякие системные и сервисные вопросы на дополнительном компьютере.

Например, этот дополнительный сервер можно поставить на линукс платформе (это такой ненавязчивый намек)
9 soulectro
 
20.01.20
02:37
(8) Дело в том, что при свертке базы, наблюдая за статистикой я увидел нагрузку на память всего 15%, проц sql сервером отъедался на 35% максимум. Полная монополия была обеспечена для этого дела. Так же игрался с параметрами кластера и сервера 1С, убирая любые ограничения по памяти, устанавливая перезапуск процессов чаще, ничего не помогло. Сегодня попробую выгрузить базу в файл и сделать свертку. По поводу дополнительного сервера это было бы замечательно, но руководство у нас очень сложное на выделение средств.
10 Фрэнки
 
20.01.20
08:48
(9) ненавязчивых намеков не понимаем? ну тогда ладно.
11 soulectro
 
20.01.20
08:55
(10) да понимаем, другое дело, что это требует достаточно больших временных затрат, а нужно сейчас, а лучше вчера )))
12 Фрэнки
 
20.01.20
09:05
(11) а пробовал в порядке проверки работоспособности свертки, как обработки, запустить на короткий период? Т.е. на первые два года работы базы, а не весь период, который решили свернуть?

Кстати, как-то очень давно уже не приходилось проверять на практике, что получается со свертками, если их делать по каждому году, а не сразу за большой период - будут они поддерживать корректно наличие последовательности предыдущих сверток.
13 soulectro
 
20.01.20
09:10
(12) Не поверишь, но это один из вариантов, который мне сегодня утром пришел на ум. Так же есть еще одна задумка. У нас в базе по алкоголю хранится очень большое количество сканов сопроводительной документации, которая распечатывается при реализации товара. Не знаю сработает ли это, сработает ли правильно, но, что если попробовать выпилить эти сканы из базы? ну и соответственно подчистить ссылки на все эти изображения? Я сам не программист, но есть возможность озадачить человека написать обработку под это дело.
14 Масянька
 
20.01.20
09:32
(9) А загрузку диска смотрел?
15 soulectro
 
20.01.20
09:42
(14) Диск тоже не сильно напрягался.
16 unregistered
 
20.01.20
09:45
(8) >> одного сервера для нормальной работы в режиме 24/7 при таком размере баз и процессов уже не хватит.

Странное утверждение. У нас работают базы и по 150ГБ и даже больше, и не по одной штуке на одном(!) сервере, и 24/7.
По-моему, размер базы - это отнюдь не единственный параметр, на который следует опираться, делая подобные заявления.
17 unregistered
 
20.01.20
09:47
(0) Автор. А нафига вообще вам свёртка?
Тупой конечно же вопрос, но на всякий случай спрошу. А перед запуском свёртки тестирование и исправление базы и конфигурации делали? Уверены, что в базе действительно нет ошибок?
18 unregistered
 
20.01.20
09:49
(9) >> игрался с параметрами кластера и сервера 1С, ... устанавливая перезапуск процессов чаще.

В чём смысл этого действа?
В чём смысл вообще установки перезапуска процессов?
Уверены, что проблема не связана с тем, что рабочий процесс по вашей же настройке перезапускается и теряет связь с реальностью (длительная незавершенная транзакция падает)?
19 unregistered
 
20.01.20
09:52
(7) >> разрешено памяти на один процесс до 20Гб

Для чего установлено это ограничение? В чём смысл?
20 soulectro
 
20.01.20
09:53
(17) Свёрка нужна для уменьшения объема базы в первую очередь, есть в этом нужда, да и в любом случае тот период, который подвергается свёртке полностью закрыт и давно забыт. ТиИ делалось.
(18) Пробовал и с большим временем до перезапуска процесса, проблема не решилась.

(19) оно было установлено изначально, когда я пришел работать. Ограничения снимались для выполнения свёртки.
21 unregistered
 
20.01.20
09:53
Складывается впечатление, что вы понастроили кругом заборов и теперь пытаетесь понять какой именно из них мешает приложению.
22 soulectro
 
20.01.20
09:54
(21) Еще раз повторюсь, что так называемые "заборы" были убраны полностью, когда столкнулись с проблемой указанной в самом начале, но это не спасло ситуацию.
23 unregistered
 
20.01.20
09:55
(20) >> Свёрка нужна для уменьшения объема базы

Более идиотскую потребность придумать сложно. Я бы ещё понял, если бы база была в несколько терабайтов. Но ради 100Гб устроить себе такой геморрой... Успехов.
24 Vstur
 
20.01.20
09:56
(23) +100500
25 Ёпрст
 
20.01.20
09:57
(0) поделку для свертки где хоть взяли то? И она прям для утапа написана? )
26 unregistered
 
20.01.20
09:58
+ к (23) И не удивляетесь, когда поймёте, что база сократилась только на 15-20%% вместо ожидаемых 50-70%% (или сколько вы там планируете).
Следующие вопросы автора будут - что делать с неудалившимися, но помеченными на удаление объектами, и почему размер базы почти не изменился.
27 Ёпрст
 
20.01.20
09:59
А так, посмотреть базопузомером, что там место занимает и выкосить лишнее и свертка не нужна будет. Если еще и сжатие в скуле включмть и реструктуризовать таблички в скуле..она еще похудеет в разы
28 soulectro
 
20.01.20
10:18
(23) нет возможности работать с таким объемом данных комфортно, ресурсов маловато серверных и расширить их в ближайшее время не представляется возможным.
29 unregistered
 
20.01.20
10:54
(28) >> нет возможности работать с таким объемом данных комфортно

С таким - это с каким? Какой ожидается объём?
Вы отдаёте себе отчет в том, что никакой разницы по комфорту работы между 100Гб и 50Гб не будет? Не боитесь, что наобещав пользователям манну небесную, устроив им ад на земле со сверкой начальных остатков их выверкой и исправлением всех косяков свёртки, вы будете ими прокляты, когда они поймут, что никакого обещанного комфорта нет? Кроме мифической экономии дискового места для бекапов никакого толку от свёртки нет. И это надо чётко понимать.
И что же поменяется, когда вместо 100Гб база будет весить, например, 80, а через год - снова 100?

>> ресурсов маловато серверных.

Каких именно?
30 palsergeich
 
20.01.20
10:55
Есть конторки которые за сотку другую свернут остатки скульным скриптом.
31 Ёпрст
 
20.01.20
10:56
(28)
Ё.. вам нужен базопузомер, а не свёртка. Тем более, в утапе.
Там поди ни разу никто всякие регсведения типа запросыегаис/запрросы и ответы егаис и т.д не чистил никогда
32 soulectro
 
20.01.20
11:05
(31) поделитесь ссылкой?
И да, никто никогда ничего не чистил.


(29) когда база весила 50Гб, работала она заметно быстрее. Да можно говорить за усталость оборудования, но нет, все проверки по железу проходят на ура, реиндексация и ребилд индексов делается регулярно по расписанию.
33 Ёпрст
 
20.01.20
11:12
(32) та любую с нимфостарта, хоть такую
http://catalog.mista.ru/public/251332/
34 hhhh
 
20.01.20
11:12
(32) кеши чистите? И еще настройки вариатов отчетов. Со временем могут занимать гигабайты. И реиндексацией вы их нифига не удалите
35 soulectro
 
20.01.20
11:13
(34) Да, кеши чистим тоже регулярно. А про настройки вариантов отчетом можно подробнее, куда копать?
36 ZDenis
 
20.01.20
11:19
(32) SQL И 1С на одном сервере? (в (9) есть намек на это). А то про ограничение 1С на память прочитал, а SQL вообще может под себя всю память забрать.
37 soulectro
 
20.01.20
11:22
(36) Да, всё крутится на одном сервере, в настройках SQL стоит ограничение до 25Гб потребляемой памяти, т.к. уже сталкивался с тем, что он кушает как не в себя )
38 soulectro
 
21.01.20
03:52
Взяли период свертки один первый год, чуть дольше попытался поработать, но в итоге все равно отвалился с той же ошибкой.
39 rphosts
 
21.01.20
04:39
(34) и форм бывает тоже
40 soulectro
 
21.01.20
05:07
Короче самая жирнота это регистр сведений "Двоичные данные файлов " со сканами сопроводительных документов... только они весят почти 65Гб...
41 rphosts
 
21.01.20
06:22
(40) вынеси во внешнее хранение и сожми РС
42 soulectro
 
21.01.20
06:37
(41) Не будет ли от этого медленнее проходить работа с этими файлами? Опять же, как это скажется на надежности?
43 rphosts
 
21.01.20
06:42
(42) копать молотить!!! Если адекватно разместишь - будет быстрее!
44 soulectro
 
21.01.20
06:53
(43) Спасибо!
45 unregistered
 
21.01.20
08:53
(32) >> когда база весила 50Гб, работала она заметно быстрее.

Во-первых, уменьшения в два раза вы не получите.
Во-вторых, я уверен на 99%, что это утверждение явно ничем не подкреплено, кроме субъективных утверждений. Потому что чудес не бывает. Ибо скорость работы клиент-серверной базы мало зависит от её объёма (во всяком случае, когда речь идёт о 100Гб).
В-третьих, даже если реально имеет место снижение скорости (что, по-моему, не факт), то причина, скорее всего, не в объёме, а либо в самой конфигурации, либо в данных (какие-то регистры не закрываются). Не исключено, что и в железе или кривой настройке SQL.
46 soulectro
 
21.01.20
14:50
(45) спасибо за Ваши ответы, непременно буду изучать все моменты. Я далеко не программист, а средней руки сисадмин, прогера наняли только пару дней назад, так, что пока только "въезжает в тему".
47 soulectro
 
21.01.20
14:53
(43) можно еще вопрос? после переноса файлов на том, они всё еще остаются в базе, как их вычистить? не разу не пользовался функционалом хранения файлов на томе, подумал, что после переноса файлов во внешнее хранилище они из базы потрутся сами.
48 rphosts
 
21.01.20
15:39
(47) 1.В РС добавляешь Реквизит в котором указываешь полный путь к файлу, устанавливаешь значение этого реквизита попутно сохраняя файлы на диск, удаляешь реквизит типа ХранилищеЗначений.
49 Фрэнки
 
21.01.20
15:42
(48) но база автоматом не сожмется, наверное? шринки там какие-то... процедуры в админке СУБД надо бы...