Грабли с первасивом

[bolbatos]

На WMvare ESX установлен SLES+OES - в отдельном дереве, всё по дефолту, NSS, PSQL 10SP3, предполагалось потестить как свалку бэтрив баз. В результате - скорость копирования на том по 1G - ниже 30 не опускается, один глобальный процесс в ПО натянул 2 новелл 5.1 сервера на 30%.
Как тока положил живую базу и запустил юзеров - (настройка путь к PSQL базе - UNC путь, юзера прав на сусю не имеют - висят как нот логгед ины) вроде работали без проблем сначала.
!!!!!НО!!!!!! В одной задаче читается внешний список из .TXT файла (USB FLASH), загоняется в базу, сверяется и зачисляется. Так вот - после чтения файла его отражение в БАЗЕ ПРОИСХОДИТ ОТ 1мин до 10мин!!!!!
Т.Е. - вижу наконец то в базе список (после 10мин), хочу удалить, пишет удалено - но список висит!!!! - опять 1-10мин - список удалён из базы....
Под занавес получил на одном из файлов ошибку 2 - потерял 15 записей и на этом эксперименты закончились - попробовали тестить с реальным мапом и правами админа - те же грабли

На 10PSQL под виндами и 9.5 на новеле тоже ПО работает корректно.
где криво - в сусях либо кривые руки разработчиков - не пойму.....

Может чегонить подкрутить надо в сусях либо в NSS????

Может кто ещё тестил реальный софт на этой связке????

[Dimerson]

1. что говорит саппорт первасива (на форумах) ?2
2. если выложить базу не на NSS а на какойнить EXT3/Reiser , сделать том (NCP Share) ?

[bolbatos]

Походу с наследием бэтрива тут тока мы в двоём отались....

Я всётаки больше думаю про кривые руки разработчиков: ПО писано на паскале и настолько криво, что не передать словами - мой супорт плачет...... Звонил разработчикам - они понятия ни имеют о SLES+OES..... Базы выросли до 30 - 40 гиг.......
Мало того - никто не хочет брать ответственность за тестирование под новыми платформами и что печально то, что кто писал мать всех батников - уже давно уволился..... И ЭТО В КРУПНЕЙШЕМ БАНКЕ СТРАНЫ.......
Тока на чтение (базы прошлого года для отчётов) выложил 50гиг работает всё на ура

С NCP шаре у меня не получилось - если на NSS даю PSQL юзеру ч/з admin/rights права - то на NCP шаре давал ч/з ncpcon - получилась лажа - то что создано юзером PSQL - работает - созданное правами админа недоступно первазиву - 94 ошибка ....
здесь я застрял и переехал на ESX благо железка позволяет HP370 2x4ядра 16г ОП и 540 в 0+1 RAID

После праздников попробую выплодить в ESX чистую SLES и ч/з самбу (гнилой с точки зрения совместимости с новелами вариант, но чтобы убедится что не в LUNIX PSQL проблема) попробую....
И вообще я в трауре..... Было стока надежд....

Dimerson - если есть на чём - потести свой софт - мне важен опыт других....

[Boris Morozov]

Весь транспорт Беларуси работает и работает первазив великолепно, никакого желания менять базу нет. Компоненты и под Дельфи 2010 разработаны и работают.
Разработчики ваши и не должны ничего знать про SLES OES.
Все дела у первазива вытащены в драйвер. Там просто нечем рулить и не нужно. Хотя для Protected mode паскаля надо было подчистить в Baccess структурку для DPMI под клоны NT. Мелкомягкие нарушили спецификацию и заюзали недокументированные поля.

А вот скорее мне кажется, что глюк с текстовыми файлами или с кривостью назначения прав. Лучше, чем в классике новелла нет и не было сделано.
А с правами глюки совершенно идиотские были недавно с вендой.
Дали все права на каталог, часть под каталогов записали с флэхи, два подкаталога для временных файлов создали. В те, которые с флэхи пишет, в созданные админом под юзером нет. Права с полным доступом. Скинули каталоги на флэху, вернули обратно, все шуршит. NTFS мать его. Что это было, никто не знает.

Есть другой вариант, пустить Pervasive Security. Тогда вообще никаких шар не надо, чисто по TCP/IP будет работать. И софт вроде как менять не надо, изучал когда-то, просто не понадобилось. Шары все эти нужны первазиву исключительно для прочтения прав доступа, потом все равно идет обычный TCP/IP обмен по 3351 порту.

[bolbatos]

Весь транспорт Беларуси работает и работает первазив великолепно, никакого желания менять базу нет. Компоненты и под Дельфи 2010 разработаны и работают.
Разработчики ваши и не должны ничего знать про SLES OES.

Согласен на все 100% - Но - если всё отдать движку - а не лезть в базы с кривыми руками. Ядро ПО было написано в 1996 году под 6.15 и 4.х/5.х базы. Есть в ПО 2 модуля с одинаковой логикой - паскаль дос и виндовозный - оба ведут себя одинаково

Все дела у первазива вытащены в драйвер. Там просто нечем рулить и не нужно. Хотя для Protected mode паскаля надо было подчистить в Baccess структурку для DPMI под клоны NT. Мелкомягкие нарушили спецификацию и заюзали недокументированные поля.

- Вот этим точно разработчики заниматься не будут

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

Думаю не в правах дело - UNC путь (вообще без прав на сервер/базу)
и полные админовские с реальным мапом - и дело не в списке - читали его и из флопаря, и из локального С: и из флэхи... да и не в списке дело - удаляется то он из базы также речез ж....у.

Есть другой вариант, пустить Pervasive Security. Тогда вообще никаких шар не надо, чисто по TCP/IP будет работать. И софт вроде как менять не надо, изучал когда-то, просто не понадобилось. Шары все эти нужны первазиву исключительно для прочтения прав доступа, потом все равно идет обычный TCP/IP обмен по 3351 порту.

А это как??
Выйду на работу - опробую запустить процесс с трассировкой и протоколированием на новеле и в слесе - логи потом сравню или кину разработчикам .....

недопетрил сразу

[Boris Morozov]

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

[bolbatos]

Чтобы выяснить где глюк - PSQL, LINUX или VMvare ESX шалит сделано следующее: в ESX выплодил WINDOWS SERVER 2003 накатил PSQL 10SP3 и попробовал работать с UNC путём (БЕЗ РАЗДАЧИ ПРАВ!!!) - РАБОТАЕТ без ошибок - т.е. ПО сообщает движку UNC путём где лежат базы - и движок там гадит!!!! Т.Е. как и в ситуации со SLES+OES.

Таже ситуация и с SLES БЕЗ OES PSQL10SP3 - /base - пляски с бубнами CHMOD/CHOWN юзеру PSQL, НИКАКИХ шар - UNC путь - И ОПЯТЬ ВСЁ РАБОТАЕТ КОРРЕКТНО.
Вывод - каким то образом мешает OES NSS том ибо разница только в в первазив мониторе отображения файлов:

Классический NOVELL, *NIX, WINDOWS отображает открытые файлы ВСЕ в верхнем регистре типа:
WORK:SCBASE/ACCOUNT
WORK:SCBASE/ACCLIST

Таже база на SLES + OES: (на чтение работает без ошибок)

/media/nss/DATAVOL/scbase/Account
/media/nss/DATAVOL/scbase/AccList
/media/nss/DATAVOL/scbase/AccList
/media/nss/DATAVOL/scbase/CLIENT
/media/nss/DATAVOL/scbase/ls

Причём AccList есть и ACCLIST И РАЗНЫЕ пользователи их открывают!!!!!!!!!!!

Такое впечатление, что как разработчикам ПО больше нравилось в исходниках рисовать имена файлам - так оно и отображает..... С разных модулей люди лезут к ОдНоМУ
Похоже глюк всё таки в OES+NSS - осталось потестить NCP шару - но
ж....й чуствую - там будет всё нормально.....

[Boris Morozov]

имен файлов.

[Dimerson]

Чтобы выяснить где глюк - PSQL, LINUX или VMvare ESX шалит сделано следующее: в ESX выплодил WINDOWS SERVER 2003 накатил PSQL 10SP3 и попробовал работать с UNC путём (БЕЗ РАЗДАЧИ ПРАВ!!!) - РАБОТАЕТ без ошибок - т.е. ПО сообщает движку UNC путём где лежат базы - и движок там гадит!!!! Т.Е. как и в ситуации со SLES+OES.

Таже ситуация и с SLES БЕЗ OES PSQL10SP3 - /base - пляски с бубнами CHMOD/CHOWN юзеру PSQL, НИКАКИХ шар - UNC путь - И ОПЯТЬ ВСЁ РАБОТАЕТ КОРРЕКТНО.
Вывод - каким то образом мешает OES NSS том ибо разница только в в первазив мониторе отображения файлов:

Классический NOVELL, *NIX, WINDOWS отображает открытые файлы ВСЕ в верхнем регистре типа:
WORK:SCBASE/ACCOUNT
WORK:SCBASE/ACCLIST

Таже база на SLES + OES: (на чтение работает без ошибок)

/media/nss/DATAVOL/scbase/Account
/media/nss/DATAVOL/scbase/AccList
/media/nss/DATAVOL/scbase/AccList
/media/nss/DATAVOL/scbase/CLIENT
/media/nss/DATAVOL/scbase/ls

Причём AccList есть и ACCLIST И РАЗНЫЕ пользователи их открывают!!!!!!!!!!!

Такое впечатление, что как разработчикам ПО больше нравилось в исходниках рисовать имена файлам - так оно и отображает..... С разных модулей люди лезут к ОдНоМУ
Похоже глюк всё таки в OES+NSS - осталось потестить NCP шару - но
ж....й чуствую - там будет всё нормально.....

Было сказано выше - создайте NCP шару на EXT3/REISER etc для теста.

btw - Lemux Pervasive engine имеет параметр USE SYSTEM CACHE.
Если сделать его в OFF на NSS что-нибудь изменится >

[bolbatos]

Было сказано выше - создайте NCP шару на EXT3/REISER etc для теста.

btw - Lemux Pervasive engine имеет параметр USE SYSTEM CACHE.
Если сделать его в OFF на NSS что-нибудь изменится >

С NCP шарой работает корректно - но я так и не понял как заставить первасив работать с файлами, созданными другими юзерами:
т.е. - ч/з ncpcon даны права на том
если admin пишет на этот том - первазиву эти файлы недоступны - опять надо плясать с CHMOD. Пришлось логиниться к серверу юзером PSQL и лить базу на том. Но в мониторе как и без OES на чистой SUSE файлы БОЛЬШИМИ буквами и глюков нет. И второй минус - удалив что либо на томе - восстановить невозможно, это не NSS

USE SYSTEM CACHE - по барабану..... всё равно криво.

Используя DELHPI и родные библиотеки от PSQL10 изваяна гага: открыть файл (ACClist) - удалить запись (accLIST) и перечитать (ACCLIST) - acclist строковая переменная передаваемая в буфер имени файла - теже грабли в мониторе - на каждой операции имя файла МЕНЯЕТСЯ!!!!
Если я попрошу разработчиков перекомпилить тонну исходников для приведения к одному знаменателю имён - меня весело пошлют на х....
осталось курить настройки NSS...... вот тока бы знать шо в них курить

[bolbatos]

О да, с линуксом будет полная задница с регистромимен файлов.

Я был бы тока рад еслиб задница была на LINUX и на NCP шаре - а на NSS было бы гуд..... ТАК ВЕДЬ ПРОСТО ЛИНЮХУ ПО БАРАБАНУ!!!!!

[bolbatos]

Всё вылечилось банально простым методом:

на NSS томе поставил NAME SPACE - UNIX и всё срослось!!!!!! в мониторе - всё БОЛЬШИМИ БУКВАМИ как положено и нет двойников!!!!!

Если будет время на выходных из дома шарахну живую базу для работы........

[Boris Morozov]

За то и любим мы его, что глюков не наблюдается.

[Dimerson]

из Provo (штат Юта) сообщают :
NSS supports the Long, DOS, UNIX, and Macintosh name spaces. By default, names on the NSS file system are case insensitive, which is supported by the Long name space. The Long name space is the default setting used when mounting NSS volumes on Linux or NetWare. In order to mount a volume with a different name space, you must specify the name space explicitly in the mount command, or you can specify the name space to use as a property of the NSS volume.

On Linux, the UNIX name space is typically used for Linux POSIX file systems. If your volume contains large directories with millions of files, using the default UNIX name space on NSS volumes can cause volumes to mount very slowly. Using the Long name space allows the NSS volume to mount normally. Unless you need to support case sensitive filenames, we strongly recommend using the Long name space.

[bolbatos]

из Provo (штат Юта) сообщают :
NSS supports the Long, DOS, UNIX, and Macintosh name spaces. By default, names on the NSS file system are case insensitive, which is supported by the Long name space. The Long name space is the default setting used when mounting NSS volumes on Linux or NetWare. In order to mount a volume with a different name space, you must specify the name space explicitly in the mount command, or you can specify the name space to use as a property of the NSS volume.

On Linux, the UNIX name space is typically used for Linux POSIX file systems. If your volume contains large directories with millions of files, using the default UNIX name space on NSS volumes can cause volumes to mount very slowly. Using the Long name space allows the NSS volume to mount normally. Unless you need to support case sensitive filenames, we strongly recommend using the Long name space.

Спасибо за инфу!
Мне показалось что PSQL ничего не зная о OES и NSS, т.к. он линуксоидный всё таки ждёт UNIX names - а на NSS -LONG и DOS - отсюда и глюк.......

Если только дело в скорости монтирования и дальше глюков не будет - это я переживу (у меня если не падает сервак и не требует ребута из за переконфигурации работает по году) - тем более что всё таки планирую преводить всё в VMware ESX - а там проще - надо том для PSQL с UNIX Names - пожалуста - надо с LONG для файловой мусорки или прикладного - накось выкуси.

Всё в понедельник запузырю 40гиг живой базы в работу на SLES+OES (дам 6гиг оперативы 4 камня и PSQL 4 гига кэшу) - буду зырить перфоманс - если да - в огонь новельный сервак и ещё один ESX ставить буду.