proNovell

То ли я чего не понимаю, то ли это погрешности перевода?

В общем сервер 5.0. Монитор. Статистика использования кэш-памяти. Хелп. И есть в этом хелпе такие слова:

<pre>Выделено блоков:
Совокупное количество запросов к дисковым
кэш-блокам, сделанных с момента запуска
или перезапуска сервера.

Это значение представляет собой сумму
значений "Выделено из AVAIL" и "Выделено
из LRU". Если значительно больше значение
"Выделено из AVAIL", то в сервере
достаточно памяти для кэша. Если велико
значение "Выделено из LRU", нужно
увеличить оперативную память для кэша.</pre>

Теперь представим такую картину - uptime сервера много больше вермени установки LRU. Все кэши кроме резервированных забиты некоей инфой - любое обращение либо пойдет в кэш, либо потребует выделения кэша... откуда? из LRU есссно, с какого бы перепугу AVAIL трогать...

Вот скажем конкретная статистика (uptime сервера - 450 дней):

<pre>Попадания в краткосрочный кеш: 100%
Попадания в грязный краткосрочный кеш: 100%
Попадания в долгосрочный кеш: 94%
Попадания в грязный долгосрочный кеш: 99%
Время установки LRU: 2:28:07.9
Выделено блоков: 145 044 804
Выделено из AVAIL: 2 903 557
Выделено из LRU: 142 141 247</pre>

Как видим, "Выделено из LRU" на 2 порядка больше, и по хелпу вроде надо бечь в магазин за мозгами... однако по всему остальному все просто прекрасно и шоколадно... 94% попадания в долгий кэш - результат ночного бэкапа (99% -> 96%) плюс утреннего обновления Консультант-плюс(96% -> 94%).

Там же сказано, что из LRU-кеша берутся блоки только тогда, когда остальные кеши недоступны.
ХЗ, но у меня картина аналогичная - из LRU берется гораздо больше и памяти по всем показателям предостаточно. Тоже на 5.0

Влад А.Сокол aka Akina писал(а):Вот скажем конкретная статистика (uptime сервера - 450 дней):

<pre>Попадания в краткосрочный кеш: 100%
Попадания в грязный краткосрочный кеш: 100%
Попадания в долгосрочный кеш: 94%
Попадания в грязный долгосрочный кеш: 99%
Время установки LRU: 2:28:07.9
Выделено блоков: 145 044 804
Выделено из AVAIL: 2 903 557
Выделено из LRU: 142 141 247</pre>

Очень похожая картина и у нас наблюдается.

Теперь представим такую картину - uptime сервера много больше вермени установки LRU. Все кэши кроме резервированных забиты некоей инфой - любое обращение либо пойдет в кэш, либо потребует выделения кэша... откуда? из LRU есссно, с какого бы перепугу AVAIL трогать...

Вроде, по логике, так и должно быть?
Я наблюдал развитие ситуации сразу после запуска сервера и т.д. Сначала рос параметр "from AVAIL", а "from LRU" оставался в нуле. Далее, после достижения первым определенного значения, начался рост "from LRU", а "from AVAIL" увеличивался весьма незначительно. Ну, а потом "from LRU" уходил далеко вперед. Тем не менее, другие параметры вроде как в норме: LRU sitting time порядка нескольких суток, Long Term Cache Hits потихоньку росло и доросло до 98%.

Василий Андреев

Я наблюдал развитие ситуации сразу после запуска сервера

Вот и у мя то же... Значит все-таки перевод кривой.

Нет, перевод-то, похоже, адекватный:
If the value of Allocated from AVAIL is much higher, the server has sufficient RAM for cache. If the value of Allocated from LRU is high, install more RAM for cache.

Может, корифеи все-таки просветят, в чем дело?

Василий Андреев
Ну тады хельп кривой... не может же быть чтобы хелп писАлся для исключительно первых минут работы сервера...

Хм... А если предположить, что

....хелп писАлся для исключительно первых

версий NW ?
Тогда это было актуально, соответствовало объективной ревльности, испрвалялось соответственно. А потом пошла гонка версий, новые технологии, новые объемы данных .... ну и руки не доходят переписать и новые рекомендации дать... А может они там, у себя, в тестовых лабораториях, и не знают, что теперь рекомендовать, а?
Такое вот ИМНО.

Касательно старых версий: в NW3.11 мне не удалось найти какого-либо упоминания LRU (может, плохо искал?).

Вот, кстати, еще информация для размышления. По поводу параметра Long Term Dirty Cache Hits в хелпе написано:

"If this value is high or steadily incrementing, add more RAM for cache ".

У Влада этот параметр - 99%, у нас - столько же. Опять возвращаемся к констатации факта о малом количестве памяти?

Кстати, может кто просветит насчет грязного кэша?

"Dirty cache must be written to disk before being used".

Формально - все понятно. А практически это как?

Пусть, например, один клиент считал файл , а другой - его через некоторое время изменил. В этом случае "механизм грязного кэша" работает или как?

Формально - все понятно. А практически это как?

А практически вот как - грязный буфер должен быть записан на диск, прежде чем он сможет быть использован для кэширования ДРУГОГО блока данных.

один клиент считал файл , а другой - его через некоторое время изменил. В этом случае "механизм грязного кэша" работает или как?

Если этот кэш уже сброшен на диск -он не грязный. Он будет изменен и помечен как грязный. Плюс один к "Попадания в краткосрочный кеш:" Если НЕ сброшен - он будет изменен, и пометка о его "грязности" останется. Плюс один к "Попадания в краткосрочный кеш:" и к "Попадания в грязный краткосрочный кеш:". Все нормально...

Помнится, меня в свое время тоже несколько озадачил этот хелп ( на английском ). На что я тогда сказал себе "фигня какая-то" - и поехал дальше. Вообще, вроде больше нигде в документации ( имеется в виду не встроенный хелп в MONITORe, а реальная дока и статейки типа Performance Tuning and Optimization ) не ссылаются именно на эти параметры ( from AVAIL и from LRU ), а все больше на значение LRU sitting time - которое, по их же рекомендациям, по памяти не должно быть меньше 15 мин ? Встречаются даже перлы типа, что если оно у вас стабильно сильно больше, то .. you may consider taking some memory out and using it somewhere else ..

Встречаются даже перлы типа, что если оно у вас стабильно сильно больше, то .. you may consider taking some memory out and using it somewhere else ..

Йес!

AVAIL - свободная память сразу после загрузки. Ессесно, пока она есть, то берется оттуда. В процессе работы она вся задействуется и становится "from LRU". И потом все блоки берутся уже из ранее выделенных. Большое их количество говорит об интенсивном использовании памяти (ну это смотря за какой промежуток времени). Поэтому все в норме, пока у вас долговременные кеши более 90%. Простой пример: чтобы у вас все было из AVAIL, то нужно в сервер памяти напихать столько, сколько нужно ОС, всем прогам и плюс весь объем дискового пространства, чтоб все диски в кэш поместились. Такого еще долго не будет, так как диски все равно дешевле.
Теперь про лишнюю память. Действительно, если LRU очень большой, то серверу хватает памяти с ИЗБЫТКОМ для ДАННОЙ КОНКРЕТНОЙ работы. И действительно, избыток можно использовать с большЕй пользой где-то еще (но кто память из сервера по своей воле отдаст? :-) ). Серевер NetWare эффективно работает при LRU более 10 минут. В подавляющем количестве случаев этого достаточно.

Павел Гарбар
избыток можно использовать с большЕй пользой где-то еще (но кто память из сервера по своей воле отдаст? )
На самом деле даже если отдаст - куда ты ее пихнешь? этого ЕСС-шного монстра? ради любопытства пробовал - поставил в рабстанцию... не включаем ЕСС в БИОСе - не проходит тест памяти, сбой дает на каком-то там адресе, включаем - не проходит тест первых 64 кБ (не инитится модуль вообще)... вернул в сервер - живет уже год и не жалуется.