ASA9.0.2.3182
Использую AWE кэш, в строке запуска указываю размер = 4096М.
1) Поясните что значит "Выделенное адресное пространство":
I. 18/09 19:57:20. Выполняется на Windows 2003 Build 3790 Service Pack 1
I. 18/09 19:57:21. 4096000K памяти использовано для кэширования
I. 18/09 19:57:21. Физическая память, выделенная для изображений: 4049712К
I. 18/09 19:57:21. Выделенное адресное пространство: 1482464К
I. 18/09 19:57:21. Использование страницы максимального размера 8192 байт
В диспетчере задач видно, что выделяется 4Гига, а вот вопрос как использует
их сервер?

2) И еще, как можно узнать содержимое кэша, как он используется? CacheRead
не дает представления о том насколько эффективно используется кэш. Как
узнать есть ли необходимость/возможность увеличивать/уменьшать размер кэша
без практического влияния на производительность?


Posted via ActualForum NNTP Server 1.3

Ладно, допустим с эффективностью использования кэша все понятно.
Но что значит следующая строка?:
"Выделенное адресное пространство: 1482464К"
Откуда это число? Есть подозрения, что сервер не использует предоставленную ему память. Как проверить точно?

UsersGuide это конечно хорошо. Но вся документация у меня и так есть. И
естественно я плотно с ней ознакомился прежде чем сюда задавать вопросы.
Есть такой момент, который мне жутко не нравится. Если перед каким-то
здоровым запросом по паре таблиц сделать два банальных селекта select
count(*)..., то этот запрос выполняется за 10-15 минут, а если не делать
предварительного шаманства с select count(*), то запрос может выполнятся
часами. В связи с чем возникает желание разобраться, почему сервер посчитал,
что ему проще ненапрягаясь перерыть дисковым чтением 100 млн. таблицу за Х
часов, чем потратить Х минут на чтение этой таблицы в кэш и разобраться с
ней в памяти? Ну да ладно, с этим можно бороться обыкновенной избыточностью
данных и дублировать нужные данные в двух таблицах. Либо, у меня появилась
мысль, повлиять на оптимизатор установкой его политики не в "first row", а в
"all row".
Но почему при старте сервер говорит что выделено 1,5гига, а используется 4 -
вот что необъяснимо... Прямо загадка какая-то.


Posted via ActualForum NNTP Server 1.3

1) optimization_goal точно никогда не крутил. Базу в свое время создавал в централе, данные переливал через полный unload/load из 6-й версии. Подозреваю, что эта опция переползла со старой базы, но проверить не могу, скрипт релоада завален обломками времени..)
Просто сейчас стал смотреть настройки и бросилось в глаза что там стоит вот так, а не иначе.
2) Поднимать тему с пересечением больших объемов данных не хотел бы, т.к. тут это мы уже обсуждали. Но напомню, что производился один здоровый селект, такого вида:
select a,b,olap_functions()
from (select a,b,sum(c)
from (select t1.a,t2.b,t1.c
from t1 key join t2
where t1.d between '' and ''
) as vv()
group by a,b
) as v()
индекс по t1.d имеется. Понятное дело, что запрос слишком нехороший.
Так вот, именно вот про этот запрос я говорил "проще ненапрягаясь перерыть дисковым чтением 100 млн. таблицу за Х
часов, чем потратить Х минут на чтение этой таблицы в кэш и разобраться с
ней в памяти". Оно и понятно, если вторая таблица в кэше, то сервер с диска тянет только первую(и вот тут-то и помогает дисковый кэш), и пробегаясь по ней делает все что надо, а если кэш пустой, то сервер поочередно читает то первую, то вторую таблицу. Возможно, кстати, на такое поведение и повлиял пункт 1.
3) Напомню, первоначальная тема топика связана с эффективностью использования кэша сервером АСА9, а также с административным функциями связаными с получением максимальной информации о кэше АСА и его использовании. О запросах давайте тут не будем, все равно проблему решаю конструктивно (перестройкой структуры).
4) По поводу чтения с диска через память. Да, диск всегда читается через память, но одно дело читать через один буфер размером 64К, другое дело читать через буфер 64К и складывать в сторонке в памяти, авось пригодится. И вот тут меня и интересует, складывает ли АСА что-то в "сторонке"? Что именно лежит сейчас в "сторонке"? Мне кажется странным что не сделан такой функционал, что тут сложного? Или это никому не нужно?

А нет борьбы-то за кэш, то что юзают одни сессии нормально работает и с кэшом в 1гиг. Все остальное выделено под одну задачу. Я сомневаюсь, что что-то вытесняется из кэша. И проделав два(или даже один) шаманских селекта никак не влияет на работу других сессий, а на работу некоего запроса влияет принципиально(даже план не меняется)!!! И дело не в сессиях. К примеру, один сервер, одна сессия, почему АСА сам не может догадаться, что не нужно разрываться на две таблицы одновременно, а последовательно закачать сначала меньшую к себе в память(это на порядок быстрее), а потом последовательно бежать по второй, пересекать с данными из памяти и результат откладывать опять-таки в кэш? Даже если есть сессии которые что-то вытесняют из кэша, они не вытеснят такой объем никогда, у них потребности меньше в тыщи раз. Ему что, памяти жалко? А зачем тогда она ему нужна? Не хочет ее заполнять, а оставить на потом, типа авось пригодится? Я вот как раз не понимаю поведение сервера АСА.

P.S.: По умолчанию, в АСА стоит как раз first-row. Только что проверил. Думаю, надо сначала попробывать с all-row, возможно это и объяснит желание сервера быстрее хоть что-нибудь выдать, вместо потратить меньшее время на всю выборку.

Хм, что-то тут не чисто с этим optimization_goal.
Сейчас настройку посмотрел, там теперь вообще стоит "Response-time".
Возникает вопрос, сервер сам может выставлять эту опцию, в зависимости от каких-то внешних и внутренних факторов? Ведь никто ничего не трогал в базе со вчерашнего дня, а вчера было "first-row"! Только сервер перегружали и все.
Будем разбираться дальше.

))) Это же одно и тоже, что first-row, что response-time. Вопрос снят.

Ха, поменяв опцию Optimization_goal на 'all-rows' вылечил проблему (как мне кажется). По крайней мере план изменился, и по нему видно, что сервер решил отбросить использование внешнего ключа. Вот она собака где порылась.
P.S.: А еще кто-то говорит, что ASA это "несерьезная детская игрушка"...) Очень даже приличный сервер, надо только уметь готовить.