Сервер 1С и SQL. Отдельно или вместе? #526550

Хочу узнать мнение тех, у кого был реальный опыт сравнения работы 1С и SQL на отдельных серверах и на одном. Имеется платформа 8.1 (8.2 пока не будет) Сервер с 32Гб озу. На нем же сервер 1С (10 процессов). Для SQL выделено 22Гб озу. Сервер 1С съедает обычно 7Гб. База 70 Гб. 130 юзеров. SQL обычно грузит процессоры на 30-40%. Диски справляются (RAID 10). В последние время стали медленнее работать отчеты. Похоже, из-за роста базы (и рост ускоряется, т.к. документов вводится всё больше). Есть ли смысл выносить сервер 1С на отдельный сервер, а SQL дать больше памяти? Не будет ли обратного эффекта из-за того, что взаимодействовать SQL и 1С будут через сеть, а не внутри одного сервере? p.s. дорабатывать конфигурацию, добавлять индексы не предлагать, она постоянно оптимизируется по-возможности

В идеале - на разные сервера, между ними прямая ветка гигабита с правильно настроенным рутингом...

[Диски справляются] раз счетчики на чтение нормальные, значит осталось балансировать нагрузку на CPU

Любой сервер при возможности ставить на отдельную машину и больше никаких серверов туда не ставить. Т.е. ответ: конечно выноси на отдельный.

1С тупить не начнет, обмениваясь с SQL по сети?

2 э... она и так с ним обменивается по сети...

бывает

2 этого же можно добиться и не разнося на отдельные железки.. разве нет?

никакой разницы, если машинка тянет. Более того, выкинуть платный sql, все загнать под линукс (+postgress)и не думать.

Постгри точно не будет. Скорее уж на SQL2008 перейти придется. Кстати, базы с сотней юзеров живут под постгри? Как-то нет доверия к нему.

мне на одном хосте 54 ошибку получить ни разу не удалось

ага, послушай совет перейди на линь, хапни ощущений ))) потом отпишись тут, поржем вместе )))

по ссылке на Гилева почитай. у меня - живут.

если совсем линукс не понимаешь, то не трогайте его лучше.)

а скок рпхост каждый сжирает у тебя?

Вот тоже опасаюсь нестабильности при разнесении. Так-то всё спокойно (т-т-т), безо всяких 54.

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

что именно сжирает? памяти?

Зачем 10 процессов? Хватит и 2-3 Реиндексацию таблиц делал?

Реиндексация, обновление статистики, шринк по выходным. 2-3? 40 юзеров на 1 процесс - многовато, имхо. 8 ядер на сервере, пускай трудятся. rphost немного жрут процессорного времени. Основное - sql.

Можно еще обновить SQL до 2008 R2 и у таблиц включить сжатие данных - тогда SQL будет меньше отжирать память.

Интересная мысль. Но только когда до 2008 дозреем.

Не особо rphost и трудиться, обрабатывая данные 13 юзеров, зато все 10 заваливают очередями запросов SQl сервер

Кстати, попробуйте 64-х битный сервак, он получше будет (хотя бы на недельку с эмулятором, чтобы сравнить ощущения и определиться, или у франей на тестирование взять на недельку)

Надо бы еще проверить как формируются отчеты во время работы 130 юзеров и без них. Есть ли большая разница во времени?

Всё и так х64.

Нет большой разницы.

ИМХО разделение серверов тогда не поможет, надо

+ шаманить с SQL

а ты посмотри по блокировкам в скуле - когда база тормозит, они есть или их нет?

Дело не в том, что тормозит в какой-то момент, а просто постепенно увеличивается время отчетов. В последние месяцы увеличение стало более заметным (остатки не пухнут!). Например, отчет, который год назад на базе в 30 гиг строился 5 сек., сейчас строится в 3 раза дольше. Боюсь, что при 100гб будет недопустимо медленно. Хочется эффективной масшабируемости.

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

не разносить, увеличь объем оперативной памяти добавь диски вроде

ты писал что делаешь реиндексацию и обновление статистики. Под обновлением статистики ты подразумеваешь и очистку процедурного кэша тоже?

Скидывать данные в OLAP и, используя готовые данные из кубов, строить отчеты, например в OnVision .

Либо, что маловероятно, вы этот отчёт делаете за весь период существования базы и тогда рост времени построения отчёта понятен и неизбежен. Либо у вас некая неоптимальность в метаданных и SQL неправильно выбирает план запроса. Имею опыт использования связки "MS SQL Server + сервер 1С:Предприятия" как на одной машине, так и на нескольких. Этот опыт однозначно говорит, что сколько-нибудь значимое улучшение при разнесении будет только в ситуации нехватки каких-либо системных ресурсов - насколько я понял, не ваша ситуация. P.S. Процессов сервера 1С:Предприятие всё же слишком много, я бы оставил 4, максимум 6.

УТ 8.1 80 гиг 90 юзверей 4 года данных 2 раза разносил на разные сервера гигабитка между ними оба раза видимое ухудшение производительности мнение мое идет в разрез с политикой 1с перечитал по этому поводу много. спорить ни с кем не буду. Может мы с админом действительно что то не учли. Второй раз просто для сервера 1с выделили точно такой же сервак второй, с такими же параметрами. результат отрицательный. Как то так. производительность системы увеличили значительно за счет других методов(шаманили с сервером SQL и дисковым массивом)

, Спасибо большое за информацию! Про процессы подумаю.

Я тоже за ОЛАП.

ээ... это как? получается двойной сетевой трафик %)

2 Я про то, что даже будучи установленными на одну машину 1С и СУБД общаются по протоколу ТСП/ИП (я уж не знаю, можно ли указать 1С при МС СКЛ юзайть нэймед-пайп), пусть и через внутренний сетевой интерфейс.

где двойной сетевой трафик - не понял

да это так... под конец дня накрывает по-тихоньку

а не судьба в 2011 году перенести остатки в новую базу и в ней работать?

воткни в сервер вот такую вещь под файлы БД

В последние время стали медленнее работать отчеты. Похоже, из-за роста базы (и рост ускоряется, т.к. документов вводится всё больше). Попробуй сделать квази ОЛАП: Создай документы необходимыми данными для отчетов (вроде плоской таблицы) и юзай данные оттуда при построений отчета. Схожее реализовано в конфе "Анализ данных" в 77.

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

Про процы: во первых процесс от х64 может отъесть до 3-х гиг. У нас часто есть картинка, когда процесс доходит до 2-х, хотя нагрузки пока маленькие. Поэтому вместо 10 ужатых, лучше 3-4 полноценных. И еще 8.1 лучше сменить на 8.2, она интереснее и фич там больше (в плане админства)