IgorPes писал(а): ↑Пн ноя 11, 2019 8:25 pm
Снова про тормоза нынешней 1С, почему не спасают ни современные процы причём работает под 5гГц, диск SSD чтение что то в районе 3 гигабайт в секунду, память так же больше 3 гГб/сек, но сука тормозит она по сравнению с предыдущими версиями (бух2.0) просто безбожно, памяти оперативной при этом отжирает в 3-5 раз больше предыдущей версии, это кропотливая работа 1С в поддержку нового железа- соответственно нового софта микрософт или это как то всё же лечится, вчера попытка добиться ответа от гугла не увенчалась успехом... Какого хрена открытие пары документов в 1с сложности эксель начинает отжирать в памяти по 200-300 мегабайт дополнительно, онииблядь, издеваются?
Дык счётчики производительности смотри - где именно затуп. Я уже выше описывал, как из-за лога тормоза возникали
Или журнал подключай и смотри на запрос - что долго выполняется.
А по поводу - 200-300 мегабайт. Этож хорошо и збс - что он всё кэширует. А не читает на каждый чих со сторейджа. Память благо щас дешевая.
arxont писал(а): ↑Вс сен 09, 2018 12:42 am
Есть "неочевидный" косяк с 1Ской:
тормозит. Начали разбираться: скульная база + сервак. По гигагерцам всё ровно, и база, и лог-файл скуля на SSD, tempdb тоже на ссд. Но при некоторых действиях начинаются дикие тормоза:
Оказалось, что был включен "Журнал регистрации", причём на полное логирование. А оно по умолчанию пишется на системный диск, в папку C:\Program Files\1cv8\srvinfo\<Имя кластера сервера>\<Идентификатор базы на сервере>\1Cv8Log, что и создавало тормоза, ибо системный диск был отдельным 320 гигабитным обычным 3.5 (ещё и 5400 и мэдленный).
Причём логирование в журнале было настроенно хитро и с условиями (прогаммер когда-то что-то отлаживал и забыл убрать) и поиск занял время.
Методика поиска - смотрим по монитору производительности какой процесс грузит и что грузит. Затем процмоном смотрим какие файлы читает-пишет.
ЗЫ: Вот если бы эту херню сразу знал и сделал, то бухал бы с вами спокойно, а не пил чай час, а потом обратно работать
arxont писал(а): ↑Пн ноя 11, 2019 9:05 pm
Вот, Игорь, я про это писал
Я понимаю когда винт винт тормозной, но система и базы крутятся на одном разбитом nvme винте с бешеными скоростями. Хорошо, допустим логирование так много времени отнимает, где и как его отключить или настроить?
Вроде нашёл, какие рекомендации с твоей точки зрения по его настройке? что оставить, что отключить?
IgorPes писал(а): ↑Пн ноя 11, 2019 9:55 pm
Я понимаю когда винт винт тормозной, но система и базы крутятся на одном разбитом nvme винте с бешеными скоростями. Хорошо, допустим логирование так много времени отнимает, где и как его отключить или настроить?
Вроде нашёл, какие рекомендации с твоей точки зрения по его настройке? что оставить, что отключить?
Вопрос не в логировании - оно тормозить будет только если там на каждую строчку логируется. И каждое изменение.
Это достаточно редкий и частный кейс - к которому у тебя может совершенно не быть отношения. (Ибо в моём случае это вполне конкретные кривые ручки программиста были причастны)
Вопрос в том, что надо определять ЧТО именно тормозит - и уже предметно разбираться с этим: почему тормозит, кто виноват и что делать. А так это "слепой с глухим ёбется". А тормозить может ОЧЕНЬ много чего - и проц, и диск, и память, и сеть, и сам код (особенно если конфа не стандартная).
Поэтому само по себе отключение лога может ничего не дать - я это к тому, что надо всё смотреть и мониторить. И искать конкретное "бутылочное горлышко". И устранять уже его.
Конфиги стандартные, просто одна и та же проблема на разных конфигах и разных серверах, обычные SSD 500-550 мБайт/сек чтение совсем печалька-печальная, nvme - немного но спасает, но даже когда скорость почти всего(память, диск, ну проц в 2 раза быстрее - ладно) в 5 раз выше, ускорения работы программы едва заметно. Обновление баз тоже стало протекать как черепаха на льду.
В целом мысль понятна, попробую разобраться.