1. Liris 40 10.07.19 21:13 Сейчас в теме

Сервер для 10 пользователей и 100+ ИБ

Добрый день, уважаемые коллеги. Вопрос нетривиальный.
Имеется организация, которая оказывает услуги по бухучету Предпринимателям и маленьким организациям (бухучет на аутсорсинге).
Живут сейчас на сервере с виртуализацией (esxi):
- Intel Xeon E3-1220v6 (3.00Ghz/8Mb)
- 16Гб оперативной памяти 2666MHz DDR4
- 2Тб в RAID 10 (довольно быстрый массив на контроллере Adaptec RAID 8405E V2).
Используется 1С:Предприятие 8.3 (8.3.14.1779), сервер х32бит (программная лицензия).
СУБД MS SQL Server 2014.
Постоянных пользователей - 11. В пике работает 7 пользователей, каждый максимум с 3 ИБ.
Размеры ИБ варьируются от 1Гб до 3Гб. Используется две конфигурации: БП 3.0 и ЗУП 3.1.

Чтобы было понятно, как работает организация:
- заключает договор на платные услуги по ведению учета (Бухучет, зарплата, кадры);
- берется ИБ от клиента, размещается на своих мощностях (ведется учет за него).
- чем больше клиентов, тем больше количество ИБ.

Описанного оборудования хватало, пока организация работала с 20-30 базами.
Проблемы начались когда число ИБ выросло за 50+. Сейчас вот такая картина (100ИБ) https://i.imgur.com/CMQbdqc.png

Понятно, что жить на 16Гб совсем невозможно.
Основной затык в оперативной памяти. Ее не хватает, чтобы обслуживать такое количество ИБ.
Как рассчитываю память для этого сервера:
6 ИБ на 1 процесс = 2048 Мб (сервер 32-х битный, процесс не может потреблять больше 2Гб)
100 ИБ / 6 ИБ = 17 процессов rphost
17 * 2048 = 34816 Мб памяти.

16Гб установлено, докупаем 32Гб и получаем 32 + 16 = 48Гб.
По расчетам, этого должно хватить с запасом на год+.

Прошу вас, коллеги, поделиться опытом в подобных вопросах.
1) Правильно ли рассчитываю требуемый объем оперативной памяти? Может есть проверенные методики для "моего случая"?
2) У кого из вас есть опыт управления таким огромным числом ИБ?
Думаю, здесь требуются особенные подходы в администрировании, управлении ресурсами. На ИТС, в разделе Крупных внедрений, не говорится о случаях 100+ ИБ. Рассказывают о большом числе пользователей и больших базах. Что посоветуете, может есть рекомендации?
Ответы
Избранное Подписка Сортировка: Древо
2. collider 11.07.19 05:34 Сейчас в теме
(1) Вы забыли прикинуть память под процедурный кэш MSSQL. Его чем больше, тем лучше. Это единственное, что можно ответить по делу.


А вообще, в данном конкретном случае сервер 1С - это лишнее. Тем более, х32.
Сервер 1С и отдельная СУБД берутся главным образом для обеспечения параллельного доступа к конкурентным ресурсам.
Например, 10 кассиров шквально пробивают чеки. Они все обращаются к одним и тем же таблицам. Это требует управления.
Другое дело - ваш случай. Всё наоборот. Пользователи крайне редко пользуются одними и теми же таблицами одновременно. Здесь не требуется оптимальное управление блокировками.
Короче говоря, у вас сервер 1с - это лишняя прослойка, которая не даёт ничего. Ну разве что, более удобное обслуживание баз в MSSQL.

Ну и виртуализация. Зачем она здесь? Только бесполезное замедление.
5. Liris 40 11.07.19 12:27 Сейчас в теме
(2)
Вы забыли прикинуть память под процедурный кэш MSSQL

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

в данном конкретном случае сервер 1С - это лишнее
.
Пробовали работать без сервера 1С, использовали только файловый вариант. Вариант не устроил по быстродействию, нагрузке на сеть.
Вы не представляете сколько времени экономит сервер 1С. Конфигурации все современные, используется ТонкийКлиент. После развертывания сервера 1С, скорость работы с базами существенно улучшилось. Появилась единая точка администрирования.
Нормальные средства для резервного копирования (SQL), которые можно выполнять даже в течении рабочего дня (возникают ситуации, когда нужно откатить состояние на определенный момент дня).

Здесь не требуется оптимальное управление блокировками

Соглашусь, что нет шквальной записи. Но работать и управлять 100 ИБ без сервера - это не просто и не надежно.

Ну и виртуализация. Зачем она здесь?
Для удобного администрирования и управления сетью и сервером.
В случае замены "железа", переехать на новый сервер не составит никаких проблем. В моем случае, замедление, которое дает esxi, равно статистической погрешности измерения. Виртуальный сервер проходит "Нагрузочный тест TPC-1C" на 23 балла (между удовлетворительно и хорошо). Для маленькой фирмы - вполне приемлемый результат. Понимаю, что можно поднять результат выше. На него еще предстоит заработать. :-)
А виртуализация - хорошее и удобное средство для администрирования и управления системами. Добавим массив с дисками - легко его применить на сервере. Никакой привязки к "железу".

Напишите рекомендации по расчету памяти под SQL, пожалуйста. Может есть ссылки, которые попробовали?
* кроме статей на ИТС. Изучил подробно https://its.1c.ru/db/metod8dev#content:5904:hdoc и выполнил все рекомендации.
7. TODD22 17 11.07.19 12:31 Сейчас в теме
(5)
Но работать и управлять 100 ИБ без сервера - это не просто и не надежно.

Чем именно вы собираетесь управлять? Копированием?
collider; +1 Ответить
10. Liris 40 11.07.19 14:10 Сейчас в теме
(7)
Чем именно вы собираетесь управлять? Копированием?

Есть внутренние задачи, которые существенно упрощаются с сервером 1С:Предприятия. Сбор различной статистики, разбор ЖР и т.п.
Кроме того, работа в трехзвенной архитектуре улучшает безопасность (это важно для этого предприятия).
11. TODD22 17 11.07.19 15:04 Сейчас в теме
(10)
разбор ЖР

Как разбор ЖР упрощается трёхзвенкой если ЖР хранится либо в отдельной базе SQLite либо в текстовых файлах?
Сбор различной статистики

Статистику можно и из файловой собирать. А какая нужна статистика при 10 пользователях?
Кроме того, работа в трехзвенной архитектуре улучшает безопасность (это важно для этого предприятия).

Тут да... по сравнению с файловой по надёжней будет.
На ИТС, в разделе Крупных внедрений, не говорится о случаях 100+ ИБ.

Потому что 100+ баз это не "крупные внедрения", "Крупные" это когда от 500 пользователей одновременно в одной базе.

А так единственная проблема тут только с обновлением всех этих баз. У меня знакомый работает в какой то компании, у него там штук 200 или 300 баз. Обновляет скриптами, админит всё это дело скриптами. Вот единственная проблема это писать скрипты администрирования всего этого обновления, добавление/отключение пользователей и тд.
collider; Liris; +2 Ответить
8. collider 11.07.19 12:32 Сейчас в теме
(5)
Посоветуйте методику расчета, которая в моем случае подойдет.

Нет такой методики. Обычно выделяются всё, что останется после сервера 1С и самой операционки. Чем больше, тем лучше. Лишь бы не меньше гигабайта получилось.
9. Liris 40 11.07.19 13:56 Сейчас в теме
(8)
Обычно выделяются всё, что останется после сервера 1С и самой операционки

Спасибо. Это мне понятно.
3. coolseo 53 11.07.19 05:49 Сейчас в теме
Возьмите минимум 64 памяти.
Ее много не бывает.
6. Liris 40 11.07.19 12:28 Сейчас в теме
(3) Спасибо за совет.
Поставим пока 32Гб. Напишу сюда результат.
4. s_demidov 11.07.19 05:53 Сейчас в теме
Поддерживаю про память. И сервер на x64 перевести.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Руководитель проекта, аналитик, консультант
Санкт-Петербург
По совместительству

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Бизнес-аналитик 1С
Санкт-Петербург
зарплата от 120 000 руб.
Полный день

Программист 1С
Санкт-Петербург
зарплата от 120 000 руб.
Полный день

Программист 1С
Москва
Полный день