vasilis,
vasilisсами читаете, разбираетесь, пробуете, задаете внятные вопросы и также сами отвечаете.
А как иначе? Проблема ведь у меня возникла )) И на паблик форуме никто никому ничего не должен. Так что это с вами работать приятно)
vasilisПроверьте, на самом ли деле работает write-back.
Совсем не давно тут рассматривалась проблема падения производительности из-за автоматического отключения кэширования на запись.
Проверил, работает. Сделал простой тест на запись с работающим, а затем отключенным кэшем. В 1 поток. Объем данных сопоставим с объемом грязных страниц в буферах в момент КТ. Размер блока 2к и 4М для сравнения (просто не знаю, блоком какого размера IDS пишет на диск. Возможно, pagesize?).
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
кэш вкл
[root@ondbprm ~]# time dd if=/usr/logs/phys of=/usr/data/temp_of oflag=direct bs=2k count=128000
128000+0 records in
128000+0 records out
262144000 bytes (262 MB) copied, 7.91706 seconds, 33.1 MB/s
real 0m7.920s
user 0m0.024s
sys 0m1.104s
[root@ondbprm ~]# time dd if=/usr/logs/phys of=/usr/data/temp_of oflag=direct bs=4096k count=60
60+0 records in
60+0 records out
251658240 bytes (252 MB) copied, 1.06274 seconds, 237 MB/s
real 0m1.074s
user 0m0.000s
sys 0m0.122s
кэш выкл
[root@ondbprm ~]# time dd if=/usr/logs/phys of=/usr/data/temp_of oflag=direct bs=4096k count=60
60+0 records in
60+0 records out
251658240 bytes (252 MB) copied, 1.01192 seconds, 249 MB/s
real 0m1.023s
user 0m0.000s
sys 0m0.135s
[root@ondbprm ~]# time dd if=/usr/logs/phys of=/usr/data/temp_of oflag=direct bs=2k count=128000
128000+0 records in
128000+0 records out
262144000 bytes (262 MB) copied, 567.298 seconds, 462 kB/s
Для bs=2k без кэша совсем грустно). А для 4М разницы между вкл/выкл кэша просто нет.
vasilisPHYSFILE 16500000
Зачем такой огромный? Ведь обслуживать такой файл и искать там нужную точку тоже нужно время. В моей жизни 1-2Гб хватало даже в самых нагруженных системах, но на истину не претендую
Да, это я дал маху. Ориентировался на суммарный объем буферов. Совсем не учел, что в моем случае изменению подлежит лишь малая их часть. Уменьшил до 2 Гб. Посмотрим, каков будет результат.
vasilis
AUTO_AIOVPS 1
Тоже отключил бы и, помониторив, установил бы ручками.
Я не знаю логики работы этого автомата, но обычно они все заточены под некие очень стандартные и условные параметры. Знающий человек почти всегда сделает лучше.
Следующим шагом отключу и буду «руками» изменять.
vasilis
RESIDENT 0
рекомендую 1 или 2.
Изменил на 1.
vasilisCKPTINTVL 150
А зачем уменьшали диапазон ? Это меньше 3-х минут.
Установите стандартные 300, а я бы даже и увеличил до 600.[quote]
Когда не работали LRU, сократил время, чтобы суммарный объем грязных страниц был меньше. Сейчас вернул в 300.
[quote vasilis]AUTO_CKPTS 1
тоже самое, что я уже писал по поводу "автоматов"
Выключил
vasilisTAPEDEV /dev/null
LTAPEDEV /dev/null
А это как понять ?
У вас разве не промсистема ? Надеюсь, что это тестовая.
Куда пишутся архивы - на диск или ленту? если на диски, то блок можно увеличивать - в нашем ФАК-е помнится были исследования на эту тему...
Пишу на диски. Использую STDIO. Очень удобно. Вот, может пригодится кому:
Бекап
ontape -s -L 0 -t STDIO | gzip -1 > /back/full_backup.gz
gzip сжимает где-то в 10 раз. Процессора почти не ест (т.к. ключ -1).
Восстановление
zcat /back/full_backup.gz | ontape -r -t STDIO
И самое приятное, чтобы не прыгать с ленточкой по серверной, поднятие репликации по сети без файлов и лент:
На primary делаем скрипт /back/stdio_back.sh
# set IDS ENV
ontape -s -L 0 -t STDIO
На secondary запускаем
ssh primary “/back/stdio_back.sh" | gunzip | ontape -p -t STDIO
Ну и все, дальше onmode’ом переключаемся в primary/secondary. По сети перегоняется сжатый бекап. Одновременно работает как бекап так и восстановление, что положительно сказывается на времени работы.
(Когда в этом топике я пишу, что делаю ontape, значит я делаю ontape –s –L 0 –t STDIO | cat > /dev/null. Это чтобы исключить влияние gzip’а и записи файла с бекапом на диск)
По-моему только в 11ом появилось STDIO.
vasilisDS_NONPDQ_QUERY_MEM 128
Однозначно увеличить, хотя бы до 5М - это позволит увеличить память для сортировок
Увеличил до 10 М. Заодно пришлось увеличить и DS_TOTAL_MEMORY до 60М. Было по дефолту меньше 1М.
vasilisBUFFERPOOL size=2K,buffers=4000000,lrus=256,lru_min_dirty=0.100000,lru_max_dirty=0.300000
BUFFERPOOL size=8K,buffers=1500000,lrus=256,lru_min_dirty=0.500000,lru_max_dirty=1.000000
Такие огромные пулы требуюти больших расходов на свое обслуживание.
Надо тщательно помониторить процент кэширования и поиграться с размерами - вполне возможно, что ваша активная часть БД поместится и в значительно меньшем объеме. Тогда будет однозначный плюс для КТ.
+
Я бы установил еще большее количество очередей (мне кажется в 11.5 можно больше 256?) для таких огромных пулов, а также попробовал бы не так сильно уменьшать "окно" сброса, т.е. установил бы для начала на уровне 5 и 2% или даже 10 и 5.
Уменьшил в 2 раза кол-во буферов и увеличил LRU до 500. В моей версии максимум 512.
Теперь буфера выглядят так:
BUFFERPOOL default,buffers=10000,lrus=8,lru_min_dirty=50.000000,lru_max_dirty=60.500000
BUFFERPOOL size=2K,buffers=2000000,lrus=500,lru_min_dirty=0.400000,lru_max_dirty=1.200000
BUFFERPOOL size=8K,buffers=750000,lrus=500,lru_min_dirty=2.000000,lru_max_dirty=4.000000
vasilisБуфер сбрасывается в журнал целиком, а в среднем там меньше двух страниц, при размере буфера в 16 2К-страниц. Т.е. буфера переключаются слишком быстро и не успевают сбрасываться на диск (это если рассматривать ситуацию, описанную В.К.).
Если будет буферизация, то буфер будет сбрасываться только после заполнения, (т.е. преключения будут более редки) т.о. давая время на сброс двум другим буферам.
Спасибо, буду пробовать изменять размер буфера.
Статистику (profile_ из DBA_Tools) выложу, как только соберу
