25.10.2005, 16:45 | #41 |
Moderator
|
У меня прям сейчас работает. Попробуй нажать "Обновить".
|
|
25.10.2005, 16:46 | #42 |
Участник
|
Цитата:
Сообщение от komar
Private HotFix - звучит круто. И почему для меня такие не делают? Пошел в саппорт, добывать этот Ваш секретный фикс...а то так бы и не узнал о его существовании - номера нет, информации нет, на партнергайде нет.....он сам-то в природе есть?
Если да, то пригодился или полная ерунда? |
|
25.10.2005, 16:51 | #43 |
Шаман форума
|
Что-то добыл, пока не тестировал. В основном проблемы решали самодельными заплатками, которые либо используют функции SmartHeap (можно поискать по этому форуму и форуму mazzy по слову SmartHeap), либо разбивают объем обрабатываемых данных на куски (чтобы сервак не успевал загнуться, пока идет операция). Говорят, на MS SQL обязательно нужно ставить новый MDAC. На Оракле это не помогает.
|
|
25.10.2005, 17:31 | #44 |
Member
|
Цитата:
Сообщение от komar
...
На Оракле это не помогает. ...
__________________
С уважением, glibs® |
|
31.10.2005, 10:04 | #45 |
Участник
|
Кто нибудь нашел как решить проблему утечки памяти в SP4?
При обновлении перекрестных ссылок в 2-tier (в 3-tier) программа вылетает. Т.е. своп растет (не по дням, а по часам), в конце концов все заканчивается вылетом программы. Тестили на разных компах (1 комп 4 xeon 2.8Gz 1 Gb RAM, 2 комп 1 проц Atlohh 1.7Gz 1 gb Ram) , ставили "чистую" аксу - не помогает. |
|
31.10.2005, 10:25 | #46 |
Шаман форума
|
Цитата:
Сообщение от SeregaG
Кто нибудь нашел как решить проблему утечки памяти в SP4?
При обновлении перекрестных ссылок в 2-tier (в 3-tier) программа вылетает. Т.е. своп растет (не по дням, а по часам), в конце концов все заканчивается вылетом программы. Тестили на разных компах (1 комп 4 xeon 2.8Gz 1 Gb RAM, 2 комп 1 проц Atlohh 1.7Gz 1 gb Ram) , ставили "чистую" аксу - не помогает. Oracle? |
|
31.10.2005, 10:33 | #47 |
Участник
|
MDAC 2.8
MS SQL SP3A Сейчас хочу поксперементировать с экзешниками от SP3 |
|
31.10.2005, 15:27 | #48 |
Member
|
Цитата:
Сообщение от SeregaG
...
в конце концов все заканчивается вылетом программы. Тестили на разных компах (1 комп 4 xeon 2.8Gz 1 Gb RAM, 2 комп 1 проц Atlohh 1.7Gz 1 gb Ram) ... Или ax32.exe от сп3 используйте.
__________________
С уважением, glibs® |
|
31.10.2005, 16:37 | #49 |
Шаман форума
|
Цитата:
Сообщение от glibs
А у меня построились. Правда, сожрала 2 с хвостиком Гб виртуальной памяти. Так что добавьте виртуальной памяти побольше.
Или ax32.exe от сп3 используйте. |
|
01.11.2005, 16:46 | #50 |
Moderator
|
После того как я поставил вызовы heapCheck в xRefCreate::updateReferences() и в xRefCreate::updateDBReferences() - отъедание памяти кончилось.
В xrefCreate::updateReferences() надо вставлять вызовы heapCheck.shrinkPool() и heapCheck.postCompactingMessage() в конец условия: if (counter>500) { } В xRefCreate:updateDBReferences() - просто в самом конце функции - перед return. На самом деле во время обновления перекрестных ссылок система постоянно создает нехилые mapы состоящие из structов, потом после того как таких элементов накопится 500 штук - она их записывает в базу (в функции updateReference), а затем удаляет. А от этого случается нехилая фрагментация памяти, от которой постоянно приходится захватывать новую оперативку у системы и тп. После того как мы поставили вызовы сжатия памяти и в двух методах (один всегда на клиенте отрабатывает, второй - может и на сервере и на клиенте работать), дефрагментация памяти прошла и потребности ее все время у операционки захватывать - нету. Последний раз редактировалось fed; 02.11.2005 в 11:09. |
|
03.11.2005, 13:11 | #51 |
Участник
|
Данный метод так же не помог, хотя тестировали и в тонком и толстом клиенте.
Вариант м.б. только таким: запускать перекрестные ссылки отдельно для каждой ветви (таблицы, классы и т.д.), после чего выходить из программы, чтобы освободить память. Или добыть загадочный private hotfix... |
|
|
За это сообщение автора поблагодарили: Logger (1). |
03.11.2005, 13:31 | #52 |
Участник
|
А у меня прокатило (спасибо, fed!), в "локальной 2-х звенке" на почти стандартном приложении на достаточно скромной машинке, swap ~1.5 Гб, за 4.3 часа, галки ставил все, но без удаления, и попытка была 3-ей.
С уважением, itfs. |
|
16.11.2005, 11:04 | #53 |
Участник
|
Кстати, никто не обратил внимания, у меня в about остался SP3, хотя номера build-ов и даты выпуска поменялись, это у всех так?
С уважением, itfs. |
|
16.11.2005, 12:31 | #54 |
Member
|
Если речь идет об приведенной ниже картине, то там через "/" указаны:
1. Номер билда клиента 2. Номер СП базовой функциональности 3. Номер версии Option pack (функциональность, что живет на GLS слое) Есть еще [4]. Это версия локализации. Уточните, пожалуйста, в чем заключается ваш вопрос.
__________________
С уважением, glibs® |
|
|
За это сообщение автора поблагодарили: (3). |
16.11.2005, 13:40 | #55 |
Участник
|
Спасибо за развернутый ответ, но вопрос снят, ручки кривые, не на всех приложениях галки поставил при установке SP ....
C уважением, itfs. |
|
16.11.2005, 16:19 | #56 |
Участник
|
Цитата:
Сообщение от glibs
Если речь идет об приведенной ниже картине, то там через "/" указаны:
1. Номер билда клиента 2. Номер СП базовой функциональности 3. Номер версии Option pack (функциональность, что живет на GLS слое) Есть еще [4]. Это версия локализации. http://forum.mazzy.ru/index.php?showtopic=881 |
|
26.01.2006, 10:29 | #57 |
Участник
|
Цитата:
Сообщение от ALEG
А Вы можете воспроизвести проблему в SP4? А лучше в последнем Kernel Rollup?
Будем тестировать и дальше. Но пока результаты положительные. Не забудьте выполнить рекомендации Алексея Еременко для русского языка. |
|
26.01.2006, 17:06 | #58 |
Шаман форума
|
Проблема решена для каких операций и для каких инсталляций? Решена ли она для Оракловых инсталляций? Решена ли она для разноски журналов по 10-20-70-100 тысяч строк?
Не будет ли случаться беда при расчете амортизации на 100 тысяч объектов по 3 моделям? Или при построении налоговых регистров по таким объемам данных? Или тестирование проводилось исключительно на перекрестных ссылках?
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately. |
|
26.01.2006, 18:04 | #59 |
Участник
|
Цитата:
Сообщение от komar
Проблема решена для каких операций и для каких инсталляций? Решена ли она для Оракловых инсталляций? Решена ли она для разноски журналов по 10-20-70-100 тысяч строк?
Не будет ли случаться беда при расчете амортизации на 100 тысяч объектов по 3 моделям? Или при построении налоговых регистров по таким объемам данных? Или тестирование проводилось исключительно на перекрестных ссылках? Потихоньку планирую тестировать и в других режимах. Уважаемые участники, если вы проверили работоспособность rollup на указанных komar'ом режимах, напишите сюда пожалуйста. |
|
26.01.2006, 18:56 | #60 |
Гость
|
Строил ссылки на mssql2005, все чики-пики, порядка 100М скушала
интереснее было бы производительность сравнить, с 2000 сервером например |
|
Теги |
ax3.0, баг, ошибка, утечка памяти |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|