|
|
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
MasterZivСпасибо конечно, но Вы написали это просто чтобы написать !? Я тут болею немного, так что извините. Вам и без меня думаю хорошо помогли. В том и вся трабла что объект ЕСТЕСТВЕннО прибинден к кэшу (что видно в примере запроса положенному выше). Существует ли какая нибудь политика использования кэша, если при наличии именнованого кэша данные из объекта все равно попадают в default data cache. Может быть на каких то запросах.. .я не знаю... Нет, нет, никогда такого быть не должно, если все правильно сконфигурено. Может вам стоит перегрузить сервер ? я точно не помню, но кажется надо сервер перегружать чтобы объект перешел из одного кэша в другой. СУБД перезагружали неоднократно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2008, 12:41 |
|
||
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
А что тут комментировать... Использование именнованных кешей в вашем случае вообще нецелесообразно... Так как ранее было замеченно, вы можете полжить всю свою БД в default cache с несколькими партишенами в нем. А также еще сделать кеш для лога и tempdb В данный момент, именнованные кеши используются максимум в 2% случае обращений. "Так называемые" большие пулы в них вообще никогда не используются.. "Так называемые", потому что если хотите делать большие пулы, то делайте их максимального размера, т.е. 8 логич. страниц а не 4 лог.страницы как сейчас. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2008, 13:38 |
|
||
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
morisА что тут комментировать... Использование именнованных кешей в вашем случае вообще нецелесообразно... Так как ранее было замеченно, вы можете полжить всю свою БД в default cache с несколькими партишенами в нем. А также еще сделать кеш для лога и tempdb В данный момент, именнованные кеши используются максимум в 2% случае обращений. "Так называемые" большие пулы в них вообще никогда не используются.. "Так называемые", потому что если хотите делать большие пулы, то делайте их максимального размера, т.е. 8 логич. страниц а не 4 лог.страницы как сейчас. Спасибо за ответ. скажите у нас база растет почти 2гб в месяц. то скоро она будет намного больше чем размер оперативки. Как нужно действовать чтобы всетаки физ.чтения были минимальные? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2008, 13:57 |
|
||
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
merphy9 Спасибо за ответ. скажите у нас база растет почти 2гб в месяц. то скоро она будет намного больше чем размер оперативки. Как нужно действовать чтобы всетаки физ.чтения были минимальные? покупать по 2 гига оперативки в месяц :) как живут системы у которых базы в сотни гиг ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2008, 16:46 |
|
||
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
0rc merphy9 Спасибо за ответ. скажите у нас база растет почти 2гб в месяц. то скоро она будет намного больше чем размер оперативки. Как нужно действовать чтобы всетаки физ.чтения были минимальные? покупать по 2 гига оперативки в месяц :) как живут системы у которых базы в сотни гиг ? Так я и спрашиваю совета как можно еще подкрутить сервер для уменьшения количества физ.чтений! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2008, 16:58 |
|
||
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
автор"Так я и спрашиваю совета как можно еще подкрутить сервер для уменьшения количества физ.чтений!" Ув. merphy9 без обид, но Вам не кажеться, что вы задаете вопросы по сути ни о чем? О какой проблеме с излишним физическим чтением вы говорите?? По присланным сисмонам у вас 100% попадание и это даже при таком неграмотном разбиение на кеши. Учитывая тот факт, что ваша БД вся в кеши может находиться вообще, в ближайшее время, о каком проблеме с физическим чтением все-таки говориться?? На каком основании ваше начальство вообще сделало такой вывод, что проблема с излишним физическим чтением имеет место??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2008, 17:23 |
|
||
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
moris автор"Так я и спрашиваю совета как можно еще подкрутить сервер для уменьшения количества физ.чтений!" Ув. merphy9 без обид, но Вам не кажеться, что вы задаете вопросы по сути ни о чем? О какой проблеме с излишним физическим чтением вы говорите?? По присланным сисмонам у вас 100% попадание и это даже при таком неграмотном разбиение на кеши. Учитывая тот факт, что ваша БД вся в кеши может находиться вообще, в ближайшее время, о каком проблеме с физическим чтением все-таки говориться?? На каком основании ваше начальство вообще сделало такой вывод, что проблема с излишним физическим чтением имеет место??? Спасибо что подтвердили наше мнение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2008, 17:34 |
|
||
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
Посоветуйте пожалуйста как грамотно сделать именованные кеши? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2008, 17:41 |
|
||
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
morisО какой проблеме с излишним физическим чтением вы говорите?? По присланным сисмонам у вас 100% попадание и это даже при таком неграмотном разбиение на кеши. Учитывая тот факт, что ваша БД вся в кеши может находиться вообще, в ближайшее время, о каком проблеме с физическим чтением все-таки говориться?? На каком основании ваше начальство вообще сделало такой вывод, что проблема с излишним физическим чтением имеет место??? Вот это уже интереснее! Уважаемый Moris, интересно Ваше мнение - существует ли какая нибудь пропорция размер БД, размер физической памяти сервера, размеры кэшей, количество пользователей и характер их запросов!? По поводу истоков проблемы: перед группой системных администраторов поставлена задача исследования и минимизации времени обработки транзакций, посредством тонкого тюнинга самого железного сервера, сервера БД, и прочего... Одной из причин замедления времени обработки транзакции считаются физические обращения к дисковому массиву (не смотря на быстрые винты, разкладывание "тел" БД и лога на разные партитиции и прочее... ;-) ...). Вот мы и озадачились данной проблемой. Лично я заинтересован не в разборках с начальством, а с полным пониманием работы конкретной БД с конкретным железом и с конкретной логикой клиенских приложений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2008, 18:36 |
|
||
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
biplane пишет: > Уважаемый Moris, интересно Ваше мнение - существует ли какая нибудь > пропорция размер БД, размер физической памяти сервера, размеры кэшей, > количество пользователей и характер их запросов!? не существует никаких волшебных пропорций, все зависит от конкретной БД и приложения. А вам совет - уберите все именованные кэши, отдайте все в дефолтный, Разве что для tempdb отдельный кэш (и для ее лога) небольшой оставте. Напр. на пол -tempdb. И - мониторьте, мониторьте. И сматрите, что тормозит. > По поводу истоков проблемы: перед группой системных администраторов > поставлена задача исследования и минимизации времени обработки > транзакций, посредством тонкого тюнинга самого железного сервера, > сервера БД, и прочего... Ага, но у них не хватает опыта и они крутят за все рычажки, что видят Одной из причин замедления времени обработки > транзакции считаются физические обращения к дисковому массиву (не смотря > на быстрые винты, разкладывание "тел" БД и лога на разные партитиции и > прочее... ;-) ...). С какого вы это решили-то ? Мониторинги делали ? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2008, 19:03 |
|
||
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
MasterZivне существует никаких волшебных пропорций, все зависит от конкретной БД и приложения. А вам совет - уберите все именованные кэши, отдайте все в дефолтный, Разве что для tempdb отдельный кэш (и для ее лога) небольшой оставте. Напр. на пол -tempdb. И - мониторьте, мониторьте. И сматрите, что тормозит. Спасибо за совет. Встречный вопрос: по каким параметрам Вы оцениваете свою платформу !? Еще практический вопрос - какие основные параметры влияют на быстродействие обработки транзакций в БД !? Одним из решений было создание именнованых кэшей... что еще !?))) MasterZivАга, но у них не хватает опыта и они крутят за все рычажки, что видят Согласитесь некорректное высказывание. И я же писал выше, что просто "выкручиванием" всех параметров не хотелось админить, а хочется четко понимать как и что работает и параллельно интересно мнение коллег. Улавливаете разницу !? ;-) MasterZivС какого вы это решили-то ? Мониторинги делали ? Ну естественно мониторили, тестили и мониторили. И если четко в логе написано что физических чтений при обработке запроса столько-то, да умножить это все на количество транзакций.... Я не говорю что необходимо "высадить" все БД в память, но по возможности минимизации физических чтений при работе конкретного приложения и конкретной БД. Во, блин я в полемику полез !!! ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2008, 19:24 |
|
||
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
biplane Во, блин я в полемику полез !!! это не полемика а чистое упрямство - прочитать в документации что-то и упорно настаивать минимум трое участников вам предложили свести к минимуму количество именованных кешей, а вы все равно зациклились на этом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2008, 20:06 |
|
||
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
morisА что тут комментировать... Использование именнованных кешей в вашем случае вообще нецелесообразно... Так как ранее было замеченно, вы можете полжить всю свою БД в default cache с несколькими партишенами в нем. А также еще сделать кеш для лога и tempdb В данный момент, именнованные кеши используются максимум в 2% случае обращений. "Так называемые" большие пулы в них вообще никогда не используются.. "Так называемые", потому что если хотите делать большие пулы, то делайте их максимального размера, т.е. 8 логич. страниц а не 4 лог.страницы как сейчас. +1! 2 biplane: делать выводы по одному сисмону конечно не очень корректно, но полагаю картина не сильно изменится и при дальнейшем мониторинге имхо, оставить default cache & tempdb cache, всё остальное убрать база у вас почти равна кэшу - ситуация идеальная ;) более того, подозреваю, что реально данных у вас меньше, чем размер БД ;) что говорит Код: plaintext кстати, почему руководство уверено что проблема именно в физических чтениях? как проверяли? что у вас с дисковой подсистемой? biplaneПо поводу истоков проблемы: перед группой системных администраторов поставлена задача исследования и минимизации времени обработки транзакций, посредством тонкого тюнинга самого железного сервера, сервера БД, и прочего... что за транзакции? если имеется ввиду OLTP, то для ускорения записи в таблицы надо убрать индексы, триггеры - тогда скорость записи будет максимальна. Как только добавляется логика, скорость вставки снижается. Кстати, а вы не рассматривали такой вариант, как добавление отчетного сервера и настройки репликации на него с боевого сервера? Возможно у вас на одном сервере конкурируют OLTP & DSS активности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2008, 09:14 |
|
||
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
biplane пишет: > Спасибо за совет. Встречный вопрос: по каким параметрам Вы оцениваете > свою платформу !? Это как ? Не понял. > Еще практический вопрос - какие основные параметры влияют на > быстродействие обработки транзакций в БД !? Одним из решений было > создание именнованых кэшей... что еще !?))) Да много чего. Вы хотите чтобы мы вам так вот удаленно и забесплатно оттюнили ваше приложение и БД ? Не получится, это - достаточно серьезная работа, и ее надо заниматься, а не так чтобы плюнул-дунул, и за вас это никто не сделает. (есть правда вариант нанять консультанта, например в том же нашем Sybase CIS). > "выкручиванием" всех параметров не хотелось админить, а хочется четко > понимать как и что работает и параллельно интересно мнение коллег. Так читайте, читайте документацию P&T, изучайте. > Ну естественно мониторили, тестили и мониторили. И если четко в логе > написано что физических чтений при обработке запроса столько-то, да > умножить это все на количество транзакций.... В каком логе ? Короче, я нифига не понимаю из того, что вы тут пишите. Думаю, что другие не понимаю тоже. Вы задавайте конкретные вопросы, будут конкретные ответы. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2008, 09:33 |
|
||
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
...быстрые винты, разкладывание "тел" БД и лога на разные партитиции и прочее... какая операционка ? какие диски ? в каким массиве они ? как сервер с дисковым массивом соединен ? как созданы девайсы ? как расположены девайсы ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2008, 10:38 |
|
||
|
Физические чтения с сервера БД
|
|||
|---|---|---|---|
|
#18+
авторУважаемый Moris, интересно Ваше мнение - существует ли какая нибудь пропорция размер БД, размер физической памяти сервера, размеры кэшей, количество пользователей и характер их запросов!? Полностью согласен с Код: plaintext 1. 2. 2 biplane Реально я тут в вашем случае вообще не вижу проблемы ни как по присланным материалам, так и по вашим обсуждениям. И так вы считаете... авторОдной из причин замедления времени обработки транзакции считаются физические обращения к дисковому массиву Кем считается ?? На основании чего был сделан такой вывод???? Вы не можете четко сказать этого не так ли? Конфуций Тяжело искать черную кошку в темной комнате. Тем более , если ее там нет. Я бы с удовольствием постарался вам помочь, если бы была реально проблема, но в этом случае мне просто жалко своего времени на флейм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2008, 11:38 |
|
||
|
|
start [/forum/topic.php?fid=55&msg=35243683&tid=2011633]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
151ms |
get topic data: |
8ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 200ms |
| total: | 447ms |
| 0 / 0 |
