|
Действия ...
|
29.04.2013, 10:48
|
|||
|---|---|---|---|
|
|||
база данных 64 кб |
|||
|
|
|
29.04.2013, 11:09
|
|||
|---|---|---|---|
|
|||
база данных 64 кб |
|||
|
|
|
29.04.2013, 14:58
|
|||
|---|---|---|---|
|
|||
база данных 64 кб |
|||
|
|
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
29.04.2013, 10:30
|
|||
|---|---|---|---|
база данных 64 кб |
|||
|
#18+
Приветствую новые версии каше поддерживают базы данных с размером блока 8/16/32/64 На сервере Centos6.4 стоит рэйд с 64 кб размером блока. Будет ли эфективнее скорость работы с диском, если поменять блок БД в каше на 64кб? Можно ли изменить размер блока данных в кашетемп и остальных систмных баз. Если нет то нужно ли оставлять кэш на каше темп? Те в настройках системы указывается кэш для 8кб и 64кб баз нужно ли отводить кэш под 8 кб базы, при условии что там останутся только те базы что создались в каше при старте (%sys/user/samples/cachetemp/audit) ??? Кто нибудь будь рабортал с 64кб БД в каше? как впечатления? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.04.2013, 10:48
|
|||
|---|---|---|---|
база данных 64 кб |
|||
|
#18+
Нам на некоторых проектах пришлось перейти на 16Kb блоки (были проблемы с кешированием через ECP) для работы с БД отличными от 8Kb, необходимо иметь настроенным обязательно буферы глобалов на блоки самого большего из имеющихся в БД размеров, т.е. например если у вас есть хотя бы одна БД на 64Kb, то можно настроить только буфер на 64Kb, для других БД будет использоваться этот же буфер. Переделать системные БД под такой размер блока можно, но нет смысла, а вот с CACHETEMP, так как она может создаваться и автоматически (если ее удалить) она будет создаваться с размером блока по умолчанию который можно переопределить в глобале например так Код: plaintext запятая в конце нужна, если в списке разрешенных размеров будет 8192, то по умолчанию будет такой размер блока, иначе самый последний в списке, посмотреть размер блока по умолчанию Код: plaintext по поводу скорости работы улучшений особо и не заметно и вроде как им неоткуда взяться, но я всех тонкостей работы с блоками не знаю, но полагаю что выбор размера блока лучше основывать на характере данных, если у вас много строк в БД размером большим 8Kb, то полагаю это может быть оправдано, у нас используются битовые строки в 64000 бита, и из-за них мы и перешли на 16Kb блоки, так как они не кешировались в ECP-конфигурации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.04.2013, 11:09
|
|||
|---|---|---|---|
база данных 64 кб |
|||
|
#18+
gr_vl , В дополнение: DBSizesAllowed ( ещё ) Memory Allocated for XXKB Database Cache (MB) Disk/Storage Subsystem Configuration Recommendations Database Configuration Considerations ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.04.2013, 14:36
|
|||
|---|---|---|---|
|
|||
база данных 64 кб |
|||
|
#18+
То-то и оно, что практический опыт работы с большими блоками, похоже, ещё не накоплен, в основном ссылки на документацию. 8K и 16K - соседние размеры, ожидаемо, что разницы по скорости практически нет. Мы когда-то сравнивали 8K и 4K (в GT.M), особой разницы тоже не было. Е. Каратаев упоминает исследование Oracle, где сделан вывод, что оптимальный размер блока обычно лежит в пределах между 6 и 12K (могу ошибаться, книги сейчас под рукой нет). Кстати, знаете ли вы, (работая с ECP), что самый большой размер кадра в сетях Ethernet (так называемый Jumbo Frame) = 9000 байт? В него как раз хорошо ложится 8KB блок... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.04.2013, 14:58
|
|||
|---|---|---|---|
база данных 64 кб |
|||
|
#18+
у нас до переход на 16Kb ECP трафик был довольно большой, что вынудило нас поначалу, соединять каждый ECP-клиент с ECP-сервером отдельным гигабитным каналом, потом уже после перехода все сервера успешно сидят на одном канале и теперь загрузка гигабита не больше 10% на ECP-сервере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.05.2013, 11:07
|
|||
|---|---|---|---|
база данных 64 кб |
|||
|
#18+
DAiMorу нас до переход на 16Kb ECP трафик был довольно большой, что вынудило нас поначалу, соединять каждый ECP-клиент с ECP-сервером отдельным гигабитным каналом, потом уже после перехода все сервера успешно сидят на одном канале и теперь загрузка гигабита не больше 10% на ECP-сервере. А если не секрет у вас ECP зачем используется? На его основе построен кластер для увеличения быстродействия или чтото другое? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.05.2013, 11:11
|
|||
|---|---|---|---|
база данных 64 кб |
|||
|
#18+
gr_vlDAiMorу нас до переход на 16Kb ECP трафик был довольно большой, что вынудило нас поначалу, соединять каждый ECP-клиент с ECP-сервером отдельным гигабитным каналом, потом уже после перехода все сервера успешно сидят на одном канале и теперь загрузка гигабита не больше 10% на ECP-сервере. А если не секрет у вас ECP зачем используется? На его основе построен кластер для увеличения быстродействия или чтото другое? Для обеспечения работы большого количества пользователей, один сервер с этим не справляется. в пиковой нагрузке было около 3 тыс пользователей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/search_topic.php?author=stanislove&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
58ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
2ms |
| others: | 592ms |
| total: | 772ms |
| 0 / 0 |
