Назад в раздел
Performance, Tuning and Optimization
|
eManual.ru - электронная документация
Секция 1 из 2 - Предыдущая - Следующая
Оpигинал: TID2943356 и TID2943472
From: Support.novell.com
Название: Performance, Tuning and Optimization
Пеpевод: Осуществлен Сеpгеем Агаpковым (Serg Agarkoff) Fidonet: 2:5041/1
(0803@03100000.mhs.rosmail.com)
Коppекция: Алексей Белозеpов (Alex Belozuerov) FidoNet: 2:5014/1.1
По пpосьбе: Гоpохова Виталия (GSLab@email.com) в pамках поддеpжки FAQ'а
по эхоконфеpенциям Su.net и Ru.Lan.nw
Коментаpий: См. также Btlneck.txt, где конспективно описаны именно методы
обнаpужения и советы по устpанению пpичин, пpиводящих к потеpе
пpоизводительности сеpвеpа.
См. также BMPerf.txt посвященный настpойке proxy сеpвеpа
на базе пpодукта "Border Manager".
Date: [Thu 03-06-99],[Thu 10-06-99]
Access to: http://netware.inter.net.md
-----------------------------------------------------------------------------
Производительность, Настройка и Оптимизация - часть 1 и 2
(Последние изменения: 03MAY1999)
Суть вопроса:
TID2943356 и TID2943472 раскрывают различные аспекты оптимизации
производительности вашего сервера, а также вопросы профилактики.
Описанные здесь меры способствуют предотвращению авостов и сбоев сервера.
В TID2943356 и TID2943472 затронуты следующие области:
1. MONITOR.NLM и утилизация
2. "Заплатки" к операционной системе и прочие обновления NLM
3. NDS и DS.NLM
4. Сервисные процессы
5. Upgrade Low Priority Threads (обновлять низкоприоритетные потоки)
6. LRU Sitting Time (время жизни наиболее редко используемых)
7. Physical Packet Receive Buffers (физические буферы для приема пакетов)
8. Packet Burst (ускорение пакетов)
9. Cache Buffers (буферы кэша)
10. Dirty Cache Buffers (ожидающие буферы кэша) и Current Disk Requests
(сейчас запросов к диску)
11. Host Bus Adapters (адаптеры главной шины), Mirroring (зеркалирование)
и Duplexing (дублирование).
12. Directory Caching (кэширование каталогов)
13. Block Suballocation (выделение субблоков)
14. Disk Block Size (размер блока на диске)
15. Hotfix Blocks (блоки горячего резерва)
16. Влияние подвыделения (suballocation) на количество свободных блоков и
место на диске для каждого тома
17. Сжатие файлов
18. Расширение файлов
19. Read After Write Verification (проверка записи чтением)
20. Сгребание мусора
21. Имитация сбоя чтения/записи и ошибочные указатели
22. Выделение и настройка прерываний
23. Set Reserved Buffers Below 16 Meg (резервирование буферов в первых 16М памяти)
24. AppleTalk
25. Печать
1. MONITOR.NLM и утилизация
---------------------------
Параметр "utilization" не является "истиной в последней инстанции".
Некоторые серверные процессы вызывают функции NetWare CyieldWithDelay или
CyieldUntilIdle. Если есть поток, находящийся в состоянии ожидания, и
выполняющий эти функции, то сервер может казаться очень загруженным.
В данном случае утилизация будет подсчитана неаккуратно. Не волнуйтесь, если
она на короткое время подскакивает до 100% - это нормально для всех
серверов 4.10.
2. "Заплатки" к операционной системе и прочие обновления NLM
------------------------------------------------------------
Примените "заплаты" как из 410PTx.EXE, так и из 410ITx.EXE. Они решают
проблемы, приводящие к сообщениям о ненормально высокой утилизации. Кроме
того, эти "заплаты" исправляют и множество других проблем. Своевременное
применение всех "заплат" избавит вас от будущей головной боли.
Для IntranetWare или NetWare 4.11, используйте комплекты поддержки (support
packs) с именами IWSPx.EXE. Для NetWare 5, используйте комплекты поддержки
NW5 с именами файлов NW5SPx.EXE. Пакеты поддержки содержат не только заплаты
для ОС, но и все необходимые дополнения и улучшения серверных NLM. (На данный
момент последняя версия заплат к NW410 - 410PT8B.EXE и сервиспак IWSP6.EXE.)
Заплаты OS исправляют проблемы с SERVER.NLM или LOADER.EXE. Выпущены
исправления и к другим модулям, например, к CLIB.NLM, для решения проблем,
приводящих к высокой утилизации. Обновления модулей не просто исправляют
старые ошибки, но и добавляют модулям новые возможности. Постарайтесь, чтобы
на вашем сервере были применены самые свежие обновления.
Чтобы получить последние обновления и заплаты, посетите web-страницу
support.novell.com. Рекомендуется применять все последние заплаты и
обновления, указанные в минимальном списке заплат (minimum patch list),
находящемся на http://support.novell.com/misc/patlst.htm.
Разумеется, надо использовать свежайшие драйвера для дисков и сетевых карт,
предлагаемые поставщиками оборудования.
3. NDS и DS.NLM
---------------
Обновите DS (службу каталогов) до версии 4.89a или более поздней для NW4.10.
Служба поддержки Novell получала сообщения о том, что более младшие версии
вызывали проблемы с утилизацией, а версия 4.89a решает их все. (На данный
момент последняя версия DS.NLM для NW410 - 5.15, а для NW411 - 6.02)
Правильная разработка дерева, разбиение на разделы и настройка репликации
играют важную роль в борьбе с проблемами утилизации. При отсутствии
надлежащего управления, размер, тип и количество реплик разделов могут
привести к проблемам утилизации. Проверьте и общее количество объектов NDS,
расположенных в разделах данного сервера. DS должна поддерживать
синхронизацию всех серверов в кольце реплик. Чем больше реплик, тем выше
служебный траффик в сети. Novell рекомендует иметь не менее трех реплик
каждого раздела в дереве, что обеспечивает достаточную устойчивость перед
сбоями и позволяет DS исправлять повреждения, если происходят нарушения базы
данных.
4. Сервисные процессы
---------------------
Сервисные процессы - это потоки (threads), которые отвечают на поступающие
запросы на обслуживание. NetWare 4.X способна выполнять до 1000 сервисных
процессов. Установите максимальное количество сервисных процессов (maximum
service processes) по 2-3 на соединение. Рекомендуется сразу установить
Maximum Service Processes в 1000 (максимально разрешенное значение). Если
серверу не нужны дополнительные процессы, он не будет их создавать. Можно
также установить время ожидания нового сервисного процесса (new service
process wait time) в 0.3 (по умолчанию стоит 2.2).
Обратитесь к HIGHUTL1.EXE за дополнительными сведениями о сервисных
процессах и о том, как быстро увеличить их количество до
нужного.
5. Upgrade Low Priority Threads (обновлять низкоприоритетные потоки)
--------------------------------------------------------------------
Убедитесь, что SET UPGRADE LOW PRIORITY THREADS = OFF. Если эта установка
имеет значение ON, то она будет вносить немалый вклад во все возможные
проблемы утилизации. Этот параметр не применяется к серверам NW5.
6. LRU Sitting Time (время жизни наиболее редко используемых)
-------------------------------------------------------------
Подсистема кэширования файлов NetWare суть набор 4К страниц памяти. После
загрузки OS, системных и прикладных NLM, NetWare распределяет всю оставшуюся
память под файловый кэш. В начале списка находится "голова", где в список
вставляются новые буферы кэша. Конец списка называется "хвостом", откуда
вычеркиваются удаляемые из списка буферы. Каждый буфер связан с последующим
и имеет отметку времени, показывающую, когда он был вставлен в голову
списка.
Когда сервер получает запрос на ввод/вывод данных с диска, которых в данный
момент нет в кэше ("промах", cache "miss"), данные читаются с диска и
помещаются в один или несколько буферов, которые удалены из хвоста списка.
Каждый вновь заполняемый буфер "штемпелюется" текущим временем и
подключается в голову списка. Такой буфер называется "только что
использованным" (most-recently-used, MRU) буфером, поскольку он находится в
кэше минимум времени.
"Попадание" в кэш (cache "hit") - частое явление в среде NetWare,
происходящее, когда затребованные данные берутся не с диска, а из кэша. В
таком случае буфер, в котором находились нужные данные, удаляется из хвоста
списка, "штемпелюется" текущим временем и вновь привязывается к голове
списка. Таким образом самые часто используемые буферы собираются (SA:
"кучкуются") в голове списка. Эта характеристика списка очень важна,
поскольку вы, наверняка, хотите, чтобы самые используемые данные оставались
в кэше для повторных к ним обращений.
В какой-то момент времени файловый кэш заполняется недавно нужными данными.
Тогда говорят о "давно не использованных" (least-recently-used, LRU)
буферах. LRU-буферы, это такие буферы, которые были загружены в кэш, но не
использовались так часто, как MRU-буферы, находящиеся в голове списка.
Благодаря переподключению MRU к голове списка, LRU собираются в его хвосте.
Когда требуется создать новые буферы, но для них уже нет свободного места,
NetWare удаляет нужное количество самых старых LRU из хвоста списка,
заполняет их новыми данными, штемпелюет и привязывает к голове списка.
Таким образом, система кэширования NetWare отдает предпочтение часто
используемым данным, сохраняя память для старых данных только до тех пор,
пока она не понадобится под новые.
Идеальным сценарием при настройке кэша был бы такой, при котором любой
запрос на часто используемые данные мог бы выполнен только за счет
кэш-памяти. Этого можно добиться увеличением оперативной памяти
сервера.
Статистика LRU Sitting Time вычисляется как разность между текущим временем
и отметкой времени самого старого LRU. LRU Sitting Time обозначает время,
требуемое на переход буфера из головы списка, где он называется MRU, в
хвост, где он становится LRU. Можно назвать ее "скоростью вращения кэша",
поскольку благодаря промахам или попаданиям в кэш каждый буфер будет
повторно использован за этот период времени. Оптимальная "скорость" не
должна быть меньше 15 минут. Если она меньше, то наращивайте память.
7. Physical Packet Receive Buffers (физические буферы для приема пакетов)
-------------------------------------------------------------------------
Приемные буферы используются для хранения входящих пакетов из каждой сети,
подключенной к серверу NetWare. Максимальный размер физического буфера для
приема пакетов (Maximum Physical Receive Packet Size) должен быть установлен
в соответствии с типом используемой сети. Обычно достаточно: 1524 байта для
сегментов Ethernet segments, 4540 байт для Token-Ring и FDDI, и 618 байт для
Arcnet и LocalTalk. Эти значения взяты из руководства "Novell BorderManager
Installation and Setup", глава "Installing Novell BorderManager", стр. 9.
Некоторые продукты предъявляют свои специфические требования, так что вам
может понадобиться обратиться к руководствам по этим продуктам для получения
конкретных инструкций.
Считается хорошим тоном выделять как минимум по 2-3 приемных буфера на
соединение, а как максимум - 4000 или больше.
Проверьте и информацию о нехватке блоков управления событиями (No ECB (Event
control block) Available Count) в разделе "информация LAN/WAN" (LAN/WAN
Information) модуля MONITOR.NLM. Эти сообщения обозначают, что сервер не
смог получить необходимое число буферов для приема пакетов, обычно
называемых блоками управления событиями (event control blocks (ECB).
Исчерпание ECB не является фатальной проблемой. Серверы, работающие
несколько дней, могут периодически, в моменты пиковых нагрузок, исчерпывать
имеющиеся ECB, что вынуждает систему генерировать соответствующие сообщения.
Если такие сообщения выдаются только в редкие моменты пиковых нагрузок,
оставьте все как есть - пусть себе изредка выскакивает это сообщение.
С другой стороны, если память вашего сервера сильно загружена и вы часто
получаете сообщения об ошибках выделения ECB, вам надо бы увеличить
максимальное количество ECB. Вставьте в AUTOEXEC.NCF следующую команду:
SET MAXIMUM PACKET RECEIVE BUFFERS = количество
Имейте в виду, что память, выделенная под ECB не может использоваться для
других целей. Минимальное количество приемных буферов может быть установлено
и в STARTUP.NCF следующей командой:
SET MINIMUM PACKET RECEIVE BUFFERS = количество.
Если нынешнее количество приемных буферов регулярно превышает минимальную
настройку на более или менее постоянную величину, установите минимальную
величину в текущее значение параметра Packet Receive Buffers.
8. Packet Burst (ускорение пакетов)
-----------------------------------
Служба технической поддержки Novell получала сообщения о проблемах с
утилизацией, вызванных ускорением пакетов как в клиенте NetWare, так и в
клиенте Microsoft. Большая часть этих проблем решается применением новой
заплаты для OS, или новым реквестером. Загрузите необходимые заплаты для OS
и достаньте новый FIO.VLM, который исправляет проблему с реквестером от
Novell. Файл называется VLMFX3.EXE. (Текущая версия VLM - 1.21)
Устранение неполадок:
В службе технической поддержки Novell имеется модуль PBRSTOFF.NLM, который
запрещает ускорение пакетов со стороны сервера. Модуль должен загружаться
при запуске сервера, поскольку ускорение пакетов будет запрещено только для
тех соединений, которые были установлены после загрузки модуля. Таким
образом можно выявить проблемы утилизации, возникающие из-за ускорения
пакетов.
9. Cache Buffers (буферы кэша)
------------------------------
При загрузке сервера вся свободная память выделяется под файловый кэш. При
запросе памяти другими ресурсами, например буферами для кэширования
каталогов, количество буферов файлового кэша уменьшается. Операционная
система не сразу "кидается" выделять новые ресурсы при получении запроса.
Вместо этого система ждет некоторое заданное время, чтобы увидеть, не
освободились ли какие-нибудь из ранее выделенных ресурсов запрошенного типа.
Если есть освобожденные ресурсы, то система использует их повторно и не
выделяет новых. Такая временная задержка гарантирует, что случайные пики
повышенной активности не приведут к постоянному выделению ресурсов,
надобность в которых отпадает очень быстро. Операционная система динамически
конфигурирует следующие параметры.
Directory cache buffers
Disk elevator size
File locks
Kernel processes
Kernel semaphores
Maximum number of open files
Memory for NLMs
Router/server advertising
Routing buffers
Service processes
TTS transactions
Turbo FAT index tables.
Грубо говоря, если остается меньше 40% буферов кэша, что можно посмотреть в
MONITOR.NLM, Resource utilization, то на сервере надо наращивать память.
Такой процентаж использовался многие годы, когда средняя система имела от
16MB до 32MB, а современные системы имеют гораздо больше буферов (но и
подвергаются большим нагрузкам). Например, 40% от 32MB будет 12 MB, а 40% от
1024MB будет 409 MB. Поэтому мы и ведем речь о процентах а не об абсолютном
количестве.
Падение производительности сервера становится заметным, как правило, когда
количество буферов падает ниже 40% от начального значения. Это отношение
является частным от деления действительного количества буферов (total cache
buffers) на изначальное их количество (original cache buffers). Значения
total cache buffers и original cache buffers находятся в окне общей
информации (General Information) модуля MONITOR.NLM. Обратитесь к AppNotes
от марта 1997 года, раздел "Optimizing IntranetWare Server Memory".
Краткое замечание насчет точной настройки:
Поскольку ресурс, например, память, на каждом сервере ограничен (пока не
добавлено еще памяти), точная настройка, в целом, сводится нахождению
баланса между ограниченным ресурсом и реакцией сервера на обращения рабочих
станций. В качестве примера возьмем сервер, имеющий только 64MB памяти. Если
я выделю больше памяти для кэша каталогов и буферов для приема пакетов, это
приведет к уменьшению количества буферов, используемых для кэширования
файлов. Чрезмерное распределение других ресурсов, которые потребляют память,
уменьшило бы объем памяти для кэширования файлов, и, следовательно,
замедление сервера, а не его ускорение. Для данного примера нужен баланс
между количеством буферов каталогов и буферов для приема пакетов, дающий
достаточное количество файловых буферов. Он даст больше производительности,
нежели слишком малое или слишком больше количество буферов каталогов
(учитывая ограниченность ресурса)
10. Dirty Cache Buffers (ожидающие буферы кэша)
и Current Disk Requests (сейчас запросов к диску)
-----------------------------------------------------
Если количество ожидающих файловых буферов (Dirty Cache Buffers) и текущих
запросов к диску (Current Disk Requests), которое можно увидеть в окне
модуля MONITOR, велико, то это означает, что много буферов ожидают своей
записи на диск и много запросов на чтение с диска так же ожидают
своей очереди.
Вы можете установить максимальное количество одновременных записей на диск
кэша каталогов (Maximum Concurrent Directory Cache Writes) (по умолчанию
10), и файлов (Maximum Concurrent Disk Cache Writes) (по умолчанию 50) выше
стандартного, принимаемого по умолчанию значения. Можно установить задержку
записи буферов на диск (Dirty Disk Cache Delay Time) в меньшее чем по
умолчанию значение (по умолчанию 3.3с).
Играйтесь этими настройками до тех пор, пока Dirty Cache Buffers и Current
Disk Requests не будут периодически падать до нуля. Их значения должны
нарастать всплесками и падать до нуля. Если после всех настроек количество
ожидающих сброса буферов и запросов к диску остается высоким, значит ваши
диски не могут справиться с такой нагрузкой. Тогда можно посоветовать либо
купить более быстрые диски, либо уменьшить загруженность сервера. Чаще всего
узким местом указывается именно дисковая система сервера.
Советуем начать со следующих установок, а уж потом подстраивать их под свои
нужды:
SET Maximum Concurrent Disk Cache Writes = 500
SET Dirty Disk Cache Delay Time = 0.5
SET Maximum Concurrent Directory Cache Writes = 100
11. Host Bus Adapters (адаптеры главной шины), Mirroring (зеркалирование) и
Duplexing (дублирование).
---------------------------------------------------------------------------
При конфигурировании нескольких устройств рекомендуется вешать медленные
устройства на отдельный от быстрых устройств канал или шинный адаптер. К
медленным устройствам относятся ленточные накопители и приводы CDROM.
Быстрые устройства - жесткие диски и им подобные.
При возможности используйте аппаратное зеркалирование, дублирование или
создание RAID-массива, предпочитая его программному, ибо на аппаратном
уровне эти мероприятия работают гораздо быстрее чем в своей программной
реализации.
Скорость сервера зависит от разных обстоятельств - процессора, количества
памяти и быстродействия дисков. "Задумчивость" сервера может быть связана с
медленными дисками. Проверьте "Dirty Cache Buffers" и "Current Disk
Requests" на консоли модуля MONITOR, чтобы убедиться, что дисковая система
справляется с нагрузкой.
12. Directory Caching (кэширование каталогов)
---------------------------------------------
Память из кэша выделяется для хэш-таблицы, FAT, Turbo FAT, таблиц выделения
субблоков, кэша каталогов, области временного хранения для файлов и
NLM-модулей, а также для других системных нужд. FAT и DET (С.П.А. -
Directory Entry Table - таблица элементов каталога) записаны в память
сервера (С.П.А. - written into the servers memory). Область, где хранятся
элементы каталога, называется кэшем каталогов. Сервер получает адрес файла
из кэша гораздо быстрее, чем с диска.
Установите минимальное количество буферов каталогов (minimum directory cache
buffers) из расчета 2-3 на каждое соединение, а максимальное (maximum
directory cache buffers) сделайте равным 4000. Можно уменьшить время
ожидания выделения кэша каталогов (directory cache allocation wait time)
до 0.5 (по умолчанию 2.2). Если количество буферов каталогов остается
постоянным в течение длительного времени, сделайте это количество новым
минимумом.
13. Block Suballocation (выделение субблоков)
---------------------------------------------
Подвыделение (выделение субблоков) реализовано в NetWare 4.X чтобы
справиться с неэкономным расходованием места на диске из-за блоков (С.П.А. -
в терминах ДОС - "кластеров"), заполненных лишь частично. Подвыделение
позволяет "хвостам" нескольких файлов занимать один и тот же блок места на
диске. Единицей распределения в субблоке является один сектор (512 байт).
Это значит, что в одном 64К блоке могут находиться хвосты 128 разных файлов.
С использованием подвыделения, максимальные потери дискового пространства
составляют 511 байт на файл. Это произойдет, если файл на один байт длиннее,
чем необходимо, чтобы заполнить 512-байтный сектор. Следовательно,
подвыделение почти подавляет лишний расход места, возникающий за счет
больших единиц распределения дискового пространства и повышает эффективность
дискового канала на больших дисках.
С точки зрения производительности, подвыделение ее улучшает, поскольку
хвосты целой кучи файлов могут быть записаны на диск одной операцией записи.
Конечно, это небольшое преимущество зачастую съедается расходами на
управление процессом подвыделения. Главный выигрыш состоит в оптимизации
дискового канала и кэша относительно 64KB дискового блока.
Когда мультимедиа и другие нагрузки, требующие непрерывных потоков данных,
получат большее распространение, размер блока в 64KB станет неоценимым. Мы
всем рекомендуем использовать именно такой размер блока для достижения
большой эффективности, избавления от напрасных затрат места и получения
выгод от упреждающего чтения.
Очень важно, чтобы при разрешенном подвыделении были загружены все
необходимые "заплаты" ОС. Подвыделением нельзя управлять какими-либо
параметрами команды SET: все делается автоматически. Во избежание проблем с
подвыделением очень важно отслеживать количество свободного места на диске.
Novell Engineering рекомендует иметь в запасе 10-20% места на диске
свободным, чтобы не возникли проблемы подвыделения.
Подвыделение использует свободные блоки для выполнения своей задачи. Когда
свободных блоков остается мало, подвыделение может переключиться в
"агрессивный" режим, заблокировать том и вызвать повышенную утилизацию. В
большинстве случаев достаточно иметь более 1000 свободных блоков, чтобы эта
проблема не возникла. Если это не так, если свободных блоков меньше 1000, то
выполните PURGE /ALL из корневого каталога тома. Это очистит "ожидающие
освобождения неиспользуемые блоки" ("freeable limbo blocks") и вернет их
обратно в пул свободных блоков.
14. Disk Block Size (размер блока на диске)
-------------------------------------------
Исходя из наших проверок, мы рекомендуем использовать блоки размером 64KB на
всех томах. Большой блок позволяет NetWare более эффективно использовать
дисковый канал за счет единовременного чтения большего количества данных,
что ускоряет доступ к устройствам массовой памяти и улучшает реакцию сервера
на запросы пользователей сети. Если вы используете диски RAID5, установите
размер блока соответствующим количеству дисков в массиве
(set the block size equal to the stripe depth of the RAID5 disks)
(*Comment:*)
Размеp кyсочка (на котоpые pазбивается большой блок данных) записываемого на
каждый диск в составе RAID5 массива.
Допyстим y меня есть RAID5 массив из 5 дисков. Stripe Size = 8kb.
Я записываю блок 64kb.
1-е 8kb записываются на 1-й диск.
2-е 8kb записываются на 2-й диск.
3-е 8kb записываются на 3-й диск.
4-е 8kb записываются на 4-й диск.
На _5-й_ диск записывается CRC по этим четыpем блокам.
_и сдвигаемся на однy позицию._
5-е 8kb записываются на 2-й диск.
6-е 8kb записываются на 3-й диск.
7-е 8kb записываются на 4-й диск.
8-е 8kb записываются на 5-й диск.
На _1-й_ диск записывается CRC по этим четыpем блокам.
(это один из частных слyчаев конфигypации raid массива. Напpимеp можно pаботать
без crc, это бyдет raid0. Можно выделить под crc отдельный диск и не сдвигать
поpядок следования. Это не помню как называется.)
Соответственно по квоченомy текстy: В идеале Stripe Size в RAID5 массиве и
pазмеp блока нетваpевого тома должны быть pавны и составлять 64kb. ;)
15. Hotfix Blocks (блоки горячего резерва)
------------------------------------------
Загрузить SERVMAN, выберите Storage Information (информация об устройствах
памяти), откройте NetWare Partitions in the server (разделы NetWare на
сервере). Убедитесь, что нет используемых блоков горячего резерва ("Used
Hotfix blocks"). Либо вы можете загрузить MONITOR, выбрать "Disk
Information", выбрать устройство, нажать <ENTER> и <TAB>. Вы увидите
информацию о переадресованных блоках (Redirected Blocks). "Used Hotfix
blocks" и "Redirected Blocks" показывают, что на вашем диске есть
поврежденные сектора. Приготовьтесь к замене диска.
16. Влияние подвыделения (suballocation) на количество свободных блоков и
место на диске для каждого тома
-------------------------------------------------------------------------
Очень важно иметь на каждом томе, гле разрешено подвыделение, не менее 1000
<свободных блоков> и 10%-20% свободного места. Подвыделение использует эти
свободные блоки для освобождения дополнительного места на диске. Чтобы
вовремя узнавать о недостатке свободных блоков, установите Volume Low
Warning Threshold и Volume Low Warning Reset Threshold в 1024.
Проблемы с повышенной утилизацией могут быть вызваны нехваткой места на
диске. Подвыделение - низкоприоритетный процесс (low-priority thread). Это
означает, что в обычных условиях она будет выполняться только когда
процессору нечего делать и он простаивает. В этом случае подвыделение
работает в <неагрессивном режиме>. Когда на диске остается меньше 10%
свободного места, подвыделение может перейти в <агрессивный> режим - оно
становится процессом с нормальным приоритетом и удерживает контроль над
семафором тома до тех пор, пока не освободит и не очистит как можно больше
места. Такая блокировка семафора тома заставляет остальные процессы,
желающие поработать с этим томом, ждать, пока семафор не будет освобожден. В
крупных системах это приводит к увеличению количества буферов для приема
пакетов (Packet Receive Buffers) и процессов обслуживания файлов (File
Service Processes). Когда количество приемных буферов превышает свой верхний
предел, сервер начинает сбрасывать соединения и пользователи не могут
зарегистрироваться. Когда подвыделение завершает чистку, семафор
освобождается и происходит обслуживание процессов, ожидавших своей очереди.
После этого загруженность (утилизация) падает и сервер возвращается в
нормальный режим работы.
Недостаток свободных блоков это не то же самое, что недостаток места на
диске. Удаленные файлы сохраняются на диске - файл существует, но он невидим
для пользователя и не включается в статистику тома как занимающий место.
Количество свободных блоков рассчитывается по формуле:
Free Blocks<свободные блоки> = [Total Blocks<всего блоков> - (Blocks In Use
by Files<блоки, занятые файлами> + Blocks In Use by Deleted Files<блоки
занятые удаленными файлами>)]
(С.П.А. - перевод названий компонентов формулы может не совпадать с
названиями статистических параметров в русской версии NetWare - у меня нет
русской версии и я не уверен в том, что мой перевод совпадет с переводом от
Novell)
Короче говоря, половина места на томе может быть свободна, но при этом может
не быть ни одного свободного блока, поскольку они заняты под удаленные файлы. Если свободных блоков
остается мало, запустите PURGE /ALL из корневого каталога этого тома, чтобы
освободить блоки, ожидающие освобождения (freeable limbo blocks) и передать
их в пул свободных блоков. Чтобы не делать это слишком часто, присвойте
атрибут P (PURGE - очищать) тем каталогам, в которых создается большое
количество временных файлов. Атрибут P не влияет на подкаталоги (does not
flow down the file system), это нужно иметь в виду при его установке. А еще
можно с консоли сервера установить IMMEDIATE PURGE OF DELETED FILES = ON
(немедленное уничтожение удаленных файлов), чтобы удаляемые файлы не
занимали место.
17. Сжатие файлов
-----------------
Перед использование сжатия желательно загрузить <заплаты> к OS. Стандартный
набор параметров сжатия учитывает тот факт, что сжатие использует часть
процессорного времени для сжатия и расширения файлов. Сжатие разработано
так, чтобы выполняться после полуночи, когда у большинства серверов загрузка
минимальна. Чтобы не сжимать/расширять часто используемые файлы, применяется
параметр DAYS UNTOUCHED BEFORE COMPRESSION (сжимать файлы, неиспользуемые
сколько-то дней). Любые изменения стандартной конфигурации командами SET
могут оказать серьезное влияние на производительность сервера.
Пользователи, имеющие ограничения по использованию места на диске, могут
присвоить своему каталогу атрибут IC (immediate compress - сжимать сразу
же), чтобы сэкономить место на диске. Установка этого атрибута также влияет
на производительность сервера. Обычно, сжатие - низкоприоритетный процесс,
то есть оно сжимает файлы только во время простоя процессора. После
установки атрибута IC, сжатие становится процессом с обычным приоритетом и
не ждет простоя.
Если установить DELETED FILES COMPRESSION OPTION = 2 (тип сжатия удаленных
файлов), то они будут сжиматься сразу же после удаления, что приводит к
повышенной утилизации, поскольку процессор вынужден сразу же сжимать их по
мере удаления.
Устранение неполадок:
Отключите сжатие, как возможный источник проблем, используя команду
ENABLE FILE COMPRESSION=OFF. (разрешить сжатие файлов = выкл). При этом
файлы будут ставиться в очередь на сжатие, но сжиматься не будут. В любом
случае, сжатые файлы при обращении к ним будут расширены.
Чтобы увидеть количество сжатий/расширений выполните следующую команду:
set compress screen = on
Мы советуем установить Days Untouched Before Compression = 30 (сжимать файлы,
неиспользуемые сколько-то дней), а Minimum Compression Percentage Gain = 20
(минимальная выгода от сжатия).
18. Декомпpессия файлов
-----------------------
Декомпpессия(pасшиpение), как и сжатие, отнимает часть процессорного времени.
Если ваш том с разрешенным сжатием почти полон, то файлы будут сжиматься,
но не смогут быть расширены из-за нехватки места.
Такое может случиться, если велико значение параметра
Minimum File Delete Wait Time (минимальное время ожидания удаления файла),
что не позволяет расширяемому файлу освободить под себя место, сейчас
занятое удаленными файлами. Ситуация с переполнением тома обычно
обозначается предупреждением "Compressed files are not being committed" (не
получается расширить сжатые файлы) на консоли сервера. Эту проблему можно
решить присвоением параметру "Decompress Percent Disk Space Free To Allow
Commit" (сколько места должно оставаться на томе, чтобы разрешить расширение
файлов) меньшего, чем сейчас, значения. Однако, вам все равно надо иметь
достаточно места на диске, чтобы на него поместилась расширенная версия
файла.
(С.П.А. - следующий абзац я перевел дословно, сохранив и оригинальный текст,
ибо слишком многое там не понятно. Либо я настолько не знаю английского,
либо это опечатка составителя TID-а. Вероятно, там говорится о сжатии, но
явного указания на это нет.)
Когда файл расширен, он по-прежнему потребляет процессорное время, но отдает
управление для обслуживания других процессов и NCP. Процессор PentiumR,
работающий на 60Гц (С.П.А. - Чего? Может быть МГц?) способен
декомпрессировать до 1Мб в секунду.
ОРИГИНАЛЬНЫЙ ТЕКСТ: As a file is decompressed, it does consume CPU cycles but it will
relinquish control to allow other threads and NCPs to be serviced. A Pentium
processor (60Hz) can decompress on average 1 MB a second.
19. Read After Write Verification (проверка записи чтением)
-----------------------------------------------------------
Проверка <чтение после записи> (read-after-write) суть важная часть защиты
данных вашей системы. Как правило. Вы не должны отключать ее, но если диски
Секция 1 из 2 - Предыдущая - Следующая
|
|
 |
|
