Ru-Board.club
← Вернуться в раздел «В помощь системному администратору»

» 1с + Win2003s Terminal Services

Автор: softech
Дата сообщения: 09.06.2006 12:33
Daimos
А зачем тебе кэширование?
Автор: Daimos
Дата сообщения: 09.06.2006 14:43
softech
Так говорят - не ставьте на контроллер домена, там будет отключено кэширование и будет тормозить.
То есть надо включать кэширование чтобы не тормозило.
Или я чего-то не догоняю.
Автор: softech
Дата сообщения: 09.06.2006 14:47
Daimos
Если у тебя система не тормозит то и не надо! Обычно кэширование вкл. при удаленном доступе (Terminal Serv).

Добавлено:
Че то я прогнал! У тя и так сервер терминалов так что включай.Включи его только для
терминалов.
Автор: Daimos
Дата сообщения: 09.06.2006 14:59
softech
ЭЭЭ, я не писал, что у меня Terminal Server стоит - хотя так и есть, но клиенты 1С сидят в сетевой версии не под TE.
Автор: softech
Дата сообщения: 09.06.2006 15:05
Daimos
Я что то не понял ты пишешь

Цитата:
сервер, который пока не DC - кэширование там, естественно будет включено и должно быстрее работать - но! Вылез косяк - периодически выскакивает у клиентов Ошибка отложенной записи

Значит кэширование еще не включено.

Цитата:
Это что, надо выключать кэширование на новом сервере чтоли?

А теперь спрашиваешь выкл. его или нет?




Добавлено:
Объясни плиз нормально!!
Автор: help777
Дата сообщения: 09.06.2006 15:07
Daimos
Цитата:
ЭЭЭ, я не писал, что у меня Terminal Server стоит - хотя так и есть, но клиенты 1С сидят в сетевой версии не под TE.

Очень плохо что они не сидят в терминале, а гоняют мегабайты по сети... Даже при маленькой базе в 30 мб при 5 клиентах у сервака и сетевого оборудования должна быть пропускная способность 1,2 гб чтобы не было никаких тормозов, и диски твои должны быть готовы читать по 150 мб/с. Иначе получаются тормоза, которые выражаются в рассинхронизировании и проблемах с кэшированием...

зы. Дешевое железо на серваки не ставьте - ничего хорошего это не принесет...
Автор: softech
Дата сообщения: 09.06.2006 15:12

Цитата:
Очень плохо что они не сидят в терминале, а гоняют мегабайты по сети... Даже при маленькой базе в 30 мб при 5 клиентах у сервака и сетевого оборудования должна быть пропускная способность 1,2 гб чтобы не было никаких тормозов

help777
Я бы так не сказал. У меня базы по 300 метров, терминалки нет, сервант Р-3, 550.
И никаких тормозов.Работает 7 челов с несколькими базами одновременно!
Главное нормально (грамотно) настроить систему!!
Автор: Daimos
Дата сообщения: 09.06.2006 15:32
help777
у меня сервер Fujitsu-Siemens TX200S2 2Xeon 3.0ГГц, 4096МБ ОЗУ, LSI MegaRAID 320-0X 128МБ 4 винта Fujitsu UltraSCSI320 70ГБ в RAID 5 массиве. сетевая Broadcom 1Гбит
Сервер не самосбор - целиком приехал в такой конфигурации с завода.
Коммутаторы в сети 3COM 3C13300 Switch 4200 SuperStack
Так что это не дешевое железо надеюсь.
Автор: help777
Дата сообщения: 10.06.2006 06:40
softech А ты попробуй посмотреть что будут делать твои 5 пользователей когда один из них будет проводить документ? И попробуй на это посмотреть - если у тебя торговая фирма, и клиенты сильно нервничают из-за неудачных транзакция или проблем с переиндексациями
Автор: Daimos
Дата сообщения: 14.06.2006 13:01
softech
у меня есть сервер, который DC - на нем кэширование выключено и проблем с 1С нет.
на втором сервере, он не DC, кэширование в Windows включено по видимому - периодически выскакивает ошибка отложенной записи на клиентах.

В RAID контроллер Write Cahche отключен, Read Control - Read Ahead, I/O control - Direct IO.
И все равно - закрывал 1с на клиенте - в трее выскочил значок - оишбка отложенной записи

Может стоит напрячься и перейти на SQL версию?

Автор: gag
Дата сообщения: 18.06.2006 05:16
to Nick Korkin:
Отключи 16 bit цвет на клиентах в настройках RDP.
При твоей конфигурации это и может быть причиной упомянутых различий в скорости W2k-W2k3.
Автор: Nick_Korkin
Дата сообщения: 25.08.2006 02:05
Мдя.. давно это было, а я такой рассякой не запостил решение проблемы.
В общем люди до сих пор в аську ломятся и спрашивают.
Решилось заменой NIC (сетевой контролер) с насквозь софтового Компекса, на чтото башковитое от 3com или Intel. Но время прошло уже столько что все давно на SQL и отдельном серваке.
Автор: zaharmd
Дата сообщения: 19.10.2006 22:31
Люди добрые! Я в полном ступоре!!!

Есть выделенный терминальный сервак (он является членом домена).

Конфигурация сервака

Windows 2003 R2 Ent.
2 x Intel XEON Dual-Core (система видит их как 8 процессоров)
2 Gb DDR2-5300 ECC
Raid Controller E200i: 128 Mb BBWC
RAID-1 : 2xSAS (System)
RAID-5 : 3xSAS (1C 7.7)
1Gbit NIC

Как работает база - я еще не проверял... только сегодня установил всё...
но для затравки прогнал генерацию какого-то супер-пупер отчета (мне бухгалтера его запустили)...

и тут я увидел как это все тормозит !!!

в Task Manager-e на 100% загружен только один процессор... генерация отчета еле движется... обращения к RAID-5 минимальны, судя по лампочкам на винтах (проверить все детально в PerfMon не было времени)...

Вопрос:

Можно ли заставить 1С использовать хотя бы 4 процессора из 8 видимых ???
И как вообще это можно оптимизировать ???

Автор: Kokos06
Дата сообщения: 20.10.2006 07:55
zaharmd
1С 7.7 однопоточная, её не заставишь работать даже на 2-х процах, не говоря уже о 4-х.
Единственный совет в твоём случае отключить HT в биосе, что-бы в системе было 4 проца видимых.
Автор: zaharmd
Дата сообщения: 20.10.2006 08:31
Kokos06

а переход на 1С v8 что-то даст?
Автор: noblekey
Дата сообщения: 20.10.2006 09:09
zaharmd
больное место у твоего сервака это между процесорами и северным мостом через который идет общение с памятью. Производительность процессоров больше чем пропускная способность этого "бутылочного горлышка" у тебя не будет что и подтверждается

Цитата:
в Task Manager-e на 100% загружен только один процессор



Цитата:
Можно ли заставить 1С использовать хотя бы 4 процессора из 8 видимых ???

к сожелению этого на твоем железе не выйдет.
Автор: zaharmd
Дата сообщения: 20.10.2006 09:32
noblekey

какое железо нужно?

у меня - 2 x Dual-Core Intel Xeon Processor 5150 (2.66 GHz, 65 Watts, 1333 FSB) / 1333MHz front side bus (FSB)
Автор: noblekey
Дата сообщения: 20.10.2006 09:42
я поставил себе сервак на процессорах opteron от AMD у них контроллер памяти интегрирован в сам проц и нету северного моста. производительность реально выше в несколько раз.
Автор: zaharmd
Дата сообщения: 20.10.2006 10:00
noblekey

Цитата:
и нету северного моста


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

Serverworks HT-2100 Northbridge and HT1000 Southbridge Chipset

Автор: noblekey
Дата сообщения: 20.10.2006 10:15
zaharmd
я имел ввиду что общение с памятью происходит не через северный мост а напрямую эти самым уменьшается латентность памяти
и чем больше процессоров у тебя будет в системе тем больше будет производительность
Автор: zaharmd
Дата сообщения: 20.10.2006 10:25
noblekey

ты говоришь:
Цитата:
чем больше процессоров у тебя будет в системе тем больше будет производительность


выше писали:
Цитата:
1С 7.7 однопоточная, её не заставишь работать даже на 2-х процах, не говоря уже о 4-х.


я в замешательстве...
или твой ответ не относится к 1С ?

Автор: noblekey
Дата сообщения: 20.10.2006 10:29
zaharmd
Что значит отнопоточная?
у меня 20 пользователей сидят в терминале юзают 1с и нагрузка между процами распределяется равномерно
нагрузка будет распределятся равномерно и на 8 процах так как каждый проц имеет встроенный контроллер памяти
Автор: Kokos06
Дата сообщения: 21.10.2006 04:48
zaharmd
1С 8 уже умеет работать в многопроцессорных средах.
В твоем случае переживать по этому поводу не стоит, т. к. у тебя на серваке не один пользователь будет работать, каждый процесс 1С будет грузить отдельный проц.
Кстате, а сколько пользователей будет на серваке и каков тип БД (dbf/sql) и объём?
noblekey
Однопоточная - это значит один поток исполняемых команд для процессора.

Цитата:
у меня 20 пользователей сидят в терминале юзают 1с и нагрузка между процами распределяется равномерно
А ты попробуй выкинуть всех пользователей, запустить 1С 7.7, нагрузить её.

Цитата:
нагрузка будет распределятся равномерно и на 8 процах
Верно для одновременной работы большого количества пользователей.

Цитата:
так как каждый проц имеет встроенный контроллер памяти
Это здесь не причём. Планирование процессов в ОС происходит на более высоком уровне.


Автор: zaharmd
Дата сообщения: 21.10.2006 11:01
Kokos06

пока что установлена 1С 7.7 на файлах... компания для которой я устанавливал сервак говорит, что sql версия менее безопасная и не очень желает переходить на нее...

я в 1С не очень рабираюсь... вот и не стал спорить...

еще вопрос: можно ли работать в 1С 8 на файлах на не на БД ?
Автор: Kokos06
Дата сообщения: 21.10.2006 12:02
zaharmd
Что-то эта компания не то говорит

Цитата:
еще вопрос: можно ли работать в 1С 8 на файлах на не на БД ?

Да, можно. Только там вся БД хранится в одном файле вместе с метаданными и данными о пользователях. И расчитан такой вариант на однопользовательскую работу, либо работу не большого количества пользователей. А вообще SQL всё-таки надёжнее.
Автор: zaharmd
Дата сообщения: 21.10.2006 12:14
Kokos06

Только, что узнал что там две базы по 300 Мб.
Сейчас работает 8 человек. Скоро будет около 15 человек.

еще вопрос насчет скорости SQL - она быстрее файлов ?
Автор: Kokos06
Дата сообщения: 21.10.2006 12:43
zaharmd
Быстрее в многопользовательской работе. В однопользовательской почти тоже самое.
Это что касается 7.7. И быстрее работает с регистрами. А вообще 1С 7.7 не умеет пользоваться всеми благами SQL-сервера.
А для таких баз и такого количества пользователей этого железа хватит с полна. Хотя 1С рекомендует при таком объёме БД уже переходить на SQL, но на практике объём БД может доходить до нескольких Гб. Правда есть свои нюансы - объём отдельного dbf файла не должен привышать 2Гб - ограничение формата, а всей базы, насколько я помню, 10Гб. Я сам сталкивался с ситуацией, когда при пересчёте регистров (тестирование и исправление БД) индексный файл одного из dbf файла после многих часов работы доходил до 2-х ГБ и всё ломалось, а после перевода в sql та-же процедура выполнялась без проблем и гораздо быстрее.
Автор: PogorYur
Дата сообщения: 21.10.2006 19:53
По поводу скорости работы 1С 7.7 в dbf и SQL варианте - однозначно DBF быстее. Только при увеличении объема базы (более 2 Гб) и достаточной нагрузке (3-5 РАБОТАЮЩИХ пользователя) индексы летят настолько часто, что еженочная переиндексация не помогает. Типовые конфигурации изначально не оптимизированы под SQL - в Profiler'е сплошные курсоры и временные таблицы - нормальных запросов практически нет ( На одинаковом оборудовании после перехода на SQL замедление базы особенно при групповом перепроведении - до 5-7 раз по сравнению с DBF. А отчеты работают действительно быстрее - там 1С генерит человеческие SQL-запросы. Оптимизация конфигурации 1С - переход от фильтрации к запросам спасает - замедление не настолько велико - оптимизорованная под SQL конфигурация чуть медленне (проц.на 20), чем dbf.
Все сказанное отностится к достаточно большой базе 1С (4Гб за 5 месяцев работы), в которой интенсивно работают 5 операторов (всего 20 пользователей), вводящих до 1000 документов в день.
Кстате - все вышесказанное про полезность дефрагментации DBF правда - проверьте не пожалеете.
По поводу "многопоточности" работы 1С: при проведении документов 1С блокирует таблицу 1sjurnal. Поэтому при любом количестве процессоров, проведение документов (основная задача 1С) является однопользовательским. Т.е. пока один чел проводит документ все остальные ловят ошибку блокировки (( Следовательно 1С нужен 1 очень-очень быстрый процессор (или 2 - второй для SQL), а не 4 помедленнее.
Насчет 1С 8.0. По поводу запросов, которые генерит система в стандартной конфигурации - они совсем не так хороши как поет разработчик - проверьте сами - поглядите в mssql profiler. Правильных SQL запросов стало больше, но все равно 90% курсоры и пр. Проблему блокировки таблиц целиком, как анонсирует 1С, решили - теперь блокировка на уровне записи. Но я этого лично не проверял, поэтому НЕ ВЕРЮ
Автор: Kokos06
Дата сообщения: 22.10.2006 11:49
PogorYur

Цитата:
На одинаковом оборудовании после перехода на SQL замедление базы особенно при групповом перепроведении - до 5-7 раз по сравнению с DBF

Вопрос: а на каком железе всё это делалось, я имею ввиду переход на SQL? SQL сама ресурсов жрёт много, и без рэйда на SCSI дисках и RAM желательно размером с объём БД на SQL переходить не стоит. Иначе как раз тупняк поймаешь "до 5-7 раз по сравнению с DBF". Задачи-то разные или дисковые операции на файл сервере, или сервер БД, который жрёт не только дисковые операции, но и проц, и оперативку.

Цитата:
По поводу "многопоточности" работы 1С: при проведении документов 1С блокирует таблицу 1sjurnal. Поэтому при любом количестве процессоров, проведение документов (основная задача 1С) является однопользовательским.

А у тебя что, на сервере терминалов все 100% пользователей одновременно проводят документы?! Процессорное время в системе тратится не только на 1С и даже работая в 1С, при проведении документа, другие пользователи, к примеру, могут формировать отчёт или вводить новый документ, просматривать документ, подбор номенклатуры в справочнике и пр. В TS, однозначно, чем больше процессоров тем лучше.
Кстате в SQL тоже полезно индексы дефрагментировать.
А по поводу нормальных запросов в 7.7 их там действительно нет .
Автор: zaharmd
Дата сообщения: 22.10.2006 12:37
Мда... ситуация беспонтовая... завтра попробую отрубить HT на процах... по-идее это должно ускорить процесс формирования месячных/годовых отчетов (когдаиспользуется только один логический процессор).

Страницы: 123456

Предыдущая тема: Флейм для сисадминов.


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.