← назад Оглавление вперед →

Samba, производительность и оптимизация

Можно ускорить работу Samba в зависимости от требуемой ситуации. В нашем распоряжении несколько вариантов конфигурации.

Параметры Socket

Одним из полезных параметров является изменение настроек sockets в файле конфигурации Samba. Стоит отметить что все сети различны (тип соединений, коммутаторы, шумы, и т. д.), поэтому не существует универсальной магической формулы для всех сетей. Поэтому если вы хотите оптимизировать производительность Samba для своей сети, вам придется экспериментировать. Для особо упертых рекомендую прочитать страницу man для socket(7). Остальным же нужно просто добавить в конфигурацию Samba следующее SO_KEEPALIVE, SO_RCVBUF=8192, and SO_SNDBUF=8192.

Последние два параметра определяют максимально возможны размер буферов приема и передачи Samba. Уменьшение размера буферов приводит к увеличению фрагментации пакетов, увеличение размера ( вплоть до максимального значения) к уменьшению фрагментации. Лучшим решением будет поставить эксперимент по созданию одного тестового файла размером 100 MB и 100 тестовых файлов по 1 MB, и оценить время копирования их с сервера и на него. На всякий случай рекомендую каждый раз останавливать и запускать сервер Samba для предотвращения кеширования данных. По результатам тестирования времени копирования для разных значений SO_RCVBUF и SO_SNDBUF вы можете определить оптимальное значение для вашей локальной сети. Чтобы создать тестовы файл выполните:

$ dd if=/dev/zero of=testfile count=10240 bs=10240

Для создания 100 файлов размером 1MB выполните:

#!/bin/sh
for ((counter=1; counter<=100; counter++)); do
        dd if=/dev/zero of=test${counter} count=1024 bs=1024
done

После сбора данных, добавьте их в график для определения наиболее оптимальных значений параметров socket. На основании этих значений измените параметры socket в файле конфигурации Samba для вашей локальной сети.

Гибкие блокировки (oplocks)

Что вы получаете в Карнеги Холле? Практику, практику, практику. Чего не хватает в классическом подходе, так это то что можно получить на практике. Каждый человек имеет свой метод или подход, будь то музыка или артистическая деятельность. Так и гибкие блокировки — это один методов из множества возможных сделать что-то (в нашем случае получить доступ к файлам по сети). Конечно сейчас они модны и имеют спрос как на Священный Грааль, и их можно настроить. Загвоздка в том что: они являются ароматом эпохи, при этом имея свои преимущества и свои недостатки (смотрите: базы данных Microsoft Access).

Понятие гибкие блокировки лучше всего описано в старой статье 129202 базы знаний Microsoft

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

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

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

Посмотрим как работают гибкие блокировки второго уровня:

  1. Станция 1 открывает файл, создавая запрос гибкой блокировки.
  2. Поскольку другие рабочие станции не открывают этот файл, сервер выдает станции 1 монопольную гибкую блокировку.
  3. Станция 2 открывает файл, создавая запрос гибкой блокировки.
  4. Поскольку станция 1 пока ничего не пишет в файл, сервер запрашивает у 1 станции перерыв до второго уровня гибкой блокировки.
  5. Станция 1 подчиняется, сбрасывая локально сбуферизированую информацию блокировки на сервер.
  6. Станция 1 сообщает серверу что она перешла на второй уровень гибкой блокировки (альтернативно, станция 1 может закрыть файл).
  7. Сервер отвечает второй станции на запрос открытия, предоставляя второй уровень гибкой блокировки. Другие рабочие станции так же могут открыть файл, получив при этом второй уровень гибкой блокировки.
  8. Станция 2 (или любая другая станция открывшая файл) отправляет запрос записи SMB. Сервер возвращает ответ писать.
  9. Сервер запрашивает все станции открывшие файл на полное отключение, с намерением отключить гибкие блокировки на файле. Поскольку рабочие станции могут в этот момент иметь незакешированую запись или блокировки, они не должны отвечать на сообщение о полном отключении; все что они должны сделать это отключить данные, локально закешированные в режиме упреждающего чтения.

А теперь кратко, отдельно от основной части статьи перечислим жемчужины мудрости (поражает язык повествования 🙂 , прим. переводчика)

  • Монопольные блокировки необходимо отключать только для изоляции проблем.
  • Гибкие блокировки повышают производительность, но потенциально могут приводить к потере закешированых данных в некоторых сетях, особенно в глобальных сетях
  • Отключайте непосредственные и монопольные блокировки в сетях с низкой пропускной способностью.
  • Отключайте непосредственные I/O и монопольные блокировки в сетях с большими задержками.
  • Уменьшение времени ожидания для клиента для предотвращения нарушения монопольной блокировки, может позволить определять зависших клиентов, но потенциально может привести к потере кэшированных данных.

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

Второй уровень монопольной блокировки это просто фантастический способ сказать, что вы обеспечиваете гибкую блокировку на файл, который будет рассматриваться как "только для чтения". Обычно используется для файлов, которые открываются только для чтения, или только для файлов в которые клиент не имеет намерения осуществлять запись (по крайней мере, на начальном этапе).

Ядро монопольных блокировок по существу это метод, позволяющий ядру Linux сосуществовать с гибкими блокировками файлов Samba, хотя это сильно утрировано. SGI IRIX и Linux являются единственными двумя Unix's, которые на данный момент поддерживают монопольные блокировки.

Если ваша система не поддерживает монопольные блокировка ядра, вы должны отключить монопольную блокировку при доступе к одним и тем же файлам из обеих Unix/Linux и Smb клиентов. Несмотря на это, монопольная блокировка всегда должна быть отключена, если вы используете файл базы данных (например, Microsoft Access) между несколькими клиентами, так как при запросе на прерывание первого клиента придется синхронизировать весь файл (а не одну запись) , что приведет к заметной задержке выполнения программы, и, что более вероятно, в первую очередь к проблемам с доступом к базе данных. Замечено, что файлы личных папок Microsoft Outlook (*. PST) очень плохо реагируют на монопольные блокировки. Если сомневаетесь, отключите монопольные блокировка и заново настройте вашу систему. Выигрыш от включения монопольных блокировок будет, если кэширование на стороне клиента является желательным и надежным в вашей сети. Если ваша сеть медленная и/или ненадежна, или вы обмениваетесь файлами при помощи других механизмов совместного использования файлов (например, NFS), либо через глобальную сеть или несколько человек, будут получать доступ к файлам часто, вы, вероятно, не получите выигрыша от применения монопольной блокировки, лучше отключите монопольную блокировку на общем ресурсе. Еще необходимо учитывать скорость доступа к файлам. Если монопольная блокировка не предоставляет существенного увеличения скорости при работе с файлами для вашей сети, может и не стоит с ними связываться. Также вы можете отключить монопольную блокировку на отдельный файл на общем ресурсе:" veto oplock files = /*.MDB/*.MDB/".

Если у вас возникли проблемы с монопольной блокировкой, о чем свидетельствуют записи в логах Samba, вы можете играть безопасно и отключите обе монопольную гибкую блокировку и level2oplocks

Вы можете отключить блокировки на общем ресурсе добавив файл конфигурации в секцию общего ресурса строку:

oplocks = False
level2oplocks = False

Альтернативно можно отключить блокировки на отдельные файлы:

veto oplock files = /*.mdb/*.MDB/

 

← назад Оглавление вперед →