Сервер 1С x64 и 19 баз данных... тормозит. Есть решение?
Добрый день, коллеги!
Имеется сервер, на котором крутится 1С.
Стоит Сервер 1С x64, PostgreSQL
Общее пиковое число одновременных сеансов - 45-50
Баз данных - 19шт, 1С:Бух, 1С:ЗуП, 1С:Альфа-Авто 4 и 5 ред.
Сервер периодически начинает ужасно тормозить, смотрим ресурсы, а их в целом достаточно
Т.е. CPU занят не более чем на 20-30%, ОЗУ - максимум 70% занято
Единственное что напрягает, так это большая очередь к диску иногда она скачет аж до 5-10.
Читал Гилёва, он советует настроить Сервер 1С так, что бы на каждую базу был свой процесс.
Но, как выяснилось такие параметры в Платформе ПРОФ нельзя сделать, Сервер 1С начинает ругаться и не пускать пользователей... мол параметры сервера отличаются о тех, которые подходят по ПРОФ платформу.
Техническая поддержка сетует за смену сервера, но мне что-то кажется, что это не поможет и будет выброшено несколько сот. тыс. рублей.
Может есть какой-то другой выход?
Переход на КОРП-платформу, переход на MsSQL?
Покупка еще одного "среднего" сервера, сервера 1С, что бы разнести базы?
Скриншоты Сервера, настроек Сервера 1С во вложении.
P.S. Когда процессы rphost близятся к 10Гб расходу памяти, тогда и начинаются тормоза((
Имеется сервер, на котором крутится 1С.
Стоит Сервер 1С x64, PostgreSQL
Общее пиковое число одновременных сеансов - 45-50
Баз данных - 19шт, 1С:Бух, 1С:ЗуП, 1С:Альфа-Авто 4 и 5 ред.
Сервер периодически начинает ужасно тормозить, смотрим ресурсы, а их в целом достаточно
Т.е. CPU занят не более чем на 20-30%, ОЗУ - максимум 70% занято
Единственное что напрягает, так это большая очередь к диску иногда она скачет аж до 5-10.
Читал Гилёва, он советует настроить Сервер 1С так, что бы на каждую базу был свой процесс.
Но, как выяснилось такие параметры в Платформе ПРОФ нельзя сделать, Сервер 1С начинает ругаться и не пускать пользователей... мол параметры сервера отличаются о тех, которые подходят по ПРОФ платформу.
Техническая поддержка сетует за смену сервера, но мне что-то кажется, что это не поможет и будет выброшено несколько сот. тыс. рублей.
Может есть какой-то другой выход?
Переход на КОРП-платформу, переход на MsSQL?
Покупка еще одного "среднего" сервера, сервера 1С, что бы разнести базы?
Скриншоты Сервера, настроек Сервера 1С во вложении.
P.S. Когда процессы rphost близятся к 10Гб расходу памяти, тогда и начинаются тормоза((
Прикрепленные файлы:
Найденные решения
(24)
круто.еще один сервер
покупайте, чего уж....
против ссд серверных, потому что ценник поищите на них
а если не смогли найти выход при этих условиях
то будете искать выход через некоторое время
после установок виртуалок и прочей "полезности"
а от меня пожелание , если будет два сервера
один на 1с другой на бд
и никаких виртуалок
и еще опять же вопрос, как настроят слона , рейд и всю систему.
круто.еще один сервер
покупайте, чего уж....
против ссд серверных, потому что ценник поищите на них
а если не смогли найти выход при этих условиях
то будете искать выход через некоторое время
после установок виртуалок и прочей "полезности"
а от меня пожелание , если будет два сервера
один на 1с другой на бд
и никаких виртуалок
и еще опять же вопрос, как настроят слона , рейд и всю систему.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Ну вот же на вашей картинке все есть.
1. У вас на один рабочий процесс могут залезть до 128 пользователей в 8 баз. Естественно, rphost распухнет.
2. Уменьшите количество соединений до 20, например. 50 пользователей по 20 соединений - это минимум 2-3 рабочих процесса.
3.И количество баз уменьшите с 8 до 4, например.
Примерно таким образом вы поднимете 6-8 рабочих процессов с более равномерным использованием памяти и независающими rphost-ами...
(Только надо будет существующие соединения после перенастройки сбросить)
P.S. Когда процессы rphost близятся к 10Гб расходу памяти, тогда и начинаются тормоза((
Ну вот же на вашей картинке все есть.
1. У вас на один рабочий процесс могут залезть до 128 пользователей в 8 баз. Естественно, rphost распухнет.
2. Уменьшите количество соединений до 20, например. 50 пользователей по 20 соединений - это минимум 2-3 рабочих процесса.
3.И количество баз уменьшите с 8 до 4, например.
Примерно таким образом вы поднимете 6-8 рабочих процессов с более равномерным использованием памяти и независающими rphost-ами...
(Только надо будет существующие соединения после перенастройки сбросить)
(5) нельзя на Сервере 1С ПРОФ (НЕ КОРП) ставить параметры "ИБ на процесс" отличное от по-умолчанию. В КОРП можно...
Вот делема теперь...
1. Оставаться на этом сервере, апгрейдиться с ПРОФ на КОРП (примерно 100 000р). Но я не знаю нужно ли будет апгрейдить клиентакие лицензии на КОРП... не выяснял пока что.
2. Поменять этот сервер на более мощный (ЭТО ПРЕДЛАГАЮТ СИСАДМИНЫ)
3. Поставить еще 1 сервер и разнести базы + сервер 1С (ЭТО МОЙ ВАРИАНТ)
Вот делема теперь...
1. Оставаться на этом сервере, апгрейдиться с ПРОФ на КОРП (примерно 100 000р). Но я не знаю нужно ли будет апгрейдить клиентакие лицензии на КОРП... не выяснял пока что.
2. Поменять этот сервер на более мощный (ЭТО ПРЕДЛАГАЮТ СИСАДМИНЫ)
3. Поставить еще 1 сервер и разнести базы + сервер 1С (ЭТО МОЙ ВАРИАНТ)
кроме проца и памяти есть еще диск или диски
вы посмотрите их в графике :)
и еще напишите , какого они типа.
вы посмотрите их в графике :)
и еще напишите , какого они типа.
Могу посоветовать - рестарт 1С агента утром ...
Тормоза могут быть связаны например с Хранилищем и частыми динамическими обновлениями;
Тормоза могут быть связаны например с Хранилищем и частыми динамическими обновлениями;
(4)
А в том-то и дело, что рестарт агента вообще ничего не меняет. Помогает только перезагрузка сервера целиком.
Могу посоветовать - рестарт 1С агента утром ...
Тормоза могут быть связаны например с Хранилищем и частыми динамическими обновлениями;
Тормоза могут быть связаны например с Хранилищем и частыми динамическими обновлениями;
А в том-то и дело, что рестарт агента вообще ничего не меняет. Помогает только перезагрузка сервера целиком.
Общее пиковое число одновременных сеансов - 45-50
Баз данных - 19шт, 1С:Бух, 1С:ЗуП, 1С:Альфа-Авто 4 и 5 ред.
еще не ясно , на реальном или виртуальном все хозяйство находится
какие диски , как настроен слоник и когда последний раз проверяли железо...
потому-что
-------------------------
Сервер периодически начинает ужасно тормозить, смотрим ресурсы, а их в целом достаточно
Т.е. CPU занят не более чем на 20-30%, ОЗУ - максимум 70% занято
Единственное что напрягает, так это большая очередь к диску иногда она скачет аж до 5-10.
--------------------------------
единственное узкое место может сильно "помочь" в работе...
для человека важно , что проц и память без нагрузки
а о дисках и сетевом адаптере вообще забыл....
Баз данных - 19шт, 1С:Бух, 1С:ЗуП, 1С:Альфа-Авто 4 и 5 ред.
еще не ясно , на реальном или виртуальном все хозяйство находится
какие диски , как настроен слоник и когда последний раз проверяли железо...
потому-что
-------------------------
Сервер периодически начинает ужасно тормозить, смотрим ресурсы, а их в целом достаточно
Т.е. CPU занят не более чем на 20-30%, ОЗУ - максимум 70% занято
Единственное что напрягает, так это большая очередь к диску иногда она скачет аж до 5-10.
--------------------------------
единственное узкое место может сильно "помочь" в работе...
для человека важно , что проц и память без нагрузки
а о дисках и сетевом адаптере вообще забыл....
(17)
Нет конечно, не забыл
Написал же, что очередь диска иногда огромная.... уверен, что всё дело в этом.
Но может как-то можно распределить нагрузку
Хотя решение уже принято, покупка еще одного сервера, правда системщики категорически против SSD дисков почему-то.... пока не переубедил их.
Но на 90% будет выход такой.... покупка "мощного" сервера, поднятие там 2х виртуалок, на каждой по серверу 1С + SQL (Postgre).
От меня только было пожелание, что бы каждая виртуалка крутилась на своём диске, а то снова всё в очередь диска упрётся.
В общем "системщикам" очень хочется продать людям дорогой сервер)
для человека важно , что проц и память без нагрузки
а о дисках и сетевом адаптере вообще забыл....
а о дисках и сетевом адаптере вообще забыл....
Нет конечно, не забыл
Написал же, что очередь диска иногда огромная.... уверен, что всё дело в этом.
Но может как-то можно распределить нагрузку
Хотя решение уже принято, покупка еще одного сервера, правда системщики категорически против SSD дисков почему-то.... пока не переубедил их.
Но на 90% будет выход такой.... покупка "мощного" сервера, поднятие там 2х виртуалок, на каждой по серверу 1С + SQL (Postgre).
От меня только было пожелание, что бы каждая виртуалка крутилась на своём диске, а то снова всё в очередь диска упрётся.
В общем "системщикам" очень хочется продать людям дорогой сервер)
(24)
круто.еще один сервер
покупайте, чего уж....
против ссд серверных, потому что ценник поищите на них
а если не смогли найти выход при этих условиях
то будете искать выход через некоторое время
после установок виртуалок и прочей "полезности"
а от меня пожелание , если будет два сервера
один на 1с другой на бд
и никаких виртуалок
и еще опять же вопрос, как настроят слона , рейд и всю систему.
круто.еще один сервер
покупайте, чего уж....
против ссд серверных, потому что ценник поищите на них
а если не смогли найти выход при этих условиях
то будете искать выход через некоторое время
после установок виртуалок и прочей "полезности"
а от меня пожелание , если будет два сервера
один на 1с другой на бд
и никаких виртуалок
и еще опять же вопрос, как настроят слона , рейд и всю систему.
(24)
И без SSD будет у вас то же самое.
Продать сервер это всегда приятно.
Но на 90% будет выход такой.... покупка "мощного" сервера, поднятие там 2х виртуалок, на каждой по серверу 1С + SQL (Postgre).
И без SSD будет у вас то же самое.
В общем "системщикам" очень хочется продать людям дорогой сервер)
Продать сервер это всегда приятно.
Попробуйте до покупки сервера для начала разобраться в какой момент начинаются тормоза и их причины. Можно ещё диски попробовать SSD.
по которой может происходить падение производительности PostgreSQL в Windows-среде при интенсивной работе с базами.
Насчет количества одновременно открытых файлов тоже верно. В последних версиях PostgreSQL от 1С параметр max_files_per_process установлен 8000 ( в postgresql.conf), в более ранних было то ли 1000 то ли 2000.
Насчет количества одновременно открытых файлов тоже верно. В последних версиях PostgreSQL от 1С параметр max_files_per_process установлен 8000 ( в postgresql.conf), в более ранних было то ли 1000 то ли 2000.
Всем спасибо за советы, отзывы, критику!
В целом всё как я предполагал/планировал. Осталось договориться с фирмой кто сервер будет поставлять и внедрять...
В целом всё как я предполагал/планировал. Осталось договориться с фирмой кто сервер будет поставлять и внедрять...
(30) Да, очередь диска бешено растёт во время пиковых нагрузок
Чуть подправили конфиг постгри, так же все же удалось сделать что бы не 2 процесса сервера 1С было, а 4
Тормозов меньше стало, очередь диска все равно скачет сильно иногда
Чуть подправили конфиг постгри, так же все же удалось сделать что бы не 2 процесса сервера 1С было, а 4
Тормозов меньше стало, очередь диска все равно скачет сильно иногда
(31)
А что там происходит в эти пиковые нагрузки смотрели? Просто может получится так что проще и эффективнее код оптимизировать чем покупать новый сервер и получить то же самое только на новом сервере.
Хотя бы понять какая база, на каких операциях вносит больше всего вклад в тормоза.
Да, очередь диска бешено растёт во время пиковых нагрузок
А что там происходит в эти пиковые нагрузки смотрели? Просто может получится так что проще и эффективнее код оптимизировать чем покупать новый сервер и получить то же самое только на новом сервере.
Хотя бы понять какая база, на каких операциях вносит больше всего вклад в тормоза.
(32)
Не-не, сервер всё равно нужен... на этом же сервере еще сервер терминалов крутится, на котором 30 пользователей сидят... на нём же Postgre, на нём же Сервер 1С...
На новом будет 1С+Постгри, на старом останется сервер терминалов.
Ну или как-то по другому распределим.
+ контора расширяется, сервер по-любому нужен
Просто может получится так что проще и эффективнее код оптимизировать чем покупать новый сервер и получить то же самое только на новом сервере.
Не-не, сервер всё равно нужен... на этом же сервере еще сервер терминалов крутится, на котором 30 пользователей сидят... на нём же Postgre, на нём же Сервер 1С...
На новом будет 1С+Постгри, на старом останется сервер терминалов.
Ну или как-то по другому распределим.
+ контора расширяется, сервер по-любому нужен
(33)
Новый сервер это хорошо. Но тут речь о том что новый сервер может не решить старых проблем.
Если например у вас где то код кривой и создаёт большую нагрузку то вам и на новом сервере будет создавать ту же нагрузку.
Всё же попробуйте найти в чём причина тормозов в пиковые нагрузки.
Определите время в которое случаются эти нагрузки, определите базу, найдите операции которые тормозят. Подумайте как можно оптимизировать.
Покупка нового железа не всегда решает проблему.
+ контора расширяется, сервер по-любому нужен
Новый сервер это хорошо. Но тут речь о том что новый сервер может не решить старых проблем.
Если например у вас где то код кривой и создаёт большую нагрузку то вам и на новом сервере будет создавать ту же нагрузку.
Всё же попробуйте найти в чём причина тормозов в пиковые нагрузки.
Определите время в которое случаются эти нагрузки, определите базу, найдите операции которые тормозят. Подумайте как можно оптимизировать.
Покупка нового железа не всегда решает проблему.
(34)
Базы все идентичные, просто несколько юр. лиц.
Стандартные связки: Альфа-Авто 5 + 1С:Бух 3 + 1С:ЗУП
С добавлением еще одного Юр. лица и соответственно 3-х баз всё усугубилось.
Вообще больше всего загружают сервер 1С и SQL почему-то Бухгалтерии, хотя в них уже отключили уже почти все рег. и фоновые задания. Если смотреть по кол-ву отъедаемой оперативной памяти за сеанс, или пик её (в консоли Сервера 1С), то 100% лидирую Бухгалтерии. Хотя в 1С Бух по 2-3 подключения (пользователя) к каждой базе, в то время когда к Альфа-Авто подключено 10-20 человек к каждой базе.
Но тут речь о том что новый сервер может не решить старых проблем.
Если например у вас где то код кривой и создаёт большую нагрузку то вам и на новом сервере будет создавать ту же нагрузку.
Всё же попробуйте найти в чём причина тормозов в пиковые нагрузки.
Определите время в которое случаются эти нагрузки, определите базу, найдите операции которые тормозят. Подумайте как можно оптимизировать.
Если например у вас где то код кривой и создаёт большую нагрузку то вам и на новом сервере будет создавать ту же нагрузку.
Всё же попробуйте найти в чём причина тормозов в пиковые нагрузки.
Определите время в которое случаются эти нагрузки, определите базу, найдите операции которые тормозят. Подумайте как можно оптимизировать.
Базы все идентичные, просто несколько юр. лиц.
Стандартные связки: Альфа-Авто 5 + 1С:Бух 3 + 1С:ЗУП
С добавлением еще одного Юр. лица и соответственно 3-х баз всё усугубилось.
Вообще больше всего загружают сервер 1С и SQL почему-то Бухгалтерии, хотя в них уже отключили уже почти все рег. и фоновые задания. Если смотреть по кол-ву отъедаемой оперативной памяти за сеанс, или пик её (в консоли Сервера 1С), то 100% лидирую Бухгалтерии. Хотя в 1С Бух по 2-3 подключения (пользователя) к каждой базе, в то время когда к Альфа-Авто подключено 10-20 человек к каждой базе.
(35)А обмен как часто в БП работает, на выгрузку? Может у вас так кто нибудь упражняется месяц закрывает :) Не смотрели какие операции идут в момент тормозов?
Если в БП по 2-3 подключения то довольно странно что она так много отъедает. У меня по 30-40 пользователей в БП с RLS и таких проблем не было.
Если в БП по 2-3 подключения то довольно странно что она так много отъедает. У меня по 30-40 пользователей в БП с RLS и таких проблем не было.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот
