Имя: Пароль:
1C
 
1c после платформы 8.3.15.1830 стала жутко тормозить
0 Лентаf
 
21.01.20
11:19
всем привет друзья!
Кто ставил 8.3.15.1830 серверный вариант баз, все стало хуже работать.
1 Лентаf
 
21.01.20
11:19
ребут сервера сделал, может есть смысл перейти на 8.3.16.1148?
2 RoRu
 
21.01.20
11:21
На последней 16 та же фигня (((
3 palsergeich
 
21.01.20
11:23
Надо бомбить партнерку, что бы они разрабов платформы отшлепали.
Чем больше воя. тем больше толку
4 Лентаf
 
21.01.20
11:26
2DYMC  Материнская плата Dell
Intel® Xeon® Processor X5675
48 гигов памяти
не ссд на 1 терабайт
5 palsergeich
 
21.01.20
11:28
Та я тут партнерку глянул, там у людей жопы горят.
https://partners.v8.1c.ru/forum/topic/1880900 например
Ждем когда поправят и бомбим партнерку.
6 Масянька
 
21.01.20
11:29
Интересно попробовать - эска завалит пентагоновский сервак? :(
7 Джинн
 
21.01.20
11:30
(0) Этот же релиз - никакой разницы в производительности не заметил с предыдущими.
8 2S
 
21.01.20
11:43
(0) вы наверное почувствовали разницу между ПРОФ и КОРП ;)
9 Kigo_Kigo
 
21.01.20
11:44
тоже ставил одну из новых платформы, были жуткие тормоза, удаление кеша помогло
10 Vstur
 
21.01.20
11:54
(5) в двух словах, о чем там речь идет ?
11 ansh15
 
21.01.20
12:02
>>Intel® Xeon® Processor X5675
Очередной деликатный намек "любителям винтажа".
12 ВикторП
 
21.01.20
12:06
(10) там про ошибку в файловой базе - неправильный план запроса для 8.3.16.1048
13 palsergeich
 
21.01.20
12:10
(10) К тому что за последние 2 дня очегь много на платформу жалуются, у некоторых бомбит.
14 Garykom
 
гуру
21.01.20
12:22
Может дело не в платформе а в конфе? Она обновлялась или нет?
15 pechkin
 
21.01.20
12:38
у нас 15.1830 -  уторможений после апдейта не замечено
16 Лентаf
 
21.01.20
12:42
(14) ласт
17 neomarat
 
21.01.20
12:44
У нас вообще стал падать сервер 1С(32 разряда) с нехваткой памяти. На 12 перезапускали раз в месяц - теперь раз в пол-дня валится.
18 sqr4
 
21.01.20
12:50
Есть ли жизнь на новых платформах?)
19 arsik
 
гуру
21.01.20
12:50
(17) Ну так укажите ограничение в настройках.
20 pechkin
 
21.01.20
12:51
(19) ну будет валиться еще чаще
21 pechkin
 
21.01.20
12:51
ограничение не ограничивает потребление, а прибивает если слишком много съел
22 neomarat
 
21.01.20
12:52
(19) ограничение чего? Онаж вроде больше 2Гб адресовать не может. Сделать еще меньше? Ей и этого не хватает теперь.
23 neomarat
 
21.01.20
12:53
(21) пользователи отвалятся при этом?
24 Cyberhawk
 
21.01.20
12:54
(5) Какую-то ты левую тему скинул. (10) Там про то что техподдержка у 1С - дно
25 Cyberhawk
 
21.01.20
12:55
(23) Для 32б кроме размножения рпхостов у тебя выхода нет
26 Пробел
 
21.01.20
12:57
(17) подтвержу проблему с 32-разрядным сервером 1с на платформе 8.3.16.1048. Пришлось срочно докупать лицуху на x64...
27 pechkin
 
21.01.20
12:58
(25) так вроде ты сам ничего размножить не можешь, 1с все сама делает
28 Cyberhawk
 
21.01.20
13:00
(27) Через ограничение кол-ва соединений на процесс конечно же
29 Пробел
 
21.01.20
13:00
(25) (27) 8.3. плодит рпхосты автоматически, в зависимости от параметров "Количество ИБ на процесс" и "Количество соединений на процесс".

А лицензии уровня ПРОФ не позволяют изменять эти параметры)))
30 Cyberhawk
 
21.01.20
13:01
(29) Ошибаешься
31 Cyberhawk
 
21.01.20
13:01
"Количество соединений на процесс" лицензия уровня ПРОФ позволяет изменять
32 Пробел
 
21.01.20
13:05
Тогда жить чуть легче)
33 Fragster
 
гуру
21.01.20
13:10
если добавить в boot.ini /PAE и /3GB, то 32битные процессы в 64битной ОС смогут адресовать аж до 4 ГБ адресного пространства. для обновления измененной КА хватит. И рпхосты пореже станут падать.
34 Сисой
 
21.01.20
13:15
Существуют две группы мудаков:
1. Которые пытаются на файловой 1С эксплуатировать продуктивные многопользовательские БД.
2. Которые пытаются юзать современные типовые решения на 32хразрядном сервере 1С при гигабайтных базах (от 10 Гб).

Лучше в них не вступать.
35 Сисой
 
21.01.20
13:17
Мы еще пять лет назад все сервера на x64 перевели.
36 Cyberhawk
 
21.01.20
13:18
(34) А что с пунктом 2 не так?
37 sitex
 
naïve
21.01.20
13:21
(0) Вот на днях тоже планируем перейти. В чем собственно проявляются тормоз то ?
38 pessimist
 
21.01.20
13:24
(34) Типовые конфигурации работают на x86, но на длинной дистанции для небольшой компании затраты на администрирование выше.
Если есть люди которые хорошо понимают как оно там внутри устроено то всё решается в рабочем порядке, пользователи даже не узнают что были какие-то проблемы. Но небольшой компании такие люди не нужны и зарплату им платить смысла нет. Дешевле купить лицензию на x64 сервер.
39 pessimist
 
21.01.20
13:30
(17) Немного выросло потребление памяти. Но этого "немного" хватило.
Можно было раньше разбираться.
40 pessimist
 
21.01.20
13:35
(11) Нормальный процессор. При запуске на физическом железе 30 попугаев по тесту Гилёва должно быть. Можно работать.
Потребление электричества у сервера конечно раза в два больше чем у современного. Но при наших ценах общая стоимость сравняется не скоро.
41 Nikoss
 
21.01.20
13:37
(34)(36) а что с пунктом 1 не так?
42 Cyberhawk
 
21.01.20
13:51
(41) Меньшая надежность и производительность в многопльзовательском режиме - по сравнению с клиент-севрерным. И об этом официально сказано в разных первоисточниках (ИТС, сайт, ЖКК).
43 Nikoss
 
21.01.20
13:53
(42) 2 пользователя - тоже многопользовательский режим
44 Cyberhawk
 
21.01.20
13:54
(43) Хочешь придраться - ступай в первоисточники и найди там сам то, о чем Я тебе кратко пересказал в предыдущем сообщении
45 Nikoss
 
21.01.20
14:01
(44) я не хочу придраться. Я хочу сделать сноску к (34) сообщению - не нужно воспринимать его всецело за истину. Не редки случаи вполне рабочих многопользовательских систем на файловой БД, как и на 32х битном сервере.
46 d4rkmesa
 
21.01.20
14:02
(11) Думаете, "сервер" из запчастей с Aliexpress?
47 Cyberhawk
 
21.01.20
14:04
(45) "Не редки случаи вполне рабочих многопользовательских систем на файловой БД" // Ошибаешься
48 Сисой
 
21.01.20
14:21
(45) Безусловно. Но надо осознавать риски. А они довольно серьезные. Лично я сразу говорю всем клиентам, что файловый вариант - это в основном для обучения, разработки и базовых версий. Ну можно еще на 2-3 пользователей, если они с разными участками работают и технические перерывы для бэкапов выделены.
49 ansh15
 
21.01.20
15:48
(46) Необязательно, просто давно куплен.
50 ansh15
 
21.01.20
16:02
(34) >> Лучше в них не вступать
Да, выйти оттуда будет весьма нелегко.
Пока вендор предлагает(пусть и с оговорками) эти два решения, мало что изменится.
51 shuhard
 
21.01.20
16:19
(48) у тебя лет 20 как нет клиентов, внутренняя автоматизация =)
52 Ranger_83
 
21.01.20
16:26
(0) После, не значит в следствии.
Сократи ЖР, проведи оптимизацию баз SQL.
53 Сисой
 
21.01.20
17:50
(51) Так бывшие коллеги-то регулярно за советом обращаются. Иногда даже за платным.
54 Evgeney
 
23.01.20
11:18
Обновили сервер на 8.3.15.1830 -  работаю на mac os. Нигде не могу теперь найти тонкий клиент. Кто знает где скачать?
55 Фрэнки
 
23.01.20
11:21
56 Evgeney
 
23.01.20
11:28
Зашел под собой . Однако по ссылке - Ошибка доступа
У Вас нет доступа к данной странице. Уточните пожалуйста ссылку. Если она верна - то обратитесь в техподдержку и вам обязательно помогут найти интересующие вас данные.
57 Evgeney
 
23.01.20
11:50
Кто может, скиньте ссылку на облако какое нибудь с данной версией клиента. Срочно надо. Буду очень благодарен. В компании что нас обслуживает техник на выезде.
58 vladko
 
23.01.20
12:10
59 Evgeney
 
23.01.20
12:17
Спасибо. добрый человек!
60 Провинциальный 1сник
 
23.01.20
13:52
(33) "если добавить в boot.ini /PAE и /3GB, то 32битные процессы в 64битной ОС смогут адресовать аж до 4 ГБ"
В 64-битной ОС эти заклинания не требуются, там изначально 32-разрядные процессы имеют по 4Гб.
61 Провинциальный 1сник
 
23.01.20
13:59
(0) А по теме - действительно, заметил такой нюанс. Судя по профайлеру VerySleepy, можно сделать вывод, что в очередной раз в рантайме сломали динамическую память - malloc/free жрут процессор. Читал, что в многопоточных процессах использовать системную кучу - плохое решение, ибо куча однопоточна, и возникает точка конкуренции за ресурс с блокировками и ожиданием.
62 ansh15
 
31.01.20
10:37
(61) В Linux можно использовать tcmalloc, 1С, в принципе, не против - 1C 8.3. Linux + mimalloc = +10% (ссылка в 11-м сообщении).
63 Провинциальный 1сник
 
31.01.20
12:01
(62) Так особо это не избавит от проблем многопоточной кучи, точка блокировки всё равно останется. Даже если сама куча оптимальнее сделана, чем стандартная. Правильнее было бы для каждого потока создавать свою кучу и выделять память отдельно, но это надо переписывать в платформе, а там и так глюков хватает..
64 GreenSCI
 
31.01.20
12:18
На 1830 32 битный клиент запарил вылетать в режими конфигуратора из-за нехватки памяти. Решил установкой 64 бит. И, да, все тормозит.
65 ezhikofff
 
31.01.20
12:43
(0) Работаем на 8.3.15.1830 (64х) уже почти месяц, тормозов особо не замечено

клиент - серверный вариант баз
УТ, БП, ЗУП - более 300 юзверей
66 Гобсек
 
31.01.20
15:44
(64) Сегодня тоже столкнулся с этой проблемой. Решил тоже переходом на 64-разрядную платформу. Т.е. в режиме конфигуратора на этой платформе лучше использовать 64-разрядную платформу.
67 leo_kov
 
02.02.20
15:10
(58) Добрый день! Не могли бы Вы еще раз ссылку на дистрибутив дать, я тоже не могу на мак поставить)
Спасибо)