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)
