Как хостить 100+ баз 1С?

Question

[OwDafuq]

Доброго времени суток.
Есть серверный комп с +-100 базами, есть много бухгалтеров, которые подключаются к базам на сервер со своих компов. Из-за этого получается, что все входят в базы очень долго (иногда по 20(!) минут).
Локальная сеть сделана в 1 Гбит.
Сервер на windows (есть мысль, что во всём виноват он, так ли это? стоит ли переехать на линукс?). Процессор xeon e-2144g, 32 ГБ Озу, raid 1 из 2-х дисков.
Куда нам вообще смотреть? Облачные решения от 1С не подойдет (бюджета нет).

Comments

[Denis Melnikov]

у нас на 30 баз , 150 гигов ОЗУ ... и то мало. Все на скуле.
Попробуйте работать через RDP, чтоб не грузить сеть. Тогда упретесь только в скорость дисков.

[Василий Банников]

raid 1 из 2-х дисков.

Ну как минимум стоит перейти на SSD

[OwDafuq]

Denis Melnikov, а зачем нам столько ОЗУ? У нас в пике нагрузке потребление идет 4 ГБ ОЗУ, у нас на сервере только лежат базы, всё. Никаких вычислений и прочего.
Через RDP возможно будет подключить 40+- человек к 1 машине?

[OwDafuq]

Василий Банников, на нормальные - денег нет. На простые - умрут быстро, скорее всего. Объемы данных большие.

[Василий Банников]

LiptonOlolo,

На простые - умрут быстро, скорее всего.

Простые стоят не так уж и дорого. Если запускать их также в RAID 1 или RAID 10, то их можно иногда заменять.
Ну и умирают SSD не от количества данных, а от количества перезаписей. Не думаю, что у вас там постоянно идёт жирный поток данных на запись, так что одного диска хватит на пару лет.

[OwDafuq]

Василий Банников, Ну первый вариант и был такой, просто переехать на SSD. Но ставили на SSD m2 и скорости особой не получилось выиграть.

[Василий Банников]

LiptonOlolo, пробовали использовать профайлер? В какой момент происходят тормоза?
Может у вас там какая-то тормознутая конфигурация или база?
Или может вся эта куча бухгалтеров пытается одновременно делать тяжёлые вещи?

[АртемЪ]

LiptonOlolo, Базы файловые или серверные? Сколько именно пользователей активных?
У меня более 150 баз на данный момент - полет нормальный.

[Denis Melnikov]

LiptonOlolo, ну так откуда нагрузка будет, если у вас базы файловые .. как я понял.
Тут упрется всегда в сеть + диски.
На счет 40 юзеров, да, спокойно вытянет.
А вообще, 100 баз, требуют конечно хорошего контроля и инфраструктуры.

[АртемЪ]

LiptonOlolo,

на нормальные - денег нет. На простые - умрут быстро, скорее всего. Объемы данных большие.

Да они вроде недорого стоят, и с чего им умирать? От 1с нагрузка не большая.
Горячую информацию (с которой активно работают) давно уже никто не держит на HDD.
На HDD только холодная информация - то что редко пишется и читается, в основном хранится.

Answer 1

[АртемЪ]

Сервер на windows (есть мысль, что во всём виноват он, так ли это? стоит ли переехать на линукс?)

Нет. Быстрее на линуксе работать не будет.

Быстродействие достигается грамотной организацией инфраструктуры и правильным подбором железа.
В остальном нужно больше информации.
Средний размер одной базы, сколько всего пользователей активных, сколько пользователей в среднем работает в одной базе в один момент времени, что за базы типовые или нет, если да то какая конфигурация.

Если предположить что базы файловые то -

1. Обратить внимание на клиентские компьютеры которые работают с базой - SSD и8гб озу обязателны. Именно на клиентах. Ну и настройка процессора на максимальную производительность.
   
2. Сеть, и организация шары. Сеть должна быть нормально настроена и работать четко.
   
3. Базы на сервере на SSD желательно, обязательно форматировать диск под базами с размером кластера 8к.
   
4. Обратить пристальное внимание на обслуживание БД. Регулярно проводить реиндексацию и сжатие баз. В процессе работы, а особенно при обновлениях базы распухают - а это все приходится тащить по сети.
   

В общем при нормальной настройке база должна открываться примерно за 1-2минуты. Быстрее не получится. А этих результатов достичь вполне реально.

Из явно видных проблем - raid 1 из 2-х дисков.
Сразу возникает подозрение что на этом массиве установлена система и лежат базы. Так делать нельзя.
Сделали рэйд под систему - отлично. Но под базы будьте добры выделить отдельный диск или рэйд.

Answer 2

[LollyFox]

Количество информационных баз в данном случае не имеет особого значения. Важнее сколько всего одновременных пользователей, сколько в одной базе, размеры баз, файловые или SQL, способ подключения клиентов к серверу, HDD или SSD... - ничего этого вы не указали, а без этого будет гадание на кофейной гуще.
Если пользователей больше десятка, базы файловые в расшаренной папке, а диски HDD, то запуск 20 мин - это вполне ожидаемо.

Сервер на windows (есть мысль, что во всём виноват он, так ли это?

Скорее всего, но не факт, что переход на линкус решит проблему, т.к. проблема не в ОС.

Answer 3

[Drno]

Ну на SSD переезд обязателен. Можно 4шт поставить в raid10.
Если базы файловые - не удивительно что всё зависает.. (судя по потреблению оперативки так и есть) тем более если они не маленькие. Переведите базы на SQL... тогда он хотя бы будет выгружать к юзеру только нужные данные, а не почти всю базу... и оперативка сразу займется кешем и нужными вещами))

Comments

[АртемЪ]

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

Ну не факт.
Можно достичь противоположного эффекта.
В клиент серверном варианте работа вся идет на сервере - на такое количество баз, надо оперативки добавлять, обслуживание усложнится.
В общем SQL не панацея, если пользователей немного файловый вариант лучше.

SQL хорош когда много пользователей. Это именно многопользовательский вариант работы.
Файловый он более быстрый, но он по сути для одного пользователя. Он позволяет работать нескольким пользователям, но кривовато.

В данном случае если я правильно понял ситуацию - 40юзеров и 100баз - 0,4активного юзера на базу в среднем.
По факту с одной базой активно работает один пользователь. Редко два-три. А все сорок в одну базу точно не заходят одновременно.

А в этом режиме файловый более удобен и быстр.

Answer 4

[Александр Черных]

1С любит быть в терминале, так уж сложилось исторически. И если уже переходить на RDP, то всю рабочую среду пользователя нужно переносить в терминальный сервак. А это 1С, клиент-банки, браузеры, документы, и т.д.
Память расчитывать исходя из 400-600Мг/чел (хотя у Вас могут быть др цифры, попробуйте завести самого "жирного" в терминал и поработайте). Мои берут и по 1,5Гб на брата, но правда и не отказывают себе ни в чем

raid1 хорошо, но raid10 лучше

Кароче, нужен бюджет, как ни крути

Comments

[АртемЪ]

1С любит быть в терминале, так уж сложилось исторически.

Не согласен.
В общем то терминал действительно нужен, когда база файловая а сеть хреновая. Чисто чтобы по сети не гонять.
В остальных случаях - прекрасно работает без терминала. Тут уж как кому удобно.

И если уже переходить на RDP, то всю рабочую среду пользователя нужно переносить в терминальный сервак

Ну ни в коем случае.
Я сколько терминальных серверов настраивал - главное запретить работу с браузером. В терминале никакого браузера.

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

А так - если 1с в терминале, то только 1с, и ничего более.

raid1 хорошо, но raid10 лучше

Чем лучше???
Если файловая база - SSD надо, тут RAID вообще никак не поможет. SQL к дискам менее требовательна, но тоже при наличии финансов SSD.

По поводу бюджета - 150файловыйх бухгалтерий крутятся прекрасно на сервере уровня core i5, с 16 ОЗУ, и
парочкой SSD Samsung
Там по бюджету - если очень скромно - 50тыс.
Если более- менее 80-100, а за 150 вообще избыточно.

Answer 5

[VitalyChaikin]

Иногда такой лаг возникал, когда один из юзеров, печатал на свой принтер и теперь при входе 1С как-то пытается найти этот принтер, а его нет (выключен в данный момент) Именно при терминальной работе наблюдалось.
Так что проверьте этот вариант.