Posts Tagged ‘блокировка’

Протокол STP — как оно работает

Написал admin . Опубликовано в Network просмотров 12 013

Так себеПойдетХорошоПонравилосьОтличный пост (4 votes, average: 4,00 out of 5)
Загрузка...

Введение

Как известно, грамотный дизайн отказоустойчивой сети подразумевает использование резервирования каналов. Наиболее подходящей для этого является кольцевая топология. Однако, в случае построения сети по технологии Ethernet в чистом виде, множественные связи между узлами не предусмотрены и могут привести к полной неработоспособности всей конструкции. Например, в случае попадания в кольцо широковещательного пакета, он будет передаваться активным оборудованием по кругу бесконечно, обеспечивая предельную загрузку. Для предотвращения подобных ситуаций был создан специальный протокол Spanning Tree Protocol (STP).

Блокировки в репозитории CVS

Написал admin . Опубликовано в Unix просмотров 157

Так себеПойдетХорошоПонравилосьОтличный пост (No Ratings Yet)
Загрузка...

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

Файлы в репозитории, чьи имена начинаются с `#cvs.rfl’ — это блокировки чтения. Файлы, чьи имена начинаются с `#cvs.wfl’ — это блокировки записи. Старые версии CVS (до @cvsver{1.5}) создавали также файлы с именами, начинающимися с `#cvs.tfl’, но такие файлы здесь не обсуждаются. Каталог `#cvs.lock’ служит основной блокировкой, то есть перед тем, как создавать какую-либо еще блокировку, сначала необходимо создать основную блокировку.

Чтобы создать блокировку чтения, сначала создайте каталог `#cvs.lock’. В большинстве операционных систем операция создания каталога является атомарной. Если попытка создания завершилась неудачно, значит, основная блокировка уже существует, поэтому подождите немного и попробуйте еще. После получения блокировки `#cvs.lock’ создайте файл, чье имя состоит из `#cvs.rfl’, и информацией по вашему выбору, например, имя машины и номер процесса. Потом удалите каталог `#cvs.lock’, чтобы снять основную блокировку. Теперь можно читать репозиторий. Когда чтение окончено, удалите файл `#cvs.rfl’, чтобы снять блокировку чтения.

Чтобы получить блокировку записи, сначала создайте каталог `#cvs.lock’, как и в случае с блокировкой чтения. Затем убедитесь, что в репозитории нет файлов, чьи имена начинаются с `#cvs.rfl’. Если они имеются, удалите `#cvs.lock’, подождите немного и попробуйте снова. Если блокировок чтения нет, создайте файл с именем, состоящим из `#cvs.wfl’ и какой-нибудь информации по вашему выбору, например, имени машины и номера процесса. Не удаляйте блокировку `#cvs.lock’. Теперь вы можете писать в репозиторий. Когда запись окончена, сначала удалите файл `#cvs.wfl’, а затем каталог `#cvs.lock’. Заметьте, что в отличие от файла `#cvs.rfl’, файл `#cvs.wfl’ имеет чисто информационное значение; он не оказывает блокирующего эффекта, который в данном случае достигается использованием главной блокировки (`#cvs.lock’).

Заметьте, что каждая блокировка (чтения или записи) блокирует единственный каталог в репозитории, включая `Attic’ и `CVS’, но не включая подкаталоги, которые представляют собой другие каталоги, находящиеся под контролем версий. Чтобы заблокировать целое дерево, вам следует заблокировать каждый каталог (заметьте, что если вы не сможете получить хотя бы одну блокировку в этом процессе, то следует отменить все уже полученные блокировки, затем подождать и попробовать снова, во избежание мертвых блокировок.)

Заметьте также, что CVS ожидает, что доступ к отдельным файлам `foo,v’ контролируется блокировками записи. RCS использует в качестве блокировок файлы `,foo,’, но CVS не поддерживает такую схему, поэтому рекомендуется использование блокировки записи. Смотри комментарии к rcs_internal_lockfile в исходном коде CVS, где находится дополнительное обсуждение и мотивация.

PostgreSQL: аналитика для DBA

Написал admin . Опубликовано в Databases просмотров 662

Так себеПойдетХорошоПонравилосьОтличный пост (No Ratings Yet)
Загрузка...

Многие пользователи СУБД PostgreSQL знают, что сервер во время своей работы собирает разнообразную статистику, но не все знают, что ее полезно анализировать и как ее извлекать для этого. В этом небольшом тулките собраны несколько полезных запросов, дающих некоторое представление о том, как использовать это «скрытое знание», которое постоянно копится. Эти запросы можно использовать для мониторинга состояния PostgreSQL (ручного или с помощью плагинов для систем мониторинга вроде Nagios, Cacti или Zabbix), для поиска узких мест в работе сервера и многих других подобных задач. Помните, что это лишь верхушка айсберга; в документации можно найти описания нескольких десятков системных представлений, которые также могут быть полезны администратору PostgreSQL.

Для корректной работы тулкита необходимо включить опции stats_block_level и stats_row_level в postgresql.conf, а также настроить параметр stats_reset_on_server_start по своему усмотрению. Если при каждом перезапуске сервера PostgreSQL вы меняете какие-то существенные параметры его конфигурации, имеет смысл обнулять статистику, чтобы отслеживать эффект внесенных изменений. Если же вас интересует долгосрочная перспектива и рестарт производится не вследствие изменения конфигурации PostgreSQL, ставьте параметр stats_reset_on_server_start в значение off.