vasilisДам рекомендации уже завтра - к сожалению, сегодня уже нет времени :(
завтра пришло послезавтра :)
Ниже мои рекомендации по onconfig без подробных объяснений (некоторые уже были ранее).
Что будет непонятно - спрашивайте. Лучше добавлять (изменять) понемногу. Так лучше понять результаты изменений и откатить назад, если что.
Исходим из того, что 16 ядер, 4 Гб ОП, на сервере только IDS и ничего более, чистый OLTP (редкость, кстати), много дисков, высокая нагрузка.
PHYSFILE 512000 (32М - старый) - большой размер ничем не грозит, маленький - опасен.
LOGFILES 184 # Number of logical log files
LOGSIZE 256000 # Logical log size (Kbytes)
Логи у вас разных размеров и разбросаны по многим пространствам. Надо бы навести порядок.
Почему ? Например, полетит один из рядовых чанков с данными (возможно и не критичными). В обычной ситуации сервер будет продолжать работать, но если там лежит логический журнал, то сервер встанет полностью.
TBLSPACE_STATS 1 - после настройки этот параметр лучше выключать в тяжело нагруженной системе
RESIDENT 2 (0) - два сегмента должны быть резидентными
NUMCPUVPS 12 (4) - при 16 ядрах можно смело увеличивать
NOAGE 0 # Process aging
AFF_SPROC 0 # Affinity start processor
AFF_NPROCS 0 # Affinity number of processors
А на SCO эти параметры работают в принципе ?
#BUFFERS 524288 # Maximum number of shared buffers
BUFFERS 262144 # Maximum number of shared buffers
#BUFFERS 131072 # SHMMAX set to 819200000
У вас 4Гб памяти. Установите параметры ядра, чтобы можно было сделать сегмент (и буферный пул ) больше. Хотя бы размером в 1Г.
Т.е. попробуйте сделать BUFFERS 512000
Но проверьте это сначала на тестовой машине с такой же версией ОС и IDS.
У вас может хорошо вырасти производительность, т.к. буферов не хватает и процент кеширования по чтению низкий.
NUMAIOVPS 32 (не был установлен). По умолчанию у вас их 128 (по удвоенному числу чанков). Это много и не нужно.
PHYSBUFF 32 # Physical log buffer size (Kbytes)
LOGBUFF 32 (64) # у вас небуферируемая БД, т.к. большой буфер вам просто не нужен - постоянная лишняя работа по обработке и сбросу пустого, практически, буфера.
CLEANERS 16 (8) - по статистике видно, что все 8 нагружены одинаково сильно. А желательно, чтобы был 1-2 свободных (у них кол-во операций на порядок-два меньше) для пиковых нагрузок.
SHMVIRTSIZE 131072 # initial virtual shared memory segment size
Здесь просканируйте свой online.log на предмет динамического добавления сегментов. Если такие попадались -лучше увеличить. Например до 256000 - памяти у вас девать некуда :)
CKPTINTVL 0 # Check point interval (in sec)
Об этом уже писал.
CKPTINTVL 300 или 600.
#LRUS 64 # Number of LRU queues
LRUS 256
В вашей версии максимум 128 (если не ошибаюсь).
Поэтому установите
LRUS 127
LRU_MAX_DIRTY 30 # LRU percent dirty begin cleaning limit
LRU_MIN_DIRTY 20 # LRU percent dirty end cleaning limit
Эти надо будет настроить, когда измените CKPTINTVL и промониторите длительности.
LTXHWM 45 (50) # Long transaction high water mark percentage
LTXEHWM 54 (60) # Long transaction high water mark (exclusive)
Много разз писал на эту тему. Поищите по форуму.
OFF_RECVRY_THREADS 1 (80) - надежнее
ON_RECVRY_THREADS 10
RA_PAGES 64 # Number of pages to attempt to read ahead
RA_THRESHOLD 32 # Number of pages left before next group
Read Ahead ("чтение наперед" большими блоками) ускоряет дисковое чтение при оследовательных просмотрах таблиц и индексов. Алгоритм интелектуален и не применяется для всех операций чтения с диском. Эффективность мониторится по onstat -p (последняя строка), при этом эффективным считается рубеж в 90% (как его вычислять смотрите в других FAQ).
DBSPACETEMP temp01,temp02 # Default temp dbspaces
Лучше сделать еще 1-2 временных пространства такого же размера, как и первые два.
У вас может помочь распараллелить сортировки и т.п.
OPTCOMPIND 2 # To hint the optimizer
тут рекомендую почитать.
http://www.sql.ru/faq/faq_topic.aspx?fid=681
Есть много мнений в OLTP системах устанавливать 0
