Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
21.11.2011, 14:19
|
|||
|---|---|---|---|
|
|||
Поиск утечки памяти. Настройка logcfg.xml |
|||
|
#18+
Добрый день. Пару недель назад начались утечки памяти. В течение двух суток объем памяти занимаемой rphost постепенно увеличивается, достигает полутора гигабайт, память на сервере заканчивается и приходится перезагружать сервер. В случае если корректно завершить все клиентские сеансы - память также не очищается. Попробовал отследить утечку памяти при помощи технического журнала . Для этого создал файл logcfg.xml такой структуры: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. При такой конфигурации в логи не выводится вообще ничего. С другой конфигурацией, например такой: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. Подскажите пожалуйста - как "выловить" это проблемное место в котором происходит утечка памяти. Версия платформы 1С 8.1.15.14 СУБД Microsoft SQL Server 2005 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.11.2011, 14:35
|
|||
|---|---|---|---|
|
|||
Поиск утечки памяти. Настройка logcfg.xml |
|||
|
#18+
КонсольЗаданий.epf смотрели? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.11.2011, 14:58
|
|||
|---|---|---|---|
|
|||
Поиск утечки памяти. Настройка logcfg.xml |
|||
|
#18+
Нет, не смотрел. В учетной системе выполняются и регламентированные задания и планировщиком Windows есть вызовы, когда задание надо отработать на стороне клиента. Но про все эти фоновые задания я знаю и, если бы утечка началасть после каких-то изменений связанных с одним из фоновых заданий - действительно первым делом начал бы подробно разбираться с этим заданием. Никаких новых заданий не добавлял и не модифицировал, изменений в них не было ну минимум несколько месяцев, насколько я помню. Примерно в это время как начались утечки памяти я занимался Внешней обработкой Отчетами Процедурой которая вызывается из модулем проведения в нескольких документов, но изменял только логику. В упор не помню чтобы добавлял работу с таблицами значений или массивами. Поэтому и начал поиски при помощи технического журнала. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.11.2011, 11:20
|
|||
|---|---|---|---|
Поиск утечки памяти. Настройка logcfg.xml |
|||
|
#18+
Дмитрий ЗайцевНет, не смотрел. В учетной системе выполняются и регламентированные задания и планировщиком Windows есть вызовы, когда задание надо отработать на стороне клиента. Но про все эти фоновые задания я знаю и, если бы утечка началасть после каких-то изменений связанных с одним из фоновых заданий - действительно первым делом начал бы подробно разбираться с этим заданием. Нжурнала. И все же смотри в сторону заданий. Дело в том, что ты можешь ничего не менять: просто алгоритм заданий по каким-то причинам стал обрабатывать больше данных и утечка стала заметной. Пример из личной практики: написал я как-то подсистему, которая на основе штатного механизма версионирования позволяла навешивать на базу определяемые пользователем условные события с извещениями. Например, пришел платеж > 5 млн.руб. - извещение. Пока в справочнике отслеживаемых событий было немного, все работало нормально. Как только количество "хотелок" перевалило за несколько десятков, фоновый процесс стал забирать более 2Г памяти и "вешать" сервер. Оптимизировал код, переписал фоновое задание таким образом, что за один запуск анализируется только одно событие - и все стало Ok. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.11.2011, 11:22
|
|||
|---|---|---|---|
Поиск утечки памяти. Настройка logcfg.xml |
|||
|
#18+
Верный признак того, что "виснет" задание - увеличение его времени выполнения. Кроме того, ты можешь в журнале регистрации посмотреть № сеанса, под которым запущено задание и потом в консоли сервера увидеть объем занимаемой памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.12.2011, 15:17
|
|||
|---|---|---|---|
|
|||
Поиск утечки памяти. Настройка logcfg.xml |
|||
|
#18+
Во-первых хочу поблагодарить за ответы. Причину утечки выяснил. Это было не регламентированное задание. В начале сентября (то-есть около двух месяцев до возникновения проблемы) заниматься оптимизацией на стороне SQL-Server-a. Вобщем "игрался" с параметрами. Есть такой параметр max full-text crawl range Код: sql 1. У меня двухпроцессорный сервер, четыре ядра на каждый процессор. Установил значение параметра в 16 (было 0), посмотрел пару дней - вроде никак не повлияло на производительность. Вернуть в прежнее значение - забыл. Дальше события развивались так: В начале ноября начала наблюдаться утечка памяти. Приходилось перегружать сервер раз в сутки/ в двое суток. Пямять забивал процесс rphost - сервер приложения 1С. Среди всех возможных причин проблемы я вспомнил об этом злополучном параметре. Установил его в 4. Утечка памяти значительно уменьшилась, но все равно продолжалась. Установил его в значение 1 - утечка памяти практически прекратилась, но за сутки rphost все равно приростал на сотню/две мегабайт. После установки max full-text crawl range в 0 - проблема утечки памяти прекратилась. Конечно после всего этого у меня остались вопросы, ответы на которые скорее всего кроются в сферах непознаного и мистического: Почему утечка началась не сразу, а только спустя два месяца. Какое отношение параметр, который по сути должен влияеть только на работу запросов, в которых происходит полное сканирование индекса, имеет к механизмам выделения и очистки памяти сервера приложений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=28&tablet=1&tid=1520808]: |
0ms |
get settings: |
6ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
48ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
21ms |
get tp. blocked users: |
1ms |
| others: | 222ms |
| total: | 317ms |

| 0 / 0 |
