|
|
|
DATABASE_CACHE_PAGES
|
|||
|---|---|---|---|
|
#18+
Дано: OS - Win2k, YA 1.0|FB 1.5 FR. Есть такой параметр сервера как DATABASE_CACHE_PAGES. Вычисляется примерно так: Код: plaintext Оптимальное значение сего параметра? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2004, 14:25:13 |
|
||
|
DATABASE_CACHE_PAGES
|
|||
|---|---|---|---|
|
#18+
Ты неправильно понял. Он так не вычисляется . Он используется для кеширования страниц данных и индексных страниц. Вычисляется обычно методом борьбы с отсутствием достаточного количества памяти. В идеале, конечно, было бы здорово засандалить всю базу в кеш. Но у-вы, не всегда это возможно. Кроме того, имеет значение, какая архитектура сервера используется - CS, или SS. Для CS это количество памяти будет отжирать каждый процесс, порождаемый коннектом. Посему, сильно задирать его не стОт. Для SS же, кеш общий для всех коннектов, т.к. в этом случае процесс один (многопоточный). Резюмирую. Выбирай исходя из того, сколь памяти (RAM) тебе не жалко под это отдать, каковы размеры базы, к каким таблицам обращаются наиболее частые и критичные по времени запросы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2004, 14:37:36 |
|
||
|
DATABASE_CACHE_PAGES
|
|||
|---|---|---|---|
|
#18+
Привет. Оптимальное значение сего параметра зависит от типа сервера CS, SS, объема свободной памяти, количества коннектов, данных в базе, сложности запросов к ней и т.д. Так что врядли кто-нибудь даст точный ответ. Попробуй сам определить методом дихотомии. Удачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2004, 14:40:53 |
|
||
|
DATABASE_CACHE_PAGES
|
|||
|---|---|---|---|
|
#18+
Все понятно, будем теперь методом дихотомии (с) лентяй ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2004, 15:38:51 |
|
||
|
DATABASE_CACHE_PAGES
|
|||
|---|---|---|---|
|
#18+
Забыли добавить что увеличением размера кэша в классика легко получить вместо прироста обратный эффект. И дело не в вылете хозяйства БД в своп. А в механизме выгрузки страниц из кэша конкурирующими процессами классика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2004, 15:52:23 |
|
||
|
DATABASE_CACHE_PAGES
|
|||
|---|---|---|---|
|
#18+
Ась??? У классика? Конкуренты выгружают кеш чужих процессов ?! Сам придумал? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2004, 16:03:09 |
|
||
|
DATABASE_CACHE_PAGES
|
|||
|---|---|---|---|
|
#18+
Ну ляпнул ;) сам прочитал обалдел :)))) Чо цеплятся то. Когда кэш слишком большой у классика то в нем могут и будут находится страницы БД которые будут нужны другому процессу и lock_manager будет просить выгрузить их на диск. Процесс записи может быть долгим особенно када их 10000. :) Во всяком случае после 1024 страницы на классике я в своей задаче получил обратный эффект. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2004, 16:21:49 |
|
||
|
DATABASE_CACHE_PAGES
|
|||
|---|---|---|---|
|
#18+
А что скажут уважаемые гуру по поводу такого метода (не знаю как его назвать) - оставить все по дефолту и ничего не трогать. Я лично пользуюсь и пока доволен ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2004, 16:41:49 |
|
||
|
DATABASE_CACHE_PAGES
|
|||
|---|---|---|---|
|
#18+
Аккуратно подправив количество страниц под кэш и объем памяти для сортировки можно весьма неплохо увеличить производительность за счет снижения IO. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2004, 16:59:47 |
|
||
|
DATABASE_CACHE_PAGES
|
|||
|---|---|---|---|
|
#18+
Поясните выделенные красным цветом слова Igor ElyasАкуратно подправив количество страниц под кэш и объем памяти для сортировки можно весьма неплохо увеличить производительность за счет снижения IO. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2004, 14:15:17 |
|
||
|
DATABASE_CACHE_PAGES
|
|||
|---|---|---|---|
|
#18+
Без претензий на абсолютную истину ;) Возможно это очередное заблуждение ) Настройка сильно разнится для супера и классика. К тому же в каждом приложении надо экспериментировать. В любом случае БД не должна вылетать в swap. Иначе будет хуже. Классик берет на каждое подключения память. Супер один раз. Основные параметры напрямую влияющие на производительность : 1.SortMemUpperLimit - для классика 8Мб для супера 64Мб - эта память используется в любом запросе с планом SORT. Чем больше памяти тем лучше. 2.SortMemBlockSize - по умолчанию 1Мб имеет смысл увеличивать только для супера при запросах с большими объемами сортировки. Я еще не выяснил четко влияние этого параметра. Но его экспериментальное увеличение до 2х Мб при 128 Мб на сортировку дало увеличение 5-10%. 3.DefaultDbCachePages (в страницах)- для супера тем больше тем лучше, при размерах более 10000 - может получится наоборот - осторожнее (но это редко). Для классика все зависит от приложения до 256 увеличение потом надо аккуратно увеличивать параметры и пользователей спрашивать про изменение производительности. Примерный расчет : страница БД 8Кб Супер : 16 Мб на всякие нужды (где то 30 подключений, особого роста не объема от увеличени количества подключений не заметно) DefaultDbCachePages = 8192*8кб = 64 Мб + 64 Мб для сортировки итого : 144 Мб памяти под сервер и это не более 2/3 памяти свободной после ОС. Если еще что то крутится то вычитай эту память из доступной. Классик : Поключений: 30 на каждое подключение : 3 Мб на всякие нужды. DefaultDbCachePages = 256*8кб = 2 Мб Под БД (3+2) * 30 = 150 Мб Под сортировку : 8 *30 = 240 Mb этот размер можно смело уменьшать более чем в 4 раза (но осторожно), итого 60 Мб Итог: для комфортной работы нужно 210 Мб свободной RAM (2/3 доступной ОС) Остальные все тюнинги это ОС зависимые. И еще раз при таких экспериментах надо спрашивать пользователей о производительности сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2004, 15:20:38 |
|
||
|
DATABASE_CACHE_PAGES
|
|||
|---|---|---|---|
|
#18+
Igor Elyas1.SortMemUpperLimit - для классика 8Мб для супера 64Мб - эта память используется в любом запросе с планом SORT. Чем больше памяти тем лучше. 1) Для линухового классика дефолт - 0, т.е. сортировка на диске. Опыты показали, что линуховый файловый кеш для темповых файлов работает почти на уровне серверного буфера сортировки. 2) Не только SORT, но и MERGE. Igor Elyas2.SortMemBlockSize - по умолчанию 1Мб имеет смысл увеличивать только для супера при запросах с большими объемами сортировки. Я еще не выяснил четко влияние этого параметра. Но его экспериментальное увеличение до 2х Мб при 128 Мб на сортировку дало увеличение 5-10%. У меня процент увеличения был еще меньше. Этот параметр я ввел исключительно для максимально полного контроля над происходящим в сервере. Возможно, в будущем его уберем, коли он значительного влияния не оказывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2004, 13:17:48 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=32560258&tid=1578450]: |
0ms |
get settings: |
13ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
245ms |
get topic data: |
125ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 687ms |

| 0 / 0 |
