|
|
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
В MS SQL сервере первая (а зачастую и последняя :) рекомендация по увеличению производительности сервера - добавьте оперативной памяти. Это не гарантирует увеличения производительности, но точно не ухудшит. Мой знакомый, побывавший на курсах ORACLE утверждает, что для ORACLE это не так. Что их преподаватель сказал, что увеличение памяти может ухудшить производительность. Вопрос: Это так ? Если да, то за счет чего ? Ну не могут же затраты на управление кэшем перевесить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 10:16 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
Само по себе добавление памяти производительность не ухудшит. Но если еще бездумно менять параметры SGA - то запросто. Например, вопрос о кэше буферов. Не всякое его увеличение приведет к увеличению производительности системы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 10:22 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
То что не всякое это понятно. Но вот чем он может ухудшить производительность при условии отсутстви конкуренции за память с другими приложениями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 10:29 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
может ухудшить, поскольку при росте SGA растут издержки на управление. Уверен, что для MSSQL - тоже самое. Просто уровень ответов был разный Насчет конкуренции... не забывайте, что Oracle - многопользовательская среда. Куча процессов(нитей) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 10:38 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
2 killed может ухудшить, поскольку при росте SGA растут издержки на управление. Уверен, что для MSSQL - тоже самое. Просто уровень ответов был разный Насчет конкуренции... не забывайте, что Oracle - многопользовательская среда. Куча процессов(нитей) А лошадь бегает медленее человека, потому что ей четыре ноги переставлять, а человеку две ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 11:21 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
Насколько я понимаю Килледа, то лошадь будет бажать медленнее если у нее будет шесть ног и то же количество весьма ограниченное количество мозгов чтобы ими рулить. Ситуация в общем редкая, но представимая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 11:30 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
>А лошадь бегает медленее человека, потому что ей четыре ноги переставлять, а человеку две ? А у таракана еще больше ног. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 11:39 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
А если серьезно, то я не понимаю, что нужно делать с кешем, чтобы затраты на управление им стали сравнимы с выгодой от его использования. И почему примитивный, по сравнению с ORACLE, сервер MS SQL может получить выгоду от увеличения памяти, а ORACLE нет. Горе от ума ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 11:47 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
Не зря-же появилась возможность разбивать BUFFER POOL на 3 части: DEFAULT, KEEP, RECYCLE ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 11:49 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
>То что не всякое это понятно. >Но вот чем он может ухудшить производительность при условии отсутстви >конкуренции за память с другими приложениями. кстати, интересно обсудить какие накладные расходы возникают, например, с увеличением буферного кеша. Навскидку могу назвать две: 1. Ожидание latch #66 (cach buffer chain), число которых по дефолту равно числу cpu/2 или выставляется параметром db_block_lru_latches. 2. Более интенсивные чекпоинты (конечно, при условии, что предыдущий размер буферного кеша был достаточным и небыло недостатка free buffers) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 11:53 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
Вроде, может возникнуть деградация производительности с большим буферным кешем при сбросе на диск грязных блоков во время чекпоинта вызванного переключением журналов. Если не прав поправьте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 12:11 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
Вроде, может возникнуть деградация производительности с большим буферным кешем при сбросе на диск грязных блоков во время чекпоинта вызванного переключением журналов. Если не прав поправьте. Поправить не могу, но недоумение выражу. Откуда взялось увеличение количества грязных блоков ? Сколько пользователи испачкали, столько и будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 12:18 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
>Поправить не могу, но недоумение выражу. Откуда взялось увеличение >количества грязных блоков ? Сколько пользователи испачкали, столько и >будет. имеется ввиду пиковая нагрузка во время выполнения чекпоинта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 12:32 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
To .dba 1) Я так понимаю паямять нужно наращивать пока есть недостаток в FREE BUFFERS. А потом сразу прекращать это дело. 2) db_block_lru_latches можно настроить так чтобы он соответствовал измененным параметрам кеша. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 12:33 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
Mozhet bitj, shto dlja maljenkoj aplikacii slishkom bolshoj abjom pamjatji budet meshatj. Privedu primer - v baze hranjitsja 1MB dannih, pamjatj dlja SGA - 1GB. Podnjatj bazu u katoroj SGA tolko 32MB budet namnogo bistree :)) No ja njikogda bi njezadumivalsja nad tem, shto nado umenshitj abjom pamjatji u servera, v katorom teper stoit 12GB shtobi povisitj proizvoditeljnostj. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 12:37 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
>1) Я так понимаю паямять нужно наращивать пока есть недостаток в FREE >BUFFERS. А потом сразу прекращать это дело. ну почему ж только при недостатке free buffers? Разве логические чтения не являются более эффективными чем физические? >2) db_block_lru_latches можно настроить так чтобы он соответствовал >измененным параметрам кеша Изменить то можно, но при том же колличестве cpu это особого смысла иметь не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 12:37 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
2 Eter Panji Я так понимаю паямять нужно наращивать пока есть недостаток в FREE BUFFERS. А потом сразу прекращать это дело. Как это ? Постоянно сидеть перед монитором и отслеживать ? А если нагрузка меняется в течении дня (и количество пользователей и характер запросов) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 12:38 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
2 Delerium Меня, конечно, интересует нормальный случай. База больше оперативной памяти и изменение количества памяти в разы, а не порядки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 12:43 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
To .dba Да ну здесь мы натыкаемся на HIT_RATIO параметр первого порядка для определения размера буфферного кеша Насколько я понимаю то о чём мы говорим влияет на производительность уже во втором порядке. To ф На зачем же можно каким-нибудь монитором это дело отслеживать. А потом вывести среднее приемлемое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 12:49 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
Судя по длительному молчанию, все кто мог высказались. Подвожу итог (как я его понял) MS SQL сервер в работе с кэшем круче чем ORACLE :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 16:05 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
Я не говорю о системах, в которых дисковые операции - изначально слабое место. Тогда добавление памяти даже при неоптимальной настройке сервера все равно даст заметный рост производительности. Хотя диски будут все сильнее и сильнее тормозить работу. Аналогичная проблема в такой системе появится и при добавлении новых процессоров. Далее считаю, что дисковая система опимальна (какой-нибудь массив на fiber channel). При увеличении кэша производительность растет не пропорционально, а скачками - какой-то прирост не вызывает роста производительности, а потом еще капельку - и вдруг случается чудо. Это связано с тем, что оракл перестраивает свои управляющие структуры не монотонно, а скачками. Те же lru_latches или очереди чекпойнтов. Чтобы обеспечить более плавный рост производительности и используются задания параметров, котроые вроде вычисляются ораклом. Могут еще быть достаточно идиотские платформенные заморочки, вроде памяти больше 2Г под HP-UX, когда из-за переключения страниц ОС возникают хитрые таймауты не дающие, к примеру подключаться пользователям без увеличения ожидания, или вынужденному ограничению размера кэша. Может, правда в последних HP-UXах это убрали - я общался с 10 и 11.0. Но в конце-концов все можно заставить работать достаточно оптимально. Ну и последнее. Поставьте MS SQLServer на HP-UX или Solaris и посмотрим, что лучше работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 16:47 |
|
||
|
Память. Чем больше, тем лучше ?
|
|||
|---|---|---|---|
|
#18+
2 AI Поставьте MS SQLServer на HP-UX или Solaris и посмотрим, что лучше работает. Так пока вас(ораклоидов) не спровоцируешь грубыми наездами, вы ж все молчите :) А из Ваших объяснений я понял, что можно не опасаться уменьшения производительности ORACLE при увеличении памяти. (Я собственно так и думал) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 17:38 |
|
||
|
|

start [/forum/topic.php?fid=52&gotonew=1&tid=1990935]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
53ms |
get topic data: |
10ms |
get first new msg: |
6ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 221ms |
| total: | 362ms |

| 0 / 0 |
