Новые книги

Одна из последних тенденций в деловом мире — проектная система организации работ; в последние годы навыки управления проектами требуются от менеджеров практически любого уровня. В этой книге вы найдете информацию о различных подходах к планированию и управлению проектами, научитесь составлять планы, графики работ и бюджет, а также правильно организовывать и контролировать процесс выполнения проекта. Вы узнаете о значении хороших взаимоотношений с людьми — теми, кто выполняет проект с вами, и теми, для кого он выполняется.

Теоретический материал сопровождается примерами, схемами и рисунками, подсказками и полезными советами, которые облегчат планирование и реализацию проекта. Прочитав книгу «Управление проектами для чайников», вы научитесь выявлять и преодолевать проблемы, которые мешают успешному применению эффективных методов. Эту книгу найдут для себя полезной как начинающие, так и опытные менеджеры, а также все, кто интересуется современными подходами к организации труда.
This book was written to provide a single reference for network administration in a Linux environment. Beginners and experienced users alike should find the information they need to cover nearly all important administration activities required to manage a Linux network configuration. The possible range of topics to cover is nearly limitless, so of course it has been impossible to include everything there is to say on all subjects. We've tried to cover the most important and common ones. We've found that beginners to Linux networking, even those with no prior exposure to Unix-like operating systems, have found this book good enough to help them successfully get their Linux network configurations up and running and get them ready to learn more.

There are many books and other sources of information from which you can learn any of the topics covered in this book (with the possible exception of some of the truly Linux-specific features, such as the new Linux firewall interface, which is not well documented elsewhere) in greater depth. We've provided a bibliography for you to use when you are ready to explore more.

Нестандартные требования к памяти

 

Нестандартные требования к памяти

Поскольку во многих UNIX-системах (например, в Solaris) реализовано кэширование файлов в виртуальной памяти, большинство пользователей склонны конфигурировать серверы NFS очень большой подсистемой основной памяти. Однако примеры типичного использования файлов клиентами NFS показывают, что данные восстанавливаются из буферного кэша в действительности относительно редко и дополнительная основная память обычно не обязательна.

В типичных серверах предоставляемое клиентам пространство на диске намного превышает размер основной памяти системы. Повторные запросы к блоками данных удовлетворяются скорее путем чтения из памяти, а не с диска. К сожалению, большинство клиентов работает со своими собственными файлами и редко пользуются общими разделяемыми файлами. Более того, большинство приложений обычно читают файл данных целиком в память, а затем закрывают его. В результате клиент редко обращается к первоначальному файлу снова. Если никто из других клиентов не воспользуется тем же самый файлом прежде, чем произойдет перезапись данных в кэш, то это означает, что кэшированные данные никогда снова не используются. Правда какие-либо дополнительные накладные расходы, связанные с кэшированием этих данных и последующим их неиспользованием, отсутствуют. Если требуется память для кэширования других страниц данных, в соответствующие страницы просто происходит запись новых данных. Не обязательно сбрасывать страницу на диск, поскольку представление памяти, которое предстоит сохранить, уже находится на диске. Конечно мало пользы от хранения в памяти старой страницы, которая повторно не используется. Когда объем свободной памяти снижается ниже уровня 1/16 всего объема памяти, страницы, неиспользованные в недавнем прошлом, становятся доступными для повторного использования.

Самым большим исключением из этих эмпирических правил является временный рабочий файл, который часто открывается в начале и закрывается в конце работы. Поскольку файл остается для клиента открытым, страницы данных, связанные с этим файлом, остаются отображенными (и кэшированными) в памяти клиента. Подсистема виртуальной памяти клиента использует сервер в качестве резервного хранилища временного файла. Если клиент не имеет достаточного объема физической памяти для хранения этих страниц в собственном кэше, некоторые или все страницы данных будут откачены или заменены новым содержимым при выполнении последующих операций, а повторные обращения к этим данным будут приводить к выдаче операции чтения NFS для восстановления этих данных. В этом случае способность сервера кэшировать такие данные является определенным преимуществом.

Операции записи не могут использовать все преимущества механизма кэширования UNIX на сервере, поскольку протокол NFS требует, чтобы любая операция записи на удаленный диск выполнялась полностью синхронно, чтобы гарантировать согласованное состояние даже в случае выхода сервера из строя. Операция записи называется синхронной в этом смысле, поскольку логическая операция с диском в целом полностью завершается прежде, чем она будет подтверждена. Хотя данные кэшированы, операции записи NFS не выигрывают от буферизации и откладывания момента записи, которые обычно выполняются при реализации операций записи UNIX. Заметим, что клиент может и обычно выполняет операции записи в кэш точно таким же способом, что и любую другую операцию дискового ввода/вывода. Клиент в любом случае способен контролировать когда результаты операции записи сбрасываются на "диск" независимо от того, является ли диск локальным или удаленным.

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

В заключении приведем несколько простых эмпирических правил, которые позволяют выбрать конфигурацию памяти в серверах NFS:

  • Если сервер в основном обеспечивает пользовательскими данными многих клиентов, следует конфигурировать относительно минимальную память. Для небольших коллективов обычно ее объем составляет 32 Мбайта, а для больших коллективов - примерно 128 Мбайт. В мультипроцессорных конфигурациях всегда необходимо предусматривать по крайней мере 64 Мбайт на каждый процессор. Приложения с интенсивным использованием атрибутов обычно выигрывают от увеличенного объема памяти несколько больше, чем приложения с интенсивным использованием данных.
  • Если на сервере выделяется пространство для хранения временных файлов приложений, которые очень интенсивно работают с этими файлами (хорошим примером является Verilog фирмы Cadence), следует конфигурировать память сервера равной примерно сумме размеров активных временных файлов, используемых на сервере. Например, если размер временного файла клиента составляет примерно 5 Мбайт и предполагается, что сервер будет обслуживать 20 полностью активных клиентов, следует установить (20 клиентов х 5 Мбайт) = 100 Мбайт дополнительной памяти (конечно 128 Мбайт представляет собой наиболее удобную цифру, которую легко конфигурировать). Однако часто этот временный файл может быть размещен в локальном справочнике типа /tmp, что приведет к значительно более высокой производительности клиента, а также к существенному уменьшению сетевого трафика.
  • Если главной задачей сервера является хранение только выполняемых файлов, следует конфигурировать память сервера примерно равной суммарному объему интенсивно используемых двоичных файлов. При этом нельзя забывать о библиотеках! Например, сервер предполагающийся для хранения /usr/openwin для некоторого коллектива сотрудников должен иметь достаточно памяти, чтобы кэшировать Xsun, cmdtool, libX11.so, libxwiew.so и libXt.so. Это приложение NFS значительно отличается от более типового сервера тем, что оно все время поставляет одни и те же файлы всем своим клиентам, а потому способно эффективно кэшировать эти данные. Обычно клиенты не используют каждую страницу всех двоичных кодов, а потому разумно в конфигурации сервера предусмотреть только такой объем памяти, которого достаточно для размещения часто используемых программ и библиотек.
  • Размер памяти может быть выбран исходя из правила пяти минут: 16 Мбайт для ОС плюс объем памяти для кэширования данных, к которым будут происходить обращения чаще, чем один раз в пять минут.

Поскольку серверы NFS не выполняют пользовательских процессов, большого пространства подкачки (swap) не нужно. Для таких серверов пространства подкачки объемом примерно 50% от размера основной памяти более чем достаточно. Заметим, что большинство этих правил прямо противоположены тому, что все ожидают.

[Предыдущая глава] [Оглавление] [Следующая глава]