База в 300 Гб, 200 пользователей, Как правильно организовать архитектуру, чтобы не тормозило?

удалить

(1) флудить не надо

что лучше 2а сервера или один но топовый, если два сервера я так понимаю слабым местом будет локальная сеть которая будет их соединять, как правильно организовать резервирования БД, чтобы все оперативно восстанавливать и т.д

(2) хорошо, если про 2 сервера как серверы приложений и СУБД, то меж ними можно прокинуть и прямой 1Гб провод

(4)Если гигабита маловато будет, то можно подключить еще пару сетевух и прокинуть 2-5Гб.

Вообще при таких объемах думаю что удачней будет разделить сервер БД и сервер 1с.

(0) Что за база? Типовая, переписанная, самописка?
200 пользователей — это постоянное количество или максимальное? Насколько активные пользователи?
Работа в терминале или через тонкий клиент?
Какие серваки, какие локалки?
MS SQL?
Чем занимается контора?

(3) Резервирование делается автоматическим бекапированием, например полный бекап раз в сутки и инкрементный раз в час.

(3) Два — это в смысле один для скуля, другой для 1С или что?

>>инкрементный раз в час

есть вероятность, что инкремент будет делаться не менее 10% от бщего времени системы

(10) 1. С чего бы?
2. И что, не делать бекап?

Один топовый
Оперативно восстанавливать - это перекинуться всей братвой на резервный сервер (тоже топовый)
Иначе не будет оперативно...

Я за 1 топовый. За счет шаред мэмори будет прирост, а сервер 1с и sql не сильно пересекаются по ресурсам.

(0) уважаемый, тупить не надо
ЗЫ два юзера могут тупо забанить себя на неделю с корректировкой одного и того же дока
ЗЫЫ не думаю что с быстродействием быстрее дойдет

(11) Зеркалировать же. На резервный SQL сервер.

Вариант такой - пробить 2 сервера топовых на ссд.
Поднять 1с и скл на 1 и попробовать как будет работать. Если будут жалобы поднять скл на 2м сервере. Если будут жалобы вернуть к 1 варианту. 2 сервер пропить и уволится.

(0) А с чего ты решил, что вообще будет тормозить?
Размер базы и количество пользователей не влияют на тормоза.

(0) Кособокий взгляд на проблему. Ты смотришь на проблему со стороны админа. Т.е. пытаешься решить "железом". Неизвестно, что у тебя за конфигурация. Неизвестно, насколько она кривая и не оптимальная. В общем, мало данных для принятия решения.

Любой совет - пальце в небо - без обследования и замеров.

(0) база не большая, средненькая...

два сервера
1. на скуле 64 памяти и два быстрых 10 рейдов, отдельно рейд база+лог, отдельно темп ДБ+система, камней можно не много... основной упор на диски и память... плюс медленый винт для временого хранения бекапов

2. сервер 1с памяти 32, быстрый диск под систему (под кеш и логи сервера 1с), камней побольше...

оба сервера но ОС 64х, сервер 1с и скуль 64х

(0) Разнести сервер приложения и SQL, На SQL не менее 128(лучше 256)памяти, на сервере приложения 64(128). Сеть между ними не мене 10G. SSD диски. Желательно топовые процессоры.

(17) совсем-совсем? ))

(0) А как у вас организовано сейчас, что все так тормозит? :)
И поподробнее, пожлуста

(0) 1 хороший сервер, памяти от 256 гб и рейд из SSD типа intel S3700. Будет летать.

(4) (6) Почему SHARED MEMORY хуже? Или вы не в курсе этой технологии?

(16) Т.е ты не знаешь и предлагаешь самим экспериментировать

(0) 200 пользователей чего? Платежных документов? Пасьянса "косынка"?
Какое допустимое время простоя?

(0) Хм, ИМХО, сложно советовать по сферическому коню в вакуме. Нет ни нагрузки, ни активности этих 200 пользователей. Нет анализа самой конфы. Может там во всех динамических списках по 3-4 вложенных запроса с соединениями по регистрам. Или при проведении дока на 1000 строк идет цикл по ним с запросом. Да и вообще надо смотреть чего не хватает сейчас: может процы простаивают, а память уходит в своп.

2 хороших под кластер мс скл, 1 топовый под сервер приложений 1с. под бэкапы схд понадежнее.

(22) Грубо говоря эти параметры не являются определяющими.

(25) я пробовал. Процент прибавки около статистической погрешности. Но при этом у тебя начинается борьба за ресурсы, в т.ч. за винты

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

Т.е. когда у тебя 5 человек и ресурсы сервера позволяет, то будет небольшой прирост (не факт что он будет заметен невооруженным глазом), но когда у тебя 200 человек ... тут банально не одни винты не справятся с обработкой данных от сервера предприятия, клиентов и скуля, т.е. тут шаред мемори - как мёртвому припарка

(0) пригласите специалистов

(31) 200 человек это много? 0_о

(31) Зачем 1С винты?

Я вот сейчас смотрю в мониторе ресурсов на сервере во вкладке  "Нетворк" задержки у rphost до 250мс на гигабитном канале. Это четверть секунды! И это на каждый запрос к sql.
Сам я лично не тестировал перенос на один сервак sql+1c. Но задумываюсь.

(35) Может 250мс время выполнения запроса сервером СКЛ?

Без анализа можно только гадать. Советую ТЖ настроить и посмотреть все этапы.

(34) лог писать

(35) один сервак будет работать медленее, причина - разная оптимизация и борьба за ресурсы.

кроме того два сервака лучше в плане масштабируемости, проще делать кластеры, отдельно скульный отдельно 1с, где проблемма - там и делаем кластер...

ну и как всегда для тестирования советую
http://wiki.mista.ru/doku.php?id=it:analiz_sql_block

(35) Гигабитный канал мало, проверено на практике...

(26) а что не так с зеркалированием? это экспериментальная технология? )

(39) эммм у меня аналогичная самописка работала на 100 мегабитном канале без проблемм, загрузка сети была примерно 60%.

разумеется линк прямой и настроки маршрутов специальные...

ихмо гигабитного линка - за глаза....

(37) Лог пишется на отдельный диск, о чем ты?

(42) есть лог скуля а есть лог 1с (файл регистрации), я про второе...

(38) Это твоя теория или ты проверял?

(43) Ты же в курсе, что лог можно писать на другой диск?

(43) кстати новый формат файла регистрации - реально рулит :)

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

(39) 10Гб стоит как новый сервер

(47) Но если он не будет конфликтовать с SQL в чем "борьба за ресурсы" по твоему?

(44)проверял, правда не совсем честно, проверял на слабеньких двух физических серверах, разница примерно 20% при 100 активных сесиях

(50) А Гилев говорит обратное. Кому верить?

(51) верить никому нельзя! мне можно... (с) Мюллер :)

я-же написал - не совсем честно....

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

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

(41) Самописка может быть, для УПП среднего производственного предприятия мало.

Что ни купи - все одно плохо будет...

(48) Ну вроде в стартовом сообщении про бюджет ничего не говорилось... Для более-менее крупного предприятия затраты на сервера в 10-15 млн, которых хватит лет на 5 минимум, в общем не существенны.

(0) Что-то мне подсказывает, что прежде чем управлять такими базами с таким количеством пользователей рулевые должны набираться опыта на чем-нибудь попроще ;-)

(0) В Вашем случае вопросов по идее уже возникать не должно.

(46) А где можно почитать про новый формат файла регистрации?

(55) Никто не любит отдавать деньги, что крупное, что мелкое предприятие.
Тем более к этом серверу еще и обвязка соответствующая нужна.
И какой-то регламент падения этого сервера...

Кстати , а MS SQL для таких больших баз уже нужно энтерпрайз версия или стандарт еще справляется?

(60) размер базы не влияет на выбор версии sql

(46) А можно с цифрами?
Вчера для теста перевел журнал размером в 1гб со старого на новый формат.
Результаты:
1) Долгая конвертация (1Гб > 10 минут, а у нас журнал 50Гб за полгода, он весь день будет конвертироваться)
2) Отбор по полю "Представление данных" стал быстрее всего на 30% (тест на 1гб журнале в старом размере).
3) Размер журнала стал на 80% больше старого (и вместо 50 гб очень неприятно будет получить 90гб)
4) Теперь всё в одном файле, нельзя разбить по дням.

Одна надежда, что с ростом размера в новом формате всё-таки будет работать отбор. В старом - не дождаться.

(58) http://v8.1c.ru/o7/201310log/index.htm

(59) А это уже вопрос, как обосновать необходимость приобретения железа. И сервера обычно уже со всей обвязкой идут, если есть опасения в падении - можно взять дополнительные сервисные пакеты. Ну и конечно нужен грамотный специалист, чтобы все это настроить и запустить в работу.

(62) а на 5 и 10 гб провести тест? имхо, по п.3 прирост веса новой таблицы на дальнейшие гиги старого журнала будет несущественен.

(62) долгая конвертация - 70 гигов примерно 20 минут
отборы реально работают а не вешают сервак
размер увеличивается но не сильно вместо 70 стало 75
бить по периодам вроде можно...

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

(3) два сервера и между ними прямой линк две сетевые 10 гигабит.

(0) Автор вроде убежал .... а так  -  СХД шустрые ставте ибо  все  на временных  tempdb построено . Бесконенчый  insert ,update

temp разбить .. файлов на 6 -7

опять знатоки оптимизации повылазили, че вы спорите на пустом месте, автору все равно не поможете у него все равно знаний не хватит

к тому же на франч работает похоже

(70) +100500 Спор пикейных жилетов на бульваре. Уже и ТС давно нет, а они все спорят как повлияет погода на урожай капусты на островах Кука

(66) Какая версия 8.3?
У меня на 8.3.5.1146 лог в 5Гб уже больше часа конвертится (уже 8Гб размер нового файла)

(2) он прав.. флудите вы..

(67) бугага....
Жж0те...
Там и гигабит никогда заполнен не будет..

Епти... нифигасе себе тут отписали пока меня не было, знаний по оптимизации хватит, но хотя хотелось бы ваши удачные примеры оптимизации тут увидеть , как говорится век учись век живи, всего знать не возможно)) как вы настраивали 1С Сервер? какие параметры настроек выставляли? как оптимизировали работу MS SQL начиная с версии 2008 под базы большого объема на топовых серверах и не очень???

(70) а то крутых тут дядек много, что они тут типа мега спецы по оптимизации и все такое.. только мало че толкового предлагают

(77) есть жалобы пользователей на работу?
если нет, настраивайте бэкапирование, на остальное забейте - иначе возможно сделаете хуже.
при появлении жалоб, сморите конкретные места тормозов и делайте анализ в чем дело. Скорее всего дело будет в коде, его и оптимизируйте.

(76) Мы оптимизировали структуру БД и код. Никакой гигабитный линк (бугога, его еще и забить нужно) тебе не поможет с кривой базой. Бери подороже сервер и спи спокойно. Настройки в инете есть.

(76) А я-то думал, что только пользователи мечтают о одной большой кнопке...

(76) Ставиь 2 сервера по 1 млн. и будет счастье (один - основной, второй - зеркалирование).
Бюджет озвучь!

+ (81) долларов непременно ;)

(0) вот тебе вариант для нищебродов: последний коре и7, 64 гига оперативы, 4 винта хитачи в 2 по первому рейду - на систему и на базы, винсервер 2003 х64, сервер 1с х32, скулю отдаешь 40 гигов, остальное добиваешь количеством процессов 1с (8 штук должно хватить, в принципе). если вдруг найдете денег на 128 гигов, то 80 скулю и 16 процессов 1с.

только потом отпишись, чокак получилось. и да, тему я не читал :)

мсскуль 2008р2, ради сразужатых бэкапов, да

(83) И это будет ворочаться при 200 юзерах?
Да не смешите мои тапки!

(85) не, ну если задача освоить средства, тогда да...

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

опять же можно помериться с другими: http://infostart.ru/public/173394/

(0) Пара дестктопных тачек легко потянут при грамотной настройке

(75) > Там и гигабит никогда заполнен не будет..

Максимум, что я наблюдал - 500 Мбит. Но дело не в скорости, а в меньших задержках на сетевой интерфейсе при росте нагрузки. В этом смысле 10 Гб лучше 1 Гб.

http://www.softpoint.ru/article_prn_id4226.htm