|
Действия ...
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
02.03.2006, 18:32
|
|||
|---|---|---|---|
|
|||
ASE размер страницы |
|||
|
#18+
Интересно мнение - можно ли как-либо кроме эксперимента определить оптимальный размер страницы базы данных? Пробовал 2К и 4К, быстрее 4К (несмотря на настроенные пулы 4К и 16К). Хочу попробовать страницы 8К, но очень жалко времени на переливку. Насколько я понимаю, при увеличении размера страниц возрастет количество поднятия с жестких дисков бесполезной информации при точечных запросах. С другой стороны существует граничное количество обращений в 1 жесткому диску за секунду (приводится, что для 10 Кrpm винтов оно примерно 100 операций). То есть для массива из 10 дисков - 1000 операций ввода вывода в секунду. Даже если будет идти ввод/вывод по 16К - объем потока данных составит 1000*16К=16Мб, что намного ниже пропускной способности raid. Поэтому с этой точки зрения нужно ставить 16К и не раздумывать... Кто то может поделиться опытом работы с большими страницами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.03.2006, 22:35
|
|||
|---|---|---|---|
ASE размер страницы |
|||
|
#18+
Ну тут нельзя увлекаться. Большие страницы применяют для хранилищ данных в основном. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.03.2006, 10:37
|
|||
|---|---|---|---|
|
|||
ASE размер страницы |
|||
|
#18+
MasterZivНу тут нельзя увлекаться. Большие страницы применяют для хранилищ данных в основном. А в чем может быть проблема в oltp-системе? все равно ввод/вывод по 16К * 100 операций/сек не нагрузят диск. Меньше страничек в кеше будет храниться, но если кеш большой, то это не проблема. Какие еще подводные камни могут быть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.03.2006, 11:15
|
|||
|---|---|---|---|
ASE размер страницы |
|||
|
#18+
Олег321 А в чем может быть проблема в oltp-системе? все равно ввод/вывод по 16К * 100 операций/сек не нагрузят диск. Меньше страничек в кеше будет храниться, но если кеш большой, то это не проблема. Какие еще подводные камни могут быть? А подводные камни следущие: - Размер БД возрастет, т.к. будет больше неиспользованного места в екстентах. Небольшие теблицы, включая системные будет резервировать больше места, бOльшая часть которого будет не использованна. - Это же свойственно и для tempdb. Все временные таблицы будут бОльших размеров. - Размер кешей тоже надо будет увеличивать (как уже было подмеченно) - Увеличится конкуренция за блокировки для APL таблиц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.03.2006, 11:37
|
|||
|---|---|---|---|
|
|||
ASE размер страницы |
|||
|
#18+
moris А подводные камни следущие: - Размер БД возрастет - Размер кешей тоже надо будет увеличивать) - Увеличится конкуренция за блокировки для APL таблиц Сводобного места на диске много, кеш большой, при блокировках можно сметить тип блокировки по отдельным таблицам. Оптимально - 16К ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.03.2006, 18:05
|
|||
|---|---|---|---|
ASE размер страницы |
|||
|
#18+
Думаю что в активных OLTP-системах может быть нехорошо из-за конкуренции за блоки индекса. Чем больше блок-тем больше ключей туда попадает ведь. Т.е. если уж очень хочется большие страницы-ну например железо плохо работает с мелкими страницами - то нужен некоторый баланс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.03.2006, 23:45
|
|||
|---|---|---|---|
ASE размер страницы |
|||
|
#18+
Насчет performance разных pagesize это много обсуждалось на sybase forums newsgroups, впрочем без особого результата (типа уже упомянутых здесь вещей) IMHO, но вот у меня на 8K сервере (12.5.0) Sybase Central и DBArtisan показывают вещи типа free devise size неправильно (причем AFAIK это связано с тем что в Sybase системных таблицах/sps забито кое-где pagesize = 2K). А вот интересно еще из книги J.Lewis-a (по Oracle 8i, но тут IMHO это не важно), что db_block_size(Oracle) (pagesize,Sybase) должен быть кратен (больше или равен) OS block size (если база на файлах, на raw device это несущественно и вот почему некоторые люди "открывают" что "raw-device is much faster than file system" ), т.е. для Solaris 7/8/9 (df -g) размер блока должен быть кратен 8K (8K,16K, etc...), иначе будет so-called block-mismatch и запись может быть в 2 шага (wait in ave. 1.5 rotation) там же приводится табл. (см.ниже) из которой видно что при 8K блоке файловой системы из-за block mismatch проигрыш на записи почти в 2 раза. Правда смущает что в C программе там приведенной(эмулирует Oracle DBWR process) мода O_DSYNC, что может не так на Sybase (?). No, of writes 8K File system Raw device ------------------ -------------- ---------- 1,000 writes of 2K 26.63 sec 11.39 sec 1,000 writes of 4K 25.70 sec 11.45 sec 1,000 writes of 8K 15.61 sec 12.05 sec ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
04.03.2006, 15:15
|
|||
|---|---|---|---|
|
|||
ASE размер страницы |
|||
|
#18+
Zhoraно вот у меня на 8K сервере (12.5.0) Почему выбрано именно 8? Пробовали 4 или 16? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
04.03.2006, 23:35
|
|||
|---|---|---|---|
ASE размер страницы |
|||
|
#18+
Еще могу сказать вот что. В разных серверах пулы ввода - вывода могут быть такие : 2k server : 2k, 4k, 8k, 16k 4k server : 4k, 8k, 16k 8k server : 8k, 16k 16k server : 16k Т.е. с ростом базовой страницы у сервера все меньше и меньше вариантов для выбора размера ввода-вывода, в сторону только большого ввод-вывода. Минимальный объем IO для позиционирования по ключу индекса растет, ну и вообще минимальная стоимость по IO всех операций растет. Для OLTP это вообще по-моему катастрофа. Как там ОС и RAID хотят читать - это их проблемы, ASE c ними бороться не должен, но и сам лишнего не делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.03.2006, 13:11
|
|||
|---|---|---|---|
ASE размер страницы |
|||
|
#18+
MasterZivЕще могу сказать вот что. В разных серверах пулы ввода - вывода могут быть такие : 2k server : 2k, 4k, 8k, 16k 4k server : 4k, 8k, 16k 8k server : 8k, 16k 16k server : 16k ... , ну и вообще минимальная стоимость по IO всех операций растет. Для OLTP это вообще по-моему катастрофа.... А как, в общем виде, исходя из всего вышесказанного, правильно настроить кэши, если страница базы данных = 2к, а страница OS (HP UX IA64) = 4k? И стоит ли, какой?, делать кэш для лог-сегмента? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.03.2006, 13:44
|
|||
|---|---|---|---|
|
|||
ASE размер страницы |
|||
|
#18+
MasterZivс ростом базовой страницы у сервера все меньше и меньше вариантов для выбора размера ввода-вывода, в сторону только большого ввод-вывода. Чем меньше вариантов оставлять оптимизатору ASE, тем лучше получаются планы запросов :) А вообще я так и не понял, ну и что плохого в том, что вместо 2К сервер запишет 16К? Я начал с того, что у диска есть 2 ограничения макс.объем записываемой информации (пропускная способность - примерно 50Мб/сек на 1 диск) и максимальное количество операций ввода/вывода (примерно 100 в секунду на 1 диск). Ни при странице 2К ни при странице 16К предела в 50Мб/сек при 100 операциях ввода вывода мы не получаем. А количество операций при увеличении страницы ввода/вывода может либо не измениться либо сократиться, что есть хорошо. А блокировки можно побороть например сменой типа блокировки. Вобщем, я установил 16К, на первый взгляд быстрее... Неделю еще понаблюдаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.03.2006, 13:54
|
|||
|---|---|---|---|
|
|||
ASE размер страницы |
|||
|
#18+
SAV4SAV А как, в общем виде, исходя из всего вышесказанного, правильно настроить кэши, если страница базы данных = 2к, а страница OS (HP UX IA64) = 4k? И стоит ли, какой?, делать кэш для лог-сегмента? При 2К странице желательно пул 4К для логсегметов, пул 16К для большого ввода/вывода, их размеры для начала например по 20% от общего кеша, а затем нужно менять исходя из их использования запросами (нужно мониторить планы запросов и sp_sysmon) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.03.2006, 19:58
|
|||
|---|---|---|---|
ASE размер страницы |
|||
|
#18+
MasterZivЕще могу сказать вот что. В разных серверах пулы ввода - вывода могут быть такие : 2k server : 2k, 4k, 8k, 16k 4k server : 4k, 8k, 16k 8k server : 8k, 16k 16k server : 16k Это неверно, на самом деле так: 2k server : 2k, 4k, 8k, 16k 4k server : 4k, 8k, 16k, 32К 8k server : 8k, 16k, 32К, 64К 16k server : 16k, 32К, 64К, 128К ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.03.2006, 22:26
|
|||
|---|---|---|---|
ASE размер страницы |
|||
|
#18+
Олег321 Zhoraно вот у меня на 8K сервере (12.5.0) Почему выбрано именно 8? Пробовали 4 или 16? Нy, например так: 1. Девелопмент сервер. 2. Истина обычно посредине :-) 3. Смесь OLTP+DSS 4. Oracle DBCA by default (к сожалению Sybase ничего не предлагает) предлагает 8К для 3. 5. SQL server 2000 by default=8K 6. Solaris pagesize=8K. 4,16 - net, ne proboval. Основная проблема я думаю с pagesize > 2k - locks/deadlocks на system tables в tempdb (все "старые" таблицы - только APL, кажется только в 15 - datarows) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=55&mobile=1&tid=2013007]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
40ms |
get topic data: |
7ms |
get forum data: |
1ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 246ms |
| total: | 366ms |
| 0 / 0 |
