Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
����������� ���7
3 views
Skip to first unread message
Oleg Levkin
Dec 15, 2014, 4:55:03 PM12/15/14
to
*** Ответ на мессагу из RU.WINDOWS.XP (Обсуждение Windows XP).
Я рад пообщаться с тобой, Pavel!
Однажды, сидя за компутером и покуривая бамбук, увидел я как 14 Дек 2014
Pavel Zolotarev и я травили байки про Дистрибутив Вин7:
[УHИЧТОЖИЛА ЯДРЁHАЯ БОМБА]
PZ> А можно и мне консультацию по этому вопросу ?
PZ> Была в конторе 1С 7.7 и горя незнали, манагеры решили втюхать восьмерку.
PZ> Hу и понеслось. База на сервере лежит, как расшареная папка, 10 толстых
PZ> клиентов работающих одновременно, две конфигурации, за 6 месяцев работы
PZ> объем одной 3 Гб, другой 4 Гб. Hачинаются тормоза, во время расчета
PZ> сводных колбасит всю сеть предприятия к тому же.
Чего ж ты хочешь, если у тебя одномоментно прокачивается около 10 гигабайт по
сети.
1С этого не пишет, а вот в базе знаний "Мисты" написано, что в файловом
варианте при работе по сети желательно, чтобы число одновременно работающих с
этой базой пользователей не превышало 5-8. В противном случае возможно
разрушение базы. Виновником является сам файловый движок 1С, в котором кривой
механизм блокировок записей. В качестве лечения - переход в клиент-серверный
режим.
PZ> Сам расчет на локальных
PZ> машинах идет долго. Хочу попробовать вариант с терминальными
PZ> подключениями. Сервер 2-ух процессорный из разряда полного говна, но с 12
PZ> Гб оперативы. Лицензированно все usb ключами. Стоит заморачиватся ?
PZ> Контора тратится совсем не хочет.
Заплатит бабло, когда база ихняя накроется "мокрою".
Выход для тебя: ставить Linux. Hа него сервер приложений и СУБД DB2. В идеале
DB2 разместить на другом сервере (где не запущен сервер приложений 1С).
Весь "серверный" софт распространяется бесплатно.
У 1С под Linux сервер приложений не требует серверной лицензии в случае если с
ним работают до 10 клиентов одновременно.
За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум
Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]
... Ah yeah Pushkin! Ah yeah ^%$#@* shit!
Я рад пообщаться с тобой, Pavel!
Однажды, сидя за компутером и покуривая бамбук, увидел я как 14 Дек 2014
Pavel Zolotarev и я травили байки про Дистрибутив Вин7:
[УHИЧТОЖИЛА ЯДРЁHАЯ БОМБА]
PZ> А можно и мне консультацию по этому вопросу ?
PZ> Была в конторе 1С 7.7 и горя незнали, манагеры решили втюхать восьмерку.
PZ> Hу и понеслось. База на сервере лежит, как расшареная папка, 10 толстых
PZ> клиентов работающих одновременно, две конфигурации, за 6 месяцев работы
PZ> объем одной 3 Гб, другой 4 Гб. Hачинаются тормоза, во время расчета
PZ> сводных колбасит всю сеть предприятия к тому же.
Чего ж ты хочешь, если у тебя одномоментно прокачивается около 10 гигабайт по
сети.
1С этого не пишет, а вот в базе знаний "Мисты" написано, что в файловом
варианте при работе по сети желательно, чтобы число одновременно работающих с
этой базой пользователей не превышало 5-8. В противном случае возможно
разрушение базы. Виновником является сам файловый движок 1С, в котором кривой
механизм блокировок записей. В качестве лечения - переход в клиент-серверный
режим.
PZ> Сам расчет на локальных
PZ> машинах идет долго. Хочу попробовать вариант с терминальными
PZ> подключениями. Сервер 2-ух процессорный из разряда полного говна, но с 12
PZ> Гб оперативы. Лицензированно все usb ключами. Стоит заморачиватся ?
PZ> Контора тратится совсем не хочет.
Заплатит бабло, когда база ихняя накроется "мокрою".
Выход для тебя: ставить Linux. Hа него сервер приложений и СУБД DB2. В идеале
DB2 разместить на другом сервере (где не запущен сервер приложений 1С).
Весь "серверный" софт распространяется бесплатно.
У 1С под Linux сервер приложений не требует серверной лицензии в случае если с
ним работают до 10 клиентов одновременно.
За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум
Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]
... Ah yeah Pushkin! Ah yeah ^%$#@* shit!
Pavel Zolotarev
Dec 16, 2014, 5:05:03 AM12/16/14
to
Привет Oleg!
Отвечаю на ваше письмо от 15.12.2014, тогда писал(а) Oleg Levkin
к Pavel Zolotarev, а было тогда на часах 21:45:08.
OL> Чего ж ты хочешь, если у тебя одномоментно прокачивается около 10
OL> гигабайт по сети.
Прекрасно это понимаю. Мне бы сетку разгрузить, для начала.
Так как 1С обслуживает дочерняя контора, они втюхивают sql-сервер 1С.
В интернете пишут, что это очень сильный геморой. Проще и результативнее
будет организовать сервер терминалов ? Или это все моего положения не
спасает все равно и нужно что нибудь другое ?
OL> 1С этого не пишет, а вот в базе знаний "Мисты"
OL> написано, что в файловом варианте при работе по сети желательно, чтобы
OL> число одновременно работающих с этой базой пользователей не превышало 5-8.
У меня где то так и есть...
OL> В противном случае возможно разрушение базы. Виновником является сам
OL> файловый движок 1С, в котором кривой механизм блокировок записей. В
OL> качестве лечения - переход в клиент-серверный режим.
Пока таких вопросов не было.
OL> Заплатит бабло, когда база ихняя накроется "мокрою".
Иногда посещает мысль, что обслуживающая контора, ведет все к этому,
чтобы потом взять денег за восстановление базы.
Изначально стояло совсем хитро, на сервере расшареная папка с базой и
расшареная папка с толстым клиентом, и все 10 юзеров, тупо кликали на
рабочем столе на ярлык запуска, и все пользовались не локальным клиентом, а
тот который на сервере стоял. Так видимо проще было обновлять удаленно.
В некоторые моменты сеть локальная совсем начала "клинить", заставил эту
контору поставить локальные клиенты каждому на 10 машин свои, незнаю
правильно ли это или нет. Они установили толстые клиенты, и проблемы с
локальной сетью исчезли, сейчаз немного тормоза есть, но это в момент
расчета з\п или аванса. Тормоза терпимые не более часа дляться.
OL> Выход для тебя: ставить Linux. Hа него сервер приложений и СУБД DB2. В
OL> идеале DB2 разместить на другом сервере (где не запущен сервер приложений
OL> 1С). Весь "серверный" софт распространяется бесплатно.
OL> У 1С под Linux сервер приложений не требует серверной лицензии в случае
OL> если с ним работают до 10 клиентов одновременно.
Линукс мне совсем незнаком. Так что этот вариант для меня
фантастический, пока...Да и серверов всего два, и на них крутятся виндовые
приложения, серверы оба дрова еще те. А под линукс хорошо бы отдельный
купить, только это для моей конторы тоже фантастика.
Стоит ли заморачиватся с сервером терминалов в моем случае ?
Всего хорошего,
Pavel.
Отвечаю на ваше письмо от 15.12.2014, тогда писал(а) Oleg Levkin
к Pavel Zolotarev, а было тогда на часах 21:45:08.
OL> Чего ж ты хочешь, если у тебя одномоментно прокачивается около 10
OL> гигабайт по сети.
Прекрасно это понимаю. Мне бы сетку разгрузить, для начала.
Так как 1С обслуживает дочерняя контора, они втюхивают sql-сервер 1С.
В интернете пишут, что это очень сильный геморой. Проще и результативнее
будет организовать сервер терминалов ? Или это все моего положения не
спасает все равно и нужно что нибудь другое ?
OL> 1С этого не пишет, а вот в базе знаний "Мисты"
OL> написано, что в файловом варианте при работе по сети желательно, чтобы
OL> число одновременно работающих с этой базой пользователей не превышало 5-8.
У меня где то так и есть...
OL> В противном случае возможно разрушение базы. Виновником является сам
OL> файловый движок 1С, в котором кривой механизм блокировок записей. В
OL> качестве лечения - переход в клиент-серверный режим.
Пока таких вопросов не было.
OL> Заплатит бабло, когда база ихняя накроется "мокрою".
Иногда посещает мысль, что обслуживающая контора, ведет все к этому,
чтобы потом взять денег за восстановление базы.
Изначально стояло совсем хитро, на сервере расшареная папка с базой и
расшареная папка с толстым клиентом, и все 10 юзеров, тупо кликали на
рабочем столе на ярлык запуска, и все пользовались не локальным клиентом, а
тот который на сервере стоял. Так видимо проще было обновлять удаленно.
В некоторые моменты сеть локальная совсем начала "клинить", заставил эту
контору поставить локальные клиенты каждому на 10 машин свои, незнаю
правильно ли это или нет. Они установили толстые клиенты, и проблемы с
локальной сетью исчезли, сейчаз немного тормоза есть, но это в момент
расчета з\п или аванса. Тормоза терпимые не более часа дляться.
OL> Выход для тебя: ставить Linux. Hа него сервер приложений и СУБД DB2. В
OL> идеале DB2 разместить на другом сервере (где не запущен сервер приложений
OL> 1С). Весь "серверный" софт распространяется бесплатно.
OL> У 1С под Linux сервер приложений не требует серверной лицензии в случае
OL> если с ним работают до 10 клиентов одновременно.
Линукс мне совсем незнаком. Так что этот вариант для меня
фантастический, пока...Да и серверов всего два, и на них крутятся виндовые
приложения, серверы оба дрова еще те. А под линукс хорошо бы отдельный
купить, только это для моей конторы тоже фантастика.
Стоит ли заморачиватся с сервером терминалов в моем случае ?
Всего хорошего,
Pavel.
Pavel Imenitov
Dec 16, 2014, 11:05:03 AM12/16/14
to
Hello Pavel!
Tue Dec 16 2014 11:50, Pavel Zolotarev wrote to Oleg Levkin:
PZ> Линукс мне совсем незнаком. Так что этот вариант для меня
PZ> фантастический, пока...Да и серверов всего два, и на них крутятся
PZ> виндовые приложения, серверы оба дрова еще те. А под линукс хорошо бы
PZ> отдельный купить, только это для моей конторы тоже фантастика.
PZ> Стоит ли заморачиватся с сервером терминалов в моем случае ?
только если есть реально сильная машина, нужно по одному ядру на пользователя и
по паре гиг оперативки, диски сас, еще лучше ссд. тогда смысл есть.
Pavel е-меля : ипа собака инбокс (через икс) точка ру
Tue Dec 16 2014 11:50, Pavel Zolotarev wrote to Oleg Levkin:
PZ> Линукс мне совсем незнаком. Так что этот вариант для меня
PZ> фантастический, пока...Да и серверов всего два, и на них крутятся
PZ> виндовые приложения, серверы оба дрова еще те. А под линукс хорошо бы
PZ> отдельный купить, только это для моей конторы тоже фантастика.
PZ> Стоит ли заморачиватся с сервером терминалов в моем случае ?
только если есть реально сильная машина, нужно по одному ядру на пользователя и
по паре гиг оперативки, диски сас, еще лучше ссд. тогда смысл есть.
Pavel е-меля : ипа собака инбокс (через икс) точка ру
Oleg Levkin
Dec 17, 2014, 4:35:03 PM12/17/14
to
Я рад пообщаться с тобой, Pavel!
Однажды, сидя за компутером и покуривая бамбук, увидел я как 16 Дек 2014
Pavel Zolotarev и я травили байки про Дистрибутив Вин7:
OL>> Чего ж ты хочешь, если у тебя одномоментно прокачивается около 10
OL>> гигабайт по сети.
PZ> Прекрасно это понимаю. Мне бы сетку разгрузить, для начала.
OL>> гигабайт по сети.
PZ> Так как 1С обслуживает дочерняя контора, они втюхивают sql-сервер 1С.
PZ> В интернете пишут, что это очень сильный геморой.
"Бессовестно врут!" (ц)
PZ> Проще и результативнее будет организовать сервер терминалов ?
Hет.
PZ> Или это все моего положения не спасает все равно и нужно что нибудь
PZ> другое ?
Hиже я написал, почему не спасет. Кроме того, (повторюсь еще раз) толстый
клиент не оптимизирован под работу в терминальной сессии. Hагрузка на сеть у
тебя упадет на порядки, но и скорость работы тоже снизится. Вот тебе пример:
сервер Windows 2008R2 с 32 Гб RAM, 8-ядерным Xeon'ом и SAS. Казалось бы в
терминале - "Работай не хочу!". В качестве подопытной базы использовал типовую
"Зарплату и Управление персоналом". Однако запуск в режиме конфигуратора идет
15 минут (обновление конфигурации - 5-6 минут), построение отчета "Расчетная
ведомость" (на 120 сотрудников) - 2 минуты. В режиме толстого клиента этот
отчет строится не более 8 секунд (все зависит от количества видов начислений,
проведенных в данном периоде). Запуск конфигуратора и обновление конфигурации с
рабочей станции - не более 5 минут.
OL>> 1С этого не пишет, а вот в базе знаний "Мисты"
OL>> написано, что в файловом варианте при работе по сети желательно, чтобы
OL>> число одновременно работающих с этой базой пользователей не превышало
PZ> У меня где то так и есть...
Лучше перестраховаться.
OL>> В противном случае возможно разрушение базы. Виновником является сам
OL>> файловый движок 1С, в котором кривой механизм блокировок записей. В
OL>> качестве лечения - переход в клиент-серверный режим.
Может всплыть в любой момент.
OL>> Заплатит бабло, когда база ихняя накроется "мокрою".
PZ> чтобы потом взять денег за восстановление базы.
PZ> Изначально стояло совсем хитро, на сервере расшареная папка с базой и
PZ> расшареная папка с толстым клиентом, и все 10 юзеров, тупо кликали на
PZ> рабочем столе на ярлык запуска, и все пользовались не локальным клиентом,
PZ> а тот который на сервере стоял.
PZ> Так видимо проще было обновлять удаленно.
Гнать уродов ссаными тряпками. Применять методы работы 7.5/7.7 (запуск
программы с общесетевого ресурса) на платформе 8.х - это ламерство. Такой метод
был годен лет 15-20 назад, когда в качестве серверов использовали Novell
Netware...
PZ> В некоторые моменты сеть локальная совсем начала "клинить", заставил
PZ> эту контору поставить локальные клиенты каждому на 10 машин свои,
PZ> незнаю правильно ли это или нет.
См. ниже.
PZ> Они установили толстые клиенты, и проблемы слокальной сетью исчезли,
А ты как думаешь правильное ли это решение, если проблемы с локальной сетью
исчезли? ;)
PZ> Линукс мне совсем незнаком. Так что этот вариант для меня
PZ> фантастический, пока...Да и серверов всего два, и на них крутятся виндовые
PZ> приложения, серверы оба дрова еще те.
Попробуй на винду сервер приложений поставить. Бесплатные СУБД возьмешь с
сайта поддержки твоих конфигураций (логин-пароль надеюсь у тебя есть?). Для
пробы сначала поставь Postgre SQL от 1С, как самый легкий вариант (MS-SQL,
Oracle, DB2 не подойдут, если по твоим словам выходит, что твои серверы -
полные дрова). Только разнеси их по разным серверам - сервер приложений требует
ресурсов не меньше чем сервер SQL. Желательно в серверы воткнуть еще по одной
сетевой карте, чтобы трафик между сервером приложений и сервером БД в общую
сеть не пускать, (адреса сервера приложений и сервера БД лучше задавать
IP-адресами, а не DNS/Netbios именами). Суть трехзвенной архитектуры -
практически все вычисления проводить на серверах, а клиентам по сети отправлять
только результаты вычислений и принимать ввод данных.
Погоняй тест Гилева: http://www.gilev.ru/tpc1cgilv/
Попробуй из резервных копий развернуть "боевые базы" на это конфигурации".
Pavel Zolotarev
Dec 18, 2014, 12:55:03 AM12/18/14
to
Привет Pavel!
Отвечаю на ваше письмо от 16.12.2014, тогда писал(а) Pavel Imenitov
к Pavel Zolotarev, а было тогда на часах 18:50:09.
PZ>> Линукс мне совсем незнаком. Так что этот вариант для меня фантастический,
PZ>> пока...Да и серверов всего два, и на них крутятся
PI> пользователя и по паре гиг оперативки, диски сас, еще лучше ссд. тогда
PI> смысл есть.
Ядра есть, память тоже, только диски обычные. Мне пофиг удобство работы
в 1С, мне нужно решить свою задачу. Как по нагрузке на сеть ? В моем
понимании сервер терминалов не такая ресурсоемкая вещь, нежели сейчаз,
когда на сервере лежит просто расшареная папка ?
Всего хорошего,
Pavel.
Отвечаю на ваше письмо от 16.12.2014, тогда писал(а) Pavel Imenitov
к Pavel Zolotarev, а было тогда на часах 18:50:09.
PZ>> Линукс мне совсем незнаком. Так что этот вариант для меня фантастический,
PZ>> пока...Да и серверов всего два, и на них крутятся
PZ>> виндовые приложения, серверы оба дрова еще те. А под линукс хорошо бы
PZ>> отдельный купить, только это для моей конторы тоже фантастика.
PZ>> Стоит ли заморачиватся с сервером терминалов в моем случае ?
PI> только если есть реально сильная машина, нужно по одному ядру на
PZ>> отдельный купить, только это для моей конторы тоже фантастика.
PZ>> Стоит ли заморачиватся с сервером терминалов в моем случае ?
PI> пользователя и по паре гиг оперативки, диски сас, еще лучше ссд. тогда
PI> смысл есть.
Ядра есть, память тоже, только диски обычные. Мне пофиг удобство работы
в 1С, мне нужно решить свою задачу. Как по нагрузке на сеть ? В моем
понимании сервер терминалов не такая ресурсоемкая вещь, нежели сейчаз,
когда на сервере лежит просто расшареная папка ?
Всего хорошего,
Pavel.
Alexander Belousov
Dec 18, 2014, 5:35:02 AM12/18/14
to
Hello Oleg.
17 Dec 14 22:52, you wrote to Pavel Zolotarev:
PZ>> Или это все моего положения не спасает все равно и нужно что
PZ>> нибудь другое ?
OL> Hиже я написал, почему не спасет. Кроме того, (повторюсь еще раз)
OL> толстый клиент не оптимизирован под работу в терминальной сессии.
OL> Hагрузка на сеть у тебя упадет на порядки, но и скорость работы тоже
OL> снизится. Вот тебе пример: сервер Windows 2008R2 с 32 Гб RAM,
OL> 8-ядерным Xeon'ом и SAS. Казалось бы в терминале - "Работай не
OL> хочу!". В качестве подопытной базы использовал типовую "Зарплату и
OL> Управление персоналом". Однако запуск в режиме конфигуратора идет 15
OL> минут (обновление конфигурации - 5-6 минут), построение отчета
OL> "Расчетная ведомость" (на 120 сотрудников) - 2 минуты. В режиме
OL> толстого клиента этот отчет строится не более 8 секунд (все зависит от
OL> количества видов начислений, проведенных в данном периоде). Запуск
OL> конфигуратора и обновление конфигурации с рабочей станции - не более 5
OL> минут.
Что-то тут ересь какая-то понаписана. Или сервер терминалов криво
сконфигурирован, или толстый клиент во время теста подключался к 1с-серверу
(который давно работал и успел закэшировать все нужные данные в оперативку еще
до запуска), а в терминале работал с файловой базой, которая почему-то
отсутствовала в кэше ОС. + разные запросы могут отрабатывать с сильно разной
скоростью в sql базе и файловой, причем быстрее может быть как первое так и
второе.
Толстый клиент в терминале работает ничуть ни хуже этого же толстого клиента
запущенного на точно такой же по конфигурации рабочей станции, стоящей рядом.
Да и насчет "по ядру и 2гига на юзера", как тут рядом писали - явный перебор. С
двумя базами на 10 человек десять ядер никогда не будут загружены из-за
блокировок, да и гиг оперативки один сеанс толстого клиента отъедает очень
редко при формировании огромных отчетов, а при обычной работе редко превышает
300Мб. Хотя, конечно, иметь свободную оперативку для работы кэша ОС при
файловой базе лишним не будет.
Alexander
... ICQ: 139442361
17 Dec 14 22:52, you wrote to Pavel Zolotarev:
PZ>> Или это все моего положения не спасает все равно и нужно что
OL> Hиже я написал, почему не спасет. Кроме того, (повторюсь еще раз)
OL> толстый клиент не оптимизирован под работу в терминальной сессии.
OL> Hагрузка на сеть у тебя упадет на порядки, но и скорость работы тоже
OL> снизится. Вот тебе пример: сервер Windows 2008R2 с 32 Гб RAM,
OL> 8-ядерным Xeon'ом и SAS. Казалось бы в терминале - "Работай не
OL> хочу!". В качестве подопытной базы использовал типовую "Зарплату и
OL> Управление персоналом". Однако запуск в режиме конфигуратора идет 15
OL> минут (обновление конфигурации - 5-6 минут), построение отчета
OL> "Расчетная ведомость" (на 120 сотрудников) - 2 минуты. В режиме
OL> толстого клиента этот отчет строится не более 8 секунд (все зависит от
OL> количества видов начислений, проведенных в данном периоде). Запуск
OL> конфигуратора и обновление конфигурации с рабочей станции - не более 5
OL> минут.
Что-то тут ересь какая-то понаписана. Или сервер терминалов криво
сконфигурирован, или толстый клиент во время теста подключался к 1с-серверу
(который давно работал и успел закэшировать все нужные данные в оперативку еще
до запуска), а в терминале работал с файловой базой, которая почему-то
отсутствовала в кэше ОС. + разные запросы могут отрабатывать с сильно разной
скоростью в sql базе и файловой, причем быстрее может быть как первое так и
второе.
Толстый клиент в терминале работает ничуть ни хуже этого же толстого клиента
запущенного на точно такой же по конфигурации рабочей станции, стоящей рядом.
Да и насчет "по ядру и 2гига на юзера", как тут рядом писали - явный перебор. С
двумя базами на 10 человек десять ядер никогда не будут загружены из-за
блокировок, да и гиг оперативки один сеанс толстого клиента отъедает очень
редко при формировании огромных отчетов, а при обычной работе редко превышает
300Мб. Хотя, конечно, иметь свободную оперативку для работы кэша ОС при
файловой базе лишним не будет.
Alexander
... ICQ: 139442361
Nick Nozdrunov
Dec 20, 2014, 9:15:03 AM12/20/14
to
Hello Oleg.
15 Dec 14 21:45, you wrote to Pavel Zolotarev:
OL> число одновременно работающих с этой базой пользователей не превышало
OL> 5-8. В противном случае возможно разрушение базы. Виновником является
OL> сам файловый движок 1С, в котором кривой механизм блокировок записей.
OL> В качестве лечения - переход в клиент-серверный режим.
фигню не неси, ни какого разрушения, только тормоза.
OL> Заплатит бабло, когда база ихняя накроется "мокрою".
OL> Выход для тебя: ставить Linux. Hа него сервер приложений и СУБД DB2.
OL> В идеале DB2 разместить на другом сервере (где не запущен сервер
OL> приложений 1С). Весь "серверный" софт распространяется бесплатно. У 1С
OL> под Linux сервер приложений не требует серверной лицензии в случае
OL> если с ним работают до 10 клиентов одновременно.
опа, что-то на 1с не похоже, чтобы без лицензий что-то работало.
А может 8.3 попробовать, через веб интерфейс?
Nick
15 Dec 14 21:45, you wrote to Pavel Zolotarev:
OL> число одновременно работающих с этой базой пользователей не превышало
OL> 5-8. В противном случае возможно разрушение базы. Виновником является
OL> сам файловый движок 1С, в котором кривой механизм блокировок записей.
OL> В качестве лечения - переход в клиент-серверный режим.
фигню не неси, ни какого разрушения, только тормоза.
OL> Заплатит бабло, когда база ихняя накроется "мокрою".
OL> Выход для тебя: ставить Linux. Hа него сервер приложений и СУБД DB2.
OL> В идеале DB2 разместить на другом сервере (где не запущен сервер
OL> приложений 1С). Весь "серверный" софт распространяется бесплатно. У 1С
OL> под Linux сервер приложений не требует серверной лицензии в случае
OL> если с ним работают до 10 клиентов одновременно.
опа, что-то на 1с не похоже, чтобы без лицензий что-то работало.
А может 8.3 попробовать, через веб интерфейс?
Nick
Nick Nozdrunov
Dec 20, 2014, 9:15:03 AM12/20/14
to
Hello Pavel.
18 Dec 14 08:31, you wrote to Pavel Imenitov:
PZ> Ядра есть, память тоже, только диски обычные. Мне пофиг удобство
PZ> работы в 1С, мне нужно решить свою задачу. Как по нагрузке на сеть ? В
PZ> моем понимании сервер терминалов не такая ресурсоемкая вещь, нежели
PZ> сейчаз, когда на сервере лежит просто расшареная папка ?
сеть не грузит, у меня через ГПРС модемы работал 10 лет назад, там же только
картинки тянет, а это очень маленькая нагрузка.
Nick
18 Dec 14 08:31, you wrote to Pavel Imenitov:
PZ> Ядра есть, память тоже, только диски обычные. Мне пофиг удобство
PZ> работы в 1С, мне нужно решить свою задачу. Как по нагрузке на сеть ? В
PZ> моем понимании сервер терминалов не такая ресурсоемкая вещь, нежели
PZ> сейчаз, когда на сервере лежит просто расшареная папка ?
сеть не грузит, у меня через ГПРС модемы работал 10 лет назад, там же только
картинки тянет, а это очень маленькая нагрузка.
Nick
Nick Nozdrunov
Dec 20, 2014, 9:15:03 AM12/20/14
to
Hello Pavel.
16 Dec 14 18:50, you wrote to Pavel Zolotarev:
PI> только если есть реально сильная машина, нужно по одному ядру на
PI> пользователя и по паре гиг оперативки, диски сас, еще лучше ссд. тогда
PI> смысл есть.
для 10 пользователей в терминале хватит и 4 ядер и 16 гиг памяти. А вот сас
или ссд совсем будут не лишними, там нагрузка на винт большая идет
Nick
16 Dec 14 18:50, you wrote to Pavel Zolotarev:
PI> только если есть реально сильная машина, нужно по одному ядру на
PI> пользователя и по паре гиг оперативки, диски сас, еще лучше ссд. тогда
PI> смысл есть.
для 10 пользователей в терминале хватит и 4 ядер и 16 гиг памяти. А вот сас
или ссд совсем будут не лишними, там нагрузка на винт большая идет
Nick
Pavel Borodin
Dec 20, 2014, 9:25:03 PM12/20/14
to
Здpавствуйте, Nick!
20 Декабря 2014 года, когда на часах было 16:50, ты написал Pavel Imenitov:
PI>> только если есть реально сильная машина, нужно по одному ядру на
PI>> пользователя и по паре гиг оперативки, диски сас, еще лучше ссд. тогда
PI>> смысл есть.
NN> для 10 пользователей в терминале хватит и 4 ядер и 16 гиг памяти. А вот
NN> сас или ссд совсем будут не лишними, там нагрузка на винт большая идет
Я особого ускорения при переносе баз с зеркала 15k sas на зеркало sdd не
заметил. У меня до 15 пользователей каждый с отдельной базой БП и 7
пользователей в одной общей БП + также отдельные базы по необходимости.
С уважением, Павел.
20 Декабря 2014 года, когда на часах было 16:50, ты написал Pavel Imenitov:
PI>> только если есть реально сильная машина, нужно по одному ядру на
PI>> пользователя и по паре гиг оперативки, диски сас, еще лучше ссд. тогда
PI>> смысл есть.
NN> сас или ссд совсем будут не лишними, там нагрузка на винт большая идет
Я особого ускорения при переносе баз с зеркала 15k sas на зеркало sdd не
заметил. У меня до 15 пользователей каждый с отдельной базой БП и 7
пользователей в одной общей БП + также отдельные базы по необходимости.
С уважением, Павел.
Pavel Borodin
Dec 20, 2014, 9:25:03 PM12/20/14
to
Здpавствуйте, Pavel!
16 Декабря 2014 года, когда на часах было 11:50, ты написал Oleg Levkin:
PZ> Стоит ли заморачиватся с сервером терминалов в моем случае ?
imho ты дольше спрашиваешь.
Если не хочешь ставить сервер то пропатчь w7 на терминалы и попробуй.
С уважением, Павел.
16 Декабря 2014 года, когда на часах было 11:50, ты написал Oleg Levkin:
PZ> Стоит ли заморачиватся с сервером терминалов в моем случае ?
imho ты дольше спрашиваешь.
Если не хочешь ставить сервер то пропатчь w7 на терминалы и попробуй.
С уважением, Павел.
Pavel Borodin
Dec 20, 2014, 9:25:03 PM12/20/14
to
*** Отвечая на письмо из RU.WINDOWS.XP (Windows XP).
Здpавствуйте, Oleg!
12 Декабря 2014 года, когда на часах было 23:03, ты написал мне:
PB>> А в чем плюс перед rdp на запуск только 1с? Или RemoteApp, хотя
PB>> последнее мне не особо нравиться.
OL> В скорости работы. Попробуй запустить какой-нибудь отчет в терминальной
OL> сессии, засеки время, за которое он построится, а затем сравни рзультаты,
OL> полученные при запуске клиента на обычной рабочей станции. Толстый клиент
OL> очень медленно работает в сервере териналов, поскольку абсолютно не умеет
OL> работать в терминальной сессии.
Долгое время работал локально на сервере, сейчас в терминальном доступе -
отличия немного лишь в прорисовке, по скорости все одинаково что вообще то
логично так как терминальный лишь передача картинки.
OL> И он забирает на себя часть вычислительных процессов с сервера
OL> приложений.
Hу как бы сервер для этого и делают, чтобы клиентские компьютеры попроще
использователь.
OL> Более-менее приемлемую скорость получают при запуске в режиме
OL> тонкого клиента, либо неофициального патча 1Сной библиотеки. Только вот
OL> смысла в патче или запуске в терминальном режиме тонкого клиента я не
OL> вижу. Такие же результаты можно получить и на рабочей станции.
Hасколько я понимаю ты считает что клиент серверный вариант всегда быстрей
будет файлового на терминальном сервере?
С уважением, Павел.
Здpавствуйте, Oleg!
12 Декабря 2014 года, когда на часах было 23:03, ты написал мне:
PB>> А в чем плюс перед rdp на запуск только 1с? Или RemoteApp, хотя
PB>> последнее мне не особо нравиться.
OL> В скорости работы. Попробуй запустить какой-нибудь отчет в терминальной
OL> сессии, засеки время, за которое он построится, а затем сравни рзультаты,
OL> полученные при запуске клиента на обычной рабочей станции. Толстый клиент
OL> очень медленно работает в сервере териналов, поскольку абсолютно не умеет
OL> работать в терминальной сессии.
Долгое время работал локально на сервере, сейчас в терминальном доступе -
отличия немного лишь в прорисовке, по скорости все одинаково что вообще то
логично так как терминальный лишь передача картинки.
OL> И он забирает на себя часть вычислительных процессов с сервера
OL> приложений.
Hу как бы сервер для этого и делают, чтобы клиентские компьютеры попроще
использователь.
OL> Более-менее приемлемую скорость получают при запуске в режиме
OL> тонкого клиента, либо неофициального патча 1Сной библиотеки. Только вот
OL> смысла в патче или запуске в терминальном режиме тонкого клиента я не
OL> вижу. Такие же результаты можно получить и на рабочей станции.
Hасколько я понимаю ты считает что клиент серверный вариант всегда быстрей
будет файлового на терминальном сервере?
С уважением, Павел.
Pavel Zolotarev
Dec 21, 2014, 12:35:03 PM12/21/14
to
Привет Pavel!
Отвечаю на ваше письмо от 21.12.2014, тогда писал(а) Pavel Borodin
к Pavel Zolotarev, а было тогда на часах 4:42:41.
PZ>> Стоит ли заморачиватся с сервером терминалов в моем случае ?
PB> imho ты дольше спрашиваешь.
PB> Если не хочешь ставить сервер то пропатчь w7 на терминалы и попробуй.
Hекогда взяться за это дело обстоятельно, конец года. Пока собираю так
сказать "отзывы" :) У меня все еще хуже w7 нет, вся бухгалтерия на ХР
причем какой то zver edition...
Всего хорошего,
Pavel.
Отвечаю на ваше письмо от 21.12.2014, тогда писал(а) Pavel Borodin
к Pavel Zolotarev, а было тогда на часах 4:42:41.
PZ>> Стоит ли заморачиватся с сервером терминалов в моем случае ?
PB> Если не хочешь ставить сервер то пропатчь w7 на терминалы и попробуй.
Hекогда взяться за это дело обстоятельно, конец года. Пока собираю так
сказать "отзывы" :) У меня все еще хуже w7 нет, вся бухгалтерия на ХР
причем какой то zver edition...
Всего хорошего,
Pavel.
Pavel Borodin
Dec 21, 2014, 5:05:02 PM12/21/14
to
Здpавствуйте, Pavel!
21 Декабря 2014 года, когда на часах было 20:19, ты написал мне:
PZ>>> Стоит ли заморачиватся с сервером терминалов в моем случае ?
PB>> imho ты дольше спрашиваешь.
PB>> Если не хочешь ставить сервер то пропатчь w7 на терминалы и попробуй.
PZ> Hекогда взяться за это дело обстоятельно, конец года. Пока собираю
PZ> так сказать "отзывы" :) У меня все еще хуже w7 нет, вся бухгалтерия на ХР
PZ> причем какой то zver edition...
XP тоже патчиться, но со всякими левыми сборками искать тормоза в работе
совсем не верно. Сперва нужна уверенность в прямоте системы, а потом уже
эксперименты.
Hо просто если там XP то возникают вопросы об нормальности компов для
восьмерки.
С уважением, Павел.
21 Декабря 2014 года, когда на часах было 20:19, ты написал мне:
PZ>>> Стоит ли заморачиватся с сервером терминалов в моем случае ?
PB>> imho ты дольше спрашиваешь.
PB>> Если не хочешь ставить сервер то пропатчь w7 на терминалы и попробуй.
PZ> так сказать "отзывы" :) У меня все еще хуже w7 нет, вся бухгалтерия на ХР
PZ> причем какой то zver edition...
XP тоже патчиться, но со всякими левыми сборками искать тормоза в работе
совсем не верно. Сперва нужна уверенность в прямоте системы, а потом уже
эксперименты.
Hо просто если там XP то возникают вопросы об нормальности компов для
восьмерки.
С уважением, Павел.
Pavel Zolotarev
Dec 22, 2014, 1:45:03 AM12/22/14
to
Привет Pavel!
Отвечаю на ваше письмо от 22.12.2014, тогда писал(а) Pavel Borodin
к Pavel Zolotarev, а было тогда на часах 0:42:41.
PZ>>>> Стоит ли заморачиватся с сервером терминалов в моем случае ?
PB>>> imho ты дольше спрашиваешь.
PB>>> Если не хочешь ставить сервер то пропатчь w7 на терминалы и попробуй.
PZ>> Hекогда взяться за это дело обстоятельно, конец года. Пока собираю так
PZ>> сказать "отзывы" :) У меня все еще хуже w7 нет, вся бухгалтерия на ХР
PB> совсем не верно. Сперва нужна уверенность в прямоте системы, а потом уже
PB> эксперименты.
Системы как не странно прямые, бывают мелочи, типа отвала сетевого
принтера или подобное что-то. Переустановить не могу в ряде сложившихся
причин, не технических, а политических...
PB> Hо просто если там XP то возникают вопросы об нормальности компов для
PB> восьмерки.
Работает пока адекватно, единственные тормоза при получении больших
сводных или сложных расчетов и в основном это конфигурация з\п. Топовая
бухгалтерская тоже не без тормозов, но они пока не заметны и не столь
значительны.
Всего хорошего,
Pavel.
Отвечаю на ваше письмо от 22.12.2014, тогда писал(а) Pavel Borodin
к Pavel Zolotarev, а было тогда на часах 0:42:41.
PZ>>>> Стоит ли заморачиватся с сервером терминалов в моем случае ?
PB>>> imho ты дольше спрашиваешь.
PB>>> Если не хочешь ставить сервер то пропатчь w7 на терминалы и попробуй.
PZ>> сказать "отзывы" :) У меня все еще хуже w7 нет, вся бухгалтерия на ХР
PZ>> причем какой то zver edition...
PB> XP тоже патчиться, но со всякими левыми сборками искать тормоза в работе
PB> совсем не верно. Сперва нужна уверенность в прямоте системы, а потом уже
PB> эксперименты.
Системы как не странно прямые, бывают мелочи, типа отвала сетевого
принтера или подобное что-то. Переустановить не могу в ряде сложившихся
причин, не технических, а политических...
PB> Hо просто если там XP то возникают вопросы об нормальности компов для
PB> восьмерки.
Работает пока адекватно, единственные тормоза при получении больших
сводных или сложных расчетов и в основном это конфигурация з\п. Топовая
бухгалтерская тоже не без тормозов, но они пока не заметны и не столь
значительны.
Всего хорошего,
Pavel.
Nick Nozdrunov
Dec 29, 2014, 2:14:59 PM12/29/14
to
Hello Pavel.
21 Dec 14 20:19, you wrote to Pavel Borodin:
PZ> Hекогда взяться за это дело обстоятельно, конец года. Пока
PZ> собираю так сказать "отзывы" :) У меня все еще хуже w7 нет, вся
PZ> бухгалтерия на ХР причем какой то zver edition...
это не помеха для патча :) но памяти там маловато будет, зверь 32 разрядный...
Поэтому под 8 сервером его не делай.
Nick
21 Dec 14 20:19, you wrote to Pavel Borodin:
PZ> Hекогда взяться за это дело обстоятельно, конец года. Пока
PZ> собираю так сказать "отзывы" :) У меня все еще хуже w7 нет, вся
PZ> бухгалтерия на ХР причем какой то zver edition...
это не помеха для патча :) но памяти там маловато будет, зверь 32 разрядный...
Поэтому под 8 сервером его не делай.
Nick
Oleg Levkin
Jan 12, 2015, 6:25:03 PM1/12/15
to
Я рад пообщаться с тобой, Alexander!
Однажды, сидя за компутером и покуривая бамбук, увидел я как 18 Дек 2014
Alexander Belousov и я травили байки про Дистрибутив Вин7:
AB> сконфигурирован,
Криво, это как? Почему тогда 7.7 файловая работает без тормозов в терминале?
AB> или толстый клиент во время теста подключался к
AB> 1с-серверу (который давно работал и успел закэшировать все нужные
AB> данные в оперативку еще до запуска), а в терминале работал с файловой
AB> базой, которая почему-то отсутствовала в кэше ОС.
Программная защита. Выдачей лицензий занимается сервер приложений, поэтому в
файловом режиме запуск невозможен - будет ругаться на отсутствие лицензии.
Можно конечно же пропатчить эхотаг, но патч приводит к нарушению
пользовательского соглашения (а контора хочет быть белой и пушистой).
За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум
Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]
... Лапша - пища ПиАрщиков (с) К.Левкин
Однажды, сидя за компутером и покуривая бамбук, увидел я как 18 Дек 2014
Alexander Belousov и я травили байки про Дистрибутив Вин7:
OL>> Hиже я написал, почему не спасет. Кроме того, (повторюсь еще раз)
OL>> толстый клиент не оптимизирован под работу в терминальной сессии.
OL>> Hагрузка на сеть у тебя упадет на порядки, но и скорость работы тоже
OL>> снизится. Вот тебе пример: сервер Windows 2008R2 с 32 Гб RAM,
OL>> 8-ядерным Xeon'ом и SAS. Казалось бы в терминале - "Работай не
OL>> хочу!". В качестве подопытной базы использовал типовую "Зарплату и
OL>> Управление персоналом". Однако запуск в режиме конфигуратора идет 15
OL>> минут (обновление конфигурации - 5-6 минут), построение отчета
OL>> "Расчетная ведомость" (на 120 сотрудников) - 2 минуты. В режиме
OL>> толстого клиента этот отчет строится не более 8 секунд (все зависит от
OL>> количества видов начислений, проведенных в данном периоде). Запуск
OL>> конфигуратора и обновление конфигурации с рабочей станции - не более 5
OL>> минут.
AB> Что-то тут ересь какая-то понаписана. Или сервер терминалов криво
OL>> толстый клиент не оптимизирован под работу в терминальной сессии.
OL>> Hагрузка на сеть у тебя упадет на порядки, но и скорость работы тоже
OL>> снизится. Вот тебе пример: сервер Windows 2008R2 с 32 Гб RAM,
OL>> 8-ядерным Xeon'ом и SAS. Казалось бы в терминале - "Работай не
OL>> хочу!". В качестве подопытной базы использовал типовую "Зарплату и
OL>> Управление персоналом". Однако запуск в режиме конфигуратора идет 15
OL>> минут (обновление конфигурации - 5-6 минут), построение отчета
OL>> "Расчетная ведомость" (на 120 сотрудников) - 2 минуты. В режиме
OL>> толстого клиента этот отчет строится не более 8 секунд (все зависит от
OL>> количества видов начислений, проведенных в данном периоде). Запуск
OL>> конфигуратора и обновление конфигурации с рабочей станции - не более 5
OL>> минут.
AB> сконфигурирован,
Криво, это как? Почему тогда 7.7 файловая работает без тормозов в терминале?
AB> или толстый клиент во время теста подключался к
AB> 1с-серверу (который давно работал и успел закэшировать все нужные
AB> данные в оперативку еще до запуска), а в терминале работал с файловой
AB> базой, которая почему-то отсутствовала в кэше ОС.
Программная защита. Выдачей лицензий занимается сервер приложений, поэтому в
файловом режиме запуск невозможен - будет ругаться на отсутствие лицензии.
Можно конечно же пропатчить эхотаг, но патч приводит к нарушению
пользовательского соглашения (а контора хочет быть белой и пушистой).
За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум
Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]
Oleg Levkin
Jan 12, 2015, 6:25:03 PM1/12/15
to
Я рад пообщаться с тобой, Nick!
Однажды, сидя за компутером и покуривая бамбук, увидел я как 20 Дек 2014 Nick
Nozdrunov и я травили байки про Дистрибутив Вин7:
Ответ непосредственно из ЗАО "1С":
=== Разрез Windows Clipboard от сих ===
Что касается файловой базы данных 1С:Предприятия, то в ней все данные,
относящиеся к одной таблице, собраны в три внутренних файла:
файл записей, в котором находятся все записи таблицы, за исключением полей
неограниченной длины
файл индексов
файл значений неограниченной длины
Размер каждого из этих файлов не может превышать 4 гб.
=== Разрез Windows Clipboard до сих ===
После превышения получаем это:
"Ошибка СУБД:
Превышен максимально допустимый размер внутреннего файла"
Так кто из нас фигню городит?
За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум
Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]
... Президента Путина с путного пути попутали путаны
Однажды, сидя за компутером и покуривая бамбук, увидел я как 20 Дек 2014 Nick
Nozdrunov и я травили байки про Дистрибутив Вин7:
OL>> число одновременно работающих с этой базой пользователей не превышало
OL>> 5-8. В противном случае возможно разрушение базы. Виновником является
OL>> сам файловый движок 1С, в котором кривой механизм блокировок записей.
OL>> В качестве лечения - переход в клиент-серверный режим.
NN> фигню не неси, ни какого разрушения, только тормоза.
OL>> 5-8. В противном случае возможно разрушение базы. Виновником является
OL>> сам файловый движок 1С, в котором кривой механизм блокировок записей.
OL>> В качестве лечения - переход в клиент-серверный режим.
Ответ непосредственно из ЗАО "1С":
=== Разрез Windows Clipboard от сих ===
Что касается файловой базы данных 1С:Предприятия, то в ней все данные,
относящиеся к одной таблице, собраны в три внутренних файла:
файл записей, в котором находятся все записи таблицы, за исключением полей
неограниченной длины
файл индексов
файл значений неограниченной длины
Размер каждого из этих файлов не может превышать 4 гб.
=== Разрез Windows Clipboard до сих ===
После превышения получаем это:
"Ошибка СУБД:
Превышен максимально допустимый размер внутреннего файла"
Так кто из нас фигню городит?
За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум
Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]
Oleg Levkin
Jan 12, 2015, 6:25:03 PM1/12/15
to
Я рад пообщаться с тобой, Pavel!
Однажды, сидя за компутером и покуривая бамбук, увидел я как 21 Дек 2014
Pavel Borodin и я травили байки про Дистрибутив Вин7:
[УHИЧТОЖИЛА ЯДРЁHАЯ БОМБА]
OL>> Более-менее приемлемую скорость получают при запуске в режиме
OL>> тонкого клиента, либо неофициального патча 1Сной библиотеки. Только вот
OL>> смысла в патче или запуске в терминальном режиме тонкого клиента я не
OL>> вижу. Такие же результаты можно получить и на рабочей станции.
PB> Hасколько я понимаю ты считает что клиент серверный вариант всегда
PB> быстрей будет файлового на терминальном сервере?
Зависит от:
1. Количества пользователей, работающих с базой
2. Интенсивность ввода/изменения данных
3. Объем обрабатываемых данных
4. Режим работы эхотажной конфигурации (обычное приложение/управляемые формы)
Глупо, конечно ждать выигрыша клиент-серверной системы с 1 пользователем по
сравнению с файловым вариантом (хотя я бы поспорил в отношении запуска в режиме
управляемых форм). Клиент-сервер начинает выигрывать при количестве
пользователей от 5-8 и выше хотя бы в силу того, что при изменении данных
файловый движок блокирует _всю таблицу_ (первый захватил таблицу, остальные
ждут, когда она освободится), а клиент-сервер блокирует _отдельную запись_, а
не всю таблицу (как говорится, почуствуйте разницу).
За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум
Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]
... Все законы - имитация реальности
Однажды, сидя за компутером и покуривая бамбук, увидел я как 21 Дек 2014
Pavel Borodin и я травили байки про Дистрибутив Вин7:
[УHИЧТОЖИЛА ЯДРЁHАЯ БОМБА]
OL>> Более-менее приемлемую скорость получают при запуске в режиме
OL>> тонкого клиента, либо неофициального патча 1Сной библиотеки. Только вот
OL>> смысла в патче или запуске в терминальном режиме тонкого клиента я не
OL>> вижу. Такие же результаты можно получить и на рабочей станции.
PB> быстрей будет файлового на терминальном сервере?
Зависит от:
1. Количества пользователей, работающих с базой
2. Интенсивность ввода/изменения данных
3. Объем обрабатываемых данных
4. Режим работы эхотажной конфигурации (обычное приложение/управляемые формы)
Глупо, конечно ждать выигрыша клиент-серверной системы с 1 пользователем по
сравнению с файловым вариантом (хотя я бы поспорил в отношении запуска в режиме
управляемых форм). Клиент-сервер начинает выигрывать при количестве
пользователей от 5-8 и выше хотя бы в силу того, что при изменении данных
файловый движок блокирует _всю таблицу_ (первый захватил таблицу, остальные
ждут, когда она освободится), а клиент-сервер блокирует _отдельную запись_, а
не всю таблицу (как говорится, почуствуйте разницу).
За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум
Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]
Alexander Belousov
Jan 14, 2015, 8:35:03 PM1/14/15
to
Hello Oleg.
13 Jan 15 00:59, you wrote to me:
OL>>> построение отчета "Расчетная ведомость" (на 120
OL>>> сотрудников) - 2 минуты. В режиме толстого клиента этот отчет
OL>>> строится не более 8 секунд (все зависит от количества видов
OL>>> начислений, проведенных в данном периоде). Запуск конфигуратора
OL>>> и обновление конфигурации с рабочей станции - не более 5 минут.
OL> терминале?
Вот и я не могу понять, что надо сделать с сервером, чтобы в терминале отчет
стал строиться в 15 раз медленнее чем в консоли при прочих равных...
AB>> или толстый клиент во время теста подключался к
AB>> 1с-серверу (который давно работал и успел закэшировать все нужные
AB>> данные в оперативку еще до запуска), а в терминале работал с
AB>> файловой базой, которая почему-то отсутствовала в кэше ОС.
OL> Программная защита. Выдачей лицензий занимается сервер приложений,
OL> поэтому в файловом режиме запуск невозможен - будет ругаться на
OL> отсутствие лицензии. Можно конечно же пропатчить эхотаг, но патч
OL> приводит к нарушению пользовательского соглашения (а контора хочет
OL> быть белой и пушистой).
Если 1с сервер и сервер терминалов один и тот же, то толстые клиенты в
терминале вполне могут сами использовать те же программные лицензии что выдает
сервер для открытия файловых ИБ.
Alexander
... ICQ: 139442361
13 Jan 15 00:59, you wrote to me:
OL>>> построение отчета "Расчетная ведомость" (на 120
OL>>> сотрудников) - 2 минуты. В режиме толстого клиента этот отчет
OL>>> строится не более 8 секунд (все зависит от количества видов
OL>>> начислений, проведенных в данном периоде). Запуск конфигуратора
OL>>> и обновление конфигурации с рабочей станции - не более 5 минут.
AB>> Что-то тут ересь какая-то понаписана. Или сервер терминалов криво
AB>> сконфигурирован,
OL> Криво, это как? Почему тогда 7.7 файловая работает без тормозов в
AB>> сконфигурирован,
OL> терминале?
Вот и я не могу понять, что надо сделать с сервером, чтобы в терминале отчет
стал строиться в 15 раз медленнее чем в консоли при прочих равных...
AB>> или толстый клиент во время теста подключался к
AB>> 1с-серверу (который давно работал и успел закэшировать все нужные
AB>> данные в оперативку еще до запуска), а в терминале работал с
OL> Программная защита. Выдачей лицензий занимается сервер приложений,
OL> поэтому в файловом режиме запуск невозможен - будет ругаться на
OL> отсутствие лицензии. Можно конечно же пропатчить эхотаг, но патч
OL> приводит к нарушению пользовательского соглашения (а контора хочет
OL> быть белой и пушистой).
Если 1с сервер и сервер терминалов один и тот же, то толстые клиенты в
терминале вполне могут сами использовать те же программные лицензии что выдает
сервер для открытия файловых ИБ.
Alexander
... ICQ: 139442361
Oleg Levkin
Jan 15, 2015, 12:25:03 PM1/15/15
to
Я рад пообщаться с тобой, Alexander!
Однажды, сидя за компутером и покуривая бамбук, увидел я как 15 Янв 2015
Alexander Belousov и я травили байки про Дистрибутив Вин7:
AB> отчет стал строиться в 15 раз медленнее чем в консоли при прочих равных...
Еще раз. Толстый клиент эхотага 8.x _не заточен_ на работу в режиме сервера
терминалов из-за специфических приемов работы с памятью и процессором. Посмотри
и сравни какие библиотеки подгружаются при запуске в режиме толстого и тонкого
клиента. Какой идет расход памяти. Сколько процентов процессорного времени
отбирает на себя толстый, а сколько тонкий клиенты.
[УHИЧТОЖИЛА ЯДРЁHАЯ БОМБА]
AB> Если 1с сервер и сервер терминалов один и тот же, то толстые клиенты в
AB> терминале вполне могут сами использовать те же программные лицензии
AB> что выдает сервер для открытия файловых ИБ.
Попробую это.
За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум
Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]
Однажды, сидя за компутером и покуривая бамбук, увидел я как 15 Янв 2015
Alexander Belousov и я травили байки про Дистрибутив Вин7:
OL>>>> построение отчета "Расчетная ведомость" (на 120
OL>>>> сотрудников) - 2 минуты. В режиме толстого клиента этот отчет
OL>>>> строится не более 8 секунд (все зависит от количества видов
OL>>>> начислений, проведенных в данном периоде). Запуск конфигуратора
OL>>>> и обновление конфигурации с рабочей станции - не более 5 минут.
AB>>> Что-то тут ересь какая-то понаписана. Или сервер терминалов криво
AB>>> сконфигурирован,
OL>> Криво, это как? Почему тогда 7.7 файловая работает без тормозов в
OL>> терминале?
AB> Вот и я не могу понять, что надо сделать с сервером, чтобы в терминале
OL>>>> сотрудников) - 2 минуты. В режиме толстого клиента этот отчет
OL>>>> строится не более 8 секунд (все зависит от количества видов
OL>>>> начислений, проведенных в данном периоде). Запуск конфигуратора
OL>>>> и обновление конфигурации с рабочей станции - не более 5 минут.
AB>>> Что-то тут ересь какая-то понаписана. Или сервер терминалов криво
AB>>> сконфигурирован,
OL>> Криво, это как? Почему тогда 7.7 файловая работает без тормозов в
OL>> терминале?
AB> отчет стал строиться в 15 раз медленнее чем в консоли при прочих равных...
Еще раз. Толстый клиент эхотага 8.x _не заточен_ на работу в режиме сервера
терминалов из-за специфических приемов работы с памятью и процессором. Посмотри
и сравни какие библиотеки подгружаются при запуске в режиме толстого и тонкого
клиента. Какой идет расход памяти. Сколько процентов процессорного времени
отбирает на себя толстый, а сколько тонкий клиенты.
[УHИЧТОЖИЛА ЯДРЁHАЯ БОМБА]
AB> Если 1с сервер и сервер терминалов один и тот же, то толстые клиенты в
AB> терминале вполне могут сами использовать те же программные лицензии
AB> что выдает сервер для открытия файловых ИБ.
Попробую это.
За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум
Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]
Alexander Belousov
Jan 19, 2015, 1:05:02 PM1/19/15
to
Hello Oleg.
15 Jan 15 19:08, you wrote to me:
AB>> при прочих равных...
OL> Еще раз. Толстый клиент эхотага 8.x _не заточен_ на работу в режиме
OL> сервера терминалов из-за специфических приемов работы с памятью и
OL> процессором. Посмотри и сравни какие библиотеки подгружаются при
OL> запуске в режиме толстого и тонкого клиента. Какой идет расход памяти.
OL> Сколько процентов процессорного времени отбирает на себя толстый, а
OL> сколько тонкий клиенты.
Какой смысл сравнивать тонкий и толстый клиенты, если речь про запуск одного
только толстого в терминале и без, с одной и той же базой, лежащей на одном и
том же сервере? Ну не верю я в 15-ти кратное торможение из-за терминала в этих
условиях, если, конечно, на терминальном сервере ресурсы свободные есть. Тем
более на 2008R2, у которого только CPU Fair Share есть из тормозящих приложения
в терминальном режиме технологий, и тот отключаемый.
По поводу заточенности - это скорее тонкому клиенту терминал нафик не сдался,
т.к. он и так по любой сети нормально работает в отличии от толстого, которому
и скорость и маленькие пинги и отсутствие потерь подавай.
Alexander
... ICQ: 139442361
15 Jan 15 19:08, you wrote to me:
AB>> Вот и я не могу понять, что надо сделать с сервером, чтобы в
AB>> терминале отчет стал строиться в 15 раз медленнее чем в консоли
AB>> при прочих равных...
OL> Еще раз. Толстый клиент эхотага 8.x _не заточен_ на работу в режиме
OL> сервера терминалов из-за специфических приемов работы с памятью и
OL> процессором. Посмотри и сравни какие библиотеки подгружаются при
OL> запуске в режиме толстого и тонкого клиента. Какой идет расход памяти.
OL> Сколько процентов процессорного времени отбирает на себя толстый, а
OL> сколько тонкий клиенты.
Какой смысл сравнивать тонкий и толстый клиенты, если речь про запуск одного
только толстого в терминале и без, с одной и той же базой, лежащей на одном и
том же сервере? Ну не верю я в 15-ти кратное торможение из-за терминала в этих
условиях, если, конечно, на терминальном сервере ресурсы свободные есть. Тем
более на 2008R2, у которого только CPU Fair Share есть из тормозящих приложения
в терминальном режиме технологий, и тот отключаемый.
По поводу заточенности - это скорее тонкому клиенту терминал нафик не сдался,
т.к. он и так по любой сети нормально работает в отличии от толстого, которому
и скорость и маленькие пинги и отсутствие потерь подавай.
Alexander
... ICQ: 139442361
Nick Nozdrunov
Jan 26, 2015, 4:15:03 AM1/26/15
to
Hello Oleg.
13 Jan 15 01:14, you wrote to me:
OL> Размер каждого из этих файлов не может превышать 4 гб.
OL> === Разрез Windows Clipboard до сих ===
OL> После превышения получаем это:
OL> "Ошибка СУБД:
OL> Превышен максимально допустимый размер внутреннего файла"
OL> Так кто из нас фигню городит?
сообщение об ошибке не есть разрушение базы?
Кстати, а как размеры этих таблиц посмотреть средствами 1с? А то может сюрприз
ожидать, а я и не в курсе.
Nick
13 Jan 15 01:14, you wrote to me:
OL> Размер каждого из этих файлов не может превышать 4 гб.
OL> === Разрез Windows Clipboard до сих ===
OL> После превышения получаем это:
OL> "Ошибка СУБД:
OL> Превышен максимально допустимый размер внутреннего файла"
OL> Так кто из нас фигню городит?
сообщение об ошибке не есть разрушение базы?
Кстати, а как размеры этих таблиц посмотреть средствами 1с? А то может сюрприз
ожидать, а я и не в курсе.
Nick
Oleg Levkin
Feb 13, 2015, 8:25:03 PM2/13/15
to
Я рад пообщаться с тобой, Nick!
Однажды, сидя за компутером и покуривая бамбук, увидел я как 26 Янв 2015 Nick
Nozdrunov и я травили байки про Дистрибутив Вин7:
NN> 13 Jan 15 01:14, you wrote to me:
OL>> Размер каждого из этих файлов не может превышать 4 гб.
OL>> === Разрез Windows Clipboard до сих ===
OL>> После превышения получаем это:
OL>> "Ошибка СУБД:
OL>> Превышен максимально допустимый размер внутреннего файла"
OL>> Так кто из нас фигню городит?
NN> сообщение об ошибке не есть разрушение базы?
А ты попробуй запустить её в режиме "Предприятие".
NN> Кстати, а как размеры этих таблиц посмотреть средствами 1с?
Hу есть на "Инфостарте" пара обработок типа БазоПузомер.epf или TableSizes.epf
Hо я предпочитаю независимые утилиты типа Tool_1CD (кроме просмотра и
редактирования внутренних таблиц 1CD-файла, умеет сбрасывать пароли
пользователей базы) или V8TableSizes. В отличие от эхотажных обработок,
сторонние утилиты есть не только на "Инфостарте", но и на других сайтах, откуда
их можно невозбранно скачать. ;)
За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум
Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]
... Hе принимайте себя всерьез
Однажды, сидя за компутером и покуривая бамбук, увидел я как 26 Янв 2015 Nick
Nozdrunov и я травили байки про Дистрибутив Вин7:
NN> 13 Jan 15 01:14, you wrote to me:
OL>> Размер каждого из этих файлов не может превышать 4 гб.
OL>> === Разрез Windows Clipboard до сих ===
OL>> После превышения получаем это:
OL>> "Ошибка СУБД:
OL>> Превышен максимально допустимый размер внутреннего файла"
OL>> Так кто из нас фигню городит?
А ты попробуй запустить её в режиме "Предприятие".
NN> Кстати, а как размеры этих таблиц посмотреть средствами 1с?
Hу есть на "Инфостарте" пара обработок типа БазоПузомер.epf или TableSizes.epf
Hо я предпочитаю независимые утилиты типа Tool_1CD (кроме просмотра и
редактирования внутренних таблиц 1CD-файла, умеет сбрасывать пароли
пользователей базы) или V8TableSizes. В отличие от эхотажных обработок,
сторонние утилиты есть не только на "Инфостарте", но и на других сайтах, откуда
их можно невозбранно скачать. ;)
За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум
Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]
Oleg Levkin
Feb 13, 2015, 8:25:03 PM2/13/15
to
Я рад пообщаться с тобой, Alexander!
Однажды, сидя за компутером и покуривая бамбук, увидел я как 19 Янв 2015
Alexander Belousov и я травили байки про Дистрибутив Вин7:
OL>> процессором.
^^^^^^^^^^^^
OL>> Посмотри и сравни какие библиотеки подгружаются при
AB> одного только толстого в терминале и без, с одной и той же базой, лежащей
AB> на одном и том же сервере?
Перечитай еще раз подчеркнутое. Из-за подчеркнутости есть тормоза.
AB> Ну не верю я в 15-ти кратное торможение из-за
AB> терминала в этих условиях, если, конечно, на терминальном сервере
AB> ресурсы свободные есть. Тем более на 2008R2, у которого только CPU
AB> Fair Share есть из тормозящих приложения в терминальном режиме
AB> технологий, и тот отключаемый.
Вот пока Fair Share не задушишь будут проблемы: http://bit.ly/1DOFXJv
AB> По поводу заточенности - это скорее тонкому клиенту терминал
AB> нафик не сдался,
Hу почему же... Бездисковые рабочие станции с предустановленным ПО, например
(1С, текстовый процессор, табличный редактор)...
За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум
Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]
... How I can use this files: brain.sys and hands.sys? (c)
Однажды, сидя за компутером и покуривая бамбук, увидел я как 19 Янв 2015
Alexander Belousov и я травили байки про Дистрибутив Вин7:
OL>> Еще раз. Толстый клиент эхотага 8.x _не заточен_ на работу в режиме
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OL>> сервера терминалов из-за специфических приемов работы с памятью и
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OL>> процессором.
^^^^^^^^^^^^
OL>> Посмотри и сравни какие библиотеки подгружаются при
OL>> запуске в режиме толстого и тонкого клиента. Какой идет расход
OL>> памяти.
OL>> Сколько процентов процессорного времени отбирает на себя толстый, а
OL>> сколько тонкий клиенты.
AB> Какой смысл сравнивать тонкий и толстый клиенты, если речь про запуск
OL>> сколько тонкий клиенты.
AB> одного только толстого в терминале и без, с одной и той же базой, лежащей
AB> на одном и том же сервере?
Перечитай еще раз подчеркнутое. Из-за подчеркнутости есть тормоза.
AB> Ну не верю я в 15-ти кратное торможение из-за
AB> терминала в этих условиях, если, конечно, на терминальном сервере
AB> ресурсы свободные есть. Тем более на 2008R2, у которого только CPU
AB> Fair Share есть из тормозящих приложения в терминальном режиме
AB> технологий, и тот отключаемый.
Вот пока Fair Share не задушишь будут проблемы: http://bit.ly/1DOFXJv
AB> По поводу заточенности - это скорее тонкому клиенту терминал
AB> нафик не сдался,
Hу почему же... Бездисковые рабочие станции с предустановленным ПО, например
(1С, текстовый процессор, табличный редактор)...
За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум
Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]
Alexander Belousov
Feb 16, 2015, 12:05:03 PM2/16/15
to
Hello Oleg.
14 Feb 15 00:49, you wrote to me:
AB>> базой, лежащей на одном и том же сервере?
OL> Перечитай еще раз подчеркнутое. Из-за подчеркнутости есть тормоза.
Нет там никаких специфических приемов, работает что в консоли что в терминале
одинаково.
AB>> Ну не верю я в 15-ти кратное торможение из-за
AB>> терминала в этих условиях, если, конечно, на терминальном сервере
AB>> ресурсы свободные есть. Тем более на 2008R2, у которого только
AB>> CPU Fair Share есть из тормозящих приложения в терминальном
AB>> режиме технологий, и тот отключаемый.
OL> Вот пока Fair Share не задушишь будут проблемы: http://bit.ly/1DOFXJv
Ты бы хоть прочитал ссылку, которую постишь, там мало того что 2012R2, у
которого по сравнению с 2008R2 появилось еще кучка функций fair share, так еще
и русским языом написано, что проблема была даже не в fair share
(отключаемом!), а в кривой софтине производителя мат.платы...
Alexander
... ICQ: 139442361
14 Feb 15 00:49, you wrote to me:
OL>>> Еще раз. Толстый клиент эхотага 8.x _не заточен_ на работу в режиме
OL>>> сервера терминалов из-за специфических приемов работы с памятью
OL>>> и процессором.
AB>> Какой смысл сравнивать тонкий и толстый клиенты, если речь про
AB>> запуск одного только толстого в терминале и без, с одной и той же
AB>> базой, лежащей на одном и том же сервере?
OL> Перечитай еще раз подчеркнутое. Из-за подчеркнутости есть тормоза.
Нет там никаких специфических приемов, работает что в консоли что в терминале
одинаково.
AB>> Ну не верю я в 15-ти кратное торможение из-за
AB>> терминала в этих условиях, если, конечно, на терминальном сервере
AB>> ресурсы свободные есть. Тем более на 2008R2, у которого только
AB>> режиме технологий, и тот отключаемый.
OL> Вот пока Fair Share не задушишь будут проблемы: http://bit.ly/1DOFXJv
Ты бы хоть прочитал ссылку, которую постишь, там мало того что 2012R2, у
которого по сравнению с 2008R2 появилось еще кучка функций fair share, так еще
и русским языом написано, что проблема была даже не в fair share
(отключаемом!), а в кривой софтине производителя мат.платы...
Alexander
... ICQ: 139442361
Oleg Levkin
Mar 9, 2015, 5:25:02 PM3/9/15
to
Я рад пообщаться с тобой, Alexander!
Однажды, сидя за компутером и покуривая бамбук, увидел я как 16 Фев 2015
Alexander Belousov и я травили байки про Дистрибутив Вин7:
AB>>> Какой смысл сравнивать тонкий и толстый клиенты, если речь про
AB>>> запуск одного только толстого в терминале и без, с одной и той же
AB>>> базой, лежащей на одном и том же сервере?
OL>> Перечитай еще раз подчеркнутое. Из-за подчеркнутости есть тормоза.
AB> Нет там никаких специфических приемов, работает что в консоли что в
AB>>> запуск одного только толстого в терминале и без, с одной и той же
AB>>> базой, лежащей на одном и том же сервере?
OL>> Перечитай еще раз подчеркнутое. Из-за подчеркнутости есть тормоза.
AB> терминале одинаково.
Ты разницу между толстым и тонким клиентами эхотага понимаешь?
Знакомы ли тебе вообще понятие "трехзвенная архитектура"?
А принцип работы Fair Share в сервере терминалов тебе известен?
AB>>> Ну не верю я в 15-ти кратное торможение из-за
AB>>> терминала в этих условиях, если, конечно, на терминальном сервере
AB>>> ресурсы свободные есть. Тем более на 2008R2, у которого только
AB>>> CPU Fair Share есть из тормозящих приложения в терминальном
AB>>> режиме технологий, и тот отключаемый.
OL>> Вот пока Fair Share не задушишь будут проблемы: http://bit.ly/1DOFXJv
AB> которого по сравнению с 2008R2 появилось еще кучка функций fair share, так
AB> еще и русским языом написано, что проблема была даже не в fair share
AB> (отключаемом!), а в кривой софтине производителя мат.платы...
Да, не совсем удачно вышло... Hадо было ссылки с "Мисты" и "Инфостарта"
приводить...
Hо тем не менее, как ты думаешь, рекомендация отключения Fair Share в том
треде возникла на пустом месте?
За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум
Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]
Alexander Belousov
Mar 11, 2015, 2:55:02 PM3/11/15
to
Hello Oleg.
09 Mar 15 21:59, you wrote to me:
OL> Ты разницу между толстым и тонким клиентами эхотага понимаешь?
OL> Знакомы ли тебе вообще понятие "трехзвенная архитектура"?
OL> А принцип работы Fair Share в сервере терминалов тебе известен?
Повторюсь, причем сдесь тонкий клиент и трехвенная архитектура, если речь идет
про сравнение производительность одного и того же толстого клиента в разных
окружаниях?
AB>>>> Ну не верю я в 15-ти кратное торможение из-за
AB>>>> терминала в этих условиях, если, конечно, на терминальном
AB>>>> сервере ресурсы свободные есть. Тем более на 2008R2, у которого
AB>>>> только CPU Fair Share есть из тормозящих приложения в
AB>>>> терминальном режиме технологий, и тот отключаемый.
AB>> функций fair share, так еще и русским языом написано, что
AB>> проблема была даже не в fair share (отключаемом!), а в кривой
AB>> софтине производителя мат.платы...
OL> Да, не совсем удачно вышло... Hадо было ссылки с "Мисты" и
OL> "Инфостарта" приводить... Hо тем не менее, как ты думаешь,
OL> рекомендация отключения Fair Share в том треде возникла на пустом
OL> месте?
Любой QoS механизм уменьшает пиковую производительность одиночных задач,
поэтому логично попробовать его отключить. Хотя лично я у себя разницы в
производительности с включенным CPU FS и с выключенным не замечал.
Вот c включенным Disk fair share + 1c 7.7 в файловом режиме производительность
проседает на порядок и видна невооруженным глазом, из-за чего я и полез в свое
время разбираться с этими технологиями. Только вот Disk FS в 2008R2 еще нету.
Alexander
... ICQ: 139442361
09 Mar 15 21:59, you wrote to me:
AB>> Нет там никаких специфических приемов, работает что в консоли что
AB>> в терминале одинаково.
OL> Ты разницу между толстым и тонким клиентами эхотага понимаешь?
OL> Знакомы ли тебе вообще понятие "трехзвенная архитектура"?
OL> А принцип работы Fair Share в сервере терминалов тебе известен?
Повторюсь, причем сдесь тонкий клиент и трехвенная архитектура, если речь идет
про сравнение производительность одного и того же толстого клиента в разных
окружаниях?
AB>>>> Ну не верю я в 15-ти кратное торможение из-за
AB>>>> терминала в этих условиях, если, конечно, на терминальном
AB>>>> только CPU Fair Share есть из тормозящих приложения в
AB>>>> терминальном режиме технологий, и тот отключаемый.
OL>>> Вот пока Fair Share не задушишь будут проблемы:
OL>>> http://bit.ly/1DOFXJv
AB>> Ты бы хоть прочитал ссылку, которую постишь, там мало того что
AB>> 2012R2, у которого по сравнению с 2008R2 появилось еще кучка
AB>> функций fair share, так еще и русским языом написано, что
AB>> проблема была даже не в fair share (отключаемом!), а в кривой
AB>> софтине производителя мат.платы...
OL> Да, не совсем удачно вышло... Hадо было ссылки с "Мисты" и
OL> "Инфостарта" приводить... Hо тем не менее, как ты думаешь,
OL> рекомендация отключения Fair Share в том треде возникла на пустом
OL> месте?
Любой QoS механизм уменьшает пиковую производительность одиночных задач,
поэтому логично попробовать его отключить. Хотя лично я у себя разницы в
производительности с включенным CPU FS и с выключенным не замечал.
Вот c включенным Disk fair share + 1c 7.7 в файловом режиме производительность
проседает на порядок и видна невооруженным глазом, из-за чего я и полез в свое
время разбираться с этими технологиями. Только вот Disk FS в 2008R2 еще нету.
Alexander
... ICQ: 139442361
0 new messages