|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
tanyxaВлияет ли это как-то на работу базы? это разве что влияет на время первого обращения к mon$-таблицам. Для примера - торговая система. 96 коннектов, 86 активных транзакций, 3884 запроса, по 40 запросов на коннект. У ~95% запросов transaction_id = 0. время первого обращения к mon$ - 8 секунд. - торговая система. 112 коннектов, 46 активных транзакций, 7692 запроса, по 68 на коннект. в момент получения информации от mon$ только 5 запросов из этих 7.5 тысяч имели transaction_id <> 0. время первого обращения к mon$ - 40 секунд. Вероятно, что тут вполне может быть какая-то утечка хэндлов на клиентах, потому что количество вот таких непривязанных statements со временем растет, в то время как количество коннектов почти постоянно, а количество транзакций плавает. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2015, 00:45 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
похоже мнения разделились и я теперь в некоторой растерянности))) По правде сказать, я никогда не заморачивалась с освобождением запросов, так как была уверена что это происходит автоматически. Когда узнала что это не так, то снова не очень обеспокоилась - какой вред может быть от сотни сохраненных запросов... Но как то хочется определиться это нормальная картина, или все-таки лучше делать явное освобождение ? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2015, 07:04 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
tanyxaили все-таки лучше делать явное освобождение ? Хотя сейчас не вижу в этом особого смысла. Вот пользователь работает с каким-то окном, в зависимости от его действий могут выполняться разные инструкции до тех пор пока он не посчитает работу законченой и не сохранит документ. Тогда действительно - все подготовленные запросы можно считать уже ненужными и делать Uprepare. Но сразу после этого окно переходит в состояние готовности ко вводу следующего документа и следовательно теже инструкции опять подготавливаются. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2015, 11:05 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
tanyxahvladtanyxaочень ли плохо если этих запросов много кэшируется? Они жрут память.Я думала что если сам запрос уже выполнен, значит клиент уже получил запрошенные данные и это не более чем сохраненный текст в метаданныхРечь выше шла про много. Есть клинические случаи, когда из-за не освобождённых запросов сервер выходил за лимит в 2GB вирт. памяти. Достаточный аргумент ? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2015, 14:34 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
tanyxatanyxaили все-таки лучше делать явное освобождение ? Хотя сейчас не вижу в этом особого смысла. Вот пользователь работает с каким-то окном, в зависимости от его действий могут выполняться разные инструкции до тех пор пока он не посчитает работу законченой и не сохранит документ. Тогда действительно - все подготовленные запросы можно считать уже ненужными и делать Uprepare. Но сразу после этого окно переходит в состояние готовности ко вводу следующего документа и следовательно теже инструкции опять подготавливаются.Не бывает универсальных рецептов на все случаи жизни. Ищи компромисс, устраивающий конкретно тебя в конкретном случае. У тебя два противоречивых варианта действий: а) освобождать запросы плюсы: сервер жрёт меньше памяти, мониторинг меньше тормозит минусы: новые запросы будут заново создаваться и препарироваться, на это нужно время б) не освобождать запросы плюсы: форма быстрее готова к работе минусы: сервер жрёт больше памяти, мониторинг тормозит сильнее Твоё собственное решение зависит от: - насколько больше\меньше жрётся памяти - насколько дольше\быстрее готовится форма к показу - насколько [не]тормозит мониторинг и нужен ли он тебе вообще ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2015, 14:40 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
hvlad Есть клинические случаи, когда из-за не освобождённых запросов сервер выходил за лимит в 2GB вирт. памяти. Достаточный аргумент ? Вполне. hvlad У тебя два противоречивых варианта действий: да я тоже пришла к таким выводам. Скорость мониторинга для меня не критична. Хочется соблюсти золотую середину между вариантом а) и б). ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2015, 15:21 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
Hello, Tanyxa! You wrote on 28 июля 2015 г. 15:25:05: Tanyxa> Хочется соблюсти золотую середину между вариантом а) и б). если пациент не болен, не лечи его. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2015, 15:24 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
Мимопроходящий, я хочу понять как контролировать что пациент нуждается или не нуждается в лечении. Какие параметры должны меня насторожить? В данный момент все нормально, запросы выполняются быстро, сервер расходует около 400 МБ памяти, активно около 40 соединений. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2015, 15:52 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
Hello, Tanyxa! You wrote on 28 июля 2015 г. 16:04:44: Tanyxa> В данный момент все нормальнону и не парься. если проект имеет устойчивую тенденцию неконтролируемого роста, тогда имеет смысл озадачиться прогнозированием гипотетической нагрузки. а так, нет. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2015, 16:07 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
У нас ожидается постоянный рост количества проектов, поэтому и беспокоюсь ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2015, 16:09 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
tanyxaУ нас ожидается постоянный рост количества проектов, поэтому и беспокоюсь я бы сказал, что пациент постоянно нуждается в лечении. Например. Решает контора разработать свою ERP. Делает, внедряет для контор с 30-50 пользователей, все прекрасно. Потом появляется или толстый клиент, или клиент, у которого высокая скорость роста. И на 100-150 пользователях система начинает загибаться. Потому что там транзакциями не так управляют, тут за хэндлами запросов не следят, процедуры и триггеры пишут абы как - все ведь расчитывалось на 20-30 коннектов, и работало прекрасно. Ну а дальше получается вот что - такой толстый клиент один, и допиливать систему под него некогда, потому что много других мелких клиентов ждут. Поэтому толстый клиент посылается на, а говноподелие (уж извините) распространяется все более массовыми тиражами. p.s. и тут (на sql.ru) разработчиков таких систем мы НИКОГДА не видим, имею смелость это утверждать, имея массу реальных примеров. И у нас в саппорте практически никогда не видим. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2015, 19:39 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
kdvp.s. и тут (на sql.ru) разработчиков таких систем мы НИКОГДА не видим, имею смелость это утверждать, имея массу реальных примеров. И у нас в саппорте практически никогда не видим. Значит таникса - первый представитель своего вида, который таки появился здесь. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2015, 19:42 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovЗначит таникса - первый представитель своего вида, который таки появился здесь. Вы, димитри сибириаков, возможно не правы. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2015, 19:55 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
kdvp.s. и тут (на sql.ru) разработчиков таких систем мы НИКОГДА не видим, имею смелость это утверждать, имея массу реальных примеров. И у нас в саппорте практически никогда не видим. Вы очень похоже описали ситуацию, с тем лишь отличием что мы пишем не ERP а постепенно мигрируя с файл-серверной СУБД пишем условно-отдельные проекты - когда обслуживается одно предприятие, база одна а проекты охватывают некоторые бизнес-процессы наиболее нуждающиеся в автоматизации. Dimitry SibiryakovЗначит таникса - первый представитель своего вида, который таки появился здесь. Я думала таких ситуаций предостаточно, особенно на крупных гос. объектах ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2015, 19:57 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
tanyxa, ничего себе вы задержались... Мы свою систему на SQL переписали уж лет 12 назад. И до сих пор совершенству нет предела :) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2015, 08:30 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
o_v_a, Чем крупнее предприятие, тем оно инертнее имхо :) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2015, 09:04 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
удивительно, что "эффективные менеджеры" не предложили сразу купить SAP. настало время обновить менеджмент. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2015, 11:13 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
Мимопроходящий, SAP нас уже третий год обхаживает ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2015, 11:28 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
Hello, Tanyxa! You wrote on 29 июля 2015 г. 11:43:36: Tanyxa> SAP нас уже третий год обхаживаети всё никак? очень жадные менеджеры попались. но отчаиваться не стоит - бабло в конце концов победит добро. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2015, 11:44 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
И все никак. Мы уже сами не понимаем будет толк из этих переговоров или нет, поэтому тем временем понемножку мигрируем самостоятельно ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2015, 11:50 |
|
Вопрос по prepared запросам
|
|||
---|---|---|---|
#18+
Hello, Tanyxa! You wrote on 29 июля 2015 г. 11:54:51: Tanyxa> И все никак. Мы уже сами не понимаем будет толк из этих переговоров или нет как только сойдутся в сумме отката, так сразу и. то, что переговоры ведутся так долго, ещё раз подтверждает древний постулат: "у каждой шлюхи есть свои ПРИНЦИПЫ" (речь о менеджменте, естественно) Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2015, 11:57 |
|
|
start [/forum/topic.php?fid=40&msg=39017800&tid=1562695]: |
0ms |
get settings: |
12ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
27ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
others: | 266ms |
total: | 404ms |
0 / 0 |