Сообщение Re[82]: The door от 26.07.2018 17:25
Изменено 26.07.2018 17:29 vdimas
Re[82]: The door
Здравствуйте, gandjustas, Вы писали:
G>В итоге получается что 1С умудряется дичайшее тормозить на совсем скромных объемах.
1С тормозит при активном использовании т.н. "временнЫх данных".
Современные СУБД не заточены под этот специальный вид данных, они хранятся просто как последовательность значений (просто строки в таблицах), например, изменений курсов валют на определённые даты.
Когда такие данные в логике не участвуют, то там быстродействие примерно как везде.
Но речь была именно о хинтах — что там выходит при прочих равных?
Так вот, без хинтов блокировок в запросе всё тормозит еще больше.
V>>Вопрос тут в другом — как продолжить раздавать данные по лёгким частым запросам (пусть единицы тысяч раз в сек) с одновременно выполняющимися тяжелыми нечастыми (пусть их будет десятки/сотни в сек). В твоих "типовых сценариях", т.е. без ручного тюнинга гранулярности блокировок — никак.
G>
G>У тебя просто потрясающе сочетание тотального профанизма и самомнения.
Судя по написанному ниже, всё с точностью до наоборот.
G>1) Запросы на чтение не мешают друг другу, так как используют исключительно shared блокировки. Если у тебя не так, то ты делаешь какую-то фигню.
Первый приплызд.
Откуда ты вообще взял про "запросы только по чтению", когда я во всём этом топике 100 раз повторял, что специфика по историческим данным (т.е. неизменяемым) и оперативным резко разная?
Итого, сходу начал с борьбы с воображаемым собеседником.
G>2) У тебя выставлены хреновые уровни изоляции.
Откуда ты знаешь какие уровни выставлены?
G>Для типичного приложения чаще всего подходит read commited snapshot в MS SQL.
Садись два.
Бо в этом случае речь о последовательности запросов в одной транзации и к обсуждаемому никаким боком.
Я вообще не сторонник что-то обновлять и затем что-то тяжеловесное запрашивать в рамках одной и той же транзакции, а ты, смотрю, сторонник подобных стрёмных вещей? ))
G>3) Если с уровнями изоляции все в порядке и запросы нормальные, а ты все равно испытываешь проблемы с блокировками, то у тебя что-то не так с индексами. Скорее всего нет подходящих индексов для запросов на обновление или наоборот каждое обновление требует обновления слишком большого количества индексов, что замедляет остальные запросы. Тут нужен баланс.
Единственно с чем соглашусь.
Тут камешек в огород Синклера, который уверяет, что большое кол-во индексов не вредит и предлагает их по 15 шт на таблицу.
Я предлагаю за такое расстреливать.
Но допустим, что схема данных и индексы минимально необходимые (у меня не более 3-4-х индексов для таблиц частообновляемыми данными и сами индексы только по числам и датам).
G>Но для начала надо смотреть на гранулдярность блокировок.
Конечно надо.
G>Слишком частые эскалации блокировок обычно свидетельствуют о хреновых индексах.
Вот тут ты и показал своё профанство, собсно. ))
G>4) Статистика. У тебя может быть включено автообновление статистики.
И я и про это IB и Синклеру говорил, они тоже, типа ржали.
Да, со статистикой надо быть осторожным.
G>Внезапно замедляет работу при крпных объемах.
Но не так сильно, как при столкновении блокировок, т.е. не так сильно сказывается на мгновенных задержках.
Статистика обновляется в фоне.
Хотя да, ресурсы проца жрет.
G>Переведи на ручное обновление по расписанию. Для больших таблиц статистика может быть не очень адекватна. Рецепт лечения тот же.
Для больших таблиц она еще может быть сильно дефрагментирована (т.е. сами индексы могуть сильно дефрагментированы), но это уже отдельная тема и всё-равно, оказывающая не столь катастрофическое влияние, т.е. не в десятки раз по быстродействию уж точно.
G>5) Слишком долго держишь открытый rowset.
С чего ты решил?
Я тут рядом упоминал 8 основных режимов открытия рекордсета и указал самый легковесный из них для случая сервака базы данных и для случая локальной inproc-базы.
G>Как не странно, но часто в прикладном коде встречается ошибка, что обработка результатов запроса делается в цикле, внутри которого происходят тяжелые операции. Люди наверное не думают, что пока rowset открыт база данных может удерживать блокировки.
Опять профанство.
Это зависит от режима открытия рекордсета.
Ты какие режимы сейчас имел ввиду?
К тому же, сразу для енскольких режимов описаное актуально только для относительно большой выборки, подготавливаемой для отправки на клиента.
Т.е. это явно не тот сценарий, бо адекватные разработчики не гонят на клиента тонну данных по результатам запроса.
G>Если ты сделал все правильно, то ручное управление блокировками тебе понадобится только в одном случае — увеличивать гранулярность блокировки для тяжелых запросов. И то в 1 случае из 1000.
Это всё еще детсад, не влияющий кардинально (на пару порядков) на ожидаемое быстродействие.
Всеми этими приседаниями (кроме приписанных мне неверных режимов открытия рекордсета) ты можешь изменить что-то в единицы раз, т.е. мимо.
За счёт более грамотной схемы данных, переформулирования запросов и разнесения данных (в том числе физического по дискам) можно получить порой намного больший выигрыш, но всё-равно будет еще "далеко не то".
V>>Если ты с этими известными сценариями не сталкивался, значит твой опыт с РСУБД весьма однобок.
G>Сталкивался побольше твоего и успешно решал. И даже заработал хороший гонорар за решение таких проблем
Ну, реил ты чей-то наколенный затык.
А более единиц сотен запросов в сек. (от силы единиц тысяч, если техника совсем суровая) даже после твоего "решения" там всё-равно не будет.
Это всё "обратная сторона Луны", как я называю подобный срез IT.
Ничего серьёзного с таким подходом не сделаешь.
V>>Думаю, что ты с серьёзной нагрузкой никогда не сталкивался.
V>>Это видно по твоим рассуждениям не только в ответах мне.
G>Конечно не сталкивался. То что ты считаешь "серьезной нагрузкой" для меня мелочи.
Ну так отзвучь кол-во транзакций в секунду и примерный объем данных?
G>В итоге получается что 1С умудряется дичайшее тормозить на совсем скромных объемах.
1С тормозит при активном использовании т.н. "временнЫх данных".
Современные СУБД не заточены под этот специальный вид данных, они хранятся просто как последовательность значений (просто строки в таблицах), например, изменений курсов валют на определённые даты.
Когда такие данные в логике не участвуют, то там быстродействие примерно как везде.
Но речь была именно о хинтах — что там выходит при прочих равных?
Так вот, без хинтов блокировок в запросе всё тормозит еще больше.
V>>Вопрос тут в другом — как продолжить раздавать данные по лёгким частым запросам (пусть единицы тысяч раз в сек) с одновременно выполняющимися тяжелыми нечастыми (пусть их будет десятки/сотни в сек). В твоих "типовых сценариях", т.е. без ручного тюнинга гранулярности блокировок — никак.
G>
G>У тебя просто потрясающе сочетание тотального профанизма и самомнения.
Судя по написанному ниже, всё с точностью до наоборот.
G>1) Запросы на чтение не мешают друг другу, так как используют исключительно shared блокировки. Если у тебя не так, то ты делаешь какую-то фигню.
Первый приплызд.
Откуда ты вообще взял про "запросы только по чтению", когда я во всём этом топике 100 раз повторял, что специфика по историческим данным (т.е. неизменяемым) и оперативным резко разная?
Итого, сходу начал с борьбы с воображаемым собеседником.
G>2) У тебя выставлены хреновые уровни изоляции.
Откуда ты знаешь какие уровни выставлены?
G>Для типичного приложения чаще всего подходит read commited snapshot в MS SQL.
Садись два.
Бо в этом случае речь о последовательности запросов в одной транзации и к обсуждаемому никаким боком.
Я вообще не сторонник что-то обновлять и затем что-то тяжеловесное запрашивать в рамках одной и той же транзакции, а ты, смотрю, сторонник подобных стрёмных вещей? ))
G>3) Если с уровнями изоляции все в порядке и запросы нормальные, а ты все равно испытываешь проблемы с блокировками, то у тебя что-то не так с индексами. Скорее всего нет подходящих индексов для запросов на обновление или наоборот каждое обновление требует обновления слишком большого количества индексов, что замедляет остальные запросы. Тут нужен баланс.
Единственно с чем соглашусь.
Тут камешек в огород Синклера, который уверяет, что большое кол-во индексов не вредит и предлагает их по 15 шт на таблицу.
Я предлагаю за такое расстреливать.
Но допустим, что схема данных и индексы минимально необходимые (у меня не более 3-4-х индексов для таблиц частообновляемыми данными и сами индексы только по числам и датам).
G>Но для начала надо смотреть на гранулдярность блокировок.
Конечно надо.
G>Слишком частые эскалации блокировок обычно свидетельствуют о хреновых индексах.
Вот тут ты и показал своё профанство, собсно. ))
G>4) Статистика. У тебя может быть включено автообновление статистики.
И я и про это IB и Синклеру говорил, они тоже, типа ржали.
Да, со статистикой надо быть осторожным.
G>Внезапно замедляет работу при крпных объемах.
Но не так сильно, как при столкновении блокировок, т.е. не так сильно сказывается на мгновенных задержках.
Статистика обновляется в фоне.
Хотя да, ресурсы проца жрет.
G>Переведи на ручное обновление по расписанию. Для больших таблиц статистика может быть не очень адекватна. Рецепт лечения тот же.
Для больших таблиц она еще может быть сильно дефрагментирована (т.е. сами индексы могуть сильно дефрагментированы), но это уже отдельная тема и всё-равно, оказывающая не столь катастрофическое влияние, т.е. не в десятки раз по быстродействию уж точно.
G>5) Слишком долго держишь открытый rowset.
С чего ты решил?
Я тут рядом упоминал 8 основных режимов открытия рекордсета и указал самый легковесный из них для случая сервака базы данных и для случая локальной inproc-базы.
G>Как не странно, но часто в прикладном коде встречается ошибка, что обработка результатов запроса делается в цикле, внутри которого происходят тяжелые операции. Люди наверное не думают, что пока rowset открыт база данных может удерживать блокировки.
Опять профанство.
Это зависит от режима открытия рекордсета.
Ты какие режимы сейчас имел ввиду?
К тому же, сразу для енскольких режимов описаное актуально только для относительно большой выборки, подготавливаемой для отправки на клиента.
Т.е. это явно не тот сценарий, бо адекватные разработчики не гонят на клиента тонну данных по результатам запроса.
G>Если ты сделал все правильно, то ручное управление блокировками тебе понадобится только в одном случае — увеличивать гранулярность блокировки для тяжелых запросов. И то в 1 случае из 1000.
Это всё еще детсад, не влияющий кардинально (на пару порядков) на ожидаемое быстродействие.
Всеми этими приседаниями (кроме приписанных мне неверных режимов открытия рекордсета) ты можешь изменить что-то в единицы раз, т.е. мимо.
За счёт более грамотной схемы данных, переформулирования запросов и разнесения данных (в том числе физического по дискам) можно получить порой намного больший выигрыш, но всё-равно будет еще "далеко не то".
V>>Если ты с этими известными сценариями не сталкивался, значит твой опыт с РСУБД весьма однобок.
G>Сталкивался побольше твоего и успешно решал. И даже заработал хороший гонорар за решение таких проблем
Ну, реил ты чей-то наколенный затык.
А более единиц сотен запросов в сек. (от силы единиц тысяч, если техника совсем суровая) даже после твоего "решения" там всё-равно не будет.
Это всё "обратная сторона Луны", как я называю подобный срез IT.
Ничего серьёзного с таким подходом не сделаешь.
V>>Думаю, что ты с серьёзной нагрузкой никогда не сталкивался.
V>>Это видно по твоим рассуждениям не только в ответах мне.
G>Конечно не сталкивался. То что ты считаешь "серьезной нагрузкой" для меня мелочи.
Ну так отзвучь кол-во транзакций в секунду и примерный объем данных?
Re[82]: The door
Здравствуйте, gandjustas, Вы писали:
G>В итоге получается что 1С умудряется дичайшее тормозить на совсем скромных объемах.
1С тормозит при активном использовании т.н. "временнЫх данных".
Современные СУБД не заточены под этот специальный вид данных, они хранятся просто как последовательность значений (просто строки в таблицах), например, изменений курсов валют на определённые даты.
Когда такие данные в логике не участвуют, то там быстродействие примерно как везде.
Но речь была именно о хинтах — что там выходит при прочих равных?
Так вот, без хинтов блокировок в запросе всё тормозит еще больше.
V>>Вопрос тут в другом — как продолжить раздавать данные по лёгким частым запросам (пусть единицы тысяч раз в сек) с одновременно выполняющимися тяжелыми нечастыми (пусть их будет десятки/сотни в сек). В твоих "типовых сценариях", т.е. без ручного тюнинга гранулярности блокировок — никак.
G>
G>У тебя просто потрясающе сочетание тотального профанизма и самомнения.
Судя по написанному ниже, всё с точностью до наоборот.
G>1) Запросы на чтение не мешают друг другу, так как используют исключительно shared блокировки. Если у тебя не так, то ты делаешь какую-то фигню.
Первый приплызд.
Откуда ты вообще взял про "запросы только по чтению", когда я во всём этом топике 100 раз повторял, что специфика по историческим данным (т.е. неизменяемым) и оперативным резко разная?
Итого, сходу начал с борьбы с воображаемым собеседником.
G>2) У тебя выставлены хреновые уровни изоляции.
Откуда ты знаешь какие уровни выставлены?
G>Для типичного приложения чаще всего подходит read commited snapshot в MS SQL.
Садись два.
Бо в этом случае речь о последовательности запросов в одной транзации и к обсуждаемому никаким боком.
Я вообще не сторонник что-то обновлять и затем что-то тяжеловесное запрашивать в рамках одной и той же транзакции, а ты, смотрю, сторонник подобных стрёмных вещей? ))
G>3) Если с уровнями изоляции все в порядке и запросы нормальные, а ты все равно испытываешь проблемы с блокировками, то у тебя что-то не так с индексами. Скорее всего нет подходящих индексов для запросов на обновление или наоборот каждое обновление требует обновления слишком большого количества индексов, что замедляет остальные запросы. Тут нужен баланс.
Единственно с чем соглашусь.
Тут камешек в огород Синклера, который уверяет, что большое кол-во индексов не вредит и предлагает их по 15 шт на таблицу.
Я предлагаю за такое расстреливать.
Но допустим, что схема данных и индексы минимально необходимые (у меня не более 3-4-х индексов для таблиц частообновляемыми данными и сами индексы только по числам и датам).
G>Но для начала надо смотреть на гранулдярность блокировок.
Конечно надо.
G>Слишком частые эскалации блокировок обычно свидетельствуют о хреновых индексах.
Вот тут ты и показал своё профанство, собсно. ))
G>4) Статистика. У тебя может быть включено автообновление статистики.
И я и про это IB и Синклеру говорил, они тоже, типа ржали.
Да, со статистикой надо быть осторожным.
G>Внезапно замедляет работу при крпных объемах.
Но не так сильно, как при столкновении блокировок, т.е. не так сильно сказывается на мгновенных задержках.
Статистика обновляется в фоне.
Хотя да, ресурсы проца жрет.
G>Переведи на ручное обновление по расписанию. Для больших таблиц статистика может быть не очень адекватна. Рецепт лечения тот же.
Для больших таблиц она еще может быть сильно дефрагментирована (т.е. сами индексы могуть сильно дефрагментированы), но это уже отдельная тема и всё-равно, оказывающая не столь катастрофическое влияние, т.е. не в десятки раз по быстродействию уж точно.
G>5) Слишком долго держишь открытый rowset.
С чего ты решил?
Я тут рядом упоминал 8 основных режимов открытия рекордсета и указал самый легковесный из них для случая сервака базы данных и для случая локальной inproc-базы.
G>Как не странно, но часто в прикладном коде встречается ошибка, что обработка результатов запроса делается в цикле, внутри которого происходят тяжелые операции. Люди наверное не думают, что пока rowset открыт база данных может удерживать блокировки.
Опять профанство.
Это зависит от режима открытия рекордсета.
Ты какие режимы сейчас имел ввиду?
К тому же, сразу для енскольких режимов описаное актуально только для относительно большой выборки, подготавливаемой для отправки на клиента.
Т.е. это явно не тот сценарий, бо адекватные разработчики не гонят на клиента тонну данных по результатам запроса.
G>Если ты сделал все правильно, то ручное управление блокировками тебе понадобится только в одном случае — увеличивать гранулярность блокировки для тяжелых запросов. И то в 1 случае из 1000.
Это всё еще детсад, не влияющий кардинально (на пару порядков) на ожидаемое быстродействие.
Всеми этими приседаниями (кроме приписанных мне неверных режимов открытия рекордсета) ты можешь изменить что-то в единицы раз, т.е. мимо.
За счёт более грамотной схемы данных, переформулирования запросов и разнесения данных (в том числе физического по дискам) можно получить порой намного больший выигрыш, но всё-равно будет еще "далеко не то".
V>>Если ты с этими известными сценариями не сталкивался, значит твой опыт с РСУБД весьма однобок.
G>Сталкивался побольше твоего и успешно решал. И даже заработал хороший гонорар за решение таких проблем
Ну, решил ты чей-то наколенный затык.
А более единиц сотен запросов в сек. (от силы единиц тысяч, если техника совсем суровая) даже после твоего "решения" там всё-равно не будет.
Это всё "обратная сторона Луны", как я называю подобный срез IT.
Ничего серьёзного с таким подходом не сделаешь.
V>>Думаю, что ты с серьёзной нагрузкой никогда не сталкивался.
V>>Это видно по твоим рассуждениям не только в ответах мне.
G>Конечно не сталкивался. То что ты считаешь "серьезной нагрузкой" для меня мелочи.
Ну так отзвучь кол-во транзакций в секунду и примерный объем данных?
G>В итоге получается что 1С умудряется дичайшее тормозить на совсем скромных объемах.
1С тормозит при активном использовании т.н. "временнЫх данных".
Современные СУБД не заточены под этот специальный вид данных, они хранятся просто как последовательность значений (просто строки в таблицах), например, изменений курсов валют на определённые даты.
Когда такие данные в логике не участвуют, то там быстродействие примерно как везде.
Но речь была именно о хинтах — что там выходит при прочих равных?
Так вот, без хинтов блокировок в запросе всё тормозит еще больше.
V>>Вопрос тут в другом — как продолжить раздавать данные по лёгким частым запросам (пусть единицы тысяч раз в сек) с одновременно выполняющимися тяжелыми нечастыми (пусть их будет десятки/сотни в сек). В твоих "типовых сценариях", т.е. без ручного тюнинга гранулярности блокировок — никак.
G>
G>У тебя просто потрясающе сочетание тотального профанизма и самомнения.
Судя по написанному ниже, всё с точностью до наоборот.
G>1) Запросы на чтение не мешают друг другу, так как используют исключительно shared блокировки. Если у тебя не так, то ты делаешь какую-то фигню.
Первый приплызд.
Откуда ты вообще взял про "запросы только по чтению", когда я во всём этом топике 100 раз повторял, что специфика по историческим данным (т.е. неизменяемым) и оперативным резко разная?
Итого, сходу начал с борьбы с воображаемым собеседником.
G>2) У тебя выставлены хреновые уровни изоляции.
Откуда ты знаешь какие уровни выставлены?
G>Для типичного приложения чаще всего подходит read commited snapshot в MS SQL.
Садись два.
Бо в этом случае речь о последовательности запросов в одной транзации и к обсуждаемому никаким боком.
Я вообще не сторонник что-то обновлять и затем что-то тяжеловесное запрашивать в рамках одной и той же транзакции, а ты, смотрю, сторонник подобных стрёмных вещей? ))
G>3) Если с уровнями изоляции все в порядке и запросы нормальные, а ты все равно испытываешь проблемы с блокировками, то у тебя что-то не так с индексами. Скорее всего нет подходящих индексов для запросов на обновление или наоборот каждое обновление требует обновления слишком большого количества индексов, что замедляет остальные запросы. Тут нужен баланс.
Единственно с чем соглашусь.
Тут камешек в огород Синклера, который уверяет, что большое кол-во индексов не вредит и предлагает их по 15 шт на таблицу.
Я предлагаю за такое расстреливать.
Но допустим, что схема данных и индексы минимально необходимые (у меня не более 3-4-х индексов для таблиц частообновляемыми данными и сами индексы только по числам и датам).
G>Но для начала надо смотреть на гранулдярность блокировок.
Конечно надо.
G>Слишком частые эскалации блокировок обычно свидетельствуют о хреновых индексах.
Вот тут ты и показал своё профанство, собсно. ))
G>4) Статистика. У тебя может быть включено автообновление статистики.
И я и про это IB и Синклеру говорил, они тоже, типа ржали.
Да, со статистикой надо быть осторожным.
G>Внезапно замедляет работу при крпных объемах.
Но не так сильно, как при столкновении блокировок, т.е. не так сильно сказывается на мгновенных задержках.
Статистика обновляется в фоне.
Хотя да, ресурсы проца жрет.
G>Переведи на ручное обновление по расписанию. Для больших таблиц статистика может быть не очень адекватна. Рецепт лечения тот же.
Для больших таблиц она еще может быть сильно дефрагментирована (т.е. сами индексы могуть сильно дефрагментированы), но это уже отдельная тема и всё-равно, оказывающая не столь катастрофическое влияние, т.е. не в десятки раз по быстродействию уж точно.
G>5) Слишком долго держишь открытый rowset.
С чего ты решил?
Я тут рядом упоминал 8 основных режимов открытия рекордсета и указал самый легковесный из них для случая сервака базы данных и для случая локальной inproc-базы.
G>Как не странно, но часто в прикладном коде встречается ошибка, что обработка результатов запроса делается в цикле, внутри которого происходят тяжелые операции. Люди наверное не думают, что пока rowset открыт база данных может удерживать блокировки.
Опять профанство.
Это зависит от режима открытия рекордсета.
Ты какие режимы сейчас имел ввиду?
К тому же, сразу для енскольких режимов описаное актуально только для относительно большой выборки, подготавливаемой для отправки на клиента.
Т.е. это явно не тот сценарий, бо адекватные разработчики не гонят на клиента тонну данных по результатам запроса.
G>Если ты сделал все правильно, то ручное управление блокировками тебе понадобится только в одном случае — увеличивать гранулярность блокировки для тяжелых запросов. И то в 1 случае из 1000.
Это всё еще детсад, не влияющий кардинально (на пару порядков) на ожидаемое быстродействие.
Всеми этими приседаниями (кроме приписанных мне неверных режимов открытия рекордсета) ты можешь изменить что-то в единицы раз, т.е. мимо.
За счёт более грамотной схемы данных, переформулирования запросов и разнесения данных (в том числе физического по дискам) можно получить порой намного больший выигрыш, но всё-равно будет еще "далеко не то".
V>>Если ты с этими известными сценариями не сталкивался, значит твой опыт с РСУБД весьма однобок.
G>Сталкивался побольше твоего и успешно решал. И даже заработал хороший гонорар за решение таких проблем
Ну, решил ты чей-то наколенный затык.
А более единиц сотен запросов в сек. (от силы единиц тысяч, если техника совсем суровая) даже после твоего "решения" там всё-равно не будет.
Это всё "обратная сторона Луны", как я называю подобный срез IT.
Ничего серьёзного с таким подходом не сделаешь.
V>>Думаю, что ты с серьёзной нагрузкой никогда не сталкивался.
V>>Это видно по твоим рассуждениям не только в ответах мне.
G>Конечно не сталкивался. То что ты считаешь "серьезной нагрузкой" для меня мелочи.
Ну так отзвучь кол-во транзакций в секунду и примерный объем данных?