forum.clarionlife.net

Добрый день

Есть приложение (работа с локально на винчестере расположенной БД), написанное на Clarion 4, которое начинает ощутимо тормозить при размере TPS - файлов более 15-20 метров...
Хотел услышать мнение специалистов: это действительно критичный размер для Клариона ? Поможет ли переделка приложения на Кларионе 5 или 6 ?
Одним словом извечный вопрос: что делать ?

С удовольствием приму ссылки на технические характеристики и ограничения для TPS - файлов.

С уважением, Прохоров Антон
E-mail: prohorov@aggio.kiev.ua

(Добавление)

Есть приложение (работа с локально на винчестере расположенной БД), написанное на Clarion 4, которое начинает ощутимо тормозить при размере TPS - файлов более 15-20 метров...

У меня пока без проблем 200-300 Мб и одновременная работа в сети ~15 пользователей....
Хотя уже надо переходить на SQL-сервера (будет DB2). Да, работа идет на C55

С удовольствием приму ссылки на технические характеристики и ограничения для TPS - файлов.

Так об этом написано в доке по драйверу TPS

С уважением Мартюшев Леонид
mailto:leonid@opfr.komi.com

Тормозить может на интенсивных добавлениях/редактированиях/удалениях, т.е. на интенсивных перестроениях ключей. Просто потому, что это делает клиент и очевидно, что при этом он должен монополизировать доступ к файлу.
Или на не очень эфективных поисках, когда не все берется по ключу, а еще и дофильтровывается через выражение в фильтре. В такой ситуации я делал перерисовку брауза после каждой найденной записи - Display(?List).
Пользователь видит как идет поиск. Комп не мертвый. И предусматривал прерывание поиска, если искомая запись уже найдена.
У меня было до миллиона записей (100 Мег) но там был только поиск и редактирование неключевых полей. Самая большая проблема с большими файлами - это ремонт TpsFix-ом. Долго очень. И все стоят в это время.

А на изолированной машине проблему в 15-20 метров можно за 5 мин. решить виртуальным драйвом (RAM Drive). Переход на 5-6, думаю мало чего даст, если не ухудшит дело.

WBR, Nick Tsigouro. MailTo:Nick@arsis.ru
Написал: ClaList(2)

RAM Drive в живой природе существует? А почему только на изолированной машине?

--
С уважением, SAN mailto:vgsan@yandex.ru

Самая большая проблема с большими файлами - это ремонт TpsFix-ом.
Долго очень. И все стоят в это время.

Часто приходится чинить? И по какой причине база ломается?

--
С уважением,
Степанец Александр Валентинович.

Дело было на 2003b и Nowell-e. Почти каждый раз, когда дурило сетевое железо (типа хаб на фазу "заземлили"). И TPS при этом был не единственный пострадавший.

WBR, Nick Tsigouro

(Добавление)

Хотел услышать мнение специалистов: это действительно критичный размер для Клариона ? Поможет ли переделка приложения на Кларионе 5 или 6 ?

Для С5 и С5.5 это точно не размер - тестировал в издевательских режимах до 12 млн записей и 350МБ. Дальше не пошел из-за лени.

Одним словом извечный вопрос: что делать ?

Если используется ВыньДа95/98 с настройками дискового кэша по умолчанию, а прога активно кушает память под QUEUE или просто EXE+DLL размером >= 2МБ, то рекомендую освободить необходимую оперативку, ограничив размер кэша (system.ini : maxfilecache...).
Больше 32МБ IMHO имеет смысл только у чисто файловых серверов.

С удовольствием приму ссылки на технические характеристики и ограничения для TPS - файлов.

Записей до 4 млрд (2^32), одновременно юзеров - до 1024 (теоретически)... В хелпе точно все это есть.

--
Best regards, PigKiller

Есть приложение (работа с локально на винчестере расположенной БД), написанное на Clarion 4, которое начинает ощутимо тормозить при размере TPS - файлов более 15-20 метров...

А ты уверен, что "тормозит" именно само приложение?
Может начинает сказываться ограничение пропускной способности самого винта, его шины?
Или тормоза идут из-за перегрузки системы виртуальной памяти Винды, когда она "сваливается" в своп?

Хотел услышать мнение специалистов: это действительно критичный размер для Клариона ?

15-20 метров - довольно "детский" размер для TPS.
На нем прекрасно живут и файлы размером по нескольку сотен метров. Причем - на сети, в режиме интенсивной модификации.

А вообще - что-бы получить более конкретный ответ - надо задавать более конкретный воарос!

- что значит "ощутимо тормозить"?
Раньше отчет строился 1 сек., а сейчас - "целых" 3сек!
Т.е. имеем замедление в 3 раза!!! ))
Так что-ли?
Типа - я пришел к финишу первым! С конца:((

- на каких, именно, операциях тормозит?
При построении большого отчета с навороченным фильтром?
При добавлении/редактировании/удалении одной записи?
То-же - при пакетной обработке большого кол-ва записей?

Поможет ли переделка приложения на Кларионе 5 или 6 ?

У тебя есть 5/55/60?
Если есть, то напиши простенький тестик с использованием одного/двух РЕАЛЬНЫХ файлов из своей БД на РЕАЛЬНЫХ операциях, вызывающих "тормоза".
Перекомпили для каждой версии - и тестируй!
Кстати, с помощью этого теста сможешь легко определить - возможно причина тормозов не в драйвере, а в самой программе? Иногда тесты и реальные программами с одними и теми-же файлами/драйверами дают довольно разные результаты!
И тогда приходится "рыться" уже в самой программе в поисках "узкого" места.

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru

В этой теме мне интересна трансформация взглядов на ТПС за год.
Не более года назад в этой же рассылке практически тем же составом участников говорилось о 10-30 т.записях как о критичном для формата.
Вопрос - что изменилось?

-
С уважением, SAN

(Добавление)

Добрый день

Более конкретно:
Каждое утро в базу закачивается (импортируется) информация (10-40 кб), и в течении дня происходит подобный процесс с меньшим объемом (1-5 кб), в результате этого еще и перестраиваются индексы дополненных баз.
Сравнение по времени: для пустой базы процесс занимает 3-5 секунд, для 1-5 метров в среднем минуту для 16-20 метров доходит до 10 минут, что уже серьезно раздражает бухгалтера. Причем это время примерно одинаково что для закачки 10-40 кб, что для 1-5 кб; из чего я делаю вывод, что основное время уходит на перестройку индексов ...
Насколько это так мне сложно судить, так как я не разработчик этого приложения, а скажем так продвинутый пользователь который должен обеспечивать комфортную работу бухгалтерам.
Поэтому и решил обратится за советом к профи.

На Clarion 5 и 5.5 эти базы никто не тестил, поэтому меня и интересет насколько по производительности поможет переход с 4 на 5.х
Кстати насколько трудоемок сам процесс переделки с 4 на 5.х ? Нужна просто перекомпиляция или кординальная переделка основной части кода, отчетов, форм ввода ?

Заранее спасибо за ответ.

С уважением, Прохоров Антон

А какой чипсет - в компьютере на котором это все происходит Intel 8.... или что-то другое ?

S.Sergey <savits@dol.ru>

От железа это не зависит - проблемы есть и на PIII и на PIV на интеловских чипсетах (точно были проблемы на i845).
Думаю дело именно в базе данных, но хочется определить "узкое место": само приложение, использование TPS-файлов для хранения или же 4 версия Клариона...

С уважением, Прохоров Антон

Вопрос - поскольку чипсет от интела - то стоит ли у тебя IntelR Application Accelerator ?

S.Sergey

Нет, это не используется. А что, оно помогает или мешает Клариону ?

С уважением, Прохоров Антон


(Добавление)

А нет в базе индексов по большим текстовым строкам? При создании таких индексов производительность падает катастрофически...

---------------------------------------
C уважением,
Юрий Философов,
Главный программист
Корпорация "Диполь", Саратов
E-mail yufil@tacis-dipol.ru (служ)
yufil@mail.ru (дом)
ICQ#75924439

Ключи минимизируй, режимы работы файлов по возможности в 40h, но это не очень просто.

--
С уважением, SAN mailto:vgsan@yandex.ru
Написал: ClaList(2)

Сравнение по времени: для пустой базы процесс занимает 3-5 секунд, для 1-5 метров в среднем минуту для 16-20 метров доходит до 10 минут, что уже серьезно раздражает бухгалтера. Причем это время примерно одинаково что для закачки 10-40 кб, что для 1-5 кб; из чего я делаю вывод, что основное время уходит на перестройку индексов ...

Ерунда какая то. Ну не может он при простом добавлении записей тормозить по 10минут на 20метрах.
Либо не работает транзакция/кеширование, либо еще какой косяк в программе.
Тем более странно что 10-40 и 1-5 ведут себя одинаково.
Поэтому возможен вариант - за каким то хреном после добавления делается Rebuild всей базы, а тут уж если ключи большие то огого.

Посмотри в текст - небось стоит:

Loop
...
Append(траля ля)
End
Build(ключ)

Сорри под рукой клаши нет, не помню какой "ключ" отвечает за полное перестроение.

Martin <martin@sochi.ru>

(Добавление)

Нет, это не используется. А что, оно помогает или мешает Клариону ?

Это лекарство надо сразу ставить ежели его нет - предварительно можно обновить драйверы от Intel - ( единственное он не поддерживает 865 чипсет ) - ввод твоих данных будет сразу раза в два - три идти быстрее.
Брать с сайта Intel - мультиязычную версию. Установить и забыть. Он грузится сам после загрузки ОС и обеспечивает ускорение работы с HDD.

S.Sergey <savits@dol.ru>

Нужно только не забыть об очень хорошем УПС под сервант с таким драйвером. А то все данные могут и того, т.к. все ускорение у таких "акселераторов" только из-за использования отложенной записи.

Martin <martin@sochi.ru>


(Добавление)

Нужна просто перекомпиляция или кординальная переделка основной части кода, отчетов, форм ввода ?

Судя по всему, программа, которой Вы пользуетесь, написана не очень оптимально.
Для примера - так-же, каждый день, три раза, производится добавление в рабочую базу новой инфы из Инета - документы, анкеты и пр. За раз бывает до нескольких тысяч записей общим обьемом порядка метра. Весь этот процесс занимает не более минуты - точно не скажу - никому даже и в голову не приходило замерять, т.к. задержка, фактически, мизерная!
При этом общий обьем БД - ~200-300метров. Размер самых нагруженных таблиц - от 50метров до 100метров.
И, честно скажу, админы, которые запускают этот процесс, даже и не замечали особой разницы по времени в зависимости от общего обьема БД!
Никакой доп. индексации не производится - зачем?

Попробуй весь этот процесс "обернуть" в рамки транзакции - что-то мне подсказывает, что там не используется ни транзакция ни стрем?!

Не более года назад в этой же рассылке практически тем же составом участников говорилось о 10-30 т.записях как о критичном для формата.
Вопрос - что изменилось?

Насколько я помню, об этой "критичности" говорил тогда только Вадим, и то - ссылаясь на рекомендации самих разработчиков TS/SV. И там-же, он сам и писал, что этот "критичный" размер можно легко увеличить.

В моей практике не было НИ ОДНОГО случая, что-бы "рушились" таблицы такого детского размера!
Подобные проблемы стали появлятся на "активных" таблицах только тогда, когда счет кол-ва записей в них пошел на сотни тысяч. И то - только иногда в конце месяца, когда очень (раз в 10) увеличивалась активность сетевых рабочих мест.
Причем, после того, как админы начали заменять некоторые "проблемные" сетевые карточки на заведомо исправные, частота таких сбоев сильно уменьшилась!

Часто приходится чинить?
И по какой причине база ломается?

В зависимости от (по приоритету, имхо):
- кол-во активных рабочих станций в сети - соответственно, размеры сетки и бОльшая вероятность наличия в ней "битого" или "проблемного" железа. TPS очень чувствителен к аппартным проблемам. Особенно - при выполнении транзакций.
Более подробно - читай мои статьи по этой теме.
- размер таблиц, причем важен как сам их размер (точнее - размер одной записи), так и кол-во записей в них. Связано с тем, что увеличивается общее время транзкации и, соответственно, увеличивается риск "нарваться" на аппартный сбой.
- как написана сама программа, особенно - код пакетных модификаций БД, если таковые есть.

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

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru

(Добавление)

Каждое утро в базу закачивается (импортируется) информация (10-40 кб), и в течении дня происходит подобный процесс с меньшим объемом (1-5 кб), в результате этого еще и перестраиваются индексы дополненных баз.

Узкое место - как раз там, где тормозит.
Лично мне совершенно непонятно, зачем перестраивать в этом месте индексы. Это раз. А два в том, что в свойствах драйвера включено полное перестроение ключей. Три - это, как уже говорил Юрий Философов, проиндексированы длинные строки.

С уважением,
В.Смелик.

У меня была полностью аналогичная ситуация.

Сравнение по времени: для пустой базы процесс занимает 3-5 секунд, для 1-5 метров в среднем минуту для 16-20 метров доходит до 10 минут, что уже серьезно раздражает бухгалтера. Причем это время примерно одинаково что для закачки 10-40 кб, что для 1-5 кб; из чего я делаю вывод, что основное время уходит на перестройку индексов ...

Совершенно справедливо. Можно заметно ускорить оборачиванием в транзакцию.
Там сильно тормозить начнет когда весь файл не поместится в RAM и начнется интенсивный своп. Но с 15-20 М это не грозит. Это проблема для файлов в неск. сотен Мег. Еще надо предусмотреть бэкап перед доливом, чтобы не откатывать в случае чего, а просто скопировать назад файлы бэкапа.

Кстати насколько трудоемок сам процесс переделки с 4 на 5.х ? Нужна просто перекомпиляция или кординальная переделка основной части кода, отчетов, форм ввода ?

Если есть сгенерированные исходники, то можно просто перекомпилировать.
Обычно всегда можно подсунуть старые шаблоны и перегенерировать.

WBR, Nick Tsigouro. MailTo:Nick@arsis.ru


(Добавление)

RAM Drive в живой природе существует?

Вполне. Я пользовал на 2K. Сущ. и для 9х. Есть предел - 256M. Связано с какими-то особенностями управления памятью. Больше тоже можно, но там хитрости и я не разбирался, т.к. было не актуально. Между проч. на него оч. приятно Make в клаше делать.

А почему только на изолированной машине?

А вопрос был так поставлен.

Есть приложение (работа с локально на винчестере расположенной БД),

А для сетки кэширование должен обеспечивать файл сервер.

Nick Tsigouro <nick@arsis.ru>

У меня есть RAMDisk. Весит всего 98K. Работает уже пару лет. Проблем не замечено. Для прог вроде 1С помогает здорово. Для клаши ХЗ, но вероятно тоже (хотя если все в QUEUE делать то не очень).

Martin

Но все же, хоть чуть-чуть помогает? Интересно, как виртуальный диск ускоряет работу QUEUE?...

WBR, Nick Tsigouro

Но все же, хоть чуть-чуть помогает?

Если сам файл на рамдиск скинуть то индексы создаются пошустрее.

Интересно, как виртуальный диск ускоряет работу QUEUE?...

Никак. Но ведь не все происходит в QUEUE. Я имел в виду, что если проблемные отчеты написаны с использованием QUEUE то использование RAM disk не имеет особого смысла.

Martin
Написал: ClaList(2)

У меня есть RAMDisk. Весит всего 98K. Работает уже пару лет. Проблем не замечено.

Дай поиграться

Более подробно - читай мои статьи по этой теме.

Где? URL?

--
С уважением,
Степанец Александр Валентинович.

Часть из них была, если мне не изменяет память, на ClarionLife. В любом случае их можно найти в архиве данной рассылки.

=============================
С уважением, Олег А. Руденко

Думаю дело именно в базе данных, но хочется определить "узкое место": само приложение, использование TPS-файлов для хранения или же 4 версия Клариона...

Видимо всетаки дело в программе Добавлять записи в базы нужно командой APPEND а потом перестраивать индексы Если это делается командой ADD , то это будет очень долго
Только не ясно как это будет работать в сети

С уважением
Виктор
vlenkov@mail.ru
icq 310260270
Написал: ClaList(2)

Абсолютно точно (есть печальный опыт), что максимальный размер TPS-файла для С55 - 2Gb (что и было отыскано в спецификациях TPS после суток мучительных поисков причины трагедии). При превышении этого размера файл делает себе харакири с помощью Possible Data Corruption (1477), и лечится только TPSFix'ом. И всё же проблема была решена...

А может быть у тебя просто в таблице подбиваютя суммы?
При добавлении записи суммы пересчитываются...
Можно подбивать суммы только тогда, когда user-у надо, например пусть давит на кнопку.

Финогенов константин.

У меня есть RAMDisk. Весит всего 98K. Работает уже пару лет

А как на счет выложить куда нибудь?
Написал: Mixer(144)

Привет !

В свое время сталкивались с аналогичной проблемой.
Наболее простое решение замена TPS на Btrieve.

Если еще в качестве БД будет использоваться Pervasive.SQL V8
- то реальный выигрыш скорости будет в 3-4 раза.

Этот способ не требует замены версии инструментального
средства и практически не нужно модифицировать код программы
(в отличии от перехода на SQL). Более того, можно развивать
программу одновременно и с TPS и в Btrieve заменяя только
словари при сборке проекта.

Рекомендую рассмотреть такой вариант.

С уважением, ТАТА.