|   |   | 
| 
 | 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 | 
        (57) держи:
 https://yadi.sk/d/VnVPsd_DC1qSkg | |||
| 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) Добрый день! Не могли бы Вы еще раз ссылку на дистрибутив дать, я тоже не могу на мак поставить)
 Спасибо) | 
| Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |