proNovell

Добрый день!
Вчера ввели в эксплуатацию сервер с ОС NW5.1 SP6 для foxpro-шных АРМов. Ситуация такая: все работает замечательно, но вот в АРМах прописано, что каждый пользователь при входе автоматически открывает некий файл, пишет туда что-то и быстро закрывает. Так вот на новом сервере это вызывает блокировку файла на секунд 30-40. В это время другие пользователи получают отказ. Но это еще можно как-то побороть. Но вот вдруг один из пользователей подвис и файл заблокировался намертво. Утилизация на сервере подскочила до 70%, правда, пользователи работают и ничего на удивление не замечают, но ведь что-то надо делать!
Начитавшись ТИДов на support.novell.com, поняли, что надо отключить параметр file Caching на сервере. Сделали, но это приводит к резкому замедлению скорости работы, что не нравится пользователям. Что подскажете?
Сервер IBM x345, RAID 5, сеть 1Гбит,работают более 500 пользователей.

У нас в АРМе разработчики за каким то фигом при запуске открывают основную базу в монопольном режиме и затем закрывают. Поэтому я руками залез в екзешник и написал другой файл. АРМу оказалось все пофигу. Попробуй может и у тебя та же ситуация

уровня отключить.
И еще в клиентах есть всякие штучки. В 4.9 прямо есть параметр File Caching. В 3.4 тоже есть несколько настроек в том числе и про ваши 30-40 секунд. И вообще-то SP7 есть. По моему как раз он проблему с утилизацией решает.

Гммм... итересная история, чем же она кончится, а то скоро буду запускать в строй NW5.1 SP7 и у меня тоже имеются fp АРМы, но пока я на 5,0 sp6a держу...

Бурылов Александр писал(а):Гммм... итересная история, чем же она кончится, а то скоро буду запускать в строй NW5.1 SP7 и у меня тоже имеются fp АРМы, но пока я на 5,0 sp6a держу...

С той ситуацией вроде разобрались. Обратились в московское представительство Novell, они однозначно посоветовали для работы с dbf -файлами кэширование отключить, мол, кэширование может еще и сами файлы порушить. Отключили кэширование на сервере, проблемы с блокировками прекратились, утилизация 1-5%, но и скорость упала, естественно. Однако все равно лучше, чем на старом сервере

К сожалению, начались другие проблемы - с ПО БЭСТ
Не хочет оно жить на новом сервере, пользователи из АРМов вылетают, у программистов переиндексация не идет. Версия БЭСТа какая-то очень старая. Никто не сталкивался?

А тома у Вас какие ? стандартные или NSS ?

и всё же наверное стоит накатить sp7, видел даже Бета версию sp8...
самого sp7 у меня нет, а вот исталяшка nw5.1 c sp7 есть...

у нас БЭСТ стабильно индексируется на компьютерах с 98 а с 2000 вылетает иногда, кеширование отключено все и везде nw51sp5 и nw51sp6,
обычно когда БЭСТ вылетает он пишет код ошибки, по которому поддержка сразу говорит в чем проблема - с сетью, с данными, с индексами, с количеством открытых файлов
а еще очень настойчиво везде ставим в config.sys
files=250
buffers=90
из личных наблюдений - с Novell Netware БЭСТ работает стабильнее и быстрее чем с Windows серверами

Forestman писал(а):а еще очень настойчиво везде ставим в config.sys
files=250
buffers=90
из личных наблюдений - с Novell Netware БЭСТ работает стабильнее и быстрее чем с Windows серверами

Эти значения у клиентов должны стоять или на сервере?

Елена Лезгина писал(а):

Forestman писал(а):а еще очень настойчиво везде ставим в config.sys
files=250
buffers=90
из личных наблюдений - с Novell Netware БЭСТ работает стабильнее и быстрее чем с Windows серверами

Эти значения у клиентов должны стоять или на сервере?

- конечно на клиентах, под 9x в config.sys, а под NT - в config.nt

Forestman писал(а):...
files=250
...

Не наступите на грабли. Если больше 128, то шаманить надо. В FAQ по виндам есть решение.

Владимир Горяев писал(а):

Forestman писал(а):...
files=250
...

Не наступите на грабли. Если больше 128, то шаманить надо. В FAQ по виндам есть решение.

Шаманить нужно было программистам, чтоб не открывать кучу файлов. У нас все клипперовые базы работают при Files=200

files=250
так написано в руководстве по БЭСТу и поддержка первым делом советует, при значение в 200 некоторые базы не октрываются

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

Не далее как вчера, подходит программистка и говорит, что у нее проблемы с программой на XP и как всегда писки о том, что вот все годами работало и на многих объектах (действительно так) а вот у кого-то поломалось. Утверждает, что сбой при открытии файла, который перед этим формировался этой же программой (Btrieve база однако). Для надежности она даже умудрилась через шелл вызвать утилиту BUTIL -RESET (для тех, кто не в курсе - сбрасывает на локальной машине все соединения BTRIEVE и закрывает все базы).

При детальном разборе ситуации оказалось, что всего то надо было проверить существование файла и если он есть, то удалить, поскольку другой надо было переименовать. То есть реально одна строка кода, поскольку обе функции имеются в общей библиотеке.
Однако оказалось, что вместо того, чтобы воспользоваться ими она создала в программе переменную файл, открыла его, чтобы проверить на существование и НЕ ЗАКРЫВАЯ выдает команду на удаление.
Естественно получает отлуп от операционки.
Все это чудо заняло около 15 строчек кода и почему-то пропускалось ДОС и виндами 95 и 98.

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