Насколько второй проц облегчает жизнь?

[Slopuhov]

Для Slopuhov
Читаем документацию, последняя фраза.
Allow Cache Engine Connections - Specifies if the Server will support Clients that will attempt to connect to the Server with the Client Cache Engine. When set to Off, clients will still connect to the Server but will not use the client Cache Engine.

Какие еще могут быть вопросы?

Я может в аглицком не силен, но понимаю так - установка Allow Cache Engine Connections определяет, разрешит ли сервер клиентам, которые попытаются с ним соединиться, работать со своим (клиентским) кешем. Если выключен, клиенты будут соединяться с Сервером, но не будут использовать свой кеш.

Т.е. речь идет не о кешировании на сервере, а о кешировании на стороне клиента, так? (Это я себя проверяю ).

[igaryan]

Теперь правильно. Отключаем Allow Cache Engine Connections и уже по барабану включен локальный кеш у клиента или нет. Это как раз и ответ для amee

[Иван Левшин aka Ivan L.]

Исключительно для того, чтобы внести ясность. igaryan, вы сейчас что обсуждали? Правильно ли я понимаю, что речь шла о внутренних механизмах кэширования Pervasive? Если да - при чем тут оплоки и кэширование на клиенте?

[igaryan]

Иван, если только Pervasive исправить этого будет недостаточно. Если не верите наберите в google "client file caching enabled off" и почитайте.
Вот Новелл пишет (а для вас как я понял слова ихнего саппорта весомы) http://wiki.novell.com/index.php/OpLocks_on_NetWare
У них это называется CoolSolutions, т.е. это крутое решение - отключить оплоки, вот так то. Да что Netware, у меня на самбе полезли ошибки при включенных оплоках:
Apr 1 08:30:32 galaktika smbd[10723]: [2008/04/01 08:30:32, 0] smbd/oplock.c:oplock_timeout_handler(356)
Apr 1 08:30:32 galaktika smbd[10723]: Oplock break failed for file gal810/DSK/sbt.DSK -- replying anyway
Apr 1 08:31:02 galaktika smbd[10723]: [2008/04/01 08:31:02, 0] smbd/oplock.c:oplock_timeout_handler(356)
Apr 1 08:31:02 galaktika smbd[10723]: Oplock break failed for file gal810/data/tmp/sbt/tmp30.tmp -- replying anyway
И у клиентов ошибки полезли.
Хотя может памяти на сервер мало (сейчас 8 Гб) - используется вся. А по ночам еще копирование и архивирование баз - может память не высвобождается.

[Иван Левшин aka Ivan L.]

Иван, если только Pervasive исправить этого будет недостаточно. Если не верите наберите в google "client file caching enabled off" и почитайте.
Вот Новелл пишет (а для вас как я понял слова ихнего саппорта весомы) http://wiki.novell.com/index.php/OpLocks_on_NetWare
У них это называется CoolSolutions, т.е. это крутое решение - отключить оплоки, вот так то.

Уже читал. Думал, что-то новое появилось - ан нет, все то же самое.

1. Слова саппорта Novell для меня, безусловно, весомы - просто потому, что это последняя инстанция, к которой можно апеллировать. Они, мягко говоря, производители - и если они говорят, что вот это должно работать так, а вот это - эдак, то так тому и быть. Вы придерживаетесь иного мнения?

2. CoolSolutions - это набор неких Success stories, т.е. некий успешный опыт внедрения того или иного решения. По приведенной Вами ссылке я не заметил однозначной критики оплоков, в частности, присутствует раздел "Why Oplocks is a good idea?". Рекомендация "отключить оплоки" дана с оговоркой (вольный перевод мой): "В Netware 6.5SP4 и последующих версий, а также с Windows Client 4.91sp2 и последующих версий оплоки могут работать корректно" Т.е. "оплоки таки могут работать корректно, но если у Вас таки нет ни желания, ни времени разбираться с ними - отключите их к чертовой матери".
Так что я не стал бы рубить с плеча и уверенно говорить о том, что "вот поганый новель в крутых решениях требует выключить оплоки, а по дефолту до сих пор ничего не отключают". Речь ведется только о том, что, внедряя оплоки, надо четко предствлять себе - что Вы делаете и зачем. Впрочем, это стандартная рекомендация, справедливая для любых телодвижений.

3. Касаемо первазива - к стыду своему, забыл, как именно оно работает. Вариантов два: первый (наиболее вероятный с моей точки зрения) - клиент-сервер. Оплоки тут ни к селу, ни к городу, обмена через ФС быть не должно. Второй: файл сервер, в таком случае мне непонятно в принципе, зачем на сервере торчит серверная часть, на клиенте надо ставить клиентскую.
Оплоки начинают работать в случае, когда к одному файлу в ФС есть два конкурирующих коннекта. OpLock I в этом случае монопольно блокирует файл (и на чтение, и на запись), OpLock II - только на запись. При грамотном применении OpLock II позволяет добиться огромного выигрыша в скорости файлового обмена - опять же, проверено.

Хотелось бы объяснений - как связаны первазив и ФС нетвари. По присланной ссылке ни одного упоминания о первазиве, только про оплоки. Это я и так знаю

P.S. Кстати, я не понимаю, что плохого в настройках сервера по умолчанию (OpLock ON) - их всегда можно изменить двумя-тремя командами, не перезагружая сервер.

[Доменика]

....
Хотелось бы объяснений - как связаны первазив и ФС нетвари. По присланной ссылке ни одного упоминания о первазиве, только про оплоки. Это я и так знаю

Ни как ни связаны ли почти ни как.
Все изменения проходящие в файлах идут через журнал Pervasive. Всё ка бы по взрослому по принципу FIFO как и в других промышленных базах данных, т.е. это не dbf и не прямое обращение к файлу и Oplock ему не нужен. Не с кем конкурировать, один пользователь и тот engine от Pervasive. Можно даже как в аналогичных DB переписывать на другой сервер транзакционный лог и восстанавливать действия системы. Такой незатейливый метод репликации.

[Slopuhov]

Хотелось бы объяснений - как связаны первазив и ФС нетвари. По присланной ссылке ни одного упоминания о первазиве, только про оплоки. Это я и так знаю

P.S. Кстати, я не понимаю, что плохого в настройках сервера по умолчанию (OpLock ON) - их всегда можно изменить двумя-тремя командами, не перезагружая сервер.

Да никак не связаны.
А уж если я затеял эту тему, то, думаю, искать источник ее решения (или облегчения) стоит, в моем случае, именно во взаимодействии PSQL и NW.
Что-то уже вроде бы накопалось - тот же гипертрейдинг - уже показалась жизнь стала полегче, когда виртуальный проц отключил, хотя припадания сервера на обращениях к базам первазива все равно сегодня были на полсекундочки. Но в этот момент делались известные нам и разработчикам нашей системы предприятия ресурсоемкие процедуры.
Все равно, пока подожду в этом состоянии, может станет яснее.
Следующим шагом отключу клиентсоке кеширование в Первазиве и тоже, если не станет резко хуже, поизучаю.
Пока больше суток полет терпимый.
Уже спасибо, за то что нет караула и еще есть предполагаемые перспективы для улучшения .

[Мещеряков Андрей]

Первазив - клиент-сервер, выросший из бтрива. Но надо отметить, что с файловой системой nw отношения были сложными. Например, к Гупте давался модуль, пишущий/читающий базы минуя слои nw. Без него Гупта тоже работала, но сохранялся мизерный, но реальный процент (практически - 1 раз в 1/2 года работы 6 дей в неделю) полного краха базы. И turbodis мормоны издали именно как средство защиты от порчи баз бтрива. Т.е. проблема была и видимо есть.

[v13]

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

Но может запросто аукнуться позже, когда этот сервер начнёт использоваться именно как файлсервер .

Признак этого глюка - процессор с утилизацией 100% и есть открытые файлы которые ничем невозможно закрыть. Лечится перезагрузкой.

Я по этим граблям прошёлся давненько, как и большинство присутствующих сдесь. Если хочешь наступать на те же грабли - вперёд

[v13]

Первазив - клиент-сервер, выросший из бтрива. Но надо отметить, что с файловой системой nw отношения были сложными. Например, к Гупте давался модуль, пишущий/читающий базы минуя слои nw. Без него Гупта тоже работала, но сохранялся мизерный, но реальный процент (практически - 1 раз в 1/2 года работы 6 дей в неделю) полного краха базы. И turbodis мормоны издали именно как средство защиты от порчи баз бтрива. Т.е. проблема была и видимо есть.

Признаки проблемы связанной с turbofat (отключается turbodis) я тоже помню
Это когда заглядываешь внутрь файла базы данных а там одни нули.
после перезагрузки опа - а данные на месте. Я в шоке был когда первый раз увидел такое. Правда у меня это было только с dbf, очень давно на netware 5.0

[Boris Morozov]

Файловые клиенты первазиву нужны исключительно с целью определения местоположения базы и прав доступа к ней, сама работа идет по TCP/IP или IPX между серверной и клиентской частью.
Кстати, когда базы на виндовом сервере, напрочь игнорируется тот факт, что диск к примеру подсоединен клиенту по чтению. В нетвари все нормально, доступ на запись запрещен. Можно организовать доступ без подсоединения диска, чисто по порту.
Local Engine нужен только в том случае, если у вас базки на локальных дисках. В остальных случаях может вызывать блокировки, если сдуру не сконнектится с сервером, тогда может использовать сетевой диск как будто локальный и прихватить базу. Но обычно это связано с нарушением конфигурации на клиентах и исчезновением некоторых компонентов из за вируса или кривых рук.

А вообще у меня никаких замечаний по надежности первазива на нетвари нет и не было никогда. А есть клиенты, где базы крутятся огромные.

[igaryan]

У меня Netware была и как файловый сервер с большим кол-вом файлов, и как сервер Pervasive, блокировки отключал- проблем не было, если не отключал - то как раз утилизация скакала и были подвисания. Видимо это, кто как готовит свою Netware :-).
А если есть базки на локальных дисках, то я обычно ставлю не Pervasive Client, а Pervasive Workgroup.

[Иван Левшин aka Ivan L.]

Ну вот, теперь стало понятнее Выяснили, наконец-то, что отключение/включение оплоков на первазиве сказаться не может, бо оно клиент-сервер.

Например, к Гупте давался модуль, пишущий/читающий базы минуя слои nw.

Андрей, если не сложно - о каких слоях nw речь?

[Мещеряков Андрей]

Например, к Гупте давался модуль, пишущий/читающий базы минуя слои nw.

Андрей, если не сложно - о каких слоях nw речь?

Иван, я пересказал доку к Гупте и ловить меня на слове не надо -:) Хотишь конкретики - пиши к правепереемникам (сдохла контора), может ответят. Слабое место драйвера "сквозной записи" - работает только со своей версией nw. Поэтому уже на 4.11 от них пришлось уйти... Кстати, у нее был еще и третий способ вести базы - сырцом, без файловой системы вообще. Если интересно, спрошу человека, который с ней по сей день общается.
ЗЫ: Помнишь пост об устройстве NSS?
ЗЫ2: В nw 3.12-4.1 оплоков небыло и в помине. Потому с формальной точки зрения - что ТАМ они не при чем - ты прав.

[Slopuhov]

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

Но может запросто аукнуться позже, когда этот сервер начнёт использоваться именно как файлсервер .

Признак этого глюка - процессор с утилизацией 100% и есть открытые файлы которые ничем невозможно закрыть. Лечится перезагрузкой.

Я по этим граблям прошёлся давненько, как и большинство присутствующих сдесь. Если хочешь наступать на те же грабли - вперёд

Он и для первазива и файл-сервер в тоже время (или файл-мусорка). Но основная задача - все же PSQL.
Вчера вечером отключил Allow Cache Engine Connections на PSQL сервера - дублера, проверил работоспособность, никакой особой разницы не обнаружил. После этого отключил это же на основном аппарате и сегодня буду сравнивать со вчерашним поведением сервера.