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

Новый формат ЖР

Новый формат ЖР
Я
   ugorchina
 
07.05.21 - 13:10
Всем привет!
Подскажите на скульной версии если перейти на новый формат журнала данные не поедут?

Вообще как этот новый формат себя показывает? В плане надёжности и быстродействия.

И можно ли чистить ЖР это никак не влияет на данные?
   ДенисЧ
 
1 - 07.05.21 - 13:14
Журнал регистрации и его формат к данным в ИБ отношение имеет такое же, как пренатальные карты к положению Марса относительно дзеты Водолея...
   shuhard
 
2 - 07.05.21 - 13:14
(0) дык уже отказались от нового формата, ты олешек покорми =)
   ДенисЧ
 
3 - 07.05.21 - 13:14
Но лучшие собаководы и кошероведы очень не рекомендуют использовать новый формат
   shuhard
 
4 - 07.05.21 - 13:17
(3) давно пора его по галахе запретить =)
   ДенисЧ
 
5 - 07.05.21 - 13:22
(4) По УК )))
   ugorchina
 
6 - 07.05.21 - 13:28
Спасибо. Короче буду просто почистить ЖР.
   ugorchina
 
7 - 07.05.21 - 13:29
За 4года там данных с трёх баз уже 500+ гиг )
   ansh15
 
8 - 07.05.21 - 13:51
Информация о том, кто что наковырял в базах, оказывается значительно дороже, чем сами данные.
Наверное, политика информационной безопасности, принятая в организации, так предписывает.
   Вафель
 
9 - 07.05.21 - 14:01
ЖР не нужен
Нужно версионирование.
ЖР только для регистрации ошибок
   Вафель
 
10 - 07.05.21 - 14:02
Конечно архитектора из 1с который из всех бд выбрал скллайт на кол
   1Сергей
 
11 - 07.05.21 - 14:40
(9) +1

но, когда отключаешь версионирование, быстродействие вырастает в разы :)
   ugorchina
 
12 - 07.05.21 - 16:58
(10) 1с поддерживает  Sqlite?

Или что Вы имеете в виду?
   acanta
 
13 - 07.05.21 - 17:00
А может в sqllite что-то можно записывать и считать? Данные, а не жр?
   fisher
 
14 - 07.05.21 - 17:03
(10) Ты хотел сказал, который вообще выбрал БД для хранения первичных логов?
   fisher
 
15 - 07.05.21 - 17:04
Из ембеддед БД скулайт как раз логичный выбор. Но не для логов же. Для первичных логов только текст.
   Вафель
 
16 - 07.05.21 - 20:22
Надо было кликхаус выбирать (шутка)
   ugorchina
 
17 - 07.05.21 - 21:51
(15) писем Вам скуллайт как бд не нравится?
Производительность хорошая, ограничений нет, но однопользовательская
   Вафель
 
18 - 07.05.21 - 22:51
(17) чтение блокирует запись
   ansh15
 
19 - 07.05.21 - 23:41
Приладить к ClickHouse Logstash  и эти, как их там, Elasticsearch  с Grafana(что там еще есть аналогичного).
Можно будет продавать отдельно, как сервер взаимодействия, например.
   ДенисЧ
 
20 - 08.05.21 - 06:08
(19) Не забыть ремни приделать. Чтобы было что пристёгивать, когда вся эта х????ь будет пытаться взлететь
   ildary
 
21 - 08.05.21 - 06:21
Вот Вы смеетесь, а в итоге так и сделают, ибо лицензия КОРП сама себя не продаст.
   fisher
 
22 - 08.05.21 - 17:46
(17) Где я сказал, что скулайт мне не нравится как БД? Вроде как раз наоборот сказал. Мне не нравится вообще использование БД (любой) для хранения первичных логов.
Еще раз повторюсь - первичные логи должны быть в тексте. А сверху уже если сильно хочется - можно и агрегаторы логов с БД, еластик серчами и всей лабудой по списку.
   Вафель
 
23 - 08.05.21 - 22:32
(22) чем текст лучше чем бд?
   ansh15
 
24 - 08.05.21 - 23:42
(20) На серверах, которые в большинстве случаев используются для 1С? Конечно, на них это все даже как крокодил не сможет летать, низехонько-низехоноько.
   ДедМорроз
 
25 - 10.05.21 - 01:25
(22)если бы каждый поток писал в свой файл,то да,текстовые файлы-самое лучшее и надёжное,что придумали.
А так как все в кучу пишут в один файл,то база данных в этом случае позволяет получить хоть какую-то параллельность,а также явное выполнение пометки транзакций,что в случае с текстовым файлом нереально(так как нужно сменить флаг у уже сделанной записи)
И,самое главное,журнал регистрации,все же не просто Лог-файл.

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

В случае 1с и падении процесса,наличие или отсутствие записи в журнале в момент падения не критично,для реального отлова ошибок есть технологический журнал.
   H A D G E H O G s
 
26 - 10.05.21 - 12:44
(23) тем, что пишется Предсказуемо со скоростью "Ssd Гб в секунду"
   H A D G E H O G s
 
27 - 10.05.21 - 12:45
(25) в 1С пишет rmngr, а не rphost и падает он на порядки реже.
   H A D G E H O G s
 
28 - 10.05.21 - 12:47
А вот rphost общается с rmngr по tcp, и это вносит почти 35% задержки в производительности серверного кода.
Я не понимаю, почему тут нет именнованного канала или общей памяти.
   Вафель
 
29 - 10.05.21 - 12:53
(28)  потому что может быть на другом компе, а 2 варианта поддерживать влом
   ДедМорроз
 
30 - 10.05.21 - 13:15
Менеджер как раз тоже хорошо падает,и ошибки известны,при которых это происходит.
 
 
   ДедМорроз
 
31 - 10.05.21 - 13:18
В windows именованные каналы часто поверх tcp работают,а tcp на одной машине может работать напрямую,т.к.драйвер это позволяет.
Основная же задержка на синхронизации потоков,т.к.читать с той стороны будет другой поток,и ему квант времени если и перенесут с текущего,то с переключением контекста.
   H A D G E H O G s
 
32 - 10.05.21 - 13:24
(31) Нет.
Я несколько лет назад специально тесты делал, именнованный канал в несколько раз быстрее работал, что по задержкам (множество мелких пакетов), что по скорости, чем tcp.
   fisher
 
33 - 11.05.21 - 09:51
(25) Журнал регистрации - это просто лог-файл. И никакой параллельности при записи в него нет. Все потоки пишут последовательно через соответствующий сервис кластера, как было сказано ниже.
А вот с пометкой транзакции в самом деле интересный момент. Система реально меняет отметку в ранее сделанных записях. И это несколько перпендикулярно типовой концепции логирования и влияет в том числе и на производительность. Был еще пост с проблемой, где это каким-то образом приводило к какому-то сайд-эффекту, но подробностей не помню, к сожалению. Откуда такой вывод, что "в случае с текстовым файлом нереально"?
   fisher
 
34 - 11.05.21 - 09:59
(25) + При использовании скулайта тоже нет никакой параллельности, если ты про это. Скулайт был введен исключительно для повышения скорости анализа разбухающих логов, которые на дефолтных настройках фигачат спам как недотехжурнал. То есть это был классический случай вбивания очередного костыля ведущего к новым проблемам для попытки решения другой искусственно созданной проблемы.


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