Добрый день.
Переехали на новое железо.
Проблема: кластер жрет и жрет память. На обоих рабочих серверах съедены все 64Гб. Выставил перезапуск rphost каждые 12 часов. Добавили еще по 32Гб - опять съели. Т.е. сейчас 2 по 96Гб и почти все съедено.
Было: 2 виртуальных сервера 1с, по 64Гб памяти. На одном 100 баз (БП3 и ЗУП3), на втором ERP. Все более-менее работало.
Т.е. 2 кластера с одним сервером в каждом.
Стало: кластер из 4х серверов. Три из них виртуальные: один с требованием назначения "не назначать клиентов", это центральный сервер. Еще 2 одинаковых сервера с ОЗУ по 64Гб, с требованием "назначать клиентов" и "остальные соединения не назначать" - это рабочие сервера. Плюс одна физ.машина под закрытие месяца. Отказоустойчивость не настраивали (уровень 0).
В чем еще отличия от старой конфигурации: была платформа 8.3.13.1644 которую ставили больше для эксперимента, но потом словили проблемы в обычных формах и ЗУПах с условным оформлением - и решили частично откатиться на 8.3.12.1790. Т.е. на старом сервере подняли еще 1 сервер 8.3.12.1790, и на него перевели часть баз.
Новый кластер полностью на 8.3.12.1790.
Есть подозрение что раньше все было "хорошо" потому что было плохо: есть отраслевые конфигурации с бгмерзкими ключами Катран. Благодаря которым rphost раз в 2-5 минут падали. Так и жили. После переезда вычислили причину - ключи, отключили рег.задания в базах по проверке ключей - падения прекратились. Возможно теперь rphost "успевают" съесть столько памяти сколько раньше не успевали - дохли от Катрана.
Еще возможный фактор - УХ. Её как раз поставили перед переездом, и теперь начинают там что-то вводить.
В общем даже не знаю чего делать.
Переехали на новое железо.
Проблема: кластер жрет и жрет память. На обоих рабочих серверах съедены все 64Гб. Выставил перезапуск rphost каждые 12 часов. Добавили еще по 32Гб - опять съели. Т.е. сейчас 2 по 96Гб и почти все съедено.
Было: 2 виртуальных сервера 1с, по 64Гб памяти. На одном 100 баз (БП3 и ЗУП3), на втором ERP. Все более-менее работало.
Т.е. 2 кластера с одним сервером в каждом.
Стало: кластер из 4х серверов. Три из них виртуальные: один с требованием назначения "не назначать клиентов", это центральный сервер. Еще 2 одинаковых сервера с ОЗУ по 64Гб, с требованием "назначать клиентов" и "остальные соединения не назначать" - это рабочие сервера. Плюс одна физ.машина под закрытие месяца. Отказоустойчивость не настраивали (уровень 0).
В чем еще отличия от старой конфигурации: была платформа 8.3.13.1644 которую ставили больше для эксперимента, но потом словили проблемы в обычных формах и ЗУПах с условным оформлением - и решили частично откатиться на 8.3.12.1790. Т.е. на старом сервере подняли еще 1 сервер 8.3.12.1790, и на него перевели часть баз.
Новый кластер полностью на 8.3.12.1790.
Есть подозрение что раньше все было "хорошо" потому что было плохо: есть отраслевые конфигурации с бгмерзкими ключами Катран. Благодаря которым rphost раз в 2-5 минут падали. Так и жили. После переезда вычислили причину - ключи, отключили рег.задания в базах по проверке ключей - падения прекратились. Возможно теперь rphost "успевают" съесть столько памяти сколько раньше не успевали - дохли от Катрана.
Еще возможный фактор - УХ. Её как раз поставили перед переездом, и теперь начинают там что-то вводить.
В общем даже не знаю чего делать.
Прикрепленные файлы:
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Попробуйте выставить в настройках кластера рабочих серверов создание отдельного rphost на каждую базу. Этот шаг сам по себе может стабилизировать утилизацию памяти. Но если нет, можно будет "выловить" проблемную базу, если источник проблем локализован в базе. Если нет - пробовать другие релизы и комбинации настроек кластера...
(10) пробовал настроить ТЖ - валилось все подряд, типовые фоновые вида "обновление банков" или "обновление СПАРК риски"
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump location="C:\Users\mos_cod_1c\AppData\Local\1C\1cv8\dumps" create="1" type="0" externaldump="1"/>
<leaks collect="true">
<point call="client"/>
<point call="server"/>
</leaks>
<log location="C:\Users\mos_cod_1c\AppData\Local\1C\1cv8\logs" history="24">
<event>
<eq property="name" value="leaks"/>
</event>
<property name="all"/>
</log>
</config> Показать
Для 100+ баз такой объем оператвки - это мало. От того что основных рабочих серверов 2, это не значит что они будут кушать меньше чем раньше было, скорее даже наоборот.
Ведь регламентные вы отдельно не назначаете, а тогда может быть ситуация:
База 1 - клиенты на сервере 1, а регламенты на сервере 2. В итоге каждый сервер съест по объему оперативки под эту базу и вы получаете двойной расход.
Вариантов несколько:
1. Увеличивайте оперативку минимум до 128 на каждом рабочем
2. Перестмотреть распределение нагрузки в кластере
Ведь регламентные вы отдельно не назначаете, а тогда может быть ситуация:
База 1 - клиенты на сервере 1, а регламенты на сервере 2. В итоге каждый сервер съест по объему оперативки под эту базу и вы получаете двойной расход.
Вариантов несколько:
1. Увеличивайте оперативку минимум до 128 на каждом рабочем
2. Перестмотреть распределение нагрузки в кластере
Обновил с 3.13 на 3.16 и поимел непонятную фигню с сервером 1с: 1) сильное бурление rphost 2) и жор памяти. И это при отсутствии подключённых пользователей!!!
Параметры сервака: виртуалка, Win 2008 х64, 10 ядер ксеона, 32Гига оперативы, 100 пользователей, базы стандартные (бух, зуп, док). 1с сервер и MS SQL 2008 там же.
По бурлению. Нагрузка на проц постоянная 30-60%, не коррелируется с числом пользователей на сервере. Как так?!
По жору памяти. Пилообразное потребление памяти, в моментах слива - большой объём файловых операций с файлом подкачки - на несколько секунд просаживается весь сервак.
На предыдущем релизе сервера такой фигни не было. А главное - невозможно локализовать проблему и что-то подкрутить в 1с-сервере, непонятно где копать, что конфигурировать. Но даже попробовать не получилось - у новых пользователей (только документооборота КОРП!!!) вылезает предупреждение "Операция не может быть выполнена с текущим составом лицензий блаблабла". Восторг!
Картинку бурления и пилообразного жора памяти прилагаю. Большой привет чудо-инженерам 1с - передаю.
Параметры сервака: виртуалка, Win 2008 х64, 10 ядер ксеона, 32Гига оперативы, 100 пользователей, базы стандартные (бух, зуп, док). 1с сервер и MS SQL 2008 там же.
По бурлению. Нагрузка на проц постоянная 30-60%, не коррелируется с числом пользователей на сервере. Как так?!
По жору памяти. Пилообразное потребление памяти, в моментах слива - большой объём файловых операций с файлом подкачки - на несколько секунд просаживается весь сервак.
На предыдущем релизе сервера такой фигни не было. А главное - невозможно локализовать проблему и что-то подкрутить в 1с-сервере, непонятно где копать, что конфигурировать. Но даже попробовать не получилось - у новых пользователей (только документооборота КОРП!!!) вылезает предупреждение "Операция не может быть выполнена с текущим составом лицензий блаблабла". Восторг!
Картинку бурления и пилообразного жора памяти прилагаю. Большой привет чудо-инженерам 1с - передаю.
Прикрепленные файлы:
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот