serg08Подскажите кто знает как работает политика Relaxed LRU.
Вроде бы всю документацию прошерстил.


P&TG, Chapter 14 "Memory Use and Performance", раздел "Cache replacement strategies and policies"Relaxed LRU policy saves the overhead of maintaining the cache in MRU/LRU order. On SMP systems, where copies of cached pages may reside in hardware caches on the CPUs themselves, relaxed LRU policy can reduce bandwidth on the bus that connects the CPUs.
Изложу проще и по-русски : Strict LRU/MRU кэши внутри ASE реализованы в виде связных списков-очередей, с поддержкой этого списка.
Relaxed LRU кэш реализован НЕ в виде связного списка, то есть, это НЕ очередь, неупорядоченная структура, что позволяет экономить память на организацию связного списка и время при вводе/выводе на переорганизацию очереди.

serg08
Везде какие то полунамёки и лишь рекомендации.


А ничего другого там и быть не может - только рекомендации, потому что Tuning - достаточно сложная и специфичная для каждого конкретного приложения вещь.

serg08
На сервере попадание в кеш высокое.
Т.е. следует установить Relaxed LRU

Если cache hit ratio вообще высокое, это не является показанием для применения Relaxed.

Примером, где применение Relaxed будет оправдано, может служить таблица, привязанная к собственному именованному кэшу, и причем так, что вся эта таблица в кэш влезает и кэш используется только этой таблицей, и на таблицу эту часто ссылаются в запросах, но она никогда или почти никогда не меняется - т.е. какой-нибудь часто используемый справочник.

serg08
Но система многопроцесорная.
Т.е. не следует торопиться.


А при чем здесь многопроцессорность ? Ну многопроцессорная, и что ?
Ни "за", ни "против" Relaxed LRU это, насколько я знаю, ничего не говорит.

serg08
Хотелось бы всё таки осознано действовать.
Подозреваю, что это относиться не только к Sybase.

Боюсь, как раз наоборот, именно только к Sybase ASE.

serg08
Поделитесь пожалуйста ссылочкой или знаниями!



Описано в доке здесь.

serg08Как причём многопроцесорность!!!
...
SMP это разве не многопроцессорная симетричная система.


Да, фразу я про SMP пропустил мимо ушей ... Видимо, потому что подсознательно понимал, что SMP здесь ни при чем.

Короче, я знаю следующее (если я не путаю, но я это уточню):
Relaxed LRU было придумано специально для кэширования одной таблицы, а точнее - псевдотаблицы, syslogs, т.е. журнала транзакций баз данных ASE. Но реализовано оно было прозрачно для всего остального сервера, поэтому ее стало возможно применять не только для журнала транзакций.

В курсах по Performance & Tuning ничего про SMP или не SMP в отношении Relaxed LRU не говорилось. Да и вообще, при оптимизации чето-то надеятся, что что-то попадет во внутренний кэш процессора как-то странно - ASE им не управляет.

Я постараюсь найти про Relaxed в материалах курса и кратко изложить здесь.

serg08
Как я понимаю никак и ничем не упорядоченную структуру и кешем назвать нельзя.
Это ничто. Всё таки какие то принципы Strict LRU должны остаться. Или это просто как буфер винчестера. Куда процессор захотел туда и записал? Что захотел то и затёр?
Ну да, типа того. Поэтому и есть требование низкой интенсивности вытеснения.
Представь себе ассоциативный массив страниц БД - вот тебе и кэш, и как список он НЕ организован, и данные неупорядочены, порядок поддерживать не надо.

serg08
1.Предполагаю что высокий уровень
попадания в КЕШ обусловлен, не в последнюю
очередь, принципом перемешения повторно(из кеша)
прочитанной страницы в начало кеша. Если бы они

Неправильно предполагаешь, т.е. это утверждение в отношении Relaxed LRU ложно.

serg08
просто затирались, то собрать и поодерживать
в кеше горячие страницы и высокое попадание
вообще не получилось бы. И после перевода в
Relaxed LRU можно будет забыть о высокой вероятности
попадания в КЕШ. А мне не хотелось бы.

Именно затираются, что и есть недостаток Relaxed.

serg08

2.Почему то назвали же LRU. Значить механизм LRU где
то присутствует.
Есть подсознательное ощущение, что тут как то задействован
механизм, который используеться для более длительного
удержания в кеше индексов и OAM страниц.Но это уже мистика.


"Если на клетке с тиграм написано "лев" - не верь глазам своим." (С) Козьма Прутков.

Короче, терпение , спокойствие, сейчас они появятся....

(см. мой след пост)

Теперь о том, как реально работает политика Relaxed LRU .

(Будем в дальнейшем называть Relaxed LRU просто "Relaxed" для краткости.)

Организация кэша, работающего по принципу Relaxed LRU

Relaxed LRU кэш организован по револьверному принципу (round-robin):
сам кэш представляет собой закольцованный связный список буферов кэша,
каждый из буферов имеет два признака :
признак недавнего использования ("recently used")

признак "грязного буфера" ("dirty"), который устанавливается, если данные в буфере
изменились и требуется сохранить их на диск.
и два указателя :

Указатель "жертвы". Он указывает на буфер, в который будет помещен
следующий читаемый блок данных.

Указатель смыва (wash marker). Он указывает на буфер, который будет
проверяться на "грязность".

Эти два указателя перемещаются по закольцованному списку буферов по кругу в одну сторону
(скажем, по часовой стрелке), но так, что расстояние между двумя указателями в количестве
буферов всегда сохраняется постоянным, и указатель смыва движется "впереди" указателя жертвы.
Буфера, попадающие между указателем смыва и указателем жертвы называются областью смыва.

Работа Relaxed кэша


0) Когда надо прочитать новую страницу, указатели одновременно перемещаются на один буфер по кругу.

1) Буфер, на который указывает указатель смыва, сбрасывается на диск (путем асинхронного ввода-вывода),
если он грязный, и признак недавнего использования этого буфера сбрасывается.

2) Буфер, на который указывает указатель жертвы, проверяется на признак недавнего использования.

3) Если буфер не был недавно использован, новая страница читается в этот буфер, замещая его.

4) Если буфер, на который указывает указатель жертвы, был недавно использован или он еще грязный,
указатели перемещаются дальше (возврат к пункту 0).

Замечание :
Здесь в пункте 4 я немного домыслил, поскольку не очень понятно, как под указателем жертвы может появиться
недавно использованный буфер, если впереди идущий указатель смыва этот признак сбрасывает, и как синхронизируется
окончание ввода-вывода, сбрасывающего грязный буфер.

Недостатки Relaxed кэша

Relaxed кэш не различает часто используемые и редко используемые страницы, у него есть только
один признак - только что использовалось или давно использовалось. Поэтому часто используемые страницы
могут вытесняться из кэша и, если они еще и изменялись, это будет приводить к лишнему вводу-выводу
при записи, помимо последующего чтения. Поэтому Relaxed кэш должен применяться только когда
вытеснение из кэша очень редкое .

Как правило, Relaxed кэш медленнее обычного для большинства нормального использования кэша
(когда оборот кэша не низкий)
Преимущества Relaxed кэша

Список буферов кэша не должен переорганизовываться для поддержания порядка MRU-LRU. Это особенно
полезно, когда вытеснение из кэша очень редкое - в переорганизации списка просто нет большой нужды.

Во многом из-за того, что не нужно поддерживать MRU-LRU-порядок, Relaxed кэш позволяет в меньшем
объеме сбрасывать кэши процессоров при переходе процессов (потоков) ASE с одного процессора на другой
в среде SMP. Поэтому использование Relaxed кэш повышает масштабируемость ASE в SMP.

Пояснение:

Когда использовать Relaxed кэш


Для именованных кэши для объектов, которые полностью влезают в кэш

В базах данных с универсальным кэшем, когда вытеснение из кэша очень мало.

Для кеширования лога (log only cache), кроме случаев, когда лог данных читается парралельно
с записью в лог. Это есть в реплицируемых базах данных (из которых идет репликация) или в базах данных,
где много отложенных UPDATE-ов (deferred updates) или очень много откатов транзакций.

Relaxed кэш приспособлен специально для работы в SMP, поэтому он более полезен при большом количестве
процессоров и менее полезен при наличии только одного или нескольких процессоров.

В завершении хочется напомнить основные принципы Performance & Tuning

прежде, чем изменять конфигурацию, проведите тщательный мониторинг

произведите изменения настроек и проведите мониторинг еще раз

сравните результаты "ДО" и "ПОСЛЕ" и сделайте выводы о нужности изменения конфигурации. Если изменения не дали положительного эффекта - верните конфигурацию обратно.

Сообщение подготовлено с использованием материалов курса Sybase "Performance & Tuning: Configuring ASE". Разрешите считать это небольшой рекламой этому курсу - он действительно этого стоит.

Кстати, положу ка я это и в FAQ !

Я рад, что тебе понравилось
:-)

serg08А может область смыва можно изменять, как и область стирки!!!!)

Я не понял, что ты называешь этими терминами. Вроде бы как это синонимы, и соответствуют английскому wash area. Так что я просто ничего не понял.

serg08
Нежесткая политика пытается избежать замены недавно использо -
страницы , но без издержек , связанных с содержанием буферов
в порядке LRU/MRU.


Ну, как бы у Relaxed LRU может это и не получаться. Оно тупо по кругу использует все буфера. Если например объем кэша достаточно мал, оно будет тереть даже только что прочитанные страницы.

serg08
Здорово я закрутил????


Нет, не здорово. Более того, я подозреваю, что ты так ничего и не понял, если это ты все про Relaxed LRU.
НЕТУ в буфере Relaxed-кэша частоты обрашения, т.е. как только буфер попадает в область
смыва, он затирается. В итоге кэш пишется тупо по очереди и по кругу.
Если будет 100 буферов в кэше, и при первом чтении мы считаем туда какую-то страницу,
то при последующих 100 чтениях (если при этом нет попадания в кэш, конечно) эта страница
гарантированно затрется другой.

Впрочем, я что-то вообще слабо понимаю то, что ты написал. К чему это все ?

Posted via ActualForum NNTP Server 1.0

Я добавил эту тему в FAQ.