Назад в раздел
BorderManager Cache Performance and Tuning.
eManual.ru - электронная документация
Оpигинал: TID2949807
From: Support.novell.com
Название: BorderManager Cache Performance and Tuning
Пеpевод: Осуществлен Дмитpием Томко (Tomko Dmitry)
E-Mail: Postmaster@mmf.bsu.unibel.by
Коppекция: Гоpохов Виталий (GSLab@email.com)
По пpосьбе: Гоpохова Виталия (GSLab@email.com) в pамках поддеpжки FAQ'а
по эхоконфеpенциям Su.net и Ru.Lan.nw
Коментаpий: См. также c_alloc.txt посвященный pазбоpу пpоблем связанных
с нехваткой/утечкой памяти.
См. также tune.txt посвященный тонкой настpойке Netware.
См. также limit.txt посвященный влиянию пpостpанств имен на
pаботу сеpвеpа.
Date: [Wed 27-10-99]
Access to: http://netware.inter.net.md
-----------------------------------------------------------------------------
В документе приводятся сведения по оптимизации и тонкой настройки вашего
сервера BorderManager
СОДЕРЖАНИЕ:
-----------
1. Патчи и драйвера.
2. Тома для кэша
2.1. Создание отдельных томов для кэша
2.2. Создание нескольких томов для кэша
2.3. Выключение компрессии
2.4. Выключение перераспределения
2.5. Установка размера блока равным 8К
2.6. Пространство имен - только DOS
3. Использование NSS томов для кэширования
4.Файлы распознования имен
4.1. NETDB.NLM /N
4.2. HOSTS
4.3. RESOLV.CFG
4.4. PXYHOSTS.*
5. Установка параметров сервера (через команду SET)
5.1. Праметры соединений
Maximum Physical Receive Packet Size = 1514
Maximum Packet Receive Buffers = 10000
Minimum Packet Receive Buffers = 5000
New Packet Receive Buffer Wait Time = 0.1 sec
Maximum Interrupt Events = 50
5.2. Память
Garbage Collection Interval = 5
5.3. Кэширование файлов
Read Ahead Enabled = on
Maximum Concurrent Disk Cache Writes = 750
Dirty Disk Cache Delay Time = 0.1 sec
5.4.Кэширование информации директорий
Dirty Directory Cache Delay Time = 0.1 sec
Maximum Concurrent Directory Cache Writes = 125
Directory Cache Allocation Wait Time = 0.1 sec
Directory Cache Buffer NonReferenced delay = 30 min
Minimum Directory Cache Buffers = 1000
Maximum Directory Cache Buffers = 4000
Maximum Number of Internal Directory Handles = 500
5.5. Файловая система
Immediate Purge of Deleted Files = on
Enable File Compression = off
5.6. Блокировки
Maximum File Locks = 100000
5.7 Параметры диска
Enable Hardware Write Back = on
Enable Disk Read After Write Verify = off
5.8. Другие параметры (из раздела Miscellaneous)
Worker Thread Execute In A Row Count = 15
Pseudo Preemption Count = 200
Minimum Service Processes = 500
Maximum Service Processes = 1000
New Service Process Wait Time = 0.3 sec
6. Установки NWAdmin
6.1. Maximum Hot Unreferenced Time = 30
6.2. Cache Hash Table Size = 256
6.3. Maximum Number of Hot Nodes = 50000
6.4. Number of Directories = 128
7.Сведения по распределению и использованию памяти
1.Патчи и драйвера.
-------------------
Скачайте или получите последние сервис-паки и драйвера. Особенно позаботьтесь
о приобретении текущих сервис-паков, апдейтов к CLIB, драйверов сетевых
карточек и дисков. Большинство необходимых файлов можно найти через
http://www.support.novell.com. Возможно потребуется сходить на сайт
производителя вашего оборудования для получения необходимых драйверов.
Перед применением тех или иных патчей или драйверов убедитесь, что вы
прочитали файл "readme",прилагающийся к нему. Хорошо ознакомьтесь с
возможными ограничениями и специальными соглашениями к этим файлам.
Например,в файле "readme" для сетевой карты могут находиться рекомендации для
максимального значения параметра Maximum Physical Receive Packet Size,
который отличаются от рекомендуемых в этом документе.
2. Тома для кэширования.
------------------------
2.1 Создание отдельных томов для кэша
Обязательное условие - используйте для кэша свой СОБСТВЕННЫЙ том-
это даст возможность BM использовать все пространство на томе для
кэширования. Это также поможет уменьшить частоту удаления с диска
наиболее неиспользованных элементов данных, когда размер свободного
пространства становится минимальным. И в конечном итоге это даст
возможность удалить и пересоздать том с новым размеров блока тома,
когда вы захотите изменить размер блока.
(BM оставляет на томе примерно 3.5 % свободного места при заполнении
кэшем)
2.2 Создание нескольких томов для кэша
Неплохим решением, если размер вашей дискового массива достаточно
большой, является использование раздельных томов для кэша. Например
дисковый массив на 8 Гб можно использовать следующим образом: на
систему (Netware+BM)- 2 Гб и организовать два тома для
кэша "Cache1:" и "Cache2:" по 3Гб.
Для задания директории и томов для кэширования, используйте Netware
Administrator. Откройте NWADMN32-Details для вашего сервера BM, далее вкладка
BorderManager Setup -> Caching -> Cache Location
Путь, который вы введете будет использован для всех заданных томов. Исходя из
того, что тома создаюся только для кэширования, можно задать путь от корня
тома, введя единственный слэш (/). Затем впишите все ваши тома для
кэширования в список томов. После сохранения изменений нажатием кнопки "OK" и
до возвращения к просмотру дерева перегрузите прокси.
Если тома для кэша, который вы указали в Netware Administrator->
->BorderManager->Setup не смонтированы, прокси не сможет загрузиться.
2.3 Выключение компрессии.
Компрессия в среде, где необходим немедленный доступ к файлам и файлы будут
предположительно иметь короткое время жизни, компpессия только снижает
производительность. Когда происходит попадание в кэш и требуется прочитать
файл с сервера, не хотелось бы, что бы сервер затрачивал время на
декомпрессию файла. Не хотелось бы также, чтобы зря терялось время на
компрессию файлов, который полностью удалены при последующем обновлении;
т.е. при создании томов выключайте компрессию.
2.4. Выключение перераспределения.
Перераспределение блоков (suballocation) - сервис, интенсивно использующий
процессор при сборке мусора на томе. Вместо того, что бы просто удалить
помеченный для этого файл, при перераспределении блок сначала считывается для
определения той его части, которая подлежит удалению, а затем
перезаписывается на диск с уже удаленной частью. На сервере, предназначенном
для кэширования файлы постоянно создаются и удаляются, поэтому сборка мусора
при перераспределении будет вызывать большую утечку производительности.; т.е.
при создании томов выключайте и перераспределение.
2.5 Установка размера блока равным 8К.
При выключенном перераспределении блоков и большом размере блока на томе
появляется большое количество неиспользованного пространства. Размер блока
должен быть немногим больше среднего размера файла на томе. Начните с 8К.
После некоторого времени работы кэша вычислите средний размер файла на томе,
где находиться кэш и установите размера блока равным ближайшему большему
значению для блоков (т.е. если получили 15.2, то 16К)
(Вот когда вы обрадуетесь тому, что создали кэш на отдельном томе)
2.6 Пространство имен.
Каждый том для кэша должен иметь только DOS - пространство имен, Для кэша не
используются другие пространства. Вне зависимости от действительного имени
кэшируемого объекта, кэш-файлы хранятся в нотации 8+3 и создаются при
использовании хэш-алгоритма. Загрузка остальных пространств ведет к излишней
трате вхождений директорий и других ресурсов.
3. Использование NSS томов для кэширования.
-------------------------------------------
Если вы использование NSS тома для кэширования, вы ДОЛЖНЫ увеличить
кэш-баланс, как указано в "readme" для BorderManager. Фактически, вы можете
увеличить его установив равным 60-75%. Данный параметр соответствует проценту
кэш-буферов от их общего числа, которые будет использовать NSS для своего
кэширования. Требуется, чтобы определенный процент кэш-буферов был доступен
для использования не-NSS томам и распределения памяти модулей системы.
Например, использовании томов NSS можно указать в autoexec.ncf параметр
загрузки NSS
LOAD NSS /cachebalance=65
Другие параметры NSS могут быть использованы для улучшения производительности
- они могут меняться в зависимости от инсталляции, конфигурации кэша и его
использования
4.Файлы распознавания имен.
---------------------------
4.1. NETDB.NLM /N
BM использует не только NETDB для разрешения имен DNS, он имеет свой
собственную систему распознавания. Однако при загрузке прокси просматривает
NETDB на предмет уже распознанных имен для заполнения своего собственного DNS
кэша. т.е. когда BM инсталлируется, он не создает никаких обработчиков
Unix-сервисов.
По умолчанию, NETDB делает проверку каждые 10 сек в NDS на предмет
обработчика Unix - сервисов. Данная операция использует вызовы NDS и
создает/удаляет временный файл, т.е. если у Вас нет обработчика Unix -
сервисов, этот процесс тратит впустую драгоценные ресурсы и некоторый выигрыш
может быть получен при его отключении. Если вы не используете Netware NFS или
Unix Print Services, то в autoexec.ncf до загрузки conlog загрузите NETDB,
используя /N для предотвращения 10 секундных проверок.
Просмотрите следующие TID-ы ,относящиеся к NETDB:
2937176 NetDB library loaded without logging into NDS
2936136 NetDB - What is it?
4.2. файл HOSTS.
При загрузке прокси заполняет свой DNS - кэш вхождениями из файла
SYS:ETCHOSTS. Очистите этот файл, от серверов, к которым вы не обращаетесь
(многие сервера указаны для примера). Файл HOSTS должен содержать по крайней
мере вхождения для localhost loopback и самого сервера. При загрузке прокси
происходит чтение этого, как часть процесса построения DNS кэша и в некоторых
версиях прокси мог не загрузиться при отстутствии данного файла.
Например, если имя вашего сервера "Gonzo" и ваш IP-адрес - 172.17.1.8, ваш
файл HOSTS может выглядеть следующим образом:
127.0.0.1 localhost loopback
172.17.1.8 gonzo
4.3. файл RESOLV.CFG
Прокси использует файл RESOLV.CFG для определения имеющихся для разрешения
имен DNS-серверов. Подчистите SYS:ETCRESOLV.CFG. Этот файл должен содержать
одну строчку с указанием вашего домена и по строчке для каждого DNS-сервера.
Удалите строчки, которые не соответствуют DNS-серверам, определенные здесь
сервера должны быть быстрыми и доступными.
Прокси начинает проверку серверов с первого встретившегося, поэтому наиболее
близкий, быстрый и доступный сервер должен быть описан первым, а самый
недоступный и медленный сервер должен быть описан в конце или вообще убран из
списка серверов.
4.4. файл PXYHOSTS.*
Каждые 10 минут функционирования прокси перезаписывает файл SYS:ETCPXYHOSTS.
Этот файл является текущим дампом кэша DNS. При следующей загрузке прокси
читает его и перестраивает в памяти DNS-кэш. Чтение данного файла невозможно
при сбросе дампа в него, он доступен только когда прокси уже загружен.
Если Вы предполагаете, что ваш DNS-кэш испорчен, то выгрузите прокси и
удалите данный файл, перезагрузив прокси. Но делайте это только при
необходимости, т.к. DNS-кэширование сберегает много времени, которое ушло бы
на распознавание. Не хотелось бы, чтобы сервер снова начал-бы перестрайку
этого файла-кеша.
5. Параметры сервера (через команду SET)
----------------------------------------
Файл-сервер использует устанавливаемые параметры для конфигурации различных
сервисов, тайм-аутов и т.д. Путь, по котоpому вы шли пpи настpойке
доступа к файлам (основной сервис) отличается от способов, когда
сервер настраивают для кэширования. В этом случае для кэширования отводится
максимум ресурсов.
Помните: даный документ - точка для старта и требует уточнения с точки зрения
ваших требований и конфигурации.
Некоторый версии Netware 4 или Netware 5 могут иметь различные максимальные и
минимальные значения параметров, различные настроечные параметры, который
перечислены здесь. При установке этих параметров, особенно для Netware 5
рекомендуется использовать monitor.nlm - это поможет убедиться, что значения
параметров установлены правильно и в нужном месте.
Примечание:
при использовании NSS томов для кэширования, лучшая настройка
производительности может быть получена путем улучшения NSS -
- параметров, а не путем улучшения файловых и дисковых
параметров, описанных ниже.
5.1. Параметры соединений (Communications)
Maximum Physical Receive Packet Size = 1514
Данное значение соответствует максимально возможному размеру пакета для
интерфейса сервера. 1514 - значение для сетей Ethernet, при использовании WAN
-соединений этот параметр должен быть 1524. Требуется также, чтобы данное
значение было различным для различных типов интерфейсов. Данное значение
соответствует количеству байт, которое резервируется для каждого пришедшего
пакета и используется при выделении буферов под пришедшие пакеты (packet
receive buffers).Не использованные байты будут накапливаться - например если
приходится по 10 лишних байт на каждый буфер и уже выделена память под 10,000
приемных буферов, то потери составляют 100,000 байт, которые могли бы быть
использованы для кэширования.
Maximum Packet Receive Buffers = 10000
Значение соответствует максимальному количеству буферов приема (packet
receive buffers). При задании значений возможен несложный подсчет:
возможная, по максимуму используемая память, под буферы приема pавна:
Maximum Physical Receive Packet Size * Maximum Packet Receive Buffers
- так что держите себя в рамках, плз.
Minimum Packet Receive Buffers = 5000
Значение соответствует минимальному количеству буферов приема (packet receive
buffers), выделение которых происходит сразу же при загрузке системы.
После установки этого значения, последите за количеством Packet Receive
Buffers.
Если количество буферов приема много больше данного значения, увеличьте его
до величины 500+текущее значение используемых. Если наоборот, значение
никогда не достигается и вероятно не будет никогда достигнуто, попробуйте
уменьшить его на 500. Конечным результатом значения Minimum Packet Receive
Buffers является величина приблизительно равная 500+максимально достигнутое
количество буферов приема.
New Packet Receive Buffer Wait Time = 0.1 sec
Промежуток времени, в течение которого сервер ждет, чтобы убедиться что буфер
приема освободился, прежде чем он снова его выделит для другого пакета.
Maximum Interrupt Events = 50
Максимальное количество допустимых событий "пpеpывание от таймеpа", дающее
гарантию, что переключение "нити" произошло.
(У меня есть один ответ от поставщика, котоpый установил это значение
большим чем 170. )
5.2. Память
Garbage Collection Interval = 5
В системе кэширования, столь долгое ожидание сборки мусора может вызвать
нехватку памяти в нужный момент, даже если она освободиться в следующий
момент. Однако, если установить данный параметр слишком коротким, сборка
мусора будет происходить слишком часто, расходуя ресурсы процессора.
5.3. Кэширование файлов (File Caching)
Read Ahead Enabled = on
Данная опция включена по умолчанию.
Maximum Concurrent Disk Cache Writes = 750
Если вы заметили, что количество отложенных кэш-буферов (Dirty Cache Buffers)
растет и само быстро не уменьшается до значения, пропорционального Current
Disk Request, то попробуйте увеличить это значение.
Dirty Disk Cache Delay Time = 0.1 sec
Задает более быструю запись отложенного дискового кэша на диск
5.4. Кэширование информации директорий (Directory Caching)
Dirty Directory Cache Delay Time = 0.1 sec
Задает более быструю запись отложенного кэша директорий на диск
Maximum Concurrent Directory Cache Writes = 125
Добавьте 100 для каждого дополнительного диска в массиве (максиум 500). Если
Concurrent Disk Requests непропорционально выше, чем Dirty Cache Buffers,
уменьшите этот параметр (не опускайтесь ниже 75).
Directory Cache Allocation Wait Time = 0.1 sec
Для уменьшения задержки выделения памяти под кэш диркторий.
Directory Cache Buffer NonReferenced delay = 30 min
Хотелось бы, чтобы кэш директорий оставался в памяти дольше времени,
предотвращая тем самым, повторные запросы к диску для одних и тех же данных.
Minimum Directory Cache Buffers = 1000
Под данные кэш-буферы директорий- память при загрузке системы не выделяется,
как например, под буферы приема. Вместо этого, когда требуется новый
кэш-буфер, если количество уже выделенных кэш-буферов ниже этого числа, он
выделяется без учета времени ожидания. После некоторого времени эксплуатации
системы, установите значение этого параметра равным примерно максимальному
значению этого параметра в ходе эксплуатации.
Maximum Directory Cache Buffers = 4000
Если количество выделенных кэш-буферов директорий близится к этому
максимальному значеню, попробуйте увеличить его на 500. Если наоборот,
значение никогда не достигается и вероятно не будет никогда достигнуто,
попробуйте уменьшить. Конечным результатом значения этого параметра является
где-то 500+максимально достигнутое за время работы значение.
Maximum Number of Internal Directory Handles = 500
Внутренние дескрипторы директорий используются как прокси, так и другими
NLM-ми, запущенными на сервере.
5.5. Файловая система
Immediate Purge of Deleted Files = on
Если сервер используется только под BM -установите данный параметр. Если же
он используется и для других приложений или для доступа к файлам - установите
его в Off
Enable File Compression = off
Если сервер используется только под BM -снимите данный параметр. Если же он
используется и для других приложений или для доступа к файлам - установите
его.
5.6.Блокировки (Locks)
Maximum File Locks = 100000
Включает в себя как блокировки прокси, так и всех остальных модулей системы
5.7 Параметры диска
Enable Hardware Write Back = on
Если ваше оборудование поддерживает данную особенность - включите ее.
Enable Disk Read After Write Verify = off
Как правило, при современном оборудовании это уже не требуется и поддержка
этой особенности ведет утечке производительности.
5.8. Другие параметры (из раздела Miscellaneous)
Worker Thread Execute In A Row Count = 15
Число, показывающее сколько раз кряду планировщик будет запускать новое
задание перед тем, как разрешить работу других "нитей"
Pseudo Preemption Count = 200
Допустимое количество вызовов записи/чтения для "нитей" перед тем как
передать управление.
Minimum Service Processes = 500
Каждый запрос, который получает прокси порождает нить WorkToDo, используя
сервисный процесс. Не плохо было с самого начала выделить память под
достаточное количество сервисных процессов, чтобы обеспечить потребности в
них при пике нагрузки. Для начального значения подойдет 500. Если видим, что
максимальное значение, достигнутое на системе больше данного и растет,
пробуем увеличить данный параметр на 100. Делаем так до того момента, пока
значение данного параметра не бует на 50 больше, чем в моменты пиковой
загрузки сервера.
Maximum Service Processes = 1000
Значение соответствует максимально устанавливаемому количество сервисных
процессов.
В среде web-кэширования нити подвергаются постоянному распределению и
сервисные процессы используются в реальном времени, не хотелось бы достигнуть
пределтного количества сервисных процессов. Работа при нехватке сервисных
процессов вызовет сбой сервера.
New Service Process Wait Time = 0.3 sec
Если вы заметили, что ваши сервисные процессы в ступоре и закрываются-
- увеличьте слегка этот параметр.
6. Установки в NWAdmin.
-----------------------
Изменяйте приведенные ниже параметры в Nwadmin32. Параметры могут
варьироваться для различных версий BM
Помните: даный документ - точка для старта и требует уточнения с точки зрения
ваших требований и конфигурации.
6.1. Maximum Hot Unreferenced Time = 30
Настройка данного параметра зависит от инсталляции. Увеличение параметра
соответствует более длительному хранению объекта в "горячем" кэше. Неплохо
установить его равным Directory Cache Buffer NonReferenced Delay (секция
5.4).
6.2. Cache Hash Table Size = 256
Размер хэш-таблицы. Для наиболее загруженных серверов увеличение этого
параметра улучшит производительность с большимим кэш-томами. Попробуйте 256K
6.3. Maximum Number of Hot Nodes = 50000
Данный параметр может улучшить производительность для наиболее загруженных
серверов с большим количеством оперативной памяти путем увеличения его до
50000.
6.4. Number of Directories = 128
Number of Directories может поднять производительность путем
увеличения количества директорий. Исходя из того, что отдельные директории
содержат в себе большое количество файлов, то для такой директории
хэширование по таблице, занимает много времени. Лучше больше директорий с
меньшим количеством файлов, чем много файлов с меньшим количеством
директорий. Попробуйте увеличить данный параметр до 128.
7. Сведения по распределению и использованию памяти
---------------------------------------------------
Память - очень критичный элемент для прокси. Если вы работаете с небольшим
количеством памяти, то что могло бы быть найдено в "горячем" кэше будет
найдено в дисковом. Обращаться к диску, конечно, быстрее чем в Internet, но
значительно медленнее оперативной памяти .
Во-первых, выгрузите все неиспользуемые модули. Другой вещью, которую нужно
сделать, это перенести все сервисы, кроме прокси ( например web или email) на
другие, предназначенные для них сервера - это позволит кеш-серверу
использовать большее количество pесуpсов, что тут-же должно сказаться на
пpоизводительности.
Следите за параметром LRU Sitting Time в monitor.nlm (Cache Utilization
Statistics) - После некоторого времени работы сервера оно должно быть в
районе 15 минут. При меньшем времени, добавьте памяти. Также следите за
параметром Available Cache Buffers (Server Memory Statistics) - оптимальное
значение: 30% м. и выше, при меньшем значении - добавьте память.
Количество и размер буферов, которые выделил ваш сервер, влияют на заполнение
памяти. Выделение памяти под кэш - буферы директорий и буферы приема большие,
чем требуется, будет попусту расходовать память. Каждый сервисный процесс
занимает 16К памяти, каждый буфер директорий - 4К, а каждый буфер приема -
1514 байт (или то количество, которое вы определили параметром maximum
physical packet receive buffer).
Отличные от DOS пространства имен, находящиеся на томе, требуют больше
кэш-буферов директорий (Directory Cache Buffers) для кэширования информации
из файла на данном томе. Исходя из этого, на томах для кэширования,
устанавливайте, только пространство имен DOS.
Имена файлов, создаваемые хэш- алгоритмом не требуют LONG пространства имен.
|
|
 |
|
