Некорректная работа кластера 1с 8.3(почему тупит супер сервер 4 гб озу, 2 ядра) #737776

Характеристики: ms 2k8 r2 sql 2008 ms 2k8 r2  (4 гб озу, 2 ядра) кластер 1с На кластере кроме ключей и самого кластера ничего не установлено. Планируется переход на версию 8.3, поэтому на данный момент работают две платформу 8.2.19.83 и 8.3.5.1486 (ключ 64 битный). Имеем хаотически проблемы связанные с кластером 8.3,  периодически очень долго запускаются базы 8.3 ( от 30 - 5 минут). Были проделаны работы: а) Оптимизация работа по памяти кластера 8.3 параметры кластера: Интервал перезапуска:86400 Интервал превышения допустимого объема памяти:30 Включенные процессы останавливать через:30 Приоритет по памяти параметры рабочего сервера: Безопасный расход памяти 512мб Объем памяти рабочих процессов, до которого сервер считается проивод 700 мб Кол-во ИБ на процесс: 1 Кол-во соединений на процесс 25 2) Перенастройка клиентов на поиск лицензии со стороны сервера с исправлением файла на сервере  nethasp.ini В данном случаи у нас 30 лицензий программных и ключ на 10 на 18 сервере. 3) После старта службы агента 8.3 в логах зафиксирована проблема: Сбойное приложение ragent.exe, версия 8.3.5.1486, штамп времени 0x54f76689, сбойный модуль rtrsrvc.dll, версия 8.3.5.1486, штамп времени 0x54f7685d, код исключения 0xc0000005, смещение ошибки 0x00000000000020f4, ИД процесса 0xcb4, время запуска приложения 0x01d065fa56ec19bd. Была попытка переставить платформу (8.3) с нуля, но ошибка осталась. P.S. Основные зависания зафиксированы с утра, до момента работы с базой. После захода нескольких клиентов она открывается нормально, но в середине дня может снова получить ту же ерунду. Пробовал после нормального захода перезагрузить поль. машину и посмотреть скорость захода в базу = 5-7. То есть КЕШ машины я исключил полностью, хотя у нас и тонкий клиент, но мало ли... Более того с сервером работают порядка 25-30 активных пользователей 8.2 и они грузят память только на 700 метров. А пустые 5 баз могут с выключенным регламентными заданиями съесть 2.5 гига. Пробовал убить все базы и оставить только одну,но  на утро та жа самая проблема вновь. Спасите, помогите...

Забыл указать ... машины виртуальные,на базе hyper-v. Кластер 1с лежит в кластер из двух нод. А sql на stand alone сервере ( но тоже как VM) Хосты машин тоже 2008 r2.

[Спасите, помогите.] после вышеописанного помочь может только полная переустановка винды, сиквела и серверной части 1С

На виртуалках запускать "тонкого" клиента это как минимум не разумно. Сначала надо все это сделать без виртуалок. Посмотреть как это все будет работать. Я думаю плохо. С такой-же проблемой я столкнулся Для себя я сделал вывод, что "тонкий" клиент в сочетании с сервером 1с предприятия и менеджером кластера - это ЗЛО. Подобная связка - неработоспособна. Мало того, что механизм кеширования съедает все ресурсы сервера, так еще в момент перезапуска процесса rphost происходит отваливание т.н. тонких клиентов с формулировкой "потеряно соединение с сервером"

4 гб озу, 2 ядра это НЕ сервер!!! это рядовая клиентская тачка, а Вы на ней пытаетесь и скуль и 1с воткнуть....

не а, это не рядовая тачка, это бюджетный смартафон =)

1. на сервер выделяй 32 ФИЗИЧЕСКОЙ памяти, 8 ядер в монопольном доступе 2. сервер 1с должен иметь название службы "1C:Enterprise 8.3 Server Agent (x86-64)", обрати внимание на наличие последних буковок.... 3. сервер 1с оставляй только один (8.3), базы конверти 4. в настройках скуля установи лимит памяти 20 гигов 5. на сервере 1с рабочий процесс один, без лимита памяти

и тему переименуй в "некорректная работа мозга студента"

у меня рабочий комп мощнее:)

Спасибо большое за оскорбления. Надеюсь вы не повторите данных фраз в мой адрес. Возможно я не правильно что указал, попробую еще раз. Мы имеем кластер hyper-v на базе 2008 r2 с объемом памяти 64 гб и stand alone машины на базе 2008 r2 с объемом памяти 32 гб. На данной связке крутиться несколько VM, конкретно в нашем случаи будет разбирать только 1с. Кластер 1с крутить на базе Кластера hyper-v. Машине отдано 4 гб , 2 ядра. SQL крутить на базе stand alone сервера. И как указано выше было тоже как VM, он имеет объем памяти 20 гигов. Кластер 1с, состоит сейчас из 2-ух, это платформа 8.2.19.83.  На нем крутиться 7 баз , общий объем пользователей до 30. Загрузка процессора процессом rphost 8.2 (все в одном на все базы) -  не превышает 10 %. Объем потребляемой памяти  не более 1.2 гб. Естественно во время пика работы. Платформа 8.3.5.1486 - На ней крутить 5 баз, которые не имеют на данный момент активных пользователей. Рег. и фон задания выключены. Загрузка процессора процессом rphost 8.3 (5 процессов на 5 баз) - от 40-80 %. Объем потребляемой памяти при 4 пользователях работающих с ТОЛЬКО одной базой 2.5 гб. ------------------------------------------------------ P.S. Забыл указать, что у нас 2 SQL сервера. Базы 8.2 и 8.3 разнесены по разным естественно.

Работают как толстые клиенты.

Под кластером HYPER-V подразумевается связка нескольких серверов ( в нашем случаи это  две ноды ) , которые работают для обеспечения отказоустойчивости.

Замените ваш "сервак" на это: . Производительнее будет :)

Можно уточнить - для чего разносили sql базы 8.2 и 8.3? Если они работаю на 1 версии скуля - это не нужно делать.

Нафига два SQL-сервера-то? Сервер баз данных должен быть один, если нет специфических задач.

делал одмин закомый с 1сом мало попробуй разнеси службы агентов 1с 8.2 и 8.3 по разным юзерам.

я Вам дал реальные шаги.... зачем тебе 2 сервера 1с 8.2 и 8.3 ??? из Вашего описания понял следующее 1. есть 2 физических сервера, их обьеденили в отказоустойчивый кластер? какими средствами? 2. на этом кластере подняли скуль и паралельно ему HYPER-V ? 3. одна из виртуалок отдана под два сервера 1с? все так?

Хотел разнести нагрузку по разным серверам. Так как первый сиквел работает с SAN-ом на базе HP 2000, и с ним же работают другие VM-ы в кластере. Второй же SQL работает в зеркале на базе SA cервера и имеет всего 2 VM-ы в нагрузке у хоста. Плюс ко всему на SAN- место заканчивается, а когда ребята полностью все базы переведут в 8.3 неизвестно..

Среди всего этого мусора, попробую сделать две вещи. 1) Разнести службы на разных пользователей 2) Вернуть базы 8.3 на первый сиквел и посмотреть что будет. Спасибо тем, кто говорит по делу...

Работы за планированы на вечер, плюс ко всему отдан технический журнал 1с по ИТС поддержке. Завтра опишу помогло ли это....

Ты обновил платформу?

На последнюю. Там деградацию производительности vrs кэша поправили.

Для 1С выбирайте между отказоусточивостью и производительностью. Когда ж до вас, админов, это дойдёт? Всякая ересь типа виртуализации или NAS - это не для 1С.

Уважаемый, будьте добры.... Свое мнение оставляйте при себе. А) Для системного администратора не имеет значение что работает на его оборудование. Для него важно, КАК это работает. Поэтому любой процесс должен совмещать в себе и отказоустойчивость и производительность. И тот и другой показатель должны стремиться к своим данным (отказоустойчивость хотя бы к двум девяткам, а производительность хотя бы к 60% нагрузке). Б) Учитывая данный комментарии могу предположить, что Вы являетесь программистом 1С (либо других)... Тогда зачем давать советы, в которых Вы ничего не понимаете. Это равносильно тому, чтобы я учил бы  Вас как править конфиги и оптимизировать работу с памятью. P.S. Родной, я тебя обидеть не хотел. Просто пойми 8.2 - работает N-кол-во лет, а 8.3 нет. А это не есть правильно. Не говоря уже о том, что и программисты и администраторы... не очень то хотят пересаживаться 8.3...

И так к слову)) SAN и NAS это разные вещи... а NAS на ZFS будет предпочтительней всяких файлопомоек на базе MS.

"Поэтому любой процесс должен совмещать в себе" о чем тебе и сказали, что это 1С, а оно никому ничего не должно. "программисты и администраторы... не очень то хотят пересаживаться 8.3" мхахаха

И были случаи когда файловые базы на 10 пользователей, при переезде на NAS благополучно забывали  о скуле и продолжали работать.

Ты сам бы не обижался, но какой вопрос - такие и ответы. Информацию надо давать максимально полную, а не обрывки, по которым мы должны догадываться, что у тебя там происходит.

Ептыть, суперсервер :)) У меня домашний шестиядерный с 16 гигами мозгов. Чисто покодить и себестоимость попересчитывать.

Вы спроведливо отослали к SLA, я не знаю Ваших критериев SLA, допустим в них прописана отказоустойчивость, но вот прописаную производительнось я не предствляю... Админу опиратся нужно именно на SLA которое формируют потребители услуг, потребителям услуг пофиг на нагрузки им важно поведение программ, если админ не может самостоятельно определить критерии позволяющие обеспечить SLA он привлекает в виде консультантов других специалистов (DBA, 1c и т.д.)... Я не знаю Ваших заморочек, но я ставлю под сомнение необходимость отказоустойчивого кластера (в место него лучше имет резервный сервер с резервными ключами, востановление без это минутное дело....), кроме того у Вас явные проблеммы с взамоотношениями, по тому как два сервера 1с ставят только на период тестирования, а у Вас это рабочая схема. Вам нужно было давно разрулить это.... Идем далее Установка скуля рядом с гипервизором для меня это жесть непонятная, лучше-бы установить скуль на виртуалку... Выделение ресурсов на сервер 1с непонятное, 8.3 легко жрет и 16 гигов памяти с 8 камнями....

Это еще и виртуалка, но всему, т.е. процессор общий. Но из это вообще ни фига не понятно, а сама Тема напоминает задачу Швейка про бабушку.

Возможно и я был тут не прав. Давайте это холивар закончим   Может быть и правда я что то не правильно описываю.... Давайте по порядку: Все машины которые используются являются виртуальными. Используются они только для тех сервисов, для которых они подняты. Т.е на скуле, ничего кроме скуля не стоит. Или как раньше было сказано "На кластере кроме ключей и самого кластера ничего не установлено." 1) sqlA - 2008 (os 2k8 r2) 20 гб 2) sqlb - 2008 (оs 2k8 r2) 20 гб 3) 1cserv - 2008 (os 2k8 r2) 4 гб Т.е у нас есть 3 виртуальные машины, которые базируются на базе Hyper-v. sqlA,1cserv -  cluster 2008r2 из двух Nod`s, sqlb - SA сервер 2008r2 ----------------------------------------------------------- Относительно кластера.... На нем естественно крутиться не только 1с сервер и скуль, но и другие виртуальные машины. Но это не имеет значение, учитывая режим работы MS кластера. Поэтому давайте забудем о физике, остановимся только на ВМ-ах. ------------------------------------------------------------ Выделения памяти: Когда кластер функционировал только как 1с 8.2, объем памяти был равен - 2 гб с 1 ядром. И никаких проблем с производительностью никогда не было. Поэтому увеличение ОЗУ до 4 гб и ядер до 2- ух, обусловлено тем, что базы работают в тестовом режиме. Скуль на котором работают базы 8.2 - 8 ядер и 20 гб ОЗУ Учитывая что все транзакции у нас обрабатывает скуль а запросы делает пользователь как толстый клиент. Выставлять большее значение я на тот момент не видел смысла. ----------------------------------------------------------- И так после добавления кластера 8.3 и увелечения памяти и ядер. Работоспособность 8.2 осталась на том же уровне,а 8.3 функционировала через Ж...у. ---------------------------------------------------------- Она сразу же съела все 4 гб и обрубала сеансы. С моей стороны были проведены оптимизации по работе с кластером 8.3 указанные выше. Память стабилизировалась, но почему 7 баз 8.2 - съедают максимум 1.2 гб. А 5 пустых баз с 4 пользователями  8.3 - 2.5 гб. ----------------------------------------------------------- Дальше я проделал все операции выше и пока что у меня зацепка только за одну ошибку: Сбойное приложение ragent.exe, версия 8.3.5.1486, штамп времени 0x54f76689, сбойный модуль rtrsrvc.dll, версия 8.3.5.1486, штамп времени 0x54f7685d, код исключения 0xc0000005, смещение ошибки 0x00000000000020f4, ИД процесса 0xcb4, время запуска приложения 0x01d065fa56ec19bd. Именно на нее я пытался получить ответ на форуме, потому что это единственная моя зацепка была. З.Ы. Схема моя рабочая, более того знаю людей у которых она работает.

во первых я не увидел отказоустойчивости, я вижу как минимум 2 сервиса без резервирования... ну да ладно это ваши проблеммы... во вторых нельзя не учитывать физику на которой стоит гипервизор, тут то-же целая песня.... ну ладно и это оставим... идем дальше, когда устанвливали два сервера 1с во первых нужно было развести диапазоны портов, во вторых завести их на разныех пользователей (что-бы темповые каталоги были разные), в третих если у Вас службы 1с x86-64 то рхост должен быть один на одну службу (это рекомендация 1с), 64х сервер корректно работает в многопоточности с большим объемом памяти... в четвертых я предположу, что 8.3 поставили не из-за хотелок "поигратся" а из-за необходимости обновится бухгалтерии (для сдачи отчетности) а она требует последнюю платформу... и вот эти "последние" конфигурации сильно отличаются от того что крутится на 8.2, в частности там очень много чего вынесено в рег задания на сервер, по этому новые конфигурации жрут памяти в разы больше.... бух 2.0 нормально работала на 2х, а бух 3.0 зажрет и 8 в одно рыло.... надеюсь я ответил и про память и про ЦП, ну а ошибка должна уйти если поставишь 8.3 под другим юзером и порты разнесешь

Чтоб быть уверенным, что дело в диапазоне портов, я бы попросил строки запуска служб 1с в студию. А так в целом поддерживаю, тоже наблюдал отвалившиеся фоновые задания из-за недостатка памяти.

C:Program Files1cv88.3.5.1486in agent.exe" -srvc -agent -regport 1741 -port 1740 -range 1760:1791 -d "C:Program Files1cv8srvinfo" "C:Program Files1cv828.2.19.83in agent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:Program Files1cv82srvinfo" Про нового пользователя ни на православной статье от 1с ни на более съедобном варианте не увидел -------------------------------------------------- Ладно, более дельных сове я не увидел... 1) Разнести службы на разных пользователей 2) Вернуть базы 8.3 на первый сиквел и посмотреть что будет. --------------------------------------------------   Во первых ни схему резервного копирования, ни систему репликации мы с тобой не обсуждали. Более того ты не знаешь почему у меня сейчас стоят сервера в SA и что с ними будет далее. Поэтому судить об отказоустойчивости по крайней мере глупо и этот вопрос мною не поднимал и не утвержался. А по физике я не говорил не учитывать, просто сказал что там все нормально. Исключать же аппаратный дефекты, вместе с глюками ОС хоста  не надо естественно.Но это уже решается на уровне поддержки вендора и ни на таких форумах. Ну как и было сказано " Это мои проблемы "....

Отпишусь завтра, что к чему....

Нафига на одной физической машине делать два hyper-v с мыслью об отказоустойчевости?

Как на одной машине можно поднять две роли hyper-v?

Опять админы играются виртуалками ради чсв, да сколько можно-то..

Если это все что вы смогли подчеркнуть из "Работоспособность 8.2 осталась на том же уровне,а 8.3 функционировала через Ж...у. ", тогда да.

кстати порт 1741 не удачно выбран.... может еще какие порты ведут к сетевым проблемам :)

Победа далась не легко…. Я постараюсь описать все детально, хотя и прошло довольно много времени. Надеюсь информация, собранная мною поможет системным администраторам и даст пишу для размышления. Перенес я базы на 1 скуль и переназначил я пользователя для 8.3 агента – не помогло… Исколесил я наш рунет вдоль и поперек и нашел две интересные статьи, которые предлагаю и вам ознакомиться. Впервой довольно детальный тест между двумя платформами: ПС- мидл варианта и двухядерного сервера. Выясняется довольно интересные моменты, которые были подчеркнуты и мной во время работы в других компаниях. Вторая же относится к тестам 1с на виртуальных машинах. В ней как раз я и увидел причину задержки запуска конфигурации: Покопавшись где-то с недельку и перепробовав несколько методик, проблему с первым запуском я решить не смог. Но заметил одну интересную закономерность… При работе тонкого клиента, второй запуск системы происходит почти моментально. Изменил настройки кол-во ИБ на процесс: 8 (баз на 8.3 пока что 5). В итоге так как на создание RPHOST сервер перестал тратить время при заходе в след. базу и оставшееся он тратил только на выгрузку конфы из скуля. Сократил время старта второй баз на 10-7 секунд. Такой вариант меня в принципе устраивает полностью, учитывая, что с каждой базой работает по 7-10 пользователей, конфа держится постоянно в RPHOSTe и время захода равняется 4-8 секундам с аутентификацией вместе. Если же у вас имеются проблемы что базу открывают не часто, то как вариант могу предложить напилить небольшое рег. задание по заходу польз.  в каждую базу и настроить перезагрузку сервиса на вечернее время (либо через сервисы или интервал перезапуска). Думаю, это должно помочь, хотя тут мы упираемся в наличие лицензии, так что надо думать))) Но всплыл еще один неприятный момент, на одном из форумов я получил вот такой ответ: Offtop. У вас лицензии КОРП? Расширенные возможности сервера уровня КОРП «1С:Предприятия 8.3» по сравнению с 64-разрядным сервером уровня ПРОФ: * безопасный расход памяти за один вызов; * количество ИБ на процесс; * объем памяти рабочих процессов, до которого сервер считается производительным; * максимальный объем памяти рабочих процессов; *стратегия балансировки (по памяти, по производительности); Использование перечисленных функциональных возможностей при помощи продуктов «1С:Предприятие 8. Лицензия на сервер (x86-64)» уровня ПРОФ, то есть не имеющих в названии обозначения КОРП, является неправомерным. Решил уточнить у ребята из трех разных компаний, знают ли они что есть платформа корп и проф. На что был получен ответ в виде: крутящегося пальца у виска и посылка на форум 1с. И вот ниже ответ от саппорта 1с: 1)    >>> Хотелось бы уточнить различия между платформой 8.3 корп и 8.3 проф. Фактически при использовании Платформы ПРОФ ,согласно лицензии, можно использовать только дефолтные настройки кластера. Если при настройках кластера "по умолчанию" у Вас возникают проблемы (нехватка памяти, невозможность обновить конфигурацию и тд), то данное поведение является ошибкой (либо платформы либо данного прикладного решения). Просьба с конкретными примерами создавать обращения на исправление. На время исправления ошибки может быть письменно выдано разрешение (за подписью директора ЗАО "1С") на использования функционала лицензии Корп. 2)    >>> Прошу уточнить, т.е. есть две платформы 8.3? Нет. Платформа не текущий момент одна. Однако право использования функционала КОРП появляется только при покупке соответствующей лицензии. Программного контроля данной лицензии на текущий момент также нет. Таким образом лицензия КОРП является больше юридическим понятием. Честно говоря, я не веру в различные виды заговоров, но когда у компании есть почти 100% монополия на рынке малого и среднего бизнеса мысли лезут разные. «Выйдет обновление какой нибудь конфигурации для сдачи отчетности, которая будет требовать обновления платформы, в которой уже будет реализован программный контроль... И тут то вы нам (1с) проплатите по полной с...ны дети.» P.S. Хочу уточнить что сервер у меня на базе 2008r2 и могут быть отличия от 2012. Все таки ядро там детально перепилено и hyper-v 3.0 тоже плюшками под рос. Но как говориться «IT`s Alive!!!» и работа 1с на виртуальных машинах не только возможна, но и приветствуется. На выходе мы имеем 30 пользователь 8.2 и 20 пользователей 8.3. Удачи Вам всем, будьте терпимее и никогда не сдавайтесь)))

Забыл сказать, модератор... Верни название темы назад))