1С на самбе

Добрый всем день!

Поставил 1С 7.7 файл-серверный вариант на самбу. Теперь возникают вопросы. А именно - есть устойчивое ощущение, что самба работает с блокировками немного не так, так работает Windows. А именно - самба пытается (и успешно пытается) заблокировать целый файл, там где, по моему, в виндах блокировалась на запись только часть файла. В результате юзер ждет какое то время, пока нужный файл (в конкретном случае - с таблицей "Журналы") не разлочится, чтобы самому в этой таблице начать свою транзакцию. Опрос юзерей показал, что раньше, в виндах, такого поведения не было, похоже эта таблица лочилась частично. Можно ли это вылечить?

Настройка самбы в части 1С следующая

[1C]
path=...
browseable=yes
public=yes
readonly=no
createmask=0666
directory mask=0777
write cashe size = -1
locking = yes
csc policy=disable

и в секции global - в части блокировок 1С следующая запись

kernel oplocks = yes
level2 oplocks = yes
strict locking = yes
oplocks = yes

Все файлы базы 1С принадлежат руту и имеют атрибуты вообще 0777.

Кстати, на кластере gluster 1С заработал криво... Опять же с блокировками проблемы и индексы начали сыпаться почти сразу после начала работы пары юзерей в базе... Пришлось откатиться на однокомпьютерную раздачу файловой системы.

oplocks выключать не пробовали?

у меня на самбе тоже имеется база 1С в dbf формате. Проблем не возникает. Я сравнил параметры и различие в них в следующем:
strict locking = auto
write cashe size = 0
csc policy = manual
эти параметры у меня по умолчанию как впрочем и все остальные

djadm написал:

oplocks выключать не пробовали?

Я долго не думал и тащил в свой smb.conf то, что встречал в дебрях Инет'а в части связки 1С и самбы. Поясните, за что именно отвечает этот параметр, чтобы я работал с ним более осмысленно. Pls.

Он есть в "man smb.conf", после 5000 строк.

Пётр.

fiZik написал:

у меня на самбе тоже имеется база 1С в dbf формате. Проблем не возникает. Я сравнил параметры и различие в них в следующем:
strict locking = auto
write cashe size = 0
csc policy = manual
эти параметры у меня по умолчанию как впрочем и все остальные

По поводу write cashe size - я нашел в Инете статью, где для этого параметра указано именно это (-1) значение. Причем специально подчернуто было, что с этим значением при старте самбы возникает WARNING, но далее всё работает корректно. Причем при данной настройке работает корректно и "Монитор пользователей 1С". То есть показывает всех активных юзерей.
Однако testparm говорит, что эта опция - устарела. И, более того - если её ставить в 0, то её не показывает, то есть настройка дефолтная.
Как и опция csc policy = manual. Если её поставить в это значение, то testparm её не отобраемет.

Далее - заметил, что торомоза у меня, как я полагаю, из за "мощи" клиентской машины. А именно имею гигабитную сеть и файл-сервер - ну очень могучей производительности. Клиент - Celeron 430 на 1.8ГГц c 2мя гектарами памяти. Чистое копирование файлов может разогнаться до скорости 14-18 мегабайт в секунду. Однако, когда я запускаю 1С в монопольном режиме (при этом в сети никого уже нет, вечер рабочего дня) и запускаю в нем тяжелую задачу (переиндексацию или перепроведение документов), то сетевой обмен клиента с сервером идет на скоростях, в среднем, 2.5 .. 3 мегабайта в секунду (по показаниям системного монитора сервера). То есть тормоз скорее на клиентской части. Хотя, может и самба не слишком быстро может отрабатывать сетевые запросы 1С. Днем-то она хорошо приседает, до 4-6 мегабайт в секунду на копировании большого файла.... Не нравятся мне эти приседания...

И последнее - по поводу glusterfs. Скорее всего я его неправильно приготовил под 1С. А именно - увлекся идеей повышения производительности, активизировал трансляторы опережающего чтения и отложенной записи. А клиентам файл-серверной 1С это, похоже, неполезно. Надо будет тщательно протестировать glusterfs без этих трансляторов под 1С. И сделать вторую попытку. Там, с гигабайтным кэшем на сервере чтение большого файла до 25-30 мегабайт в секунду разгонялось. Плюс, опять же репликация данных между двумя серверами...

Peter написал:

Он есть в "man smb.conf", после 5000 строк.

Да, я в курсе, что ман на smb.conf толстый, полный и сортирован по алфавиту :-). Однако он несколько лапидарен. И на вопрос - как именно поведет себя 1С при конкретной настройке - не отвечает. Поэтому и спрашиваю: а как оно повлияет на работу 1С?

есть прекрасный сайт с переводом smb-conf.ru. По поводу 1С. Насколько большая база? все дело в том что файл-серверная версия имеет свой предел применимости, для этого и существует клиент-серверная версия.

fiZik написал:

есть прекрасный сайт с переводом smb-conf.ru. По поводу 1С. Насколько большая база? все дело в том что файл-серверная версия имеет свой предел применимости, для этого и существует клиент-серверная версия.

Тот сервер курю постоянно :-). Просто было очень неплохо иметь практическое разъяснение, что такая-то задача пользуется такими то особенностями, а такая - иными. И для оптимальной работы такой задачи надо ставить параметры такие, а для работы иной задачи - иные. Вот такого прикладного сайта я не нашел. Увы. Поэтому и приходится заниматься псевдоисследовательской работой.

А база у меня (точнее не у меня, а мне в наследство досталась от прежних админов) более чем превосходящая все разумные пределы (я оцениваю - на порядок, не меньше). Перевести её в SQL не самая простая и дешевая работа. Так как 7.7 база файловая. А 1С 7.7 работает, насколько я понимаю, или с файлами, или с MSSQL. Я же на серверах решительно ухожу от M$ в сторону OpenSource. А здесь опять возникает призрак M$. И насколько я неправильно понял - для того, чтобы заставить 1С работать с postgre надо у етерсофта покупать специальную "прокладку", транслятор вызовов с языка MSSQL на язык PostgeSQL. А стоит оно очень недешево.... Не дешевле ВыньСервера с MSSQL. Тогда какой смысл во всей затее отказа от M$?

Значит переходить надо с 7.7 файл-серверного варианта сразу в 8-ку SQL... К тому же учесть, что в коде были сделаны (опять же не мной) серьезные доработки... Ну, словом, такую операцию у меня пока знаний не хватает. Буду лучше курить тему об свертке базы. Об удалении из неё старых, неактуальных, документов. Если кто этим занимался, то приму рабочую методику с большой благодарностью.

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

Cruiser78 написал:

Кстати, с Вашими параметрами блокировок база зашуршала ощутимо быстрее

Это скорее всего из-за

strict locking = auto

Так как включение strict locking на постоянку заставляет самбу проверять диапазоны при любом обращении (чтение и запись) к файлу, а реально виндовый клиент может требовать блокировки не для каждого обращения.
strict locking = yes помогает усилить секьюрити, но явно замедляет работу