СередаВот мой ONconfig:
-------------------------
IDS 9.40
ISM/OnBar
ОЗУ 2Gb
Двухядерная CPU
Кроме параметров BUFFERS и SHMVIRTSIZE все остальное - это "подарок" от производителя софта который крутится на этой базе (базах).
Черным выделил то, что вызывает у меня подозрения.
Мои рекомендации, вопросы и советы по параметрам:
LOGFILES 25
LOGSIZE 100000
Слишком большой размер логжурналов (100М). Лучше сделать их больше , но меньшего размера, хотя бы по 10М. Доводы смотри в этом форуме, уже не раз обсуждалось (как минимум, при падении винта потеряешь слишком много транзакций).
RESIDENT 1
установи в 2, иначе Win может свопить виртуальный сегмент
NUMCPUVPS 2
Еще не работал с двухядерными серверами, поэтому трудно рекомендовать, но как то не вяжется этот параметр с твоей статистикой ниже (почему то аж 4 KAIO ?)
1.
2.
3.
kio 0 0 16 11489 0 11489 0
kio 1 0 16 26921 830 26091 0
kio 2 0 33 956004 919021 36983 0
kio 3 0 33 546699 437411 109288 0
В любом случае, перегруженным проц не выглядит, хотя для этого нужны другие данные.
В то же время
usercpu syscpu
4567.28 1278.13
говорит о слишком большой части системного времени, что чаще всего говорит о перегруженности дисковой подсистемы или обилии сортировок.
AFF_NPROCS 2
Это нужно убрать. Т.е. установить в 0.
BUFFERS 230000
Рекомендую еще расширить буферный пул, если есть 2Г и больше ничего на этом серваке не работает.
Правда в твоих данных фигурируют разные размеры
сейчас 1307648 Kbytes, а ранее было 1184704 Kbytes
рекомендую BUFFERS 280000
NUMAIOVPS
установить в конкретное значение =1
PHYSBUFF 32
LOGBUFF 32
Размер буфера физжурнала лучше не трогать, чаще всего его размера и так достаточно. А вот размер буфера для логжурнала можно немного увеличить (опять таки, данных для этого мало) до 64, но т.о. слегка понижается надежность (при падении сервака пропадут те транзакции, которые были в буфере и не успели сброситься на диск).
CLEANERS 32
Зависит от числа активных чанков и конфигурации дисков.
И не видно их загрузки.
Покажи хотя бы onstat -u после нескольких часов ативной работы системы.
SHMVIRTSIZE 350000
А нужно ли столько ? Мониторил ли ты потребность в памяти для запросов ?
Из приведенных тобой ранее данных видно, что более 60% сегмента свободно.
CKPTINTVL 1200
Кстати, ты не привел среднее время КТ из журнала. Если оно не превышает 1-2 сек, то можно ничего и не менять. Но при твоих параметрах во время КТ может сбрасываться до 300М на диск и это может занять довольно много времени. Если время КТ большое надо уменьшать LRU...DIRTY.
LRUS 31
Однозначно увеличить до 127.
(при этом размере буферного пула и большом кол-ве ожиданий буферов).
LRU_MAX_DIRTY 30
LRU_MIN_DIRTY 20
Требуют кореляции с другими параметрами
DYNAMIC_LOGS 2
Рекомендую выключить (0) и соответственно, уменьшить два следующих параметра до 45 и 54.
LTXHWM 70
LTXEHWM 80
OFF_RECVRY_THREADS 40
ON_RECVRY_THREADS 10
Зачем это ? Лучше оставить по умолчанию.
Никогда не встречал рекомендации увеличить эти значения, видел только уменьшение.
CDR_EVALTHREADS 1,2
CDR_DSLOCKWAIT 5
CDR_QUEUEMEM 4096
А у вас включена репликация ?
RA_PAGES 32
RA_THRESHOLD 16
Однозначно увеличить. Сначала хотя бы до 128 и 64.
DBSPACETEMP tempdbs1:tempdbs2:tempdbs3:tempdbs4:tempdbs5:tempdbs6
И зачем их столько ? Они что, лежат на разных физических дисках ? Если да, то можно оставить :)
Если нет и все лежат на одном разделе рейда, то достаточно 2-х или 3-х.
USEOSTIME 0
Не трогать (и чем он у тебя вызвал сомнение ?)
MAX_PDQPRIORITY 100
DS_MAX_QUERIES 20
DS_TOTAL_MEMORY 100000
DS_MAX_SCANS 56
А PDQ используется в запросах ? Это ведь легко промониторить даже по onstat -u
OPTCOMPIND 0
А вот эта штука может играть значительную роль в быстродействии запросов.
Вообще то, по умолчанию, д.б. 2 и чаще всего это лучше, но не всегда.
Т.ч. тут можно только поэкспериментировать - взять несколько наиболее частых запросов (или самых "тяжелых" по времени и критичных для системы) и проверить на свободном серваке время выполнения с этими разными параметрами.
ONDBSPACEDOWN 0
Тоже далеко не однозначный параметр. Сам ставлю в 0 (хотя по умолчанию 2).
СередаАпдейты статистики софт выполняет сам по расписанию, которое у них там как-то завязано с другими операциями. Т.е. можно считать, что статистика обносляется своевременно.
А я бы так не считал, а проверил. Хотя бы элементарным запросом по sysdistrib
или воспользоваться готовым, например этим
----------------------------------------------------
-- List Tables with Update Statistics and without
--
-- V.Shulzhenko DBA_Tools
----------------------------------------------------
select unique
t.tabname[1,18] table_name
-- ,d.colno
,t.created
,t.nrows
,d.constructed upstat_date
,d.mode
,substr(d.resolution,1,4) resol
from systables t,outer sysdistrib d
where t.tabid=d.tabid
and t.tabtype='T'
order by 1;
----------------------------------------------------
