Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Если все в dbf-ках, а не на SQL - то это нормальное... 01.11.06 15:48 Число просмотров: 3093
Автор: whiletrue <Роман> Статус: Elderman
Отредактировано 01.11.06 15:49 Количество правок: 1
|
> итак есть терминальный сервер, на нем 1С 7.7. одновременно
> от 50 до 65 подключений. сервер Хеон 3.0 памяти 4Гб. Citrix
> Metaframe 4. база всего одна. средняя сессия юзера 65-90Мб
> памяти и ну и от 5 до 25% загрузки проца. на сервере других
> задач нет
> тормозит чудовищно.
Если все в dbf-ках, а не на SQL - то это нормальное поведение, т.к. в файловой версии больше 25 пользователей не рекомендуется, иначе придется часто переиндексировать для скорости.
> планирую поднять еще один сервер на нем Citrix , кроме того
> поднять на 3-й машине MS SQL. базы залить на MS SQL,
> конфигурации положить одинаковые на 2 терминальных сервера,
> пользователей поделить пополам. решит ли это проблему
> быстродействия или 2-х серверов мало? какие есть еще
> варианты? у кого как реализованы подобные задачи?
MS SQL - точно должен решить. Он немного медленнее dbf-ок, но при таком количестве юзеров - будет выигрыш. Также для скорости можешь журналирование у SQL сервака отрубить (правда тогда откатить на какое-то время нельзя будет... но тут уже хозяин-барин)
|
|
<sysadmin>
|
Терминальные сервера, как разгрузить? 01.11.06 15:32
Автор: mentat[bugtraq.ru] <Александр> Статус: Elderman
|
итак есть терминальный сервер, на нем 1С 7.7. одновременно от 50 до 65 подключений. сервер Хеон 3.0 памяти 4Гб. Citrix Metaframe 4. база всего одна. средняя сессия юзера 65-90Мб памяти и ну и от 5 до 25% загрузки проца. на сервере других задач нет
тормозит чудовищно.
планирую поднять еще один сервер на нем Citrix , кроме того поднять на 3-й машине MS SQL. базы залить на MS SQL, конфигурации положить одинаковые на 2 терминальных сервера, пользователей поделить пополам. решит ли это проблему быстродействия или 2-х серверов мало? какие есть еще варианты? у кого как реализованы подобные задачи?
новый сервер под Терминал планируется 2хХеон 2.33 новый, памяти 8Гб. SCSI RAID5 под SQL будет машина Пень4 дуалкоре 3.0 памяти 4Гб. SATA RAID5
кто что думает?
|
|
SQL Server решит вопрос однозначно, однако настойчиво... 14.11.06 11:11
Автор: kokos Статус: Незарегистрированный пользователь
|
|
SQL Server решит вопрос однозначно, однако настойчиво советую ограничить оперативную память для работы самого сервера. Это делается в "SQL Server Enterprise Manager"->Свойства сервера->вкладка Memory, там выбрать "Use a fixed memory size (MB)"- указать хотя бы половину оперативки, иначе сервер жрет оперативку по возрастающей и в итоге происходят сильнейшие тормоза.
|
|
Я с несколько другой бухгалтерией работаю, но тут дело не в... 03.11.06 10:29
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 03.11.06 10:29 Количество правок: 1
|
> итак есть терминальный сервер, на нем 1С 7.7. одновременно
> от 50 до 65 подключений. сервер Хеон 3.0 памяти 4Гб. Citrix
> Metaframe 4. база всего одна. средняя сессия юзера 65-90Мб
> памяти и ну и от 5 до 25% загрузки проца. на сервере других
> задач нет
> тормозит чудовищно.
Я с несколько другой бухгалтерией работаю, но тут дело не в ней. Пусть даже это будет другая сетеавя база, активно используемая несколькими десятками пользователей.
Может и конкретные программисты что-то намутили, но я в первую очередь обратил внимание на "арифметику цифр". Если сессии требуется под сотню мег памяти, их количество достигает 60, приложения активны (то есть активно наравят вылезти из свопа), то выходит 60*100=6000 Мег или 6 Гиг надо. Естественно при расчете нужно еще четверть накинуть на систему и файл-кеш. Выходит, что 8 гиг минимум, чтоб не тормозило.
Проверить, что памяти не хватает легко: 1) При достаточно активной работе при пиковой нагрузке (все бухгалтеры не курят, а кнопки давят) лампочка диска будет гореть не моргая. 2) При активной работе даже 5-10 юзеров активность дисков будет минимальна.
Еще на загрузку проца можно посмотреть - может заодно можно рассмотреть раширение "многопроцовости" сервака.
> планирую поднять еще один сервер на нем Citrix , кроме того
> поднять на 3-й машине MS SQL. базы залить на MS SQL,
> конфигурации положить одинаковые на 2 терминальных сервера,
> пользователей поделить пополам. решит ли это проблему
> быстродействия или 2-х серверов мало? какие есть еще
> варианты? у кого как реализованы подобные задачи?
Если база файл-серверная, то разносить файловый сервер с терминальным не имеет смысла абсолютно и даже противопоказано. Если база клиент-серверная, то "под вопросом", поскольку при достаточной памяти и процессорных ресурсах все тансферы данных внутри сервака будут быстрее, чем по сети.
> новый сервер под Терминал планируется 2хХеон 2.33 новый,
> памяти 8Гб. SCSI RAID5 под SQL будет машина Пень4 дуалкоре
> 3.0 памяти 4Гб. SATA RAID5
Дуалькоре обязательно, а лучше два или четыре дуалкоре. При таком-то количестве юзеров пусть хоть одна десятая коре на юзера приходится. И если памяти более 4Гиг, то архитектуру лучше 64-разрядную. Можно и АМД64 рассмотреть.
> кто что думает?
|
|
Если все в dbf-ках, а не на SQL - то это нормальное... 01.11.06 15:48
Автор: whiletrue <Роман> Статус: Elderman
Отредактировано 01.11.06 15:49 Количество правок: 1
|
> итак есть терминальный сервер, на нем 1С 7.7. одновременно
> от 50 до 65 подключений. сервер Хеон 3.0 памяти 4Гб. Citrix
> Metaframe 4. база всего одна. средняя сессия юзера 65-90Мб
> памяти и ну и от 5 до 25% загрузки проца. на сервере других
> задач нет
> тормозит чудовищно.
Если все в dbf-ках, а не на SQL - то это нормальное поведение, т.к. в файловой версии больше 25 пользователей не рекомендуется, иначе придется часто переиндексировать для скорости.
> планирую поднять еще один сервер на нем Citrix , кроме того
> поднять на 3-й машине MS SQL. базы залить на MS SQL,
> конфигурации положить одинаковые на 2 терминальных сервера,
> пользователей поделить пополам. решит ли это проблему
> быстродействия или 2-х серверов мало? какие есть еще
> варианты? у кого как реализованы подобные задачи?
MS SQL - точно должен решить. Он немного медленнее dbf-ок, но при таком количестве юзеров - будет выигрыш. Также для скорости можешь журналирование у SQL сервака отрубить (правда тогда откатить на какое-то время нельзя будет... но тут уже хозяин-барин)
|
| |
+1 01.11.06 16:05
Автор: DamNet <Denis Amelin> Статус: Elderman
|
> > итак есть терминальный сервер, на нем 1С 7.7.
> одновременно
> > от 50 до 65 подключений. сервер Хеон 3.0 памяти 4Гб.
> Citrix
> > Metaframe 4. база всего одна. средняя сессия юзера
> 65-90Мб
> > памяти и ну и от 5 до 25% загрузки проца. на сервере
> других
> > задач нет
> > тормозит чудовищно.
>
> Если все в dbf-ках, а не на SQL - то это нормальное
> поведение, т.к. в файловой версии больше 25 пользователей
> не рекомендуется, иначе придется часто переиндексировать
> для скорости.
>
> > планирую поднять еще один сервер на нем Citrix , кроме
> того
> > поднять на 3-й машине MS SQL. базы залить на MS SQL,
> > конфигурации положить одинаковые на 2 терминальных
> сервера,
> > пользователей поделить пополам. решит ли это проблему
> > быстродействия или 2-х серверов мало? какие есть еще
> > варианты? у кого как реализованы подобные задачи?
>
> MS SQL - точно должен решить. Он немного медленнее dbf-ок,
> но при таком количестве юзеров - будет выигрыш. Также для
> скорости можешь журналирование у SQL сервака отрубить
> (правда тогда откатить на какое-то время нельзя будет... но
> тут уже хозяин-барин)
По железу добавлю что не скупись на диски и на память (больше дисков в рейде-выше скорость)) Ну и памяти 8 вполне достаточно
|
| | |
Спасибо за ответы!! и еще уточнение! 01.11.06 16:26
Автор: mentat[bugtraq.ru] <Александр> Статус: Elderman
|
насколько я знаю у 1С даже на SQL есть лимит типа то ли 30 то ли 50 конектов, после которого у него наступает колапс, и дикие тормоза... есть точно такая проблема именно поэтому при более 40 юзерах делают терминал на Цитриксе а не просто SQL . Вопрос вот в чем, получится же что 2 терминала будут порождать те же 60-65 конектов к SQL серверу. так? или я не правильно себе это понимаю? не будет ли здесь засады?
и еще вопрос. win2003 Enterprise нормально и спокойно работает с 8Гб и даже с 32 вроде. а вот Citrix и 1С не будут ли какиех засад? по идее не должно это же проблемы ОС как рулить памятью.. но вдруг я чего-то не знаю....
оба терминала с SQL я планирую соединить напрямую по 1000 без свича, воде тут не должно быть засад?
о каких ньансах я могу еще не знать? что может вылезти?
к слову, не порекомендует ли кто поставщиков серверов? я вроде нашел неплохие варианты по supermicro, но может есть варианты лучше?
> > > итак есть терминальный сервер, на нем 1С 7.7.
> > одновременно
> > > от 50 до 65 подключений. сервер Хеон 3.0 памяти
> 4Гб.
> > Citrix
> > > Metaframe 4. база всего одна. средняя сессия
> юзера
> > 65-90Мб
> > > памяти и ну и от 5 до 25% загрузки проца. на
> сервере
> > других
> > > задач нет
> > > тормозит чудовищно.
> >
> > Если все в dbf-ках, а не на SQL - то это нормальное
> > поведение, т.к. в файловой версии больше 25
> пользователей
> > не рекомендуется, иначе придется часто
> переиндексировать
> > для скорости.
> >
> > > планирую поднять еще один сервер на нем Citrix ,
> кроме
> > того
> > > поднять на 3-й машине MS SQL. базы залить на MS
> SQL,
> > > конфигурации положить одинаковые на 2
> терминальных
> > сервера,
> > > пользователей поделить пополам. решит ли это
> проблему
> > > быстродействия или 2-х серверов мало? какие есть
> еще
> > > варианты? у кого как реализованы подобные задачи?
> >
> > MS SQL - точно должен решить. Он немного медленнее
> dbf-ок,
> > но при таком количестве юзеров - будет выигрыш. Также
> для
> > скорости можешь журналирование у SQL сервака отрубить
> > (правда тогда откатить на какое-то время нельзя
> будет... но
> > тут уже хозяин-барин)
> По железу добавлю что не скупись на диски и на память
> (больше дисков в рейде-выше скорость)) Ну и памяти 8 вполне
> достаточно
|
| | | |
Встречал на форумах 1с ников настойчивые рекомендации отделять таки терм от сиквел сервера. Не помню мотивацию. 01.11.06 17:13
Автор: Garick <Yuriy> Статус: Elderman
Отредактировано 01.11.06 17:21 Количество правок: 1
|
В серверном железе как правило есть 2 езернет порта (при желании и больше доустановить можно). Транковать и для усиления надежности и скорости.
На чистом интеле можно собрать или бренд посмотреть НР, например.
|
| | | |
имхо 01.11.06 16:45
Автор: whiletrue <Роман> Статус: Elderman
Отредактировано 01.11.06 16:47 Количество правок: 1
|
> насколько я знаю у 1С даже на SQL есть лимит типа то ли 30
> то ли 50 конектов, после которого у него наступает колапс,
> и дикие тормоза... есть точно такая проблема именно поэтому
> при более 40 юзерах делают терминал на Цитриксе а не просто
> SQL . Вопрос вот в чем, получится же что 2 терминала будут
> порождать те же 60-65 конектов к SQL серверу. так? или я не
> правильно себе это понимаю? не будет ли здесь засады?
> и еще вопрос. win2003 Enterprise нормально и спокойно
> работает с 8Гб и даже с 32 вроде. а вот Citrix и 1С не
> будут ли какиех засад? по идее не должно это же проблемы ОС
> как рулить памятью.. но вдруг я чего-то не знаю....
>
> оба терминала с SQL я планирую соединить напрямую по 1000
> без свича, воде тут не должно быть засад?
>
> о каких ньансах я могу еще не знать? что может вылезти?
я видел такое: 300 юзеров под терминалом и SQL, терминал 1 (win2000 встроенный), SQL-сервак 1... никаких больше излишеств - все классно пахало. Не думаю, что стоит разделять терминал и SQL-сервак. Вот для 8-ки в этом будет выигрыш, а для 7-ки - только зря по сети будут данные гоняться..
Попробуй просто на SQL перевести сначала, а потом думай как еще улучшить, если результат не удовлетворит.
Еще могу несколько экзотический и геморройный в настройке вариант пердложить, однако выигрыш будет просто охренительный: прикрутить веб-компоненту (но на SQL все равно перевести) и через броузер безо всяких терминалов...
|
|
|
подробно о проекте
Анализ криптографических сетевых...
