У нас на 7-ке оперативный учет и на 8-ке бухгалтерия и зарплата, все базы SQL, около 40 пользователей, но нет терминального сервера. Если ставить терминальник, прирост производительности будет при работе какой-нибудь или нет? Узкие места на 7-ка переписаны на прямых запросах, но всё равно бывают блокировочки, решится ли проблема блокировок?

Или терминал актуален только для файловых баз?

с блокировками полегче будет...

(2) может быть, а может и нет

С терминалом самые хреновенькие клиентские места будут просто шуршать

(3) скорее всего...

если клиенты дохлые, то терминал однозначно, тут и думать нечего. особенно для 7.7...

(0) опиши конфиги рабочих мест и сервера тогда уж

У нас нормальные компьютеры на клиентских местах. Админ предлагает  поднять терминальник в виртуалке на SQL сервере, дескать он всё-равно больше чем на 25% не загружается.

(8) бред какой то

т.е. на виртуальном сервере сервер терминалов не лучше не поднимать? Одна из его мотиваций - данные между сервером и терминалом будут ходить в пределах 1-ой физической машины, не будут "гулять" по сети.

По-идее можно отдать сам скуль сервер под терминалку. Секурность будет вполне достаточная, если пользователям права не расширять на сервере. Терминалка в виртуалке - это извращение, 1с-ка достаточно много кушает, тем более при 40-ка пользователях.
По сетке 7-ка работает достаточно печально даже (тем более?) в случае скуля, т.к. скуль используется ограниченно. А в случае 40-ка пользователей - комфортная работа без терминалки возможна только при совсем микроскопической базе.

(10) если только для теста

(10)пока не попробуешь - не узнаешь. Сделайте, потОм тут расскажешь надо это или нет.
Я делал, но наоборт - в виртуалке на сервере приложений ставил скуль. Хуже по сравнению сотдельными физическими машинами не стало точно (во вяком случае юзера не стали жаловаться).
Но там основной мотив сэкономть на лицензии на виндовоз...

эпично тут у вас...

(3) стопроцентно будет легче. Разве что эффект будет... гомеопатический :) Но в случае сервер скуля=сервер терминалов эффект будет вполне заметен.

админу в бубен дать не предлагали?

Не, не предлагали. Обидится же, уйдет, кто сеть ковырять будет?

Терминал в виртуалке извращение,
а так физически будет лучше

ОК, ставим терминал на SQL сервере безо всяких виртуалок. Всем большое спасибо.

(8) >> он всё-равно больше чем на 25% не загружается.

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

Разворачивать терминал на сервере, где СУБД крутиться я бы не стал. Терминал дофига требует памяти и ресурсов. Производительность дисковой подсистемы тоже сильно упадет. Даже если терминал будет только для 1С.

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

(20) Дисковая подсистема - 2 SSD в зеркале, правда не серверных, взяли на пробу обычные Corsair, как показала практика, SQL быстрее не заработал.

(21) - значит криво SQL и система настроены
полностью конфиг сервера - процы, ОЗУ диски
размеры баз
что на каком диске лежит...

+ версия и релиз SQL...

(22) Двухпроцессорный Xeon E5620 2.40 GHz, RAM 8ГБ, система стоит на обычном диске, базы и temp на SSD. Размеры основных баз: оперативный учет (7.7) 2,5 ГБ, Бухия (8.2) 25ГБ, ЗуП (8.2)

SQL 2005, версия не знаю какая, Managment Studio - 9.00.5000

Microsoft SQL Server Management Studio        9.00.5000.00
Microsoft Analysis Services Client Tools    2005.090.5000.00
Microsoft Data Access Components (MDAC)        6.1.7601.17514 (win7sp1_rtm.101119-1850)

Что еще... Ну на SSD по всем понятиям больше половины свободно для шустроты. И чё, как-то надо специально настроить, тогда взлетит со страшной силой?

вообше то сервак на SSD опасная штука. можно остаться вообще без ничего

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

(28) да ладно, у мня база, вообще на РАМ диске была

(29)+ ну и зеркало конечно на всякий пожарный

(0) Блокировки увеличатся. Причина и решение описаны например тут http://openconf.1cpp.ru/vk/prior/

(32) Есть же таблетка от ромикса для этой беды

У меня недавно была похожая задачка. Нужно было значительно ускорить доступ к семерке в базе размером примерно с гиг, 20 пользователей онлайн.
1. Семерка под СКЛ работает МЕДЛЕННЕЕ чем в файловом режиме, если нет большого количества блокировок (которые порождаются большим кол-вом пользователей ПО СЕТИ (!))
2. Самый важный аспект быстродействия базы - не проц и не память а скорость чтения / записи на диск. Причем скорость произвольного доступа наиболее важна.

Из этих двух несложных соображений родился выход. Купил тупо геймерский комп без видеокарт, в него воткнул SATA3 USSD диск. И поднял на нем вин 2008 с терминалкой.
Системник обошелся в 50 тыс. руб ( но я его навернул без меры заради терминалов - i7, 24Gb mem) Можно сделать и в 25-30.
Я запретил вообще доступ к рабочей базе по сети, только в терминале (нет сети - нет медленных блокировок, роляет только скорость доступа к дискам)
Итог - все летает при активных 20 сотрудниках, причем даже быстрее чем было при открытии той же базы в файловом варианте монопольно со старого локального компа.

(33) ну собственно я и написал что решение там же ) только не от ромикса, а орефкова.

Да, вариантом сопоставимым по скорости с USSD будет 50 рейд с аппаратным контроллером (а значит аппаратно серверное решение - что дорого и бессмысленно для 7, овечка не стоит выделки)

(32) - не факт....
(33) - попробуй поискать статьи Гилева, было достаточно хорошо описано что зачем и почему.
ЗЫ: регламентные задания на SQL - реорганизация индексов, обновление статистик настроено?

(34) у тебя база ФАЙЛОВАЯ? У нас возврата к файлу уже нет, всё переписано на 1c++
(35) ну да, это я потом уже дочитал, спасибо

(36) как раз для 7, овечка и стоит

+ 37 - имхо: если блокировки были бы, то были бы уже сейчас

и вообще хватит колеса пинать и фары протирать :)

(37) Настроено, но мы это всё хозяйство в III-ем квартале только включаем, когда база распухает

т.е. 25 гиг это база маленькая еще?
стоп а 8.2 - сервер приложений где стоит?

(43) В бухгалтерии работает 8 человек всего, и там как раз блокировок нет. Сервер приложений стоит. А в опер учете на 7.7 сейчас на маленькой базе 2,5 ГБ блокировки пока редки, в основном во II полугодии начинаются проблемы, когда объемы начинают сеть забивать.

Интересуюсь: чем это терминал на виртуале плох?

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

Вспомнил одну историю из практики, может немного не в тему, про прямые запросы. У одной известной, ныне вроде почившей в бозе торговой сети стояла база для кассовых аппаратов на оракле. Ежедневно каждый магазин, как и водится, снимал зет отчет и сверял с базой. Так вот движок оракла пересчитывал все кассовые чеки всей сети магазинов за 7 лет (!!!!), чтобы выдать итог в конце дня. Это действо занимало на оракле 2 минуты, от чего местные админы очень перлись. Их впечатляла скорость оракла (там более 2 тыс чеков в день, сеть крупная).

ну, то Оракл, у нас если в ноябре бухи внезапно залезут в март чего поправить ГП нарушается и наступает сезон тормозов, пока ГП не восстановлю

(44) - сервер приложений стоит на той же машине что и SQL?

+ 7.7 при таком объеме летать просто должна...
замеры по использованию памяти и дисков делали?

(48) Да, на том же.
(49) Нет не делали, надо? Скажи как?

(49) Да оно и летаэ, говорю же когда база от 5 Гиг начинаются блокеровкэ, раньше на штатных запросах и выборках вообще жуть была.

(24) >> Xeon E5620 2.40 GHz, RAM 8ГБ

Это извините как???

(52) Так, открыл "Мой компьютер" - "Свойства" и переписал сведения о системе. Что настораживает?

(53) 1) 8 на 6 не делится.
    2) 8/6 примерно чуть больше 1,33, вы меньше планки серверной памяти искать не пробовали?
Для справки KVR1333D3D4R9S/8G стоят около 100 у.е.

(54) т.е. надо кол-во памяти как-то кратно устанавливать?

у нас 2-ве планки по 4-ре Гига если чё стоит

(0)Есть две заповеди-
Работаеть - не трогай!!!
От добра добра не ищут.
вот на них и ориентируйся.

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

Нужно смотреть какая материнская плата. Обычно если люди потратились на два Xeon E5620 и мать и корпус под них 300-600 долларов на память не жалеют и ставят минимум по три планки на процессор.

Думаю если в ваш доставить еще 4 таких-же планки 60х4=240 у.е.,
SQL сможет базу 7.7 на усб носителе хранить, без потери скорости.

(52)Что там непонятного?
(54)Что за бред? Нафиг ты делишь объем оперативки на 6? От нечего делать?

(57) Если б я не трогал, всё бы лежало пластом. Есть еще проблемы, т.е. можно сказать "иногда не работает", по этому трогаю.
(59) Т.е. для увеличения скорости работы SQL необходимо увеличить количество планок, чтобы все банки были заняты? Хм... первый раз слышу, но пну одмино, пусть почитаэ в этих своих интернетах.

+(60)то ж не понятно зачем память делить ?

верятно, делит на кол-во слотов/каналов...

и шо если у меня в серваке 8 слотов их все надо забивать ?

(60) (62)
http://www.nix.ru/support/faq/show_articles.php?number=722&faq_topics=LGA1366-LGA1156-LGA1155

(64) С твоими знаниями нужно админа позвать.

(64)не знаю.
Но факт, что декстоп с 2*2 работает заметно шустрее, чем 1*4.

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

(66) Естественно в памяти второй показатель после объема ПСП.
И имея два недешевых процессора с трехканальным контроллером памяти в каждом использовать всего две планки дешевейшей памяти по моему дико.

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

(68)скорее всего ты прав. Оптимально - (по планке на канал)*(кол-во камней).

(69) добавишь памяти и поднимай, бекапы еще в обед добавь.
Приказом директора по организации.

Я ж написал ответ. Он касается и скуля тоже, потому как 7 (как и 8 впрочем) НЕ создает запросов на запись массива, все делается построчно. Что создает блокировки, и пофиг какие они, файловые или средствами скл. а сетка эти блокировки растягивает во времени.
Только в случае с скл базой прирост в скорости ты получишь небольшой, но лаги уйдут. Только отруби сетевой доступ к базе, это обязательно.

(71) Думаешь стОит еще и в обед? У нас в 4:00 ежедневный бакап на другой диск + винты в зеркале.

(72) Да, я услышал тебя, собственно терминал поднимается не для ускорения, а для решения блокировок, но если плюсом еще бы и бонус по производительности пришёл было бы очень хорошо.

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

У меня обработка автозакрытия 1С, единственное - может где заглючит ВК и системная ошибка выскочит, но я в мониторе смотрю у кого и РАдмином пасу, бегать по кабинетам влом!

Не я в обед руками выгоняю посоветовавшись предварительно с ФД и ГБ.
А вообще жду пока этот мужик свою разработку допилит.
http://forum.infostart.ru/forum24/topic53302/?PAGEN_1=2
Пока глючная страшно. Раз сервер наглухо повесила.

Так VNC Viewer на что?

(77) Да чё там пилить? Обработка событий и константа = ВсеВон! + монитор константы ПриЗапускеСистемы, чтобы незалазили обратно. Оповещение тоже кидаю через 1С событие = сообщить "В 13:00 отключение оперучета 1С на 20 мин."

Традиционно я могу это делать в обед в 13:00 и в БОЛЬШОЙ ПЕРЕКУР в 16:00

(79) Сеанс зависший на моменте когда юзер задумался какой же у него пароль в 1С наставит тебя на путь истинный..

(79) Все таки почитай, задумка не плохая, если все выгорит и купить можно.

(81) Таких я гоню из сервера по открытым файловым шарам, просто закрываю users.usr и их всех выносит )))

(46) При чем тут Оракл? В 2008 году мускл из набора записей овер 3млн. выдавал суммирование с группировками менее чем за минуту. Так что Оракл тут абсолютно не причем.

(47) имею чисто академический интерес, каким образом ГП связана с тормозами?...

40 юзверей - не такая уж и большая нагрузка.
хотя нужно смотреть на документооборот.
-----------
для тестирования сервера есть неплохой скрипт, известный как "скрипт vde69" :-)

(85) напрямую.
если бы бухи не были такими тормозами, они не полезли бы в ноябре править март....

(85) Последовательность улетает в март и 1С вместо того чтобы брать готовую цифру начинает рассчитывать помесячные итоги.