8.х 1C Предприятие сервер и MS SQL 2008 проблема...

Доброго времени суток, коллеги!



Ранее работал с небольшими конфигурациями и использовал файловый вариант. Теперь появилась необходимость развернуть УПП с 30 пользователями....



Собственно всё развернуто успешно. Почитал мануалы всё сделал по пунктам...



Результат: Сервак Xeon 6 ядер, 16 Гб ОЗУ, 4 винта SAS 10k в рейде 0+1, Hyper-V на нем виртуалка Win 2008 R2, выделил тестово 2 ядра и 10 гигов оперативы, на SQL крутится 4 базы по 5 гигабайт. одновременно работает в среднем около 15-20 пользователей через терминал.



Проблема: Во время работы\простоя SQL занимает всю оперативную память. Например утром пока никого нету 3Гб занято другими приложениями, почти 7 Гб sql, как заходят пользователи sql уменьшается до 3х Гб, остальное терминалки... И 1С сервер частично перемещается на ЖД в файл подкачки, что вызывает тормоза... Добавил виртуалке еще 3 Гб оперативы... ситуация повториласть, sql занимает всю свободную оперативку, 1С сервер вытесняется на ЖД



Вопрос: Какие есть пути решения данной проблемы? Вижу несколько: жестко задать объем sql(как это сделать?), повысить приоритет процесса 1C сервера(как это сделать?), увеличить объем оперативной памяти если для такого объема баз на самом деле этого не достаточно...



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

Причина: MS SQL штука умная, и по возможности старается закэшировать наиболее часто используемые записи в оперативку (оперативка оперативне хардов то?) Пока утром возможность есть, так SQL и поднимает ВСЮ БД (ежли она одна, ежли не одна, то наиболее часто "дергаемые" куски этих БД) в оперативу.
Когда в течении дня начинают работать люди, и требуют ОЗУ и под себя - скуль умеряет свой пыл, и уменьшает размер кэша в ОЗУ до некиих приемлемых размеров.

Решения:
1) Разнести SQL+1C и терминальник по разным серверам (дорого, но правильно)
2) Добить в сервер оперативы объемом превышающим суммарный объем БД + запас под терминальные сессии (тоже не дешево, да еще и не совсем правильно)
3) Ограничить объем ОЗУ занятый под SQL (в настройках сервера через менеджмент студио ищите)

16 гигов на сервере с 4 активными SQL базами по 5 гигов (20 гигов суммарно), на котором еще и 1С, еще и терминал :blink: - точно что мало.
Нужно наверное как то так:
SQL - 5 х 4 + 2 = 22 Гб
1С: 4 Гб
терминал: 0.5 - 1 гб на сеанс = 10 - 20 гб
ИТОГО: 22 + 4 + 20 = 48 => 64 гб (2^6). Если сервер конечно поддерживает такой объем.

"опускать" и "поднимать" приоритеты служб самостоятельно не рекомендуется. Это вряд-ли даст сколь либо существенный прирост производительности в данном случае, а вот проблемы заполучить можно вполне натурально.

6 ядер на 2 активные службы (1С + SQL) - нормально, но если еще туда и загонять терминальных пользователей - мне этого кажется недостаточным.
Зачем в случае с MS SQL ным вариантом 1Ски нужен еще и терминальный сервер, если все юзеры сидят на не самых тухлых тачках, и в одной локальной сети - для меня загадка (или у меня неверный посыл в условиях?)

to shurikvz:
1 Скачаю обновление, попробую поставить... а до SP3 SQL обновляется без проблем? Не будет ни каких конфликтов с базами\заданиями\пользователями?
2 Регламентные задания настроил согласно этим рекомендациям...

to uza:
Я конечно понимаю что в идеальном случае нужно чтобы вся база была в оперативе и всё летало))), но:
Во первых до этого та же система крутилась на обычном системнике Core2Quad, 8 Гб озу и сата диски в зеркале и после переноса на желехо превосходящее прошлую конфигурацию в более чем 2 раза особого прироста производительности я не заметил... Вот это в первую очередь смущает...
Во вторых есть слышал от других програмистов о том что у них крутятся на 32 Гб ОЗУ базы размером до 80 Гигов и не испытывают особых проблем...
По последнему пункту отвечу что машинки на местах действительно слабые и даже Почта+Скайп+Офис+Браузер держат с усилием... если запускать еще и 1с то появится еще одна проблема


Вопщем понял что нужно сделать 2 вещи:
1 Обновить SQL c SP2 до SP3
2 Попробовать урезать размер процесса SQL сервера
3 "Клянчить" у руководства деньги на оперативу)))

После того как сделаю отпишусь... Спасибо за оперативный ответ.

В два раза? Это вы по каким критериям оцениваете то? Можно еще оценивать по потр######емой мощности, ага. Еще по размерам "коробки" - тоже вариант. Еще можно по массе коробки. Тогда какойнить 10 летний Пролиант 4100 (вес что то под 80 кило) должен был бы просто в клочки рвать ваш
Гигагерцы сегодня - это просто цифирька. Одно ядерный P4 на 3.2 ггц в большинстве бизнес задач сегодня слабее какого-нибудь Атома 230го (1 ядро на 1.6 ггц).
Прирост производительности - вещь многогранная. Иногда затыка идет не на уровне железа, а на уровне исполняемого кода. Можете проверить, что какойнить Excel 2003 с 50 000 строками и 30 колонками проведет обсчет макросом этого бардака на C2D (2.6 ггц / 2гб / sata) лишь на проценты (даже не десятки процентов) медленее чем на сервере с двумя оптеронами о 6и ядрах кажный (2.6 ггц / 8гб / SAS Raid 10)

А чем вы замеряли эту самую производительность? Какой нагрузочный тест использовали? Условия самого теста остались исходными (программное окружение, количество задач, количество запросов и т.д.)
Перенос с файла на MS SQL сам по себе может не только не увеличить производительность, но даже и уменьшить. Но тут ведь еще есть понятия "надежность", "масштабируемость".

Да без проблем. Не обязательно ведь всю БД поднимать в ОЗУ. Скуль умный (и денег стоит, возможно это как то связанно) он кэширует только наиболее часто используемые куски БД, и старается для этого задействовать не всю ОЗУ (другое дело, что алгоритмы иногда не сочетаются с реальными задачами - ну для того в настройках можно самому поковырять).
Т.е. будь у меня БД хоть 2Тб, но если я из той БД только читаю/модифицирую по десятку записей из пяти таблиц - так это можно и крутить даже на 1-2 Гб ОЗУ. Кэшировать то и нужно только эти 10 х 5 записей (пара-десятка метров). Так что все ж индивидуально. У меня вон на девелоперском сервере 36 бд, каждая по 15-25 Гб. А ОЗУ только 8 гб. Правда на сервере только скуль и 1Ска. Но всего хватает, и даже можно сказать что не многим медленее работает чем боевой сервере с тем-же железом и прог. окружение, но всего 3мя БД (12, 25, 43 Гб) и ОЗУ 16 Гб.

P.S.
Что то я разошелся. Видать весна - обострение.
Резюме же такое: то что я сказал в прошлом ответе - рекомендации, а не руководство.
ОЗУ желательно поднаростить - однозначно.
Серверы терминалов и 1С+СКУЛЬ разнести на разные машины - да, тоже бы.
Скуль можно в настройках "урезонить".

Деньги клянчить не надо. Это нужно не Вам, а вашему руководству. В конце концов размер вашей ЗП наверное не зависит напрямую от прибыльности компании. Деньги нужно просить.
Как мотивацию можете привести то, что все равно желательно иметь резервные мощности, чтобы в случае П можно было оперативно перевести работу на тот же терминал (пусть и с потерей производительности), чем в случае "П" бегать по городу и искать у кого можно здесь и сейчас купить сервер (либо ждать гарантии, которая подико у вас еще и не расширеная до "24 часа на решение или замену оборудования").
Руководство при такой мотивации быстро может прикинуть что оно может "поиметь" в виде убытков за 2-3 дня простоя.

Отсюда правило: усугубляейте, резонируйте и контрастируейте.
Усугубляйте - допускайте специально неоптимальные моменты. Главное помните где они. Когда нужно будет срочно показать нужность и пушистость - закоментите и аааааать.
Резонируйте - в ответ на "а вот у [companyname]..." отвечайте что у [companyname] штат айтишнков выше, оборудование другого класса, и вообще "вы все г..но, а я вот в белом". Маленькие глючки доводите до трындеца. Особенно это умеют бухи "А-а-а-а-а-а все пропало! А-а-а-а-а базы нет!!1 А-а-а-а-а мы не сдади отчетность!!1111 А-а-а-а-а нас всех посадят!!!!1111адинone"
Контрастируйте - при описании возможных последствий не стесняйтесь приукрасить аки Пикасо под грибами. Если даже по вашему довольно типовому (на сегодня) железу замену БП можно проивзести оперативно (с доплатой) за 4 часа - укажите что это может занять до трех дней. Если заменить мать можно за три дня, то укажите "поставка оборудования из за рубежа может занять МЕСЯЦ!!1111"

Лучше как говориться перебздеть, чем недобздеть.

И да, пусть у Вас все будет Х.О.Р.О.Ш.О и резерв ни когда не придется задействовать на 100%.

P.S.
А диры, да, в большинстве котор такие. Являясь единственным владельцем, живя в центре и катайся на майбахе не может изыскать сраную 1000$ для резервного кондея в серверную.
Просирая сотни тыщ на корпоративы (с дибилдингами и мадонами) жмутся на закупку нормальной станции.