Растет swap файл. Как узнать почему.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) SuhoffGV, Тоже страдаю от подобной проблемы.
Пока остановился на том, что дело в регламентных заданиях. Если заблокировать их через утилиту администрирования, утечки пропадают. Вполне вероятно, что плохо себя ведет только одно задание, надо лишь его найти.
Пока остановился на том, что дело в регламентных заданиях. Если заблокировать их через утилиту администрирования, утечки пропадают. Вполне вероятно, что плохо себя ведет только одно задание, надо лишь его найти.
(3) SuhoffGV, платформа последняя? В нескольких ранних были утечки.
Ошибки исправленные в 8.2.15.318
10100226 Постепенная утечка памяти в процессе rphost и rmngr
Ошибки исправленные в 8.2.15.319
20005912 (SW701767) Быстрый рост объема памяти, занимаемой рабочим процессом кластера
20005912 (SW701767) Быстрый рост объема памяти, занимаемой рабочим процессом кластера
Ошибки исправленные в 8.2.15.318
10100226 Постепенная утечка памяти в процессе rphost и rmngr
(4) б#я, как же они за###ли. криворукие 1с-сные разработчики.
Хоть бы рассылку какую делали.
С 318 ушел по этой же причине, а вот в 319 проглядел.
Спс. Ушел обновлять платформу.
ps сбил с толку ответ саппорта 1с. я им писал что у меня версия платформы 8.2.15.319, их это не смутило. Из чего я сделал вывод что платформа не при чем.
Хоть бы рассылку какую делали.
С 318 ушел по этой же причине, а вот в 319 проглядел.
Спс. Ушел обновлять платформу.
ps сбил с толку ответ саппорта 1с. я им писал что у меня версия платформы 8.2.15.319, их это не смутило. Из чего я сделал вывод что платформа не при чем.
Все верно, в 8.2.16.хх процессы 1С стали отъедать меньше памяти и начали нормально отдавать занятую память.
Но, все равно, самое лучшее решение ночью рестартовать 1С по крону, иначе при длительной работе, даже бэкап не удается сделать.
Но, все равно, самое лучшее решение ночью рестартовать 1С по крону, иначе при длительной работе, даже бэкап не удается сделать.
(6) niram,
не мудрите, утечки в памяти и кэшируемые данные - совершенно разные вещи. 1С НЕ РАБОТАЕТ с HDD как с памятью напрямую, пора бы уже знать такие вещи.
(1) SuhoffGV,
Утечки по памяти - да, есть такое, и ничего особо не исправили ни в 8.2.16, ни в 8.2.17. Нужна разбивать на несколько рабочих процессов, если один разжирается. Ну и вообще, поработать в консоли 1С с процесамми, настроить их временнОй терминэйт, нагрузку, приоритеты.
Отследите, кто из пользователей максимально грузит rphost - скорей всего, кто-то запускает огромный отчет, либо - какие другие гигантские объемы обработки данных.
Это если фоновые ничего не делают.
Отсюда и вывод будет, что делать и как бороться.
(4) psier,
Во всех последних - наблюдаются утечки в том или ином размере (в 8.2.15 - огромные и быстро, 8.2.17 - меньше и медленно).
Так что ничего не исправили. Одни идентичные "поправки" по утечкам из релиза в релиз в баглисте говорят о многом...
(13) Sanella_nt,
Вирус кэширует данные в своп? Придумайте что-нибудь более реальное.
А по памяти - 1С сама как вирус все забивает прекрасно.
1С стали отъедать меньше памяти
не мудрите, утечки в памяти и кэшируемые данные - совершенно разные вещи. 1С НЕ РАБОТАЕТ с HDD как с памятью напрямую, пора бы уже знать такие вещи.
(1) SuhoffGV,
Утечки по памяти - да, есть такое, и ничего особо не исправили ни в 8.2.16, ни в 8.2.17. Нужна разбивать на несколько рабочих процессов, если один разжирается. Ну и вообще, поработать в консоли 1С с процесамми, настроить их временнОй терминэйт, нагрузку, приоритеты.
Отследите, кто из пользователей максимально грузит rphost - скорей всего, кто-то запускает огромный отчет, либо - какие другие гигантские объемы обработки данных.
Это если фоновые ничего не делают.
Отсюда и вывод будет, что делать и как бороться.
(4) psier,
Во всех последних - наблюдаются утечки в том или ином размере (в 8.2.15 - огромные и быстро, 8.2.17 - меньше и медленно).
Так что ничего не исправили. Одни идентичные "поправки" по утечкам из релиза в релиз в баглисте говорят о многом...
(13) Sanella_nt,
Вполне возможно что вирус
Вирус кэширует данные в своп? Придумайте что-нибудь более реальное.
А по памяти - 1С сама как вирус все забивает прекрасно.
(14) AlexO,
Процессов изначально 8, по числу ядер в процессоре.
По пользователям - даже запуск перерасчета себестоимости бухом не вызывает сколь-нибудь заметного увеличения размера swap.
Можно подробнее про "настроить их временнОй терминэйт, нагрузку, приоритеты"? Есть какой нибудь вменяемый мануал про это?
Косвенное подтверждение про необходимость рестартовать rphost есть в . Там правда не 1с+postgres, а "скрипт"+postgres. Явление то-же самое. При длительном коннекте скрипта с субд растет занимаемая память.
Возможно это проблема связки 1с+postgres, а не только 1с.
Это если фоновые ничего не делают.
Отсюда и вывод будет, что делать и как бороться.
Зуб даю, что не делают. Заявку в 1с поднял ещё осенью, когда то-ли 15- толи 16-я версия была. Все логи для них собрал и тишина.
(4) psier,
Во всех последних - наблюдаются утечки в том или ином размере (в 8.2.15 - огромные и быстро, 8.2.17 - меньше и медленно).
Так что ничего не исправили. Одни идентичные "поправки" по утечкам из релиза в релиз в баглисте говорят о многом...
"Список изменений:
1. Исправили старые баги.
2. Добавили новые баги.
3. Неисправленные баги перевели в фичи."
Утечки по памяти - да, есть такое, и ничего особо не исправили ни в 8.2.16, ни в 8.2.17. Нужна разбивать на несколько рабочих процессов, если один разжирается.
Процессов изначально 8, по числу ядер в процессоре.
Ну и вообще, поработать в консоли 1С с процесамми, настроить их временнОй терминэйт, нагрузку, приоритеты.
Отследите, кто из пользователей максимально грузит rphost - скорей всего, кто-то запускает огромный отчет, либо - какие другие гигантские объемы обработки данных.
Отследите, кто из пользователей максимально грузит rphost - скорей всего, кто-то запускает огромный отчет, либо - какие другие гигантские объемы обработки данных.
По пользователям - даже запуск перерасчета себестоимости бухом не вызывает сколь-нибудь заметного увеличения размера swap.
Можно подробнее про "настроить их временнОй терминэйт, нагрузку, приоритеты"? Есть какой нибудь вменяемый мануал про это?
Косвенное подтверждение про необходимость рестартовать rphost есть в . Там правда не 1с+postgres, а "скрипт"+postgres. Явление то-же самое. При длительном коннекте скрипта с субд растет занимаемая память.
Возможно это проблема связки 1с+postgres, а не только 1с.
Это если фоновые ничего не делают.
Отсюда и вывод будет, что делать и как бороться.
Зуб даю, что не делают. Заявку в 1с поднял ещё осенью, когда то-ли 15- толи 16-я версия была. Все логи для них собрал и тишина.
(4) psier,
Во всех последних - наблюдаются утечки в том или ином размере (в 8.2.15 - огромные и быстро, 8.2.17 - меньше и медленно).
Так что ничего не исправили. Одни идентичные "поправки" по утечкам из релиза в релиз в баглисте говорят о многом...
"Список изменений:
1. Исправили старые баги.
2. Добавили новые баги.
3. Неисправленные баги перевели в фичи."
А утилитой - ProcessMonitor (тогоже производителя) можно посмотреть кто лазит в своп...
Несмотря на безапеляционное заявление AlexO (14) - лично я встречал вирус который "раздувал" своп - правда это было лет 7 назад и подробностей я не помню. Так что просканировать систему несколькими антивирусами наверно будет нелишним.
Здесь (42) я кратко описал как можно посмотреть что в свопе
Несмотря на безапеляционное заявление AlexO (14) - лично я встречал вирус который "раздувал" своп - правда это было лет 7 назад и подробностей я не помню. Так что просканировать систему несколькими антивирусами наверно будет нелишним.
Здесь (42) я кратко описал как можно посмотреть что в свопе
(12), (16), (17)
Ну это вам наврядли поможет. Память занятая под буферный кэш итак перераспределяется приложениям, когда они того требуют.
Кстати размер SWAP=RAM это спорное решение. Классическая рекомендация SWAP=2*RAM. Конечно, радикально не спасет,
но, скорее всего, позволит оттянуть "кончину". Память, занятая в результате утечек будет выгружаться в своп пока в нем есть место.
Ну это вам наврядли поможет. Память занятая под буферный кэш итак перераспределяется приложениям, когда они того требуют.
Кстати размер SWAP=RAM это спорное решение. Классическая рекомендация SWAP=2*RAM. Конечно, радикально не спасет,
но, скорее всего, позволит оттянуть "кончину". Память, занятая в результате утечек будет выгружаться в своп пока в нем есть место.
(18) wkon,
Такие мысли были. Но это не решает проблему и swap раздел уже не увеличить. Только делать ещё, в виде файла.
Попробовал пока сделать как написано в .
"12. Поочередно, с интервалом 5-20 мин. перевожу рабочие процессы из состояния "Использовать" в состояние "Не использовать" и обратно. Цель - сделать процесс автоматического перезапуска рабочих процессов последовательным. Интервал перезапуска устанавливаю 7200 сек. "
Посмотрю что получится.
Кстати размер SWAP=RAM это спорное решение. Классическая рекомендация SWAP=2*RAM. Конечно, радикально не спасет,
но, скорее всего, позволит оттянуть "кончину". Память, занятая в результате утечек будет выгружаться в своп пока в нем есть место.
но, скорее всего, позволит оттянуть "кончину". Память, занятая в результате утечек будет выгружаться в своп пока в нем есть место.
Такие мысли были. Но это не решает проблему и swap раздел уже не увеличить. Только делать ещё, в виде файла.
Попробовал пока сделать как написано в .
"12. Поочередно, с интервалом 5-20 мин. перевожу рабочие процессы из состояния "Использовать" в состояние "Не использовать" и обратно. Цель - сделать процесс автоматического перезапуска рабочих процессов последовательным. Интервал перезапуска устанавливаю 7200 сек. "
Посмотрю что получится.
не жалуюсь и это не мокус а вполне официальная фича ну разве что придется выбирать между глубиной очистки от 1 до 3. обычно хватает 1 но если ест много то 3 но при этом могут быть не предсказумые последствия.
если на вайне работает то тут мне нечго сказать а если как защищенный портал то 3 сойдет.
если на вайне работает то тут мне нечго сказать а если как защищенный портал то 3 сойдет.
Попытка ограничить через limits.conf не удалась, т.к. ограничение там идет на каждый процесс.
Поступил как в сообщении , настроив cgroups. Пришлось для этого ставить ядро из backports (debian x64) и передавать ему cgroup_enable=memory при загрузке.
Кроме описанного по ссылке ограничения памяти (memory.limit_in_bytes = <лимит_в_байтах>), добавил параметр memory.swappiness=0
Пока работает. Основная память не доходит до лимита (что странно, т.к. раньше уходила дальше). Кэш занимает почти весь свободный объем, но в своп не идет.
Если графики такие же, как , то может помочь простое изменение vm.swappines=0 в /etc/sysctl.conf
Поступил как в сообщении , настроив cgroups. Пришлось для этого ставить ядро из backports (debian x64) и передавать ему cgroup_enable=memory при загрузке.
Кроме описанного по ссылке ограничения памяти (memory.limit_in_bytes = <лимит_в_байтах>), добавил параметр memory.swappiness=0
Пока работает. Основная память не доходит до лимита (что странно, т.к. раньше уходила дальше). Кэш занимает почти весь свободный объем, но в своп не идет.
Если графики такие же, как , то может помочь простое изменение vm.swappines=0 в /etc/sysctl.conf
(24) psier, насчет vm.swappines=0 в /etc/sysctl.conf - пробовал и так, все равно не помогает, даже еще хуже: в определенный (ессно, самый подходящий :-) момент может привести к зверским тормозам. Утечки-то все равно никуда не деваются.
Впрочем, на релизе 8.2.18.61 уже две недели своп 12 МБ и не меняется.
Впрочем, на релизе 8.2.18.61 уже две недели своп 12 МБ и не меняется.
(27) 6 дней на 8.2.18.61 + одновременно с этим увеличил оперативку сервера с 8 до 48Gb (жаль больше нельзя - ограничения платформы HP).
swap в пределах 100Мb оперативка - больше 6 не поднималась.
После увеличения размера оперативки вдвое ускорились процессы выгрузки дампа базы из постгрес и dt из 1с.
Выгрузка в dt размером 4.2Gb раньше выгружалась ~ 25-30 мин. Теперь ~15мин. Это плюсы оперативки. После добавления памяти и перед переходом на 8.2.18.61 проверил выгрузку на 8.2.17.153 - прирост скорости есть.
swap в пределах 100Мb оперативка - больше 6 не поднималась.
После увеличения размера оперативки вдвое ускорились процессы выгрузки дампа базы из постгрес и dt из 1с.
Выгрузка в dt размером 4.2Gb раньше выгружалась ~ 25-30 мин. Теперь ~15мин. Это плюсы оперативки. После добавления памяти и перед переходом на 8.2.18.61 проверил выгрузку на 8.2.17.153 - прирост скорости есть.
(31)22.83
Сервер HP Ml150G6, 1 проц Intel® Xeon® CPU E5520 @ 2.27GHz, 8 cores
48ОЗУ, винты - 2*300Gb SAS в зеркале под базы и 2*146Gb SAS под систему. RAID - железный с кэшем и батарейкой.
Centos 64bit, postgres 64bit.
Правда валится с ошибкой "{Обработка.TCP_1C_GILV.Форма.Форма(505)}: Ошибка при вызове конструктора (COMОбъект): Недопустимая строка с указанием класса: Недопустимая строка с указанием класса"
В причинах не разбирался.
В ближайших планах переход на 1с 64bit. База растет, выгрузку в dt можно сделать только после перезагрузки сервера. Не хватает памяти, точнее 1с 32бит не может её использовать. Жду приезда ключа.
Сервер HP Ml150G6, 1 проц Intel® Xeon® CPU E5520 @ 2.27GHz, 8 cores
48ОЗУ, винты - 2*300Gb SAS в зеркале под базы и 2*146Gb SAS под систему. RAID - железный с кэшем и батарейкой.
Centos 64bit, postgres 64bit.
Правда валится с ошибкой "{Обработка.TCP_1C_GILV.Форма.Форма(505)}: Ошибка при вызове конструктора (COMОбъект): Недопустимая строка с указанием класса: Недопустимая строка с указанием класса"
В причинах не разбирался.
В ближайших планах переход на 1с 64bit. База растет, выгрузку в dt можно сделать только после перезагрузки сервера. Не хватает памяти, точнее 1с 32бит не может её использовать. Жду приезда ключа.
(32) SuhoffGV, Маловато чего-то. У меня в разгар рабочего дня 36-38, а когда народа нет, так и более 40.
В последней версии теста этой ошибки нет. Хотя она и в старой не мешает.
64-битную систему сам бог велел, смысл тогда в 48 ГБ ОЗУ :-)
Кстати, проц Е5520 имеет 4 ядра, а со включенным гипертредингом и получается 8 потоков. Я тут пришел к выводу, что все-таки лучше брать проц с тактовой как можно выше. Очень сильная получается разница в производительности системы на E3-1220 и E3-1240 с отключенным HT (т.е. при одинаковом кол-ве потоков).
Вам бы проц с тактовой под 3,5 ГГц, отличный бы сервер вышел. Жаль, среди E55xx потолок - 2,5/2,8 turbo.
В последней версии теста этой ошибки нет. Хотя она и в старой не мешает.
64-битную систему сам бог велел, смысл тогда в 48 ГБ ОЗУ :-)
Кстати, проц Е5520 имеет 4 ядра, а со включенным гипертредингом и получается 8 потоков. Я тут пришел к выводу, что все-таки лучше брать проц с тактовой как можно выше. Очень сильная получается разница в производительности системы на E3-1220 и E3-1240 с отключенным HT (т.е. при одинаковом кол-ве потоков).
Вам бы проц с тактовой под 3,5 ГГц, отличный бы сервер вышел. Жаль, среди E55xx потолок - 2,5/2,8 turbo.
(33) audion,
в отсутствии "жора" свопа. "И пусть этотхомяк сервер1с подавится."
А переход на 64 из за того что начали пихать в базу файлы и она начала быстро расти. Выгрузка в dt весит 6Gb.
Так бы ещё посидели на 32 битной.
Переставлю на 64 сделаю замер ещё раз.
А так, производительности вроде хватает.
64-битную систему сам бог велел, смысл тогда в 48 ГБ ОЗУ :-)
в отсутствии "жора" свопа. "И пусть этот
А переход на 64 из за того что начали пихать в базу файлы и она начала быстро расти. Выгрузка в dt весит 6Gb.
Так бы ещё посидели на 32 битной.
Переставлю на 64 сделаю замер ещё раз.
А так, производительности вроде хватает.
А, вон оно в чем дело. Тогда конечно.
Впрочем, если есть утечки памяти, то сожрет хоть 48, хоть 196 гиг, это лишь дело времени.
У моего сервера сейчас аптайм 96 суток, и своп - 536 МБ из 32 ГБ. Платформа 8.2.18.61. На некоторых более старых платформах своп сжирался за пару недель.
Сейчас вот думаю - стоит ли обновлять платформу, а то у 1С сюрприз на сюрпризе.
Впрочем, если есть утечки памяти, то сожрет хоть 48, хоть 196 гиг, это лишь дело времени.
У моего сервера сейчас аптайм 96 суток, и своп - 536 МБ из 32 ГБ. Платформа 8.2.18.61. На некоторых более старых платформах своп сжирался за пару недель.
Сейчас вот думаю - стоит ли обновлять платформу, а то у 1С сюрприз на сюрпризе.
(35) audion, Ye коли меряться
System uptime 53 days, 21 hours, 37 minutes
Real memory 47.13 GB total, 4.73 GB used
Virtual memory 8.28 GB total, 225.85 MB used
Релиз 8.2.18.61. Последнее отключение было связано с отключением электричества более чем на 1 час. Час у меня упсы держат, потом сервера начинают тушится по сигналу от упсов.
Вот тоже думаю, 64 бит ставить свежий релиз или 18.61 оставить.
System uptime 53 days, 21 hours, 37 minutes
Real memory 47.13 GB total, 4.73 GB used
Virtual memory 8.28 GB total, 225.85 MB used
Релиз 8.2.18.61. Последнее отключение было связано с отключением электричества более чем на 1 час. Час у меня упсы держат, потом сервера начинают тушится по сигналу от упсов.
Вот тоже думаю, 64 бит ставить свежий релиз или 18.61 оставить.
Да ладно Вам, батенька, никто ничем меряться не собирается :-) Так, для сравнения. В плане изучения передового опыта.
Просто, с одной стороны, от добра добра не ищут, работает, и ладно, и нет гарантий, что 100-какой-то-там релиз будет безглючным. А с другой стороны - УТ народ нервирует, что релиз платформы обновить надо. Наверное, все же буду обновляться, поправили там пару ошибок, которые, по всей видимости, вылезали.
Просто, с одной стороны, от добра добра не ищут, работает, и ладно, и нет гарантий, что 100-какой-то-там релиз будет безглючным. А с другой стороны - УТ народ нервирует, что релиз платформы обновить надо. Наверное, все же буду обновляться, поправили там пару ошибок, которые, по всей видимости, вылезали.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот